前言：你是否写测试用例时总陷入 “要么漏场景，要么写一堆没用的用例”？

其实不用瞎凑数 —— 等价类、边界值、判定表、场景法等 6 种核心方法，就是测试用例的 “万能公式”。

从单个输入框的格式校验，到复杂业务流程的全链路覆盖，再到经验性的隐性缺陷补充，这篇把每种方法的「核心逻辑 + 实操案例 + 组合技巧」拆解得明明白白，看完直接能套用在注册、登录、命令行工具等任意功能上，再也不用愁 “用例怎么写才全面”。

一、设计测试⽤例的⽅法

1.1基于需求的设计⽅法

基于需求的测试用例设计方法，是指测试人员依据需求文档 / 产品规格说明书，通过分析、验证并细化需求，提取测试点后设计用例的核心方法。

流程：接收需求 → 分析 / 验证需求 → 细化需求并提取测试点 → 基于测试点设计用例。

1.1.1实操案例（邮箱账号注册需求）

以 “邮箱账号注册” 为例，需求拆解与测试设计的关键要素：

1. 业务流程（核心场景）：

   • 基本事件流：用户选择注册→同意协议→填写信息→提交→接收激活邮件→激活账号→注册完成；
   • 扩展事件流：注册成功后首次登录提示完善信息；
   • 异常事件流：未收到激活邮件时，可在登录页重发（激活邮件 24 小时有效）。

测试设计思路

• 1.明确需求中的功能点： 账号注册，账号登陆
• 2.结合万能公式设计测试点

1.2具体的设计⽅法

1.2.1等价类

1. 核心解决的问题

解决 “穷举测试效率低” 的问题：将输入（或输出）划分为若干等价类，从每个类中选一个用例测试，若通过则认为该类所有用例通过，以少量用例覆盖多数场景。

2. 分类

• 有效等价类：符合需求规格的合理输入集合，用于验证功能是否实现预期。
• 无效等价类：不符合需求的输入集合，用于验证功能的异常处理。

3. 设计步骤

1. 确定有效 / 无效等价类；
2. 编写用例并设计测试数据。

示例（姓名 “必填、6~15 位字符”）

等价类类型	测试数据	预期结果
有效等价类	10 位字符	无错误提示
无效等价类（<6 位）	1 位字符	提示错误
无效等价类（>15 位）	20 位字符	提示错误

4.缺点

仅考虑单输入域的分类，未覆盖输入域的组合场景，需配合其他方法补充。

1.2.2边界值

1. 核心定位

作为等价类方法的补充，针对输入 / 输出的边界值设计用例（软件在边界处易出现错误）。

2. 边界范围

包含 “边界值” 与 “次边界值”（边界附近的临界值），示例：

• 输入框长度 1~11 位：边界值取 1、11；次边界值取 0（<1）、12（>11）；
• 参赛项目 1~3 项：边界值取 1、3；次边界值取 0（<1）、4（>3）。

3. 示例（姓名 “6~15 位字符”）

边界类型	测试数据	预期结果
有效边界	6 位字符	无错误提示
有效边界	15 位字符	无错误提示
次边界（<6 位）	5 位字符	提示错误
次边界（>15 位）	16 位字符	提示错误

1. 等价类的核心：仅按 “有效 / 无效区间” 划分，测试数据取区间内非临界值（如 6~15 位取 10 位），实现 “区间覆盖”；
2. 边界值的补充：在等价类基础上，针对区间的临界值（如 6 位、15 位） 及临近边界的无效值（如 5 位、16 位） 单独测试，实现 “边界精准覆盖”；
3. 归属关系：
   • 边界值（如 6 位、15 位）属于有效等价类；
   • 临近边界值（如 5 位、16 位）属于无效等价类。

两者结合后，既覆盖了区间的 “普遍性”，又覆盖了边界的 “易出错点”，让测试更全面。

等价类 + 边界值组合测试模板

测试维度	等价类类型	边界类型	测试数据	预期结果
有效场景覆盖	有效等价类	非临界值	[如 10 位字符]	符合需求（无错误）
有效边界覆盖	有效等价类	临界值（左）	[如 6 位字符]	符合需求（无错误）
有效边界覆盖	有效等价类	临界值（右）	[如 15 位字符]	符合需求（无错误）
无效边界覆盖	无效等价类（< 左边界）	次边界（左）	[如 5 位字符]	提示错误
无效边界覆盖	无效等价类（> 右边界）	次边界（右）	[如 16 位字符]	提示错误
其他无效场景	无效等价类（如格式错误）	-	[如含特殊符号]	提示错误

1.2.3正交法

我们已通过等价类与边界值方法补充了部分测试用例，目前还需完善 “仅填写部分选项” 的场景用例。若采用排列组合法保障测试覆盖率，用例数量会随选项数呈指数级增长：2 个选项需设计 4 个用例（2²），3 个选项需 8 个用例（2³）；而当前涉及姓名、电子邮箱、密码、确认密码、验证码这 5 个选项，若全量排列组合，需设计 32 个用例。

1.正交法的核心价值

解决多选项排列组合导致用例数量过多的问题：通过 “正交表” 选取有代表性的用例，以少量用例覆盖输入的两两组合，平衡测试效率与覆盖率。

2.正交法的基础概念

• 正交试验设计：研究多因素多水平的高效设计方法，基于正交表选取部分试验点，替代全量组合。
• 正交表结构：以L₄(2³)为例：
  • L：代表正交表；
  • 4：4 行（需执行 4 次试验）；
  • 3：3 列（最多支持 3 个因素）；
  • 2：因素的水平数（每个因素有 2 个可选值）。

• 正交表性质：每列不同数字出现次数相等；任意两列的数字排列方式齐全且均衡。

3.正交法设计用例的步骤

1. 确定因素和水平：

   • 因素：影响结果的条件（如注册中的 “姓名、电子邮箱” 等选项）；
   • 水平：因素的可选值（如 “填写、不填写”）。

2. 用工具生成正交表：以allpairs工具为例：

   • 步骤 1：将因素和水平写入 Excel，再复制到文本文件；
   • 步骤 2：执行命令allpairs.exe [输入文件]>[输出文件]生成正交表。

   • 

3. 编写测试用例：基于生成的正交表，转化为具体用例。

     4.补充遗漏用例：补充正交表未覆盖的重要场景。

1.2.4判定表法

1.判定表法的核心价值

解决多输入条件组合对应不同输出结果的场景（正交法无法覆盖此类逻辑关联场景），通过表格清晰呈现 “条件组合→结果” 的逻辑关系，确保测试用例覆盖所有逻辑分支。

2.判定表法的设计步骤

1. 确认输入条件与输出条件：明确需求中的触发条件（输入）和对应的结果（输出）；
2. 梳理条件与结果的关系：分析不同输入组合对应的输出；
3. 绘制判定表：用表格形式呈现 “输入条件组合→输出结果” 的对应关系；
4. 编写测试用例：基于判定表转化为具体的测试场景。

3.实操案例（注册管理员身份的需求）

1. 条件与结果定义

• 输入条件：账号包含admin字符（a）、内部注册链接（b）、点击注册按钮（c）；
• 输出条件：管理员身份（1）、非管理员身份（2）。

2.找出输⼊条件和输出条件之间的关系

3. 判定表（输入组合→输出结果）

4.根据判定表编写测试⽤例
a. 账号包含admin，⾮内部注册链接，点击注册按钮，为管理员⾝份
b. 账号包含admin，内部注册链接，不点击注册按钮，⾮管理员⾝份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员⾝份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员⾝份
e. 账号包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份
f. 账号不包含admin，⾮内部注册链接，点击注册按钮，⾮管理员⾝份
g. 账号不包含admin，⾮内部注册链接，不点击注册按钮，⾮管理员⾝份

判定表法的优势是能无遗漏地覆盖复杂逻辑的所有分支，适用于 “条件组合影响结果” 的场景（如权限控制、流程判定等）。

1.2.5场景法

1.场景法的核心逻辑

针对事件触发的业务流程，通过模拟 “基本流程 + 分支场景” 的方式设计用例，覆盖正常、异常等不同业务路径，避免遗漏流程中的关键节点。

场景法包含两类流程：

• 基本流：业务的常规、无异常的核心流程；
• 备选流：基本流中出现的分支场景（如异常、特殊情况）。

2.场景法的设计步骤

1. 确定基本流：梳理业务的正常核心流程；
2. 确定备选流：分析基本流各阶段可能出现的分支场景（异常、特殊情况）；
3. 补充测试用例：结合基本流与备选流的组合，覆盖所有业务路径；
4. 编写测试用例：将流程场景转化为具体的测试步骤与预期结果。

5. 

3.实操案例（邮箱注册流程）

1. 流程梳理

• 基本流：输入正确账号密码→点击注册→发送确认邮件→24H 内确认→注册成功；
• 备选流：不输入账号密码、只输部分信息、账号已注册、邮件发送失败、24H 内未确认等。
• 备选流就是在基本流的每个流程节点中，延伸出的异常、特殊场景。

2. 对应测试用例

1. 输入正确账号密码→点击注册→收邮件并 24H 内确认→注册成功；
2. 不输入账号密码→点击注册→提示重新输入；
3. 只输入账号（不输密码）→点击注册→提示重新输入；
4. 输入已注册账号→点击注册→提示账号已存在；
5. 点击注册后邮件发送失败→系统提示重试；
6. 24H 内未确认邮件→注册流程失效。（基本流的前置流程默认是 “已完成正确操作”，只需重点描述备选流的差异环节 + 后续结果，不用重复写基本流的相同步骤。）

用例类型	测试步骤	预期结果
基本流	1. 输入正确账号 + 正确密码2. 点击 “注册” 按钮3. 接收确认邮件并在 24H 内点击激活链接	注册成功，账号状态为 “已激活”
备选流 1	1. 不输入账号、不输入密码2. 点击 “注册” 按钮	系统提示 “请输入账号和密码”
备选流 2	1. 输入正确账号、不输入密码2. 点击 “注册” 按钮	系统提示 “请输入密码”
备选流 3	1. 输入已注册的账号 + 正确密码2. 点击 “注册” 按钮	系统提示 “该账号已存在”
备选流 4	1. 输入正确账号 + 正确密码2. 点击 “注册” 按钮3. 系统提示 “邮件发送失败”	系统显示 “邮件发送失败，请重试”
备选流 5	1. 输入正确账号 + 正确密码2. 点击 “注册” 按钮3. 24H 内未点击邮件激活链接	注册流程失效，再次登录提示 “账号未激活”

场景法的优势是能建立业务流程的整体认知，避免孤立测试功能点，更贴合实际用户的操作路径，适用于流程类功能（如注册、支付、下单等）的测试设计。

1. 优先覆盖 “高风险、高频发生” 的备选流：比如 “账号已注册”“密码格式错误” 这类用户实际使用中易遇到的场景；
2. 次要覆盖 “低概率、低影响” 的备选流：比如 “邮件被拦截” 这类偶发场景，可酌情简化；
3. 忽略 “极端罕见、无实际影响” 的备选流：比如 “注册时系统服务器断电” 这类几乎不会出现的场景，无需强制覆盖。

核心原则是：覆盖用户真实使用场景 + 高风险异常，平衡测试完整性与测试成本。

1.2.6错误猜测法

1.错误猜测法的核心逻辑

基于对软件需求、设计的理解，结合个人经验、直觉，推测软件可能存在的缺陷，进而针对性设计测试用例。它与 “探索式测试” 思路一致，在敏捷开发中投入产出比高，应用广泛。

2.方法特点

• 优势：灵活高效，能快速覆盖经验性的潜在缺陷；
• 缺点：依赖个人能力，难以系统化覆盖所有场景。

3.实操案例（邮箱注册场景）

结合经验推测的测试点：

1. 账号中含特殊字符 / 空格，系统是否正确校验；
2. 密码校验是否区分大小写；
3. 姓名中含特殊字符（如 emoji、符号），系统是否支持；
4. 注册流程中密码是否以明文形式传输 / 显示。

错误猜测法通常作为其他测试方法的补充，结合等价类、场景法等使用，能覆盖常规方法遗漏的 “经验性缺陷”。

以下是邮箱注册场景下，基于错误猜测法的规范测试用例：

测试点	测试步骤	预期结果
账号含特殊字符 / 空格的校验	1. 输入账号为 “test@123”（含空格）2. 输入账号为 “test#123”（含特殊字符）3. 点击注册	系统提示 “账号格式不合法，请勿包含空格 / 特殊字符”
密码校验的大小写区分	1. 设置密码为 “Abc123”2. 再次输入密码为 “abc123”（小写）3. 点击注册	系统提示 “两次输入的密码不一致”
姓名含特殊字符的支持情况	1. 姓名输入为 “张三🤔”（含 emoji）2. 姓名输入为 “李 * 四”（含符号）3. 点击注册	系统提示 “姓名格式不合法，请勿包含特殊符号 / 表情”
密码的明文传输 / 显示	1. 输入密码时观察输入框显示2. 抓包查看注册请求中密码的传输形式	1. 输入框显示为密文（●）2. 请求中密码为加密形式
注册后重复提交表单	1. 输入正确信息后快速多次点击 “注册” 按钮	系统仅处理 1 次请求，避免重复注册

错误猜测法的测试点，本质是 “基于经验的备选流”，两者核心都是覆盖 “异常 / 特殊场景”，只是来源不同：

• 备选流（场景法）：从业务流程逻辑出发推导的异常分支；
• 错误猜测法：从经验 / 直觉出发，覆盖流程逻辑之外的 “隐性缺陷”（比如密码明文这类技术层面的问题）。

“省略前置流程” 是所有场景类用例的通用简化写法 —— 默认前置步骤与基本流一致，只写差异环节，避免冗余。

分类	覆盖维度	测试用例（步骤 + 预期结果）
场景法备选流	业务流程逻辑内的异常分支	1. 不输入账号密码→点击注册预期：提示 “请输入账号密码”2. 输入已注册账号→点击注册预期：提示 “账号已存在”3. 24H 内未确认邮件→查看账号预期：注册流程失效，提示 “账号未激活”
错误猜测法	经验 / 技术层面的隐性缺陷	1. 账号含空格（如 “test@123”）→点击注册预期：提示 “账号格式不合法”2. 密码输入时观察输入框 + 抓包预期：输入框显示密文，请求中密码加密3. 姓名含 emoji（如 “张三🤔”）→点击注册预期：提示 “姓名格式不合法”4. 快速多次点击注册按钮预期：仅处理 1 次请求，无重复注册

可以看到：

• 场景法备选流聚焦业务流程本身的分支（用户操作逻辑内的异常）；
• 错误猜测法聚焦流程外的隐性风险（技术细节、非常规输入等经验性缺陷）。

两者互补，能更全面地覆盖测试场景。

• 场景法（备选流）：覆盖用户常规操作中易犯的错误（比如漏填信息、重复注册），是 “用户大概率会遇到的常见异常”；
• 错误猜测法：覆盖用户偶然 / 离谱的输入、或技术层面的隐性风险（比如输入 emoji、密码明文这类用户不一定会主动操作，但软件可能存在缺陷的场景）。

简单说：场景法是 “用户常犯的错”，错误猜测法是 “用户偶尔犯的错 + 软件潜在的坑”。

拓展用例

1.命令⾏程序

 存在功能可以在命令⾏使⽤zip/unzip命令对⽂件进⾏解压缩，这样的场景如何来设计测试⽤例？

测试维度及核心覆盖点

测试类型	核心测试场景
功能测试	不同文件类型（txt / 图片 /zip）压缩、多文件混合压缩、空文件夹压缩、错误命令（如缺少参数）的处理
界面测试	命令执行后的提示信息是否清晰（如压缩成功 / 失败的反馈）
性能测试	大文件（>1G）的压缩可行性、压缩耗时是否合理
兼容性测试	多系统（Windows/Linux/Mac）下命令是否可用
易用性测试	是否提供帮助文档（如zip --help）
安全性测试	压缩 / 解压过程中是否泄露文件内容

设计逻辑

命令行程序的测试逻辑是：先确保核心功能可用，再验证体验、性能、多环境适配等维度—— 因为命令行工具的核心是 “功能是否能完成压缩 / 解压”，但同时要兼顾 “用户能否清晰获取反馈、大文件是否高效、跨系统是否能用” 等实际使用场景。

补充说明

这类命令行工具的测试，还可以结合等价类 + 错误猜测法补充场景：

• 等价类：比如测试 “文件大小”（小文件 < 100M、大文件 > 1G）；
• 错误猜测法：比如输入 “不存在的文件路径” 执行 zip 命令，验证错误提示是否明确。

总结

测试用例方法的选择逻辑其实很简单：先按 “测试维度” 分类，再匹配对应的方法，复杂场景直接 “组合使用”。

使用决策表

测试场景	优先用什么方法？	搭配什么方法？
单个输入框的格式 / 范围校验（如账号长度）	等价类 + 边界值	错误猜测法（补充特殊字符）
多条件组合影响结果（如登录权限）	判定表法	错误猜测法（补充异常组合）
业务流程类功能（如注册、下单）	场景法（基本流 + 备选流）	等价类（校验每个节点的输入）
减少多选项的用例数量（如多筛选条件）	正交表法（allpairs）	场景法（补充核心流程）
补充经验性 / 隐性缺陷（如密码明文）	错误猜测法	任何方法（作为补充）

核心原则：

1. 单一简单场景：用 1 种方法足够比如 “测试密码长度”：直接用「等价类（合法 / 非法长度）+ 边界值（最长 / 最短）」。

2. 复杂场景：必用 “组合法”比如 “注册功能”：

• 先靠场景法梳理 “输入→点击→发邮件→激活” 的流程；
• 每个输入环节用等价类 + 边界值校验格式；
• 多条件组合（如 “账号已注册 + 密码正确”）用判定表覆盖；
• 最后用错误猜测法补充 “姓名含 emoji” 这类隐性问题。

总结成一句话：先搭 “流程 / 维度” 的骨架，再用 “基础方法” 填细节，最后用 “经验方法” 补漏洞。

示例：登录功能 -多方法组合使用流程：

步骤 1：先确定「测试骨架」—— 用【场景法】梳理流程

先把登录的基本流 + 备选流列出来（这是整个测试的 “流程骨架”）：

• 基本流：输入正确账号→输入正确密码→点击登录→登录成功
• 备选流：
  1. 账号为空；2. 密码为空；3. 账号错误；4. 密码错误；5. 点击 “忘记密码”；6. 勾选 “记住密码”

步骤 2：给「流程节点填细节」—— 用【等价类 + 边界值】校验输入

针对基本流 / 备选流里的 “输入环节”（账号、密码），用等价类 + 边界值拆分成具体的输入场景：

账号的等价类：

• ✅ 合法：长度 6-12 位、含字母数字（如 “test123”）
• ❌ 非法：长度 < 6（如 “t12”）、长度 > 12（如 “test12345678”）、含特殊字符（如 “test#123”）

密码的等价类：

• ✅ 合法：长度 8-16 位、含大小写 + 数字（如 “Abc12345”）
• ❌ 非法：长度 < 8（如 “12345”）、纯数字（如 “12345678”）

步骤 3：覆盖「多条件组合」—— 用【判定表法】列全逻辑

针对 “账号 + 密码” 的组合场景，用判定表列出所有可能的结果：

账号状态	密码状态	结果
正确	正确	登录成功
正确	错误	密码错误
错误	正确	账号错误
错误	错误	账号 / 密码错误

步骤 4：补「经验漏洞」—— 用【错误猜测法】加特殊场景

在前面的基础上，补充 “经验性” 的异常场景：

1. 快速连续点击 “登录” 按钮（防止重复请求）
2. 账号输入 “sql 注入语句”（如 “'or 1=1--”）
3. 密码输入时看是否显示明文
4. 换个浏览器登录 “记住密码” 是否生效

步骤 5：最终整合 —— 把所有场景写成「测试用例」

把上面的内容整合为 “步骤 + 预期结果”，比如：

1. 输入合法账号（“test123”）+ 合法密码（“Abc12345”）→点击登录→预期：登录成功
2. 输入账号为空 + 密码正确→点击登录→预期：提示 “请输入账号”
3. 输入账号 “t12”（长度 < 6）→点击登录→预期：提示 “账号长度需 6-12 位”
4. 输入账号 “'or 1=1--”→点击登录→预期：提示 “账号格式错误”
5. 快速点 3 次登录按钮→预期：仅触发 1 次登录请求

总结：

1. 先搭流程（场景法）：先写 “正常咋操作 + 可能出啥错”；
2. 再拆输入（等价类 + 边界值）：把每个输入框的 “合法 / 非法” 情况列全；
3. 列组合逻辑（判定表）：多个条件搭配的结果别漏；
4. 补经验坑（错误猜测法）：想想 “以前类似功能出过啥问题”；
5. 最后写成用例：把上面的内容翻译成 “步骤 + 预期结果”。