用 AI 设计测试用例：从正常流程走到边界、异常和回归风险
AI 可以快速扩展测试场景，但不能替团队定义正确性。本文讲清如何从规则、边界、状态、权限和副作用构建可追溯的高质量测试用例。
需求文档写着：“用户输入验证码后登录，连续输错五次锁定账号。”让 AI 生成测试用例，它很快列出正确验证码、错误验证码、空值三项，看起来像一份清单，却漏掉了计数窗口、并发请求、重新发送、锁定后的旧验证码、管理员解锁和多设备状态。真正危险的缺陷，往往藏在这些规则交界处。
AI 能扩展测试思路、生成数据组合和整理回归范围，但它不知道哪条规则最关键，也不知道真实系统的历史包袱。要让它帮上忙，必须先把需求变成可观察规则、状态变化、边界条件、权限约束和失败后果。
测试用例不是操作步骤的数量，而是对风险和规则的系统覆盖。
先确认测试依据是否足够
在写用例前，收集需求、验收标准、界面原型、接口契约、数据字典、权限矩阵和历史缺陷。让 AI 标出冲突与缺口：验证码有效期从何时计算？第五次错误本身是否触发锁定？锁定按账号、设备还是 IP？如果答案未知，先形成待确认问题，不能擅自生成一个确定规则。
把自然语言拆成可测试规则
| 规则元素 | 示例 | 测试关注点 |
|---|---|---|
| 前置条件 | 账号正常且已发送验证码 | 账号状态、发送渠道、已有会话 |
| 输入 | 六位验证码 | 格式、空值、过期、重复使用 |
| 状态变化 | 错误次数增加或账号锁定 | 计数、并发、重置、持久化 |
| 输出 | 登录成功或明确错误 | 界面、接口码、日志、事件 |
| 约束 | 五分钟内最多五次 | 第 4/5/6 次和时间边界 |
先画测试空间，再写具体步骤
把变量列出来：账号状态、验证码状态、尝试次数、时间、设备、网络、权限和下游依赖。然后使用等价类、边界值、决策表和状态迁移筛选组合。AI 可以帮助枚举，但全排列通常既昂贵又没有重点。
正常流程只是一条窄路
除了正常成功，还要覆盖输入边界、业务异常、技术失败、权限差异、重复操作、顺序变化和恢复流程。例如支付成功但回调超时、提交按钮被连点、请求已处理却收到重试、页面刷新后状态如何恢复。这些场景比“换三个不同用户名”更可能发现严重问题。
用边界值抓住规则转折点
若允许 1 至 100 个字符，至少关注 0、1、100、101，而不是随机挑 20 和 30。时间、金额、次数、分页、容量和精度都应围绕规则发生变化的位置设计。还要明确边界单位、时区、包含关系和取整方式，否则“到期当天”会出现多种解释。
用决策表处理条件组合
优惠资格可能同时取决于会员等级、商品类型、活动时间和优惠券状态。把每个条件及预期动作放入决策表，再删除业务上不可能出现的组合。让 AI 查找缺失和矛盾规则，但最终预期结果必须由产品或领域负责人确认。
用状态迁移发现顺序问题
订单从待支付到已支付、已取消、退款中和已退款，允许的操作随状态变化。测试不仅要验证每个状态，还要验证合法与非法迁移、重复事件、乱序消息和失败恢复。状态图还能揭示“页面显示已取消，但支付回调稍后到达”这类竞争条件。
异常测试必须检查副作用
看到错误提示并不代表测试完成。还要检查数据库是否部分写入、库存是否扣减、消息是否重复、审计日志是否完整、重试是否幂等、敏感信息是否泄露。一个请求返回失败却悄悄改变状态，通常比界面文案错误严重得多。
按风险确定优先级
| 风险 | 优先覆盖 |
|---|---|
| 资金与账务 | 重复扣款、精度、对账、补偿 |
| 权限与隐私 | 越权、对象级权限、日志脱敏 |
| 不可逆操作 | 删除、发布、批量修改、错误恢复 |
| 高频核心流程 | 主路径、依赖失败、并发与性能 |
| 历史高缺陷模块 | 相关回归、兼容和配置组合 |
可以用“发生概率 × 影响 × 可发现性”做粗略排序，但数字只是讨论工具。高损失的低频场景仍可能需要优先验证。
让每条用例都能追溯
用例至少关联需求或风险编号，包含前置条件、数据、步骤、预期结果、优先级和自动化状态。需求改变时，团队能快速找到受影响用例；缺陷出现时，也能判断是规则未覆盖、实现错误还是环境问题。
AI 生成的数据也要受约束
测试数据应说明字段规则、关联关系、脱敏要求和清理方式。不要把真实客户数据直接交给外部模型，也不要接受看似合理却违反数据库约束的数据。对日期、身份证明、金额和多语言字符，优先使用可复现的生成器和固定种子。
区分适合自动化和适合人工探索的用例
稳定、重复、结果明确的接口和核心回归适合自动化；视觉体验、模糊需求、新功能探索和跨系统异常恢复仍需要人的判断。AI 可以起草测试代码，但必须经过代码审查、在隔离环境运行，并验证断言真的能发现错误，而不只是“脚本执行成功”。
一次变更如何选择回归范围
从直接修改的规则出发，追踪调用者、共享组件、数据结构、缓存、事件消费者和权限。再结合历史缺陷与生产流量，形成必测、建议测和观察项。不要每次都机械执行全部用例，也不要只测开发者说“改过的页面”。
从生产缺陷反推测试资产
缺陷修复后，不应只新增一条“复现步骤”。先判断原有测试为什么没发现：需求没有写、场景没有覆盖、数据不真实、断言太弱，还是环境与生产不同。然后补充对应风险、邻近边界和同类模块的回归用例。AI 可以帮助搜索相似规则和历史缺陷，但关联关系要由维护者确认，避免把一次事故变成孤立补丁。
AI 辅助设计流程
- 输入脱敏后的需求、接口和业务规则。
- 让 AI 先列冲突、未知和不可测试表述。
- 拆出条件、状态、边界、权限和副作用。
- 用决策表、状态图和风险清单生成候选场景。
- 人工确认预期结果并删除无意义组合。
- 关联需求与风险，评审后进入执行和回归。
可直接使用的提示词
“你是测试设计助手。只能依据编号需求和接口材料。先列出已知规则、冲突、缺失条件和需要业务确认的问题，不得自行补充规则。随后按正常流程、等价类、边界值、状态迁移、权限、并发、重试、依赖失败和恢复生成测试场景。每条写前置条件、数据、步骤、可观察预期、副作用检查、对应需求、风险级别和是否适合自动化。最后指出覆盖空白与最小回归集合。”
评审检查清单
- 未知规则是否先提问而非被 AI 补全？
- 每个边界是否覆盖转折点两侧？
- 状态迁移、重复和乱序是否考虑？
- 失败后数据库、消息和外部系统是否检查？
- 高风险权限和资金场景是否优先？
- 用例是否能追溯到需求、风险和变更？
AI 最适合扩展视野和整理结构，不能替测试人员定义正确性。先把规则和风险说清，再让模型帮助枚举；最后用人的领域知识删减、验证和排序，才能得到真正能发现问题的测试集。
本文为读懂 AI 原创内容。处理生产日志、客户数据、账号与安全规则时，请使用脱敏材料和隔离测试环境，并遵守组织的权限、隐私与安全制度。
