持续测试 | 让测试更自由：在 CODING 中实践自动化执行用例

Posted 2021-06-02 DevOps 实践指南

本文作者：程胜聪 - CODING 产品经理

自动化测试是持续测试的基础

在 DevOps 的高频交付场景下，团队容易陷入在速度和质量之间“二选一”的困境：为了拥抱需求变更，采用较短的交付周期，然后变更频繁导致问题变多，于是开发提测延迟，最后导致测试时间被压缩、难以进行充分的测试。面对这样的情况，团队该如何提升测试的执行效率呢？大家第一个会想到的应该就是自动化测试——通过自动化测试来替代重复性的手工测试，执行更快从而节省测试时间。此外，由于自动化每次执行时间相对固定，而且程序预设的测试行为带来了高一致性，让测试的稳定性和可重复性达到很高的标准，能够很好的实现“快速重现软件缺陷”的目标。

如果说在测试时间相对充足的传统瀑布模式下，针对回归测试场景而投入的自动化测试所体现的最大价值是在节约人力成本方面，那么在敏捷和 DevOps 时代，自动化测试的更大价值则体现在频繁验证并且提供快速反馈方面。可以说持续测试实践的基础就是自动化测试，只有自动化程度足够高，才能够满足持续交付的高频发版需求。

自动化测试策略

自动化测试有很重要的价值，但不表示我们应该无限制投入到各种类型的自动化测试当中。自动化测试是为了验证既定逻辑是否符合预期，在需求变更频繁的场景下，自动化代码的维护成本巨大。所以，我们需要合适的策略来指引自动化的实现——金字塔模型。

出自《The Test Automation Pyramid: Your essential guide for test automation》

自动化测试金字塔最早由 Mike Cohn 于 2009 年在《Succeeding with Agile: Software Development using Scrum》中提出，当时从上到下的三层分别是 UI、Service 和 Unit。之后随着敏捷测试实践的落地，业内逐渐形成的认知是从上到下分别为用户界面测试（UI Tests）、接口集成测试（API Tests）、单元测试（Unit Tests），再加上顶部的手动探索性测试，进一步丰富为测试金字塔（包括自动化和手工）。这个上窄下宽的三角形为我们在各层的自动化投入提供了形象的指引：底层的单元测试最多，接口测试居中，UI 测试最少。

如金字塔模型所示，下层的单元测试/接口测试比起上层的 UI 测试优点有：由于更接近生产代码所以更容易编写并定位到代码的缺陷；由于测试对象的粒度更小、依赖更少，所以执行效率更高；由于测试对象更加稳定所以维护的成本更低等等，当然越接近上层的测试的优点就在于，因为更加反映业务需求，所以更容易让人看到测试的价值。那么在 DevOps 时代，基于对速度和质量的平衡，中间层的接口集成测试因为既能保持相对低的维护成本，又能兼具反映业务逻辑的价值，应该成为我们重点投入的部分，尤其是在自动化各方面还处于初级阶段的时候。

测试金字塔发源于敏捷实践，以之作为参考对我们的自动化测试投入进行持续的调整，团队的测试用例和执行状况就会逐步形成良好的平衡。

精准测试的价值

虽然从近几年行业的调查报告可以看出，随着对 DevOps 的认可，企业对自动化测试的投入在持续提升，带来的直接结果就是自动化测试的代码越来越多。但是有了数量快速增加的自动化代码，自动化就能达到我们预期的效果吗？

从现实效果来看，企业并没有由于自动化测试覆盖率的提升而获得预期中的价值，因为自动化代码的执行并没有我们想象中的那么“自由”，往往在于两方面的原因：

1. 一般团队会把自动化代码执行当作 CI 的一个环节，也只是被作为回归场景使用，但是全量回归的耗时过长限制了执行的频率不会太高；
2. 搭建流水线和在这基础上搭配相应的工具还是存在技术门槛，再加上这些操作本身需要的工作量，也导致了难以做到每个人都能随时执行自动化测试。

这就导致随着自动化覆盖率的提升，回归测试的执行时间反而变得越来越长，于是自动化测试的执行频率只能降低，最后自动化代码的价值受到质疑。其实除了提升自动化覆盖率之外，我们还需要改变“每次测试执行覆盖的用例越多越好”的理念：我们不应该因为“不放心”而让测试集变得过分冗余，而是需要基于业务风险优化测试覆盖范围，以期在有限的范围内实现较高的测试投入产出比，实现精准测试。

CODING 让测试执行更加自由

为了让测试执行更加“自由”，CODING 打造了云端自动化执行的能力，期望解决自动化测试的“最后一公里”问题，从而实现：

1. 每次执行都有灵活选择用例子集的自由；
2. 所有人都拥有执行测试的自由。

接下来，让我们看看如何在 CODING 测试管理实现“自由”地执行测试：

1. 首先，在 CODING 自动化用例库中进行自动化代码登记，确定自动化代码已经存在于代码托管中，对已经存在的自动化代码库进行登记，并设置相关的语言/框架。

2. 解析自动化代码库的测试函数列表，并建立用例管理中的功能用例与自动化函数的匹配关系，得出自动化覆盖率。通过匹配自动化代码和功能用例，可以帮助我们对自动化代码产生的价值建立直观感受，做到“心里有数”。

3. 创建执行方式为自动化执行的测试计划，圈选用例。

   选取适合的自动化测试子集是需要业务测试知识的，而执行固定范围的全回归测试耗时过长，或者反复机械性执行冒烟测试并不能及时反映新需求的测试情况，这是自动化测试覆盖率的提升之后仍然未能达到预期中的价值的原因。CODING 提供按需圈选测试子集的方式来创建测试计划，精准执行相关的自动化代码子集、快速反馈结果，从而解除了自动化运行时长的顾虑，让团队努力生产的自动化代码价值得到最大化。

4. 执行该测试计划，已经匹配上的自动化用例在后台执行并更新对应功能用例的执行结果。自动化执行完毕后，可以对未测或者未通过的用例进行手工验证、并更新用例任务状态。

5. 点击生成测试报告，系统将自动根据采集到的数据进行质量分析和评价。测试可追溯让测试报告更令人信服，帮助团队将风险控制到较低水平。