1. 先搞清楚设计方法不是拿来炫技的是拿来控制遗漏的1.1 为什么想到哪测到哪注定会漏我带过几个刚入行的同学拿到需求第一反应就是打开Excel开始列正常登录、密码错误、账号不存在、验证码错误……列到二十条左右就开始卡壳然后问我还有吗。这个卡壳不是能力问题是方法问题——他在用大脑的短期记忆去对抗一个组合空间这场对抗从一开始就输了。算一笔很简单的账。一个登录框用户名涉及长度和字符类型两类因素密码涉及长度、大小写、特殊字符三类再加验证码正确与否、账号状态正常/冻结/未激活、设备环境首次登录/常用设备/新设备各三种。哪怕每类只取两个值光是这几个因素的全组合就是 2×2×2×2×3×3两百多种。真要把时序因素叠进去——先输密码后输用户名、中途刷新页面、切换网络——数量级还要再翻。靠脑补去覆盖这个空间覆盖率能到三成都算运气好。更要命的是遗漏的代价。我复盘过自己参与过的线上事故绝大多数不是测了没测出来而是压根没设计到那一条。执行环节出问题的比例其实很低设计环节漏掉的才是大头。这就是为什么测试用例设计方法值得单独拿出来讲——它不是让用例文档看起来更专业而是把该测什么从个人经验里抠出来变成有推导过程、可复查、可交接的东西。顺带说一句你可能在搜索框里看到过各种奇怪的长尾词比如有人搜功率放大器放大电路图的设计方法有人搜面向数据流的设计方法。这说明设计方法这四个字在不同领域都是高频诉求底层逻辑其实相通先界定输入范围的边界再决定在哪些点上投入资源最后留出安全余量。测试用例设计也是同一套逻辑只不过我们的器件是需求和业务规则。1.2 方法选型的底层逻辑用最少的用例覆盖最大的风险面很多人把各种设计方法当成并列的选项觉得用等价类就不用边界值了。这是误解。这些方法是叠加使用的各自负责不同的盲区像一组不同口径的筛子粗筛一遍再用细筛。方法主要解决什么典型适用场景用例量级上手成本等价类划分输入域太大无法穷举表单校验、数值范围、枚举类型低很低边界值分析临界点计算错误、比较符号写反分页、限额、时间区间、版本号比较低很低判定表/因果图多条件组合下的规则遗漏折扣、风控、权限、计费中中正交实验多参数多水平全组合爆炸兼容性、配置项、协议参数中较高场景法业务流程断链、异常分支缺失下单、支付、审批流中低状态迁移状态机非法跳转、漏状态订单、工单、设备状态中中错误推测历史踩坑、异常操作全场景补充低依赖经验选型的判断依据其实就三条输入空间能不能穷举、条件之间有没有组合关系、有没有时序和状态。能穷举的直接枚举不能穷举但条件独立用等价类加边界值条件互相影响上判定表参数组合爆炸正交降维有先后顺序和状态必须画状态图。我一般的工作流是先画业务流程图和状态图把主干路径理清楚再对每个输入点做等价类划分和边界值提取条件复杂的地方补判定表最后用错误推测法扫一遍补充。整个过程走完用例集的骨架就有了剩下的才是填充具体数据。注意不要为了用方法而用方法。一个只有两个输入项、逻辑直白的接口硬套判定表只会让文档臃肿到没人看。方法服务于覆盖率不服务于形式感。2. 黑盒设计方法逐个拆解配上能直接抄的例子2.1 等价类划分把无限输入切成有限几块等价类划分的核心假设是同一类输入在程序里的处理路径相同测一个就能代表整类。所以要把输入域切成若干个有效等价类和无效等价类有效类取一个代表值无效类每个都要单独测因为不同错误输入的报错分支往往不同。举个天天遇到的例子某商城后台商品定价输入框需求写的是单价 0.01 到 99999.99 元最多两位小数。我们来切有效等价类只有一个0.01 ≤ 值 ≤ 99999.99 且小数位 ≤ 2。代表值取 99.99 就行。无效等价类要拆细值为空、非数字字符、负数、0、小于 0.01 的正数、大于 99999.99、小数位 3 位及以上、超长数字串比如 20 位、前后带空格、科学计数法表示。每一条对应一个独立的校验分支必须各出一条用例。这里有个新手常犯的错把输入 abc和输入 !#当成一个等价类。看起来都是非法字符但实现层面一个是字母判断一个可能是正则整体不匹配报错提示都可能不一样。无效等价类的划分标准是有没有走不同的处理逻辑不是输入长什么样。实操心得等价类划分做完后养成习惯回头对一遍错误提示文案。如果需求里为某个非法输入定义了专门的提示语那它就是一个独立等价类别合并。2.2 边界值分析缺陷最爱藏在临界点上边界值分析是等价类的搭档。因为开发在写if (amount 99999.99)的时候手滑写成的概率远高于把整个判断逻辑写反。所以边界附近要加密采样。标准做法是取三个点上点边界本身、离点刚好越过边界的最近值、内点边界内侧的正常值。以上面的金额为例下边界0.01上点、0.00离点、0.02内点上边界99999.99上点、100000.00离点、99999.98内点但金额这种连续量有它自己的坑。浮点精度是重灾区。开发用 double 存价格0.01 在二进制里是无限循环小数0.01 0.02 0.03在某些语言里返回 false。所以除了常规边界还得补精度截断是否正确输入 1.005 是四舍五入到 1.01 还是截断成 1.00、累加是否出现尾差100 件 0.07 元的商品总价是不是 7.00 而不是 6.999999。金额相关问题一律建议核对是否使用定点数或整数分单位。还有几类边界特别容易被忘掉我列个清单数量边界列表返回条数为 0、1、恰好等于分页大小、分页大小 1时间边界跨天、跨月、跨年、闰年 2 月 29 日、夏令时切换有海外业务时长度边界字符串长度为 0、1、刚好等于上限、上限 1注意这里要区分字符数和字节数中文名 20 个字可能是 60 字节数值类型边界int 最大值、long 最大值、超过 JS 安全整数范围的 ID最后一条尤其值得说。订单号、用户 ID 这类字段如果用了 19 位以上的数字前端 JS 用 Number 接收时会丢精度末尾几位变成 0。这个问题的触发条件恰好就在数值边界上你不去测就永远发现不了。2.3 判定表与因果图多条件组合的逻辑陷阱当一个结果由多个条件共同决定时用等价类和边界值就不够用了因为条件是互相影响的。这时候上判定表。判定表的做法列出所有条件桩输入条件和动作桩输出动作穷举条件的真假组合为每种组合指定动作然后合并等价规则。看个例子某平台的优惠规则条件用户是会员是/否、订单金额满 200是/否、有可用优惠券有/无、本单是首单是/否。动作折扣力度分为 95 折、9 折、8 折、不打折。四个条件全组合是 16 条规则。写出来之后会发现很多条结果相同可以合并比如非会员且金额不满 200这个条件下后面两个条件怎么取值都不影响结果那这 4 条就能压成 1 条。合并后可能只剩 7 到 8 条。每条保留的规则出一条用例这就是最小的完备集合。判定表真正的价值不在压缩用例而在暴露需求里的逻辑空洞。你把 16 种组合列全经常能发现几种组合需求里压根没定义——比如会员 有券 首单三重重叠时到底能不能叠加使用这种空洞如果不提前问清楚开发会自己拍一个测试再按自己理解测最后线上出现有的人能叠有的人不能叠。因果图本质上是判定表的前置步骤用图形方式理清条件之间的与、或、非关系。实际工作中我很少真的画因果图直接列判定表更快但遇到条件之间有因果链A 导致 BB 又和 C 共同决定 D时画一下能防止自己绕晕。2.4 正交实验参数组合太多时的降维打法兼容性测试是正交实验最典型的战场。假设要测一个 H5 页面因素有操作系统iOS 15、Android 12、Android 14、浏览器内核Safari、Chrome、微信内置、屏幕尺寸小、中、大、网络类型WiFi、4G、弱网。四个因素各三个水平全组合是 3^4 81 种。81 种全测不现实。正交实验的思路是用一张设计好的正交表挑出 9 组左右保证任意两个因素的所有水平组合都至少出现过一次。这叫两两覆盖。用的是 L9(3^4) 正交表用例系统内核屏幕网络1iOS 15Safari小WiFi2iOS 15Chrome中4G3iOS 15微信大弱网4Android 12Safari中弱网5Android 12Chrome大WiFi6Android 12微信小4G7Android 14Safari大4G8Android 14Chrome小弱网9Android 14微信中WiFi9 条用例把 81 种组合压到九分之一而且任意两列之间的 9 种水平配对都出现了。这意味着如果存在某系统 某内核的双因素交互缺陷一定能被抓到。代价是三因素及以上的交互缺陷会漏比如只有iOS Safari 小屏三者同时出现才触发的布局错乱可能就被跳过了。所以正交实验有一个前置判断**这些因素之间会不会产生三方以上交互**如果会就得选更高阶的正交表或者对高风险组合补测。我的经验是UI 兼容性类的问题大多是单因素或双因素正交够用但涉及协议参数、硬件配置的场景多因素交互很常见这时候正交只能作为基线重点组合还得手工补。参数怎么选也有讲究。水平和因素不是越多越好优先挑历史上出过问题的因素。比如某机型以前出现过软键盘遮挡输入框的问题那它就值得作为一个独立因素进表而不是被合并到屏幕尺寸里。2.5 场景法与状态迁移业务流程和状态机的覆盖前面几种方法都在处理单点输入但业务系统的大部分风险在流程和状态上。用户不会按你设计的路径走他会在支付页面按返回、会在提交后连点两次、会在订单已发货时申请取消。场景法的基础是基本流和备选流。以商城下单为例基本流是选商品 → 加购物车 → 结算 → 选地址 → 选支付方式 → 支付成功 → 订单创建一路顺畅。然后为每个环节设计备选流库存不足、地址被删除、优惠券过期、支付超时、支付成功但回调延迟、订单创建失败但钱已扣。这里最值钱的备选流是部分成功。系统由多个服务组成A 成功了 B 失败了怎么办钱扣了订单没建、库存锁了支付没完成、优惠券用了订单被取消——这些不一致状态是线上工单的主要来源而且几乎不会在需求文档里写清楚必须测试主动提出来。状态迁移法则是把对象的所有状态和允许的跳转画成一张图。订单的状态大概是待支付 → 已支付 → 待发货 → 已发货 → 已签收 → 已完成另外还有已取消、退款中、已退款等分支。设计用例时合法的跳转要各测一遍非法的跳转更要测已取消的订单能不能再次支付已发货的订单能不能改成已取消退款中的订单能不能再次申请退款已完成订单能不能回退到待发货非法跳转往往对应着越权或者并发问题。我见过一个典型案例订单取消和支付是两个接口用户点取消的同时点了支付两个请求并发到达最后订单状态变成了已取消但钱扣了。这种问题只有把状态迁移和并发结合起来设计用例才能覆盖到。2.6 错误推测法与探索式测试经验怎么沉淀成清单错误推测法听起来最不科学但实际杀伤力最大。它的本质是把团队踩过的坑变成可复用的检查清单。我维护过一份叫老坑清单的文档按模块分类每条写清楚触发条件和现象。比如列表页在数据为空时是否显示了正确的空状态还是显示暂无数据但分页控件还在输入框粘贴超长文本时是否触发了长度校验很多前端只校验了键盘输入表单提交按钮是否做了防重复点击连续点 5 次产生 5 个订单时间显示在跨时区时是否正确服务端返回 UTC前端是否转换修改密码后旧 token 是否立即失效分页最后一页删光数据后页码是否越界报错长列表滚动到底部再切 Tab是否出现数据错位探索式测试则是给测试人员一段有主题的自由时间带着明确目标去自由发挥边测边记录。它和随机乱点完全是两回事必须有时间盒、有测试章程、有记录。比如章程写成用 60 分钟探索优惠券在各种边界操作下的表现重点关注叠加和回退场景。错误推测法还有个现代变体把线上监控和工单数据反哺到用例库。每次线上问题修复后强制补一条对应的回归用例。坚持半年用例库的质量会有一个质变。3. 拿一个真实业务场景走一遍完整设计流程3.1 需求拆解商城优惠券下单场景需求原文大意是用户在商品详情页可以领取优惠券下单时选择使用优惠券分满减券和折扣券满减券有使用门槛折扣券有最高优惠上限同一订单只能用一张券券有有效期部分商品不参与优惠券活动。拿到这段需求先别急着写用例做三件事第一列出所有参与对象用户、商品、优惠券、订单、支付单。每个对象都有状态都要单独理。第二找出所有规则和约束券类型、门槛、上限、叠加限制、有效期、商品范围限制、领取次数限制。第三标出模糊点。这段需求里至少有三处没说清楚折扣券和满减券能不能同时领但只能用一张还是连领都互斥部分商品不参与是按商品维度还是按类目维度订单退款后优惠券是否返还这些必须在写用例之前找产品确认否则用例写完了还得重写。3.2 从等价类到正交表的落地过程先处理优惠券本身这个输入项。券类型有满减和折扣两类各自的有效性条件有是否在有效期内、订单金额是否达门槛、是否已被使用、是否已过期、是否属于当前用户。用判定表整理规则在有效期达门槛未使用属于本人商品参与结果R1是是是是是可用R2是是是是否不可用提示不支持R3是是否是是不可用提示已使用R4是否是是是不可用提示未达门槛R5否—是是是不可用提示已过期R6是是是否是不可用提示非本人券注意 R5 那种带—的行就是条件无关的情况可以合并。这就是判定表在压缩用例。再处理下单主流程用场景法基本流一条备选流包括未登录下单、库存不足、地址失效、券不可用、支付超时、支付后回调延迟、订单创建失败。这里要特别注意备选流和基本流的交叉——券在结算页校验通过但支付时券已被其他订单占用这是典型的并发场景。参数组合部分用正交。因素定为券类型满减/折扣/无券、订单来源App/小程序/H5、支付方式余额/第三方、商品类型参与活动/不参与。四因素各二水平全组合 16 种用 L8(2^7) 正交表取 8 条即可覆盖所有两两组合。3.3 用例颗粒度控制一个用例最多检查几项这个问题被问得特别多网上答案也是五花八门。我的原则是一个用例只验证一个业务断言但可以包含多个为了完成这个断言所必需的准备步骤和辅助校验。具体点说一条使用满 200 减 30 的券下单订单金额正确抵扣的用例里面会包含登录、加购、领券、结算、选券、确认金额、提交订单。这里面只有订单金额 商品金额 - 30是核心断言其他都是步骤。这没问题。但如果一条用例同时验了金额抵扣正确、订单状态变成待支付、库存扣减正确、优惠券状态变成已使用那就是四个断言了。一旦失败你得逐个排查到底是哪一个不满足定位成本翻倍。建议一条用例的强断言不超过两个且这两个必须强相关。还有个细节准备数据不要写进用例步骤里当作断言。比如登录后余额为 100 元这是前置条件用数据准备脚本或者 SQL 预置别写成验证点。把前置条件当成校验点是导致用例脆弱、换个环境就跑不通的主要原因。3.4 接口层用例与 UI 层用例的分工同一个业务场景接口层和 UI 层的用例设计策略完全不同。接口层关注的是边界、异常和契约。比如下单接口要测的是字段缺失、类型错误、越权用 A 的 token 下 B 的券、参数篡改前端传的金额是 1 元但商品实际 100 元后端有没有重新计算、幂等同一个 requestId 重复提交只产生一个订单、并发同一个券同时被两个请求使用。这些在 UI 上基本测不了或者测起来成本极高。UI 层关注的是交互和呈现。券的选择弹窗有没有按门槛正确置灰、可用券和不可用券的分组是否正确、金额展示是否保留两位小数、券码超长时是否截断显示。我的做法是接口用例为主干UI 用例为点缀。核心业务逻辑的覆盖全部放在接口层跑得快、可自动化、定位准UI 层只保留必要的用户路径和展示类用例。一个典型商城项目的比例大概是一千条接口用例配两百条 UI 用例。4. AI 辅助生成测试用例能帮上什么忙哪里不能信4.1 从 PRD 到用例草稿的可用链路这两年用 AI 生成测试用例已经成了常规操作但我见过太多人用法不对。直接把需求文档整篇丢进去说帮我生成测试用例出来的东西看着很全实际上全是验证页面正常显示验证功能可用这种废话。比较靠谱的链路是这样的先人工做需求拆解把功能拆成独立的功能点每个功能点整理成结构化的输入输出描述再交给 AI 生成草稿。比如上面那个优惠券场景我会先拆成领券券列表展示结算页选券金额计算券核销退款退券六个功能点每个功能点单独喂给 AI。这样做的原因是AI 对局部逻辑的穷举能力很强对跨模块的业务上下文理解很弱。你把整篇 PRD 给它它会抓住那些描述得最详细的段落大做文章对描述简略但逻辑复杂的部分反而一笔带过。拆成小粒度之后每个点的输入输出都明确它的表现会好很多。另外一个有效技巧是让 AI 先做等价类划分再接生成用例。提示词里明确要求先列出所有有效等价类和无效等价类再为每个等价类生成用例产出质量明显比直接生成高因为划分的过程强迫它对输入空间做了一次系统梳理。4.2 提示词与 skills 怎么写才不产出废话用例专门给测试用例写一套可复用的提示词模板比每次现编效果好得多。我的模板大概是这个结构角色你是一名有8年经验的测试工程师擅长等价类划分、边界值分析和场景法。 输入[这里是功能点的结构化描述包含输入项、取值范围、业务规则、前置条件] 要求 1. 先用表格列出所有输入项的等价类有效/无效分开标注每个等价类的代表值。 2. 再为每个等价类生成测试用例用例格式为用例编号 | 前置条件 | 操作步骤 | 预期结果。 3. 必须覆盖以下维度字段为空、字段超长、特殊字符、并发重复提交、权限越权。 4. 预期结果必须具体到可验证的数值或状态禁止出现显示正常功能正确这类表述。 5. 如果输入描述中有信息缺失或逻辑矛盾先列出你的疑问不要自行假设。 约束不生成UI样式类用例不生成与输入无关的通用用例。最后两条特别关键。禁止出现显示正常这条能过滤掉大部分废话。逻辑矛盾先提问能帮你在生成阶段就发现需求漏洞——AI 会指出你说券不参与活动但又说活动商品可以用券这两条冲突这种提示有时候比用例本身还值钱。至于网上说的专门写测试用例的 skills本质上就是把这类模板固化下来再配上团队自己的用例格式规范和业务术语表。术语表很重要把券活动价到手价这些内部词汇的定义喂进去产出才不会张冠李戴。4.3 AI 产出的用例必须过的三道校验我个人的铁律AI 生成的用例一条都不能直接进用例库必须过三关**第一关事实校验。**逐条核对涉及的业务规则是否和需求一致。AI 很擅长编造合理的业务规则比如它可能默认优惠券可以叠加使用而你的需求明确写了不能叠加。这种错误看着无害但会让测试结论完全跑偏。第二关可执行性校验。检查前置条件是否能在测试环境构造出来预期结果是否有明确的判定依据。AI 经常写出验证数据库中的库存字段为 99这种预期但没告诉你哪个库哪张表哪个字段执行的人还得自己找。第三关去重校验。AI 在批量生成时重复率相当高同一个边界值可能出现在三条用例里。我一般会按功能点 输入项 预期结果做一次去重通常能砍掉两到三成。三道走完AI 节约的时间大概是生成 100 条用例到可用 60 条比起纯手工效率提升还是很明显的但如果你以为能省掉全部人力那就要出事了。4.4 复杂领域里的落地边界在车载以太网这类领域AI 生成用例的可用度会明显下降。原因很简单这类系统的知识密度高、公开语料少、且高度依赖硬件和时序。举个具体例子车载以太网涉及 SOME/IP 服务发现、DoIP 诊断、gPTP 时间同步、TSN 流量调度、VLAN 优先级映射这些机制。让 AI 生成验证 gPTP 主从时钟切换后同步精度在 1 微秒内这样的用例它能写出格式正确的一段话但它没法告诉你这个精度指标从哪来、用什么设备测、采样多少个周期才有统计意义。这类领域正确的用法是让 AI 处理结构化的、边界清晰的测试点人工负责机制性的、需要协议理解和硬件配合的部分。比如让 AI 生成诊断报文长度字段填充错误时的异常处理用例这个是可行的让 AI 设计多播组加入退出的时序用例几乎不可能靠谱。还有一个现实约束AI 生成的用例没法覆盖那些需要真实物理环境才能触发的场景比如线束接触不良导致的偶发丢包、温度变化引起的时钟漂移。这些必须靠台架测试和实车验证。5. 常见问题与排查技巧实录5.1 用例写了没人执行、执行了发现不了缺陷问题出在哪这两个抱怨在团队里出现的频率极高但原因完全不同。用例没人执行通常不是态度问题是用例本身不可执行。常见表现前置条件写得含糊用户已登录但没说用哪个账号、什么权限依赖的数据被别的用例改掉了步骤里涉及了需要人工等待十几分钟的操作。解决办法很直接前置条件必须精确到具体账号和状态数据用脚本自动准备超过两分钟的等待用 Mock 或者改成接口级验证。一条用例如果需要超过 10 分钟才能执行完它大概率会被跳过。执行了发现不了缺陷多半是断言太弱。最典型的弱断言是页面跳转正常什么叫正常URL 对了元素都渲染了还是数据正确正确的写法是把断言落到具体值上订单号与数据库记录一致、金额字段等于 199.00、状态字段等于 PAID。还有一个隐蔽的原因用例是被自动化跑了但断言写得太宽松。比如接口自动化只断言 HTTP 状态码是 200而业务错误其实也是 200 返回body 里 code 是 500。这种用例跑一万遍都是绿的一点价值都没有。5.2 高频问题速查表现象可能原因排查方向处理建议边界值测试全部通过线上仍出边界缺陷边界定义错误或存在隐式转换核对需求中的比较符号检查数据类型转换补测类型转换和精度相关场景同一用例换环境跑不通前置数据依赖环境差异对比两环境的初始化脚本数据准备脚本化禁止手工造数组合场景总有遗漏只用了单因素方法检查是否存在条件耦合补判定表或正交表状态相关缺陷反复出现未覆盖非法跳转和并发检查状态图是否完整补充非法跳转和并发用例AI 生成用例重复率高提示词未约束去重检查提示词模板增加去重要求和格式约束回归用例越来越多跑不完未做用例分层统计各用例的历史发现缺陷率按优先级分层淘汰零命中的低价值用例5.3 我踩过的几个坑最后分享三个我自己实实在在踩过的坑都是文档里不会写的东西。第一个坑把用例数量当成绩。早年我做项目交付的时候特别得意写了八百条用例结果评审的时候被问这八百条里有多少条是真正能发现问题的答不上来。后来我养成了一个习惯每条用例都标注设计来源来自哪个等价类、哪条边界、哪条业务规则评审的时候一眼能看出哪些是从业务风险推导出来的哪些是凑数的。标注之后我的用例总数反而降了将近一半缺陷发现率没降。第二个坑过度依赖历史用例库。有段时间我接手一个迭代很快的项目图省事直接拿上个版本的用例改改就用。结果新版本改了默认排序规则旧用例里所有涉及列表顺序的断言全部失效跑出来的失败一大堆排查了两天才发现是断言本身过时了。从那以后我坚持一个原则需求变更评审时必须同步评估受影响用例宁可当场改不要留到执行阶段猜。第三个坑在弱网和并发场景上偷懒。这两个场景的共同特点是构造成本高、复现概率低所以特别容易被这次先跳过。但我负责过的几个大版本上线后最严重的两个问题一个是并发下单导致的超卖一个是弱网下支付回调丢失导致订单卡在待支付。这两个场景现在是我每个版本的必测项哪怕是手工模拟限速也得跑一遍。一个小技巧把并发用例做得简单可复用。写一个脚本同时发 N 个请求参数从配置文件读换业务的时候只改配置不改脚本。这样构造成本降下来之后就不会再找借口跳过了。另外还有一个关于用例维护的心得。用例库最怕的不是写得不全是没人敢删。我建议每季度做一次用例健康度盘点把过去一年从未发现缺陷、且对应的功能模块也没有变更的用例降级归档。腾出来的执行时间投入到新业务和高风险模块上整体的缺陷发现效率会明显提升。这个动作我坚持做了两年用例总数从三千多降到两千出头但每个版本的缺陷发现数量反而涨了。至于用例设计这件事本身我的看法是方法是死的判断是活的。你能不能在需求评审的时候一眼看出哪句话埋着坑能不能在别人都在测正常流程的时候想到去测那个如果这才是经验真正的价值所在。工具和 AI 都是加速器方向还是得自己拿。