上周帮一个朋友看他团队新整理的测试用例库一千两百多条表格拉了好几屏。我随手翻了三条登录相关的用例发现问题都差不多要么是“输入正确的用户名密码登录成功”这种正确但没用的废话要么是“随便输个错的看会不会报错”这种执行时根本没法照做的模糊描述。这两种用例凑数可以真到版本上线前当验收依据是撑不住的。设计测试用例这件事表面看是写文档本质上是把“这个功能该怎么被验证”这件事想清楚、写明白、传下去。它解决的是三个问题测什么、怎么测、测到什么程度算过。不管你是刚入行的功能测试还是带了几人的测试小组长甚至是被拉来兼职验收的产品同学只要你要对着一个功能给出“它到底行不行”的判断用例设计就是绕不过去的基本功。测试用例设计方法等价类、边界值、场景法这套东西很多人背过概念但落到具体需求上就不知道怎么下笔这篇就把我自己这些年写用例的完整思路和踩过的坑摊开讲。1. 先想明白测试用例到底在替谁干活1.1 用例不是交差文档是提前做过的风险推演很多人写用例的心态是“需求评审完了任务派下来了总得写点东西证明我在干活”。这个出发点一歪用例就会变成凑数的产物。我更愿意把用例理解成一次提前进行的风险推演在代码还没写完、甚至还没开始写的时候我就把“用户会怎么折腾这个功能”“系统在什么情况下会掉链子”先在纸上过一遍。这个视角的转变很关键。当你把它当交差文档你会关心“写够多少条”当你把它当风险推演你会关心“还有哪种输入、哪种操作顺序、哪种环境组合我没考虑到”。前者产出的是数量后者产出的是覆盖度。我在带新人的时候经常让他们做一个练习写完一批用例后把用例盖住只看需求文档自己凭记忆说这个功能有哪些地方可能出问题然后再对照用例看漏了哪些。漏掉的部分往往就是当时写用例时思维偷懒的地方。风险推演还有一个好处它天然带有优先级。一个电商下单流程付款金额计算错误的杀伤力远远大于页面文案换行位置的偏差。当你知道自己在防什么风险用例的优先级排序就不是拍脑袋定的而是按“这个点万一挂了会造成多大损失”来排的。后面讲用例要素的时候会具体说优先级怎么标但根子在这里你得先知道自己在防什么。1.2 一份能用的用例至少要满足哪三条标准我自己衡量一份用例合不合格看三条缺一条都算没写完。第一条是可执行。什么叫可执行就是把这条用例交给一个完全不了解这个需求的同事他照着步骤一步一步点能完整跑完并得出明确结论。如果你的步骤里写着“输入一个正常的手机号”那就不算可执行因为“正常”是相对的到底是 13800000000 还是 13800000001 还是带 86 前缀执行的人会卡在这里。可执行要求每个输入值都是确定的、每个操作都是有指向的。第二条是可判定。预期结果必须是一个能被客观验证的结论不能是“页面显示正常”“功能符合预期”这种主观描述。什么叫显示正常是跳转到首页还是弹出“登录成功”的 toast还是控制台没有任何报错这些要写死。我见过太多用例的预期结果写“验证成功”结果执行的时候两个人对“成功”的理解不一样一个说接口返回 200 就算成功一个说页面得跳转才算成功最后扯皮。第三条是可追溯。每条用例最好能对应到具体的需求点或设计点。这样做的好处是当需求变更的时候我能快速定位到哪些用例需要改当有人问“这个功能到底测没测”的时候我能拿出证据说测了用例第几条就是。可追溯性还能反过来帮你查漏把需求逐条列出来看每条需求挂了几条用例挂零的那条就是漏测风险最高的地方。1.3 从需求到用例中间隔着一层“测试点”新手最容易犯的错误是拿到需求文档就直接开始写用例。需求文档是写给开发和产品看的它的语言是“功能描述”用例是写给测试执行者看的它的语言是“验证动作”。中间缺了一层翻译这层翻译就是测试点。测试点是需求的“可验证原子”。一个需求可以拆成若干个测试点一个测试点可以展开成若干条用例。举个例子需求写“用户注册时密码长度要求 8 到 20 位必须同时包含大小写字母和数字”。这句话直接写用例你可能会写一条“输入符合要求的密码注册成功”。但拆成测试点它至少包含密码长度下边界、长度上边界、长度不足、长度超限、只含小写、只含大写、只含数字、大小写数字混合、含特殊符号、含空格、空密码。这些测试点再展开成用例覆盖度就完全不一样了。我自己的习惯是需求评审完之后先不写用例先列测试点清单。这个清单可能就十几行字但它是我和产品、开发对齐“这个功能要测到什么程度”的依据。有时候产品看到清单会主动说“这个点不用测内部约定就是这样的”那我就能省掉一批用例有时候开发看到会说“这个情况不可能出现我在前面就拦截了”那我就能把精力挪到更值得测的地方。测试点清单确认完再往下写用例效率和覆盖度都会好很多。2. 四个核心设计方法掰开揉碎讲2.1 等价类划分把无穷的输入变成有限的几类等价类划分的核心思想特别朴素如果一组输入数据在程序里走的是同一条判断逻辑那它们就是“等价”的测其中一个就够了。这解决的是输入空间无限的问题——你不可能把用户能输入的所有字符组合都测一遍但你可以把它们分成几类每类挑代表。划分的时候分两种有效等价类和无效等价类。有效等价类是符合需求的合法输入比如密码位数为 8 到 20 位那 8 到 20 位之间任意一个值都是有效等价类。无效等价类是不符合需求的非法输入比如长度 7 位、长度 21 位、包含中文字符、包含空格、空值这些各算一类甚至要拆得更细。这里有个实操里的关键点无效等价类要尽量拆细有效等价类可以适当合并。为什么因为程序对合法输入的处理路径通常是统一的出错概率低而对非法输入的处理路径往往是各种 if-else 分支每个分支都可能有 bug。你把“长度不对”和“字符类型不对”混成一类去测很可能只触发了长度校验分支就返回了字符类型的校验根本没走到那个分支的 bug 就漏了。举个具体的例子还是密码规则“8 到 20 位必须包含大小写字母和数字”等价类类型具体数据举例说明长度 8-20 且大小写字母数字齐全有效Abc12345标准合法输入长度不足 8 位无效Abc123长度下边界外的无效类长度超过 20 位无效Abc123456789012345678901长度上边界外的无效类只含小写字母和数字无效abc12345缺大写只含大写字母和数字无效ABC12345缺小写只含字母不含数字无效Abcdefgh缺数字含特殊符号无效Abc1234字符集越界含空格无效Abc 12345特殊字符的一种空值无效空字符串边界特殊情况你看光一个密码字段就能拆出九类。如果只写一条“输入合法密码”和一条“输入非法密码”那覆盖度连及格线都够不上。划分完之后从每个等价类里挑一到两个代表值去设计用例覆盖度就上来了而且用例数量并没有爆炸。2.2 边界值分析缺陷最爱扎堆的那几毫米如果说等价类划的是“面”边界值盯的就是“线”。程序里大量的判断逻辑都是“大于等于”“小于”“等于”这些判断的分界线附近是最容易出问题的地方。有个统计说法是超过一半的逻辑缺陷发生在输入域的边界上我自己实测下来虽然没这么夸张但边界值确实是性价比最高的方法。边界值分析有个口诀取上点、离点、内点。以密码长度 8 到 20 位为例上点正好落在边界上的值8 和 20。内点区间内部的值比如 14随便取一个用来确认正常范围处理没问题。离点紧挨着边界外侧的值7 和 21用来验证越界拦截有没有生效。所以边界值在这条需求上至少要覆盖 7、8、20、21、14 这几个数值。7 和 21 是无效的8 和 20 是有效的14 是有效区间内的对照。实操里还有几个容易忽略的边界陷阱我列一下字符串长度边界如果字段允许 0 到 50 个字符那空串、1 个字符、50 个字符、51 个字符都是要测的。空串尤其容易被漏很多程序对空串的处理和 null 处理是两条不同的分支。数值类型的最大值最小值比如数量字段允许输入 1 到 999999那 0、1、999999、1000000 要测还要注意超过 int 范围的处理。时间边界活动开始时间那一秒、结束时间那一秒、跨天跨月的时刻都是经典的高危区。特别是时区处理服务器时间和客户端时间不一致的时候边界处经常出幺蛾子。分页边界总条数刚好等于每页条数、比每页条数多一条、最后一页只有一条这些位置翻页逻辑容易算错。金额边界0 元、0.01 元、最大金额、刚好等于优惠券门槛的金额这些都是优惠计算逻辑最容易错的地方。我个人的习惯是凡是需求里出现了数字、长度、时间、次数这类可量化的描述第一反应就是把边界值列出来然后再用等价类去补中间区域。顺序上先边界后等价覆盖效率更高。2.3 场景法用业务流程把零散的用例串起来前面两个方法盯的是单个字段、单个条件但真实用户从来不会只操作一个字段。他会先登录再搜索再加入购物车再改数量再用优惠券最后付款。场景法解决的就是这种多步骤流程的验证问题。场景法的基本结构是基本流 备选流。基本流就是一切顺利的主流程每一步都按预期走备选流是主流程中任何一个环节出现异常或分支时走的路。用画图的方式会很清楚基本流是一条直线往下走备选流是从某个节点岔出去的支线。举个例子电商下单付款基本流登录 → 搜索商品 → 加入购物车 → 进入结算页 → 选择收货地址 → 选优惠券 → 提交订单 → 支付成功。备选流 1加入购物车时商品已下架。备选流 2结算时库存不足。备选流 3提交订单时网络超时。备选流 4支付时余额不足。备选流 5支付成功但页面没跳转用户重复点击支付。每一条备选流都要设计成独立的用例因为程序在每条支线上的处理逻辑都是不一样的。基本流只有一条备选流可能有很多条而且备选流往往是 bug 的高发区因为开发和产品在讨论需求的时候注意力大多放在主流程上异常分支经常被一笔带过。这里有个我踩过的坑备选流不要只测“异常发生”还要测“异常发生之后的状态”。比如库存不足导致下单失败失败之后购物车里的商品还在不在优惠券有没有被占用这些“后置状态”如果不验证很容易出现数据脏掉的问题用户下次操作就会看到莫名其妙的异常。还有一个更细的点多条备选流的组合。真实场景里异常往往不是单独发生的。比如网络超时的时候用户可能又点了两次提交这就是“超时 重复提交”的组合场景。场景法做到极致就是把这些组合也考虑进去。当然全组合会爆炸实际操作里按照风险高低挑最可能发生的组合来测。2.4 判定表与正交多条件组合怎么收敛当测试对象的输入条件有多个而且每个条件有多个取值输出结果又依赖于这些条件的组合时等价类和边界值就有点力不从心了。这时候要用判定表。判定表的结构很简单上半部分是条件桩列出所有输入条件下半部分是动作桩列出所有可能的输出动作表格的每一列是一种条件组合对应一个动作结果。还是用密码规则举例条件有“长度是否合法”“是否含大写”“是否含小写”“是否含数字”每个条件两种取值全组合是 2 的 4 次方等于 16 种。判定表会把 16 种组合都列出来然后逐列确定预期结果。但 16 种已经有点多了如果条件再多几个全组合就是指数级增长。这时候用正交实验法来抽样。正交表的好处是用最少的实验次数覆盖两两组合。比如四个三水平因子全组合是 81 次正交表 L9 只需要 9 次就能覆盖所有两两组合。测试里用正交就是接受“不测全组合但保证任意两个条件的组合都被覆盖到”。不过说实话日常功能测试里我自己很少严格去查正交表。更常用的做法是先用判定表列出全部组合然后人工判断哪些组合可以合并、哪些组合风险最高优先保留。真正需要正交法的场景一般是配置项特别多的功能比如打印模板设置、权限矩阵配置、促销规则叠加。这类功能的特点是配置维度多、组合结果差异大、手动穷举不现实。顺带提一个容易被忽略的方法错误推测法。它不是严格的方法论更多靠经验。比如你看到“导入 Excel”功能脑子里第一反应就是空文件、超大文件、格式错误的文件、表头带空格的、单元格里有公式的、单元格里有换行的。这些都是历史上被坑出来的直觉。错误推测法不系统但它补的是前面几种方法覆盖不到的“经验盲区”实际项目里非常好用。3. 实操演练给登录功能从零写一套用例3.1 需求拆解先把测试点列出来假设需求是这样的用户通过手机号 密码 图形验证码登录手机号必须是 11 位数字且以 1 开头密码 8 到 20 位且必须包含大小写字母和数字验证码 4 位数字不区分大小写连续输错密码 5 次锁定账号 10 分钟登录成功后跳转到首页并记住登录状态 7 天。拿到这个需求我不急着写用例先列测试点。按模块拆至少能拆出这几组第一组是手机号校验位数不足、位数超出、不以 1 开头、含非数字字符、空值、前后带空格。 第二组是密码校验长度下边界、长度上边界、长度不足、长度超限、缺大写、缺小写、缺数字、含特殊符号、含空格、空值。 第三组是验证码校验正确验证码、错误验证码、小写输入正确验证码、超时后输入、空验证码、点击刷新后旧验证码是否失效。 第四组是登录次数与锁定连续错 4 次不锁、第 5 次锁定、锁定期间用正确密码登录、锁定 10 分钟后自动解锁、锁定后换个账号是否受影响。 第五组是登录成功后的状态跳转是否正确、登录态是否保持、关闭浏览器再打开是否还在登录态、7 天后是否过期这个通常用改系统时间或直接看 token 过期时间来验证。 第六组是安全相关密码是否明文传输、接口是否做了频率限制、token 是否能被伪造这部分偏接口安全功能测试至少确认基本表现。把这六组列出来比一上来就写“输入正确用户名密码登录成功”要有方向得多。列测试点的过程其实就是我前面说的“把需求翻译成可验证动作”的过程。3.2 逐个方法套上去生成候选用例测试点有了接下来用方法把每个点展开。手机号字段用等价类 边界值位数 10 位无效下边界外、11 位有效、12 位无效上边界外、首位是 0无效、首位是 1有效、含字母无效、含特殊符号无效、空值无效。这里 11 位还要细分成“首位 1 且后面 10 位数字”和“首位 1 但后面含字母”因为程序可能先校验长度再校验字符两个分支要分别走到。密码字段等价类 边界值长度 7无效、8有效、20有效、21无效、Abc12345有效含大小写和数字、abc12345无效缺大写、ABC12345无效缺小写、Abcdefgh无效缺数字、Abc1234无效含特殊符、含空格无效、空值无效。注意长度和字符类型的组合程序的校验顺序会影响最终提示信息所以组合场景也要覆盖。验证码字段等价类 场景正确的 4 位数字、错误的 4 位数字、正确的验证码但用小写输入如果验证码是字母数字混合不区分大小写是需求明确点那这里要测、验证码已过期等 60 秒后再提交、点击刷新后用旧验证码、空验证码。验证码这块有个隐藏坑刷新和提交的时序问题。用户点刷新拿到新验证码但页面还留着旧的请求没回来这种情况下新验证码可能被旧响应覆盖导致用户输新的反而提示错误。这个是场景组合单独测验证码字段是测不出来的。锁定逻辑场景法 状态验证连续错 4 次不锁定、第 5 次锁定、锁定后正确密码也登不进、锁定期间错误密码提示什么、10 分钟后自动解锁可以用改数据库字段或改服务器时间的方式模拟、解锁后错误次数是否清零、A 账号锁定是否影响 B 账号从同一设备登录。锁定逻辑的坑在于计数器的存储位置和清零时机。计数器存在内存里重启就丢存在缓存里过期时间设置错就会提前解锁存在数据库里又要考虑并发写入。这些细节决定了用例要覆盖哪些场景。登录成功后的状态场景法跳转首页、刷新页面保持登录、关闭浏览器重新打开保持登录、清除 Cookie 后是否退出、7 天后登录态过期验证 token 有效期。这部分最容易漏的是“登录态在多个标签页之间是否同步退出”比如一个标签页点了退出另一个标签页是否还停留在登录状态。3.3 用例要素怎么填才规范候选用例出来了接下来要落成标准格式。一份完整的用例我通常包含这几个字段字段说明填写要点用例编号唯一标识用模块缩写 序号如 LOGIN-001所属模块归属功能便于按模块筛选和统计覆盖度用例标题一句话描述格式条件 动作 预期如“密码长度 7 位时提交登录”优先级P0/P1/P2P0 主流程和核心异常P1 次要异常P2 边缘场景前置条件执行前必须满足的状态如“已存在账号 13800000000密码 Abc12345”测试步骤一步步的操作每步一个动作不要合并测试数据每步用到的具体值写死不要写“正常值”这种模糊描述预期结果每步或最终的验证点具体到文案、跳转、接口返回用例类型功能/边界/异常/安全便于统计各类型用例占比优先级这里多说一句。很多人标优先级是靠感觉我自己的标准是P0 挂了就绝对不能上线包括主流程可用、核心数据正确、资金和权限相关P1 挂了可以评估上线包括次要流程、非致命异常提示、体验问题P2 挂了可以放到下个版本包括极端边界、低频操作、兼容性边缘。这个标准让优先级有了决策意义而不是一个装饰字段。用例标题的写法也值得说。差的标题是“登录功能测试”好的标题是“连续输错密码 5 次后账号被锁定 10 分钟”。标题本身就是一个小结看标题就能知道这条用例在验什么统计用例的时候也不用点进去看细节。我带的团队里要求标题必须包含“触发条件”和“验证结论”做不到就重写。3.4 评审与去重别让用例库变成垃圾场用例写完不是终点得评审。评审的时候我通常盯三件事重复、遗漏、不可执行。重复最常见于不同人写的用例合并时A 写了“密码错误登录失败”B 写了“输入错误密码提示密码错误”这两条本质是一条合并掉。去重不是简单地删而是把两条里更精确的描述保留下来。比如 A 的“登录失败”太模糊B 的“提示密码错误”更具体那就保留 B 的表述删掉 A。遗漏靠对照需求清单和测试点清单来查。把需求逐条拉出来问“这条需求对应哪些用例”挂零的就是漏。测试点清单同理。我自己还会做一件事把所有用例按执行顺序排一遍模拟一个真实用户的操作流看看有没有哪一步是断的。比如用例里有“登录成功”和“下单成功”但中间“加入购物车”没有用例那这个流就是断的。不可执行主要检查步骤和数据的确定性。评审的时候随便挑几条让没写这条用例的人照着念一遍看能不能顺畅执行。念到一半卡住的就是需要改的地方。这个方法很土但特别有效比一个人对着屏幕反复看要快得多。4. 踩过的坑常见问题与排查技巧4.1 为什么总觉得用例写不全写不全的根本原因通常不是方法不会而是对需求的理解停留在表面。需求说“支持上传头像”你写了一条“上传合法图片成功”这就算写完了吗远远不够。图片格式有哪些jpg、png、gif、webp、bmp、大小限制是多少、尺寸有没有要求、上传后能不能裁剪、能不能删除、上传失败怎么办、上传大文件时页面有没有 loading、断网后上传进度怎么处理、上传后是否立即生效还是需要审核……这些问题需求文档不一定写全但测试必须想到。我的经验是写不全往往发生在“我以为我懂了”的时候。真正的做法是拿着需求去问开发这个字段在后端是怎么校验的这个接口失败了返回什么这个状态存在哪里问的过程就是把隐藏的测试点挖出来的过程。开发随口一句“这里做了防抖”你就多了一组防抖相关的用例。另一个补全的办法是站在异常视角重新扫一遍。正常视角下你会想“用户会怎么正确使用”异常视角下你要想“用户会怎么把它搞坏”。断电、断网、重复提交、并发操作、超大数据量、特殊字符、越权访问这几招下去用例库能厚一倍。4.2 用例越写越多怎么瘦身用例多本身不是问题问题是执行不过来。瘦身的思路有几个层次。第一层是合并同类。同一个字段的多个无效等价类如果程序的处理逻辑和提示文案完全一致可以合并成一条用例测试数据用列表形式并列。比如密码缺大写、缺小写、缺数字如果都提示“密码格式不正确”那可以合并成一条“密码不满足复杂度要求时提交”测试数据写三组执行时跑三组数据但算一条用例。这样统计和执行都清爽。第二层是区分验收用例和探索用例。有些用例是必须每轮都跑的回归核心有些是一次性探索用的查 bug 用的。后者不需要进用例库长期维护记在个人笔记里就行。我见过太多团队把探索性的用例也塞进用例库结果每次回归都要跑一堆没意义的步骤浪费大量时间。第三层是用自动化承接高重复用例。接口层的参数校验、边界值这类用例执行成本低、重复度高特别适合自动化。放自动化之后人工回归只需要跑核心流程和新增功能用例库的“有效执行量”就上来了。后面第 5 节会细说。4.3 需求变更后用例怎么维护需求变更是不维护用例的最大借口也是最真实的痛点。我的做法是建立用例和需求的映射关系。每条用例标注它覆盖的需求编号或测试点编号需求变更时通过映射关系反查受影响的用例只改这些不用全量重写。映射关系怎么建简单做法是在用例表里加一列“关联需求”填需求文档里的编号。复杂一点的做法是用测试管理工具维护需求树和用例的关联。工具不重要重要的是这个动作要做。没有映射关系需求一变更用例库就慢慢腐烂到最后没人信它也没人用它。还有一个习惯是给用例打版本标签。比如 V1.2 版本的登录逻辑做了调整那我在调整的用例上标记“V1.2 修改”历史版本要用的时候还能查得到。这个在需要回溯“上个版本是怎么测的”的时候特别有用。4.4 常见问题速查表问题现象可能原因排查方向用例执行时步骤走不通前置条件缺失或步骤描述模糊补齐前置数据把每步操作写具体预期结果有争议预期描述太主观改成客观可验证的结论如文案、状态码用例数量爆炸无效等价类未合并、探索用例混入按处理逻辑合并拆出探索用例回归时漏测用例和需求没映射变更后没更新建立映射关系变更时反查受影响用例不同人对同一用例结论不同判定标准不统一明确验证点必要时补充截图或接口返回边界用例执行后仍然出 bug只测了边界值没测边界组合补充边界值与其他条件的组合场景这张表我一般放在团队 wiki 的显眼位置新人遇到问题先查表查不到再来问。5. 让用例真正跑起来数据、执行与度量5.1 测试数据从哪来怎么造用例写得再好数据不对也跑不起来。测试数据的来源主要有三种手工构造、脚本生成、生产脱敏。手工构造适合小规模、逻辑复杂的数据比如一个特定状态的订单脚本生成适合大批量、规律性强的数据比如一千个不同手机号的用户生产脱敏适合贴近真实分布的数据但要严格处理敏感信息。造数据最容易踩的坑是数据依赖。比如测“下单”需要先有商品、有库存、有收货地址、有可用的优惠券。这些前置数据如果每次都要手工准备执行效率会低到无法接受。我的做法是把高频依赖的数据固化下来写成初始化脚本或者用固定的测试账号。每次回归前跑一遍初始化保证起点一致。还有个细节是数据的隔离。多人同时执行用例时如果都在同一套数据上操作很容易互相干扰。比如 A 在测删除用户B 在测该用户的订单查询结果 B 的数据被 A 删了。解决办法是每个执行者用独立的数据命名空间或者用数据池轮换。数据准备这块我还想强调一点不要用生产数据直接测。哪怕脱敏也要走审核流程。用户手机号、地址、订单金额这些一旦泄露后果很严重。测试环境的数据能造则造确实需要生产数据的话必须脱敏并且限定使用范围。5.2 用例和自动化怎么衔接不是所有用例都适合自动化这个判断很重要。适合自动化的用例有几个特征执行频率高、步骤稳定、结果可断言、数据可准备。接口层的参数校验、边界值、状态码验证这些天生适合自动化。而 UI 交互复杂、依赖人工判断比如视觉效果、执行频率低的用例手工执行更划算。我的分工思路是接口自动化承接校验类用例UI 自动化承接核心流程用例人工承接探索性和体验类用例。接口自动化的投入产出比最高因为它稳定、快、容易维护。UI 自动化脆弱性高页面改个元素定位就挂所以只自动化最核心的那几条主流程别贪多。用例和自动化脚本的关系我的做法是一条用例对应一个自动化脚本用例编号作为脚本的标识。执行报告里按用例编号统计通过率这样用例库和执行结果是对齐的不会出现“用例库里有但自动化没覆盖”或者“自动化跑了但用例库里找不到对应项”的混乱。还有一点经验自动化用例也要定期评审和淘汰。产品逻辑变了对应的自动化脚本可能还在跑但断言的是过时的预期这种脚本就是负资产。我一般每个大版本过一遍自动化用例把失效的、冗余的清理掉保持脚本库的精简。5.3 用哪几个指标判断用例有没有价值用例库的价值不能靠“条数”衡量。我自己看三个指标。第一个是需求覆盖率。把需求拆成可验证点统计有多少个点被至少一条用例覆盖覆盖比例是多少。低于 90% 就该查漏了。这个指标直接反映用例库的完整性。第二个是缺陷发现率。统计每轮测试中通过用例执行发现的缺陷数占总缺陷数的比例。如果大量缺陷是靠探索性测试发现的说明用例库设计得不够覆盖不到真实的 bug 集中区。这个指标反映用例库的有效性。第三个是执行成本和收益比。统计跑一轮全量用例需要多少人时发现了多少有效缺陷。如果跑一轮花了两天只发现两个小问题那这份用例库就需要瘦身了。降低执行成本的办法前面说过合并、自动化、淘汰过时用例。这三个指标不用天天看每个版本复盘的时候过一遍就行。指标不好的时候重点不是改数字而是回头检查用例设计的思路哪里出了问题。最后分享一个我自己一直在用的小习惯每写完一批用例我会随机抽三条假装自己是第一次接触这个功能的人从头到尾执行一遍。如果执行过程中有任何一次犹豫——不知道该点哪里、不确定数据填什么、不清楚结果对不对——那这条用例就还没写完回去改。这个习惯帮我挡掉了很多“看起来写完了但实际没法用”的用例也让我的用例库在团队里一直有人愿意用。用例这东西写给人看的成分比写给系统看的成分大得多。