持续测试的益处

自从 2006 年 Unruly 公司成立以来，其团队就开始采用极限敏捷（XP）实践并沿用至今。Unruly 的软件开发项目是由多个小型团队完成的，没有设立专职的测试人员。这些团队在开发代码时遵从测试优先原则，并且投入了大量的精力以实现能够在真实环境运行的自动化检测，而不依赖于在预发布环境中进行手工测试。

Rachel Davies 是 Unruly 的敏捷教练，她在敏捷测试日2015 年荷兰大会上进行了关于持续测试的主题演讲。InfoQ 有幸对Davies 进行了采访，内容涉及以持续化方式进行测试的重要性、这种方式是如何演变的，以及它为Unruly 所带来的商业优势。

InfoQ：能否请你解释一下，为什么自动化测试对你的团队如此重要？

Davies：它的重要性是因为自动化测试比起手工检测软件速度更快、也更加可靠。手工测试是一件很烦人的工作。我们希望做到，在销售人员提出某些产品变更需求的当天就能够立即部署。为了实现这一点，我们对部署脚本进行了自动化，并且通过脚本运行自动测试。机器比人类运行重复性步骤要快得多，因此自动化能够帮助我们更快地交付有价值的解决方案。

InfoQ：你能否为我们举一些例子，让我们了解自动化测试是如何帮助 Unruly的团队交付商业价值的？

Davies：销售人员可以对运行中的系统提出某种变更的需求，而我们能够在几个小时、而不是几天内让这个变更生效。我们有一个与众不同的地方，就是我们没有搭建任何临时的预发布环境，强制代码必须在这些环境上进行检验。我们的做法是直接将变更发布到生产环境中，因为这样可以更快地交付价值。虽然新的代码直接部署了到新的生产环境中，但我们可以通过某些手段让在线系统的用户不会直接看到这些变更。我们的做法是使用多个可部署的小步骤，通过自动化测试检测行为是否符合我们的需求。如果在测试中出现了速度缓慢或是经常出错的情况，那么在团队的回顾会议中会进行讨论。

InfoQ：经过这么多年对持续测试的投入，你觉得为什么值得这样做，持续测试能够为你带来什么益处？

Davies：通过采取测试优先的开发方式，我们实现了良好的代码覆盖率，以帮助我们检测产品的特性是否按期望的方式工作。如果有任何变更破坏了现有的自动化测试，我们能够迅速地发现问题。通过对在线服务进行自动化监控，也能够帮助我们指出是否出现了哪种我们没有预料到的情况。以测试驱动我们的产品开发，这种方式也帮助我们团队专注于所需交付的价值，并不断发展前进。

InfoQ：在敏捷测试日荷兰大会上，你谈到了在生产环境中运行某些持续性的检测以进行持续测试。你能否描述一下这种方式是如何实现的？

Davies：我们配置了 Nagios 警报系统，它会根据在线服务的不同情况对团队发出通知。如果出现问题，我们将通过短信方式获得通知。我们也在开发团队的区域摆放了几台大屏幕，以显示我们的在线系统的软件负载及性能。也许你会有兴趣读一下我们的开发者所写的一个博客，其中提到了监控检测中的坏味道。

InfoQ：你能否详细阐述一下自动化测试这几年间在 Unruly是如何演变的吗？

Davies：公司是于 2006 年成立的，我们当时就采用了 XP 实践当中的 TDD，因此从一开始测试就是自动化的。经过几年的发展，我们必须将这些测试扩展到浏览器与设备测试上（因为浏览器和移动平台的新功能也在不断涌现）。产品的功能也扩展了，并且在技术上产生了很大的转变，转为能够适应桌面电脑、平板和移动设备的“响应式”网站。而在 2006 时平板电脑并非我们所考虑支持的设备。

我们并没有采用让非技术人员也能够阅读的 BDD 风格的测试，这是因为我们早先在使用 FiTnesse 进行自动化验收测试时的体验很糟糕。我们的开发者直接与项目干系人进行对话，而不是业务分析师。所有的测试都是由开发者使用与应用代码相同的编程语言进行编写和维护的，因此使用示例型 BDD 的风格对于我们来说没有多少益处。

InfoQ：你在演讲中提到在测试中使用了 chaos monkeys技术，你是否详细说明一下？

Davies：这一点是受到 Netflix 的基础设施 chaos monkeys 的启发，因此我们也开发了特定于我们领域的“monkeys”，在生产环境中的应用级别注入一些潜在的错误，例如在对于延迟非常敏感的应用中产生服务无响应的错误。这种方式能够帮助我们找到并修复那些在测试环境中不会出现的问题。我们的一位开发者 Alex Wilson 在一篇博客帖子中就提到了如何在生产环境中注入应用级的错误。

InfoQ：有没有什么新的测试技术是看起来很有前途的，并且你们团队也打算尝试的？

Davies：我们或许能够在手工探索性测试方面投入更多时间。对于这种测试，经典的定义是“同时进行测试设计与测试执行，同时进一步学习系统”，这一定义来自于由 Cem Kaner、James Bach 与 Bret Pettichord 在 2002 年共同出版的名作《软件测试经验与教训》（Lessons Learned in Software Testing）。这种方式与自动化检测不同，而是积极地探索系统的各种行为，在不使用脚本的情况下学习系统会表现出哪些未预料的行为。

InfoQ：如果有其它组织打算实施持续测试，你能否为他们提供些建议？

Davies：首先将所有的回归测试都实现自动化，并且不要将注意力分散到 BDD 上。从基础的健康状况检测开始自动化，例如冒烟测试，并逐渐改善测试覆盖率。从最重要的业务逻辑，或是最容易出错的地方开始。

查看英文原文： Benefits of Continuous Testing