Testing 当持续测试生产环境时是有意义的

假设我有一系列单元测试、集成测试和e2e测试，这些测试涵盖了我的应用程序。让这些设备连续运行（例如每10分钟一次）是否有意义

我在想不，原因如下： 我的测试已经在每次产品部署后运行。如果他们通过了测试，但之后没有代码更改，那么他们应该继续通过测试。因此，在此后对它们进行测试是没有意义的

我真正想持续测试的是我的基础设施——它还在运行吗？在这种情况下，每10分钟运行一次API集成测试以检查我的API是否仍在工作是有意义的。因此，我正在处理我的测试套件的一个子集——测试我的基础设施可用性（集成+e2e）的套件，而不是只测试单个代码位（单元测试）。因此，在实践中，我会将测试产品运行时间的测试套件与用于测试部署前/部署后的套件分开吗？

这种“冗余”验证（顺便说一句，它们也可以包括构建，而不仅仅是测试）提供额外的数据点，从而提高实际生产过程的监控精度

根据生产环境的复杂性，即使是简单的问题“是否已启动/正在运行？”也可能没有简单的答案，验证的子集/快捷方式版本可能无法解决这一问题-您只能涵盖这些版本，而不是实际的生产版本

例如，构建服务器启动并不意味着它也能够成功构建产品，您需要检查构建本身的每个方面：每个工具、存储、依赖项、操作系统资源的可用性，等等。对于复杂的构建，只执行构建本身可能比可靠地管理代码更简单（检查构建是否可行；）

有两个生产过程属性将受益于更精确的监控（子集/快捷方式验证也不适用于这两个属性）：

• 可靠性/稳定性-间歇性故障的类型、发生率和根本原因（是的，可能影响是否满足发布日期的严重意外事件）
• 性能各种验证的平均/最小/最大持续时间；特别重要的是，如果验证在所涉及的时间/资源方面很昂贵；对于计划、预算、生产ETA等，可能需要趋势分析

---

Donno，如果其中任何一项适用于您的环境或具有可接受的成本/效益比，那么它们对于大多数非常大型/复杂的软件项目来说无疑是重要的。

我想说的是，代码更改后的测试与监控基础设施完全不同。即使你的代码在几周内没有变化，你也应该在短时间内监控你的基础设施的正常运行时间。我已经设置了类似的设置。对于监控来说，快速且有用的测试被标记为“BVT”-构建验证测试。在部署期间首先运行BVT（如果有问题，则更快地进行反馈循环），然后运行其余的测试。BVT也可以定期进行，以监视应用程序。