我们在做数据统计类的测试时，往往需要准备各种源数据，如果是本系统的内部产生的数据，还好处理，但如果是一些对接第三方的数据报表测试，该如何展开呢？本文通过两种常见的场景来做一些分享。
01 模拟接口造数
如上，这是一个网关平台需要采集中间件 WAF 上报的请求流量监控，在实际的应用中，需要用户把 WAF 的 SDK 集成到自己的应用上，然后 SDK 会定期把数据上报到网关平台，加以展示，那么，在这种场景下，测试人员应该如何生成数据来验证报表的展示呢？数据库虽然有存数据，但都是原始数据，而且涉及多张表，不好直接通过 SQL 插入。
备选方案一：自己模拟一个服务（不行就让开发协助），带上 WAF 的 SDK，然后运行程序，手动访问，生成 http 请求数据，然后验证页面数据是否准确。
缺点：
1.过分依赖开发，如果换个监控项（要采集 CPU 使用等信息），都需要开发配合修改服务（自己有能力写一个也是可以的，但是成本较高）。
- 数据处理不灵活，比如需要 CPU 高于 80% 的，需要运行一个很耗 CPU 的代码 ，不是很好处理。
备选方案二：了解开发的实现过程，得知数据由 WAF 的 SDK 上报到平台，那么我们只要模拟这个过程就可以了，弄清楚平台需要的数据格式，那我们是不是就可以直接修改不同的监控项及对应的指标，想怎么报就怎么报？
缺点：
1.需要深入地了解业务实现方式，且需要一定的编码能力。
- 在实际场景中，如果 WAF 的上报功能有问题，无法验证到。
我们的选择：采用方案二，灵活制造数据，验证各种所需要被验证到的场景。关于这种办法的缺点，其实 WAF 的上报功能并不是本次测试的功能点，所以可以默认它是没有问题的（需要和开发保持良好的沟通，数据结构发生变更时，及时通知测试。如果不通知，测试过程中也是能够发现的，只是比较滞后，可能会误提 BUG）。这也体现了分段测试的思想。
02 构建 Mock 服务
如上，这是一个实时查询的接口，数据来源于 Zipkin 的日志统计分析，与上一个场景不同的是，这是一个实时查询接口，被测平台传查询条件到 Zipkin，Zipkin 通过条件查询对应的日志文件，生成数据。所以我们没有办法像上一个场景那样去模拟接口。那么，这种场景又该如何测试呢？
备选方案一：让开发模拟一个服务，接入 Zipkin，然后运行程序，手动访问，生成对应的接口数据，验证前端的展现是否正确。
缺点：
1.过分依赖开发，如果需要换一个服务，或者接口类型，都需要开发配合修改服务（自己有能力写一个也是可以的，但是成本较高）。
- 数据处理不灵活，比如很难模拟接口调用超时，或者超过 5S 才响应。
备选方案二：了解开发的实现过程，得知我们的应用是访问 Zipkin 系统的指定接口，返回数据并展现，并不关心 Zipkin 接口的内部实现。那么我们是不是可以把这个接口调个包？变成我们模拟的接口，只要返回的数据格式和 Zipkin 接口的一样，不就可以了？
缺点：
1.需要深入地了解业务实现方式，且需要一定的编码能力。
- 需要自己 mock 一个接口出来，并有一定的逻辑根据业务返回不同的数据。
我们的选择：自己搭建一个 mock 平台，配置好不同的入参及返回数据，然后让平台配置文件中的 Zipkin 的接口指向我的 mock 地址，就可以了实现了（就相当于自己搭建的 Zipkin 平台）。这样，我们只要修改 Mock 的响应，就可以在被测平台中展示不同的数据，以验证平台的展示是否 OK（排序、分页、界面溢出等场景）。此方案的缺点及解决方案与上一个场景一样，这就不再赘述。
03 熟悉被测系统架构
平常在测试过程中，我们需要深入地去了解被测系统，问自己以下几个问题：
你测试的系统后面的逻辑拓扑是什么，各负责哪些职责？
你测试的系统采用的开发架构是什么？应用架构？数据库？中间件？
你测试的系统数据流向是什么？哪些数据是自己系统产生并处理？哪些是需要上下游系统支持？数据如何传递？
只有当你深入了解系统的实现机制后，才能对 BUG 产生的根本原因有很好的认知，并对 BUG 进行总结、分类。总结不同技术产生的常见问题，进行针对性的业务覆盖，提高测试的有效性。（关于如何熟悉被测系统，可参考茹老师的文章：优秀的测试工程师为什么要懂大型网站的架构设计）
04 小结
当我们在测试这类报表，需要强依赖第三方的数据时，需要能够区分被测平台获取数据的方式，以便快速构造对应的场景，生成相对简单可维护的数据结构，用于测试。对于数据本身的正确与否，需要在对应系统中去做验证，等上下游的测试都走通了，再进行一次端到端的拉通测试，而不是等着上下游的数据（因为可能会涉及多系统，不同的团队，研发节奏不对称，不能干等着，是吧）。这也是分段测试思想的落地应用。
