本文整理自 TestDog 文档的《用 AI 提升测试工程师素养》一章，例子里的客户字段和业务规则仅作示例。

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

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

下面以「新增客户」为例，说说这些能力平时怎么练。

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

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

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

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

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

在工具里提交需求后，别急着点生成，先认真看计划确认弹窗里的「测试意图与验收约定」：

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

同一个弹窗在深色模式下也是这个结构。下面是一条更完整的 CRM 计划（8 步），能看清「测试数据约束」里每个字段的取值策略，以及「验收目标」里被标成必验的那一条：

图里有三个细节值得注意：

• 「固定值，不自动修改」 = 每次都用这个常量，不允许执行器改写（「所属客户=云启信息科技有限公司」「互动类型=电话」「持续时长=30」都是这样）；
• 「允许生成测试数据」 只给了标题一列，用 ${randomNumber[:6]} 造唯一标题，方便后续定位、避免重名；
• 验收目标 C1 标了「必验」，断言的期望值锚定「本次生成的那条记录」，而不是「列表里有没有类似的记录」，右侧还保留了「用户需求」作为来源溯源。

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

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

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

老手会区分「阻碍测试的数据问题」和「正在验证的错误输入」。同样是手机号重复，两种场景处理完全相反：

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

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

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

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

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

三、懂点前端，是为了解释「为什么没出预期结果」

不必一开始就熟悉整个框架，先能解释这几类现象就够了：

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

关键在最后一句：这些都是待验证的假设。比如「选完子字段父字段被清空」，可能是正常联动，也可能是产品缺陷 —— 不能只凭这个现象就认定用户选错了。

工具里先看生成轨迹的快照、动作结果和接口信息：

回放失败时再看运行明细里的截图、console 与 network。必要时用浏览器开发者工具补查 DOM、计算样式、事件和请求时序。

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

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

好断言的标准：能区分「业务正确」和「看上去成功」。写完反问自己一句 —— 如果产品根本没做成这件事，这条断言还有可能通过吗？

只检查整页出现「张三」，可能命中旧客户；只检查「保存成功」，可能漏掉持久化失败；只检查列表数量大于零，可能压根没验证到本次新增。

把断言关联到对应的验收目标，再核对定位范围、断言类型和预期值：

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

断言自己的语义也要注意：text 是包含匹配，text_exact 是规范化空白后全文相等；count 统计匹配节点、包括隐藏节点。在分页或虚拟列表里，「当前 DOM 没有这条记录」推不出「系统里不存在这条记录」，得先用准确查询或接口验证缩小范围。

浏览器断言会在超时预算内自动重试。优先等明确结果，别随手加几秒固定等待去掩盖不稳定。

另外，当前工具要求所有必验目标都有实际通过的断言证据才允许完成生成 —— 这能防漏验，但验收目标本身对不对、是否覆盖关键风险，还是得人来审。

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

看到红色结果，先别改脚本。把问题整理成四句话：

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

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

按证据决定下一步：

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

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

工具不对失败断言做 AI 自愈 —— 理由是避免把真实问题改成通过。动作定位自愈之后，也要核对操作的是不是正确对象，再决定是否采纳回写。

发现真实缺陷本身，就是一次有价值的测试产出。 遇到必验断言失败时不应该出现「已完成」；应保留步骤和日志，记录缺陷，修复后再续跑或回放。别为了拿到「完成」状态降低验收标准。

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

一次跑通只说明「当时的环境和数据下能走通」。稳定的回归还要管登录、数据、版本和清理。

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

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

随机生成不保证满足所有业务规则，也不保证绝无碰撞 —— 固定长度、号段限制、必须预先存在的数据，要按项目规则准备。

保存脚本后，用「运行当前版本」验证回放，并核对：

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

已经验证稳定的脚本，日常回归优先走回放：确定性回放不调模型，需要定位自愈时才会有模型消耗。翻生成记录里的重复观察和失败重试，往往还能发现需求描述或前置条件没写清的地方，顺手就省了后续生成的 token。

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

每周挑三条用例复盘就够了：一条生成成功的、一条失败的、一条频繁自愈的。

1. 成功那条的断言，能不能识别「提示成功但数据没保存」这类缺陷？
2. 失败那条的证据，够不够让另一位工程师独立复现和判断？
3. 频繁自愈，是定位不稳、环境变了，还是测试设计耦合太紧？

有条件的话，在隔离的练习页面里预先埋几种已知错误（错误手机号被接受、保存后数据丢失、失败响应被显示成成功），看看现有用例能不能检出来，再据此改断言。别在共享环境里改产品行为做练习。

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

持续练这三件事 —— 把需求写成可验证的约定、把页面现象解释成可检验的假设、把执行结果整理成可复核的证据 —— AI 才会真的成为提升专业判断力的助手。

下一次打开计划确认弹窗时，先问自己一句：这份计划究竟能证明什么？

各位平时怎么审这份「验收约定」？有没有遇到过「计划看着挺全、跑完却什么都没证明」的情况？评论区聊聊。

参考：

• 项目地址：https://github.com/xianyongwen/TestDog
• 文档：https://softwing.top/testdog-doc/
• 社区：https://testerhome.com/opensource_projects/testdog