freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

知物由学 | 无需了解业务 也可进行低成本高覆盖的测试方法
2020-04-14 20:50:32

​​“知物由学”是网易易盾打造的一个品牌栏目,词语出自汉·王充《论衡·实知》。人,能力有高下之分,学习才知道事物的道理,而后才有智慧,不去求问就不会知道。“知物由学”希望通过一篇篇技术干货、趋势解读、人物思考和沉淀给你带来收获的同时,也希望打开你的眼界,成就不一样的你。当然,如果你有不错的认知或分享,也欢迎在“网易易盾”公众号后台投稿。


作为国内领先的内容安全&业务安全服务商,领先的不仅仅是智能、高效、稳定的安全能力,其整个开发流程都非常具有代表性。本文就从测试角度,分享我们在API项目引流测试上的实践,即通过引流平台,将线上用户的真实流量复制,并运用于自动化回归测试中,精准覆盖核心业务逻辑,实现了低成本的日常自动化回归。


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

1.jpg

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

2.jpg

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

3.jpg

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

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

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

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

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

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

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

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

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

4.jpg

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

他们说:

我们有完善的mock机制,你说的上述mock痛点我们都能解决!
线上数据多种多样,数据清理工作不用做了!
录制线上流量在测试环境回放,可以真实模拟线上用户行为,核心业务逻辑覆盖不遗漏!
快速接入平台,支持录制实时回放,快速验证录制用例的有效性,快速建立回归用例!降本提效,唯快不破!

5.jpg

为了证(偷)明(懒)他(不)们(用)没(写)有(接)在(口)吹(用)牛(例),我决定试一试这个引流平台。

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

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


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


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

6.jpg

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


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

7.jpg

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

8.jpg

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


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

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


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


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


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


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

9.jpg

第六步:沉淀回归用例集


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

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


第七步:引流测试效果


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

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

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

3、异常逻辑覆盖,比如针对供应商返回错误码的处理,线上较少出现这种情况,没有录制到相关流量

理论上来说,随着录制量越来越多,以及不同时间段错开录制,数据会更加多样化,代码行覆盖率也会越来越高。


实践小结


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

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

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

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

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


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

10.jpg

当然还有一些问题


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


1、代码行覆盖率的提升


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


2、用例稳定性考量


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


还有展望


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


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


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


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


相关阅读:

  1. 知物由学第五十四期 | 社交风控中遇到的问题,可以用这些手段进行“围追堵截”
  2. 知物由学第五十三期 | ESIM模型的“全能版”!网易易盾实验室研究员解读HIM混合推理模型
  3. 知物由学第五十二期 | 浅谈网易易盾云真机检测


点击免费试用【稳定的】网易易盾安全服务。


本文作者:, 转载请注明来自FreeBuf.COM

# 内容安全,业务安全
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
评论 按时间排序

登录/注册后在FreeBuf发布内容哦

相关推荐
  • 0 文章数
  • 0 评论数
  • 0 关注者
登录 / 注册后在FreeBuf发布内容哦
收入专辑