测试策略与系统信心
不同的测试回答不同的问题。分类测试时，应依据其覆盖的边界和提供的证据，而不是仅仅看文件名。
黑盒测试通过公开接口验证输入输出行为；白盒测试则利用内部实现细节，针对特定分支或状态进行验证。健康的测试体系应两者兼备，同时确保重构代码时不必重写所有测试。
基于风险选择用例
在系统实际面临风险的地方，测试常规行为、边界值、非法输入、部分失败、重试机制、并发场景及恢复能力。回归测试用于固化之前遗漏的行为；冒烟测试（Smoke Test）仅在构建或部署后验证关键路径，它不能替代完整测试套件。
当不变量（Invariants）比手工构造的样例更容易描述时，属性测试（Property-based testing）和模糊测试（Fuzzing）能探索更广阔的输入空间。它们是对重要领域场景可读性示例的补充，而非替代。
CI 作为可复现性检查
持续集成（CI）应从声明式环境启动，安装锁定或受限版本的依赖，并运行确定性的必选检查。将快速反馈信号前置，将昂贵或依赖特定环境的测试套件隔离，并明确其责任人。
必选测试失败必须阻断变更，或通过明确的例外流程处理。切勿将“重跑直到变绿”常态化。Flaky Test（不稳定测试）意味着测试、产品或环境中存在非确定性因素；应记录该问题、指派负责人，并在保留可见性的前提下限期修复或隔离。
证据，而非分数
行覆盖率和分支覆盖率只能揭示未执行的代码，无法衡量断言质量、数据真实性或需求遗漏。变异测试（Mutation Testing）能发现那些“执行了代码但未检测到变化”的无效断言，但会增加计算成本。
生产环境的可观测性、灰度发布、回滚能力及事故复盘，覆盖了测试环境无法完全复现的条件。系统可靠性源于完整的反馈闭环，而非单一的测试金字塔或某个覆盖率百分比。