目前中通上千个线上应用，一直使用CAT作为线上监控工具。随着业务量的增大，采集的数据量直线上升，每秒上报采集的数据上达百万。与此同时，也对数据采集工具的要求也越来越高。但由于CAT集群存在宕机、文件破坏、重启失败、丢失数据等问题，所以，中通科技中心自研了中通监控平台ZCAT。ZCAT提供了链路数据跟踪、信息采集存储、数据计算、风险预警等能力，低成本的排障方案能帮助不同职级的用户快速定位问题，主要分为这四部分实现:1)支持各类客户端SDK数据上报;
2)数据采集计算查询服务;
3)数据本地存储;
4)基于查询和报表展示的监控门户;
本文主要介绍如何从功能测试出发，针对JSSDK功能、后端Java服务数据上报及查询结果验证等实践案例进行分析，最终将功能测试转化为自动化测试的实践过程。
首先，来看一下研发架构。ZCAT客户端SDK支持无感知的字节码增强/hook的方式采集，同时也支持业务方自定义埋点。Java应用端直接使用CAT的客户端上报，服务端兼容CAT的Message协议。以下是研发架构图。
经过对研发的架构进行分析并结合业务功能，可以得知，ZCAT实际就是经过对用户操作进行采集、存储、再将结果展示到平台供研发、运维等快速查询和跟踪链路问题。但无论是JSSDK端还是后端Java服务，测试都需要考虑有以下几点：①数据如何准备？
②准备什么样的数据？
③数据如何上报？
④数据上报后，用户在查询接口返回的数据如何验证？（用户在查询接口返回的数据是经过聚合后的计算结果，因此，还需要非常清楚这些计算规则。）
带着这些问题，我们继续往下看。在进入正题之前先来看一下上面提到的两个部分的测试流程图
基于上面两个测试流程图结过分析，其实，贯穿整个测试流程，需要做测试工作主要有以下几个部分：
暂时撇开数据存储各种维度等复杂逻辑，对于功能测试而言，无论是JSSDK端还是后端Java服务首先要考虑的两个点：
1、数据上报正常；
2、数据查询结果正确；其次，由这两个点再衍生出更多测试点如下：
JSSDK是通过在前端应用中引用SDK的JS文件进行数据采集并上报到服务器。首先，需要确定数据采集维度；其次，要梳理公司所有的前端框架、确定兼容性测试范围、JSSDK本身健壮性（异常影响、止血规则）等。最后，上报数据结果的验证。具体如下：
首先，在测试之前，整理出JSSDK采集的维度，如下图。
目前，公司主要支持五个前端框架（VUE、Angular、jQuery、H5、React），因此，兼容性测试主要基于这五个框架来开展。
①JSSDK与各种框架兼容性
为了测试更真实，提前创建好上述五个测试项目，分别引用JSSDK文件。利用SpringBoot后端服务提供接口，用来模拟各种维度数据返回并供这五个测试项目调用。分别运行这五个前端项目，通过页面按钮调用模拟访问后端接口，分别上报上文中所提到的几个维度的数据。上报过程中页面调用后端接口时，将上报PV/UV、访问速度、API请求、用户满意度等信，再通过页面模拟JS异常并抛出。观察JSSDK是否正常将数据上报，且通过接口或页面查看这些数据的正确性。
基本异常：在几个前端框架中模拟下面几种类型异常并观察是否正常返回预期结果
a.引用错误的JSSDK文件地址
b.JSSDK上报数据地址错误
c.引用内部有异常的JSSDK文件
a.数据收集限制最大量：b.数据上报限制最大量：c.数据上报接口报错限制：
以上几个方面测试完成后，对于五个维度（用户满意度、PV/UV、访问速度、错误数、API请求）的数据验证，利用自动化的方式快速上报快速检测结果(由于上报后数据存储与查询方式一致，因此在Java后端部分会详细介绍)。直接调用ZCAT后端上报接口模拟各种维度数据到服务端，再对返回结果进行验证。
将上报数据封装为对象方便上报。
各种不同类型数据上报方法封装并通过HttpClient进行上报：
首先，来看一下测试工作推进开始前，还需要了解哪些部分：
与JSSDK一样，后端同样有多种采集维度
根据上面数据采集的维度进行分析，测试工作存在以下痛点：
a.测试场景复杂：几十种类型、子类型数据采集上报，业务功能支持数据落盘精确到分钟级别。因此，在上报数据时就要考虑多种场景的组合，单/多分钟，单/多个IP等。
b.数据难模拟：上文提到Java后端应用数据上报采用CAT的MessageTree的信息结构，这种结构可读性比较差，大大降低了自定义数据的灵活性。
c.数据结果对比复杂：大量的数据在上报到服务器后，查询结果都是按分钟、小时、天单位经过聚合计算的。
d.数据各类多：主要基于主机、CPU、线程、异常、服务调用等。
在分析了这些痛点后，迫切需要解决的是如何快速、高效上报自定义的数据，丰富测试场景，并验证结果。
结合上面的痛点，在保证了主要业务功能正常运行之后，利用自动化的技术手段不断迭代高效完成测试工作。
测试工程按功能层级化分为：
提前整理上文提到的五个维度的原始MessageTree类型的数据，将其转为Json模板。对于关键性的数据采用通配符定义（$domain等），自动化程序运行时替换数据快速生成自定义测试数据丰富测试场景，提高效率。
提前定义日期格式化处理、精度处理、计算等方法，为自动化运行提供日期格式化、数据计算及数据精度处理等。
数据上报类型多达几十种，创建类来统一定义这些类型，如Dubbo（Service,Client)类型、Http类型（Service、Client、Request)、MQ类型（Consumer、Sender,Kafka)、异常、SQL(MySQL、Oracle、MyBatis)、NoSQL(Redis、ES、HBase)等，为程序能高效运行，提前定义好这些类型。
为了更好的管理用例执行，每个用例虽然场景不同，但总体运行流程基本相同。下面举例说明用例整体运行流程：
例：入口流量单IP多分钟请求用例
第一步：定义部分类全局预期数据，如第一分钟第一次请求耗时数、第一分钟第二次请求耗时数、请求次数、失败次数、成功次数、耗时最大值；第二分钟第一次请求耗时数、第二分钟第二次请求耗时数、请求次数、失败次数、成功次数、耗时最大值
第二步：定义测试用例
定义测试用例时，自定义上报类型、每分钟上报数据等
第三步：数据上报
前面讲过，为了方便模拟自定义数据，将MessageTree的结构转成了Json模板，在数据上报时，需要将其再转成MessageTree的格式通过TCP的方式最终上报到ZCAT服务端进行存储。第四步：预期结果计算
为了代码通用性，预期结果使用类对象进行存储，在上文中提过，ZCAT数据采集后，用户在查询时返回的结果是经过聚合计算的，因此，在数据结果断言前需要将预期结果根据上报的测试数据进行聚合计算并赋值。
第五步：结果断言
数据上报后，服务器对采集的数据根据一定结构进行存储，我们需要验证查询的结果是否正常，调用查询接口并对服务器返回的结果和预期结果进行对比，从而验证数据的正确性。此环节，需要保证代码计算规则是正确的，在编写之前，需要非常清楚各个数据指标的计算规则，否则，结果验证将会失败。
6）用例执行统一
用例执行支持多种类型参数，测试人员可随意定时运行或调整自己执行方式
7）执行结果统一输出
采用TestNG的报告进行输出
在项目测试的整个过程中，有时遇到的问题是复杂多样的，需要去分析、思考、不断实践摸索，这样做是否可以更好地解决问题。正如上文所讲，笔者也是经过了几个阶段的演进和迭代，不断探索、改进，最终将项目从功能测试转换为自动化测试，并不断优化测试工程。目前，此自动化测试工程已频繁用在研发日常单元测试、回归测试中。在中通科技像这样的产品比较普遍，站在测试的角度，我们需要不断学习、改进，最终为团队贡献一份力量。
目前，此自动化测试工程主要针对Java服务端，为了更好的服务团队，未来将打通三端实现自动化测试统一管理（JSSDK、移动端SDK、Java服务端统一管理）；一站式定时执行及结果推送；统一丰富的Allure测试报告输出。