持续测试 | 让测试更自由：在 CODING 中实践自动化执行用例
本文做者：程胜聪 - CODING 产品经理
自动化测试是持续测试的基础
在 DevOps 的高频交付场景下，团队容易陷入在速度和质量之间“二选一”的困境：为了拥抱需求变动，采用较短的交付周期，而后变动频繁致使问题变多，因而开发提测延迟，最后致使测试时间被压缩、难以进行充分的测试。面对这样的状况，团队该如何提高测试的执行效率呢？你们第一个会想到的应该就是自动化测试——经过自动化测试来替代重复性的手工测试，执行更快从而节省测试时间。此外，因为自动化每次执行时间相对固定，并且程序预设的测试行为带来了高一致性，让测试的稳定性和可重复性达到很高的标准，可以很好的实现“快速重现软件缺陷”的目标。框架
若是说在测试时间相对充足的传统瀑布模式下，针对回归测试场景而投入的自动化测试所体现的最大价值是在节约人力成本方面，那么在敏捷和 DevOps 时代，自动化测试的更大价值则体如今频繁验证而且提供快速反馈方面。能够说持续测试实践的基础就是自动化测试，只有自动化程度足够高，才可以知足持续交付的高频发版需求。ide
自动化测试策略
自动化测试有很重要的价值，但不表示咱们应该无限制投入到各类类型的自动化测试当中。自动化测试是为了验证既定逻辑是否符合预期，在需求变动频繁的场景下，自动化代码的维护成本巨大。因此，咱们须要合适的策略来指引自动化的实现——金字塔模型。函数
出自《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 的承认，企业对自动化测试的投入在持续提高，带来的直接结果就是自动化测试的代码愈来愈多。可是有了数量快速增长的自动化代码，自动化就能达到咱们预期的效果吗？ui
从现实效果来看，企业并无因为自动化测试覆盖率的提高而得到预期中的价值，由于自动化代码的执行并无咱们想象中的那么“自由”，每每在于两方面的缘由：spa
- 通常团队会把自动化代码执行看成 CI 的一个环节，也只是被做为回归场景使用，可是全量回归的耗时过长限制了执行的频率不会过高；
- 搭建流水线和在这基础上搭配相应的工具仍是存在技术门槛，再加上这些操做自己须要的工做量，也致使了难以作到每一个人都能随时执行自动化测试。
这就致使随着自动化覆盖率的提高，回归测试的执行时间反而变得愈来愈长，因而自动化测试的执行频率只能下降，最后自动化代码的价值受到质疑。其实除了提高自动化覆盖率以外，咱们还须要改变“每次测试执行覆盖的用例越多越好”的理念：咱们不该该由于“不放心”而让测试集变得过度冗余，而是须要基于业务风险优化测试覆盖范围，以期在有限的范围内实现较高的测试投入产出比，实现精准测试。对象
CODING 让测试执行更加自由
为了让测试执行更加“自由”，CODING 打造了云端自动化执行的能力，指望解决自动化测试的“最后一千米”问题，从而实现：
- 每次执行都有灵活选择用例子集的自由；
- 全部人都拥有执行测试的自由。
接下来，让咱们看看如何在 CODING 测试管理实现“自由”地执行测试：
- 首先，在 CODING 自动化用例库中进行自动化代码登记，肯定自动化代码已经存在于代码托管中，对已经存在的自动化代码库进行登记，并设置相关的语言/框架。
- 解析自动化代码库的测试函数列表，并创建用例管理中的功能用例与自动化函数的匹配关系，得出自动化覆盖率。经过匹配自动化代码和功能用例，能够帮助咱们对自动化代码产生的价值创建直观感觉，作到“内心有数”。
- 建立执行方式为自动化执行的测试计划，圈选用例。
选取适合的自动化测试子集是须要业务测试知识的，而执行固定范围的全回归测试耗时过长，或者反复机械性执行冒烟测试并不能及时反映新需求的测试状况，这是自动化测试覆盖率的提高以后仍然未能达到预期中的价值的缘由。CODING 提供按需圈选测试子集的方式来建立测试计划，精准执行相关的自动化代码子集、快速反馈结果，从而解除了自动化运行时长的顾虑，让团队努力生产的自动化代码价值获得最大化。
- 执行该测试计划，已经匹配上的自动化用例在后台执行并更新对应功能用例的执行结果。自动化执行完毕后，能够对未测或者未经过的用例进行手工验证、并更新用例任务状态。
- 点击生成测试报告，系统将自动根据采集到的数据进行质量分析和评价。测试可追溯让测试报告更使人信服，帮助团队将风险控制到较低水平。