别把测试智能体的解释当成证据

本文是论文 (Over)Reliance on Test Agents in AI-Assisted Software Testing（arXiv:2607.17927，ORCAS 2026，与 SAFECOMP 2026 同期）正文第 1 节至第 4 节的中文译文，由智测团队翻译。作者是瑞典梅拉达伦大学的 Eduard Paul Enoiu。参考文献未逐条展开。这是一篇框架论文，没有报告新的通过率或缺陷数。

摘要

基于人工智能的测试智能体，承诺缩短持续开发里的反馈回路，并提高测试的可扩展性和可维护性。要拿到这些好处，工程师仍然必须能判断智能体的输出是否有用、有效、可靠，而不能因为它们来自一个看起来能干的系统就信以为真。本文认为，测试中对人工智能的过度依赖既是主体性问题，也是保障性问题。主体性是指工程师可能把测试设计决策上的认知控制交出去。保障性是指测试产物可能在没有充分审视的情况下被当成证据接受。论证通过三个理论镜头展开：软件测试是认知上的问题求解；测试智能体是自适应的自主实体；测试设计论证用来让生成的测试可以被评审。作者提出一套在测试智能体工作流里收集过度依赖数据的框架，并指出若干具体的过度依赖模式。目标是加快测试，同时不削弱判断，也不削弱测试证据的保障价值。

1 引言

现代由人工智能辅助的软件开发，带来快速的代码变更和大量测试产物，加重了软件工程师的认知负荷。这种规模和速度，使监督、质量评估和稳健决策变难，而对可靠性的期望仍然高。眼下的挑战是：在软件测试中使用人工智能智能体时，测试仍然要支持人的理解和判断。先前工作在回归测试选择里提出了测试智能体和自适应自主，认为测试选择和调度可以从分散控制中受益。一项关于软件测试自动化伦理挑战的近期研究，把可解释性、日志与监控、隐私、技术风险和人的控制，列为把人工智能引进测试自动化时的中心关切。这给软件测试提出一个具体问题：当大模型解释它生成的测试时，工程师是把那些解释当成待检查的假设，还是当成可以接受的保障。

让测试智能体有用的能力，同时也制造风险。如果一个测试智能体能生成测试、解释它们为什么存在、汇总执行结果、把子任务委派给其他智能体，并在软件变更后重新生成自己，测试人员的角色就变了。人变成（半）自主工作的监督者。对测试智能体的过度依赖，会通过削弱「凭什么有信心」的那份证据，间接削弱人的监督。

本文的贡献如下。它把对测试智能体的过度依赖框成监督控制问题和保障问题，并用三个理论镜头展开：软件测试作为认知问题求解，测试智能体作为自适应自主的测试产物，以及测试设计论证，用来让生成的测试更容易被评审。最后，它提出一套针对人工智能辅助软件测试的过度依赖模式分类，并勾勒对测试智能体工作流和经验研究的含义。

2 相关工作与理论镜头

自动测试生成已经用在安全关键开发里，例如工业控制软件。若干研究表明，自动测试生成往往比手工测试更有效率，但在发现自然发生的缺陷上，仍然不如有经验的工程师做的手工测试设计有效。

关于软件测试认知基础的研究，关注测试人员的常规和问题求解。合在一起，这些结果说明：测试设计依赖目标形成、测试设计方法的选择，以及目标表征和基于上下文的启发式。这些很少被当前的自动化方法抓住。这个认知视角是本文的中心。

一篇综述发现，自动化偏差在测试实践里是明显的，因此过度依赖特别值得关注。确认偏差和锚定似乎也存在于实践中，所以在测试设计和评审里研究过度依赖尤其重要。这个框架建立在经典自动化文献上：自动化可以提高表现、减少人在监视中的参与，从而在出问题时让干预更难。

在安全关键软件开发里，测试可以通过验证证据和保障实践，为关于系统行为和发布就绪的主张作贡献。文中点名的实践包括 ISO 26262、EN 50128，以及目标结构化记号 GSN。

图 1 从集中式回归测试（a）走到受监督的测试智能体工作流（b）。图中放进智能体内部的问题求解模型，是为了标明：为了依赖得正当，智能体行为的哪些要素必须仍然可检查。

2.1 从测试用例到测试智能体

在测试智能体自适应自主这一概念上，可以把软件测试智能体看成能按测试上下文、可用信息和观察到的系统条件调整自主程度。不必靠一个集中机制决定选哪些用例、如何排优先级，而可以靠智能体之间的分散协调。如图 1，这允许单个智能体 A、B、C 或 D 做局部决策，需要时与其他智能体交互，并调整自己的行为。传统的自动测试用例通常是静态产物。它们包含输入值、期望结果和可执行脚本，由外围的回归测试系统来选择、调度和排优先级。测试智能体的设想则相反：测试用例能够推理、适应、交互，并随时间更新自己的行为。测试智能体打算把回归测试分散化，让测试知道何时执行、如何调整目的，以及何时与其他测试交互。

为避免把「测试智能体」当成任何人工智能工具的松散说法，本文采用与先前测试智能体和基于智能体的软件测试工作一致的定义。

定义（测试智能体）。测试智能体是嵌入测试工作流的自主或半自主软件智能体。它能观察被测系统及其测试环境中的变化，维持显式的测试目标，生成、选择或执行测试产物，与其他智能体或人交互，并产出与保障相关的证据。

这改变了工程师必须评审的东西。测试用例变成测试工作流里一个部分自主的实体。更早的测试智能体工作描述过空闲、交互、执行、重新生成、故障等状态。测试智能体可以执行自己的任务、请求协助、响应另一个智能体，或在原目的不再成立时，在测试工程师帮助下重新生成。交互可以包括：不作承诺的信息共享、一对一对话、一对一委派，以及一对多的对话或委派。例如多个智能体围绕覆盖、执行时间或缺陷历史进行协调。这意味着测试智能体跨好几层测试工作运转。它们可以生成测试、评估结果、交换证据、委派目标、监视变更，并改变未来的测试执行。用半可执行产物的语言来说，这类工作流把可执行代码、提示、智能体工作流、评测框架、策略和人的判断合在一起。Feldt 等人的半可执行栈把它们描述为：行为一部分取决于确定性执行，一部分取决于人的解释。

2.2 认知问题求解与论证

要理解测试中的过度依赖，先要理解人类测试人员在做什么。软件测试不只是产出测试输入或执行脚本。它是一种认知上的问题求解活动。测试人员解释需求、推断风险、形成测试目标、选择技术、构造用例、判断充分性、评估结果，并把含义传达给别人。图 1 里测试智能体 E 的内部画出了这些。人工智能辅助的测试会改变这个认知结构。它既可以支持，也可以替换测试人员推理过程的一部分。模型可以提出测试目标、生成具体测试、陈述该测试支持的主张、给出理由、指出证据、汇总执行，并建议一套测试是否充分。过度依赖可以发生在：工程师不再把这些输出当成待检查的假设，而开始把它们当成待接受的证据。在关于人工智能辅助测试生成的互补工作里，生成的测试可以通过测试论证，关联到显式的测试目标、主张、理由和证据。这些结果与过度依赖相关，因为它们为可论证、可检查的人工智能辅助测试提供了最初的概念基础。

3 研究测试智能体过度依赖的框架

这一节把理论镜头收成一个概念框架。它解释为什么转向测试智能体，会使过度依赖同时成为监督控制问题和保障问题；并描述一套数据收集设置，用来分析测试智能体如何被实现、使用、评估和修订。最后，它指出测试特有的过度依赖模式，可以作为设计测试智能体工作流的检查单。

3.1 作为监督控制与保障问题的过度依赖

关于伦理的人工智能测试自动化的先前工作，把人的控制与责任当作中心关切：人如何保持控制，如何与自动化交互，如何发现不充分的表现，以及自动化表现不足时谁负责。同一项工作明确提出过度信任，以及测试自动化中有缺陷的决策支持等风险。

测试智能体会放大这些风险。静态生成的测试可以被检查。测试智能体能跨时间行动。它可以改变状态、请求帮助、委派子任务、重新生成，并产出产物和摘要。人类监督者因此必须理解它为什么如此行动、用了哪些证据，以及何时应当质疑它的结果。

测试也是一种保障活动。它支持关于软件行为、质量、风险和发布就绪的主张。在受监管和安全关键的场景里，测试证据常常贡献给更大的质量保障。关于测试设计论证的先前工作指出：受监管领域要求证据表明测试达到了完整性和认证目标；论证可以组织主张、策略和支持证据，即使对单个测试用例的设计也是如此。在人工智能辅助的测试里，过度依赖可能意味着：把智能体产出的测试产物、论证、摘要、委派或重新生成的测试套件当成保障接受，而没有充分质疑它们的论证。

3.2 为过度依赖收集数据

图 2 是研究「意识到过度依赖」的测试智能体的概念框架。它把理论镜头、自适应且可论证的测试智能体的实现，以及在开源和工业场景中的经验评估连在一起。

图 2 概括了为未来数据收集所建议的步骤。在测试智能体自适应自主的概念上，软件测试智能体可以按测试上下文、可用信息和观察到的系统条件调整自主程度。测试设计的认知模型和自适应测试智能体，可以被操作化成可论证的测试智能体。这些智能体打算抓住熟练人类测试的特征：追求显式测试目标，按当下情境调整自主程度，需要时与其他智能体和人类工程师交互，并通过显式论证让推理可见。这可以落实为：自适应测试智能体维持对目标、理由、主张、假设和支持证据的显式表示。

方法上，图 2 的框架可以操作化成一个迭代回路：收集数据并建模测试智能体行为，把相关构念操作化，应用该工作流，测量测试效率、有效性和依赖结果，再用结果反过来告知框架。经验研究应把开源系统与工业规模软件结合起来，并使用带有已知、自然发生缺陷的软件版本。

依赖的度量可以包括：接受不正确主张的情况、被质疑的输出的频率、检查证据的行为、人的覆盖决定，以及发现丢失的测试目标。结果可以用来迭代精炼过度依赖的模式和风险，走向一个更新后的测试智能体依赖模型。

表 1 把过度依赖模式和它们在人工智能辅助软件测试中的风险放在一起。

3.3 人工智能辅助测试设计中的过度依赖模式

这一节把上述提议用到收集数据上，对象是测试设计和测试智能体的概念视图。表 1 概括过度依赖可能发生的位置，以及它在软件测试中可能造成的风险。过度依赖可以出现在测试人员问题求解过程的不同点上：从接受智能体的测试目标或策略，到信任它的主张、证据、执行、预言、被委派的子任务和重新生成。这被当作识别过度依赖的初始检查单。分析使用问题求解镜头和测试智能体视角，但只是作者视角下的部分视图。没有案例研究证据时，关于过度依赖的主张仍然是解释性的。尽管如此，从测试智能体、问题求解和测试论证这些镜头看，软件测试上的过度依赖有彼此不同的形式。

示例场景。考虑需求变更之后的一套工业控制系统。测试智能体 A 检测到变更，重新生成边界测试，再把输入交互检查委派给测试智能体 B。智能体 B 报告没有失败，但它的证据只覆盖单次交互情形。测试智能体 C 标出：一个重要的交互场景仍然没测。此时，重新生成的测试被假定为保住了先前意图，有限证据被当成充分，委派出去的工作被信任得过宽，而一份摘要藏起了一个未测场景。

4 结论与局限

本文认为，对测试智能体的过度依赖，在人工智能辅助的软件测试里应被理解为主体性、监督控制和保障问题。把软件测试看成认知问题求解，可以看出智能体式人工智能如何把人的工作从直接的测试设计，转到对测试智能体的监督。这一转移造出测试特有的过度依赖模式，包括对目标、策略、论证、预言、委派、重新生成和维护的过度依赖。所提出的模式应被当作一份工作中的分类。未来工作应在开源和工业场景中研究这些模式，发展对依赖和质量的度量，并评估工作流机制。

致谢。本工作由 Software Center、MONA LISA 和 MATISSE（101140216）项目以及 AI and Society Fellowship 支持。