企业官网建设流程全解析

用 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. 最后单列需要找开发/产品确认的问题。

它返回的等价类，正确示范应该长这样（注意：处理不同的要拆成不同类、一类只留一个代表）：

动作 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"的同事。