软件测试用例指南：覆盖 6 大设计方法

在软件测试中，“找 BUG” 的效率和全面性，全靠测试用例撑着。如果说 BUG 是产品的 “病灶”，那测试用例就是 “诊断手册”—— 不仅要明确 “测什么”“怎么测”，还要保证覆盖全面、不冗余。今天就从测试用例的基础概念入手，拆解设计用例的 “万能思路” 和 6 种核心方法。

一、先搞懂：什么是测试用例？为什么一定要写？

1. 测试用例的定义：不是 “一句话”，是 “完整集合”

测试用例（Test Case）是为了实施测试而准备的 “标准化套餐”，包含测试环境、操作步骤、测试数据、预期结果等核心要素。简单说，就是把 “测试动作” 拆解成可复现、可验证的步骤，让任何人照着做都能得到一致的测试结果。

举个 “网易邮箱注册” 的用例例子，规范的用例长这样：

用例要素	具体内容
用例编号	test-01
标题	成功注册网易邮箱
测试方式	手工测试
功能模块	注册登录
重要性	重要
测试前提	系统运行正常，邮件服务器已开启
测试环境	Win10 + Chrome 103.0.5060.66（64 位）
测试数据	邮箱：[e-mail]；密码：123456；手机号：[phone]
测试步骤	1. 打开 Chrome，输入注册地址注册网易免费邮箱 - 你的专业电子邮局；2. 填写邮箱、密码、手机号，获取并输入验证码，勾选协议；3. 点击 “注册” 按钮
预期结果	显示注册成功页，用新账号可正常登录并进入邮箱首页

2. 为什么必须写用例？这些坑只有用例能避

有人觉得 “凭经验测就行，写用例浪费时间”，但实际工作中，没写用例会踩很多坑：

• 漏测功能：不知道有没有覆盖所有需求，比如注册功能漏测 “验证码过期” 场景；
• 测试的覆盖率：通过一次一次的更新修改，将测试用例写到完全，使得功能覆盖率高即可。
• 回归测试难：新版本迭代时，没法快速验证历史功能是否正常；
• 背锅风险：产品上线后出 BUG，别人会问 “你当时测了吗？”，用例就是你 “测过” 的证据；
• 效率低：重复测试时容易做无用功，比如同一功能反复测相似场景。

现在很多企业（尤其是敏捷团队）会用思维导图写用例，比传统表格更灵活，但核心要素（步骤、数据、预期结果）依然不能少。

面试：思维导图

笔试：表格

二、设计用例的万能思路：3 种思维 + 1 个公式

新手设计用例常犯的错是 “只测正常场景”，比如测门锁只想到 “锁门→开门”，却忽略 “没锁门能不能开”“反锁后能不能从里面开”。想设计出全面的用例，先掌握 “思维 + 公式” 的组合拳。

1. 3 种核心思维：避免用例 “片面化”

• 常规思维：测 “功能应该做什么”，比如门锁 “锁上后能用钥匙打开”；
• 逆向思维：测 “功能不该做什么”，比如门锁 “锁上后不能用手柄打开”；
• 发散思维：测 “各种特殊场景”，比如门锁 “室内反锁后室外能不能开”“没电时能不能开”。

记住两个原则：

面试中：数量多。工作中：质量高。

1. 不仅要测 “有效输入”（比如密码 6-15 位），还要测 “无效输入”（比如密码 5 位、16 位）；
2. 不仅要查 “程序做了该做的”，还要查 “程序没做不该做的”（比如注册时不该明文显示密码）。

2. 万能公式：覆盖所有测试维度

不管测什么产品（门锁、水杯、APP），都能用这个公式拆解测试点：
功能测试 + 界面测试 + 性能测试 + 兼容性测试 + 易用性测试 + 安全测试
（根据场景可补充：弱网测试、安装卸载测试）

补充：

功能测试
功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从
最终用户的角度对程序行为的精确描述。功能测试通常是一项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。
然而，不仅是工作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？
◦ 查找其他相关文档，来帮助理解所要测试的产品需要完成的目标;
◦ 尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理
解;
◦ 召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你
的case了;
◦ 如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理;
◦ 也可以去看历史bug，可以了解到一些需要关注的东西。

界面测试
对软件界面上所有的内容都需要进行测试。
要求：
◦ 整体界面测试界面的实现与设计图要求一致。
◦ 界面元素测试
▪ 控件操作验证

性能测试
性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好。

兼容性测试
软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动
端打开；移动端又分为IOS系统和Android系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。
问题：既然市面上有众多版本的机器，那么在执行兼容性测试时难道所有的机型都需要全面覆盖吗？
选取标准：
• 优先选择使用当前产品top级别的机型进行测试实际在企业中，后台是可以获取到使用产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考。
• 选择主流的浏览器/机型进行测试

易用性测试
易用性测试的标准是检查产品是否具备简单易上手的属性。假如测试人员从来没有安装或使用过
该产品，作为一个新用户，对当前产品是否能够快速适用产品的使用流程。

安全测试
安全测试和性能测试一样都是比较大的领域。常见的安全问题如：
隐私数据明文显示。
参数未强校验导致SQL注入。
越权：普通用户也可以执行管理员权限的操作。

除了万能公式之外，还有一个比较常用的测试类型：弱网测试、安装卸载测试
弱网测试（为了覆盖更多网路场景）
弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：
• 页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
• 页面呈现是否完成一致。
• 超时文案是否符合定义，异常信息是否显示正常。
• 是否有超时重连。
• 安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
• 大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。

如何进行弱网测试？

借助工具：

抓包工具、fiddler、charles

设置的数字越大，传输速率越慢。

安装卸载测试
针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载。

用 “水杯” 举个例子，套用公式后的测试点如下：

• 功能测试：装水不漏水、盖子能拧紧、能正常倒水；
• 界面测试：杯身图案与设计图一致、刻度清晰无模糊；
• 性能测试：装 100℃热水不烫手、装冰水外壁不结露；
• 兼容性测试：能装水、果汁、牛奶（不与材质反应）；
• 易用性测试：握感舒适、盖子易拧开、刻度易读取；
• 安全测试：材质无异味、不释放有害物质；
• 补充测试：摔落测试（1 米高度掉地上不碎）、高温测试（-20℃~100℃不变形）。

这个公式的核心是 “不遗漏维度”，确保从 “能不能用”“好不好看”“快不快”“安不安全” 等角度全面测试。

三、6 大实用用例设计方法：从理论到实战

基于需求的设计方法也是总的设计测试用例的方法，在工作中，我们需要参考需求文档/产品规格说明书来设计测试用例。

测试人员接到需求之后，要对需求进行分析和验证，从合理的需求中进一步分析细化需求，从细化的需求中找出测试点，根据这些测试点再去设计测试用例。

掌握万能公式后，还需要具体方法来细化测试用例，避免 “测试点太多，不知道怎么落地”。下面 6 种方法是常见的，结合 “邮箱注册” 案例分析：

匿名用户：没有注册的用户。

基本事件流：通用流程/绝大多数用户的操作流程/主流程。

扩展事件流：可能的流程。

注意：

1. 等价类：解决 “穷举测试” 的痛点

核心逻辑

把 “输入数据” 分成若干 “等价类”，每个类选一个用例代表 —— 如果这个用例通过，就认为整个类通过，减少用例数量。

• 有效等价类：符合需求的输入（比如注册姓名 6-15 位字符）；
• 无效等价类：不符合需求的输入（比如姓名 5 位、16 位字符）。

实战案例（邮箱注册 “姓名” 字段：必填，6-15 位字符）

等价类类型	具体用例	预期结果
有效等价类	输入 10 位字符（如 “ZhangSan23”）	无错误提示
无效等价类	输入 5 位字符（如 “LiiSi”）	提示 “姓名长度需 6-15 位”
无效等价类	输入 16 位字符（如 “ZhangSan12345678”）	提示 “姓名长度需 6-15 位”
无效等价类	不输入姓名（空）	提示 “姓名为必填项”

缺点

只考虑单个输入字段，不考虑字段间的组合（比如 “姓名 + 邮箱 + 密码” 的组合场景），需要配合其他方法使用。

测试中易踩坑的 “隐性字符” 长度计算

除可见字符外，输入中可能包含空格、制表符、换行符等 “隐性字符”，这类字符的长度计算常被忽略，却可能导致 BUG：

隐性字符	字符表示	编码（UTF-8）	长度计算	测试场景示例
半角空格	（空格符）	1 字节	1 个空格 = 1 字节	密码中包含空格（如123 456），需验证系统是否允许，长度是否算 7 字节
全角空格	（全角空格）	3 字节	1 个全角空格 = 3 字节	姓名字段输入 “张 三”（半角空格）vs“张　三”（全角空格），长度差异是否影响合规性
换行符	\n	1 字节	1 个换行符 = 1 字节	文本框输入换行，系统是否统计换行符为 1 字节，是否超出长度限制

2. 边界值：等价类的 “补充工具”

核心逻辑

很多 BUG 出在 “边界附近”，比如需求 “6-15 位”，BUG 可能出在 5 位、6 位、15 位、16 位。边界值不仅要测 “边界”，还要测 “次边界”（比如 6 位是边界，5 位是次边界；15 位是边界，16 位是次边界）。

实战案例（还是 “姓名” 字段：6-15 位）

边界类型	具体用例	预期结果
下边界	输入 6 位字符（“LiSi12”）	无错误提示
下边界次边界	输入 5 位字符（“LiSi1”）	提示错误
上边界	输入 15 位字符（“ZhangSan12345”）	无错误提示
上边界次边界	输入 16 位字符（“ZhangSan123456”）	提示错误

关键

边界值通常和等价类一起用，覆盖 “正常场景 + 边界场景”，比如先用品类划分 “有效 / 无效”，再用边界值细化 “边界附近的无效场景”。

3. 正交法：减少 “多字段组合” 的用例数量

核心逻辑

当有多个输入字段（比如姓名、邮箱、密码、验证码），每个字段有 “填写 / 不填写” 两种状态，用排列组合会产生 2^5=32 个用例，效率太低。正交法通过 “正交表” 挑选有代表性的组合，用最少的用例覆盖 “两两组合”。

✅ 正交法的目的是为了减少用例数目。用尽量少的用例覆盖输入的两两组合。

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

正交表：
如图最简单的正交表是，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，
简称行，即要做四次试验；括号内的指数“3”表示有3 纵列，简称列，即最多允许安排的因素是3
个；括号内的数“2”表示表的主要部分只有2 种数字，即因素有两种水平1与2。

正交表的构成：因素数、水平数、行数。
因素：对指标的影响条件/存在条件，通常是正交表中的一列。
水平：因素的取值。

正交表的性质：
• 每一列中，不同的数字出现的次数相等。
• 任意两列中数字的排列方式齐全而且均衡。（每一列每个数字出现的次数是相同的）

实战案例（邮箱注册 5 个必填字段：姓名、邮箱、密码、确认密码、验证码）

步骤 1：确定 “因素” 和 “水平”

• 因素：5 个字段（姓名、邮箱、密码、确认密码、验证码）；
• 水平：每个字段的状态（填写 = 1，不填写 = 2）。

步骤 2：用工具生成正交表（推荐 AllPairs 工具）

使用Excel保证格式正确，复制到文本文件，不要有其他操作，直接保存

1. 在 Excel 中列出因素和水平，复制到文本文件（如 new.txt）；
2. 执行命令：allparis.exe new.txt > zhengjiao.txt，生成正交表；

步骤 3：补充遗漏用例

比如 “全部不填写” 的场景，正交表可能没覆盖，需要手动补充。

注意：使用allparis生成的正交表和预期有出入，但是不影响我们用来设计测试用例。

4. 判定表法：解决 “多条件组合对应多结果” 的场景

核心逻辑

当需求中 “条件组合” 对应不同 “结果” 时，用判定表清晰列出所有组合，避免遗漏。比如需求：“账号含 admin，或通过内部链接进入，点击注册→成为管理员；否则→普通用户”。

通过这个需求可以看出，不同的组合操作可能对应不同的结果。采用正交法无法解决这样的问题。而正交法能够解决需要考虑输入之间的组合关系对应不同结果的场景。

判定表
判定表是一种表达逻辑判断的工具，形如：

如果没有判定表，则写出来的用例组合非常乱，思路不清晰。

实战案例（管理员注册需求）

步骤 1：确定输入条件和输出结果以及关系

• 输入条件：账号含 admin（A）、内部链接（B）、点击注册按钮（C）；
• 输出结果：成为管理员（1）、普通用户（0）。

通过对输入条件的组合找出不同组合对应的结果。

步骤 2：画判定表

步骤 3：编写用例

根据判定表，每个 “Y/N 组合” 对应一个用例：
a. 账号包含admin，非内部注册链接，点击注册按钮，为管理员身份
b. 账号包含admin，内部注册链接，不点击注册按钮，非管理员身份
c. 账号不包含admin，内部注册链接，点击注册按钮，为管理员身份
d. 账号包含admin，内部注册链接，点击注册按钮，为管理员身份
e. 账号包含admin，非内部注册链接，不点击注册按钮，非管理员身份
f. 账号不包含admin，非内部注册链接，点击注册按钮，非管理员身份
g. 账号不包含admin，非内部注册链接，不点击注册按钮，非管理员身份

5. 场景法：模拟 “真实业务流程”

核心逻辑

软件的功能是 “事件触发” 的，比如注册流程是 “选择注册→同意协议→填信息→提交→收邮件→激活”。场景法通过 “基本流”（正常流程）和 “备选流”（异常流程），覆盖所有可能的业务场景。

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。

场景法一般包含基本流(基本事件流)和备用流（备用事件流），从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

场景法就是一个常规的流程中，某些阶段可能会出现一些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法比较考验发散思维。
以逛街买衣服为例:

实战案例（邮箱注册流程）

步骤 1：确定基本流（正常流程）

用户选择注册→同意协议→填写所有信息→提交→收激活邮件（24 小时内）→激活→注册成功。

步骤 2：确定备选流（异常流程）

步骤 3：编写用例

注意：

在场景法应用时，需要注意的是，商家活动系统的时间问题。

比如：

6. 错误猜测法：凭经验 “预判 BUG”

核心逻辑

基于对产品的理解、过往经验和直觉，推测可能存在的 BUG，比如 “注册时密码是否区分大小写”“姓名含特殊字符是否报错”。这种方法和 “探索式测试” 思路一致，在敏捷团队中很常用。

实战案例（邮箱注册）

• 用例 1：密码输入 “123456”，确认密码输入 “123456”→预期匹配；
• 用例 2：密码输入 “123456”，确认密码输入 “123456a”→预期提示 “两次密码不一致”；
• 用例 3：姓名含特殊字符 “张三 @”→预期提示 “姓名仅支持中英文和数字”；
• 用例 4：注册时输入已存在的邮箱→预期提示 “该邮箱已注册”。

缺点

过度依赖个人经验，难以系统化，需配合其他方法使用。

这些具体的测试方法，是为了提高我们的测试思路+提高我们设计测试用例的能力。