AI 生成边界值用例，经常漏掉什么

AI 生成边界值用例时，通常能覆盖显性的字段限制，例如长度、金额、数量、枚举值。

但如果直接把这类用例导入用例库，很容易出现一个问题：字段边界不少，业务边界不够。

下面按测试评审视角整理一套检查清单。

1. 只覆盖字段边界，漏掉业务边界

典型输出：

• 字段长度限制 20：输入 19、20、21 个字符。
• 满 100 元可用：订单金额 99.99、100、100.01。
• 库存上限 999：库存 998、999、1000。

这些用例可以保留，但不能代表边界值测试完整。

以 “满 100 元可用优惠券” 为例，还需要补充：

• 门槛金额按商品金额、订单金额还是实付金额计算。
• 运费、包装费、服务费是否参与门槛计算。
• 会员折扣、活动折扣后低于门槛时是否可用。
• 多商品订单中部分商品不支持优惠时，门槛如何计算。
• 退款、部分退款后优惠券状态和优惠金额如何处理。

判断标准：如果 AI 只围绕输入值取前后一格，它生成的是字段边界，不是完整业务边界。

2. 时间边界过粗

AI 常见写法：

• 活动开始前不可参与。
• 活动期间可以参与。
• 活动结束后不可参与。

建议细化为：

• 开始前 1 秒。
• 开始时刻。
• 开始后 1 秒。
• 结束前 1 秒。
• 结束时刻。
• 结束后 1 秒。

还要根据系统实现补充：

• 用户进入页面时间和提交时间不一致。
• 客户端时间和服务端时间不一致。
• 定时任务延迟执行。
• 跨天、跨月、闰年、时区。
• 活动时间被后台修改后，已领取/已下单数据如何处理。

示例：

前置条件：优惠券有效期截至 2026-07-04 23:59:59。
步骤：用户 23:59:50 进入支付页，00:00:01 提交订单。
预期：系统按服务端提交时间判断优惠券已过期，订单不可使用该券，并给出明确提示。

3. 漏掉状态边界

状态边界通常比数字边界更容易引发缺陷。

示例：订单 30 分钟未支付自动取消。

除了 29 分钟、30 分钟、31 分钟，还应补充：

• 29 分 59 秒点击支付，30 分 01 秒支付回调返回。
• 订单刚被取消，用户仍停留在支付页。
• 定时取消任务与支付回调并发执行。
• 后台人工取消订单后，用户继续支付。
• 订单取消后，优惠券、库存、积分是否回滚。

状态边界用例至少应明确：

• 初始状态。
• 触发动作。
• 状态变化时机。
• 最终状态。
• 页面、接口、数据库或消息上的可观察结果。

4. 组合边界被拆散

AI 往往会把条件拆成独立用例：

• 金额边界。
• 时间边界。
• 库存边界。
• 用户身份边界。
• 商品范围边界。

但高风险场景经常发生在组合条件里。

示例：

新用户 + 活动结束前 1 秒 + 库存剩 1 张 + 订单金额刚好 100 + 部分商品不参与优惠

建议让 AI 生成组合边界时加约束：

请基于金额、时间、库存、用户身份、商品范围生成高风险组合边界场景。
不要做完整排列组合，只保留可能影响资金、订单状态、库存扣减和用户权益的组合。

这样可以避免生成大量低价值用例。

5. 默认系统数据过于干净

AI 通常默认数据状态符合文档，但存量系统里经常存在历史数据和异常配置。

建议补充：

• 老用户缺少新增字段。
• 历史订单没有新状态。
• 旧版本发出的券没有新规则字段。
• 后台配置为空、重复、被禁用后恢复。
• 历史数据迁移后状态不一致。
• 接口返回字段缺失、类型不一致或枚举值超出文档范围。

这类场景不一定是传统边界值，但属于实际项目里的数据边界。

推荐提示词

请基于以下需求生成边界值测试用例。

不要只覆盖数字、长度、金额等字段边界。
请按以下维度补充：
1. 字段边界：长度、格式、必填、枚举、数量、金额。
2. 时间边界：开始前后、结束前后、跨天、服务端/客户端时间不一致。
3. 状态边界：对象状态切换、异步回调、定时任务、人工后台操作。
4. 权限边界：不同角色、未登录、过期登录态、越权访问。
5. 组合边界：只保留高风险组合，不做全量排列组合。
6. 历史数据边界：旧数据、缺失字段、重复配置、迁移数据。

每条用例请包含：前置条件、操作步骤、测试数据、预期结果、风险等级。

评审清单

可以用下面 6 个问题评审 AI 输出：

• 是否只覆盖了字段的前后一格？
• 是否说明了业务规则如何计算？
• 时间边界是否细化到具体时刻？
• 是否覆盖状态切换和并发触发？
• 是否包含高风险组合边界？
• 是否考虑旧数据、脏数据和历史状态？

AI 生成边界值用例的价值，是帮我们快速铺开显性边界。

但真正需要测试人补上的，通常是业务规则、对象状态和数据历史里的隐性边界。