有效管理 AI Agents 以进行测试

发布: 11小时前 (2025年12月18日 GMT+8 10:23)

13 min read

Source: Dev.to

大型语言模型和 AI 代理已经改变了许多领域，并以根本性的方式改变了我们的生活。在 测试领域，AI 代理有明确的路径可以在流程和质量上实现即时改进，最终产出可靠、高性能、安全且合规的软件。查看 《揭开代理式测试自动化的神秘面纱：对 QA 团队的意义》。

但如何利用这些能力并不明显。虽然 AI 代理并非完全可预测，但可以通过稳健的控制机制可靠地进行管理。让我们看看如何做到。

管理 QA 中的 AI 代理意味着什么？

在一般情况下以及在测试领域，管理 AI 代理有几个重要方面。

配置和防护措施

设置代理的自主水平和边界。
通过提示和约束定义测试目标。
指定哪些领域需要人工批准。

这些步骤确保系统在受控参数范围内运行，同时实现目标。

示例： 你可以允许你的代理式 AI 系统编写测试代码并生成跟踪/报告工件，但不允许它修改生产代码。

模型选择与更新

决定何时升级模型以及何时保持稳定。
在将模型更改推向生产之前进行测试，以避免意外问题。

如果在模型升级后测试质量和覆盖率下降，这表明你的 AI 代理过度依赖特定模型版本。

监督与验证

实施质量门和验证协议。
监控易失性测试和低价值覆盖。
管理执行成本预算。

这些做法有助于在整个开发生命周期中保持测试的可靠性和成本效益。

实际管理 AI 代理的方式

考虑到这些方面，让我们看看控制代理的具体步骤。

1. 配置代理系统提示

“您可以为 /checkout 和 /payment 流程生成 API 和 UI 测试代码。
您可以创建测试报告并更新跟踪仪表板。
您不得 修改生产代码或数据库模式。
所有破坏性操作（删除测试、更改 CI/CD 流水线）都需要人工批准。”

2. 工具集成

通过 API 将您的代理连接到测试管理平台，以便它能够读取现有测试用例并了解覆盖缺口。

选项包括类似 Tosca MCP server 的 MCP 服务器，或您自行构建的 自定义工具（Model Context Protocol 文档）。

3. 渐进式推出

周	活动
第 1 周	代理仅在建议模式下生成测试。
第 2‑3 周	代理在隔离的预演环境中执行测试。
第 4 周及以后	代理在预生产环境中运行测试，失败由人工审查。

4. 设置质量门槛

在 CI/CD 流水线中添加检查，要求最低通过率（例如 80 %），在代理生成的测试能够阻止部署之前。
每周监控误报率，并相应调整提示。

如何控制 AI 代理：提示、工具和反馈回路

学习控制你的代理至关重要。与普遍看法相反，AI 代理并不具备真正的智能或自主性。它们最好的理解方式是：

系统提示（即“代理”定义）
状态 / 记忆
一组工具

所有智能都存在于大语言模型（LLM）中，LLM 接收系统提示、工具和用户提示作为上下文，决定调用哪些工具，并迭代直至生成最终答案。

控制的三个主要杠杆：

提示工程

编写清晰的测试目标和验收标准。
构建经过验证的提示库。
根据代理的输出进行迭代。

精心设计的提示可以引导代理提供精准、实用的结果。

工具集成

使用 MCP 服务器或类似方案将代理连接到源码管理、设计文档和 CI/CD 流水线。
利用 Applitools（视觉 AI 测试）、Katalon Studio（无代码自动化）或带有 AI 扩展的 Selenium，提供不同层次的自主性和控制。

性能监控与反馈回路

跟踪指标：覆盖率、缺陷检测、误报、维护时间。
实施实时监控和告警。
当指标出现漂移时，重新配置或重新训练代理。

如何从传统测试迁移到代理式 AI 测试

从传统测试向代理式 AI 测试的转变因组织的现有流程、工具链和成熟度而异。迁移通常遵循以下阶段：

评估 – 确定当前测试的缺口并定义 AI 增强测试的成功标准。
试点 – 使用上文描述的 “建议模式” 进行小规模概念验证。
增量 rollout – 逐步扩大自主性和覆盖范围，采用渐进式 rollout 模式。
治理 – 将提示、护栏和质量门作为标准测试工作流的一部分制度化。
持续改进 – 利用监控数据优化提示、更新模型并演进工具集成。

通过将 AI 代理视为可控组件——可提示、可工具化、并持续监控——可以在保持风险、成本和质量可控的前提下，发挥其强大能力。

组织层面的考虑

现有自动化：让代理式 AI 测试与传统脚本并行运行，采用渐进式迁移策略，随着信心提升逐步增加自主性。
手动测试占比较大的团队：从低风险回归套件入手，将部落知识编码为可重复的测试，并将 QA 的关注点从脚本维护转向监督自主代理。

实际集成通常采用混合测试方法，结合手动、AI 辅助和完整代理式三种方式。像 Tricentis Tosca 和 qTest 等平台能够在这些方法之间实现统一管理。

示例：将传统测试演进为代理式方法

传统 Selenium 测试（手动脚本）

driver.findElement(By.id("username")).sendKeys("test@example.com");

问题：当 UI 发生变化（例如 ID 变为基于 class 的选择器）时，测试会失效。每次定位器变化都需要手动更新，且动态 UI（如 A/B 测试）会带来大量维护工作和错误风险。

AI 辅助测试（例如 Tricentis Tosca 或 mabl）

QA 通过可视化测试构建器记录用户操作。
自愈定位器自动适应轻微的 UI 变化。
仍需人工介入进行测试设计和断言逻辑。

完整代理式 AI 测试

QA 提供高层意图：
“使用有效和无效凭证、边缘情况以及安全场景测试登录流程。”
代理自主发现 UI 元素、生成测试用例并创建断言。
它能够自适应 UI 变化并在无需人工干预的情况下重构测试逻辑。
它从失败中学习，实时调整测试策略。

关键洞见：传统测试需要持续的开发者/QA 时间投入。代理式 AI 将工作重点从执行和维护转向战略监督和提示工程。

代理式 AI 测试的常见挑战

校准信任 – 渐进式推行至关重要。逐步引入 AI 代理，在受限范围内验证其行为，并随着对真实结果和监控性能的信心提升，逐步扩大其职责。
不稳定的测试 – 这些会削弱信任并增加维护成本。有效策略包括：
- 隔离不稳定的场景。
- 标记并隔离不稳定测试。
- 使用 AI 代理发现失败模式，以便团队加强这些区域。
成本控制与覆盖去重 – 持续剔除冗余场景，确保新增覆盖能够带来增量价值，而不是仅仅增加执行开支。
保持明确的责任归属 – 即使代理生成、执行和更新测试，质量保证团队仍必须拥有所有代理输出，并对最终发布的内容拥有最终决策权。建立评审工作流、审计追踪和签署检查点，以确保自主活动始终伴随人工监督。

AI 可以协助：多代理评审（例如，三个评审代理就发现进行辩论，达成一致后向人工提供精炼报告进行最终检查）。

终局愿景 – 将代理式 AI 测试直接集成到软件开发生命周期中，使代理不仅测试人类编写的代码，还作为多代理 AI 开发团队的一部分运作：

AI 工程师编写代码。
AI 测试员为该代码开发并执行测试。
双方迭代直至任务完成。

结论

向代理式 AI 迁移的关键要点

从低自治度和受限范围开始。
使用 MCP/工具为代理提供上下文但不授予生产写入权限。
跟踪失败率、覆盖率和成本。
仅在可靠性得到验证后才扩大自治度。

管理用于测试的代理式 AI 将焦点从传统脚本维护转向战略监督。质量保证团队必须接受新的思维方式：他们引导、监控并优化自主代理，而不是手动更新脚本。

入门指南

从小处开始——在低风险场景中验证 AI 代理。
随着信心提升，逐步扩大范围。
遵循最佳实践并利用可靠工具。

通过这样做，质量保证团队可以改造测试流程，加速发布，并提升整体软件质量。

祝您有美好的一天！