赶在客户之前发现缺陷。

从业务风险到有据可依的测试覆盖

如果缺少关键的业务场景，大量通过的测试本身说明不了太多问题。我们会将需求、风险和测试项一一对应起来。以某个审批流程为例，这就包括未经授权的角色切换、并行处理和期限已过等情况。边界值分析和多种输入组合，是对常规成功场景的补充。预期结果会从业务角度加以论证，而不是仅仅固化当前程序的行为。

针对每一条重要规则，我们都会选择合适的测试层级。小型的独立测试可以快速验证计算逻辑；集成测试用于检验与数据库或服务的协同；少量有针对性的端到端测试，则用于保障完整流程。测试替身可以简化测试，但也可能无法如实反映真实对接方的行为。因此，我们会记录哪些假设还需要在真实测试系统中另行验证。

测试数据、不稳定测试与结果可信的流水线

测试必须能够控制自身的初始状态。共用账户、固定的日历日期以及相互依赖的测试运行，都会产生在下一次尝试时又消失的错误。我们会规划可恢复的数据集、相互独立的测试身份，以及对时间的受控处理。合成数据可以有针对性地覆盖典型场景，但其数据分布和关联关系，仍必须符合预期的使用场景。

不稳定的测试会被深入分析，而不是通过无限次重试来长期掩盖问题。被临时排除的测试需要有责任人、理由说明和恢复计划。测试报告会区分产品缺陷和测试环境本身的问题。为了尽快获得反馈，合适的检查会在流水线的早期阶段运行，而耗时较长的负载测试或兼容性测试则安排在既定的时间点进行。这样一来，发布决策就变得清晰易懂，而不只是取决于信号灯的颜色。

故障条件下的负载、恢复与发布

负载测试从一个使用模型开始：会发生哪些业务操作，频率如何，数据量有多大，同时有多少用户在使用？平均值可能会掩盖响应缓慢的异常情况。因此，我们会将响应时间的分布情况与错误率、资源利用率结合起来一并考察。负载峰值、长时间持续运行和缓慢的依赖项，回答的是不同的问题，不会被混合成单一指标。

此外，我们还会在受控环境中测试约定的故障场景，例如某个服务无法访问，或者某个后台任务被中断。关键在于数据是否保持一致、用户是否能收到易于理解的反馈，以及运维团队是否能够察觉到这次故障。发布报告会说明测试状态、环境、数据基础、结果和尚未解决的风险，从而清楚显示哪些结论是可靠的，哪些方面超出了本次检测的范围。