刚开始用 AI 做测试时，常见的做法是只贴上一句需求，就让它生成用例。模型通常会列出常见场景，但哪些来自需求、哪些是它自行补充的，不一定容易分辨。
可以直接用对话做需求分析和测试设计，但最好把它当作一场有检查点的讨论，而不是一次性答案生成器。
从一句需求开始，先问它不知道什么
练习需求是：“用户可以通过手机号和验证码登录，新用户首次验证成功后自动创建账号。”
第一轮先不要让 AI 写用例，可以问：
请根据这段需求，整理已明确的规则、缺失信息、潜在风险和待确认问题。不要补写需求里没有说明的行为，也先不要生成测试用例。
首轮回答的价值在于列出后续要确认的问题，例如：验证码多长时间有效？发送是否有限流？输错多少次会限制？用户被禁用时能否登录？账号是在发送验证码时还是验证成功后创建？重复提交或网络重试会不会重复创建账号？日志如何避免记录验证码？这些都是待澄清项，不是已经确认的规则。
把已确认信息和待确认项分开
本例假设业务方确认了四条规则：验证码 5 分钟有效；每个手机号每天最多发送 20 次；连续输错 5 次后锁定 15 分钟；新账号只在首次成功验证后创建。把这些事实重新贴入对话，并让 AI 继续标注未知项。
| 信息 | 当前状态 | 对测试的影响 |
|---|---|---|
| 验证码有效期为 5 分钟 | 已确认 | 需要测试有效期内、过期后的行为 |
| 每天最多发送 20 次 | 已确认 | 需要验证限流计数与恢复时机 |
| 恰好 300 秒时是否仍有效 | 待确认 | 不能先写死边界预期 |
| 并发点击发送如何计数 | 待确认 | 需要产品或接口规则说明 |
| 连续输错 5 次后锁定 15 分钟 | 已确认 | 还要确认计数是否跨验证码或会话累计 |
| 注册失败时如何回滚 | 待确认 | 需确认是否出现半创建账号 |
上表中的规则仍是教学设定。真实项目里应替换成经产品、研发确认的规则，并保留相应出处。
再让对话逐步走向测试场景
有了业务事实后，可以要求 AI 按业务路径整理测试场景，而不是直接扩写用例数量：
只根据以下已确认规则设计测试场景，覆盖正常、异常、边界、并发、安全和可观测性相关行为。每个场景注明对应规则；如果预期行为没有依据，标记为“待确认”。先输出场景，不要虚构接口状态码或页面文案。
初步场景可以包括有效验证码登录、错误验证码、过期验证码、发送次数达到上限后的再次请求、达到错误次数后的锁定，以及首次登录成功后是否创建账号。之后还要由测试人员判断哪些风险被遗漏、哪些场景依赖尚未明确的产品行为。
当场景评审通过，再把其中一条转成可执行用例。比如“错误验证码不能创建账号”，除了验证错误提示，还要检查账号是否真的没有被创建。具体观察点要以项目接口、数据权限和测试环境为准。
把一个场景写成可复核的用例
场景评审通过后，再把已确认规则和场景一起交给 AI，要求它生成用例。不要只说“写成用例”，还要规定输出字段和证据要求：
请把下面已评审通过的测试场景写成一条可执行测试用例。
已确认规则与来源：[粘贴已确认规则及出处]
待确认项：[粘贴待确认内容；不要把它们当成事实]
测试场景：[粘贴已评审通过的场景]
请输出：用例 ID、规则依据、前置条件、测试数据、操作步骤、可观察的预期结果、断言和所需证据。
没有规则依据的预期标为“待确认”；不要编造接口状态码、页面文案或数据字段。信息不足时指出缺口，不要自行补全。下面是教学用记录，不代表任何真实产品行为。用例中的业务规则来自前面的练习设定；真实项目应替换为已确认的规则和测试数据。
| 字段 | 示例内容 |
|---|---|
| 用例 ID | LOGIN-OTP-EX-01（示例编号） |
| 规则依据 | 新账号只在首次成功验证后创建（练习设定） |
| 前置条件 | 使用未注册的测试号码，在隔离环境准备符合规则的有效验证码 |
| 操作 | 提交验证码并完成登录 |
| 预期结果 | 验证成功后登录成功，账号状态查询能找到该号码对应的新账号；若可查审计事件，创建事件时间应晚于验证成功事件 |
| 证据 | 脱敏测试主体、规则来源、环境与构建版本、请求或校验事件 ID、账号查询前后结果和执行时间 |
不要把验证码本身写入报告。只有页面显示登录成功，不能证明账号只创建了一次；需要结合项目允许查看的账号状态或审计记录。若重复提交时的行为没有产品规则，或无法取得状态证据，应标为“待确认”或“证据不足”，不要判为通过。这是用例设计示例，不代表测试已经执行。
对话里应该持续带着的上下文
AI 不一定掌握你的系统背景。除了需求正文，还要按任务补充目标用户、业务规则、状态流转、角色权限、系统边界、相关接口、已有缺陷、环境限制和测试数据策略。涉及生产数据、个人信息或访问凭证时，先按团队规范脱敏，不要把秘密直接粘进对话。
多轮沟通也有一个容易忽略的风险：前面确认过的约束可能在后续回答里被弱化，甚至被模型遗忘。可以维护一份简短的“已确认规则清单”，每次进入新的分析阶段时重新引用。对重要结论，记录来源和确认人，不要把聊天记录当作唯一事实库。
判断回答有没有帮上忙
不要只看它有没有把需求写成漂亮的表格。检查每条用例能否追溯到需求或已确认规则；前置条件、操作和结果是否可执行；异常与状态变化是否覆盖；仍然未知的地方是否诚实标记。发现错误时，把具体问题指出来，让 AI 修改对应内容，而不是笼统要求“再完善一点”。
练习时可以选一份当前需求，先做“事实与问题清单”，拿到业务确认后再生成场景和用例。这样得到的不一定是最多的用例，却更容易进入真正的评审流程。
这也是持续改进测试的起点。每轮记录遗漏、错误假设和有效补充。修订需求上下文或 Prompt 后，用同一需求重新生成场景或用例，再按规则追溯、可执行性、异常覆盖和证据要求复核修改效果。
评审或执行中确认的问题再带入下一轮。没有业务依据的猜测不要沉淀成“上下文”，否则后续对话可能重复同一个错误。换业务、Agent 或模型后，也要重新检查这套上下文是否适用。
下一篇会把这轮对话中稳定有效的做法整理成可反复调整的 Prompt 模板。