有不少刚转行做软件测试的朋友拿到需求文档的第一反应都是“我到底该测什么”。然后直接打开页面按正常流程点一遍发现没报错就算测完了。运气好点的知道要把输入框都输一遍边界数据但要他解释为什么这么测又说不出个所以然。等上线后用户报了一个压根没覆盖到的bug才后悔当初没好好设计用例。这个现象太普遍了。软件测试的核心工作不是“点按钮”而是“设计用例”。而测试用例设计方法就是把你脑子里那些零散的“要测一下这个、顺便看一下那个”变成一套有逻辑、可追溯、覆盖率可量化的工程方法。Day1我们讲了测试基础概念和整体流程今天这一篇专门把4大测试用例设计方法——等价类、边界值、判定表、场景法——掰开揉碎讲清楚。后面你面试、写用例、甚至进项目组和别人 review 用例靠的全是这些基本功。1. 为什么一定要学测试用例设计方法1.1 用例设计的底层逻辑把无限输入变成有限样例先说个扎心的现实任何软件系统的输入空间都是无穷的。一个年龄输入框可以输“18”、“-5”、“abc”、“1e10”、“%$#”、超长字符串、空字符串……你是测不完的。如果靠直觉去点同一类数据你重复测了十遍另一类数据一次没测过最后覆盖率完全不可控。测试用例设计方法解决的就是这个问题用一套规则把无穷的输入空间划分为有限的、有代表性的等价类再从每个类里挑出最有价值的样本去执行。这个思想其实生活中到处都在用。比如你要检查一箱苹果有没有烂你不会把每个苹果都啃一口而是按大小、颜色、产地抽样检查。测试用例设计就是“抽样检查”的工程化版本——但比抽样更讲究因为不同区域抽样的优先级不一样边界区域最容易藏 bug。所以你可以把这4个方法理解成4种不同的“抽样策略”等价类划分把输入按“处理结果是否相同”分桶每桶取一个代表。边界值分析专门盯着每个桶的桶壁附近取样因为 bug 往往长在边界上。判定表当多个条件组合起来决定动作时把所有“条件组合 → 动作”的关系列出来找出遗漏。场景法不再盯单点输入而是站在用户角度把完整操作流程串起来覆盖正常流、备选流、异常流。1.2 四个方法的定位不是单选题是组合拳很多初学者容易犯一个错把这4个方法当成4种“流派”觉得写用例前得先选一个再用。实际不是这样。我习惯把它们的定位说得更直白一点方法核心思路主要解决的问题典型应用场景等价类划分输入分桶每桶取代表值输入空间太大不知道怎么选数据所有输入框、下拉框、文件上传边界值分析盯着桶壁附近取值边界处最容易出“差一错误”数值范围、字符串长度、集合大小判定表条件组合与动作的全集多个条件共同决定结果组合覆盖不全登录、优惠计算、审批流规则场景法按用户操作流串用例单点测了但流程串起来会断下单、支付、注册、退改签看到这里你应该明白它们不互斥而是互补的。等价类是“主体框架”边界值是“重点补漏”判定表管“规则组合”场景法管“流程串联”。真正规范的用例设计过程通常是以需求文档为基础先画业务流程场景法再对每个处理节点做输入分析等价类边界值最后把关键业务规则抽出来做组合覆盖判定表。1.3 方法背后真正难的东西需求理解和隐性规则说实话这4个方法本身学起来不难边界值取点规则一节课就能讲完。真正难的是你对需求的理解。同一个字段需求写“年龄在18到60之间”你光知道边界值是18、60、17、61没用你还得搞清楚18和60算不算有效需求里写“18-60岁”到底是闭区间还是开区间有没有可能业务上还隐藏了“未成年不能用”这种规则但产品文档没写年龄字段是整数还是允许小数生日换算年龄的算法是向下取整还是四舍五入这些信息不对齐方法用得再熟练用例也是空中楼阁。所以我在日常带人的时候第一件事永远是让他们先把需求文档读三遍把不懂的地方列成问题去问产品而不是急着打开系统开始点。2. 边界值分析法最容易拿分也最容易踩坑的方法2.1 为什么 bug 都爱藏在边界上我先抛一个经典问题为什么边界值最容易出问题因为这个位置程序员最容易写错“大于号”和“大于等于号”。写代码的时候如果需求是“密码长度8到20位”开发可能会写if(len 8 || len 20)也可能写if(len 8 || len 20)。前者是8和20合法后者是9和19才合法。这种“差一错误”off-by-one error在真实项目里出现频率极高尤其是有多个判断条件叠加、或者多个接口各自实现一遍的时候。再举个更隐蔽的例子。以前我测过一个考勤系统需求上写“9:00之前打卡不算迟到”。结果开发在实现时用的是打卡时间 9:00还是打卡时间 9:00直接决定了一个正好 9:00:00 打卡的员工算不算迟到。这种问题你如果只测 8:59 和 9:01永远发现不了。只有把 9:00 这个精确边界测进去才能暴露。2.2 取点规则上点、离点、内点怎么取边界值分析的标准取法是围绕边界取“上点、离点、内点”三个点。先解释一下定义上点边界上的点也就是刚好等于边界值的输入。离点距离上点最近的那个、会在“合法/非法”状态上发生翻转的点。内点边界内的任意一个点一般取区域中间偏左或中间值。以闭区间[1, 10]为例点的类型取值说明上点1、10边界本身属于有效数据离点0、11紧挨着边界但已经翻转为无效的数据内点6或5中间任意一个有效值这里有一个新手非常容易犯的错误离点到底取多少有些人闭区间[1,10]取离点时会取-1和12甚至取-999和999。这当然也能测出“无效数据被拒绝”但它失去了“离点”的意义。离点的价值在于它和上点之间只差1专门用来捕捉“差一错误”。如果取-999程序和-1的处理逻辑大概率一模一样测不出边界翻转的那一行代码到底写没写对。还有一个需要重点强调的细节如果边界是开区间离点的取法要跟着变。比如输入条件为x 0也就是(0, ∞)这时候0是非法的上点不可用离点就要取1第一个合法值内点取一个较大的合法数。如果输入条件为x 0即[0, ∞)那上点是0离点是-1内点取一个正整数。很多资料会把这套规则叫“7点法”或“3点法”核心思路都一样——别死记公式先搞清楚区间开闭再找翻转点。2.3 实战举例一个订单金额输入框怎么测假设某个系统的订单金额输入框需求规定“金额范围为0.01元到999999.99元”精确到小数点后两位。先用边界值法取点点的类型取值预期结果上点0.01允许提交上点999999.99允许提交离点0.00提示“金额必须大于0”离点1000000.00提示“金额超出上限”内点500.00允许提交再补充小数位边界0.011到底算不算非法这就取决于需求是否“精确到小数点后两位”如果允许三位系统是四舍五入还是截断这个不在边界值分析的范围里但属于你设计用例时一定要去确认的需求细节。999999.994四舍五入后是999999.99那它到底合法还是非法不同系统处理方式可能完全不同。这种用例一旦设计出来你就会发现它比“随便输个100”高明得多。因为每个用例背后都对应着一个具体的开发逻辑分支测过了就说明这个分支是通的没测过你就不敢说自己是测过的。2.4 边界值不止用于输入框这一点我在教新人的时候会专门强调边界值分析绝不仅仅适用于普通的UI输入框。它适用于一切存在“边界”的地方列表分页每页显示20条第19、20、21条分别是上一页的末尾、当前页末尾、下一页的开头。接口测试请求参数里的数组长度0个元素、1个元素、最大限制、超过最大限制。文件上传文件大小限制10MB传9.99MB、10MB、10.01MB。内存与缓存缓存容量上限、淘汰策略刚好在临界点触发。算法输入比如数组索引、矩阵元素的行列下标越界判断。所以当你听到有人说“边界值就是测输入框的”你就可以判断这个人大概率只是个“工具人”测试还没形成方法论的迁移能力。3. 判定表法多条件组合校验的利器3.1 判定表长什么样条件桩、动作桩、规则列边界值解决的是“单个输入”的问题但真实业务里几乎不会有这么简单的情况。更多的场景是多个条件放在一起经过一段业务规则最终决定一个或几个动作。这时候就需要判定表。判定表的结构非常固定四个区域条件桩列出所有的输入条件。条件项每个条件取值的组合通常是“真/假”或“满足/不满足”。动作桩列出所有可能执行的动作。动作项在某一组条件下哪些动作执行、哪些不执行。举个最简单的例子。规则“会员且消费满100元打8折非会员消费满100元打9折不满100元不打折。”条件是三个是否为会员消费是否满100是否使用优惠券先不管我们可以建一个只含两个条件的判定表条件规则1规则2规则3规则4是否为会员是是否否消费是否满100是否是否动作打8折执行动作打9折执行动作不打折执行执行这样一张表4列就是4条规则每条规则对应一种条件组合。你不必拍脑袋想“会员满100要不要测”“非会员满100要不要测”因为全组合情况下所有情况天然都是要测的。3.2 判定表怎么画5步走在真正的项目里判定表不会像上面这么简单。我一般按下面这套流程来做明确条件把业务规则里所有的前置条件找出来一般用“是否”型描述。明确动作把规则触发后的结果或操作找出来。列出全组合2个条件是4种组合3个条件是8种组合n个条件是2的n次方种组合。先全部列出来。化简合并把动作完全相同、且某些条件对结果无影响的列合并成一个规则。比如发现“无论是不是会员只要消费不满100都不打折”那“会员 不满100”和“非会员 不满100”两列就可以合并成一条。写出用例每一列化简后的一条规则就是一组用例设计依据把它转成具体的输入数据和预期结果。第4步化简非常关键。不化简的判定表可能有几十列但化简后可能只剩十几列。这和你需求里规则的复杂程度有关。初学者喜欢把表画得又长又难懂其实就是化简没做好。3.3 实战案例登录功能的规则组合分析登录功能是面试和笔试里出现频率最高的案例因为它人人都用过又包含典型的多条件规则。假设这个登录功能有三个校验项用户名是否存在密码是否正确验证码是否正确动作有三种登录成功提示“用户名或密码错误”提示“验证码错误”提示“用户不存在”先列全组合理论上2 × 2 × 2 8种组合。但实际化简时你会发现如果用户名不存在密码和验证码是否正确已经没有意义界面只会提示“用户不存在”。所以这几种组合可以合并。化简后的判定表大致是规则用户名存在密码正确验证码正确预期结果R1是是是登录成功R2是是否提示验证码错误R3是否是提示用户名或密码错误R4是否否提示用户名或密码错误R5否任意任意提示用户不存在这里有一点值得和产品确认R3和R4到底是要提示“密码错误”还是统一提示“用户名或密码错误”如果产品想做防枚举攻击通常会统一用模糊提示不告诉你到底是用户名错了还是密码错了。这些业务层面的细节恰恰是判定表能帮你“可视化地暴露”出来的问题。3.4 判定表的适用边界与常见坑判定表不是万能的它有非常明确的适用条件适合的场景多个条件之间互相独立、组合关系可穷举、条件数量不太多一般不超过5~6个。比如优惠计算、运费计算、审批流程规则、会员等级判断。不适合的场景条件之间存在强依赖关系有些组合根本不可能出现比如“男 已怀孕”。条件数量太多比如有10个条件全组合就是1024种这时候判定表就失控了。实际项目中要先和产品确认哪些组合是有业务意义的只对有意义的组合做判定表其余的用等价类覆盖。我在实际项目里踩过一个坑某次做配置化规则引擎的测试规则条件有十多个我试图把所有组合都列出来结果列到一半自己都混乱了。后来和开发对齐发现很多组合在业务上根本不会出现直接从判定表里删掉最后只留了20多条有效规则。所以记住判定表的重点不是“全”而是“准”——把真正有业务含义的组合覆盖住。4. 等价类划分法用例设计的“基本盘”4.1 什么是等价类同一类里测一个等于测所有如果说边界值是锦上添花那等价类就是地基。等价类的核心假设是对于同一类输入程序的处理逻辑和结果是一样的。既然处理结果一样那从这一类里随便挑一个代表值去测就可以了。举个例子一个用户名输入框需求是“4到16位字母或数字”。我们可以把输入空间划分成这些类有效等价类4~16位字母/数字的组合。无效等价类A长度小于4例如“ab”。无效等价类B长度大于16。无效等价类C包含特殊字符例如“abc#”。无效等价类D包含中文。无效等价类E为空。这里每一个无效等价类都有一个不同的“错误原因”所以每类都要单独测。而有效等价类虽然也很多字母开头、数字开头、混合组合但程序走的是同一条分支测一个代表就够了。这就是等价类划分的精髓不是把所有可能输入都测一遍而是把所有“程序处理分支”测一遍。4.2 有效等价类和无效等价类的区别初学者最容易犯的毛病就是只测有效等价类不测无效等价类。为什么因为大部分人拿到需求后默认“用户会乖乖输入合法数据”。但真实用户不会用户可能输入乱码、空值、超长字符、复制粘贴带空格的内容。无效等价类尤其重要原因是程序要能优雅地拒绝非法输入而不是崩溃或产生脏数据。你可以回想自己遇到过的糟糕软件一个年龄输入框你输入“abc”它直接报错500你输入一个负数数据居然存进去了。这些问题背后就是无效等价类覆盖不足。这里有一个操作上的硬规则一个测试用例里只覆盖一个无效等价类。原因很好理解如果某个用例同时输入了“空用户名”和“错误格式的邮箱”页面报错后你根本无法判断到底是哪个问题触发的校验也不确定另一个无效输入是否被正确处理。而有效等价类之间关系不大可以合并到一条用例里。4.3 实战案例邮箱输入框的等价类划分注册页面有一个“邮箱”输入框需求描述“请输入有效邮箱地址长度不超过50个字符”。我按自己的工作习惯会把等价类表列成下面这样类别输入预期结果有效等价类testexample.com校验通过有效等价类边界长度刚好50字符的合法邮箱校验通过无效等价类缺少testexample.com提示邮箱格式不正确无效等价类缺少域名test.com提示邮箱格式不正确无效等价类多个testexample.com提示邮箱格式不正确无效等价类含空格test example.com提示邮箱格式不正确无效等价类为空空字符串提示邮箱不能为空无效等价类超长51个字符提示长度超限注意看这个设计思路我把“有效等价类里的边界长度”也单独列了一行这实际上就是等价类和边界值的结合用法。先用等价类把空间分桶再在每个桶的边界上补点——这就是4个方法真正的配合姿势。4.4 等价类划分的实际项目细节补充几个我在不同项目里用到的等价类划分细节这些都是面试或工作中很加分的点数值范围和业务语义要分开看。比如年龄字段“18到60”从输入校验的角度这是一个闭区间但从业务语义的角度年龄还可能有“是否是整数”“是否允许小数”等规则。等价类划分时不要只按范围分还要把数据类型整数/小数/负数/零/字母纳入考虑。枚举型字段也要做等价类。比如“性别”下拉框有“男、女、保密”这3个值本身就是3个有效等价类无效等价类包括“不选”“传入一个API里不存在的枚举值”。接口测试中最容易漏的就是“不存在的枚举值”这种用例往往能直接暴露后端枚举转换的异常。注意“可空”和“必填”是两套规则。如果字段非必填那么空值属于有效等价类如果字段必填空值属于无效等价类。这个要看清楚需求再决定不能想当然。5. 场景法从用户视角补齐流程级用例5.1 单点都对了流程还是断了这就是场景法要解决的前面讲的等价类和边界值都是从“某个输入框/某个参数”出发的。但真正上线出问题的地方往往是整个流程串联起来的时候。比如每个字段的校验都通过了但用户下单时加入购物车之后改地址改完地址返回结算页价格没刷新或者支付成功后回调通知延迟订单状态一直卡在“待支付”。这种问题你盯着单个输入框测一辈子也测不出来必须站在用户完整操作流程的角度去设计用例。场景法的核心思路是识别用户完成某个业务目标时的所有路径包括正常路径、分支路径和异常路径并为每条路径设计用例。我自己的习惯是拿到一个模块后先画流程主路径从入口到出口一步一步列出来然后再针对每一个步骤问自己“用户在这里可能不走正常路吗走岔了会怎样”5.2 基本流、备选流、异常流怎么区分场景法里有三个概念很多人分不清我用下单流程直接说明基本流从起点到终点的最核心、最顺利的那条路径。比如用户登录 → 浏览商品 → 加入购物车 → 提交订单 → 支付成功 → 订单完成。这条路径覆盖的是“软件最基本的价值”。备选流在某个节点走了另一个合法分支但最终还是能完成任务。比如加入了购物车但结算时使用了优惠券。提交订单时选择“货到付款”而不是在线支付。支付时切换了支付方式从支付宝切到微信。异常流在某个节点发生了错误或中断需要系统优雅地处理。比如未登录就点击“加入购物车”系统跳转登录页。提交订单后发现商品库存不足提示“库存不足”。支付过程中取消支付订单状态变为“已取消”或保持“待支付”。这里要特别注意每条备选流和异常流都不是独立的它们都是从基本流的某个点分叉出去的最后可能又回到基本流的某个点。所以设计用例时不是“测完基本流再测备选流”而是“基本流走一段 → 分支 → 回到基本流 → 再走一段”。5.3 场景法用例设计实例电商下单我拿电商下单举例给大家一个可以直接套用的思路。画出的流程节点大概是登录 → 浏览商品 → 加入购物车 → 结算页确认地址 → 提交订单 → 支付 → 查看订单状态基于这个流程我通常会先列一个场景清单场景编号场景描述覆盖路径S01正常下单支付基本流全程S02未登录直接加购从“浏览商品”分叉到登录再回基本流S03支付超时或失败支付节点分叉提示失败允许重新支付S04下单时修改收货地址结算页节点分叉改完地址继续S05库存不足提交订单时异常提示库存不足S06取消支付支付节点异常订单进入已取消状态S07使用优惠券下单结算页节点走备选流验证金额变化S08支付成功后查看订单基本流终点扩展验证状态和详情你会注意到这8个场景覆盖的远不止8条用例因为每个场景内部还可以继续插桩比如“支付失败”这个异常流里到底失败一次就返回还是允许重试3次每次重试有没有间隔限制这些细节又可以叠加等价类、边界值和判定表继续往下挖。所以场景法的真正用法是先用场景法搭起整个测试的骨架再把其他方法塞进每个场景里去填充肌肉和细节。5.4 场景法和状态迁移法的关系有些测试教材会把“状态迁移法”也单列出来。严格来说场景法和状态迁移法是两兄弟场景法更偏向“用户任务视角”描述的是用户和系统的交互流程状态迁移法更偏向“系统状态视角”关注的是系统在不同事件下状态的合法迁移。举个例子订单状态有“待支付、已支付、已发货、已完成、已取消”。状态迁移法会专门验证待支付 → 已支付、待支付 → 已取消、已支付 → 已发货、已发货 → 已完成这些都是合法的但是待支付 → 已发货就是非法的系统必须拦截。实际操作中如果被测对象的状态很多、状态流转很复杂比如订单、审批流我一般会先画状态图再基于状态图设计场景。如果状态很简单比如一个表单提交直接用场景法就够了。新手阶段我建议先把场景法用熟因为它的思维路径最贴合用户的真实行为。有了“先正常走一遍、再岔路走一遍、再故意走错一遍”的直觉后面学状态迁移法会轻松很多。6. 四大方法组合实战一个注册页面的完整用例设计6.1 需求描述光讲方法是纸上谈兵我拿一个在面试和实战里都极常见的“用户注册页面”作为例子带大家完整走一遍4个方法怎么配合。需求如下用户名4到16位只能包含字母、数字、下划线。密码8到20位必须同时包含字母和数字。确认密码必须与密码一致。手机号11位以1开头。6.2 用场景法搭骨架这个需求对应的主流程是进入注册页 → 填写表单 → 提交 → 注册成功 → 跳转登录页。备选流和异常流有场景说明正常注册所有字段合法提交成功用户名已存在提交时提示“用户名已被注册”手机号已注册提交时提示“手机号已注册”点击同意协议前禁止提交未勾选协议时按钮置灰提交后网络中断提示网络异常数据不丢失注意这里的“用户名已存在”和“手机号已注册”属于业务规则校验不是前端格式校验大概率要等请求返回才知道所以它们天然是判定表的候选场景。6.3 用等价类边界值填细节对每一个字段先做等价类再在关键边界上补点。用户名字段类别输入预期结果有效等价类test_user123通过有效边界正好4位abcd通过有效边界正好16位a1_b2_c3_d4_e5_f6通过无效边界3位abc提示长度不合法无效边界17位17位字符串提示长度不合法无效等价类含特殊字符testuser提示只能包含字母数字下划线无效等价类为空空提示必填密码字段类别输入预期结果有效等价类abc12345通过有效边界正好8位且含字母数字abcd1234通过有效边界正好20位且含字母数字20位混合串通过无效边界7位abc1234提示长度不合法无效边界21位21位混合串提示长度不合法无效等价类纯数字12345678提示必须包含字母无效等价类纯字母abcdefgh提示必须包含数字手机号字段类别输入预期结果有效等价类13812345678通过无效等价类10位1381234567提示长度不合法无效等价类12位138123456789提示长度不合法无效等价类非1开头23812345678提示手机号格式不正确无效等价类含字母1381234567a提示手机号格式不正确6.4 用判定表覆盖组合规则接下来是关键确认密码不一致、手机号已注册、用户名已存在这几个条件组合起来怎么测列出条件确认密码是否与密码一致。用户名是否已存在。手机号是否已注册。动作注册成功跳转登录页。提示“两次密码不一致”。提示“用户名已存在”。提示“手机号已注册”。这里要注意业务上的优先级如果同时用户名重复、手机号重复、且确认密码不一致系统会提示哪个这个必须和后端确认通常是有一个校验顺序的。假设确认结果是“先校验用户名再校验手机号最后校验密码一致性”那判定表里就会出现优先级相关的规则。我简化后的判定表如下规则用户名存在手机号已注册确认密码一致预期动作R1否否是注册成功R2是任意任意提示用户名已存在R3否是任意提示手机号已注册R4否否否提示两次密码不一致这张表化简后只有4条但把主要规则都覆盖了。如果你想把更细的边界也测进去比如“用户名刚好存在于数据库但大小写不同”可以继续追加规则——这就要和开发确认匹配规则到底是精确匹配还是大小写不敏感。6.5 完整用例清单示例最后把这些设计变成真正可执行的用例用例编号前置条件输入数据操作步骤预期结果TC01无用户名test_user、密码abc12345、确认密码abc12345、手机号13812345678填写表单并点击提交注册成功跳转登录页TC02无用户名abc、密码abc12345、确认密码abc12345、手机号13812345678填写表单并点击提交提示用户名至少4位TC03无用户名test_user、密码abc12345、确认密码abc123456、手机号13812345678填写表单并点击提交提示两次密码不一致TC04用户名test_user已存在用户名test_user、密码abc12345、确认密码abc12345、手机号13812345678填写表单并点击提交提示用户名已存在TC05手机号13812345678已注册用户名new_user、密码abc12345、确认密码abc12345、手机号13812345678填写表单并点击提交提示手机号已注册TC06无用户名test_user、密码12345678、确认密码12345678、手机号13812345678填写表单并点击提交提示密码必须包含字母到这里你会发现一张用例表里其实同时用上了场景法TC01是基本流TC04/TC05是业务异常流、等价类TC02、TC06、边界值TC02里的3位长度、判定表TC04/TC05/TC06的组合覆盖。这才是一份合格的测试用例设计。7. 常见问题与避坑经验7.1 用例设计的五个典型误区我带过不少新人看他们写的用例翻来覆去都是下面几个问题误区一正常流程写了一大堆异常场景一个没有。我见过有人给登录功能写了30条用例其中28条是各种正常登录只有2条是错误提示。这就是典型的“等价类”用反了——有效等价类重复覆盖太多无效等价类严重不足。测正常登录两三条就够真正要花力气的是那些“用户搞破坏”的场景。误区二一个用例里塞了太多断言。边界值用例要求数据精准判定表用例要求规则清晰但有人喜欢一条用例从头点到尾看起来覆盖了很多实际上中间任何一步挂了整条用例就失败了还要返工排查到底哪一步出了问题。我自己的习惯是一个用例聚焦一个核心目标把前置条件准备好尽量减少依赖链。误区三边界值只取上点不取离点。还是那句话只测18和60不测17和61等于没测。误区四判定表条件项太粗。比如只写“密码是否正确”但没写清楚“什么算正确的密码”。等到真正实现用例时才发现还需要解释密码规则的细节。条件必须先细化到可操作的程度再进判定表。误区五场景法和用例执行顺序混为一谈。场景法画的是“路径覆盖”不是“执行顺序”。实际执行时我的习惯是把异常流和边界用例排在前面优先执行因为这类用例最容易发现致命问题值得尽早暴露。7.2 实际项目中的取舍经验理论方法在真实项目里要灵活变通。我说几个自己的经验第一不是所有字段都值得做全量边界值。一个表单有10个字段如果每个字段都按上下点离点内点各取7个值用例规模会爆炸。实际项目中我会先和开发对齐哪些字段的校验逻辑最容易出问题一般是涉及金额、数量、长度、日期的优先给这些字段做边界值纯文本展示类字段用等价类覆盖即可。第二后端校验永远比前端校验重要。很多团队的前端校验做得很完善但后端接口直接裸奔。测试时不要只通过页面去测一定要把抓包工具打开绕过前端、直接调接口去测试边界条件和无效等价类。这不仅能发现后端校验缺失也是判断一个测试是“入门”还是“资深”的重要分水岭。第三接口测试同样要套用这4个方法。很多人觉得“接口测试测的是参数跟用例设计方法没关系”。这是误解。接口的每个参数都有取值范围、类型、是否必填、长度限制这些全部可以套等价类和边界值接口之间如果存在多条件联合校验比如“金额大于0且用户类型为VIP时走特定逻辑”那就是判定表的活。场景法对应的是接口之间的调用链比如“创建订单接口 → 支付接口 → 查询订单接口”这条链任何一环失败都会导致业务流程中断。第四和产品确认“隐藏规则”是低成本高收益的事。我在做用例设计之前一定会花时间和产品过一遍规则细节尤其是那些文档里没写但系统里真实执行的逻辑。最怕的是需求文档写“密码长度8到20位”结果后端还偷偷要求“不能包含连续数字”或者“不能与用户名相同”。这些规则不确认清楚用例设计得再漂亮也会漏。7.3 一句话记住核心最后送大家一句我自己总结的话等价类划分是找代表边界值是找边界判定表是找组合场景法是找流程。这4句话记住了面试官问你“这4个方法分别解决什么问题”的时候你可以直接甩出来再配上今天案例里的细节绝对比干巴巴背概念强得多。8. 把这些方法变成自己的肌肉记忆方法讲完了但说来惭愧我最早学这些的时候也觉得不就是几个模板吗背下来不就行了直到有一次在真实项目里被上了一课。那次是测一个支付金额输入框需求写的是“0.01到999999.99”。我当时用边界值取点测了0、0.01、0.02、999999.98、999999.99、1000000.00这么几组数据结果在999999.99这个“上点”上翻车了——后端用了浮点数精度比较导致这个合法金额被判为超出上限。那一次之后我才真正理解边界值方法不是考试用的八股文它背后藏着的是开发最容易写错的那一行判断条件。所以我特别想把这句话送给每一位刚开始学测试的朋友用例设计方法的价值不在于你记住了几个名词而在于你面对一个功能时脑子里能自然浮现出“我要分几类”“边界在哪”“哪些条件组合需要关注”“用户流程里有哪些岔路”。这些能力一旦形成无论你以后做功能测试、自动化测试还是接口测试都会发现底层逻辑完全相通。希望今天这篇Day2的内容能帮你把这些方法真正用起来。你可以随便拿一个自己手头正在测的页面按今天说的思路重新设计一遍用例对比一下和原来的差距。测过一次比背一百道面试题都值。
