概述
TestEngineerBench 将编码代理评估为自主软件测试工程师。给定产品需求文档、未修复的代码库和已配置的环境，代理可以决定测试内容和调查方向。无需提供问题报告、目标文件、函数或指定的入口点。
测试生成与缺陷发现和报告是两个独立的任务。关键发现是，有效的测试和广泛的代码覆盖率并不能保证有效检测出缺陷：测试人员可能执行了正确的代码，但却未能检查出区分缺陷及其修复的行为。
真实存储库，共存缺陷
该数据集包含来自 78 个开源 Python 代码库的 100 个实例，涵盖 16 个应用类别。其中记录的 531 个缺陷发生情况是按实例单独计数的，并非 531 个独立缺陷。每个实例包含 4 到 15 个共存缺陷，中位数为 5 个。
一个典型的实例包含五个文件和 11.5 个编辑块中的参考缺陷位置。产品需求文档描述了预期功能、边界条件和错误行为；参考修复和本地化目标仅供评估人员参考。
两项任务，互补措施
- 测试生成：提交一个独立的测试套件，分别在缺陷快照和修复后的快照上进行评估。头部通过率 (HP) 衡量修复后通过的测试；失败转通过率 (F2P) 衡量修复前失败、修复后通过的测试。入口覆盖率和变更聚焦覆盖率衡量的是执行范围，而非缺陷检测。
- 缺陷发现与报告：独立编写并运行探测程序，然后提交基于源代码的缺陷位置和执行证据。召回率和精确率分别在文件、函数和编辑块级别进行评分，编辑块匹配的容差为三行。
- 明确的错误定位需要匹配所有引用文件和函数符号，以及超过一半的引用编辑块。HP 统计测试次数；F2P 和大多数其他主表指标则取各实例的平均值。明确的错误率对每个可评估的错误发生赋予相同的权重。
覆盖率并不等同于缺陷检测。
在对七个评估代理进行评估后，该报告显示平均高可用性 (HP) 为 91.47%，变更导向覆盖率为 80.48%，但平均 F2P 仅为 26.36%。在对五个系统 500 次评估中注册的 49,317 个测试进行的另一项检查中，67.44% 的测试在两个快照中均通过且未暴露缺陷。该检查仅是部分测试，并非对七个代理的完整评估。
| 措施 | 报告结果 | 范围 |
|---|---|---|
| 头部通过率 | 91.47% | 7 个代理人的平均值 |
| 以变革为导向的报道 | 80.48% | 7 个代理人的平均值 |
| 不及格率 | 26.36% | 7 个代理人的平均值 |
| 文件/函数/代码块召回 | 78.11% / 51.29% / 51.88% | 7 个代理人的平均值 |
| 不同的错误已本地化 | 33.14%–49.04% | 跨代理的范围 |
| 多文件错误已本地化 | 2.00%–7.84% | 跨代理的范围 |
最大的定位差距似乎在于找到受影响的文件和隔离出问题的函数之间。多文件缺陷尤其难以处理：仅仅识别出可见的异常并不足以追踪调用者和依赖组件之间因程序错误导致的合约冲突。
积极测试是有帮助的，但也有其利弊。
一项在 100 个实例上进行的配对 GPT-5.6-Sol 实验，比较了运行现有代码库测试与根据需求编写额外测试的效果。主动编写测试分别将文件、函数和代码块的召回率提高了 4.99、2.77 和 2.69 个百分点。
收益并不均衡：三个层级的中位数配对召回率变化均为零。平均精确率也随着报告位置的增长速度超过已确认缺陷位置的增长速度而下降。这表明需要对现有测试套件之外的其他测试进行有针对性的探索，但并不能保证生成更多测试就能改进每个代理或实例。
迈向可靠的自主测试
有效的测试工程需要基于需求的断言、缺陷触发输入、跨模块调查以及严谨的证据选择。测试通过率、测试套件规模和覆盖率应与缺陷区分和精确定位能力一同评估，而不是相互替代。
目前的基准测试仅支持 Python，并根据参考缺陷映射对报告进行评分。本地化一致性并不意味着可以独立复现每份提交报告的证据；该手稿指出，未来将扩展支持其他语言并进行独立的证据验证。本页面总结了 2026 年 10 月 25 日发布的手稿，但未提供独立的结果复现或相关的公开论文/代码链接。