企业官网建设流程全解析

有不少刚转行做软件测试的朋友，拿到需求文档的第一反应都是“我到底该测什么”。然后直接打开页面，按正常流程点一遍，发现没报错就算测完了。运气好点的，知道要把输入框都输一遍边界数据，但要他解释为什么这么测，又说不出个所以然。等上线后用户报了一个压根没覆盖到的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]取离点时会取-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.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？是否使用优惠券（先不管）？

我们可以建一个只含两个条件的判定表：

这样一张表，4列就是4条规则，每条规则对应一种条件组合。你不必拍脑袋想“会员满100要不要测”“非会员满100要不要测”，因为全组合情况下，所有情况天然都是要测的。

3.2 判定表怎么画：5步走

在真正的项目里，判定表不会像上面这么简单。我一般按下面这套流程来做：

1. 明确条件：把业务规则里所有的前置条件找出来，一般用“是否”型描述。
2. 明确动作：把规则触发后的结果或操作找出来。
3. 列出全组合：2个条件是4种组合，3个条件是8种组合，n个条件是2的n次方种组合。先全部列出来。
4. 化简合并：把动作完全相同、且某些条件对结果无影响的列合并成一个规则。比如发现“无论是不是会员，只要消费不满100都不打折”，那“会员 + 不满100”和“非会员 + 不满100”两列就可以合并成一条。
5. 写出用例：每一列（化简后的一条规则）就是一组用例设计依据，把它转成具体的输入数据和预期结果。

第4步化简非常关键。不化简的判定表可能有几十列，但化简后可能只剩十几列。这和你需求里规则的复杂程度有关。初学者喜欢把表画得又长又难懂，其实就是化简没做好。

3.3 实战案例：登录功能的规则组合分析

登录功能是面试和笔试里出现频率最高的案例，因为它人人都用过，又包含典型的多条件规则。

假设这个登录功能有三个校验项：

• 用户名是否存在
• 密码是否正确
• 验证码是否正确

动作有三种：

• 登录成功
• 提示“用户名或密码错误”
• 提示“验证码错误”
• 提示“用户不存在”

先列全组合，理论上2 × 2 × 2 = 8种组合。但实际化简时你会发现，如果用户名不存在，密码和验证码是否正确已经没有意义，界面只会提示“用户不存在”。所以这几种组合可以合并。

化简后的判定表大致是：

这里有一点值得和产品确认：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个字符”。

我按自己的工作习惯，会把等价类表列成下面这样：

注意看这个设计思路：我把“有效等价类里的边界长度”也单独列了一行，这实际上就是等价类和边界值的结合用法。先用等价类把空间分桶，再在每个桶的边界上补点——这就是4个方法真正的配合姿势。

4.4 等价类划分的实际项目细节

补充几个我在不同项目里用到的等价类划分细节，这些都是面试或工作中很加分的点：

数值范围和业务语义要分开看。比如年龄字段“18到60”，从输入校验的角度这是一个闭区间；但从业务语义的角度，年龄还可能有“是否是整数”“是否允许小数”等规则。等价类划分时，不要只按范围分，还要把数据类型（整数/小数/负数/零/字母）纳入考虑。

枚举型字段也要做等价类。比如“性别”下拉框有“男、女、保密”，这3个值本身就是3个有效等价类；无效等价类包括“不选”“传入一个API里不存在的枚举值”。接口测试中最容易漏的就是“不存在的枚举值”，这种用例往往能直接暴露后端枚举转换的异常。

注意“可空”和“必填”是两套规则。如果字段非必填，那么空值属于有效等价类；如果字段必填，空值属于无效等价类。这个要看清楚需求再决定，不能想当然。

5. 场景法：从用户视角补齐流程级用例

5.1 单点都对了，流程还是断了？这就是场景法要解决的

前面讲的等价类和边界值，都是从“某个输入框/某个参数”出发的。但真正上线出问题的地方，往往是整个流程串联起来的时候。

比如每个字段的校验都通过了，但用户下单时：加入购物车之后改地址，改完地址返回结算页，价格没刷新；或者支付成功后，回调通知延迟，订单状态一直卡在“待支付”。这种问题，你盯着单个输入框测一辈子也测不出来，必须站在用户完整操作流程的角度去设计用例。

场景法的核心思路是：识别用户完成某个业务目标时的所有路径，包括正常路径、分支路径和异常路径，并为每条路径设计用例。

我自己的习惯是：拿到一个模块后，先画流程主路径，从入口到出口一步一步列出来，然后再针对每一个步骤问自己：“用户在这里可能不走正常路吗？走岔了会怎样？”

5.2 基本流、备选流、异常流怎么区分

场景法里有三个概念，很多人分不清，我用下单流程直接说明：

基本流：从起点到终点的最核心、最顺利的那条路径。比如：用户登录 → 浏览商品 → 加入购物车 → 提交订单 → 支付成功 → 订单完成。这条路径覆盖的是“软件最基本的价值”。

备选流：在某个节点走了另一个合法分支，但最终还是能完成任务。比如：

• 加入了购物车，但结算时使用了优惠券。
• 提交订单时选择“货到付款”而不是在线支付。
• 支付时切换了支付方式（从支付宝切到微信）。

异常流：在某个节点发生了错误或中断，需要系统优雅地处理。比如：

• 未登录就点击“加入购物车”，系统跳转登录页。
• 提交订单后发现商品库存不足，提示“库存不足”。
• 支付过程中取消支付，订单状态变为“已取消”或保持“待支付”。

这里要特别注意：每条备选流和异常流都不是独立的，它们都是从基本流的某个点分叉出去的，最后可能又回到基本流的某个点。所以设计用例时，不是“测完基本流再测备选流”，而是“基本流走一段 → 分支 → 回到基本流 → 再走一段”。

5.3 场景法用例设计实例：电商下单

我拿电商下单举例，给大家一个可以直接套用的思路。

画出的流程节点大概是：

登录 → 浏览商品 → 加入购物车 → 结算页确认地址 → 提交订单 → 支付 → 查看订单状态

基于这个流程，我通常会先列一个场景清单：

你会注意到，这8个场景覆盖的远不止8条用例，因为每个场景内部还可以继续插桩，比如“支付失败”这个异常流里，到底失败一次就返回还是允许重试3次？每次重试有没有间隔限制？这些细节又可以叠加等价类、边界值和判定表继续往下挖。

所以场景法的真正用法是：先用场景法搭起整个测试的骨架，再把其他方法塞进每个场景里去填充肌肉和细节。

5.4 场景法和状态迁移法的关系

有些测试教材会把“状态迁移法”也单列出来。严格来说，场景法和状态迁移法是两兄弟：场景法更偏向“用户任务视角”，描述的是用户和系统的交互流程；状态迁移法更偏向“系统状态视角”，关注的是系统在不同事件下状态的合法迁移。

举个例子，订单状态有“待支付、已支付、已发货、已完成、已取消”。状态迁移法会专门验证：待支付 → 已支付、待支付 → 已取消、已支付 → 已发货、已发货 → 已完成，这些都是合法的；但是待支付 → 已发货就是非法的，系统必须拦截。

实际操作中，如果被测对象的状态很多、状态流转很复杂（比如订单、审批流），我一般会先画状态图，再基于状态图设计场景。如果状态很简单（比如一个表单提交），直接用场景法就够了。

新手阶段，我建议先把场景法用熟，因为它的思维路径最贴合用户的真实行为。有了“先正常走一遍、再岔路走一遍、再故意走错一遍”的直觉，后面学状态迁移法会轻松很多。

6. 四大方法组合实战：一个注册页面的完整用例设计

6.1 需求描述

光讲方法是纸上谈兵，我拿一个在面试和实战里都极常见的“用户注册页面”作为例子，带大家完整走一遍4个方法怎么配合。需求如下：

• 用户名：4到16位，只能包含字母、数字、下划线。
• 密码：8到20位，必须同时包含字母和数字。
• 确认密码：必须与密码一致。
• 手机号：11位，以1开头。

6.2 用场景法搭骨架

这个需求对应的主流程是：进入注册页 → 填写表单 → 提交 → 注册成功 → 跳转登录页。

备选流和异常流有：

注意，这里的“用户名已存在”和“手机号已注册”属于业务规则校验，不是前端格式校验，大概率要等请求返回才知道，所以它们天然是判定表的候选场景。

6.3 用等价类+边界值填细节

对每一个字段，先做等价类，再在关键边界上补点。

用户名字段

密码字段

手机号字段

6.4 用判定表覆盖组合规则

接下来是关键：确认密码不一致、手机号已注册、用户名已存在这几个条件组合起来怎么测？

列出条件：

• 确认密码是否与密码一致。
• 用户名是否已存在。
• 手机号是否已注册。

动作：

• 注册成功，跳转登录页。
• 提示“两次密码不一致”。
• 提示“用户名已存在”。
• 提示“手机号已注册”。

这里要注意业务上的优先级：如果同时用户名重复、手机号重复、且确认密码不一致，系统会提示哪个？这个必须和后端确认，通常是有一个校验顺序的。假设确认结果是“先校验用户名，再校验手机号，最后校验密码一致性”，那判定表里就会出现优先级相关的规则。

我简化后的判定表如下：

这张表化简后只有4条，但把主要规则都覆盖了。如果你想把更细的边界也测进去，比如“用户名刚好存在于数据库但大小写不同”，可以继续追加规则——这就要和开发确认匹配规则到底是精确匹配还是大小写不敏感。

6.5 完整用例清单示例

最后把这些设计变成真正可执行的用例：

到这里你会发现，一张用例表里其实同时用上了场景法（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的内容，能帮你把这些方法真正用起来。你可以随便拿一个自己手头正在测的页面，按今天说的思路重新设计一遍用例，对比一下和原来的差距。测过一次，比背一百道面试题都值。