企业官网建设流程全解析

上周帮一个朋友看他团队新整理的测试用例库，一千两百多条，表格拉了好几屏。我随手翻了三条登录相关的用例，发现问题都差不多：要么是“输入正确的用户名密码，登录成功”这种正确但没用的废话，要么是“随便输个错的，看会不会报错”这种执行时根本没法照做的模糊描述。这两种用例凑数可以，真到版本上线前当验收依据，是撑不住的。

设计测试用例这件事，表面看是写文档，本质上是把“这个功能该怎么被验证”这件事想清楚、写明白、传下去。它解决的是三个问题：测什么、怎么测、测到什么程度算过。不管你是刚入行的功能测试，还是带了几人的测试小组长，甚至是被拉来兼职验收的产品同学，只要你要对着一个功能给出“它到底行不行”的判断，用例设计就是绕不过去的基本功。测试用例设计方法等价类、边界值、场景法这套东西，很多人背过概念，但落到具体需求上就不知道怎么下笔，这篇就把我自己这些年写用例的完整思路和踩过的坑摊开讲。

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 位，必须包含大小写字母和数字”：

你看，光一个密码字段就能拆出九类。如果只写一条“输入合法密码”和一条“输入非法密码”，那覆盖度连及格线都够不上。划分完之后，从每个等价类里挑一到两个代表值去设计用例，覆盖度就上来了，而且用例数量并没有爆炸。

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（无效，缺数字）、Abc@1234（无效，含特殊符）、含空格（无效）、空值（无效）。注意长度和字符类型的组合，程序的校验顺序会影响最终提示信息，所以组合场景也要覆盖。

验证码字段，等价类 + 场景：正确的 4 位数字、错误的 4 位数字、正确的验证码但用小写输入（如果验证码是字母数字混合，不区分大小写是需求明确点，那这里要测）、验证码已过期（等 60 秒后再提交）、点击刷新后用旧验证码、空验证码。验证码这块有个隐藏坑：刷新和提交的时序问题。用户点刷新拿到新验证码，但页面还留着旧的请求没回来，这种情况下新验证码可能被旧响应覆盖，导致用户输新的反而提示错误。这个是场景组合，单独测验证码字段是测不出来的。

锁定逻辑，场景法 + 状态验证：连续错 4 次不锁定、第 5 次锁定、锁定后正确密码也登不进、锁定期间错误密码提示什么、10 分钟后自动解锁（可以用改数据库字段或改服务器时间的方式模拟）、解锁后错误次数是否清零、A 账号锁定是否影响 B 账号从同一设备登录。锁定逻辑的坑在于计数器的存储位置和清零时机。计数器存在内存里重启就丢，存在缓存里过期时间设置错就会提前解锁，存在数据库里又要考虑并发写入。这些细节决定了用例要覆盖哪些场景。

登录成功后的状态，场景法：跳转首页、刷新页面保持登录、关闭浏览器重新打开保持登录、清除 Cookie 后是否退出、7 天后登录态过期（验证 token 有效期）。这部分最容易漏的是“登录态在多个标签页之间是否同步退出”，比如一个标签页点了退出，另一个标签页是否还停留在登录状态。

3.3 用例要素怎么填才规范

候选用例出来了，接下来要落成标准格式。一份完整的用例，我通常包含这几个字段：

优先级这里多说一句。很多人标优先级是靠感觉，我自己的标准是：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 常见问题速查表

这张表我一般放在团队 wiki 的显眼位置，新人遇到问题先查表，查不到再来问。

5. 让用例真正跑起来：数据、执行与度量

5.1 测试数据从哪来，怎么造

用例写得再好，数据不对也跑不起来。测试数据的来源主要有三种：手工构造、脚本生成、生产脱敏。手工构造适合小规模、逻辑复杂的数据，比如一个特定状态的订单；脚本生成适合大批量、规律性强的数据，比如一千个不同手机号的用户；生产脱敏适合贴近真实分布的数据，但要严格处理敏感信息。

造数据最容易踩的坑是数据依赖。比如测“下单”需要先有商品、有库存、有收货地址、有可用的优惠券。这些前置数据如果每次都要手工准备，执行效率会低到无法接受。我的做法是把高频依赖的数据固化下来，写成初始化脚本或者用固定的测试账号。每次回归前跑一遍初始化，保证起点一致。

还有个细节是数据的隔离。多人同时执行用例时，如果都在同一套数据上操作，很容易互相干扰。比如 A 在测删除用户，B 在测该用户的订单查询，结果 B 的数据被 A 删了。解决办法是每个执行者用独立的数据命名空间，或者用数据池轮换。

数据准备这块我还想强调一点：不要用生产数据直接测。哪怕脱敏，也要走审核流程。用户手机号、地址、订单金额这些，一旦泄露后果很严重。测试环境的数据能造则造，确实需要生产数据的话，必须脱敏并且限定使用范围。

5.2 用例和自动化怎么衔接

不是所有用例都适合自动化，这个判断很重要。适合自动化的用例有几个特征：执行频率高、步骤稳定、结果可断言、数据可准备。接口层的参数校验、边界值、状态码验证，这些天生适合自动化。而 UI 交互复杂、依赖人工判断（比如视觉效果）、执行频率低的用例，手工执行更划算。

我的分工思路是：接口自动化承接校验类用例，UI 自动化承接核心流程用例，人工承接探索性和体验类用例。接口自动化的投入产出比最高，因为它稳定、快、容易维护。UI 自动化脆弱性高，页面改个元素定位就挂，所以只自动化最核心的那几条主流程，别贪多。

用例和自动化脚本的关系，我的做法是一条用例对应一个自动化脚本，用例编号作为脚本的标识。执行报告里按用例编号统计通过率，这样用例库和执行结果是对齐的，不会出现“用例库里有但自动化没覆盖”或者“自动化跑了但用例库里找不到对应项”的混乱。

还有一点经验：自动化用例也要定期评审和淘汰。产品逻辑变了，对应的自动化脚本可能还在跑，但断言的是过时的预期，这种脚本就是负资产。我一般每个大版本过一遍自动化用例，把失效的、冗余的清理掉，保持脚本库的精简。

5.3 用哪几个指标判断用例有没有价值

用例库的价值不能靠“条数”衡量。我自己看三个指标。

第一个是需求覆盖率。把需求拆成可验证点，统计有多少个点被至少一条用例覆盖，覆盖比例是多少。低于 90% 就该查漏了。这个指标直接反映用例库的完整性。

第二个是缺陷发现率。统计每轮测试中，通过用例执行发现的缺陷数占总缺陷数的比例。如果大量缺陷是靠探索性测试发现的，说明用例库设计得不够，覆盖不到真实的 bug 集中区。这个指标反映用例库的有效性。

第三个是执行成本和收益比。统计跑一轮全量用例需要多少人时，发现了多少有效缺陷。如果跑一轮花了两天，只发现两个小问题，那这份用例库就需要瘦身了。降低执行成本的办法前面说过：合并、自动化、淘汰过时用例。

这三个指标不用天天看，每个版本复盘的时候过一遍就行。指标不好的时候，重点不是改数字，而是回头检查用例设计的思路哪里出了问题。

最后分享一个我自己一直在用的小习惯：每写完一批用例，我会随机抽三条，假装自己是第一次接触这个功能的人，从头到尾执行一遍。如果执行过程中有任何一次犹豫——不知道该点哪里、不确定数据填什么、不清楚结果对不对——那这条用例就还没写完，回去改。这个习惯帮我挡掉了很多“看起来写完了但实际没法用”的用例，也让我的用例库在团队里一直有人愿意用。用例这东西，写给人看的成分，比写给系统看的成分大得多。