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