把 AI 用进真实测试：将 Agent 应用于复杂业务 UI 测试

我持续将 AI 引入接口回归、数据库核对、文档巡检和复杂业务 UI 测试，并将测试方法整理为 Agent 可读取、可执行、可复用的数字测试资产。

1. 我解决了什么

在实际项目中，AI 已经参与了多类测试任务：

• 自动化执行： Agent 执行接口测试、数据核对、文档巡检及部分 UI 操作。
• 业务理解： 与 AI 结对探索陌生系统，辅助分析业务规则、字段依赖和流程状态。
• 结果验证： 结合接口响应、数据库、业务状态和跨系统结果进行多层核对。
• 资产沉淀： 将测试规则、Case、样本、执行入口和证据整理为可复用资产，支持后续任务接手。

这套工作方式已经在多个项目和测试场景中实践。最近，我又将其扩展到了多角色、跨系统的复杂政务审批业务。

2. 已有的 AI 测试实践

我的 AI 测试实践覆盖多个层次。

测试场景	实践内容
接口自动化	Agent 分析接口约束，设计并执行功能、边界、异常测试，结合接口与数据库验证结果
数据一致性	对比接口查询结果与数据库数据，核对列表集合、统计指标和关联业务数据
文档回归	AI 巡检接口文档，检查链接、参数说明、示例代码及跨页面一致性
语音与多模态接口	组织回归样本，使用 curl、pytest、场景 Runner 等执行测试并汇总证据
模型质量评测	对 ASR 和翻译结果计算客观指标，引入 LLM 辅助分析问题样本，人工复核关键问题
复杂业务 UI	AI 准备数据、填写表单、重开业务记录、查询前后账，人工接管关键操作和验收

此外，我也参与了大模型容量测试工程化实践，通过 Locust、EvalScope 等工具开展容量矩阵测试、指标对比和自动探测方案验证。

不同场景采用不同工具和执行方式，但使用相同的测试工程原则：明确验证目标、约束执行过程、保留结果证据、复核关键结论。

3. 将 Agent 应用于复杂业务 UI 测试

此前的 Agent 测试主要集中在接口、数据与文档层。这些测试具有相对明确的输入、输出和执行入口，容易形成可重复执行的任务。

复杂业务 UI 增加了新的挑战：

1. 多角色与审批流转： 不同节点涉及不同权限和操作人员。
2. 字段依赖与页面联动： 上游字段变化可能影响后续选项及已填写的数据。
3. 执行稳定性： 浏览器操作可能受到页面状态、身份验证和动态控件影响。
4. 结果验证： 需要结合页面、业务数据、跨系统状态和生成文书综合判断。

因此，我采用小任务、人机交接的协作方式。

我怎么做

阶段	AI 参与内容	我的工作
业务分析	整理规则、字段依赖、流程节点	确认业务口径与风险优先级
测试准备	查找基线数据、准备样本和测试条件	确定目标场景及预期结果
UI 执行	填写表单、读取页面、复核字段	处理身份校验、角色切换和关键审批
结果验证	重开同一业务记录、查询数据、计算差异	判断证据是否支持测试结论
资产沉淀	整理操作记录、截图、结果和待办	确认缺陷、更新规则及回归范围

每次交给 AI 的任务都包含明确的执行目标、前置条件、预期结果和交接点。遇到操作异常或复杂审批时，我可以直接接管，完成后再交还给 AI 继续验证。

4. AI 结对探索陌生业务

这次实践还有一个很有价值的场景：我开始参与测试时，接触被测系统只有三四天。

系统涉及多个审批角色、复杂表单、状态流转和跨平台业务。在执行过程中，我会持续与 AI 核对：

• 当前页面处于哪个业务阶段；
• 字段之间存在哪些依赖关系；
• 操作完成后应该检查什么；
• 当前结果能否满足原定测试目标；
• 下一步需要补充哪些验证。

AI 根据已有资料、当前页面和历史执行记录提供分析与建议，我再通过真实系统进行核实。

例如，遇到表单校验异常时，我会先分析当前错误对应哪个校验环节，再决定是否继续验证后面的目标规则。遇到审批流程时，则结合业务状态和数据变化，逐步建立对整条链路的理解。

这种结对方式帮助我在执行测试的同时持续熟悉业务，并将新确认的字段关系、流程规则和操作经验沉淀下来。

5. 两个实际执行案例

以下案例来自 2026 年 10 月的一次历史测试实践。

案例一：业务阈值校验与提交后复核

测试目标

验证某人工商品林抚育透光伐场景下，伐后郁闭度低于 0.5 时是否正确拦截。

字段	测试值
伐前郁闭度	0.60
伐后郁闭度	0.49
预期	不允许提交

执行过程

1. AI 基于合法样本准备数据，完成页面填写。
2. 提交时出现证件校验提示，先处理该前置条件。
3. AI 重新核对目标字段，确认 0.60、0.49 未被页面联动覆盖。
4. 继续执行申请操作，系统允许提交。
5. 从受理列表重新定位并打开同一条业务记录。
6. 再次确认伐后郁闭度仍为 0.49。

执行结果

本应被拦截的数据进入了业务流程，提交后重开仍保留问题值，补充形成了业务规则缺陷的证据。

这个案例使用了控制变量、前置条件排查、独立重开和持久化复核等方法，避免将其他校验环节的结果误判为目标 Case 通过。

案例二：人工审批与 AI 额度对账

测试目标

核对一笔 10m³ 申请在审批前后的额度变化。

执行过程

人工完成关键审批操作，AI 负责查询同一额度维度的前后数据，并计算差异。

字段	审批前	审批后	变化
总配额	260	260	0
已用额度	237.0257	247.0257	+10
剩余额度	22.9743	12.9743	-10

执行结果

已用额度增加 10m³，剩余额度减少 10m³，与申请量一致。该额度对账子项验证通过。完整发证、回传及业务办结仍按各自验收节点继续检查。

本次记录未取得关联流水和受理时的即时账，无法确定扣减的准确时点，也不能排除期间存在其他并行冲抵。

在这类测试中，我将审批操作、查询核对和结果判断分开安排，发挥 AI 在重复查询、计算和证据整理方面的作用。

6. 测试资产如何持续复用

为了让 Agent 更快接手新的测试任务，我将数字测试资产按功能组织：

资产类别	主要内容
docs	测试规则、接口说明、领域知识、执行规范
scripts	测试脚本、工具入口、场景 Runner
resources	测试数据、音频样本、截图等资源
results	测试报告、日志、差异结果、历史证据

在复杂 UI 场景中，进一步补充业务流程、字段规则、测试样本、操作交接和证据索引。执行中发现的新规则经过核对后再回填资产，形成持续迭代的过程：

业务分析 → 测试设计 → Agent 执行 → 结果复核 → 资产更新 → 后续复用

经过多轮实践，这套方式已经覆盖接口、数据库、文档以及部分复杂 UI 测试任务，并为后续自动化扩展提供了基础。

7. 我的实践总结

目前，我主要沿着两个方向推进 AI 测试工程化：

一是扩大 AI 能够实际执行的测试范围。 将接口、数据、文档和 UI 测试中的可执行任务交给 Agent，通过明确的规则、工具入口和交接机制，逐步扩展应用场景。

二是利用 AI 提升业务探索和测试资产复用能力。 在陌生系统中，通过结对分析、现场执行和持续核对建立业务认知，再将验证过的规则、测试数据、执行过程和证据保留下来。

后续我会继续关注复杂 UI 的执行稳定性、Agent 可复用能力，以及测试结果的自动验证。

当前实践的目标是建立一套：

AI 可执行、人工可接管、结果可验证、测试资产可复用的质量工程工作方式。

查看我的测试开发简历 · 接口与多模态回归 · 数字测试资产库