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

文章图片

编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实践指南》，扫描上方二维码或前往：https://developer.aliyun.com/topic/devops，下载完整版电子书，了解阿里十年DevOps实践经验。
在任何业务发展的过程中都会不可避免的面临服务的膨胀，应用复杂度的增加，可持续测试的难度不断增加。一方面，用例集会不断的膨胀，一次 CI 验证要数十分钟，用例的维护成本越来越高，开发效率开始降低。另一方面，我们花了精力写了很多自动化用例，希望能够提高投入产出比，也就是测试的有效性。
提升测试速度分布式测试
分布式测试的核心思想是通过增加计算资源，并发的对 case 进行执行，并在执行后对测试产生的结构化结果进行解析合并，进而提升单次测试的执行速度。
整个测试的执行过程可以划分为以下三个阶段：

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

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

文章图片

以阿里云某云产品核心团队的某工程为例，该工程拥有 1 万多个单元测试用例，在没有采用分布式测试方案之前，一次 CI 的验证时长超过 4 小时，导致问题发现、修复时长拉长，影响了日常的迭代速度。该团队后采取了分布式测试的方式进行，平均的执行时长被优化到了半小时以内。
分布式测试的本质就是用执行资源的堆叠，去换取更快的执行速度。理论上我们把每一个测试用例拆分到一个容器内执行，可以获得极致的反馈速度。但是并不是所有场景下都适合采用分布式测试，例如用例之间存在依赖，这些用例不能无差别的分布在不同的执行分组。
精准测试
分布式测试很大程度上解决了测试执行的速度问题。但是如果在任何情况下都无差别的执行全量的用例，会存在一些问题：

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

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

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

如何建立测试基线

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

如何进行用例推荐在代码发生变更后，会基于代码变更解析出变化的测试用例与变化的业务方法。方法的变化通常是新增、删除、更新。
用例的代码变更情况比较简单，所有新增和更新的用例都会纳入到回归范围。
被测应用代码变更，要分情况考虑：

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

文章图片

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

文章图片

文章图片

提升测试有效性我们希望编写和运行的测试用例能够有效的覆盖代码的逻辑，其中重要的一个着手点是测试覆盖率，通过测试覆盖率来暴露问题，并促进问题的解决。
测试覆盖率
测试覆盖率，在本文中，指的是代码的覆盖率。即行覆盖率，分支覆盖率等。
此外，本文中所有涉及覆盖率采集的示例都以 Java 为例。
如何收集完整的覆盖率
一个应用下通常存在多种不同类型的自动化测试集

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

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

文章图片

为了能够收集所有类型的测试覆盖率，我们做了以下事情：
单元测试对于单元测试来说，覆盖率数据产生在单测执行的机器上，我们会根据执行机上的原始代码信息，编译后的 class 信息，单测执行后产生的覆盖率数据原始文件，以及变更的代码信息，计算出单元测试的覆盖率报告。

文章图片

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

文章图片

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

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

除了上述的“测试覆盖率”，还可以使用相同的技术来统计“线上业务对代码的覆盖情况”。也就是统计出来有哪些代码是被真正的线上业务所用到的，哪些是从来没有被调用到的。从而检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。
增量覆盖率
有了完整的测试覆盖率数据之后，就可以让它发挥作用了。但脱离了具体的场景，单独追求一个较高的测试覆盖率数值是没有意义的。如果一味的追求较高的覆盖率的数值，往往带来的的是用例的过度设计。如何健康有效的让项目的测试覆盖率稳步的提升，在阿里巴巴内部，我们更多的是采用关注增量覆盖率的方式来提升整体的测试覆盖率。
什么是增量覆盖率增量覆盖率是指，某一次测试过程中，变化的代码的测试覆盖情况。
变化的代码=被测分支的代码与目标对比分支的 diff（通常目标对比分支是我们最终会合入的分支）。
增量覆盖率=变化的被覆盖的代码行/变化的代码行。

文章图片

增量覆盖率的价值

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

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

文章图片

在阿里巴巴内部的实践中，我们通常会在 CICD 流水线中的关键阶段设置各类卡点，保障在多人协作的场景下，每个开发同学提交进入集成的代码经过充分的自测。在上线前的集成阶段，进入的代码在集成环境中被充分验证后，才会被允许发布上线。
通过增量覆盖率的反馈，开发/测试同学可以针对性的去补充各类测试用例，尽可能的保障在各阶段不存在测试遗漏。同时，在不断的完善测试集的情况下，项目的整体测试覆盖率也会得到健康有效的提升。
线上覆盖率覆盖率的采集我们通常不会应用到线上环境中，但是如果将覆盖率采集放到线上环境，又能演化出应用瘦身的场景，帮助我们从另外一个角度提升效率。
通常在线业务的服务都会部署多个副本，为了减少风险，我们会在其中的少量副本上进行覆盖率采集。经过一个较长的采集周期后，会生成线上覆盖率报告。在这个时候可以认为被覆盖到的代码都是有效代码，而剩下的那些长时间没有流量覆盖的代码，需要谨慎的考虑删除/重构。通过这样的方式去精简我们的代码，从而降低维护成本。
在阿里巴巴内部，当我们决定对某些维护困难或者腐化明显的应用进行重构时，都会进行一段时间的线上覆盖率采集，并根据报告去指导我们进行代码重构，代码瘦身。
小结分布式测试为测试速度插上了翅膀，精准测试有效的识别出了测试的范围，增量覆盖率又为测试的不断完备提供了有利的指引，线上覆盖率帮助我们有效的进行应用瘦身。充分利用好这些技术手段进行测试提效，可以让持续交付的过程更加的顺畅。
【关于云效】
云效，云原生时代一站式BizDevOps平台，支持公共云、专有云和混合云多种部署形态，通过云原生新技术和研发新模式，助力创新创业和数字化转型企业快速实现研发敏捷和组织敏捷，打造“双敏”组织，实现 10 倍效能提升。
立即体验
【阿里巴巴如何进行测试提效|阿里巴巴如何进行测试提效 | 阿里巴巴DevOps实践指南】