引流测试:一种低成本高覆盖无需了解业务的测试方法

你们有没有遇到过一个项目,曾易手多人,开发和QA换了一茬又一茬,短时间内无法全面熟悉内部逻辑,没有完善的自动化回归用例集,每次上线前都感觉心好慌?

我所在的易盾部门,致力于提供业内领先的安全服务解决方案,随着近几年的高速发展,安全产品线越来越丰富,目前已多达20余个。在这过程中,有些业务线出现重组优化,人员变更的情况。我现在手里就有这么一个API项目,在迭代过程中,开发换了两三个,QA换了两三个,历史的接口用例在几经易手后七零八落,没有完整的接口自动化回归用例。然而,一个API服务没有完善的自动化回归用例,这是任何一个有担当有作为的QA同学所不能忍受的。我还记得那位靠谱的开发小哥哥过来问我:“我优化了底层服务的一些逻辑,你们有没有自动化回归用例集跑一遍”,而我尴尬地说没有的时候,他失望的表情深深地刺痛了我的心。

此处插个题外话,这个项目最初的1.0版其实就是我测的,后来转手给其他QA同学,最后兜兜转转,又回到了我手里,真是天道好轮回,苍天绕过谁。


然而要从头梳理完整的接口回归用例集可不是一件容易的事情,尤其是在短时间内无法快速熟悉内部逻辑,用例设计遗漏风险是较高的。

另外,这个项目有个特殊之处,它会调用好几个外部供应商服务,而这些供应商服务是收费的,平常测试时数据量不大,费用不高,项目组也能接受,而如果频繁地进行回归,日积月累,势必是一笔不小的开支。所以如果要进行自动化回归,必须把这些供应商服务mock掉。

mock这些供应商服务可是一个不小的工作量!看了下这些供应商服务,除了常见的http服务,还有一个是web service服务(使用soap协议),两者的mock解决方案是不通用的,我得搭两套mock服务。

还要设计各种各样的mock用例,覆盖不同供应商接口的返回值,后期维护这些mock用例也是个巨大的工程。

综上所述,我大致罗列了下完善自动化回归用例目前的难点和痛点:

1.需要自己搭建mock供应商接口的服务,低效耗时;

2.设计较多mock供应商接口的用例,后期维护成本高;

3.部分固定的自动化回归用例执行过一次之后会失效,需要做一些数据清理工作;

4.短期内难以全面熟悉内部逻辑,用例设计遗漏风险较高。

这时,引流平台向我们抛出了橄榄枝。他们说:

1.我们有完善的mock机制,你说的上述mock痛点我们都能解决!

2.线上数据多种多样,数据清理工作不用做了!

3.录制线上流量在测试环境回放,可以真实模拟线上用户行为,核心业务逻辑覆盖不遗漏!

4.快速接入平台,支持录制实时回放,快速验证录制用例的有效性,快速建立回归用例!降本提效,唯快不破!


为了证()明()他()们()没()有()在()吹()牛(),我决定试一试这个引流平台。

引流测试的主要原理就是将线上流量录制下来在测试环境中回放,并将线上流量的结果与测试环境回放的结果进行比对,如果两者一致,说明测试环境功能和线上是一致的,如果不一致,则需要排查测试环境是否有bug,或者是因为功能改动造成的。回放一致的流量可以沉淀成回归用例集,这部分用例可以反复使用进行回归,节省录制新流量的时间。

原理没毛病,接下来就是实践了。引流平台的小伙伴热心又负责,让我感受到了VIP客户的待遇。

第一步:环境对接,耗时:20分钟

环境对接确实很快,只需要在引流平台上执行一些基础步骤,把他们提供的脚本放在被测应用的机器上,执行脚本成功后即可。


第二步:Mock配置,耗时:若干天

Mock是引流平台的一大特性,它会将线上流量每一步的调用链路都录制下来,记录下每个中间步骤的入参和返回结果,从而实现mock。平台提供了通用的中间件mock配置,比如Redis,kafka,mybaits等,但是对于代码中一些时间戳、随机数,本地缓存等数据,还有参数校验、调用供应商等方法,需要提供具体的类名和方法名才能实现精准mock。通过这种手段,可以解决测试环境和线上环境业务数据不一致的情况。如图所示:


这一步往往需要阅读代码找出那些需要mock的类和方法,而且为了最大限度覆盖代码业务逻辑,一般是需要找到最底层的调用方法。否则把上层方法mock了,那底层的代码逻辑就覆盖不了了。但有时候会出现引流平台录制不到底层的mock方法,只能选择mock往上一层的方法。所以这一步mock配置很难一次性就能配置正确的,需要阅读代码找到mock的具体类和方法,会耗费较多时间。在一次次回放失败中不断调式定位,反复分析代码,终于补全了所有的mock方法:


第三步:录制,耗时:20-30分钟

录制,即引流操作,是将用户实际操作的流量或者测试人员手工测试的流量记录下来,录制下来的数据为作为回放的数据源。

平台支持全量接口的录制,也可以选择录制某几个接口。录制时长和录制总条数都可以手动设置,哪个条件先满足就停止录制,我一般设定的录制时长是20-30分钟。另外还要设置采样率,例如采样率10%,就是录制10%的流量。这里遇到的问题就是我们的项目需要设置mock的方法较多,导致引流平台在录制采样时链路跟踪记录过多出现线程安全问题,会丢弃某些数据,导致回放失败,所以每次录制的采样率不能设的过高,目前采样率需要控制在10%以内。而有些项目没有这方面的问题,采样率100%也是ok的。

第四步:回放,耗时:5分钟

将刚才录制下的流量,在被测应用的测试环境中进行回放,看相同的请求入口,输入相同的请求参数,在Mock了基准数据后,请求的返回是否与录制的时候一样,以此来实现功能验证。被测应用是个API服务,因此回放速度是很快的。我还尝试了下录制并实时回放功能,一边录制一边回放,录制结束的同时回放也结束了,十分高效。

第五步:查看测试结果并分析

回放结束之后,就能立马看到成功和失败的用例。如果全部成功,则说明测试环境功能正常,我们主要关注失败的用例,分析失败的原因,是bug引入or需求变动导致的。平台跟踪并记录了请求过程中调用链路上的每个环节,并提供线上环境与测试环境的比对,可以点击进入详情页查看:


第六步:沉淀回归用例集

引流平台会将回放成功的用例进行汇总统计,放进【用例统计】中,然后可以在这些用例中,自定义选取用例生成用例集合,用这个用例集合回放实现回归测试。同时提供用例去重功能,即相同接口且入参一样的用例,只保留最新的。目前已沉淀了一批用例,后续日常回归可以将这批用例全量进行回放,省去线上环境录制新流量的时间,整个流程只要几分钟就搞定了。

当然随着代码的变更迭代,用例统计中录制的历史数据在后续回放中可能会失败,可以将这些回放失败的用例一键删除,这个功能我觉得十分好用。

第七步:引流测试效果

衡量引流测试效果的指标当然是代码行覆盖率了,引流平台的未来规划是将覆盖率集成进来,通过覆盖率做自动推荐用例,但该功能还在孵化中,我只能自己手动统计了。最后统计出来代码行覆盖率达 63% ,分析了下,基本覆盖了线上用户的主要使用路径,没有覆盖的代码行主要是以下几点:

1.mock了一些参数校验方法

2.有些mock方法较上层,少了部分覆盖

3.异常逻辑覆盖,比如针对供应商返回错误码的处理,线上较少出现这种情况,没有录制到相关流量
理论上来说,随着录制量越来越多,以及不同时间段错开录制,数据会更加多样化,代码行覆盖率也会越来越高。

实践小结:

在实践引流测试之前,引流平台负责人曾和我一起展望了下预期收益率,如今回顾了下,它确实做到了当初的一些承诺:

1.弥补回归用例缺失:通过录制回放快速回归,保障项目质量

2.节约时间成本:自带mock机制,无需额外实现mock供应商的微服务

3.节约用例维护成本:回放成功的用例不断沉淀形成回归用例集,并且提供去重功能,用例维护成本低

4.降低用例遗漏风险:真实模拟线上使用情况,无需全面熟悉内部逻辑,依然可以实现主干业务逻辑的精准覆盖

当下一次开发小哥哥让我回归一下API服务时,我可以从容不迫地打开引流平台,创建回归用例集,启动录制回放任务,然后去泡一杯菊花枸杞茶 ,悠哉地喝上一口,点击查看测试报告,然后向开发小哥哥报告:回归测试通过,可以上线啦~


当然还有一些问题:

没有完美的测试工具,此次引流测试实践也遗留了一些问题。

1.代码行覆盖率的提升

根据我们测试团队的实践经验,一个API服务的代码行覆盖率是可以达到 70% 以上的,目前我们核心业务自动化回归测试的代码行覆盖率均在70%以上。引流测试实现主干业务逻辑的精准覆盖,然而因为mock原因以及线上流量缺少异常逻辑覆盖,导致代码行覆盖率无法进一步提升,这些未覆盖的代码还是需要额外手段去覆盖补充。

2.用例稳定性考量

目前是通过引流测试建立回归用例集,所以线上流量结果和测试环境回放结果是一致的(若不一致就是引流平台的bug了),后续随着业务迭代变更,若出现两者结果不一致的情况,是否能够快速定位分析问题所在,修复回归自动化用例,缺少实际经验,回归用例稳定性方面有待考量。

还有展望:

1.开展更多引流测试实践

这次接入引流平台的项目是一个整体架构较为简单、核心功能只有一个模块应用的小型API项目,本身也比较适合引流测试。后续希望开展更多项目的引流测试实践,在现有测试手段的基础上,通过引流测试真实模拟用户使用情况,有效确保核心业务逻辑精准覆盖,提升质量信心。

2.将引流测试融入日常研发流程

引流测试可以进行历史功能回归、重构功能的测试与验收,相比其他测试手段,引流测试是一种低成本高覆盖的测试方案,无需测试分析、人工设计用例,测试准备和测试执行的工作大大减少,非常适合成为开发自测的手段。如何让引流测试融入日常研发流程,也是需要不断摸索的。在后续的实践过程中,要让引流测试真真切切带来降本提效,为开发自测赋能,为QA解决痛点,为项目提升效率,为质量保驾护航。(作者:叶子)