目前中通上千个线上应用，一直使用 CAT 作为线上监控工具。随着业务量的增大，采集的数据量直线上升，每秒上报采集的数据上达百万。与此同时，也对数据采集工具的要求也越来越高。但由于 CAT 集群存在宕机、文件破坏、重启失败、丢失数据等问题，所以，中通科技中心自研了中通监控平台 ZCAT。ZCAT 提供了链路数据跟踪、信息采集存储、数据计算、风险预警等能力，低成本的排障方案能帮助不同职级的用户快速定位问题，主要分为这四部分实现:
1) 支持各类客户端 SDK 数据上报;

2) 数据采集计算查询服务;

3) 数据本地存储;

4) 基于查询和报表展示的监控门户;

本文主要介绍如何从功能测试出发，针对 JS SDK 功能、后端 Java 服务数据上报及查询结果验证等实践案例进行分析，最终将功能测试转化为自动化测试的实践过程。

ZCAT 系统架构

首先，来看一下研发架构。ZCAT 客户端 SDK 支持无感知的字节码增强/hook 的方式采集，同时也支持业务方自定义埋点。Java 应用端直接使用 CAT 的客户端上报，服务端兼容 CAT 的 Message 协议。以下是研发架构图。

测试思路

经过对研发的架构进行分析并结合业务功能，可以得知，ZCAT 实际就是经过对用户操作进行采集、存储、再将结果展示到平台供研发、运维等快速查询和跟踪链路问题。但无论是 JS SDK 端还是后端 Java 服务，测试都需要考虑有以下几点：
①　数据如何准备？

②　准备什么样的数据？

③　数据如何上报？

④　数据上报后，用户在查询接口返回的数据如何验证？（用户在查询接口返回的数据是经过聚合后的计算结果，因此，还需要非常清楚这些计算规则。）

带着这些问题，我们继续往下看。
在进入正题之前先来看一下上面提到的两个部分的测试流程图

• JS SDK 测试流程图
  

• Java 后端测试流程图
  由于后端 Java 应用兼容 CAT 协议，与 CAT 客户端上报逻辑一致。业务方在对接了 CAT 客户端后即可灵活上报数据。站在测试的角度，为了让测试工作更加灵活，直接跳过 CAT 客户端直接通过 TCP 链接进行数据上报。
  

数据对比流程

基于上面两个测试流程图结过分析，其实，贯穿整个测试流程，需要做测试工作主要有以下几个部分：

测试点

暂时撇开数据存储各种维度等复杂逻辑，对于功能测试而言，无论是 JS SDK 端还是后端 Java 服务首先要考虑的两个点：

1、数据上报正常；

2、数据查询结果正确；
其次，由这两个点再衍生出更多测试点如下：

• JS SDK 兼容性测试

• JS SDK 所有数据正常上报

• Java 后端所有数据正常上报

• 数据上报后，基于服务端接口查询返回的数据正确

JS SDK 测试

JS SDK 是通过在前端应用中引用 SDK 的 JS 文件进行数据采集并上报到服务器。首先，需要确定数据采集维度；其次，要梳理公司所有的前端框架、确定兼容性测试范围、JS SDK 本身健壮性（异常影响、止血规则）等。最后，上报数据结果的验证。具体如下：

1）数据采集维度

首先，在测试之前，整理出 JS SDK 采集的维度，如下图。

2）兼容性测试

目前，公司主要支持五个前端框架（VUE、Angular、jQuery、H5、React），因此，兼容性测试主要基于这五个框架来开展。

① JS SDK 与各种框架兼容性

为了测试更真实，提前创建好上述五个测试项目，分别引用 JS SDK 文件。利用 Spring Boot 后端服务提供接口，用来模拟各种维度数据返回并供这五个测试项目调用。
分别运行这五个前端项目，通过页面按钮调用模拟访问后端接口，分别上报上文中所提到的几个维度的数据。上报过程中页面调用后端接口时，将上报 PV/UV、访问速度、API 请求、用户满意度等信，再通过页面模拟 JS 异常并抛出。观察 JS SDK 是否正常将数据上报，且通过接口或页面查看这些数据的正确性。

各种框架中引用 JS SDK 文件：

后端 Spring Boot 为前端提供数据模拟接口：

3）健壮性测试

基本异常： 在几个前端框架中模拟下面几种类型异常并观察是否正常返回预期结果

a.引用错误的 JS SDK 文件地址

b.JS SDK 上报数据地址错误

c.引用内部有异常的 JS SDK 文件

可靠的止血规则：JS SDK 通过在前端应用中引用 JS 的文件，采集用户操作行为数据进行上报，因此，要保证在每秒上万的高并发下不会因为 JS SDK 上报异常和服务端数据采集异常影响到业务，它必须要有可靠的止血能力。测试必须要关注以下几个方面（N 收集数据最大量配置）：

a.数据收集限制最大量：

b.数据上报限制最大量：

c.数据上报接口报错限制：

4）数据上报及结果验证

以上几个方面测试完成后，对于五个维度（用户满意度、PV/UV、访问速度、错误数、API 请求）的数据验证，利用自动化的方式快速上报快速检测结果 (由于上报后数据存储与查询方式一致，因此在 Java 后端部分会详细介绍)。直接调用 ZCAT 后端上报接口模拟各种维度数据到服务端，再对返回结果进行验证。

将上报数据封装为对象方便上报。

各种不同类型数据上报方法封装并通过 HttpClient 进行上报：

Java 后端测试

上文提到 ZCAT 兼容 CAT 的协议，Java 后端业务应用通过 CAT 的客户端直接上报数据。在测试过程中直接跳过 CAT 客户端通过 TCP 链接的方式上报数据到服务器。由于在 ZCAT 内部，Message 存储参考了 RocketMQ 的根据 key 做 hash 索引，保证了按照 key 的纬度检索速度，报表存储采用 index 内存存储的方式。当用户查询数据时，程序通过 SQL 查询（参考上文研发架构图）报表按分钟、小时、天等维度进行聚合再返回给用户。在了解这些背景后，自定义丰富的测试数据及结果查询验证是测试关注的重点。

首先，来看一下测试工作推进开始前，还需要了解哪些部分：

1) 数据采集维度

与 JS SDK 一样，后端同样有多种采集维度

2）测试痛点

根据上面数据采集的维度进行分析，测试工作存在以下痛点：

a.测试场景复杂：几十种类型、子类型数据采集上报，业务功能支持数据落盘精确到分钟级别。因此，在上报数据时就要考虑多种场景的组合，单/多分钟，单/多个 IP 等。

b.数据难模拟：上文提到 Java 后端应用数据上报采用 CAT 的 MessageTree 的信息结构，这种结构可读性比较差，大大降低了自定义数据的灵活性。

c.数据结果对比复杂：大量的数据在上报到服务器后，查询结果都是按分钟、小时、天单位经过聚合计算的。

d.数据各类多：主要基于主机、CPU、线程、异常、服务调用等。

在分析了这些痛点后，迫切需要解决的是如何快速、高效上报自定义的数据，丰富测试场景，并验证结果。

自动化实践及收益

结合上面的痛点，在保证了主要业务功能正常运行之后，利用自动化的技术手段不断迭代高效完成测试工作。

自动化测试发展历程

自动化的工程主要使用 Java 和 TestNG 完成, 并且经过了一段时间的演进慢慢成熟的，主要有以下几个阶段：

测试工程框架图

测试工程按功能层级化分为：

• 测试用例：所有的测试用例单独维护

• 业务逻辑层：用例运行时用到的一些业务处理

• 实体类：将接口返回结果全部转为 Java 对象方便数据对比

• 工具类：日期转换、各种计算逻辑方法

• 配置：环境配置、数据上报类型、查询等使用的常量、数据库链接信息等

• Http、ES、MQ、Dubbo：封装几种类型调用的统一出口

• 报告：TestNG 报告

代码实现

1）数据上报模板统一

提前整理上文提到的五个维度的原始 MessageTree 类型的数据，将其转为 Json 模板。对于关键性的数据采用通配符定义（$domain 等），自动化程序运行时替换数据快速生成自定义测试数据丰富测试场景，提高效率。

2）数据计算统一

提前定义日期格式化处理、精度处理、计算等方法，为自动化运行提供日期格式化、数据计算及数据精度处理等。

3）数据上报类型统一

数据上报类型多达几十种，创建类来统一定义这些类型，如 Dubbo（Service, Client) 类型、Http 类型（Service、Client、Request)、MQ 类型（Consumer、Sender, Kafka)、异常、SQL(MySQL、Oracle、MyBatis)、NoSQL(Redis、ES、HBase) 等，为程序能高效运行，提前定义好这些类型。

4）用例命名统一

为了提高可读性，用例相关名称统一，以下是部分代码

5）用例编写统一

为了更好的管理用例执行，每个用例虽然场景不同，但总体运行流程基本相同。下面举例说明用例整体运行流程：

例：入口流量单 IP 多分钟请求用例

第一步：定义部分类全局预期数据，如第一分钟第一次请求耗时数、第一分钟第二次请求耗时数、请求次数、失败次数、成功次数、耗时最大值；第二分钟第一次请求耗时数、第二分钟第二次请求耗时数、请求次数、失败次数、成功次数、耗时最大值

第二步：定义测试用例

定义测试用例时，自定义上报类型、每分钟上报数据等

第三步：数据上报

前面讲过，为了方便模拟自定义数据，将 MessageTree 的结构转成了 Json 模板，在数据上报时，需要将其再转成 MessageTree 的格式通过 TCP 的方式最终上报到 ZCAT 服务端进行存储。

第四步：预期结果计算

为了代码通用性，预期结果使用类对象进行存储，在上文中提过，ZCAT 数据采集后，用户在查询时返回的结果是经过聚合计算的，因此，在数据结果断言前需要将预期结果根据上报的测试数据进行聚合计算并赋值。

第五步：结果断言

数据上报后，服务器对采集的数据根据一定结构进行存储，我们需要验证查询的结果是否正常，调用查询接口并对服务器返回的结果和预期结果进行对比，从而验证数据的正确性。此环节，需要保证代码计算规则是正确的，在编写之前，需要非常清楚各个数据指标的计算规则，否则，结果验证将会失败。

6）用例执行统一

用例执行支持多种类型参数，测试人员可随意定时运行或调整自己执行方式

7）执行结果统一输出

采用 TestNG 的报告进行输出

总结

在项目测试的整个过程中，有时遇到的问题是复杂多样的，需要去分析、思考、不断实践摸索，这样做是否可以更好地解决问题。正如上文所讲，笔者也是经过了几个阶段的演进和迭代，不断探索、改进，最终将项目从功能测试转换为自动化测试，并不断优化测试工程。目前，此自动化测试工程已频繁用在研发日常单元测试、回归测试中。在中通科技像这样的产品比较普遍，站在测试的角度，我们需要不断学习、改进，最终为团队贡献一份力量。

未来规划

目前，此自动化测试工程主要针对 Java 服务端，为了更好的服务团队，未来将打通三端实现自动化测试统一管理（JS SDK 、移动端 SDK、Java 服务端统一管理）；一站式定时执行及结果推送；统一丰富的 Allure 测试报告输出。