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

我以前让 AI 生成边界值用例时，有过一个很熟悉的感觉。

它不是不会写。相反，它写得很快，也很像那么回事。

比如字段长度限制 20 个字符，它会给你 19、20、21。金额满 100 可用优惠券，它会给你 99.99、100、100.01。库存上限 999，它也知道要测 998、999、1000。

这些当然有价值。

但我后来发现，AI 最容易漏掉的不是“边界值”这三个字，而是边界背后的业务条件。

它很会找数字的前后一格，却不一定知道，真正会出问题的边界经常藏在时间、状态、权限、组合规则和历史数据里。

AI 最擅长的是从接口文档或需求文字里抓显性的限制。

最大长度、最小金额、数量上限、必填字段、枚举值范围，这些写得越清楚，它生成得越稳定。

问题是，很多边界不写在字段说明里。

比如一个满减券规则写的是“满 100 元可用”。AI 很可能会生成 99.99、100、100.01。

但测试时我还会追问：这个 100 是商品金额，还是订单实付金额？运费算不算？会员折扣后不满 100 还能不能用？多件商品里有一件不参与优惠，门槛怎么计算？退款后优惠券要不要退回？

这些才是业务边界。

所以我现在看 AI 生成的边界值用例，会先做一个判断：它是在测字段，还是在测规则。

如果只是在字段前后取值，这一版只能算基础稿，不能直接当完整边界测试。

时间类边界，是我觉得 AI 最需要人工补的地方。

它通常会写：活动开始前不可参加，活动期间可以参加，活动结束后不可参加。

这没有错，但太粗了。

真实系统里，时间边界往往不是“某一天前后”，而是“某一秒前后”。

比如活动 10:00 开始，用户 09:59:59 进入页面，10:00:00 点击按钮，算不算有效？优惠券 23:59:59 过期，用户 23:59:50 进入支付页，00:00:01 才提交订单，系统按哪个时间判断？

还有跨天、跨月、闰年、时区、服务端时间和客户端时间不一致。

这些问题不一定每天遇到，但一旦遇到，通常很难靠页面点击临时发现。

我会给 AI 补一句提示：

请把时间边界细化到开始前 1 秒、开始时刻、结束前 1 秒、结束时刻、结束后 1 秒，并考虑用户进入页面时间和提交时间不一致的情况。

很多功能的问题，不是出在输入值刚好多一点或少一点，而是出在对象状态刚好卡在某个位置。

订单从待支付变成已取消，优惠券从未使用变成已过期，任务从处理中变成已完成，账号从正常变成冻结。

这些状态切换的临界点，比一个输入框多一个字符更危险。

比如“订单超时 30 分钟自动取消”。AI 可能会写 29 分钟、30 分钟、31 分钟。

但还要补：用户在 29 分 59 秒点击支付，支付回调在 30 分 01 秒才回来，订单应该成功还是取消？订单刚被取消时用户还停留在支付页，按钮要不要刷新？取消任务和支付回调并发时，以谁为准？

这类场景，AI 如果只看需求文档，往往写不深。

因为它不知道你们系统里哪些状态是定时任务改的，哪些状态是异步回调改的，哪些状态可能被人工后台改掉。

这也是测试经验最值钱的地方：我们不是只找边界值，我们是在找边界状态。

单个字段的边界，AI 一般能写出来。真正麻烦的是多个条件叠在一起。

比如优惠券同时受金额、品类、用户身份、活动时间、库存、领取次数限制。

AI 很可能把它们拆成一条条独立用例：金额边界、品类限制、用户身份限制、库存为 0、领取次数达到上限。

但线上问题经常发生在组合里。

新用户、活动最后 1 秒、库存剩 1 张、订单金额刚好 100、商品里有一件不参与优惠。单看每个条件都不复杂，合在一起就容易出错。

所以我会让 AI 再生成一轮组合边界：

请基于金额、时间、库存、用户身份、商品范围这 5 类条件，生成高风险组合边界场景。不要平均组合，只保留最容易影响资金或订单状态的场景。

这里有一个小提醒：组合不是越多越好。全部排列组合很快会把用例变成一张没人想看的大表。

让 AI 先铺开，再由人删掉低价值组合，会更实际。

AI 生成边界值时，还有一个很明显的盲区：它默认系统是干净的。

用户数据完整，历史订单正常，配置没有脏数据，后台规则没有改过，接口返回也都符合文档。

但真实项目不是这样。

老用户可能缺字段，历史订单可能没有新状态，旧版本发出去的券可能没有最新规则，后台配置可能出现空值、重复值、下架后又恢复。

这些不一定属于传统教科书里的边界值，却是实际测试里很容易出问题的边界。

尤其是做存量系统、营销活动、支付订单、会员权益这类业务时，我会单独补一类“历史数据边界”。

提示词可以很直接：

请补充旧版本数据、缺失字段、重复配置、下架后恢复、历史状态迁移带来的边界场景。

我现在不会指望 AI 一次就把边界值用例写完整。

更稳的方式是分两轮。

第一轮，让它根据需求和接口文档生成基础边界值：长度、金额、数量、枚举、必填、格式。

第二轮，再让它按业务维度补：时间边界、状态边界、权限边界、组合边界、历史数据边界。

最后我自己再审一遍：哪些场景会影响资金，哪些场景会影响状态，哪些场景只是看起来完整但实际价值不高。

AI 很适合帮我们把“显性的边界”铺开。

但“隐性的边界”，仍然要靠测试人把业务往深处想一层。

如果你今天就想试，可以拿一个正在测的需求，让 AI 按下面这 5 类重新补一版：

字段边界、时间边界、状态边界、组合边界、历史数据边界。

你会很明显地看到，用例不是变多了而已，是风险开始浮出来了。