编者按：本文源自阿里云云效团队出品的《阿里巴巴 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 倍效力晋升。
立刻体验