向右移动 - 生产环境中的测试
如果你开始使用自动化测试，你会很快看到质量的提高和工程师调试工作量的减少。但在某个时刻，你必须大幅增加测试的投入，才能显著改善质量。另一方面，测试的执行时间会拖慢你的发布管道，尤其是当你将性能测试和负载测试加到测试中时（见图 12.7）：
如果你的管道运行时间超过 24 小时，那就不可能每天发布多次了！管道执行时间的增加也会减少你快速向前推进和在生产环境中修复 Bug 的能力。
解决方案很简单：将部分测试“移右”到生产环境中。所有在生产环境中运行的测试不会影响你快速发布的能力，而且你不需要性能测试或负载测试，因为你的代码已经在生产负载下运行了。
然而，进行生产环境测试有一些前提条件，这些前提条件可以提高用户的性能质量，而不是降低它。接下来我们来看一下这些前提条件。
健康数据和监控
在生产环境中进行测试时，你必须时刻关注应用程序的健康状况。这不仅仅是正常的日志记录。你需要深入了解应用程序的运行状态。一种好的实践是编写测试代码，调用所有相关的系统——例如数据库、Redis 缓存或依赖的 REST 服务，并将这些测试结果提供给你的日志解决方案。这样，你可以持续获取心跳信号，表明所有系统都正常运行并相互协作。如果测试失败，可以立即触发警报，通知团队出现问题。你还可以自动化这些警报，让它们触发某些功能，例如启动断路器。
|
断路器
断路器是一种模式，防止应用程序反复尝试执行可能失败的操作，从而允许应用程序在不中断的情况下继续运行，改变其功能，而不必等待失败的操作成功（见 Michael Nygard, 2018）。 |
功能标志和金丝雀发布
你不希望在生产环境中进行测试并导致所有客户都出现服务中断。因此，你需要使用功能标志、金丝雀发布、基于环的部署，或者这些技术的组合（见第 9 章和第 10 章）。逐步曝光更改非常重要，这样如果出现故障，你不会导致整个生产环境宕机。
业务连续性和灾难恢复
另一种生产环境测试是业务连续性和灾难恢复（BCDR）或故障转移测试。每个服务或子系统都应该有一个 BCDR，并且你应该定期执行 BCDR 演练。没有什么比灾难恢复系统无法正常工作更糟糕的了，尤其是当你的系统停机时。只有通过定期测试，才能确保其在需要时能够正常工作。
探索性测试和可用性测试
自动化测试并不意味着你应该完全放弃手动测试。但手动测试的重点应从验证功能和在每次发布时手动执行回归测试转向可用性、快速且高质量的反馈，以及那些难以通过结构化测试方法发现的缺陷。
探索性测试由 Cem Kaner 于 1999 年提出（Kaner C., Falk J., H. Q. Nguyen, 1999）。它是一种同时关注发现、学习、测试设计和执行的测试方法。它依赖于个体测试人员发现那些无法通过其他测试方法轻易发现的缺陷。
有许多工具可以帮助进行探索性测试。这些工具可以帮助你记录会话、拍摄带注释的屏幕截图，并且通常允许你从你执行的步骤中创建测试用例。一些扩展可以与 Jira 集成，如 Zephyr 和 Capture，还有一些浏览器扩展，如 Azure Test Plans 的 Test and Feedback 客户端。如果你在独立模式下使用，它是免费的。这些工具提供了来自利益相关者的高质量反馈给开发人员——不仅仅是发现的缺陷。
收集反馈的其他方式包括使用可用性测试技巧——例如走廊测试或游击式可用性测试——通过对新用户进行测试来评估你的解决方案。A/B 测试是一种特殊的可用性测试形式，我们将在第 19 章《使用 GitHub 进行实验和 A/B 测试》中详细介绍。
这里重要的一点是，所有这些测试都可以在生产环境中执行。你不应该在 CI/CD 管道中执行任何手动测试。快速发布，并通过功能标志和金丝雀发布允许在生产环境中进行手动测试。