做测试这十来年被问得最多的一句话就是用例怎么设计才算够。新人上手通常是拿到需求文档打开表格从第一条需求开始往下写输入框能输什么、按钮点了会怎样、页面跳不跳。这么写出来的用例跑起来也能发现 bug但只要版本一大、逻辑一复杂问题就暴露了——要么漏得离谱要么写了八百条互相重复的用例把回归时间撑到三个小时。真正把用例质量拉开差距的不是写得多快而是脑子里有没有一套成体系的测试用例设计方法。等价类划分、边界值分析、判定表、因果图、正交实验法、场景法、错误推测法这七个方法不是七个需要背下来的知识点而是七把不同用途的工具用对了能把无穷的输入组合压成几十条高价值的用例用错了就是白写。这篇内容面向的是刚入行一两年的测试同学以及需要给团队做用例评审的负责人我会把七个方法逐个拆开讲清楚什么时候用、怎么用、容易在哪翻车每个方法都配一个能直接抄的案例最后附上我这些年踩坑攒下来的排查速查表和经验条目。1. 七个方法不是知识点清单而是一套分工体系1.1 从照着需求写到按方法设计中间差的是什么很多人写用例的默认动作是翻译需求写了一句金额输入框支持 0.01 到 50000 元就写一条输入 100提交成功。这条用例当然没错但它对一个字段的覆盖几乎是零。字段的取值域是连续的你不可能穷举但你可以用等价类把连续域切成若干段用边界值把切缝上的三个点钉住这样十几条用例就能覆盖住这个字段 95% 以上的风险面。这就是设计和翻译的区别——设计是有意识地做取舍翻译只是机械搬运。另一个常见的差距在于可追溯性。按方法设计出来的用例每条都能回答我为什么写这条它覆盖的是哪个等价类、哪条判定规则、哪条状态迁移路径。评审的时候别人问这个场景为什么没测你能立刻指出它属于哪个已经覆盖的等价类或者明确指出这是本次范围外的风险。而按需求逐句翻译出来的用例被问到漏测时只能回答文档里没写这句话在评审会上基本等于承认失职。所以我把这七个方法的价值总结成一句话它们让你在有限的时间和用例条数里做出可解释、可评审、可复用的覆盖决策。1.2 七个方法各自的主战场先给一张全景图后面再逐个展开。这七个方法可以粗分成三类数据类方法等价类划分、边界值分析。处理对象是单个或少数几个输入字段的取值域目标是用最少的用例覆盖最多的取值。逻辑类方法判定表、因果图。处理对象是多个条件之间的组合逻辑目标是把条件组合和对应动作一一对齐不漏不多。流程与经验类方法正交实验法、场景法、错误推测法。正交处理多因子多水平造成的组合爆炸场景法处理端到端的业务链路错误推测法负责用经验去补前面六种方法都覆盖不到的边角。这个分类很重要因为最常犯的错误就是拿错工具。比如一个会员等级 × 券类型 × 是否首单 × 支付渠道的优惠计算逻辑有人上来就用等价类划分把每个条件单独拆开测一遍。单条件确实都过了但会员 首单 折扣券这种组合触发的叠加 bug 根本测不到。这类问题必须用判定表或因果图。反过来一个只有上下限的年龄输入框你去做判定表就是杀鸡用牛刀四条规则里有两条还是互斥的。1.3 方法选型的判断依据我在团队里给新人总结过一张选型表照着输入特征对号入座基本不会错输入特征首选方法主要产出常见误用单字段有明确取值域或取值范围等价类划分 边界值分析有效/无效等价类表、边界点用例只测有效值无效值一条不写多个条件共同决定一个结果判定表条件桩、动作桩、规则列条件写得太粗规则列漏项条件之间有明确因果依赖、约束因果图因果图 判定表转换图只画不转画完就丢3 个以上因子每个因子多个水平正交实验法正交表、因子水平表盲目上全组合用例量失控端到端业务流程、跨模块交互场景法基本流、备选流、异常流用例只写正常流异常流靠现场临时想需求模糊、历史 bug 高发模块错误推测法经验用例清单当成主方法用覆盖面不可控对象有明确的状态流转状态迁移法状态迁移图、路径覆盖表只测正向流转回退和非法迁移不测提示一张表里出现四种以上输入特征时不要只挑一个方法。通常是数据类方法处理字段、判定表处理规则、场景法串流程三层叠起来才完整。选型只是一半另一半是顺序。我的习惯是先做场景法把主干流程铺出来让整个测试范围有个骨架再用判定表和因果关系把每个业务节点里的规则逻辑补上最后用等价类、边界值把每个具体字段的取值打磨一遍收尾的时候拿错误推测法扫一遍历史 bug 清单。这个顺序走下来用例集既有骨架又有血肉评审的时候也容易讲清楚。2. 等价类划分与边界值分析把无穷输入压成有限用例2.1 等价类划分的实操逻辑等价类划分的核心假设是如果某个输入值能触发缺陷那么它所在的整个取值范围里其他值大概率也能触发同一个缺陷。所以只要从每一类里挑一个代表值测一次就够了。这句话说起来简单实操时最容易出问题的是划分的粒度。举个例子一个提现金额输入框需求写的是单笔提现 0.01 元至 50000 元且不能超过可用余额。很多人会划成两个等价类有效0.01 ~ 50000、无效其他。这个划法漏掉了什么漏掉了格式类无效和业务类无效的区别。输入-5、abc、0、100.999、1e3、空格、超长数字串这些在代码里走的是完全不同的校验分支——有的是前端正则拦掉有的是后端 BigDecimal 解析报错有的是业务规则拒绝。它们的错误提示文案、日志记录、是否触发风控全都不一样。把它们笼统归成无效等价类只测一个-5等于放掉了六七个分支的验证机会。我的做法是把无效等价类至少拆成三层格式无效非数字、超长、特殊字符、科学计数法、边界无效0、负数、超上限、业务无效金额超过可用余额、小于手续费、超过单日限额。每一层再配合边界值方法补充具体点位。收尾的时候拿错误推测法扫一遍历史 bug 清单。这个顺序走下来用例集既有骨架又有血肉评审的时候也容易讲清楚。另外提醒一点划分等价类一定要看代码或者接口定义不要只看需求文档。需求说金额最多两位小数代码里用的是setScale(2, RoundingMode.HALF_UP)那输入0.005到底是拒绝还是进位成0.01只有看代码才知道。这类需求没写、代码有实现的分支是用例设计里性价比最高的富矿。2.2 边界值不是取最大最小值那么简单边界值分析经常被简化成取最小值、最大值、比最小值小一点、比最大值大一点这个理解只对了一半。边界点的选取要跟着等价类的切分方式走而切分方式取决于代码里的判断符号是还是。假设上限是 50000代码写的是if (amount 50000) reject;那 50000 本身是合法的边界点应该取49999、50000、50001。如果代码写的是if (amount 50000) reject;那 50000 就是非法的边界点变成49999、50000最后一个点是非法值。这两种写法的 bug 只有在取到精确点位时才会暴露测 49999 和 50001 都发现不了。还有一种更隐蔽的边界精度边界。金额字段上限 50000、两位小数那49999.99是合法最大值50000.00是边界50000.01越界。同时还要测0.01、0.001三位小数是否被截断或拒绝、0.004四舍五入是否变成 0、0.005是进位还是拒绝。这几个点位测完基本能把金额字段的坑挖干净。我把边界值常用的取点策略整理成一张表直接照着填边界类型取点典型意义数值范围min-1, min, min1, max-1, max, max1验证与的差异精度最小精度 ± 半个精度单位验证舍入策略长度len-1, len, len1验证截断与超长拒绝循环次数n-1, n, n1验证分页、批处理阈值时间临界时间点前后一分钟验证定时任务、有效期判断2.3 案例分析提现金额字段的完整用例集把上面两个方法合起来用一个提现金额字段的用例集大概长这样编号输入值覆盖的等价类/边界预期结果TC-01100.00有效正常区间提交成功进入确认页TC-020.01有效边界下限提交成功TC-0349999.99有效边界上限内侧提交成功TC-040无效边界下限外提示金额需大于 0TC-05-1无效负数提示金额格式错误TC-0650000.00无效边界上限提示超出单笔限额TC-0750000.01无效边界上限外提示超出单笔限额TC-080.001无效精度超限提示最多两位小数TC-090.005精度边界舍入需确认舍入策略后断言TC-10abc无效非数字前端拦截不发起请求TC-111e5无效科学计数法前端拦截或解析失败TC-12空字符串无效空值提示必填TC-13仅空格无效空白字符提示必填TC-14余额 1无效业务上限提示超出可用余额TC-15余额业务边界等于余额提交成功十五条用例覆盖了一个字段看起来不少但比输入 100 提交成功、输入 abc 报错两条用例强了不止一个量级。这十五条里TC-04、TC-06、TC-09、TC-14 是我在实际项目里真正抓到过 bug 的尤其是 TC-09 那个舍入点前后端用的舍入模式不一致前端显示 0.01、后端存成 0对账直接对不平。注意边界值用例的断言一定要精确到提示文案 是否发起请求 数据库落库值三个层面。只断言页面弹出错误提示很可能漏掉虽然提示了错误但还是发了一次请求这种幂等性问题。3. 判定表与因果图多条件组合下的不漏不炸3.1 判定表的四要素与化简判定表是处理组合逻辑最稳的工具它把条件和动作放在一张表里每一列代表一条规则。标准结构包含四部分条件桩列出所有条件、动作桩列出所有可能动作、条件项每个条件在各规则下的取值、动作项每个规则下执行哪些动作。还是那句提醒判定表的难点不在画在条件桩的提炼。条件写粗了规则列会漏条件写细了规则数会指数爆炸。我的经验是先把条件按是否真正影响结果筛一遍把不影响结果的条件剔除。比如一个优惠券计算逻辑最初列了七个条件包括用户注册时间、是否绑定手机号实际推下来这两个条件对优惠结果毫无影响直接从条件桩里删掉规则数从 128 列降到 32 列。第二个化简手段是利用无关项。当某个条件的取值不影响最终动作时条件项里填-这一列可以和其他列合并。上面 32 列经过无关项合并通常能压到 8 到 12 列这才是可执行的规模。3.2 因果图用在哪什么时候可以跳过因果图的价值在于处理条件之间的约束关系常见的有四类互斥E两个原因不能同时成立比如普通用户和会员用户。包含I至少有一个原因成立比如手机号登录或邮箱登录至少走一个。唯一O有且仅有一个成立。要求R一个原因成立时另一个必须成立比如用了折扣券要求订单金额达标。判定表本身表达不了这些约束硬画会画出大量实际不可能出现的规则列。因果图的作用就是先把约束标出来再转成判定表时把这些无效列直接划掉。不过说实话实际项目里我很少完整画因果图。原因很现实画图工具不统一、评审时没人愿意看图、需求变更后图很难维护。更常见的做法是直接列判定表然后在条件桩旁边用注释标明约束关系比如注C1 与 C2 互斥不出现同真组合。效果等价维护成本低得多。因果图我会在两种情况下真的画一是逻辑复杂到用表格描述不清二是需要跟产品经理对齐需求理解的时候一张图比十行表格更容易达成共识。3.3 案例分析优惠券叠加规则需求描述订单金额满 100 元可用满减券会员在满减券基础上可再叠加会员折扣折扣券与满减券不可叠加不满足门槛时提示不满足使用条件。条件桩C1订单金额 ≥ 100C2用户为会员C3持有满减券C4持有折扣券动作桩A1应用满减券A2应用会员折扣A3应用折扣券A4提示不满足使用条件化简后的判定表规则R1R2R3R4R5R6C1 金额≥100YYYYNNC2 会员YYNN--C3 满减券YNYNYYC4 折扣券NYNY--A1 应用满减券XXA2 应用会员折扣XXA3 应用折扣券XXA4 提示不满足XX六个规则列对应六条用例。R1 是最容易出 bug 的满减券和会员折扣的叠加顺序会直接决定最终价格先减后折和先折后减结果不一样而且往往差几分钱到几块钱这个差异只有测出来才会被发现。R5 和 R6 是回归时最容易被砍掉的两条因为不满足条件看起来不涉及金额计算但实际项目里我遇到过门槛判断用的是优惠前金额还是优惠后金额不一致导致的越权使用就是靠这两条抓出来的。提示判定表的每一列都要落成一条可执行用例并且用例标题里写清楚规则编号比如TC-R1 满减券会员订单金额≥100 应同时减免。回归时被砍掉哪条规则一目了然。4. 正交实验法与场景法组合爆炸和端到端流程的两把刀4.1 正交表的选型与因子水平计算组合测试的痛点是乘法效应。三个因子每个三个水平全组合是 3×3×3 27 种四个因子就是 81 种上了五个因子、每个四个水平直接是 1024 种。你不可能全测无脑抽样又容易漏掉两两组合的交互缺陷。正交实验法解决的就是这个问题它用精心构造的表让任意两个因子的所有水平组合都至少出现一次而用例总数远小于全组合。常见的正交表记法是L9(3^4)含义是 9 行、每个因子 3 个水平、最多容纳 4 个因子。注意最多 4 个因子这个说法如果只有 3 个因子用这张表的前三列就行多余的列空着不写。三个因子取 3 个水平时全组合 27 条正交后 9 条压缩率 67%。下面是一张L9(3^4)的前三列直接可用用例因子A因子B因子C111121223133421252236231731383219332你可以在任何一行任何一列上验证任意两列的水平组合都出现且仅出现一次。这就是正交表的正交性。实操中有个坑要提醒因子和水平必须先做筛选。我见过有人把内存大小、屏幕分辨率、操作系统、浏览器、语言、时区全都塞进正交表结果九个用例每个都要重新装环境执行成本远超收益。正确做法是先做一轮风险筛选只保留历史上出过问题和本次版本改动涉及的因子。通常三到四个因子就够了水平数控制在三以内。4.2 场景法基本流、备选流、异常流场景法是把系统当成一个用户旅程来看按事件流组织用例。标准做法是先定义基本流一切顺利的主干路径再从中分岔出备选流用户选了另一条合法路径和异常流出错、超时、中断、回退。这三个流的关系可以这么理解基本流是高速公路备选流是匝道异常流是事故和封路。只测基本流的测试相当于只在天气最好的白天开过一次车然后就宣布这条路没问题。场景法最容易漏的不是异常流而是流的组合。比如支付超时后用户返回订单页重新支付这条路径它跨了支付模块和订单模块既不是纯粹的基本流也不是纯粹的异常流是两者的组合。这类路径在真实用户里出现频率很高但用例设计时极容易被忽略因为写用例的人脑子里是按模块分的不是按用户旅程分的。4.3 案例分析下单支付全流程基本流进入商品页 → 加入购物车 → 结算 → 选择地址 → 选择支付方式 → 支付成功 → 订单状态变更为已支付。从这个主干分岔出来的场景场景编号场景类型关键路径断言重点S-01基本流全流程顺利支付订单状态、库存扣减、支付流水S-02备选流结算时修改地址运费重算、地址快照S-03备选流使用优惠券后支付实付金额、优惠明细S-04异常流支付超时未支付订单进入待支付超时库存回滚S-05异常流支付成功但回调延迟订单最终一致性S-06异常流支付中用户手动返回订单不重复、不脏写S-07组合流支付失败后重新支付不重复扣款、库存正确S-08组合流支付成功后申请退款退款金额、库存是否回滚S-05 和 S-07 是重灾区。S-05 涉及异步回调本地订单状态和支付平台状态可能短时间不一致如果前端没有做轮询或者轮询间隔太长用户会看到已支付但订单显示待支付然后第二次点击支付。这就串到了 S-07——重复支付。这两个场景必须一起设计、一起断言单独测其中一个都发现不了完整问题。注意异常流用例一定要明确写出预期恢复行为。例如支付超时后库存回滚是立即回滚还是延迟 30 分钟回滚这个策略不同断言的时间点就不同。写用例时不写清楚执行的人只能凭感觉等结果就是时好时坏的偶发失败。5. 错误推测法与状态迁移法经验兜底与状态补位5.1 错误推测法怎么做得有据可依错误推测法经常被误解成凭感觉瞎猜这其实是把它用废了。真正有效的错误推测是有输入来源的我一般从四个地方取材第一是历史缺陷库。把过去三个版本该模块的 bug 单拉出来按类型归类看哪些是重复出现的。比如某模块连续三个版本都出过并发下单库存超卖那这一条就必须进用例集而且优先级最高。第二是开发实现方式。用例评审时问一句这块是怎么实现的往往能问出关键信息。比如开发说用了本地缓存做去重那你立刻要想到缓存过期、缓存与数据库不一致、多实例部署缓存不共享这三个场景。第三是变更影响面。本次版本改了哪些文件、哪些接口、哪些配置项改动点周边的逻辑就是风险高发区。这类推测不需要经验只需要看 diff。第四是同类系统的公开经验。支付、库存、优惠计算这些通用场景行业里踩过的坑高度相似直接拿过来做检查清单比自己从头想效率高得多。这四个来源里第二条的性价比最高也最容易被忽略。很多测试同学拿到需求就直接写用例根本不和开发聊实现结果测的全是需求文档表面上的东西。5.2 状态迁移法把系统当成一台状态机状态迁移法适用于有明确状态流转的对象比如订单、工单、审批单、账号。做法分三步先列出所有状态再列出所有合法的迁移路径最后补上所有非法迁移路径。第三步是关键也是绝大多数人跳过的一步。非法迁移指的是从当前状态直接跳到某个不该到达的状态比如订单从待支付直接跳到已完成或者已取消的订单再次发起退款。这类操作可以通过接口直接调用、修改 URL 参数、重放请求等方式触发正常页面操作走不到但攻击者和异常客户端能走到。我常用的做法是画一张状态迁移表行是起始状态列是目标状态格子填合法/非法/不适用。这张表填完用例数量自然就出来了而且不会有遗漏。5.3 案例分析订单状态机与非法迁移以订单为例状态包括待支付、已支付、待发货、已发货、已完成、已取消、退款中、已退款。起始状态目标状态合法性用例要点待支付已支付合法正常支付待支付已取消合法用户取消、超时取消已支付待发货合法系统自动流转待发货退款中合法发货前退款已发货已完成合法确认收货、超时自动完成已完成退款中合法售后退款待支付已完成非法接口直调应拒绝已取消已支付非法需验证状态校验已退款退款中非法需验证防止重复退款已取消已发货非法需验证发货状态校验已取消 → 已支付这条非法迁移我在两个项目里都真的抓到过问题。原因是支付回调接口只校验了订单号存在没有校验订单当前状态用户在支付页停留很久订单因为超时被取消了用户这时候付款回调进来直接把状态改成已支付然后系统给一个已经释放了库存的订单发货直接造成超卖。这类 bug 靠页面点击是永远测不出来的必须用状态迁移表加接口直调才能覆盖。6. 从方法到用例库落地执行的几个关键动作6.1 用例模板字段怎么设计方法学得再好落到表格里字段设计不对一样会乱。我在团队里推的模板必填字段是这几个用例编号模块前缀 三段式比如ORDER-PAY-001方便按模块筛选和关联自动化脚本。设计方法标注这条用例是用哪个方法设计的。这个字段看着虚作用很大——评审时一眼能看出方法分布是否失衡如果整个模块全是错误推测说明前面的方法都没用上。前置条件必须写成可复现的状态比如账号 A 有 1000 元余额、账户状态正常而不是用户已登录。含糊的前置条件会让用例在不同人手里跑出不同结果。操作步骤一步一个动作不要合并。输入金额并点击提交要拆成两步因为这两步可能分别在两个端做校验。预期结果分层写UI 层、接口层、数据层各写一句。只写 UI 层的用例测不出数据层的问题。优先级P0 到 P3。P0 是冒烟必跑P1 是回归必跑P2 按需P3 是低频边界。字段之外还有一条规矩一条用例只验证一个点。把三个断言塞进一条用例里失败的时候你根本不知道是哪一个先崩的排查成本翻倍。6.2 用例数量与优先级的控制用例数量没有一个绝对标准但有一段经验区间。一个中等复杂度的业务模块按七个方法走完通常能产出 80 到 150 条其中 P0 不应该超过 15 条。如果 P0 有 50 条说明优先级定义失效了——什么都重要等于什么都不重要。控制数量的两个手段一是合并同参数不同数据的用例用参数化方式表达比如十五条金额用例可以合并成一条参数化用例加一张数据表二是裁剪重叠用例定期做一轮用例盘点把连续三个版本都没失败过的 P3 降级或者归档。这里我要说一句可能不太讨喜的话用例条数不是工作量证明。我见过有人为了显示自己测得全面把一个字段写了四十条用例结果真正的业务规则覆盖漏洞一个没补。评审的时候我只看两个数字——方法分布的均衡度和 P0 用例对核心业务的覆盖比例。6.3 评审、维护与自动化衔接用例评审最怕开成朗读会。我的做法是评审前把用例发给产品和开发评审时只讨论三类条目标注了设计方法为判定表/状态迁移的规则型用例、涉及金额和状态变更的高风险用例、以及所有 P0 用例。其他条目快速过。维护上我习惯在每次版本上线后做一次用例回流把线上发现的 bug 反向补成用例标注来源是线上缺陷并把它放到对应的方法分组下。有个规律很有意思——线上 bug 补出来的用例超过七成属于场景法的异常流和状态迁移法的非法迁移这两类恰恰是手工写用例时最容易被跳过的地方。自动化衔接方面参数化程度高的用例等价类、边界值、正交表最适合先自动化因为这些用例结构统一、断言明确、数据可外部化。判定表和状态迁移的用例自动化成本相对高一些因为它们往往跨多个接口和状态。我的顺序是先自动化边界值和正交用例做冒烟再逐步把场景法的主干流做成端到端脚本。# 边界值用例参数化的写法数据外置方便维护和复用 import pytest CASES [ (TC-02, 0.01, pass, 下限有效), (TC-04, 0, fail, 下限外), (TC-05, -1, fail, 负数), (TC-06, 50000.00, fail, 上限命中), (TC-07, 50000.01, fail, 上限外), (TC-08, 0.001, fail, 精度超限), (TC-09, 0.005, depends, 舍入边界需确认策略), ] pytest.mark.parametrize(case_id, amount, expect, note, CASES) def test_withdraw_amount_boundary(case_id, amount, expect, note): result withdraw_api.submit(amountamount) assert result.status expect, f{case_id} {note} failed这段代码里我最想强调的不是写法而是最后那条TC-09的depends状态。遇到行为不确定的用例不要假装它确定了把它标出来等和开发确认策略后再补断言。冒充确定的结果就是在给未来埋雷。7. 常见问题排查与避坑实录7.1 问题速查表把团队里高频出现的几类问题整理成表遇到时直接对号入座现象常见根因排查方向处理建议用例数量很多但漏测明显方法单一全是需求翻译统计用例的设计方法字段分布强制补充判定表和场景法用例同一功能多条用例结果不一致前置条件描述含糊检查前置条件是否可复现前置条件写死具体数据边界用例全部通过但线上出问题只测了数值边界没测精度和类型补精度边界、类型边界增加半精度点和格式无效类组合场景 bug 反复出现只做单条件测试检查是否有判定表用例用判定表补组合规则回归时间越来越长P0 定义失效用例只增不减统计 P0 占比和失败率设 P0 上限定期归档低价值用例偶发失败查不出原因断言只到 UI 层检查是否断言了接口和数据层分层断言补充日志关联接口直调能绕过状态校验未测非法迁移用状态迁移表逐格核对补非法迁移用例并推动加校验7.2 几条用血换来的经验第一条先和开发聊十分钟胜过自己闷头写两小时。前面提过好几次这里再强调一遍。很多分支逻辑需求文档里根本不写比如金额为空时默认按 0 处理还是直接报错这种差异决定了你的用例断言完全不同。花十分钟问清楚实现方式能省下大量返工。第二条不要相信这个字段前端已经限制了。前端限制只能拦住普通用户接口直调、抓包改包、模拟器调试都能绕过去。所有关键校验都必须有一条跳过前端直接调接口的用例。我在实际项目里抓到的最严重的一个越权问题就是通过直接调用接口传了一个页面上根本选不到的参数值触发的。第三条异常流的恢复行为要写清楚不能只写报错。支付超时这条用例如果只写预期结果是提示支付超时那执行的人测完就走了根本不会去看库存有没有回滚、优惠券有没有退回、订单有没有进入可重试状态。异常流的价值恰恰在这些后续动作上。第四条用例的命名比用例的步骤更重要。一条用例叫测试提现功能三个月后没人知道它测了什么叫提现金额 0.005 应按既定舍入策略处理后落库任何人一看就懂。命名这件事花不了多少时间但决定了用例库能不能长期维护下去。第五条把设计方法当成一种自我检查。每次写完一个模块的用例我会看一眼方法分布。如果发现全是等价类和边界值说明这个模块的业务逻辑我还没吃透规则型用例一条都没设计出来。这个检查动作很简单但每次都能让我回去补上一批判定表和场景法用例。第六条接受覆盖不完备这件事但要让不完备是已知的。没有任何一套用例能覆盖所有路径这是事实。但我知道这里没覆盖因为风险低、成本高所以我主动放弃了和我不知道这里没覆盖是两回事。前者可以写进测试报告后者是线上事故的伏笔。所以我的习惯是在用例集最后留一节本次未覆盖项及原因说明把边界外的情况、低概率的组合、依赖外部环境的场景明确列出来评审时大家一起确认。这套方法我用了几年从最开始只会写等价类到后来慢慢把判定表和状态迁移用熟中间踩的坑大多集中在用错工具和跳过异常流这两件事上。真正让用例质量提升的往往不是多学一个方法而是把手上这几个方法用对位置——单字段的用等价类和边界值打磨干净多条件的用判定表钉死规则跨模块的用场景法和状态迁移串起来最后拿错误推测法扫一遍边角。等你哪天写完一个模块的用例能一眼看出哪些条是用哪个方法设计出来的时候这套东西基本就算长在脑子里了。