AI-Native QA Weekly｜第 45 周
本期覆盖 2026-11-02 00:00 至 2026-11-08 23:59（Asia/Shanghai），发布日期为 2026-11-11。本期按 ai-qa-weekly 的规则筛选出 10 条与 AI 测试、Agent 评测、测试自动化和质量工程有关的动态，并将国内与国际来源统一排序。论文结果、厂商发布和社区调查分别按其证据类型说明；涉及厂商自述或特定测试条件的数据，不应直接外推为普遍结论。以下 QA 启示是编者建议，不代表本期已完成工具实测或研究复现。
1. LLM 测试修复研究构建 500 组源代码与测试协同演化样本
分类: AI Testing
来源: arXiv · 软件工程研究
更新日期: 2026-11-02
介绍:
这项研究关注源代码持续演进后，原有测试失效或变得过时的修复问题。作者整理了来自 15 个开源 Java 项目的 500 组真实源代码与测试协同演化案例，研究失败症状、代码变更和辅助代码等上下文分别怎样影响大语言模型修复测试，并分析模型多轮自我修复时采取的动作。论文还用执行轨迹归纳出修复过程中的推理动作，并报告将所提出的方法用于 Codex 后，在较难案例上的修复成功率有明显提升。对 QA 团队来说，这项工作提示测试维护不能只把失败堆栈交给模型：需要给出与变更相关的上下文、保留每轮修改记录，并以真实断言和回归运行确认结果。该基准来自 Java 开源项目，论文结论不等于对其他语言、仓库或生产系统的效果保证。
链接: https://arxiv.org/abs/2611.03197
2. Terminal-Bench 2.1 将基准维护变成持续验证流程
分类: Agent Testing
来源: arXiv · Terminal-Bench 研究
更新日期: 2026-11-05
介绍:
这篇研究把 Agent 基准视为需要持续维护的软件，而不是发布后就固定不变的题库。作者将社区反馈、任务文件、Agent 执行轨迹、自动 oracle 检查和人工把关的修复串成验证流程，并用它审计 Terminal-Bench 2.0。审计发现约 30% 的基准存在需要处理的问题，团队据此发布 Terminal-Bench 2.1；修复后准确率变化超过 10 个百分点，部分模型的榜单名次最多移动三位，整体排名相关性仍为 0.958。研究也显示时间上限、内存和沙箱配置会改变结果，因此题目、验证器、资源预算和执行环境都属于测量规范。对 QA 和评测团队而言，基准回归需要持续检查“任务是否仍有效”“合法解法是否被误拒”以及“环境差异是否扭曲分数”，避免把基准缺陷误当成模型进步或退步。
链接: https://arxiv.org/abs/2611.08417
3. FutureAGI v1.58.0 为 Agent 模拟和修复增加 must-pass 保护
分类: AI Testing
来源: GitHub · FutureAGI Releases
更新日期: 2026-11-03
介绍:
FutureAGI 的 v1.58.0 版本更新了 Agent 模拟和失败修复流程：模拟记录可以附带 Agent 提示词及工具调用，帮助团队把结果与当次行为关联起来；修复流程可以针对失败运行验证候选改动，并提出创建 pull request。版本同时加入 must-pass 用例保护，让团队标明必须持续通过的案例；如果保护检查否决候选改动，仍可在说明原因后选择提交。另有一项评测调整会跳过空的 few-shot 输入。对 QA 来说，价值在于把“修复了一个失败”与“没有破坏必须通过的行为”放到同一条验证链中，同时保留提示词、工具调用和覆盖决策的证据。must-pass 集合仍需要团队维护代表性和稳定性，工具提供的保护也不能代替独立回归测试或代码审查。
链接: https://github.com/future-agi/future-agi/releases
4. Testkube 为测试 Agent 加入模型、权限、成本和调用审计控制
分类: Quality Engineering
来源: Testkube
更新日期: 2026-11-03
介绍:
Testkube 的 11 月版本面向运行在测试基础设施中的 AI Agent 增加治理控制。管理员可以限制 Agent 可用的模型、指定哪些角色或资源组能够查看和运行 Agent，并按用户、Agent、环境或组织配置 token 预算；平台还记录 Agent 调用了哪些工具以及相关交互，便于回看执行路径。该版本还提到 GitLab 支持和新的测试执行时间线。对质量工程团队来说，这些能力把 Agent 测试从“输出是否正确”扩展到“谁能触发、能访问什么、花费多少、实际调用了什么”，可用于设计权限、预算和审计验收。需要留意的是，厂商说明 token 控制取决于模型提供方是否返回可用的 token 用量；接入时仍应核对不同模型的计量完整性、角色隔离边界和日志是否覆盖失败及重试过程。
链接: https://testkube.io/blog/testkube-november-2026-release-ai-agent-governance
5. Katalon True 支持按数据集行运行 AI 辅助手工测试
分类: AI Testing
来源: Katalon True Release Notes
更新日期: 2026-11-05
介绍:
Katalon True 在 11 月 5 日的版本说明中加入手工测试数据集运行能力：团队可以从 CSV 导入多行数据，在测试步骤中使用列占位符，并让 AI 对每一行分别启动一次会话、记录独立结果。这样同一流程可以覆盖多个输入，而不必复制出多份测试用例。发布说明还提到管理员可按 AI 功能开关账户级设置并查看设置历史；通过 MCP 创建或更新测试用例时，可以填写可写字段并要求先审批。对 QA 来说，独立会话和结果有利于定位特定数据触发的问题，但需要检查 CSV 空值、特殊字符、行间状态污染、失败重试以及 AI 结果是否可重复。审批和设置历史也应纳入权限测试，确认实际变更、操作者和批准记录能够对应起来。
链接: https://docs.katalon.com/katalon-platform/release-notes/katalon-testops-release-notes
6. ViBench 2.0 用整套产品的浏览器测试检验长周期构建 Agent
分类: Agent Testing
来源: arXiv · Replit 研究
更新日期: 2026-11-03
介绍:
ViBench 2.0 评估 Agent 从空项目开始，经过连续功能请求构建完整 Web 产品的能力。基准包含 17 个全栈产品、241 项逐步增加的功能需求，并用浏览器 Agent 执行 544 份测试计划；只有所有计划都通过，整个产品构建才算成功。研究评估了 9 个模型，发现表现最强的模型虽然在单份测试计划上最高可通过 98%，完整产品构建成功率最高也只有 65%。这种“单项看起来很强、整体交付仍会失败”的差距，说明长流程软件 Agent 需要按最终产品状态评估，不能只统计成功完成的最后一个需求。对 QA 来说，基准强调跨需求回归、全产品验收和测试计划可靠性；其范围主要是特定 harness 下的全栈 Web 功能正确性，不能直接代表视觉质量、速度或其他 Agent 配置。
链接: https://arxiv.org/abs/2611.05620
7. SWT-Bench 更新 Bugstack 结果：单元测试模式达到 91.5% 成功率
分类: AI Testing
来源: SWT-Bench
更新日期: 2026-11-02
介绍:
SWT-Bench 的 Verified 榜单在 11 月 2 日记录了 Bugstack 的一项新结果：在单元测试模式下，使用 Claude Sonnet 5.5 与 Opus 5.5 进行测试选择时，成功率为 91.5%，对修复补丁的平均行覆盖率增量为 72.2%。SWT-Bench 衡量生成测试能否复现软件问题，并报告对解决该问题的补丁增加了多少行覆盖；其站点说明已独立执行提交的预测结果进行验证。这个结果提供了测试生成 Agent 在特定基准和执行模式下的可比数据，但不能当作任意仓库中的缺陷捕获率，也不能与不同模式的分数直接等同。QA 团队可借鉴其同时看问题复现与补丁覆盖的报告方式，并在内部样本上检查测试是否真正失败于目标缺陷、是否误报，以及能否稳定重跑。
8. SWEOps-Bench 测量云事故 Agent 从发现到验证恢复的完整链路
分类: Performance & Reliability
来源: arXiv · 软件运维 Agent 研究
更新日期: 2026-11-04
介绍:
SWEOps-Bench 针对软件引发的云事故构建交互式端到端评测，包含从 16 个 Kubernetes Operator 项目已确认历史缺陷整理出的 55 个可复现任务。每个任务从健康集群开始，通过受控工作负载触发故障；Agent 需要检查运行时证据、提交源代码或配置修复，再由评测框架构建和部署改动。评估指标不仅包含故障检测，还检查分阶段定位、验证恢复、生命周期耗时和 token 使用。作者在六种 Agent 与模型配置上观察到，故障状态检测率为 72.7% 至 90.9%，但端到端恢复率只有 14.5% 至 52.7%；报告中的原因判断与最终是否恢复也并不总是一致。对可靠性工程而言，这提醒团队要用功能验证确认修复，而不能把诊断文本或症状消失当作事故已经解决。
链接: https://arxiv.org/abs/2611.06099
9. DistDebug-Bench 提供 120 个分布式系统真实缺陷供 Agent 调试评测
分类: Agent Testing
来源: arXiv · NeurIPS 2026 评测与数据集方向
更新日期: 2026-11-07
介绍:
DistDebug-Bench 面向 Agent 在分布式系统中的代码级故障诊断能力，整理了来自 11 个常用分布式系统的 120 个真实缺陷，覆盖 5 种编程语言和 10 类故障模式。论文对多种大语言模型和 Agent 进行评测，并指出当前系统与真实调试需求之间仍有差距，常见问题包括缺少明确推理结构导致的“隧道视野”，以及工具使用范围不一致带来的非确定性。作者同时开放基准与评测器，并提供 Agent 执行轨迹和榜单，便于复现与进一步分析。该版本于 11 月 7 日修订，属于本期范围。对 QA 和 SRE 团队来说，它提供了比单文件编程题更贴近复杂系统故障的评测思路；但论文中的任务集和模型配置仍不能覆盖所有生产系统，需要结合自身服务、日志、拓扑和权限条件补充验证。
链接: https://arxiv.org/abs/2611.03523
10. TestMu AI 调查显示 AI 代码验证与 Agent 评测仍有明显缺口
分类: Research & Trends
来源: TestMu AI · State of AI in Quality Engineering 2026
更新日期: 2026-11-02
介绍:
TestMu AI 于 11 月 2 日发布《State of AI in Quality Engineering 2026》，调查在 2026 年 7 月下旬至 10 月上旬通过其全球社区在线开展。报告称，81% 的受访团队曾合并自己并未完全理解的 AI 生成代码或测试，44% 表示随着 AI 生成代码增加，逃逸缺陷或生产事故也有所增加；在构建 Agent 的团队中，37% 没有系统化的 Agent 评测方式。报告还指出只有 41% 会在合并前对 AI 生成代码执行自动检查。对 QA 负责人来说，这些数据可作为审视合并前验证、Agent 回归和对抗测试覆盖的线索；但样本来自 TestMu AI 社区，是厂商组织的自报调查，不是代表整个行业的随机抽样，且相关性不能证明 AI 生成代码导致了缺陷增加。应用这些结论时应先对照自家数据和定义。
链接: https://www.testmuai.com/research/state-of-ai-in-quality-engineering/