“测试做完了吗？”这个问题常被压缩成几个数字：用例执行率、需求覆盖率、未关闭缺陷数。数字能说明计划执行到了哪一步，却不能单独回答另一个更重要的问题：我们掌握的质量证据，足以支持发布决定吗？
Stephen P.（The Stoic Tester）在 2026 年 10 月 19 日发表于 LinkedIn 的文章《How Much Testing Is Enough? The Stoic Case for Knowing When to Stop》，围绕风险、证据和判断展开。以下先整理原文观点，再把停止条件、统计示例和团队落地流程作为实践延伸说明。
“测试完成”不等于“质量足够”
测试做到什么程度才算完成，行业里没有一个适用于所有项目的答案。常见标准包括执行完 100% 的计划用例、覆盖所有需求、修完已知缺陷，或者一直测到交付期限。每一种说法都能描述一部分工作，却不能独立证明系统已经达到可接受的质量水平。
实际项目里常见两种相反的情况：交付日期临近，测试时间被挤压；或者回归包逐年变大，跑完一轮本身就像一个项目。原文认为，两者都未必代表好的测试。前者可能把重要验证压掉，后者则可能让团队把时间花在重复、低价值的检查上。
节制是判断，不是削减
作者借用了斯多葛哲学的“节制”（Temperance）。节制与智慧、勇气、正义并列，是斯多葛哲学的四大美德之一。放到软件测试里，它指的是有纪律地按比例分配精力，依据风险和证据作判断，而不是因为惯例、恐惧或外部压力机械地增加或减少测试。
作者引用马可·奥勒留《沉思录》中的一句话：“Do few things, if thou wouldst have tranquillity.”他把它理解为专注必要之事，而非把测试削到最少。
执行 5,000 条用例，不一定比执行 500 条甚至 1 条更能保障质量。关键要看测了什么、针对哪些风险，以及结果让团队学到了什么。反过来，用例少也不自动代表高效——如果支付、权限或数据完整性等高影响风险没有证据，测试再快也不能替代缺失的保障。
**实践延伸：**测试效率和保障有效性是两回事。效率关注执行时间与维护成本；保障有效性关注测试能否发现重要问题、减少关键不确定性，并帮助团队作出更好的决定。
覆盖率说明看过哪里，不说明看得够不够
仪表盘显示 100% 执行、全部通过，只能说明团队执行完了计划中的测试。若测试计划漏掉重要集成、误解需求，或没有考虑高影响场景，全部通过也不能证明系统安全或质量良好。正如作者所说：
Coverage tells us where we’ve looked.
谈覆盖率之前，团队需要先说清楚统计的对象：
| 覆盖类型 | 能说明什么 | 单靠它不能证明什么 |
|---|---|---|
| 需求覆盖 | 哪些需求关联了测试 | 需求是否理解正确、验证是否足够深入 |
| 代码覆盖 | 哪些代码在运行时被执行 | 断言是否有效、业务结果是否正确 |
| 业务流程覆盖 | 哪些用户或业务路径被检查 | 异常路径和高影响变体是否覆盖充分 |
| 风险覆盖 | 哪些已识别风险有对应验证 | 是否还存在未识别的风险 |
例如，支付流程覆盖了成功、失败和退款，并不自动代表并发请求、重复扣款、网络超时、事务回滚和幂等性都经过验证。覆盖率是有用的信号，但必须结合覆盖对象、验证深度和风险来解读。
回归测试既要有准入，也要有退役
每次发现缺陷就添一条用例，每次发布新功能就扩充回归包，过时或重复的检查却很少被移除，测试套件便会持续膨胀。执行成本上升后，团队可能赶不完、开始走捷径，业务方也更容易把测试视为交付瓶颈。
低价值用例可能重复验证相同场景，反复检查多年未变的低风险行为，却挤占了复杂新集成的验证时间。不过，“这个功能一直很稳定”本身不是删除用例的充分理由；某些关键检查无论过去通过多少次，都需要保留。
**实践延伸：**可以给回归测试明确的生命周期，而不是只规定新增规则：
| 用例类型 | 建议处理方式 |
|---|---|
| 关键业务与高风险检查 | 长期保留，优先执行，并定期确认仍然有效 |
| 与近期变更相关的检查 | 按变更影响选择执行，必要时加入完整回归 |
| 重复或低价值检查 | 找到已有等效证据后，考虑合并、降频或移除 |
| 过时、失效或已无对应功能的检查 | 修复、替换或退役，并记录原因 |
退役测试需要证据：例如功能已经删除、风险已经改变，或另一个更可靠的检查已覆盖同一目标。不能只因为“多年没报过问题”就移除关键验证。
发布建议前，回答五个问题
作者结合自己在英国皇家空军（RAF）飞机工程领域的经历，强调保障力度应与潜在故障的后果相匹配。低风险内部应用和金融交易平台、受监管的 AI 决策系统、安全关键软件，不可能共享同一条覆盖率门槛。
| 要回答的问题 | 需要说明的内容 |
|---|---|
| 我们理解风险了吗？ | 除了需求，还要说明可能出什么问题、影响谁，以及业务后果有多严重。 |
| 最重要的部分测了吗？ | 关键路径、重要集成、安全性、数据完整性，以及失败后果最大的场景。 |
| 收集了什么证据？ | 不只报告通过数量，还要解释结果能支持哪些质量判断。 |
| 哪些内容没有测试？ | 让干系人知道未覆盖范围、假设和不确定性。 |
| 继续测试会改变决定吗？ | 如果追加测试可能发现重大风险，就有理由继续；如果不太可能提供新的决策信息，就说明停止依据。 |
这五个问题把停止判断从“执行了多少”转向“现有证据能支持什么”。作者也提醒，追加测试可能出现收益递减，但拐点取决于系统、风险和现有证据的质量，不存在统一百分比。
停止测试，不代表批准发布
**实践延伸：**停止测试和批准发布是两个不同的决定。团队可能认为再投入相同资源已很难得到新的有效证据，但剩余风险仍不在组织可接受范围内；也可能因为时间到了被迫停止，却没有足够证据判断风险。
| 当前证据 | 剩余风险 | 建议的下一步 |
|---|---|---|
| 充分 | 可接受 | 提交发布建议，并说明证据范围 |
| 充分 | 不可接受 | 暂缓发布、降低风险，或由有权限的负责人明确接受风险 |
| 不足 | 尚不清楚 | 优先补充能改变判断的关键证据 |
| 因时间或资源被迫中止 | 仍有未验证项 | 如实披露测试中止原因、缺口和责任人，不能把“停止”写成“质量已证明” |
测试人员负责说明风险、证据和不确定性，并给出专业建议；发布负责人或组织的治理机制负责依据风险承受能力作出发布决定。测试结果不能替代这项责任。
继续测试是否值得，看它能提供什么新信息
**实践延伸：**可以用一个概念模型检查追加测试的价值：
追加测试的预期价值 = 发现重要新信息的可能性 × 这些信息改善决定的价值 − 追加测试的成本
这里的成本不只有执行时间，也包括维护人力和延迟交付的代价。这个模型不是原文提供的公式，也不要求团队把每个参数算成精确数字；它提醒我们问：这轮测试可能改变什么判断？如果答案是“可能发现高后果风险”，即使发现概率不高也值得继续。如果它只会重复已有证据，边际价值可能很低。
AI 让“测试足够”更难证明
生成式 AI 的输出会随提示、上下文和运行变化。同一个输入可能得到不同答案；读起来合理的回答也可能错误、不完整或误导。团队无法穷举所有输入、输出和组合，单纯增加测试数量也解决不了这个问题。
原文提出几项需要关注的做法：选择有代表性的评估数据、覆盖高风险场景、重复评估，并理解结果中的统计不确定性。100 次评估都成功可以提供有用证据，但够不够仍取决于样本、输出变化程度和错误后果。
**实践延伸：**可以用“零失败的三法则”（Rule of Three）说明样本量的边界。若 n 次相互独立、分布相同的评估均未发现失败，失败率的单侧 95% 置信上界可粗略估为 3/n：
| 零失败的评估次数 | 失败率单侧 95% 上界近似值 |
|---|---|
| 100 | 约 3% |
| 300 | 约 1% |
| 1,000 | 约 0.3% |
| 3,000 | 约 0.1% |
因此，100 次成功不能证明真实失败率为零。这个近似还依赖几个条件：样本相互独立且来自同一分布，评估方法能可靠识别失败。若样本彼此相关、数据集不能代表真实使用、评估器本身会漏判，或线上输入分布发生变化，这个上界就不能直接代表实际风险。
高风险 AI 应用需要更充分的评估、独立保障和上线后监控；低风险应用可以采用较轻的方案。无论哪种场景，都应把离线评估与真实使用后的变化分开看。
把风险、证据与停止决定连起来
**实践延伸：**风险—证据映射表可以帮助团队避免只看总覆盖率。下面是示例，状态不代表任何真实项目的评估结果：
| 风险场景 | 潜在影响 | 需要的证据 | 示例状态 |
|---|---|---|---|
| 支付重复扣款 | 高 | 幂等、并发与故障恢复验证 | 待验证 |
| 用户权限越权 | 高 | 权限矩阵、负向测试和安全验证 | 已验证 |
| 普通页面样式偏差 | 低 | 关键设备上的视觉回归抽样 | 已验证 |
| AI 回答缺少依据 | 依使用场景而定 | 事实性评估、来源核验和重复评估 | 部分验证 |
一个可复查的停止流程可以这样安排：先识别重要风险与不可妥协的发布门槛，再选择能提供相应证据的测试；执行后检查结果质量、未覆盖假设和剩余不确定性；随后评估追加测试是否可能改变建议，最后把发布建议和剩余风险交给有权限的负责人。
记录中至少应留下测试范围、关键风险、验证结果、未测内容、剩余风险、追加测试的预期价值、发布建议和责任人。这样，测试停止点有据可查，后续的人也能看懂团队当时为何作出这个决定。
质量 Loop：让停止条件跟着风险变化
停止条件不是项目启动时写一次就永远不变。上线后的缺陷、用户反馈、业务变化和新的集成都会改变风险，也会改变旧证据的价值。
可以把这个过程放进质量 Loop：记录本轮测试发现与漏测问题，补充或调整验证；整理风险、证据和决策结论，作为下一轮的上下文；再根据产品变化、提示词、数据、模型或 Agent 工具的变化重新评估。不同模型和 Agent 即使执行相同的方法，也可能表现不同，因此要验证当前组合，而不是把过去的结果当作永久保证。
这也是 AI Native Quality Engineering 可以落地的一条路径：把风险分析、测试选择、证据验证、回归优化和发布准备连接成相互配合的能力。自动化或 Agent 可以协助整理结果、找缺口、比较回归变化，但没有团队认可的门槛和授权时，不应自行宣布“测试已经足够”。质量 Loop 的产物是更可靠的证据和更清楚的决策，不是一个一次性算出的停止数字。
评论区留下的三个问题
- Thabo Mahlangu 提醒，电商购物车里的小问题与健康科技或金融科技里的同类问题，后果完全不同。项目风险级别变化时，测试门槛也要跟着调整。
- Tinashe Maphela 把难点问得很直接：回归包一直增长，退役用例的规则是什么？增加测试容易，减少测试需要证据。
- Sharon Heying 指出，产品复杂度、风险和可用时间共同影响测试深度。项目情况会变，测试重点也要重新评估。
这三个问题把文章拉回到日常工作：测试门槛如何适配风险，旧用例如何退役，测试深度又该何时调整。它们都没有脱离上下文的固定答案。
测试够不够，最后要看决策证据
斯多葛的节制要求我们把注意力放在能控制的事情上。测试人员不能保证软件没有缺陷，却能改进测试方法、提出更好的问题、收集更可信的证据，并清楚说明不确定性。
每次准备停止时，可以再问自己两句：继续测试，是风险仍然需要验证，还是没人愿意作发布决定？停止测试，是因为证据已经充分，还是因为项目没有时间了？
好的测试不要求把所有东西都测一遍，而是围绕重要风险收集足以支持知情决定的证据，并让大家知道仍在接受哪些风险。有时节制意味着停下来；有时则意味着有理由地坚持继续测。
How Much Testing Is Enough? The Stoic Case for Knowing When to Stop: https://www.linkedin.com/pulse/how-much-testing-enough-stoic-case-knowing-when-stop-stephen-platten-l4xqe/