总结

在本章中，您学习了如何通过将测试向左移动（通过自动化测试）以及将测试向右移动（通过生产环境测试和混沌工程）来加速软件交付。通过这种方式，您可以在不妥协质量的情况下快速发布。最后，您还学习了如何管理您的测试组合，消除不稳定的测试，并通过注入故障和混沌来增强应用程序的韧性。

在下一章中，您将学习如何将安全性向左移动，并在开发过程中实施 DevSecOps 实践。

案例研究

Tailwind Gears的两个试点团队通过实施DevOps实践，显著提高了交付周期时间和部署频率。恢复时间（MTTR）也得到了显著改善，因为发布管道帮助更快地发布修复。然而，变更失败率下降，频繁发布也意味着更多的部署失败，并且找出代码中的bug变得更加困难。自动化测试套件提供的质量信号并不够可靠，而且修复一个bug往往会引入另一个模块的bug。仍有许多部分的应用程序需要手动测试，但团队中只有一个QA工程师，这使得手动测试成为不可能。因此，部分测试已被UI测试取代，而其他一些则被直接删除。

为了评估测试组合，团队必须引入测试分类法，并将报告纳入其管道中。团队中的QA工程师负责分类法，报告显示，功能性和UI测试的数量过多，而单元测试的数量不足。许多工程师仍然不相信TDD可以节省他们的时间，尤其是在嵌入式软件开发中，他们认为某些情况下无法采用TDD开发。于是，团队决定一起安排TDD培训课程，学习和实践TDD。

培训后，所有新的代码都采用TDD编写，新的代码至少达到90%的代码覆盖率。团队还将每个冲刺的30%时间用于消除不稳定的测试，并将测试重写到更低的层次。

为了发现不稳定的测试，团队在包含绿色测试的管道中运行可靠性测试。不稳定的测试被优先处理。之后，团队会选择执行时间最长的测试，并决定对每个测试采取何种处理方式。大多数测试会转换为单元测试，部分会转换为集成测试。一些测试会被删除，因为它们没有带来额外的价值。

结构化的手动测试被完全替换为探索性测试。如果在这些会话中发现任何问题，则在修复之前会创建单元测试。

负责运行Web应用程序的团队还引入了一种新的测试类别，即在生产环境中执行的测试。他们实施了应用性能监控，并收集了大量的指标，以便他们能够了解应用程序在所有环境中的健康状况。他们还开始每个冲刺执行一次BCDR演练，开始进行生产环境测试和混沌工程。

进一步阅读

本章中使用了以下参考文献，帮助您更深入地了解所讨论的主题：