【软件测试】（用例篇）

一.测试用例的概念

测试用例（Test Case）是为执行测试，向被测系统准备的一组内容集合，包含：测试环境、操作步骤、测试数据、预期结果等要素。

注意：测试用例本身不包含执行结果。执行结果是运行用例之后才得到的，编写测试用例阶段不存在执行结果。

测试用例原则一： 测试用例必须定义预期输出 / 预期结果。

**高质量测试用例标准：**即使不熟悉业务的人员，也可以根据用例快速开展测试。

评价测试用例好坏的标准：

描述清晰，不存在歧义；

具备可操作性，能够落地执行；

输入、输出明确，一条用例对应一个预期结果；

可维护性良好；

对需求的覆盖率高。

什么是要素？

我们在编写测试⽤例的时候，每个⽤例需要给出这些要素对应的信息。

字段	内容
用例编号	test-01
标题	成功注册网易邮箱
测试方式	手工测试
功能模块	注册登陆
重要性	重要
测试前提	系统运行正常，邮件服务器已开启
测试环境	win10 Chrome 版本 103.0.5060.66（正式版本）（64 位）
测试数据	邮箱地址：996402440@qq.com密码：123456手机号：12312341234
测试步骤	1. 打开谷歌浏览器，输入网易注册地址：https://mail.163.com/register/index.htm2. 输入邮箱地址、密码、手机号，获取验证码并输入正确的验证码，勾选协议3. 点击注册按钮
期望结果	展现注册成功的结果页，并且使用刚注册的账号可以正常登陆并进入邮箱首页

我们在笔试的时候编写测试用例题，按照 excel 表格的方式来答题（会涉及到测试用例的要素）

我们在面试的时候回答测试用例题，按照思维导图的方式一一道来即可（不会涉及到测试用例的要素）

为什么需要测试用例呢，不写测试用例可以进行测试吗？

测试中可能会遇到很多问题（能解决的问题），诸如：

不知道是否较全面的测试了所有功能。

测试的覆盖率无法衡量。

对新版本的重复测试很难实施（即回归测试无法仅通过人工测试的方式进行历史功能的回归）。

存在大量冗余测试影响测试效率。

测试用例的出现就是解决以上这些问题。另外，测试用例的作用还可以避免测试人员被迫背锅。实际中产品出现问题，第一责任人首先想到的是测试为什么没有测到？上面展示的是传统的编写测试用例的方式，在学习敏捷模型的时候了解到，如今大多数企业采用的都是思维导图的方式来编写测试用例，后面的内容包括用例练习都是用思维导图进行编写。

1.编写测试用例带来的好处

作为测试人员执行测试工作的依据，保证测试工作有据可依。

让测试工作具备可重复性，同时也是自动化测试实现的基础。

方便评估需求覆盖程度，检验需求是否全部覆盖。

测试用例可以复用，后续迭代版本可直接参考使用。

沉淀测试思路与方法，方便后续项目参考借鉴。

2.使用测试用例存在的弊端

设计测试用例需要投入大量时间精力，很多场景下，编写用例耗费的时间甚至超过执行测试本身的时间。

二.测试用例的设计方法

1.设计测试用例的万能公式

现在有⼀款产品，要求我们对**"⻔锁"**设计测试⽤例，假如你是测试⼈员，你会怎么设计呢？

可以看出，⽤例的设计最重要的⼀点是保证功能是正确的。上图给出的案例，在互联⽹企业中，这样去设计测试⽤例的⾮常少，缺乏经验的同学往往以这样的思路去设计。

(1)常规思考+逆向思维+发散性思维

正确设计测试用例的思想

设计测试用例要结合三种思维：常规思维 + 逆向思维 + 发散性思维

设计测试用例的原则二

编写测试用例，既要考虑合法、预期内的输入场景，也要考虑非法、意外的输入场景。

检验程序完成了它应该实现的功能 ，只完成了一半测试；另一半重点，是验证程序不会去做不该做的事情（这是上一条原则的延伸）。

规划测试工作时，不能预先假设程序不存在缺陷。

明⽩了设计测试⽤例是思维的正确还往往不够。

若仅仅通过头脑⻛暴去设计测试⽤例，那么当我们⾯对⾯试官时，能够想出来的⽤例是寥寥⽆⼏的，所以在设计测试⽤例的时候需要有思路的去设计。

（2）万能公式

设计测试⽤例的万能公式：功能测试+界⾯测试+性能测试+兼容性测试+易⽤性测试+安全测试。

A. 功能测试

从产品功能角度出发，验证功能是否正确。

物体：这个物体是用来干什么的

软件：软件实现功能

功能测试，目的是找出程序和外部规格说明之间存在的不一致问题。外部规格说明，是站在最终用户角度，对程序行为做出精准描述的文档。功能测试一般属于黑盒测试。做功能测试时，我们分析规格说明提炼测试用例，这篇文章讲的用例设计方法非常适合功能测试。

但是在工作或者面试里，经常会遇到需求不明确的功能，这种情况该怎么做功能测试？

查找相关文档，辅助理解产品要实现的目标。

多参加项目组会议，例如需求讨论、设计讨论、计划会议，加深对产品的理解。

召集相关人员，针对自己整理的理解内容进行讨论，评审通过后，就可以拿这份文档作为依据设计测试用例。

如果产品已经上线，可以多实操使用产品，有疑问咨询产品经理。

查阅历史 Bug 记录，了解需要重点关注的场景。

B. 界面测试

物体：外表、材质、大小、容量......

软件：界面、字体大小、字体颜色、页面布局......

肉眼能够看到的部分都属于界面，界面里所有元素都需要测试。界面测试内容：元素（大小、颜色、形状、可交互属性）。软件界面上所有内容都需要开展测试。

要求：

整体界面：验证界面实现效果和设计图保持一致。

界面元素：验证各类控件的操作是否正常。

C. 性能测试

一般针对各类极端场景。

物体：使用寿命

软件：响应时间、吞吐量、并发数、CPU 占用率

性能测试和功能测试的区别：

功能测试检查软件能不能完成功能；

性能测试检查软件功能做得好不好。

D. 兼容性测试

不同版本（软件、操作系统），浏览器兼容性（不同浏览器）

物体：物体除核心功能外，是否具备其他附加能力

软件：操作系统（电脑 windows、mac、linux；手机 ios、Android）、设备、浏览器版本

软件运行在硬件之上，依赖对应的软件环境。例如 QQ，电脑端、移动端都可以使用；移动端分为 IOS 和 Android 系统，手机还有不同品牌、机型、系统版本。测试人员需要验证软件在各类环境下能否正常运行。

市面上机型数量很多，兼容性测试不需要覆盖全部机型。

选取标准：

优先选用产品用户 TOP 排名的机型测试。

企业后台可以统计用户使用机型，生成报表，供产品人员制定测试策略。

选择主流浏览器、主流机型开展测试。

E. 易用性测试

核心特点：简单易上手。

易用性：使用体验（操作简单、操作流程）、人性化、见名知意。

易用性测试的判断标准：产品是否简单易上手。假设测试人员从未安装、使用过该产品，以新用户视角，能否快速上手产品操作流程。

F. 安全测试

物体：物体材质是否有毒，会不会伤害人体健康

软件：sql 注入、xss 漏洞、输入恶意脚本、密码加密保存、权限控制

安全测试和性能测试一样，属于一个很大的测试领域。常见安全问题：

隐私数据明文展示。

参数缺少强校验，产生 SQL 注入漏洞。

越权问题：普通用户可以执行管理员权限操作。

除了万能公式之外，还有⼀个比较常用的测试类型：弱网测试、安装卸载测试。

弱网测试

弱网测试的目的是尽可能保障用户体验，重点关注以下内容：

页面响应时间是否达标：包含冷启动、热启动耗时、页面切换、前后台切换、首字时间、首屏时间等指标。

页面展示效果是否完整、一致。

超时提示文案是否符合规范，异常信息展示正常。

网络断开后，是否支持超时重连。

安全层面：是否存在 DNS 劫持、登录 IP 频繁变更、单点登录异常等问题。

大流量场景风险：弱网环境下，是否会自动执行 APK 更新、文件下载等消耗大量流量的操作。

弱网需要借助工具来构造弱网，这里推荐使用 fiddler

fiddler 配置代理

fiddler 进行抓包（桌面 / 移动端）

fiddler 如何构造弱网条件

如何模拟弱网？

1.推荐借助工具（Fiddler / Charles）

Download Fiddler Web Debugging Tool for Free by Telerik

2.打开限速模式

打开弱网设置选项：

打开设置弱网的脚本：

打开弱网设置：

上传 1kb 文件需要花费 300ms（上行速率），下载 1kb 需要花费 150ms（下行速率）。

这里的数字越小，说明网速越好。

H. 安装卸载测试

安装包是否可以安装，卸载之后是否可以继续安装、重复安装，软件更新后是否安装成功。
安装完成后卸载，安装一半后卸载，卸载一次后继续安装继续卸载，卸载一半停止后是否还可以继续卸载。

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

2.基于需求进行测试用例的设计

基于需求设计测试用例，是测试用例设计与开发的基础。第一步先分析测试需求，校验需求是否正确、完整、不存在歧义，并且逻辑自洽。

确认需求无误之后，再细化测试需求，从测试需求中提炼出各个测试点（测试项），再针对每一个测试点设计对应的测试用例。

分析测试需求时，一般分为功能测试需求和非功能测试需求。

基于需求的用例设计方法属于总纲性质的用例设计思路。实际工作中，我们需要参考需求文档、产品规格说明书来编写测试用例。

以该注册邮箱账号需求为例，我们来设计测试⽤例。

1.明确需求中的功能点:

账号注册，账号登陆

2.结合万能公式设计测试点:

【163 邮箱注册】

（1）功能需求测试分析

做功能测试的需求分析时，可以借助功能框图辅助梳理。功能测试需求一般包含下面几方面：

系统各类功能界面的验证

结合完整业务流程，串联各个功能开展测试

功能一致性、多功能之间交互互操作的测试

针对系统不同输入，校验业务输出结果的数据测试

错误操作、异常操作场景测试（负面测试）

功能底层算法验证，部分场景需要配合代码评审

用户操作易用性、用户体验，通常和功能测试同步验证

针对具体需求，可以按照业务类型、用户角色（例如餐厅会员系统）或者用户操作区域，把系统拆分成多个功能模块，再分模块开展测试需求分析。按功能模块、业务模块划分，是最常用的方式。

开展需求分析时，还需要重点考虑业务规则。例如：上传文件的大小限制、单次最多上传文件数量（如不超过 100 个）、文件夹最大层级等。

（2）非功能需求测试分析

非功能测试需求主要包含性能、安全性、可靠性、兼容性、易维护性、可移植性等方面。在做测试需求分析时，每一类非功能特性都需要单独分析，不同特性之间可能会互相影响。举例：安全防护级别越高，越可能对易用性、系统性能带来压力。

需要明确：所有应用软件系统，都存在非功能质量需求。但不同项目，对各项非功能指标的要求差异很大，需要结合项目本身、业务需求以及产品应用场景来分析。

A. 纯客户端软件

例如文字处理软件（Word、PPT）、音视频播放器（系统自带播放器）。这类软件的功能测试要求相对低，但是对兼容性、稳定性、可移植性有一定要求。

B. 企业内部 C/S（客户端 / 服务端）应用系统

例如邮件系统、即时通讯工具（飞 Q、企业 QQ）。相比纯客户端软件，它的功能测试需求更复杂，要求功能正常、运行稳定。但整体来看，对性能、安全性、兼容性的要求不算高。

C. 外部大型复杂网络应用系统

例如电商平台、网上银行、视频网站（腾讯、优酷）。除了复杂的功能测试需求以外，系统在性能、安全性、兼容性、容错性、可靠性等方面都有很高标准。

除此之外，大型企业级应用系统，受应用模式、系统架构（分布式、微服务等）影响，我们必须结合架构与业务场景分析非功能测试需求，重点关注可扩展性、可靠性、安全性。技术架构对功能影响较小，但非功能测试需要深入分析架构，才能更好把握测试范围与测试方法。

举例如下：

从用户需求到测试用例

bash 复制代码

用户需求：
买一台 5000 元以内的、带主动降噪的蓝牙耳机

测试用例：
1. 价格 <= 5000 元
2. 连接方式为蓝牙
3. 具备主动降噪功能
4. 耳机功能验证：
   4-1. 开机 / 关机
   4-2. 与手机配对
   4-3. 播放 / 暂停
   4-4. 接听 / 挂断电话
   ...

从软件需求到测试用例

bash 复制代码

软件需求：
1.1.1.1.5.3 异常事件流
1. 若用户未收到短信验证码，可在 60 秒后点击"重新发送"再次获取。
2. 每次发送的验证码，仅在发送后 5 分钟之内有效，超过 5 分钟后需重新获取。

测试用例
1-1、未收到短信，点击"重新发送"，验证码再次下发
1-2、发送后 60 秒内点击"重新发送"，按钮置灰不可点

2-1、收到验证码，5 分钟内输入，验证通过
2-2、收到验证码，5 分钟后输入，提示"验证码已过期"
2-3、收到验证码，已成功使用过一次，再次输入同一验证码，提示"验证码无效"

页面检查：
1、短信正常下发
2、短信内容正确，包含验证码与有效期说明
3、倒计时按钮状态正确（可点 / 置灰）
4、验证码过期时提示文案正确
5、验证码重复使用时提示文案正确

3.具体的设计方法

（1）等价类

上面注册邮箱账号的测试用例还未全部设计完成，针对姓名必填，6~15 位字符这一条需求，该如何设计测试用例？

如果采用穷举法，依次测试 6 位、7 位、8 位......14 位、15 位字符，判断能否正常提交，这种方式是否满足企业测试要求？假设需求范围修改为 6~150 位，仅仅这一个测试点，穷举所耗费的时间就会非常多，显然在企业项目中不可行。等价类划分法，就是用来解决穷举法的这个痛点。

**等价类划分：**依据需求，把输入（特殊场景下也会考虑输出）划分成若干等价类别。从每一个等价类里挑选一条测试用例，如果这条用例执行通过，就代表该等价类内其余数据都符合要求。通过这种方式，用少量测试用例，实现尽可能多的需求覆盖，解决无法穷举全部输入的难题。

**生活中等价类例子：**因材施教理论上老师需要针对每一位学生单独制定学习方案，但学生数量多，无法逐个精细化管理，于是将学生划分为几类：

优等生：拓展知识面，提升综合能力

中等生：夯实基础，查漏补缺

差等生：优先掌握核心重点，暂时跳过难点

核心思路：输入的数据集合数量庞大，无法全部覆盖。将输入划分为若干等价类，每类选取一条用例，用例通过即代表该等价类整体通过，以少量用例完成覆盖。

有效等价类 ：符合需求规格、有意义的输入数据集合。用来验证程序可以正常实现需求规定的功能。也就是满足用户要求的输入集合。

无效等价类 ：不符合需求规格、不满足用户要求的输入数据集合。

基于等价类设计测试用例步骤：

划分出有效等价类与无效等价类

编写测试用例，设计对应的测试数据

根据边界值将上述未完成的⽤例进⾏完善

缺点：等价类划分只对输入域单独分类，不会考虑多个输入之间的组合关系，遇到多输入联动场景，需要搭配其他测试用例设计方法补充覆盖。

cpp 复制代码

示例：登录账号密码校验 
需求：账号 4~16 位字符，密码 6~12 位字符 
有效等价类：账号 4~16 位，密码 6~12 位 
无效等价类：账号小于 4 位 / 账号大于 16 位；密码小于 6 位 / 密码大于 12 位

等价类思想设计测试用例的步骤：

充分理解需求，梳理清楚输入约束条件

划分有效等价类、无效等价类

分别针对有效等价类、无效等价类，设计对应的测试用例

（2）边界值

边界值分析法，是针对输入、输出边界开展测试的黑盒测试方法。它一般作为等价类划分法的补充，边界值测试用例，就取自等价类区间的边界位置。

生活里的边界漏洞举例：考完试公布成绩，老师布置寒假作业：成绩超过 60 分，习题抄写 1 遍；成绩低于 60 分，习题抄写 3 遍。小明刚好考了 60 分，既不属于 "超过 60"，也不属于 "低于 60"，因此不用写作业，这就是边界条件描述漏洞。

边界值选取包含：边界点 + 次边界点

输入框长度限制 1~11 位：选取边界值：0、1、11、12

运动员参赛项目 1~3 项：选取边界值：0 项、1 项、3 项、4 项

查询页面最多 999 行，每页展示 50 行：选取边界值：0 行、1 行、50 行、51 行、999 行

我们继续将上述用例通过边界值补充完整：

边界值即给定返回的左数据和右数据。

选择次边界值的时候，根据边界值的有效无效情况来定：

如果边界值为有效等价类中的数据，则次边界值为无效等价类中的数据。

如果边界值为无效等价类中的数据，则次边界值为有效等价类中的数据。

边界点

上点：落在区间边界上的数值点。

内点：区间范围内部的点，不受区间是开区间还是闭区间影响。

离点：紧贴边界附近的点。对于闭区间，离点是区间外侧、离上点最近的值；对于开区间，离点是区间内侧、离上点最近的值。

（3）因果图（判定表法）

因果图是一种简化的逻辑图，可以直观展示程序输入条件（原因）与输出动作（结果）之间的关联关系。因果图法是依托图形来设计测试用例的系统化方法，非常适合被测程序存在多组输入条件，且输出结果由各类输入条件组合共同决定的场景。

使用该方法可以让设计出来的测试用例更加完整、规范。

我们把需求简化为下面场景： 用户输入账号包含 admin 字符串，或者通过内部链接进入注册页面，点击提交注册按钮，即可获得管理员身份；不满足条件则没有管理员身份。

从这个需求能看到，不同操作组合会产生不一样的输出结果。正交试验法并不适合处理这类场景；正交法适合输入组合相互独立的场景。

A. 因果图需要掌握的基础知识

a. 恒等

条件成立，则结果一定成立。

b. 与

全部条件都必须满足，只要任意一个条件不成立，结果就不成立。

c. 或

多个条件里只要满足任意一个，结果就成立；只有所有条件都不成立时，结果才不成立。

d. 非

条件不成立时，结果才成立。

B. 因果图法设计测试用例的步骤

分析需求，提取全部输入条件和输出结果。

梳理输入条件和输出结果之间的逻辑关系。

绘制判定表。

基于判定表编写测试用例，判定表每一行对应一条测试用例。

C. 判定表

判定表（Decision table）是一种表达逻辑判断的工具。

通过该图，可以把所有条件对应的结果清晰的表达出来。我们就需要借助该表来清晰的写出测试⽤
例。

确认了步骤后，我们使用判定表法进⼀步对上述需求进行测试用例的设计：

1.确认需求中输⼊条件和输出条件

输入条件：账号包含 admin 字符（a）、内部注册链接（b）、点击注册按钮（c）

输出条件：管理员（1）、无管理员（2）

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

输入条件：ac ab bc abc a b c 非abc

对应结果：1 2 1 1 2 2 2 2

这里：

a：账号包含 admin 字符

b：内部注册链接进入页面

c：点击注册按钮

abc就是a、b、c 三个条件同时成立

ac：a 成立，c 成立，b 不成立

ab：a 成立，b 成立，c 不成立

bc：b 成立，c 成立，a 不成立

a：只有 a 成立，b、c 都不成立

b：只有 b 成立，a、c 都不成立

c：只有 c 成立，a、b 都不成立

非abc：a、b、c 全都不成立

业务规则回顾：账号含 admin 或者内部链接，并且点击注册按钮，才能成为管理员。也就是逻辑表达式：(a || b) && c

3.画判定表

有 3 个条件，输出有 2 个取值，所以表的列数为：2*2*2=8

根据判定表编写测试用例：

账号包含 admin，非内部注册链接，点击注册按钮，为管理员身份

账号包含 admin，内部注册链接，不点击注册按钮，非管理员身份

账号不包含 admin，内部注册链接，点击注册按钮，为管理员身份

账号包含 admin，内部注册链接，点击注册按钮，为管理员身份

账号包含 admin，非内部注册链接，不点击注册按钮，非管理员身份

账号不包含 admin，非内部注册链接，点击注册按钮，非管理员身份

账号不包含 admin，非内部注册链接，不点击注册按钮，非管理员身份

【淘宝 618 活动】

业务单据处理规则：淘宝 618 活动期间，订单已提交，并且订单合计金额大于 300 元或者拥有红包，即可享受优惠。

a. 分析业务规则，提取全部输入条件与输出结果输入条件：订单已提交、订单金额大于 300 元、有红包输出结果：享受优惠、不享受优惠

b. 第二步，梳理输入条件和输出结果之间的对应关系

订单已提交，金额大于 300 元，有红包 → 优惠

订单已提交，金额大于 300 元，无红包 → 优惠

订单已提交，金额≤300 元，有红包 → 优惠

订单已提交，金额≤300 元，无红包 → 不优惠

订单未提交，金额大于 300 元，有红包 → 不优惠

订单未提交，金额大于 300 元，无红包 → 不优惠

订单未提交，金额≤300 元，有红包 → 不优惠

订单未提交，金额≤300 元，无红包 → 不优惠
逻辑表达式：订单已提交 &&（金额 > 300 || 有红包）

c. 设计判定表：

d. 把判定表对应到每一个测试用例：

（4）正交法（正交排列）

依靠等价类与边界值分析法，我们已经补充了一部分测试用例。但还有一类场景的用例没有完善：只填写部分选项。针对这类场景，我们需要思考：究竟需要设计多少条测试用例？

想要保障系统测试覆盖率，最先想到的思路就是全排列组合。

假设有 A、B 两个选项，可以设计 4 条用例：都填写、都不填写、只填 A、只填 B，总数为（2²）。

假设有 A、B、C 三个选项，全部组合一共可以得到 8 条测试用例，总数为（2³）。

......

如果一共有 5 个选项：姓名、电子邮箱、密码、确认密码、验证码。全排列组合需要设计 32\条用例。

问题：使用因果图法生成的测试用例数量过多，该如何精简？

正交法的核心目标：缩减测试用例数量，用尽可能少的用例，覆盖输入条件之间所有两两组合情况。

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

正交表： 举一个最简单正交表，含义说明如下： "L" 代表正交表；L 右下角数字 "4" 代表一共有 4 行，代表需要执行 4 次试验；括号内右上角指数 "3" 代表一共有 3 列，最多可以放置 3 个测试因素；括号内数字 "2" 代表每个因素仅有 2 种水平，用数字 1、2 表示。

正交表的构成：因素数、水平数、行数。

因素（Factor） ：会影响测试指标的条件，对应正交表中的一列。试验中所有需要考察的变量，称为因素（变量）。

水平（位级）（Level） ：单个因素对应的可选取值。在试验范围内，给因素设定的考察值称为水平（变量的取值）。

正交表的构成

行数（Runs） ：正交表中行的数量，代表试验执行次数，用 N 代表。

因素数（Factors） ：正交表中列的数量，用 C 代表。

水平数（Levels） ：单个因素最多可取的取值数量。正交表内数值范围一般是 0 ~ 水平数 - 1 或者 1 ~ 水平数，用 T 代表。

A. 正交表的表示形式

L=行数(水平数^因素数) L_n(m^k)

B. 正交表的两条性质

每⼀列中，不同的数字出现的次数相等。

试验号 \ 列号 1 2 3 4

1 1 1 1 1

2 1 2 2 2

3 1 3 3 3

4 2 1 2 3

5 2 2 3 1

6 2 3 1 2

7 3 1 3 2

8 3 2 1 3

9 3 3 2 1

任意两列中数字的排列⽅式⻬全⽽且均衡

试验号 \ 列号 1 2 3 4

1 1 1 1 1

2 1 2 2 2

3 1 3 3 3

4 2 1 2 3

5 2 2 3 1

6 2 3 1 2

7 3 1 3 2

8 3 2 1 3

9 3 3 2 1

试验号 \ 列号	1	2	3	4
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

试验号 \ 列号	1	2	3	4
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

根据正交表的性质，⼀般⼈很难通过⼿动设计出正交表

C. 正交法设计测试用例的步骤

找到因素和水平

用 allpairs 工具生成正交表

将因素和水平填写到 Excel 表格中

在 allpairs 目录下新建文本文件 new.txt，复制 Excel 里的因素、水平内容粘贴到文本内，保存并退出

执行 allpairs 命令生成正交表：allpairs.exe new.txt>zhengjiao.txt

根据正交表编写测试用例

补充遗漏的重要测试用例
完整流程梳理：充分理解需求（梳理所有变量 / 元素）

--> 确定因素水平（明确每个因素对应的取值）

--> 构建正交表（挑选适配的正交表，将变量值映射填入）

--> 完善正交表

--> 将正交表转为测试用例（正交表每一行代表一组因素组合，作为一条测试用例；额外补充正交表没有覆盖，但风险较高的场景）

【注册的需求】

以注册场景举例，使用正交法补齐剩余测试用例业务规则：姓名、邮箱、密码、确认密码、验证码必须全部填写，才可以完成注册。

A. 因素和水平

因素：姓名、邮箱、密码、确认密码、验证码

水平：填写、不填写

B. 利用 allpairs 画正交表

a. 先将水平和因素填写到 Excel 表格中

如果不使用 Excel，直接手动在 txt 文件里面编写因素和水平，执行命令生成正交表时容易出现格式校验报错。allpairs 工具对于文本格式要求非常严格。

补充说明：

Excel 编辑的优势：可视化编辑，不容易出现多余空格、换行符等隐性格式问题；

txt 手动编写坑点：多余空格、空行、制表符都会让 allpairs 解析失败，新手容易踩坑。

b.allparis⽬录下创建新的⽂本⽂件0714.txt，复制Excel中的因素和⽔平，直接粘贴到⽂本中保
存并退出

c. 使⽤allparis命令⽣成正交表：allparis.exe 0714.txt>0714jg.txt（将⽣成的正交表数据放⼊
0714jg.txt⽂件中）

正交表确实复杂，但是在工作中很少使用，但我们还是要学习

（5）场景设计法

场景设计法围绕完整业务流程来设计测试用例。现代软件大多依靠事件触发驱动业务流程，事件触发对应的业务情景就是场景；同一个事件，不同的触发顺序、不同处理结果会形成不同事件流。该方法能够形象描述事件触发时的业务情景，方便测试人员编写测试用例，产出的用例可读性强、便于执行。

场景法的典型作用：通过业务流程串联各个独立功能点，帮助测试人员建立全局业务视角，避免只盯着零散功能细节，忽略业务主流程。

场景设计法，是借助业务场景描述系统功能与业务流程，以此提升测试有效性的测试方法。基于用例场景开展测试，就是模拟各类边界场景，依靠事件触发对应的业务动作，观察最终执行结果，以此挖掘需求缺陷。一般分析顺序：先梳理正常主场景，再拓展其他各类场景。

场景法核心分为基本流与备选流：以一条主线流程为起点，通过描述执行路径确定业务过程；遍历全部基本流和备选流，完成所有场景梳理。场景一共分为 4 类：正常用例场景、备选用例场景、异常用例场景、推测假设场景。

简单理解场景法：在标准常规流程里，部分节点会发生各类意外情况。这条正常主线就是基本流；各个节点衍生出来的异常、分支情况就是备选流。场景法比较考验测试人员的发散思维。

该⽅法可以⽐较⽣动地描绘出事件触发时的情景，有利于测试设计者设计测试⽤例，是测试⽤例更容易理解和执⾏。

典型的应⽤是是⽤业务流把各个孤⽴的功能点串起来，为测试⼈员建⽴整体业务感觉，从⽽避免陷⼊功能细节忽视业务流程要点的错误倾向

【注册】

确定基本流与备选流之后，就可以编写对应的场景测试用例：

基本流：进入注册页面，勾选同意用户协议，填写合法注册信息，提交注册；系统发送邮箱激活链接，用户完成激活，注册成功。

备选流 1：进入注册页面，不勾选用户协议，无法继续；返回重新操作，勾选同意协议，填写正确信息提交注册，接收邮件激活链接，激活账号，注册成功。

备选流 2：进入注册页面，不勾选协议；再次尝试注册依旧不勾选协议；填写错误注册信息，提交校验失败；修改信息为合法内容，提交注册，完成邮箱激活，注册成功。

想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：

用户激活后再次点击邮件激活链接。

已注册用户再次注册。

根据场景法设计测试用例的步骤

确定基本流

确定备选流

根据备选流补充测试用例

编写测试用例

编写测试用例：

输入正确的账号密码，点击注册后系统发出确认邮件并在 24H 内确认，注册成功。

不输入账号密码，点击注册，提示重新输入

只输入账号，不输入密码，点击注册，提示重新输入

.....

（6）错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个⼈直觉，推测出软件可能存在的缺陷，从⽽针对性地设计测试⽤例的⽅法。

这个⽅法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个⼈的经验和直觉。

错误推测法和⽬前流⾏的"探索式测试⽅法"的基本思想⼀致 ，这类⽅法在敏捷开发模式下的投⼊产

出⽐很⾼，被⼴泛应⽤于测试。

当我们一提到某个非常熟悉的人的名字，脑海会立刻浮现对他的评价

"武大郎"：憨厚，老实，为人坦诚，乐于助人

"潘金莲"：美丽，"温柔"，"疼爱丈夫"，"善于交友"，"精通制衣"

张三要去卖瓜

用例 1：张三这人不实诚，小心他缺斤少两

用例 2：张三这人粗心，小心他的瓜被压坏了

用例 3：张三这人小气，小心不要把他惹哭了这个方法的缺点是难以系统化，并且过度依赖个人能力。

方法名称：错误推测法

核心思想：测试人员凭借经验、直觉，推测程序哪里容易出现缺陷，针对性设计测试用例。优点：简单灵活，快速发现一些隐藏 bug。

缺点：难以系统化，并且过度依赖个人能力。

【注册】

校验中特殊字符空格的处理。

密码校验中的大小写。

姓名中的特殊字符。

密码发送是否明文。
注意事项 ：笔试的时候编写测试⽤例需要使用传统的编写方式，须完整写出测试用例以及必要要素。面试的时候只需要按照思维导图模式说出测试用例。

接下来我们，针对测试用例编写测试文档：

如何测试接口？

1.借助工具（PostmanCanary）/ 代码(进行安装的时候如果进不去，右键点击安装包以管理身份进行安装）

Download Postman | Get Started for Free

2.Http 方法进行测试

请求类型。常用的有：GET ，POST

第 1 步：直接点 Send

它会把你的请求"原样返回"------你发什么，它就回什么。

第 2 步：加个参数，看 args 变了没

在 Query Params 表格里填：

Key	Value
`keyword`	`json`

注意 URL 会自动变成：

复制代码

postman-echo.com/get?keyword=json

第3步：针对接口的参数进行测试

请求 URL。填写本次要请求的链接（例如：https://www.baidu.com）

（1）参数通过 parameter 传递

传参数

不传参数

传入非法参数

**请求参数：**拼接 URL 上的参数。

（2）通过 json 传递

Header：请求头：填写必要的校验参数。

Body：请求体：填写必要的参数。

Send：发送请求按钮。请求参数填写完成之后，尝试发一次请求。

发现下面没有传递成功

（3）添加请求的方式

手动填写

复制请求并添加到 postman 中

打开页面开发者⼯具，选中要复制的接⼝，右键复制 URL：

打开 postman，点击 "import" 按钮（选择 "Raw text" 方式导入请求）将复制好的 URL 粘贴到文本框中（选择 "continue"）。

（4）接口管理

是否每次都要重新执行一遍填写请求的步骤呢？只需⼀步，就可以在 postman 中保存经常要使用到的接口。或者在 History 按照时间来查找。

直接跳转到这个界面：

针对当前接口进行保存

选择保存的接口名称，可以自定义

选择想要保存的文件夹

最后，当前文件会被保存到相应的文件夹中。当我们下次想要测试某个接口时，只需要在对应文件夹下找到接口即可。

冒泡排序测试思路：

1.参数测试：正常数组、单元素数组、有序数组、逆序数组；不传参数；参数为空；数组含重复值、负数。

2.异常处理：校验空数组、空指针，防止数组越界；冒泡无除法，不存在除零异常。

3.代码规范：变量命名、注释、代码缩进、消除冗余代码。

4.白盒测试

语句覆盖：所有代码行至少执行一遍

判定覆盖：每个判断的真假分支都执行

条件覆盖：判断内每个条件都取真、取假

判定条件覆盖：同时满足判定覆盖与条件覆盖

5.扩展：路径覆盖、性能测试

针对 Linux 中 zip 这个命令，如何进行测试呢？

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

zip 压缩工具测试

功能测试

打包不存在的文件

命令使用正确、文件存在，验证文件是否成功压缩

验证能否一次性打包多个文件

验证打包后的文件内容是否存在缺失

对不同文件类型测试

普通 txt 文件，可生成 zip 压缩包

图片 / 视频 /zip 文件，可生成 zip 压缩包

多个混合类型文件，可生成 zip 压缩包

空文件夹，可生成 zip 压缩包

错误命令解压测试：压缩包仍是 zip 格式、未填写压缩包名称、未填写源文件

其他参数测试

界面测试

打包后的 zip 文件高亮显示

打包生成文件后缀为.zip

压缩成功时，命令行提示信息展示效果

压缩报错时，命令行错误提示是否友好

易用性测试

输入错误命令，是否给出提示信息

zip 命令提供帮助文档，执行 zip --help 可查看使用说明

性能测试

打包 1Kb 文件，统计耗时

打包 1Gb 文件，统计耗时

一次性打包多个文件，统计耗时

文件大小超过 1G，验证能否正常压缩

文件大小超过 1G，验证压缩耗时是否在合理范围

兼容性测试

zip 工具可在 Windows、Linux、Mac 多操作系统使用

安全性测试

使用 zip 命令压缩文件，不会造成文件内容泄露

【水杯测试用例】

【微信发送朋友圈测试用例】

四.测试用例的粒度和评价

1.测试用例的粒度

好的测试用例：不熟悉业务的人，也能够依据用例快速开展测试。

粒度：指测试用例编写的详细程度。测试用例可简可繁。最简的测试用例相当于测试纲要，只标注测试对象、质量目标、测试方法，类似探索性测试思路；最详细的测试用例如同维修作业指导卡，明确输入数据、预期结果、校验方式、界面操作步骤、测试工具。

（1）测试用例过于复杂详细会带来两个问题：执行效率低、维护成本高。同时限制测试人员自主思考空间，束缚测试思维。

（2）测试用例过于简单会丧失测试用例本身的价值。仅仅记录功能模块，没有真正完成用例设计，只能充当简易测试提醒。测试用例设计本质：在设计过程理解需求、检验需求，记录软件测试思路，用来指导后续测试工作。

多数团队的测试用例粒度介于二者之间。把握合适粒度是测试用例设计的关键点，直接影响用例设计效率与测试效果。粒度选择要结合项目实际、测试资源综合判断，参考因素：

产品的质量要求

项目对测试用例的规范要求

测试时间、人力资源是否充足
注意：无论如何简化，测试用例都不能省略。

2.测试用例的评价

测试用例完成设计后，需要手段保障用例质量。测试用例评审分为正式评审、非正式评审。评审方式：同行评审、用户检查、项目组评审。

（1）同行评审各类评审方式里，临时同行评审更加敏捷。同行评审（临时）可以类似结对编程，体现敏捷思想：个体和交互高于过程和工具。依靠测试人员之间思想碰撞、讨论协作完成用例设计。原因：单人思维存在局限，容易遗漏场景，多人协作可以尽可能覆盖全部需求。

（2）用户检查尽量邀请用户参与测试用例评审，体现敏捷：客户协作高于合同谈判。客户概念范围较广：

如果测试目标是校验产品质量，客户代表就是终端用户、市场人员、领域专家；

如果测试目标是辅助开发定位问题，客户就是开发程序员。

（3）项目组评审由测试负责人组织会议，用例编写人讲解测试用例，参会人员现场提出疑问与修改意见。

【某手机软件有用 TF 卡导出数据的功能】

请写出测试此功能点的思路：

考虑方向	检查点	测试思路描述
正向	导出数据正确性	正常导出数据后，对比源数据与导出数据，校验条数、字段内容、文件完整性是否一致，无乱码、无丢失、无篡改
逆向	导出数据有效性	设备中无任何待导出数据时触发导出，验证系统是否给出友好提示（如 "暂无数据可导出"），而不是崩溃或生成空文件报错
边界容量	TF 卡空间不足	待导出数据量大于 TF 卡剩余空间，验证系统是否提前提示空间不足，或在空间耗尽时正确中断并保留已导出部分，不出现数据损坏
边界容量	TF 卡容量已满	TF 卡剩余空间为 0 时触发导出，验证系统是否明确提示 "存储已满"，导出操作不执行、不报错崩溃
容错	TF 卡写保护	开启 TF 卡写保护开关后执行导出，验证系统是否检测到写保护状态并给出提示，不会卡死或反复重试
容错	TF 卡无法识别	导出过程中或导出前插入损坏 / 未格式化的 TF 卡，验证系统是否提示 "未检测到 TF 卡" 或 "卡格式异常"，不闪退
容错	人为中断	导出过程中直接拔掉 TF 卡，验证设备不死机、不烧卡，重新插卡后能恢复或提示中断原因
容错	导出时断电、关机等	导出过程中强制断电或关机，重新开机后检查：已导出文件是否损坏、能否续传或重新导出、设备数据库是否出错
性能	连续多次导出	通过脚本或自动化方式反复、大量执行导出操作，检查数据是否始终正确，是否存在内存泄漏、速度递减、句柄未释放等问题
性能	检查导出速度	分别测试小数据量（如 1 条 / 1KB）和大数据量（如满卡 / 数 GB）的导出耗时，记录单条速度与总耗时，确认在产品规格允许范围内
兼容性	不同品牌和容量	使用 SanDisk、Samsung、Kingston、Sony 等主流品牌，覆盖 8GB/16GB/32GB/64GB/128GB 等不同容量及高速卡（Class10/UHS-I）与普通卡，验证均可正常识别和导出
兼容性	不同分区格式 FAT/FAT32/NTFS	分别用 FAT16、FAT32、exFAT、NTFS 格式的 TF 卡测试，不使用手机自带格式化功能，验证设备对各文件系统的读写兼容性