本文作者：程胜聪 – 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 的认可，企业对自动化测试的投入在继续晋升，带来的间接后果就是自动化测试的代码越来越多。然而有了数量疾速减少的自动化代码，自动化就能达到咱们预期的成果吗？
从事实成果来看，企业并没有因为自动化测试覆盖率的晋升而取得预期中的价值，因为自动化代码的执行并没有咱们设想中的那么“自在”，往往在于两方面的起因：
- 个别团队会把自动化代码执行当作 CI 的一个环节，也只是被作为回归场景应用，然而全量回归的耗时过长限度了执行的频率不会太高；
- 搭建流水线和在这根底上搭配相应的工具还是存在技术门槛，再加上这些操作自身须要的工作量，也导致了难以做到每个人都能随时执行自动化测试。
这就导致随着自动化覆盖率的晋升，回归测试的执行工夫反而变得越来越长，于是自动化测试的执行频率只能升高，最初自动化代码的价值受到质疑。其实除了晋升自动化覆盖率之外，咱们还须要扭转“每次测试执行笼罩的用例越多越好”的理念：咱们不应该因为“不释怀”而让测试集变得过分冗余，而是须要 基于业务危险优化测试覆盖范围，以期在无限的范畴内实现较高的测试投入产出比，实现精准测试。
CODING 让测试执行更加自在
为了让测试执行更加“自在”，CODING 打造了云端自动化执行的能力，冀望解决自动化测试的“最初一公里”问题，从而实现：
- 每次执行都有灵便抉择用例子集的自在；
- 所有人都领有执行测试的自在。
接下来，让咱们看看 如何在 CODING 测试治理实现“自在”地执行测试：
- 首先，在 CODING 自动化用例库中进行自动化代码注销，确定自动化代码曾经存在于代码托管中，对曾经存在的自动化代码库进行注销，并设置相干的语言 / 框架。
- 解析自动化代码库的测试函数列表，并建设用例治理中的性能用例与自动化函数的匹配关系，得出自动化覆盖率。通过匹配自动化代码和性能用例，能够帮忙咱们对自动化代码产生的价值建设直观感触，做到“心里有数”。
- 创立执行形式为自动化执行的测试计划，圈选用例。
选取适宜的自动化测试子集是须要业务测试常识的，而执行固定范畴的全回归测试耗时过长，或者重复机械性执行冒烟测试并不能及时反映新需要的测试状况，这是自动化测试覆盖率的晋升之后依然未能达到预期中的价值的起因。CODING 提供按需圈选测试子集的形式来创立测试计划，精准执行相干的自动化代码子集、疾速反馈后果，从而解除了自动化运行时长的顾虑，让团队致力生产的自动化代码价值失去最大化。
- 执行该测试计划，曾经匹配上的自动化用例在后盾执行并更新对应性能用例的执行后果。自动化执行结束后，能够对未测或者未通过的用例进行手工验证、并更新用例工作状态。
- 点击生成测试报告，零碎将主动依据采集到的数据进行品质剖析和评估。测试可追溯让测试报告更令人信服，帮忙团队将危险管制到较低水平。