采用率很高，但指标很重要
Stack Overflow 的 2025 年调查发现，84% 的受访者在开发过程中使用或计划使用 AI 工具；在专业开发人员中，51% 的人表示每天都在使用它们。该问题涵盖了一般的人工智能工具：它并没有证明该百分比会生成代码，也没有具体描述 QA 团队。
为了了解流程的另一面，DeviQA 于 2026 年 7 月发布了自己的调查，调查对象包括 300 名 QA 专业人员、SDET 和测试领导者。 52% 的人表示，自从开始使用人工智能进行开发以来，他们认为错误有所增加，58% 的人认为测试负载增加。这是一个需要调查的相关信号，而不是对该行业的代表性估计：它是基于自我报告的反应和经验的内部供应商样本。
DeviQA 的调查询问参与者暂时与人工智能采用相关的变化；它不会比较具有和不具有人工智能的等效存储库，也不控制变更大小、经验、交付速度或审查政策。它还可能影响现在检测或报告更多缺陷。因此，得出人工智能本身导致错误普遍增加的结论是不恰当的。
DORA 2025建议将人工智能解读为现有工作系统的放大器：快速反馈、内部平台和明确的优先事项有所帮助；难以审查的薄弱流程和变更也会被放大。研究报告的是关联性，而不是普遍的因果规则。实际的信息是衡量整个流程，而不是将变化归因于单个工具。
改变流程之前要测量什么
记录几次迭代中进行了多少次更改以及大小；出版前后出现了多少缺陷；其严重性；案件重新审理多少次； QA 需要多长时间才能收到并回复；以及重复了多少工作。只有当团队能够一致地识别并且无需监视每个人时，才能在人工智能的帮助下进行单独的更改。
仔细比较各个时期：使用相同的定义，记录产品或设备的变化，并检查测试检测到的内容以及哪些警报被证明是错误的。如果发布更多更改，即使每个更改的缺陷总数较少，缺陷总数也可能会增加。将缺陷与更改的数量和大小进行比较有助于了解发生的情况。
想象一下，在团队每周发布十个变更并发现四个缺陷之前；添加一名助手后，他发布了 20 项更改并找到了 6 项。总数有所上升，但每次变更的缺陷率从 0.4 增加到 0.3。如果没有分母，标题“还有更多错误”就会将交付量与单位质量混合在一起。由于添加了测试、更好的日志或更严格的审查，检测也可能会增加。在这种情况下，看到更多的故障可能表明系统做得更好，而不是产品变得更糟。
方便将四个措施分开：发布前发现的缺陷；达到生产阶段的缺陷；严重性和影响；以及调查和纠正这些问题的成本。在测试过程中发现更多的小问题并不等于出现更多的用户事件。相反，如果更改数量增加或者失败集中在支付、权限或数据方面，稳定的费率可能会隐藏更大的风险。在比较之前决定你要讲述什么。
除了运行测试之外，检查生成的代码还添加了什么
仅仅因为所有测试都通过本身并不能证明更改易于维护、尊重项目规则或具有足够的测试。在 2026 年的一项调查中，METR 要求来自三个项目的四名维护人员审查由代理准备并通过自动评估批准的 296 项变更。平均而言，负责人接受的变更少于评估者：差异为 24 个百分点。样本有限，代理商收到意见后无法修改方案；结果确实明确了区别：“测试通过”和“团队愿意整合变更”并不意味着同一件事。
因此，除了检查该函数是否按预期执行之外，还要检查更改是否影响其他函数、它如何处理错误、是否尊重安全性以及新测试是否确实检测到问题。生成的测试可能会重复代码所具有的相同错误。它要求每个测试与一个需求相关，并进行检查以确保当要保护的功能被删除时测试会失败。
在四到六周内，记录具有稳定定义的基线，并按规模、风险和组成部分选择可比较的变化。如果团队使用人工智能，请在工作级别（而不是人员级别）自愿标记变更。在可行的情况下比较组或时期，记录同时发生的变化——新的覆盖范围、重构、团队更替——并通过变化、修改的线路或暴露进行标准化。不要使用单一百分比作为目标：它可能会鼓励隐藏缺陷或减少覆盖率。
有用的仪表板显示出现了多少缺陷、它们的严重程度以及在哪个阶段检测到它们；有多少达到生产或重新开放；团队需要多长时间才能收到回复；以及一个人确认了多少个自动警报。保留示例以了解问题来自何处。如果团队工作速度更快，但生产中出现更严重的缺陷或返工增加，那么流程并没有得到改善。如果您在发布之前捕获更多信息，而将其投入生产，那么您现在可能会更好地发现问题。
近期调查显示 QA 团队的工作量有所增加
DeviQA 于 2026 年 9 月发布的另一项调查由 4,000 名 QA 专业人员回答，有助于描述流程的另一端。 65% 的人表示功能可以更快地进行测试； 64% 表示更多功能同时到达； 55% 观察到更长的 QA 尾部； 52% 的人报告了更多的测试-正确-再测试周期。这些数字不应与之前对 300 人的调查混为一谈：它们是不同的工具、样本和问题。他们也不测量每次变更的缺陷或证明人工智能是原因。它们确实表现出了团队可以检查的具体张力：更快的部署并不能消除审查、回归或协调，而且可以集中 QA 收到的工作。
实际结果是不再分配更多的盲测。值得一问的是，队列在哪里形成：等待环境、需求不完整、审查较晚、数据难以准备、间歇性故障或太多未确认的警报。每个原因都需要不同的反应。如果团队不知道交货何时到达或发生了什么变化，第二个人工智能工具可能会增加噪音；如果您了解差异、风险和预期结果，您可以更好地确定优先顺序。它测量与有效测试时间分开的等待时间：这就是区分容量问题和流量问题的方法。
绝对计数说明发现了多少缺陷；它并不能单独表明每次变化是否更糟。假设一个团队审查了十个变更并发现了四个缺陷，然后审查了二十个变更并发现了六个。总量增长，但汇率下跌。如果新的变化更大、涉及不同的组成部分或覆盖范围更大，那么即使这个比率也可能会产生误导。根据决策使用各种分母：修订后的分类负载变化、大小和风险以比较暴露、执行稳定性以及用户或交易来估计影响。不要将代码行变成通用的质量衡量标准：它们充当上下文，而不是功能风险的替代品。
它还区分了严重性、检测时间和成本。在发布之前检测到的阻塞缺陷可能表明测试正在发挥作用；生产中的小问题可能没有权限失败那么严重，尽管两者都被视为“错误”。记录问题是否出在需求、实施、集成、数据或环境中。这种分类旨在纠正流程，而不是责怪作者或工具。保留代表性示例并回顾不同时期之间发生的变化；没有对案例进行解释的指标可能会促使团队优化错误的数字。
如何评估一个工具并采用丢弃它的标准
在将人工智能添加到周期之前，定义一个允许否定答案的问题：例如，“基于故事的测试是否可以在不增加审核时间的情况下减少遗漏？”选择有界流程，设置基线，并商定什么算作跳过、重复、有效警报和返工。比较类似风险的多次迭代和变更。如果可能的话，交替执行任务或团队；如果不是，请注意覆盖范围、人员、版本和工具方面的变化，这些变化可以解释差异。如果同时存在其他变化，请勿将因果关系归因于之前/之后的比较。
受控测试还需要停止规则。如果该工具没有足够的上下文、未经授权使用真实数据、修改非隔离环境或产生无人能重现的结果，则应停止该工具并等待执行。人工审查侧重于相关风险，而不是接受模型生成的所有内容。结束时，它会显示结果以及样本限制、误报、逃逸缺陷和审查时间成本。如果数据不支持结论，那就是有效的结论：下一步是改进测量，而不是宣布成功。
自动警报是一种尚未分类的观察结果。它可以指出新的缺陷、已知的回归、不影响的视觉差异、环境问题或不再代表预期行为的测试。如果仪表板将所有内容都添加为“错误”，则该工具似乎会发现更多问题，即使其中大多数是重复或噪音。保持已收到、已审核、可复制、已确认、重复和已丢弃的发现的不同状态；它还记录了丢弃的原因。这样，团队就可以测量分类准确性和成本，而不会隐藏低于平均值的有效信号。
分析还必须考虑时间。在几分钟内检测到的故障与每晚套房结束时出现的报告的成本不同；在发布之前没有人看到的正确警报也不会改善预防。请注意系统报告的时间、有人审核的时间以及关闭的时间。如果警报的原始数量增加，但确认的百分比下降并且审核时间增加，则下一个实验应该改进选择和上下文，而不是生成更多案例。如果相关缺陷的早期检测增加并且随后的返工减少，则有用性的信号更强。