这是鼎叔的第五十七篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

标题中的持续自动化不只指测试，也包含构建，部署，发布等任务。敏捷团队要确保每次迭代完成时都有可工作的软件，随时可以发布最新产品，这个目标的达成有赖于自动化。这篇文章详细聊聊实施持续自动化有哪些价值，以及面临的各种阻碍。

PART 1 持续自动化的价值

为什么需要自动化？大家很容易想出一系列的理由。这里将列举一些持续自动化实践中容易被忽视的思考。

一 缩短手工测试的耗时

当被测系统（SUT）越来越复杂，软件规模越来越大，手工测试全部功能的耗时会越来越长，甚至会指数级增长。

对于每日持续回归的测试策略，手工测试是不可能完成的任务。

但如果没有一套完整的回归自动化拦截网，测试人员需要分心在基础质量保障上，这些基础测试也需要花费大量时间，带来日益增长的挫折感和枯燥感。不断增加的技术债务也可能导致测试人力成本的增加。

没有频繁的测试检测，代码设计也可能越来越不利于可测性。

相信大家清楚，为各种复杂的用户场景手工创建测试数据，是一个让人筋疲力尽的投入。这种情况会最终导致测试人员的精力只能覆盖有限的几种用户场景，可能让某些重要的缺陷被漏测。

手工测试对于人的耐心细致是一个巨大的挑战，人在重复中容易遗漏，犯错。在截止日期的巨大压力下会走捷径，更不用说没有精力挖掘表象以外的缺陷了。

持续的自动化测试，保障了每次运行的一致性，降低了人为的回归错误。人就可以专注在观察产品究竟发生了什么。

二 自动化让人有精力做更有价值的事

自动化测试能对抗人的惰性，当单元测试和功能回归测试被持续构建运行，意味着测试人员可以有更多时间进行有趣的探索，研究系统内在的薄弱环节。

自动化不一定会挖掘出多少新问题，但一旦出现失败结果，能让测试人员快速锁定人工测试不太可能逮住的问题。这种愉悦感受是一种意外的欣喜。

三 增加开发和测试的信心

在信心的加持下，以往的测试人力投入策略被优化，人工检查的任务量大幅下降。

对于缺陷修补反思，以及新特性的用例补充，也增强了对设计质量和可测性的思考。开发人员养成了好习惯，修改代码前仔细思考要改变的行为，主动编写测试来验证它。最终培养了更优秀的编码人员和测试人员。

正确的自动化安全网，对于大规模敏捷团队的满意度至关重要。如果没有这个安全网，测试人员就会被当成兜底的安全网，压力被转移到测试人员头上。

自动化安全网对失败的快速反馈，让开发人员在记忆犹新的情况下极低成本解决问题。

四 自动化回归集就是最强大的文档

拥有一个匹配的自动化框架以及完整更新的回归套件，就能指导团队更好的捕获需求，并养成在迭代中关心测试方式改良的集体习惯，进而让需求可测性不再成为难题。

自动化测试库和代码库一起发展，团队也不用产生太多技术债。

更惊喜的是，测试实例就是讲述系统如何工作的 “活文档”。因为它可清晰执行，出了问题不会带来过多的争吵，这比不常更新的静态需求文档要强大很多。

PART2 自动化实践的阻碍因素

一 开发人员的态度

很多传统公司，开发和测试不在一起工作，开发看不到测试的具体工作，也不关心。瀑布型研发模式，导致测试环节距离开发的工作更远，等到测试人员热火朝天的时候，开发可能进行下一个版本开发中了。即使是能熟练掌握单元测试的开发，也可能不会思考单元级别以外的验收质量。

如何改变开发人员对自动化测试的态度呢？

让他们动手测试是唯一方法。但是教练角色是需要的。开发团队，尤其是主管，要承诺测试目标，哪怕目标定低一点，愿意投入培训，并给予一线员工足够的鼓励。

二 降低测试自动化的学习曲线。

注意从设计很差的遗留代码上开始工作，难度会非常高，可以先从增量代码开始实践，找一个架构设计良好的模块来学习。当团队熟练掌握了一个测试框架，再进行旧代码的全面测试。

在初期，团队要评估合适的测试套件，得到实际的覆盖率。

对录制回放型工具要谨慎使用，UI 级脚本不止有变化失效问题，还有知识难以传承导致的维护性问题。

敏捷项目中，虽然代码总是频繁变更，但是编写代码的目的很少改变，因此，按照应用的功能目的去组织测试脚本，就更容易跟上开发的节奏，而不是按测试代码的实现方式去组织。

度量开发进行自动化测试的收益，不要只看初期成本，还要看机会成本，即快速修复和项目后期修复的成本差距。

三 编程能力不足的恐慌

自动化测试是整个团队的事，团队中总有能够且愿意提供帮助的技术高手，即使是编程能力不高的同学也能做出贡献。

四 旧习惯

让没有持续自动化的团队开始实践，最常见理由就是：业务发布太紧了，新特性太重要了，没有时间实践自动化测试。还是用手工测试尽量完成所有事情吧，这样安全。

故步自封的态度，只会拖延技术债务，让形势逐步恶化。手工测试完成的内容也不能保障都是重要的，依然可能遗留导致重大经济事故的缺陷。

鼎叔能看到，当业务繁忙项目开始实践持续自动化后，测试人员的日常工作模式发生了变化，从被业务需求叠加的压力中，抽出更多心思放在补充稳定的拦截场景，而不是为各种可能的漏测事故进行焦虑式沟通。

我们理解基于团队的历史文化，工程师很难让业务测试自动化的优先级，高于新特性编码的任务，但是敏捷方法实践可以逐步克服这个障碍。未来公众号会给出更详细的分享专题。