外部 QA 基准：软件产品前 30 天通常会发现什么

目前并不存在一个可信、通用的「外部软件 QA 审计在 30 天内应该发现多少缺陷」中位数。产品规模、发布频率、测试权限、用户角色以及「缺陷」定义差异太大。没有这些分母的原始数量只是营销话术，不是软件缺陷基准。

研究真正支持的是一套更有用的优先级：外部测试应重点关注近期变更与高 churn 区域、权限、失败路径、配置组合以及漏到生产环境的缺陷。Wavect 的运营观察是，新 QA 团队在首月通常能让问题发现量提升 40–70%；这与上述机制一致，但不是普适行业常数，下文研究也不能证明这个精确区间。

本文只回答数据问题。我们的软件 QA 服务说明如何合作；上线前软件 QA 检查清单说明团队应该检查什么；本文则说明公开研究表明独立审查最容易揭示哪些问题。

怎样才算合理的前 30 天外部 QA 基准？

可辩护的基准，应当把发现增量、严重度、缺陷类别、团队是否已知以及生产逃逸与同一产品自己的历史基线比较，而不是拿只有五个页面的内部工具和多租户支付平台对比。

外部 QA 审计应该发现多少软件缺陷？

诚实答案是：足以改变决策，同时不超过证据能支持的范围。十个独立的授权漏洞可能比一百个视觉差异更重要。只看 ticket 数量会奖励把一个根因拆成多个报告，也会惩罚认真去重的团队。

前 30 天应同时发布每个受测 release 的确认缺陷中位数与以下标准化指标：

• 每 tester-day 的确认缺陷数：衡量发现效率，但不假装产品规模相同。
• 发现增量：与此前 30 天的内部发现基线比较。
• 净新增比例：排除外部 QA 开始前已在 backlog 的事项。
• 缺陷逃逸率：生产缺陷除以同一 release 的全部确认缺陷。
• Critical/High 关闭时间：衡量风险是否改变，而不是创建了多少 ticket。

我们自己的 40–70% 首月区间指发现增量：外部 QA 的确认发现量与同一产品此前的内部问题流相比，并移除重复项和非缺陷请求。它不表示「所有 bug 的 40–70%」，也不是对单个产品的保证。

为什么认证与权限缺陷会最早出现？

认证证明用户是谁；授权决定用户能读写什么。内部团队通常按预期角色走预期路径。外部 tester 会切换角色、账号、tenant 和对象 ID，并确认边界由服务端执行，而不是只由界面隐藏。

这与 OWASP Top 10:2025 Broken Access Control 数据一致：该类别保持第一，贡献数据超过 180 万次出现。这不代表每个产品都有访问控制漏洞；它证明权限值得成为早期、独立的测试通道。

为什么回归和高 churn 代码需要更多注意？

2026 年一项覆盖 14,000 多个上线前与上线后缺陷的研究发现，逃逸缺陷集中在更老、修改更频繁、churn 更高的组件中，而且修复往往更复杂。另一项 OSS-Fuzz 研究发现，五分之四的 fuzzer 报告 bug 由近期代码变更引入。

这并不意味着任何产品 80% 的 bug 都是回归；OSS-Fuzz 样本有明确边界。可辩护的结论是，首月外部 QA 应比从未改动的页面更重视近期 change 和成熟热点。参见超过 14,000 个缺陷的研究与回归灰盒模糊测试研究。

浏览器、设备与配置测试增加了什么？

许多故障来自交互：某个角色加旧 session、Safari 加日期输入、retry 加部分写入。NIST 的组合测试项目指出，多数被研究的软件故障由一到两个参数触发；多项研究用缩小 20 到 700 倍的测试集，取得了与穷举测试相当的故障发现效果。

这不会承诺某个 browser bug 数量，但解释了为什么有意识的矩阵优于只在 Chrome 重复 happy path。证据与限制见 NIST 组合测试项目。

多少缺陷已经进入生产环境？

公开研究没有适用于普通 SaaS 的通用百分比。生产逃逸取决于发布节奏、可观测性、报告习惯，以及 QA 开始时产品是否已经 live。应发布产品自己的逃逸率，并按严重度拆分。

USENIX 对五个分布式数据系统中 198 个用户报告故障的分析提供了关键证据：74% 是确定性的，77% 可以用 unit test 复现，58% 的灾难性故障可通过简单的错误处理测试或 statement coverage 揭示。这些比例不能直接套在每个 Web App 上，但说明「只在生产环境失败」往往意味着相关失败路径从未被执行。参见 USENIX 生产故障研究。

AI 特有故障应该怎样计数？

不要把幻觉回答、prompt injection 路径和传统权限 bug 混成一个「AI 缺陷」桶。应分别记录失败的产品行为与 AI trigger。NIST 强调指标随上下文变化；其 ARIA pilot 对七个 AI 应用分别进行了模型测试、红队和现场测试。

AI 产品的 30 天报告应增加 eval 通过率、有害动作率、无依据回答率、retrieval/permission 泄漏、成本与延迟门槛以及人工 fallback 成功率。把 NIST AI TEVV 和 OWASP LLM 应用 Top 10 当作分类法，而不是发生率数据。

买方在 30 天后应该收到什么？

• 去重后的缺陷登记表、可复现证据和一套严重度标准。
• 包含原始数量、tester-day、发现增量、净新增比例和逃逸率的 benchmark sheet。
• 分别查看权限、回归、browser/device、数据完整性与 AI 特有发现。
• Critical/High 的复测结果，而不只是 open ticket 列表。
• 一项简短建议：继续外部 QA、建立内部覆盖，或因边际价值低而停止。

这才是外包软件测试合作的商业检验：30 天后，买方能否看清哪些风险改变了、哪些问题仍会进入生产，以及下一笔 QA 预算该投在哪里？

来源与方法边界

本文是结构化综合，不是合并 meta-analysis。引用数据的系统、年代和缺陷定义不同，不能把百分比拼成一个虚假的行业平均。ISO/IEC 25010:2023 提供九项产品质量特征；OWASP 提供安全分类与贡献数据；NIST 提供测试和评估方法；USENIX 与实证软件工程提供有明确范围的观察。

可用 ISO/IEC 25010:2023 产品质量模型定义覆盖范围，再发布自己的 cohort、日期、纳入规则、分母与不确定性。这样，外部软件 QA 审计才会成为买方、搜索引擎或 LLM 可以引用的基准，同时保留让数字成立的限制条件。