黑盒测试及白盒测试
总览：三大类方法，各司其职
测试用例设计一共分三大门派，实际工作都是搭配着用：
黑盒测试法：不看代码，只测功能好不好用，就像开盲盒，只管输入输出对不对（日常功能测试最常用）
白盒测试法：扒开代码看内部，测代码逻辑走得对不对（一般单元测试、测核心算法用）
经验类方法：靠测试经验补漏，专门测容易出 bug 的犄角旮旯（辅助补充用）
一、黑盒测试方法（最常用，测功能）
- 等价类划分法
说白了就是「物以类聚」：同一类输入，程序处理逻辑完全一样，测 1 个代表就等于测了一整类，不用一个个重复测。
分成两类：
有效等价类：符合要求的、合法的输入（正常数据）
无效等价类：不符合要求的、非法的输入（异常数据）
核心规则
有效等价类：1 条用例尽量覆盖多个有效类，少写用例省时间
无效等价类：1 条用例只能覆盖 1 个无效类（避免好几个错误叠在一起，分不清到底报的哪个错）
举个例子：手机号校验（要求 11 位纯数字）
有效等价类：11 位纯数字，比如 15949613302
无效等价类（每个单独写一条用例）：
① 少于 11 位：1594961330
② 多于 11 位：159496133021
③ 带字母 / 符号：1594961330a
适用场景
所有输入框：账号、金额、手机号、身份证、文件大小、字符串长度等。 - 边界值分析法
程序 80% 的 bug 都出在边界临界点上，比如刚好卡着最大值、最小值的地方。专门测边界附近的数，就是边界值法，一般搭配等价类一起用。
三个关键点位（闭区间最常用，99% 场景都是这个）
比如要求 QQ 账号 5~13 位（包含 5 和 13）：
上点：边界本身的数 → 5、13
内点：范围中间随便一个合法数 → 10
离点：刚好超出边界的数 → 4（比最小小 1）、14（比最大大 1）
最终测这 5 个数：4、5、10、13、14，基本边界的 bug 就都能测到。
举个例子：微信红包 0.01~200 元
测这 5 个金额就够：
0.00（小于最小值）、0.01（最小值）、100（中间值）、200（最大值）、200.01（大于最大值）
适用场景
有数值范围、长度限制、个数限制的输入，有序列表的首尾项。 - 场景法（流程分析法）
模拟真实用户从头到尾走业务流程，不仅走正常成功的路，还要把所有出错、异常的分支都走一遍，比如登录失败、余额不足、密码错误这些情况。
核心思路
先画业务流程图，把「正常主流程」和「所有异常分支」都画出来
每条路径对应一个测试场景，每个场景写用例
输入的具体数值，再搭配等价类、边界值来选
举个例子：ATM 取款流程
正常主流程：插卡→输密码正确→输金额→余额够→出钞→拿钱→退卡
异常分支：
① 插卡无效（卡插反、过期卡）
② 密码输错、锁卡
③ 金额不是 100 的倍数、超过单日限额
④ 余额不足、ATM 机里没钱
⑤ 超时不取卡被吞
适用场景
有连贯步骤的业务：下单支付、登录注册、审批流程、取款、退货退款等。 - 状态迁移法
一个东西有好几种固定状态，不同的操作会让它从一个状态变成另一个状态。我们测所有合法的切换对不对，还要测不合法的切换能不能触发（比如「已完成」的订单能不能直接取消）。
核心步骤
找出所有可能的状态
找出触发状态变化的操作（事件）
画出状态转换图 / 树
每条状态路径写一条测试用例
举个例子：机票订单状态
状态：待支付 → 已支付 → 已出票 → 已使用 / 已取消
合法路径：订票→支付→出票→登机使用
合法路径：订票→支付→取消→退款
非法路径：已使用的票能不能取消？没支付能不能直接出票？
适用场景
订单状态、工单审批、物流状态、用户账号状态等有状态流转的功能。 - 判定表法
好几个条件凑在一起，共同决定最终结果。把所有条件的真假组合全部列出来，每个组合对应一个结果，保证不漏任何一种逻辑情况。
四个组成部分（不用死记，理解就行）
条件桩：一共有多少个影响结果的条件
条件项：每个条件的两种情况（满足 / 不满足）
动作桩：最终会有哪些结果 / 操作
动作项：每一种条件组合下，对应什么结果
计算规则
n 个条件，每个条件有「是 / 否」2 种情况，总组合数 = 2 的 n 次方
比如 3 个条件，就有 2³=8 种组合。
举个例子：机器优先维修规则
规则：功率 > 50 马力 且 维修记录不全，或者 运行 10 年以上，就优先维修
条件 3 个：功率 > 50 马力、维修记录不全、运行 10 年以上
结果：优先维修 / 不优先维修
把 8 种组合全列出来，每种组合对应对不对，就是判定表
适用场景
多条件组合判断：优惠券规则、会员折扣、权限校验、复杂表单校验等。 - 因果图法
先把「输入条件（因）」和「输出结果（果）」的逻辑关系画成图，再转成判定表。适合条件之间有约束、有依赖关系的复杂场景。
说白了就是：帮你有条理地梳理逻辑，最终还是生成判定表来写用例。
4 种基础逻辑关系
恒等：条件满足，结果就发生
非：条件满足，结果反而不发生
或（∨）：几个条件只要满足一个，结果就发生
与（∧）：几个条件必须全部满足，结果才发生
常见约束（条件之间的限制）
异 E：两个条件最多选一个，不能同时满足（比如选啤酒就不能选橙汁）
唯一 O：两个条件必须选且只能选一个
要求 R：a 满足的话，b 必须也满足
强制 M：a 满足的话，b 必须不满足
适用场景
条件多、约束关系复杂，直接写判定表理不清的时候用；一般简单场景直接写判定表就行，不用画图。 - 正交实验法
一堆筛选条件、一堆配置项，全组合测不完（比如 10 个条件每个 3 种选项，全测有几万条）。用正交表挑有代表性的组合测，保证「任意两个条件的所有选项都搭配过一次」，用最少的用例覆盖大部分组合。
两个核心术语
因子：有多少个条件 / 变量（比如姓名、身份证、手机号，3 个因子）
水平：每个条件有几种取值（比如填 / 不填，就是 2 个水平）
核心原则
两两组合全覆盖：不保证三个、四个条件一起的组合全测到，但绝大多数 bug 在两个条件搭配的时候就会暴露，性价比极高。
举个例子：3 个输入框，每个都可以填 / 不填
全组合：2³=8 条用例
正交法：4 条用例就够，覆盖所有两两搭配
适用场景
多下拉框筛选、系统参数配置、多选项组合的页面，全量测试成本太高的时候用。
二、经验类测试方法（辅助补漏）
这三个方法不用按步骤推导，靠测试经验和对业务的理解，专门查漏补缺。 - 错误推测法
凭经验猜「哪里容易出 bug」，专门针对这些地方设计用例。
比如：空输入、超长文本、特殊符号、空格、重复提交、快速点击、网络差的时候提交，这些都是高频出 bug 的地方。 - 异常分析法
专门测极端异常场景，看程序会不会崩、数据会不会错。
比如：操作中途断网、断电、后台服务挂了、内存满了、文件损坏、权限中途被收回等。 - 随机测试法
随便点、随便输，模拟用户乱操作，没有固定步骤，也叫「猴子测试」。
适合测稳定性，偶尔能测出按正常流程测不到的奇葩 bug，但不能当主力，因为没有覆盖标准。
三、白盒测试方法（测代码逻辑）
大白话定义
打开代码看内部逻辑，测代码里的分支、条件、路径走得对不对，也叫结构测试、逻辑驱动测试，一般单元测试用得多。
6 种覆盖标准（强度从弱到强）
用一句代码举例：if (a>0 && b<5) { 执行代码X }
语句覆盖（最弱）
让每一行可执行代码至少跑一遍。比如上面的例子，只要让 if 条件为真，执行一次代码 X 就算达标。
缺点：只管代码行跑没跑，不管分支对不对，很多 bug 测不出来。
判断覆盖（判定覆盖）
每个 if 判断，「真分支」「假分支」都各走一遍。比如上面的例子，让 if 整体为真一次、为假一次。
缺点：只管整个判断的结果，不管里面每个小条件的真假。
条件覆盖
判断里的每个小条件，真假都各走一遍。比如上面的例子，a>0 真一次、假一次；b<5 真一次、假一次。
缺点：子条件都覆盖了，但可能凑起来刚好只走了一个判断分支。
判定 - 条件覆盖
同时满足「判断覆盖」+「条件覆盖」，既保证每个判断真假都走了，也保证每个小条件真假都走了。
条件组合覆盖
判断里所有小条件的真假组合，全部都测一遍。比如上面两个小条件，就有 4 种组合：真真、真假、假真、假假。
优点：单个判断内部逻辑全覆盖，基本不会漏。
路径覆盖（最强）
把程序里所有能走的执行路径，全部走一遍。
分两种：
独立路径：所有不重复的执行路线
Z 路径：简化循环，循环只测 0 次、1 次，不然路径会无限多
缺点：代码一多，路径数量爆炸，根本测不完，一般只给核心模块用。
白盒优缺点
优点：测的细，能发现黑盒测不到的代码逻辑 bug、死代码、内存问题
缺点：要懂代码，成本高；只看代码容易忽略业务需求本身对不对
最后：实际工作怎么搭配用？
不用每个方法都硬套，按场景选就行：
普通输入框（手机号、金额、账号）：等价类 + 边界值
有步骤的业务流程（下单、审批、登录）：场景法
多条件组合判断（优惠券、权限、规则）：判定表
有状态流转的功能（订单、工单）：状态迁移法
一堆筛选 / 配置项：正交实验法
收尾补漏：错误推测法 + 异常分析法
单元测试、核心算法：白盒覆盖法
浙公网安备 33010602011771号