编者按:本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》,扫描上方二维码或前往:https://developer.aliyun.com/topic/devops,下载完整版电子书,了解阿里十年DevOps实践经验。

在任何业务发展的过程中都会不可避免的面临服务的膨胀,应用复杂度的增加,可持续测试的难度不断增加。一方面,用例集会不断的膨胀,一次 CI 验证要数十分钟,用例的维护成本越来越高,开发效率开始降低。另一方面,我们花了精力写了很多自动化用例,希望能够提高投入产出比,也就是测试的有效性。

提升测试速度

分布式测试

分布式测试的核心思想是通过增加计算资源,并发的对 case 进行执行,并在执行后对测试产生的结构化结果进行解析合并,进而提升单次测试的执行速度。

整个测试的执行过程可以划分为以下三个阶段:

  • 测试用例解析与分发
  • 分组用例的执行
  • 分组测试结果合并

以阿里云某云产品核心团队的某工程为例,该工程拥有 1 万多个单元测试用例,在没有采用分布式测试方案之前,一次 CI 的验证时长超过 4 小时,导致问题发现、修复时长拉长,影响了日常的迭代速度。该团队后采取了分布式测试的方式进行,平均的执行时长被优化到了半小时以内。

分布式测试的本质就是用执行资源的堆叠,去换取更快的执行速度。理论上我们把每一个测试用例拆分到一个容器内执行,可以获得极致的反馈速度。但是并不是所有场景下都适合采用分布式测试,例如用例之间存在依赖,这些用例不能无差别的分布在不同的执行分组。

精准测试

分布式测试很大程度上解决了测试执行的速度问题。但是如果在任何情况下都无差别的执行全量的用例,会存在一些问题:

  • 对计算资源的浪费
  • 引入了大量的无效执行
  • 用例本身稳定性问题导致排查时间浪费
  • 在探索测试有效性的过程中,我们引入了精准测试的方案

什么是精准测试?

通过建立测试用例与业务方法的关联关系,在代码发生变化时,精准的推荐出需要运行的用例,进行测试执行与结果反馈。通过精准的圈定测试范围,可以带来效率和速度的双重收益。

精准测试的基本要素

  • 测试用例(Case)与应用代码方法(CodeMethod)关联关系的建立。这种关联关系,我们定义为基线
  • 代码发生变更,根据基线中用例与应用代码方法的关联关系,准确推荐出变化的方法、关联的测试用例变化的测试用例,并进行运行。

如何建立测试基线

  • 基线的建立方式有多种,在阿里巴巴内部使用过以下两种方法去建立用例与代码的关联。
  • 通过字节码注入的方式,埋入 trace 调用,并在调用中传入用例与业务方法的签名。通过采集 trace 的日志,拿到所有的测试用例与方法调用链路,建立起用例与方法的关联关系。
  • 通过 AST 解析的方式。

如何进行用例推荐

在代码发生变更后,会基于代码变更解析出变化的测试用例与变化的业务方法。方法的变化通常是新增、删除、更新。

用例的代码变更情况比较简单,所有新增和更新的用例都会纳入到回归范围。

被测应用代码变更,要分情况考虑:

  • 新增的方法:匹配不到任何用例,针对此次变更,开发或测试可能补充了测试用例,也可能未补充,需要进行提示。
  • 更新的方法:更新的方法分两种情况,第一种,更新的方法有关联的用例,需要推荐出来;第二种,更新的方法原本就没有关联任何用例,需要提示用户补充测试用例进行覆盖。
  • 删除的方法:删除的方法也分两种情况,第一种,该方法本身就不关联任何测试用例,不做任何提示;第二种,该方法关联了一些测试用例,那么考虑到方法有可能只是重构或者更名的情况,这部分关联的测试用例在没有被删除的情况下,也是需要进行回归的。

阿里云某核心云产品,通过使用精准测试的方案,一个迭代了一周左右的代码变更,从原先每次 CI 需要全量执行 3700+用例,到每次 CI 可以精准的执行变更影响的用例范围。速度提升了近一倍,测试范围缩小到不到原先的 1/6。


提升测试有效性

我们希望编写和运行的测试用例能够有效的覆盖代码的逻辑,其中重要的一个着手点是测试覆盖率,通过测试覆盖率来暴露问题,并促进问题的解决。

测试覆盖率

测试覆盖率,在本文中,指的是代码的覆盖率。即行覆盖率,分支覆盖率等。

此外,本文中所有涉及覆盖率采集的示例都以 Java 为例。

如何收集完整的覆盖率

一个应用下通常存在多种不同类型的自动化测试集

  • 单元测试
  • 手工测试
  • API 测试
  • WebUI 测试
  • 其他

为了能够准确的反映一个应用的完整覆盖率,需要对上述多种自动化测试的结果进行聚合。在阿里,每一个测试的运行都会关联到相应的应用,从而可以对测试结果进行聚合。

为了能够收集所有类型的测试覆盖率,我们做了以下事情:

单元测试

对于单元测试来说,覆盖率数据产生在单测执行的机器上,我们会根据执行机上的原始代码信息,编译后的 class 信息,单测执行后产生的覆盖率数据原始文件,以及变更的代码信息,计算出单元测试的覆盖率报告。

手工/自动化测试

我们实现了一个覆盖率采集客户端,和一个覆盖率采集/报告计算解析的覆盖率平台。通过运维平台将覆盖率采集客户端部署到应用的集成环境,在应用启动时会挂载一个 javaagent 进程。当我们在任意测试平台触发任意类型的自动化测试时,会通知覆盖率平台与覆盖率采集客户端进行交互,完成覆盖率计算原始数据的采集与解析。

另外,在进行发布卡点时,我们会合并相应的单测覆盖率形成完整的覆盖率报告。

测试覆盖率能给研发过程带来哪些价值

  • 分析未覆盖部分的代码,从而反推在前期测试设计是否充分,没有覆盖到的代码是否是测试设计的盲点,为什么没有考虑到?需求/设计不够清晰,测试设计的理解有误,工程方法应用后的造成的策略性放弃等等,之后逐步补充测试用例。
  • 代码覆盖率高不能说明代码质量高,但是反过来看,代码覆盖率低,代码质量不会高到哪里去,可以作为测试自我审视的重要工具之一。
  • 分析变更代码的覆盖情况,从而保证对变更的测试充分,增强发布成功率与信心。

除了上述的“测试覆盖率”,还可以使用相同的技术来统计“线上业务对代码的覆盖情况”。也就是统计出来有哪些代码是被真正的线上业务所用到的,哪些是从来没有被调用到的。从而检测出程序中的废代码,可以逆向反推在代码设计中思维混乱点,提醒设计/开发人员理清代码逻辑关系,提升代码质量。

增量覆盖率

有了完整的测试覆盖率数据之后,就可以让它发挥作用了。但脱离了具体的场景,单独追求一个较高的测试覆盖率数值是没有意义的。如果一味的追求较高的覆盖率的数值,往往带来的的是用例的过度设计。如何健康有效的让项目的测试覆盖率稳步的提升,在阿里巴巴内部,我们更多的是采用关注增量覆盖率的方式来提升整体的测试覆盖率。

什么是增量覆盖率

增量覆盖率是指,某一次测试过程中,变化的代码的测试覆盖情况。

变化的代码=被测分支的代码与目标对比分支的 diff(通常目标对比分支是我们最终会合入的分支)。

增量覆盖率=变化的被覆盖的代码行/变化的代码行。

增量覆盖率的价值

  • 发布之前是否存在漏测
  • 针对漏测完善用例集
  • 增强变更发布的成功率与发布信心
  • 通过追求增量覆盖率进而提高被测应用的整体测试充分度

增量覆盖率的应用

在单元测试的时候,会有单元测试的增量覆盖率,在测试/预发等环境进行各种接口自动化/UI 自动化/流量回放/手工测试时,也会有增量覆盖率产生。当增量覆盖率与持续交付流水线进行结合时,能够有效的保障项目质量是在往好的趋势发展。

在阿里巴巴内部的实践中,我们通常会在 CICD 流水线中的关键阶段设置各类卡点,保障在多人协作的场景下,每个开发同学提交进入集成的代码经过充分的自测。在上线前的集成阶段,进入的代码在集成环境中被充分验证后,才会被允许发布上线。

通过增量覆盖率的反馈,开发/测试同学可以针对性的去补充各类测试用例,尽可能的保障在各阶段不存在测试遗漏。同时,在不断的完善测试集的情况下,项目的整体测试覆盖率也会得到健康有效的提升。

线上覆盖率

覆盖率的采集我们通常不会应用到线上环境中,但是如果将覆盖率采集放到线上环境,又能演化出应用瘦身的场景,帮助我们从另外一个角度提升效率。

通常在线业务的服务都会部署多个副本,为了减少风险,我们会在其中的少量副本上进行覆盖率采集。经过一个较长的采集周期后,会生成线上覆盖率报告。在这个时候可以认为被覆盖到的代码都是有效代码,而剩下的那些长时间没有流量覆盖的代码,需要谨慎的考虑删除/重构。通过这样的方式去精简我们的代码,从而降低维护成本。

在阿里巴巴内部,当我们决定对某些维护困难或者腐化明显的应用进行重构时,都会进行一段时间的线上覆盖率采集,并根据报告去指导我们进行代码重构,代码瘦身。

小结

分布式测试为测试速度插上了翅膀,精准测试有效的识别出了测试的范围,增量覆盖率又为测试的不断完备提供了有利的指引,线上覆盖率帮助我们有效的进行应用瘦身。充分利用好这些技术手段进行测试提效,可以让持续交付的过程更加的顺畅。

【关于云效】

云效,云原生时代一站式BizDevOps平台,支持公共云、专有云和混合云多种部署形态,通过云原生新技术和研发新模式,助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷,打造“双敏”组织,实现 10 倍效能提升。

立即体验

阿里巴巴如何进行测试提效 | 阿里巴巴DevOps实践指南的


扫描二维码,在手机上阅读!