测试用例已经评审通过，接下来让 AI 写自动化代码，听起来很顺。但“代码能运行”不等于“测试有效”：它可能连错接口、使用不稳定的数据，也可能只检查一个无关紧要的响应字段。
更稳妥的做法是让 AI 从一条已经讲清楚的测试条件开始，生成最小实现，再由人审查，并在获准的隔离测试环境中运行、检查和修正。
新手入门：先自动化一条已评审用例
从手工用例走到自动化，可以按这个顺序推进：
- 选一个具体场景。 先选频繁执行、风险明确且预期结果有依据的用例，不要从“自动化整个模块”开始。
- 补齐项目上下文。 告诉 AI 使用的语言、框架、目录、已有 fixture/helper、页面或接口契约、数据准备与清理方式，以及不能访问的环境。
- 要求最小代码变更。 让 AI 先说明拟改文件和断言，再生成只覆盖这一条场景的测试；缺失的响应码、文案、选择器或状态钩子都标“待确认”。
- 人工审查代码。 核对定位器、业务断言、测试数据隔离、清理和变更范围。不能解释的代码先不要运行。
- 在获准的隔离环境执行。 保存命令、结果、日志和环境信息，区分未运行、跳过、失败和通过。
- 根据证据决定下一步。 先分类失败原因；稳定且有判别力的测试再加入回归集。
流程速记： 已评审用例 → 项目上下文 → AI 小步生成 → 人工审查 → 隔离执行 → 证据复核。
先把项目边界交代清楚
在要求 AI 写代码之前，说明项目使用的语言和测试框架、测试目录约定、已有辅助函数、接口契约、鉴权方式、测试环境、数据创建与清理方式，以及哪些外部系统不能访问。对界面测试，还要说明页面路径、可访问名称、状态和等待约定。
只提供一条用例，AI 仍可能猜错项目怎么组织测试。不要粘贴生产密钥、真实用户信息或未经脱敏的日志；需要凭证时，通过项目已经采用的环境变量或密钥管理方式处理。
API 测试：不要停在“返回成功”
例如要验证错误验证码不会创建账号，测试设计至少要明确：使用什么测试手机号、如何保证验证码无效、接口契约规定什么响应、如何检查账号没有创建，以及结束后如何清理数据。以下是表达意图的伪代码，端点、状态码和查询方式都必须换成项目实际契约：
response = submit_verification(test_phone, invalid_code) assert response.status == expected_rejection_status assert account_for(test_phone) is None
若只断言 HTTP 返回某个状态码，仍无法证明业务副作用正确。反过来，若测试数据可能被其他运行复用，账号存在与否也可能受到并发测试干扰；这需要唯一数据、隔离环境或明确的清理策略。
以练习规则 R-03“连续输错 5 次后锁定 15 分钟”为例，测试至少要把阈值、状态和数据准备连起来：
| 步骤 | 自动化要完成的事 | 需要从项目确认的部分 |
|---|---|---|
| 准备 | 使用可重置的合成手机号，并确认每次运行不会继承上次的失败计数 | 测试数据创建/重置接口、隔离方式 |
| 第 1–4 次错误 | 连续提交 4 次无效验证码，并按契约观察状态；如果第 4 次场景单独运行，也要从初始状态提交完整的 4 次 | 这些尝试的响应约定和可观察状态 |
| 第 5 次错误 | 在同一连续序列中再提交一次；如果单独运行，则从初始状态重新连续提交 5 次，核对第 5 次后是否按 R-03 开始锁定 | 锁定状态的查询方式与证据 |
| 锁定期间 | 再次请求，核对契约定义的行为，并确认没有非预期账号或会话副作用 | 锁定时响应及副作用规则 |
| 收尾 | 保存用例 ID、合成数据标识、运行报告，清理或重置状态 | 清理责任、失败后如何恢复数据 |
若项目没有可控的计数重置或状态观察方式，先把它作为测试能力缺口记录；不要让 AI 虚构测试接口，也不要把 15 分钟的时间边界猜成某种包含规则。
界面测试：优先使用稳定的用户语义
在支持 Playwright 的项目里，界面测试可以优先通过标签和按钮名称定位控件，而不是依赖容易变化的层级选择器。下面的片段只用于说明结构，页面标签和错误文案必须以真实产品为准：
page.get_by_label(“手机号”).fill(test_phone) page.get_by_label(“验证码”).fill(invalid_code) page.get_by_role(“button”, name=“登录”).click() expect(page.get_by_text(“验证码错误”)).to_be_visible()
如果界面并没有这些可访问名称，正确的下一步不是让 AI 编一个选择器，而是检查页面实现、需求和测试可访问性。也要避免固定睡眠时间代替条件等待，让测试等到预期状态或给出清楚的超时失败。
运行后先判断失败属于哪一类
测试失败时，不要马上让 AI 改到变绿。先保留失败日志和环境信息，再判断是测试代码错误、产品行为不符合预期、测试数据污染、环境故障还是偶发不稳定。只有确认原因后，才决定改测试、修产品或处理环境。
通过也要检查：断言是否真的覆盖目标行为？测试是否被跳过？它在功能被故意破坏时能否失败？能稳定重复运行并产出可追踪证据后，再考虑加入持续集成流水线。
对于尚未实现的新行为，也可以按小步的测试驱动开发（TDD）来做：先确认行为和预期，写一条最小测试并运行，确认它因目标行为尚未实现而失败；再实现或调整代码，让测试通过；最后在受控环境里验证故意破坏该行为时测试会失败。若功能已经存在，不必为了套用 TDD 而强求测试先失败；补上回归测试后，可通过受控变异确认断言有判别力。
留下可复核的运行记录
每次让 AI 生成或修改测试后，把代码评审和执行证据放在一起。下面是一个记录模板，示例字段不代表任何项目已经运行：
| 字段 | 记录内容 | 解释时注意 |
|---|---|---|
| 来源用例 | 需求编号、用例 ID、预期行为和对应版本 | 没有来源的断言先标为待确认 |
| 代码范围 | 变更文件、测试框架、复用的 fixture 或 helper | 与需求无关的改动需要单独说明 |
| 数据与环境 | 合成数据标识、环境、外部依赖边界和清理结果 | 共享数据或真实凭证会让结果难以复现并扩大风险 |
| 执行信息 | 完整命令、时间、退出状态和原始报告位置 | 未执行、被跳过和通过是不同状态 |
| 断言判别力 | 目标行为失效时测试是否失败，以及依据是什么 | 只通过一次不能证明断言有效 |
只有当需求依据、测试代码、数据隔离和运行报告能互相对应时，才把这条自动化记录作为回归证据；若环境故障导致测试没跑到目标断言，应保留为未评估，而不是产品通过或失败。
让 AI 一次只完成一小步
先让 AI 检查现有测试目录和框架约定，再根据一条已评审用例提出最小代码变更。不要一开始就要求它“把整个登录模块自动化”，否则代码范围、测试数据和验收目标都很难审清楚。
可以把任务写成这样：
请根据以下已评审用例，在当前测试框架中新增一条自动化测试。
需求依据与用例 ID：[填写]
接口或页面契约：[填写]
测试数据、隔离和清理方式：[填写]
项目目录与框架约定：[填写]
限制：[不得访问生产、真实账号或未经批准的外部系统]
不要补造未提供的行为、状态码或文案。先列出拟修改文件和测试命令，再解释断言如何检查目标行为及其副作用。如果工具支持执行测试，先核对命令、环境、数据清理和外部依赖，再只在获准的隔离环境运行。记录实际命令、输出和退出状态；没有执行时标为“未运行”，不要写成通过。
运行测试后，让 AI 解释日志和失败证据，最后由你决定如何修改。
练习时挑一条错误验证码用例，先核对接口或页面契约，再让 AI 生成测试。检查数据隔离、断言和清理方式，至少验证一次功能错误时测试会失败。自动化的价值来自可靠反馈，不来自代码生成得快。
最佳实践：让自动化有稳定反馈
- 一次从一条来源清楚的用例开始，让代码 diff 和失败原因都能对应回需求。
- 优先复用项目已有 fixture、API client、page object 和清理机制；不要让 AI 再造一套与项目不一致的结构。
- 使用合成且可隔离的数据，明确并发运行和失败后的清理策略；凭证走现有密钥管理。
- 界面测试优先使用用户可感知的标签、角色和名称，并用条件断言等待状态；避免猜测选择器和固定睡眠。
- 失败先分类再修改：测试逻辑、产品行为、测试数据、环境故障和偶发不稳定要分开处理。
- 把代码审查、执行命令、报告和断言判别力放在一起记录。一次通过只是一次运行结果，不等于覆盖充分。
常见问题（FAQ）
不会写代码，可以让 AI 帮我开始自动化吗？
可以从一条已评审的手工用例开始，请 AI 检查项目已有测试结构，并解释每个修改文件、步骤和断言。先读懂并审查改动，再在授权的隔离环境运行；AI 生成的代码不应未经审查直接合入。
可以让 AI 自动运行生成的测试吗？
是否能执行取决于工具和项目权限。运行前先确认命令、环境、数据清理和外部依赖边界；只在获准的隔离环境执行，并保存真实输出。没有运行时要标“未运行”。
什么样的断言才算有用？
断言要检查需求定义的业务结果和重要副作用，并能在目标行为错误时失败。只检查请求成功或页面出现某个元素，未必足以证明场景正确。
测试失败后，让 AI 直接修到通过可以吗？
先保留日志并分类失败来源，再决定改测试、产品还是环境。若只让 AI 以“变绿”为目标改动，可能把真正的产品缺陷改成宽松断言。
可以使用生产账号和真实用户数据吗？
不要把生产密钥、真实个人信息或未经脱敏的日志交给 AI。按项目现有的密钥管理和获准测试数据方案执行，避免自动化触达未经批准的生产或外部系统。
自动化测试如何进入日常质量循环？
每条重要需求先选已评审用例，让 AI 提议最小实现；人审代码与断言，在隔离环境运行并保留证据，分类问题后修正并重跑同一用例。经验证的案例、辅助方法和失败模式进入回归集与下一轮上下文。下方的独立章节给出了完整循环。
重点：把自动化放进日常质量循环
质量循环要同时照顾测试用例、自动化代码和运行反馈。 AI 生成的用例会变成自动化代码；运行结果又会揭示原用例、断言、数据准备或项目上下文哪里不足。每轮都要把证据带回下一轮，而不是只在失败时临时改代码。
在日常工作中，每条新故事或规则先挑一个高价值、已确认的手工用例。AI 只按项目约定提出可审查的最小改动；测试人员检查代码、数据和断言后运行。失败时先归因，再修复相应的测试、产品行为、数据准备或环境，并重跑同一用例；稳定通过后检查目标行为出错时它是否也会失败，再把用例、执行证据和已验证的辅助方法收入回归集。
这条循环也要反馈到 AI 生成阶段：把已确认的项目约定、常见失败和正确示例补入上下文，把未知行为留作问题，不把临时修复或未经确认的假设当成通用规则。需求、框架、模型或 Agent 变化后，再用相同样本确认生成和执行仍然可靠。
Playwright Python locators: https://playwright.dev/python/docs/locators Playwright Python assertions: https://playwright.dev/python/docs/test-assertions