用 AI 提升测试工程师素养：从操作页面到验证业务

AI 可以帮助我们填写表单、寻找元素、生成脚本，但测试工程师的价值在于判断：应该测什么，什么结果才正确，现有证据能否支持结论，以及失败暴露了什么问题。

使用 TestDog 时，可以把每次生成看作一次协作：你提供业务目标和验收依据，AI 执行并收集结果，你审核测试是否有效，再通过回放把这份判断变成可重复的验证。节省下来的操作时间，应该投入到测试设计和问题分析中。

本文以“新增客户”为例，介绍如何在日常使用中训练这些能力。文中的客户字段和业务规则仅作示例，使用时请换成自己项目的真实要求。

一、先说明要证明什么，再安排点击什么

“打开客户管理，点击新增，填写信息，点击保存”描述了一条操作路线，但没有定义正确结果。即使页面弹出成功提示，客户也可能没有保存，或者手机号保存错了。

更完整的测试需求应该同时说明前置条件、输入约束和预期结果：

验证有新增权限的用户能够创建客户，且保存后的信息正确。

前置条件：使用有新增权限的登录配置，进入客户管理页面。
数据：客户名使用本次运行的唯一名称，手机号使用合法测试数据。
步骤：新增客户，填写名称和手机号，保存。
验收：定位到本次创建的客户，在该记录内验证名称和手机号；
      刷新页面后，重新查找并验证该客户仍然存在。
依据：需求规定保存后的客户应持久化，并在客户列表展示。
清理：验证后按项目约定清理本次创建的客户，不影响其他记录。

在 TestDog 的 AI 生成脚本 页面提交需求后，认真检查计划确认弹窗中的“测试意图与验收约定”：

需要审核的项目	工程师应该问的问题
场景类型	这是验证成功、验证拒绝，还是包含多个场景？
前置条件	账号权限、登录状态和依赖数据是否满足？
测试数据约束	哪些值必须固定，哪些允许生成？
验收目标	结果是否具体，验证范围是否指向正确记录？
验收依据	来自需求、接口契约或已确认规则，还是 AI 的猜测？
必验项	哪些结果没有验证，就不能认为测试完成？
清理要求	测试留下什么数据，何时清理，由谁执行？

页面当前表现是实际结果，需求和已确认的规则才是判断依据。 如果需求没有说明“是否允许重复手机号”，先澄清规则。不能因为页面允许提交，就把“允许重复”写成正确预期。

一个实用练习是：每写一条用例，先用一句话说明“这条用例要发现哪类错误”。如果只能回答“看看能不能点”，就继续补充验收目标。

二、保护测试意图，尤其是负向测试

经验丰富的工程师会区分“阻碍测试的数据问题”和“正在验证的错误输入”。同样是手机号重复，两种场景的处理完全不同：

场景	合理处理
验证正常新增，但旧数据占用了手机号	在允许生成数据的约束下，更换数据再验证
验证重复手机号应被拒绝	保留重复号码，检查拒绝结果和数据未新增

对于第二种场景，可以这样描述需求：

验证系统拒绝新增使用已有手机号的客户。
前置条件：已有客户使用项目环境变量中的“已有手机号”。
手机号为固定值，不得为了提交成功而更换。
其他必填字段使用合法数据，确保本次只验证手机号重复规则。
提交后验证明确的重复提示，并核对没有创建本次尝试的新客户。
不要删除本次失败提交和拒绝断言，它们是必要测试步骤。

在确认弹窗中将手机号设为“固定值”，将拒绝结果列为必验目标。负向测试中，产品按预期拒绝输入，测试应当通过；产品意外接受输入，测试才应该失败。

设计用例时，也可以围绕同一业务规则补充边界值、必填缺失、权限差异和状态转换场景。每条用例尽量有明确的失败原因，避免同时填错多个字段，最后只验证到第一个错误提示。

三、学习前端知识，是为了理解状态和定位原因

掌握前端知识，有助于解释“为什么这个操作没有产生预期结果”。不必一开始就熟悉整个框架，可以先理解以下几类现象：

页面现象	可能原因	优先检查的证据
按钮看得到却点不了	禁用、加载中、被浮层遮挡	按钮状态、遮挡区域、加载提示
输入后值消失或回滚	字段联动、输入格式处理、异步状态覆盖	操作前后的值、校验提示、相关请求
下拉框不能直接输入	自定义组件，触发器不是输入框	展开的选项、搜索框、组件交互方式
搜索后暂时没有结果	防抖、请求未完成、结果未渲染	请求时间、响应内容、加载状态
列表中找不到记录	分页、筛选、虚拟滚动或数据未保存	当前筛选、分页范围、列表响应
保存后弹窗仍在	表单校验、接口失败或页面未更新	字段错误、本次提交请求和页面反馈

这些都是待验证的假设。比如“选择子字段后父字段被清空”，既可能是正常联动，也可能是产品缺陷，不能只凭这一现象就认定用户选错了。

在 TestDog 中，先查看生成轨迹里的快照、动作结果和接口信息；回放失败时，再查看运行明细中的截图、console 与 network 记录。必要时用浏览器开发者工具补充检查 DOM、计算样式、事件和请求时序。具体入口见 生成记录 与 运行记录。

检查 DOM 和框架行为时，应保持真实用户交互路径。直接修改页面内部状态、移除禁用属性或绕过表单校验，即使能让流程继续，也无法证明普通用户可以完成操作。若需要这种方式准备测试数据，应作为独立的准备过程说明，不能冒充被测操作成功。

四、用有区分力的断言证明结果

一个好断言应该能够区分“业务正确”和“看上去成功”。写完断言后，反问自己：如果产品没有真正完成这件事，这条断言还有可能通过吗？

例如，只检查整页出现“张三”，可能命中旧客户；只检查“保存成功”，可能漏掉持久化失败；只检查列表数量大于零，可能完全没有验证本次新增。

在 TestDog 的计划中，把断言关联到对应验收目标，并核对定位范围、断言类型和预期值：

要证明的结果	可采用的验证方式
某个客户的手机号正确	唯一定位该客户，再对其手机号单元格使用 text_exact
表单回显正确	对相应输入框使用 value
选项状态正确	使用 checked / unchecked
控件按规则禁用	使用 disabled，并明确这一规则的前置条件
指定记录不存在	对稳定、准确的记录定位使用 count = 0
保存结果持久化	刷新或重新进入页面后，再对同一记录执行断言

注意断言自身的含义：text 是包含匹配，text_exact 是规范化空白后全文相等；count 统计匹配节点，包括隐藏节点。在分页或虚拟列表中，“当前 DOM 没有该记录”不能直接证明“系统中不存在该记录”，应先通过准确查询或适用的接口验证缩小范围。

浏览器断言会在超时预算内自动重试。优先等待明确结果，不要随意增加几秒固定等待去掩盖不稳定。断言类型和完成规则见 AI 生成脚本。

当前工具要求所有必验目标都有实际通过的断言证据，才能完成生成。这可以防止漏验，但验收目标本身是否正确、是否覆盖了关键风险，仍然需要工程师审核。

五、失败时先取证，再决定修哪里

看到红色失败结果时，不要立即修改脚本。先将问题整理成四句话：

预期：依据哪条需求，在什么条件下应该出现什么结果。
实际：执行了什么，页面和数据实际发生了什么。
证据：对应的步骤、输入、截图、请求响应和错误日志。
判断：目前支持哪种解释，还有什么证据缺失。

以“提交后列表没有新客户”为例，应先定位本次提交对应的请求，核对请求参数、状态码和响应体，再检查列表是否刷新、筛选条件是否排除了新记录。HTTP 200 不等于业务成功，响应体中的成功字段也不能独立证明界面和数据都正确。接口与页面都是证据，应共同对照验收依据。

根据证据决定下一步：

判断	下一步
脚本定位错误或操作方式不匹配	修正定位或交互，重新验证原目标
登录过期、权限不足或依赖数据缺失	恢复前置条件后重跑
实际行为违背明确需求	保留失败证据，提交缺陷并建立复现用例
需求不明确或证据不足	记录疑问，补充信息后再下结论

生成挂起求助时，优先给出具体补充，例如“当前客户在第二页”或“这个账号没有新增权限”。“AI 修复”适合重新定位，“改述”用于澄清意图，“手动接管”后仍要验证业务结果。“跳过”意味着该目标没有验证，不能把它写进已通过结论。

TestDog 不对失败断言进行 AI 自愈，避免把真实问题改成通过。动作定位自愈后也应核对是否操作了正确对象，再决定是否采纳回写。

发现真实缺陷，是一次有价值的测试产出。 当前生成流程遇到必验断言失败时不能报告完整完成；应保留已有步骤和日志，记录缺陷，修复后再续跑或回放。不要为了获得“完成”状态而降低验收标准。

六、让脚本能够重复运行，并且值得维护

一次成功执行只能说明当时的环境和数据下能够走通。稳定的回归还需要管理登录、数据、版本和清理。

在项目中维护适合该场景的登录配置和环境变量。正向造数可以使用系统变量；同一次运行中，同名变量保持一致，因此填写和断言应引用同一个变量。例如：

客户名：测试客户_{{systemTime}}
手机号：{{randomPhone}}
后续定位与断言继续引用上述变量。

随机生成并不保证满足所有业务规则，也不保证绝无碰撞。对于固定长度、号段限制或必须预先存在的数据，应按项目规则准备。相关用法见 测试数据与登录态。

保存脚本后，通过“运行当前版本”验证回放，并核对以下问题：

• 是否依赖生成时偶然留下的登录状态、页面位置或测试数据？
• 是否准确定位本次记录，避免命中同名旧数据？
• 必要的刷新、重复操作和负向提交是否完整保留？
• 清理是否实际完成，是否会破坏其他用例依赖的数据？
• 自愈是否频繁发生，是否需要重新审视定位和页面结构？

对已经验证稳定的脚本，日常回归优先使用 回放运行。确定性回放无需调用模型；需要定位自愈时才会产生相应模型消耗。查看生成记录中的重复观察和失败重试，往往还能发现需求描述或前置条件不清楚的问题，减少后续生成的 token 消耗。

七、用复盘衡量成长，而不是只数用例数量

可以每周挑选一条生成成功的用例、一条失败用例和一条频繁自愈的用例，分别复盘：

1. 成功用例的断言，能否识别“提示成功但数据没保存”这类缺陷？
2. 失败用例是否有足够证据，能让另一位工程师独立复现和判断？
3. 频繁自愈是否源于定位不稳定、环境变化或测试设计过度耦合？

在隔离的练习页面中，还可以预先设置几种已知错误：错误手机号被接受、保存后数据丢失、失败响应被显示为成功。观察现有用例能否检出，并据此改进断言。不要在共享环境中随意修改产品行为来做练习。

衡量效果时，关注关键风险覆盖、真实缺陷检出、错误放行、重复运行稳定性，以及每条有效用例的生成和维护成本。通过率升高有时只是断言变弱；用例数量增加，也不一定增加了有价值的覆盖。

持续练习把需求写成可验证的约定，把页面现象解释成可检验的假设，把执行结果整理成可复核的证据，AI 才会成为提升专业判断力的助手。下一次打开 TestDog 的计划确认弹窗时，先检查：这份计划究竟能证明什么？