测试用例篇：从“万能公式”到六大方法，搭一套可复用的用例设计体系

测试用例篇：从"万能公式"到六大方法，搭一套可复用的用例设计体系

测试用例（Test Case）这东西，表面上像"写文档"，本质上是把测试思路工程化：让测试覆盖可衡量、让回归可重复、让沟通有证据、让责任边界清晰。来看这一篇要解决的核心问题：

• 测试用例到底是什么、为什么必须写
• 设计用例时怎么避免"想到哪写到哪"（万能思路）
• 具体怎么把需求拆成可执行的用例（方法论 + 可落地步骤）
• Web/接口/命令行等不同形态系统，怎么迁移同一套思路

---

1. 测试用例是什么：一组"可执行的验证说明书"

来看定义：测试用例是为了实施测试而向被测系统提供的一组集合，里面要包含测试环境、操作步骤、测试数据、预期结果 等要素。

1.1 用例的必备原则：必须写"预期结果"

来看第一条原则：测试用例里一个必需部分是对预期输出或结果进行定义 。

原因很简单：没有预期结果，就无法判断"对/错"，测试会退化成"我觉得像是对的"。

1.2 一条完整用例长什么样（传统写法）

来看一个典型用例字段（你在多数企业的缺陷/用例平台都能看到同构字段）：

• 用例编号 / 标题
• 测试方式（手工/自动化）
• 功能模块
• 重要性
• 测试前提
• 测试环境（OS、浏览器/客户端版本等）
• 测试数据
• 测试步骤（可复现、可执行）
• 期望结果（可判定、可验收）

1.3 为什么需要测试用例：不是"可写可不写"

来看常见痛点（不写用例非常容易踩）：

• 不知道是否较全面覆盖了所有功能
• 覆盖率无法衡量
• 新版本的重复测试（回归）难以稳定实施
• 大量冗余测试拖慢效率
• 产品出问题时容易被"追责"：别人第一反应是"为什么测试没测到？"

用例的价值一句话：把测试从"凭经验"变成"可审计、可复用、可追踪"。

1.4 用例表达方式：表格 vs 思维导图

来看两种常见表达：

• 传统表格：适合笔试/需要完整要素、需要审计留痕的场景
• 思维导图/脑图：适合敏捷迭代、高频维护、快速评审与补充的场景（很多团队更常用）

实操建议：面试口述时，用脑图结构讲覆盖；笔试/文档提交时，用传统格式把要素补齐。

---

2. 设计测试用例的"万能思路"：别只靠头脑风暴

很多人设计用例时卡住，是因为只会"常规思考"。来看一个更稳的框架：

2.1 正确的用例思维：常规 + 逆向 + 发散

来看核心思想：常规思维 + 逆向思维 + 发散性思维。

同时记住三条非常"反直觉但很重要"的原则：

1. 用例不仅要覆盖有效、可预料输入 ，也要覆盖无效、不可预料输入。
2. 测试不止是检查系统"该做的做没做"，还要检查系统"不该做的有没有做"。
3. 计划测试时不要默认"不会发现错误"（默认无错 = 默认盲测失败）。

2.2 万能公式：先把测试类型补齐，再谈细化方法

来看万能公式（把"应该测哪些维度"一次补齐）：

功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试

下面逐个拆开，让它能直接变成测试点。

2.2.1 功能测试：做没做、对不对

功能测试目标：发现程序与外部规格说明（从用户角度描述程序行为）之间的不一致，通常是黑盒测试。

如果遇到"需求不明确"怎么办？来看几种补救路径（非常实用）：

• 查找相关文档，辅助理解产品目标
• 多参加需求/设计/计划讨论，补齐上下文
• 拉相关方评审你整理的结论，评审通过后就能当依据
• 已上线产品：多用产品，不懂问产品负责人
• 看历史缺陷：能提前发现高风险关注点

2.2.2 界面测试：页面不是"能打开就行"

来看界面测试的两个层次：

• 整体界面是否与设计一致
• 界面元素是否可用（控件操作、输入限制、提示语、布局遮挡等）

2.2.3 性能测试：不是"能做"，而是"做得好不好"

功能测试回答"做没做"；性能测试回答"做得怎么样"。典型指标包括响应时间、吞吐、资源消耗、稳定性等。

2.2.4 兼容性测试：环境不同，Bug 不是玄学

软件运行依赖硬件与软件环境。来看兼容性覆盖的常见轴：

• OS（Windows/Linux/Mac / iOS/Android）
• 浏览器（Chrome/Edge/Firefox/Safari）
• 机型/品牌/系统版本

问题：市面机型那么多，难道全测？

来看选取标准：

• 优先选择当前产品 Top 级别使用机型（实际企业可通过后台统计报表拿到）
• 浏览器/机型优先覆盖"主流"组合

2.2.5 易用性测试：新用户能不能"无痛上手"

易用性测试关注"简单易上手"。一个很好用的自测视角：把自己当成从没装过、从没用过的新用户，看是否能顺利完成关键流程。

2.2.6 安全测试：常见安全坑先列出来

安全测试是大领域，但常见高频问题可以先从这几类入手：

• 隐私数据明文展示
• 参数未强校验导致 SQL 注入
• 越权：普通用户能做管理员操作

2.3 额外常用测试类型：弱网 + 安装卸载

在万能公式之外，很多移动端/网络场景会加两类高频测试：

• 弱网测试：尽可能保证用户体验

  • 页面响应时间是否可接受（冷启动/热启动、页面切换、前后台切换、首字/首屏时间）
  • 页面呈现是否一致
  • 超时文案、异常信息是否符合定义
  • 是否有超时重连
  • 安全角度：DNS 劫持、登录 IP 频繁变化、单点登录异常等
  • 大流量风险：弱网下是否触发更新包/大文件下载等高流量动作
  • 构造弱网常借助 fiddler：配置代理 → 抓包（桌面/移动端）→ 构造弱网条件

• 安装卸载测试：针对需要部署的软件

  • 是否能正确安装、覆盖安装、卸载是否彻底、残留文件/配置是否清理、卸载后重装是否正常等

---

3. 基于需求设计用例：从"需求文本"到"测试点"再到"用例"

来看通用流程（很适合工作中落地）：

1. 分析与验证需求（先确认需求合理且一致）
2. 从需求中细化功能点（拆出测试点）
3. 用"万能公式"把测试维度补齐
4. 再用具体方法把测试点细化成可执行用例

以"注册邮箱账号"为例，需求里通常能拆出：

• 功能点：账号注册、账号登录
• 输入约束：姓名/邮箱/密码/确认密码/验证码等（必填、类型、长度、校验）
• 流程：填写→提交→发邮件→24h 激活→成功/失败分支
• 异常：验证码错误、重复注册、邮件发送失败、24h 过期等

---

4. 具体的用例设计方法：从"少量样本"覆盖"最大范围"

4.1 等价类：用"分类代表"替代"穷举"

来看痛点：如果姓名要求 6~15 位，你用穷举测 6、7、8...15 还能忍；如果改成 6~150 位呢？穷举直接爆炸。

等价类的思路是：把输入域划分为若干个"等价类"，从每类选一个代表值测试。代表值通过，则认为该类大概率通过。

• 有效等价类：合理、有意义、满足规格说明的输入集合
• 无效等价类：不满足需求的输入集合

等价类设计步骤：

1. 确定有效/无效等价类
2. 选代表值，写成测试用例（补齐数据与预期）

缺点也要记住：等价类更多关注"单一输入域分类"，不擅长处理"多输入组合关系"，需要其他方法补充。

4.2 边界值：Bug 最爱蹲在边缘阴影里

边界值分析法：对输入/输出的边界进行测试，通常作为等价类的补充（用例来自等价类边界）。

来看两个关键词：

• 边界值：最小/最大合法值
• 次边界值：刚越界/刚不足的值（典型是 min-1、max+1）

例子很直观：

• 长度 1~11：测 0、1、11、12
• 项目 1~3：测 0、1、3、4
• 分页：0 行、1 行、50 行、51 行、999 行......

4.3 正交法：组合太多？用"两两覆盖"降维打击

当多个字段存在"填/不填""多水平组合"时，排列组合数量会指数增长：

• 2 个选项：2² = 4
• 3 个选项：2³ = 8
• 5 个选项：2⁵ = 32（注册表单很容易到这个量级）

正交法的目标：用尽量少的用例覆盖输入的"两两组合" 。

它基于正交表（Orthogonal Array）：从全组合中挑代表点做试验，通过代表点推断整体情况。

正交表的性质（理解它为什么"能代表"）：

• 每列不同数字出现次数相等
• 任意两列的组合排列齐全且均衡

正交法步骤（可直接照着做）：

1. 找到因素 与水平

   • 因素：字段/条件（例如姓名、邮箱、密码、确认密码、验证码）
   • 水平：每个因素的可选状态（例如填/不填）

2. 用工具生成正交表（常见做法是 allpairs）

   • Excel 写因素与水平
   • 粘贴到文本文件 new.txt
   • 命令生成正交表输出

3. 根据正交表写测试用例

4. 补充遗漏的重要用例（正交法覆盖"两两"，不代表覆盖所有关键场景）

示例命令（Windows 习惯写法）：

allpairs.exe new.txt > zhengjiao.txt

经验提醒：工具生成的表可能与你"直觉预期"略有出入，但不影响用于用例设计的核心目标：高效覆盖。

4.4 判定表：条件组合对应不同结果，就用它

当"条件组合 → 结果"呈现明确逻辑关系时，正交法并不擅长（因为它不表达"结果映射"）。这时来看判定表法：用表格清晰表达所有条件组合与结果。

例子：

• 若账号包含 admin 或 通过内部链接进入注册页面，并点击注册按钮，则获得管理员身份；否则无管理员身份。

判定表法步骤：

1. 确认输入条件与输出结果
2. 找出条件与结果的逻辑关系
3. 画判定表
4. 根据判定表编写用例（每条规则一条/多条用例）

这样你能把"所有规则"一次性讲清楚，避免遗漏关键组合。

4.5 场景法：用"事件流"把孤立功能串成业务

很多系统是"事件驱动"的：点击、跳转、超时、失败重试、回调......事件触发的情景形成场景；同一事件不同触发顺序和处理结果形成事件流。

场景法的核心：用业务流把孤立功能串起来，建立整体业务感觉，避免陷入"只测细节不测流程"。

场景通常包含两类流：

• 基本流：正常主流程
• 备用流：在主流程某阶段出现不同情况的分支（备选/异常/推测）

常见场景类型（记住这四类就够用）：

• 正常用例场景
• 备选用例场景
• 异常用例场景
• 假定推测的场景

场景法步骤：

1. 确定基本流
2. 确定备选流
3. 依据备选流补充用例
4. 编写用例（把每条路径走通）

以"注册"为例，基本流可能是：输入账号密码 → 点击注册 → 发送确认邮件 → 24h 内确认 → 注册成功

备用流可以扩成：不输入/只输入部分/账号已注册/网络异常/邮件发送失败/邮件接收失败/确认超时/确认的不是最新邮件等。

4.6 错误猜测法：经验 + 直觉驱动的"高 ROI"补刀

错误猜测法：基于对软件设计的理解、过往经验与直觉，推测可能缺陷，并针对性设计用例。它和探索式测试的思想很接近，在敏捷迭代里投入产出比很高。

典型"猜错点"（注册场景常见）：

• 特殊字符、空格处理
• 密码大小写/复杂度规则
• 姓名的特殊字符
• 密码传输是否明文、敏感信息是否泄漏

缺点也必须诚实面对：难以系统化，过度依赖个人能力。

所以最好的用法是：在等价类/边界值/场景法之后，用错误猜测补最后一圈高风险角落。

---

5. 更多题型怎么迁移：命令行、Web、接口测试的用例思路

5.1 命令行程序（以 zip/unzip 为例）

来看命令行工具的用例设计同样可以套万能公式：

功能测试（不同文件类型/组合）

• txt 能压缩
• 图片/视频/zip 能压缩
• 多文件混合压缩
• 空文件夹是否能压缩
• 错误命令/缺少参数是否提示明确（没写压缩包名、没源文件等）
• 其他参数覆盖

界面测试（命令行输出）

• 成功提示是否清晰
• 报错提示是否友好

性能测试

• 1G 文件能否压缩

• 1G 压缩耗时是否在合理范围

兼容性测试

• Windows/Linux/Mac 下行为一致性

易用性测试

• zip --help 是否提供足够使用说明

安全性

• 压缩/解压过程是否泄漏文件内容、权限是否异常

5.2 Web/接口：从请求方式、参数、格式到性能

来看一个接口测试的拆分维度（直接能变用例）：

• 请求方式：GET/POST 是否按预期响应
• 参数组合：空参、少参、多参
• 参数值：为空/过长/特殊字符/非法类型
• 参数格式：URL 拼参、form-data、raw 等
• 性能：高并发下是否可响应、响应时间是否在可接受范围

实际执行时，命令行 curl 能测但不高效；常用工具是 Postman。

来看 Postman 的关键操作要点：

• 选择请求类型（GET/POST）
• 填 URL
• 填参数（Query / Body）
• 填请求头（鉴权、校验参数）
• 发送请求并断言响应
• 通过导入（Import Raw Text）快速把浏览器/抓包里的请求导入
• 把接口保存到 Collections，避免每次重填

---

6. 一套"拿来就能用"的用例设计清单

最后收束成一套可执行的 checklist（写用例/面试口述都能用）：

1. 先定范围：需求功能点有哪些？主流程是什么？关键规则是什么？

2. 用万能公式补维度：功能/界面/性能/兼容/易用/安全 +（弱网/安装卸载）

3. 用方法细化测试点：

   • 输入约束：等价类 + 边界值
   • 多字段组合：正交法（两两覆盖）+ 关键用例补充
   • 条件组合映射结果：判定表
   • 流程型业务：场景法（基本流 + 备用流）
   • 高风险补刀：错误猜测法

4. 落到可执行用例：补齐环境、步骤、数据、预期结果

5. 回归友好：每条用例尽量可重复执行、可复现、可判定

把这套框架练熟，你会发现：面对"登录、注册、购物车、接口、命令行工具"这类题，思路会非常稳定------不会再出现"感觉有很多要测但不知道从哪下手"的窘境。