让 AI 写测试用例，出稿速度确实快得多；但如果没有边界，它会给你一叠"看起来合理"却测不到风险的用例。正确用法是先约束，再发散。
一、先给边界，再让它发散
直接把需求丢给 AI，得到的通常是正常流程的排列组合。先告诉它输入范围、业务规则和不能违反的前提，它才会去补异常分支。
- 输入约束：长度、类型、枚举值、必填项
- 业务规则：金额上限、时间窗、角色权限
- 已知痛点：历史上出过问题的场景优先
二、一份可复用的提示结构
| 要素 | 说明 |
|---|---|
| 被测对象 | 接口名或函数名 + 一句话职责 |
| 输入约束 | 取值范围与非法值 |
| 业务规则 | 必须成立的判断条件 |
| 边界条件 | 已知的下限、上限、空值、极值 |
| 输出格式 | 用例编号、前置条件、步骤、预期结果 |
| 禁止项 | 不要编造不存在的字段与接口 |
结构固定下来之后，同一套提示可以复用到不同模块，产出的格式也便于直接导入用例库。
三、AI 补的是分支，不是重点
AI 擅长穷举等价类与边界，不擅长判断"哪个分支出了事最疼"。这两件事恰好互补：它铺广度，你定优先级。
- 让 AI 按等价类分组，避免几十条用例其实在测同一件事
- 明确标出异常与超时场景，这类最容易被漏
- 用例数量不是产出，覆盖率与缺陷发现率才是
四、人工必须复核的四类用例
- 涉及金额与计费的用例，逐条核对口径
- 涉及权限与数据的用例，确认越权路径被覆盖
- 涉及第三方接口的用例，确认异常与重试逻辑
- 涉及并发与顺序的用例，确认前置条件可复现
五、把它接进流程：什么时候用，什么时候不用
- 适合：接口参数校验、表单规则、边界值补充、回归用例扩写
- 不适合：性能与容量验证、探索性测试、复杂业务链路设计
- 用 AI 产出用例后至少留一次人工评审，并沉淀成可复用模板
省下来的是打字时间，不是思考时间。把省下的时间花在挑重点、补异常上，才是真正的提效。
#AI提效#测试用例#质量保障#提示词
