QA 测试中的信任：关键假设与风险

# QA 测试中的信任：工程师如何在没有保证的情况下做出决策

在软件测试中，每一个决策都基于验证与信任之间的权衡。QA 工程师需要依赖未经证实的假设来做出决策，这挑战了他们职业的基础。让我们来剖析科学方法与务实信任之间的界限。

QA 的基础：职业怀疑主义

测试人员天生就是怀疑论者：他们不会不经确认就相信开发人员的声明、需求，甚至自己的测试结果。然而，完全拒绝信任会让流程瘫痪。关键问题是选择哪些点可以依赖数据，而无需额外检查。

Edsger Dijkstra 说得对：测试能证明 bug 的存在，但无法证明其不存在。尽管如此，团队每天都在按下部署按钮。这只有在工程师将怀疑主义与务实信任相结合时才可能实现。信仰与信任的区别至关重要：信仰不需要证据，而信任是基于经验的理性风险评估。

日常 QA 工作中的五大关键假设

• 真相来源是可靠的

需求、分析数据和以往系统版本被视为金标准，即使其中存在错误。例如，一个推荐系统按照“相关推荐”的表述进行测试，但相关性标准却未定义。

• 测试环境与生产环境一致

环境配置差异往往被忽略。在一个案例中，生产环境的 50 ms 网络延迟——测试环境中缺失——导致了服务间调用超时。

• 测试覆盖率足够

“95% 代码覆盖率”之类的声明掩盖了未测试场景的风险。按照 ISTQB 的定义，穷尽测试是不可能的。

• 工具运行正常

CI/CD 管道可能隐藏跳过的测试。在一个实例中，Jenkins 因为超时跳过了 UI 测试，但报告显示“通过”状态。

• 以往经验适用于新情况

为“稳定”模块削减回归测试，在依赖更新后遗漏了一个 bug。

为什么发布不是信仰行为，而是风险管理

发布决策不是基于信仰，而是风险评估。QA 工程师就像飞行员在起飞前一样，运行检查清单并在没有保证的情况下决策。与信仰的关键区别在于可证伪性：任何一个 bug 都会推翻系统正确性的假设。

Karl Popper 会称之为证伪：我们假设“系统正常运行”，试图推翻它，并在没有反例时暂时接受为真。但即使测试通过，也不能保证软件无 bug——它们只是降低了问题暴露的概率。

如何最小化信任风险

用风险登记册系统化管理假设。对于每个项目，跟踪：

• 团队选择信任而非验证的点
• 重新审视这些假设的标准
• 验证机制（例如，每季度对生产环境进行审计）

特别关注监控工具。记录网络延迟、跨环境比较性能指标，以及自动配置检查，这些都不是多余的——它们是必需的。对于支付模块，在管道中添加负载测试的 API 响应时间检查就足够了。

关键要点

• 定期检查关键假设：对齐环境配置，重新审视需求来源。
• 分级信任水平：并非所有来源都同样可靠——一个有三次错误记录的分析师需要额外审查。
• 绿色测试 ≠ 无 bug：“通过”仅确认无已知问题，但不保证完全无 bug。
• 记录假设：明确声明“我们信任 X”有助于在上下文变化时及时审查。
• 采用基于风险的方法：优先考虑对业务影响最大的场景。

结论：有意识的信任是一种职业技能

QA 工程师不是拒绝验证——他们学会了什么值得信任。这种怀疑主义与务实主义的平衡不是流程缺陷，而是特性。顶尖团队会记录假设，并在上下文演变时重新审视它们。

当经理问“你能保证无 bug 吗？”时，别说“是”或“否”。而是说：“这些是我们缓解的风险，以及我们有意识接受的风险。”这将信任从脆弱性转化为可控的流程元素。最终，专业人士不是测试一切的人，而是知道什么可以跳过——以及为什么。

— Editorial Team