AI-Native QA Weekly｜第 40 周
本期衔接上一期，精选 10 条与测试生成、Agent 评测及发布验收直接相关的内容。国内及中文来源参与同一轮筛选；本轮检索到的中文候选未通过时效或实质更新核验，因此未入选。以下 QA 应用建议为编者解读，论文结果不等同于生产验证。
1. Multi-SWT-Bench：用八种语言检验 AI 缺陷复现测试
分类: AI Testing
来源: arXiv 预印本
更新日期: 2026-09-28
介绍:
Multi-SWT-Bench 将缺陷复现测试评测扩展到八种语言，包含 1,963 个问题实例。有效用例必须在缺陷版本上失败、修复版本上通过，而不只是成功执行。实验中，各方法在 Python 上的表现均高于跨语言总体表现，C++ 尤其困难；失败还涉及仓库测试约定、隐含环境准备及迭代修改后偏离目标行为。对 QA 而言，不能用单一语言的成绩代表整个技术栈。试用 AI 生成回归用例时，应保留两个版本的执行证据，检查修复测试的过程有没有弱化原始断言，并把依赖安装、测试入口和环境准备纳入验收。这些结果反映基准中的测试生成能力，不等于生产缺陷检出率。
链接: https://arxiv.org/abs/2609.34752
2. 企业 Agent 过程评测：结果正确，不代表执行过程合规
分类: Agent Testing
来源: arXiv 预印本
更新日期: 2026-10-01
介绍:
这项研究把企业 Agent 的最终结果与执行过程分开评估，通过程序检查工具选择、参数、执行顺序和数据库完整性，并辅以范围明确的模型裁判。在两个业务计算技能的 240 次试验中，175 次通过全部适用的最终数值检查，其中 162 次仍有其他执行偏差。对 QA 的启发是，答案正确不能替代对关键动作与状态的验收。测试用例应同时定义输出断言、动作约束和状态不变量，保留轨迹用于根因定位；工具或技能规范变化后，也要更新预期行为和可复用测试模板。上述比例只适用于论文场景，研究对真实接口长期演进的验证尚未完成，不能据此宣称企业流程已经获得长期稳定性保证。
链接: https://arxiv.org/abs/2610.01833
3. promptfoo 合入独立工作区能力：避免编码 Agent 评测互相污染
分类: Agent Testing
来源: promptfoo 官方 GitHub PR
更新日期: 2026-09-29
介绍:
promptfoo 合入编码 Agent 独立工作区功能，可为每次 Claude、Codex 或 OpenCode 调用创建隔离副本，保留到评分结束，采集代码差异后清理。实现也检查指向隔离区之外的链接和 Git 元数据。这直接回应了评测污染问题：共享可变目录时，前一条用例生成的文件、补丁或配置可能改变后一条的结果，导致评分无法重复。QA 接入时建议记录初始工作区、补丁、评分输入与清理结果，并覆盖并发执行、失败中断和路径越界场景，确认原始仓库没有被修改、评分仍基于对应样本。本条核实的是功能合入主分支，不代表某个已发布安装包必然包含它，实际使用前还要确认版本。
链接: https://github.com/promptfoo/promptfoo/pull/11063
4. Leapwork Play 正式可用：让 AI 生成的 Playwright 测试保留来源与审计证据
分类: Test Automation
来源: Leapwork 官方发布
更新日期: 2026-09-30
介绍:
Leapwork Play 宣布正式可用，支持依据需求工单、仓库和产品文档生成 Playwright 测试，也能录制浏览器操作或导入既有用例。标准代码可在平台、自有持续集成环境或通过 MCP 执行；企业方案提供审批、权限控制及来源、变更历史与运行日志。QA 值得检验的是需求、断言、变更和证据能否连起来。试点时可用稳定回归集作基线，检查生成用例是否覆盖验收条件、定位器修复是否保留原断言，以及失败与不稳定测试能否进入现有处理流程；不要仅以生成数量评价收益。这些能力来自供应商说明，实际覆盖质量、维护效果及套餐可用范围仍需验证。
链接: https://leapwork.com/blog/leapwork-play-reaches-general-availability/
5. Frozen Judges, Moving Agents：固定的 LLM 裁判也会让版本对比失真
分类: LLM Quality
来源: arXiv 预印本，本周修订
更新日期: 2026-09-29
介绍:
这篇本周修订的研究发现，固定的模型裁判对不同 Agent 版本仍可能具有不同误差。作者结合编码与客服任务，将裁判判断同执行结果或专家标签比较；在 60 个裁判与版本对比单元中，8 个仅靠裁判的区间判断宣告了未获执行证据支持的升级。对 QA 来说，旧版本校准的阈值不能自动成为新版本的可靠发布门禁。比较基线和候选时，应锁定相同任务保留成对样本，以可执行断言提供事实依据，对争议结果安排人工复核，并分别追踪错误接受、错误拒绝及其跨版本变化，避免总体分数掩盖风险。结论限定于论文实验，并不是断言所有模型裁判都不可用。
链接: https://arxiv.org/abs/2609.34198
6. AGO AI Quality Gate：把 RAG 评估分数转化为有证据的发布决策
分类: Quality Engineering
来源: arXiv 预印本
更新日期: 2026-10-01
介绍:
AGO 提出面向 RAG 的证据优先发布门禁，分层处理确定性检查、防护规则、模型评估和回归风险，并明确处理证据缺失与裁判错误。在相同的 1,200 条分层测试样本上，不同裁判的区分能力明显不同，说明输出格式正确不代表判断可靠。QA 可以借鉴的重点是先验证裁判，再把平均分拆成具体风险与证据：为关键错误设置确定性拦截，按业务切片检查回归，并定义证据不足时的暂停或人工复核策略，同时保存裁判版本和校准记录。公开实验主要覆盖裁判层和模拟发布决策，不是完整生产验收，因此不能把该方案宣传为已经保证真实环境零错误放行。
链接: https://arxiv.org/abs/2610.01218
7. Inspect AI 0.3.274：加强沙箱权限检查与评测日志信任控制
分类: Agent Testing
来源: Inspect AI 官方更新日志
更新日期: 2026-10-01
介绍:
Inspect AI 0.3.274 强化了执行环境和日志展示的边界：每个样本开始、Agent 执行前检查沙箱根用户能力，明确处理检查不确定、无法执行及后续权限失败；本地沙箱也不再静默忽略不支持的用户参数。日志查看器新增不信任内容的配置，改用纯文本展示，避免渲染 Markdown 媒体与可点击链接。对 QA 而言，环境权限错误应与模型任务失败区分，模型和工具输出也不该天然获得展示端信任。接入时建议补充权限不足、不支持的运行用户和不可信日志内容测试，验证错误分类，并记录运行身份与配置，使失败能够解释和复现。框架升级本身不代表评测成绩提高。
链接: https://inspect.aisi.org.uk/CHANGELOG.html
8. Merged, Not Measured：AI 性能修复被合并，不代表收益经过验证
分类: Performance & Reliability
来源: arXiv 预印本
更新日期: 2026-09-30（上海时间）
介绍:
研究识别了编码 Agent 提交中的 1,262 个性能问题，并复测部分修复。在 30 个已合并修复中，18 个达到交付判据，3 个低于声称的收益，9 个没有显著收益或出现回退；14 个还在未覆盖输入上改变了行为。这些数字仅代表复测样本，却说明合并不等于性能与正确性已经验收。QA 应让 AI 优化同时通过行为回归和受控基准，而不是采用合并记录或 Agent 自报数字作证据。建议保存基线与候选版本、重复测量结果、工作负载和环境参数，检查基准输入是否过度贴合补丁，并补充边界输入。若速度提高但业务行为改变，仍需明确判断是否允许发布。
链接: https://arxiv.org/abs/2609.37985
9. Agents Are Systems, Not Models：评测对象应包含整个 Agent 配置
分类: Agent Testing
来源: arXiv 预印本
更新日期: 2026-10-01
介绍:
这篇研究用四类科学任务评估编码 Agent 操作专业模型的表现，比较任务信息、推理、自我验证、时间预算与基础模型配置。在该基准中，约 54% 的结果差异来自相同配置重复运行的波动；任务信息影响显著，自检提示也不等同于专门验证工具。QA 因此不应只记录模型名称，或凭一次成功宣布稳定。评测需版本化任务资料、提示、工具、预算和验证机制，多次运行同一配置，报告波动与失败类型；升级比较则固定其他条件，区分模型改变和上下文、工具改变带来的效果，避免把偶然成功作为发布依据。该比例来自特定研究任务，不能直接估计所有业务 Agent 的生产稳定性。
链接: https://arxiv.org/abs/2610.01618
10. SmartBear 调查：AI 代码质量信心与生产失效存在落差
分类: Quality Engineering
来源: SmartBear 官方调查发布
更新日期: 2026-09-30
介绍:
SmartBear 的调查覆盖美国与英国 1,436 名在开发中使用 AI 的从业者和管理者。46% 的受访团队曾上线后来在生产环境失效的 AI 代码；在经历过失效的受访者中，69% 仍保持较高或完全信心。整体来看，只有 46% 的团队在生成代码前验证规格。这不是国内团队统计，也不是 AI 降低质量的因果证明，但提醒 QA 将信心与证据分开。可执行的改进包括前移需求验收检查，记录 AI 参与的代码和测试变更，按风险进行独立审查，并用逃逸缺陷、回归发现和证据完整性衡量效果，不能只看生成速度或团队使用率。规格、断言与发布风险的确认仍应保留，并由独立质量证据支持放行。
链接: https://smartbear.com/news/news-releases/state-of-software-quality-testing-2026/