:让 AI 按等价类 + 边界值把用例补全)
用 AI 做测试设计 ·二先说清怎么读这个系列一篇讲一个方法是为了讲透不是让你做需求时跑好几个 prompt。实操时脑暴、等价类、边界、场景法是同一次协作里的连续动作一个综合提示词 两三句追问即可走完系列收尾会给做完一整个需求的整合版。先讲一个我曾review 到的真实事故——用例一条没漏、全绿bug 还是上了线。开篇一组全绿的边界用例为什么没拦住某 B 端系统有个客户备注字段需求里只写了一句用户可填写客户备注没给长度、没给字符规则。负责测试的同事就让 AI 补边界用例AI 很利索地给了一组100、101、255、256。他照着填、照着测结果全是通过于是放心上线。上线没多久有个客户粘贴了一段 40 多字、末尾还带个 Emoji 的备注点保存直接报错。倒查代码才发现数据库这一列其实是varchar(32)按 UTF-8 存储这个入口的前端组件偏偏没做长度限制接口也只在落库时才抛错于是32 这个真实边界用例里一次都没出现过字符数和字节数的差异、Emoji也压根没测。255、256测了一堆可那根本不是这个系统的边界。用例绿只证明AI 猜的那几个数没出问题证明不了真实边界被覆盖了。这一篇就顺着这个事故倒查三件事等价类/边界值到底在干什么、AI 为什么会一本正经给错数、怎么把假边界换成真边界。一、倒查第一层等价类和边界值本质是测试的压缩算法一个备注框的理论输入是天文数字不可能穷举。测试设计的核心是从无穷输入里挑出最有代表性的少数几个靠的就是这两个用了几十年的方法等价类划分把系统会一视同仁处理的输入归成一类每类只取一个代表——同一类里要么都过要么都挂测十个和测一个信息量一样。边界值分析缺陷不是均匀分布的而是高度聚集在分界的地方。合起来就是一套压缩算法等价类把无穷压成几类边界值在每类最容易出事的边缘再精准点几枪。为什么 bug 总爱在边界扎堆这是代码决定的分界处几乎必然对应这些易写错的写法比较运算符写成差一个等号off-by-one下标和容量数组从 0 计数、长度判断差一、容量刚好卡住临界规则库存为 0、余额刚好等于金额、次数刚好到上限精度舍入小数截断、四舍五入、浮点表示误差。正常数据走主干大马路边界数据走分叉判断——判断一多错就多。所以老手拿到字段眼睛先盯两端。二、倒查第二层AI 为什么会给看起来很专业的假边界先说强项一旦真实边界确定让它按最小、略小、刚好、略大、最大去铺它一个不漏批量划类也又快又整齐不累、没定式。但死穴也正在这它既不知道你系统的真实边界也不知道系统按什么规则分类。你只丢一句帮我测备注长度的边界它并不知道你这列是varchar(32)还是varchar(255)、业务上限是多少。它给的255、256、100、101本质是从海量训练语料里回忆出来的高频经典数字——不是读了你的约束算出来的。心智模型沿用第一篇它是那个经验极丰富、但第一天上班、完全不懂你们系统的同事。你不告诉他字段到底多长他报的就全是别的公司常见的数。事故里那位同事踩的就是这个坑把AI 猜的当成了系统真的。记住这条下面所有动作都围绕一件事——逼 AI 把猜测和真实分开。三、从事故到正确动作把假边界换成真边界动作 1先去找真实边界能确定就直接喂最省力也最该先做别一上来就让 AI 报数。真实约束优先从这些地方直接读不必只靠问开发接口参数校验注解Size(max)、Max、DecimalMax等数据库字段定义varchar(n)、精度标度前端校验规则组件的 maxlength、正则。能拿到确定值就直接把确定值喂给它长度 按字符还是字节 前后端是否都校验要给全下面动作 2 的待确认流程只在需求没写、暂时查不到时才用。动作 2拿不准时让它先列边界假设 依据而不是直接给数在你给出任何具体数字前先列一张表 边界点 | 你的取值 | 依据。 依据必须标注三类【需求明示】【技术推断】【待确认】。同一个字段它可能这样交代下限 / 上限 → 【需求明示】“中英文是否都按 1 个字符计数” → 【待确认】“前端限了接口是否也校验” → 【待确认】数据库列长度、超长是拒绝还是截断 → 【待确认】这一步把猜测从结论里揪出来打标签你一眼就能分清哪些能直接用、哪些必须核实。等你查清后再把真实约束喂回去补充确认后的约束 - 数据库列为 varchar(32)按 UTF-8 存储 - 后端按字符个数校验不是字节数 - 前后端都校验接口直连也要拦 - 超长由后端统一拒绝不截断。 请基于这些已确认约束重新生成边界用例去掉【待确认】项。动作 3划等价类注意一类一个代表先用一版初稿提示词让它跑通看懂输出即可长期用动作 6 的进阶版你是一名有10年经验的资深测试工程师。 请对下面字段用等价类划分 边界值分析设计用例。 字段昵称2~12个字符支持中文/英文/数字不允许特殊符号不能与他人重复。 要求 1. 表格列等价类类编号 | 输入说明 | 类型(有效/无效) | 代表值 2. 对长度做边界值给出每个点的取值和预期 3. 推断的边界标【待确认】不当确定结论 4. 最后单列需要找开发/产品确认的问题。它返回的等价类正确示范应该长这样注意处理不同的要拆成不同类、一类只留一个代表类编号输入说明类型代表值E1纯中文长度区间内有效“测试工程师”E2纯英文长度区间内有效“tester”E3中英数混合长度区间内有效“test01测试”E4空什么都不填无效“”E5只填空格无效 E6纯数字有效“12345”E7长度不足1 字符无效“a”E8长度超长13 字符无效13个字符E9含特殊符号无效“test”E10Emoji / 组合音标字符无效【是否允许待确认】“测”E11与他人昵称重复无效已存在的昵称动作 4点边界用三点 / 五点法三点法常规字段够用恰在边界、刚出边界内侧、刚越界外侧。例2 / 3 / 1。五点法高风险、数值/金额字段建议最小、略高于最小、任意正常、略低于最大、最大再各配一个越界值。对应昵称 2~12真实的长度边界是1 字符拒绝 /2 通过恰下限/ 3 通过 / 11 通过 /12 通过恰上限/ 13 拒绝。数值类字段还要额外点两类小数精度金额0.01、0.001多一位小数、0.10与0.1、很大数字末位舍入业务边界 ≠ 系统边界单笔限额 5 万业务但字段本身能存更大——两个边界都要测。动作 5主动补隐性边界这是最显功力、AI 默认不会给的部分字符数 ≠ 字节数一个中文在 UTF-8 下占 3 字节、Emoji 占 4 字节还有组合音标字符——12 个字符和12 个字节测出的结果完全不同看不见的字符前后空格、全角/半角、制表符、零宽字符不止输入有等价类输出等价类成功、重复、超长是否各走对了文案状态等价类未登录 / 已登录 / 被禁用户去改结果不同分页/数量/时间边界第 0 条、第 1 条、翻页临界、跨天跨月、闰年 2 月 29 日。一句请额外补充字节数、不可见字符、输出与状态相关的边界常常能捞出一整层第一版没有的用例。动作 6反向收口并打包成进阶提示词生成完别照单全收先让它反查请给每条用例标注覆盖的类编号和边界点然后 1. 有效类允许一例覆盖多个有效类用最少用例覆盖全部 2. 无效类一例只覆盖一个无效点带两个非法条件的拆开 3. 指出还有哪个类/边界没被覆盖 4. 对每个无效类说明对应系统哪条校验/哪条不同处理路径 说不出来的标【疑似脑补】。日常不用每次手拼下面这段把全部动作整合了替换方括号查清约束后再单独补发一次你是一名有10年经验的资深测试工程师请用等价类划分 边界值分析 为下面字段设计用例。 【业务/技术背景】 - 字段用途与产品[这是什么字段、给谁填] - 已确认的约束[类型、长度按字符还是字节、数据库列、前后端是否都校验] - 业务上限/规则[单笔限额、次数、库存等没有写暂无] 【字段需求】 [贴需求原文] 请严格按顺序完成 1. 先不要给具体数字列边界假设表边界点 | 取值 | 依据 依据标【需求明示】【技术推断】【待确认】。 2. 列等价类表类编号 | 输入说明 | 有效/无效 | 代表值 除输入类外必须考虑状态类、输出类代表值落在类中间、足够典型 不新增需求里没有的类。 3. 长度用三点法、数值/金额用五点法金额额外测小数精度与舍入。 4. 主动补隐性边界字符数与字节数、Emoji/组合字符、空格/全角半角/零宽字符 以及输出等价类、状态等价类。 5. 每条用例标注覆盖的类编号与边界点有效类用最少用例覆盖 无效类一例只覆盖一个无效点指出未覆盖缺口每个无效类说明对应的 真实校验/处理路径说不出来的标【疑似脑补】。 6. 等价类专项自检逐条回答 ① 有没有漏无效类/状态类/输出类 ② 有没有需求里不存在、自己加出来的类 ③ 有效/无效有没有标反空格、特殊符号默认应为无效除非需求允许 ④ 代表值是否都落在类中间、而不是贴着边界 ⑤ 有没有处理相同却拆两类或处理不同却并一类 7. 最后列出必须找开发/产品确认的边界问题。四、事故本可以提前避免一张边界确认清单动作 6 最后那节别浪费AI 通常会列出长度按字符还是字节中英文、Emoji 如何计数前后空格是否自动 trim仅前端拦截还是接口也校验超长是拒绝还是截断重复判定是否区分大小写、全角半角需求长度与数据库列是否一致写用例前一次性跟开发对齐能避免大量我以为边界是 12结果按字节算的返工——开头那个事故靠这张清单就能在上线前拦住。五、复盘留下的三个坑1. 假边界给你虚假的安全感。AI 报的数越自信、越经典越可能只是语料高频值。它能保证格式铺满保证不了数字是真的——没核实一律【待确认】。2. AI 划类的五种典型错误对照自查漏类漏无效/状态/输出类编类加需求没有的类判反空格/特殊符号默认合法代表值取错没落在类中间粗细失当处理不同却并类、或一类拆几个。判据每个无效类对得上一条真实校验或不同处理路径吗3. 有效类笛卡尔积式爆量是用例库被灌水的隐形元凶。AI 容易把多个有效类两两组合全列出用例瞬间膨胀。但有效类只要求覆盖到不要求组合穷尽。看到用例成批增加先问这是覆盖了新逻辑还是只换了排列六、比 prompt 更重要的4 个非提示词能力prompt 只是怎么发问真正拉开水平、且不依赖某段神奇提示词的是分工AI 出初稿和广度你出约束和裁决确认真实边界、判断系统有没有、定优先级、去重。把裁决也外包就得到好看但不能用的用例。协作把一问一答变成带反馈的多轮每轮只推进一件事它开始忘约束时让它复述需求或重开。验证把产出当待验证草稿——抽样反推依据、用接口注解/库定义/实跑核对、两模型交叉看差异点。工程化模型按任务选结构化划类用主流模型复杂约束用长上下文推理稳的输出成可入库的表把验证过的提示词固化进生成—评审—入库流程。工具只是沉淀方法——方法没掌握换什么工具都白搭。总结我的固定动作拿到字段 →先从接口注解/库定义/前端校验读真实边界能确定就直接喂拿不准让 AI 列假设依据打标签→ 查清并喂回约束 → 划等价类一类一代表 三点/五点边界 → 补字节/精度/状态等隐性边界 → 按覆盖反向去重查漏 → 用边界确认清单对齐 → 定稿。几分钟换来的是每条边界都有据可依。这一步最关键的不是让 AI 多报几个数而是逼它把猜的和真的分开——假用例比没用例更危险因为它会让你以为自己测过了。这是「AI for Testing 提效实战 · 测试设计二」。如果这个动作对你有用欢迎转给那个总在用例里写测试 255、256的同事。