【软件测试】用例篇 – 详解

一、测试用例的概念

测试用例

（

Test Case

）是为了实施测试而向被测试的系统提供的一组集合 ，这组集合包含：

测试环境、操作步骤、测试数据、预期结果

等要素。 （注意：不需要执行结果，因为执行结果需要执行完测试用例才知道，没有测试用例自然就没有执行结果）

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

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

评价测试用例的标准：

对比好坏用例的评价标准。

• 用例表达清楚，无二义性。
• 用例可操作性强。
• 用例的输入与输出明确。一条用例只有一个预期结果。
• 用例的可维护性好。
• 用例对需求的覆盖率高。

什么是要素？

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

⽤例编号     test-01
-----------------------------------------------------------------------------------------
标题         成功注册⽹易邮箱
-----------------------------------------------------------------------------------------
测试⽅式     ⼿⼯测试
-----------------------------------------------------------------------------------------
功能模块     注册登陆
-----------------------------------------------------------------------------------------
重要性       重要
-----------------------------------------------------------------------------------------
测试前提     系统运⾏正常，邮件服务器已开启
-----------------------------------------------------------------------------------------
测试环境     win10 Chrome版本103.0.5060.66（正式版本）（64位）
-----------------------------------------------------------------------------------------
测试数据     邮箱地址：996402440@qq.com
             密码：123456
             ⼿机号：12312341234
-----------------------------------------------------------------------------------------
测试步骤     1.打开⾕歌浏览器，输⼊⽹易注册地址：https://mail.163.com/register/index.htm
            2.输⼊邮箱地址，密码，⼿机号，获取验证码并输⼊正确的验证码，勾选协议
            3.点击注册按钮
-----------------------------------------------------------------------------------------
期望结果     展现注册成功的结果⻚，并且使⽤刚注册的账号可以正常登陆并进⼊邮箱⾸⻚
-----------------------------------------------------------------------------------------

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

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

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

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

• 不知道是否较全面的测试了所有功能。
• 测试的覆盖率无法衡量。
• 对新版本的重复测试很难实施（即回归测试无法仅通过人工测试的方式进行历史功能的回归）。
• 存在大量冗余测试影响测试效率。

测试用例的出现就是解决以上这些问题。另外，测试用例的作用还可以避免测试人员被迫背锅。实际中产品出现问题，第一责任人首先想到的是测试为什么没有测到？

上面展示的是传统的编写测试用例的方式，在学习敏捷模型的时候了解到，如今大多数企业采用的都是思维导图的方式来编写测试用例，后面的内容包括用例练习都是用思维导图 / 脑图进行编写。

1、测试用例的给我们带来的好处

• 测试执行者的依据。
• 使得工作可重复，自动化测试的基础。
• 评估需求覆盖率。
• 用例的复用。
• 积累测试的方法思路以供后续借鉴。

2、测试用例的使用带来的困扰

测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多。

二、 测试用例的设计方法

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

现在有一款产品，要求我们对 “ 门锁 ” 设计测试用例，假如我们是测试人员，该如何设计呢？

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

（1） 常规思考 + 逆向思维 + 发散性思维

正确设计测试用例的思想 ：

常规思维 + 逆向思维 + 发散性思维

设计测试用例的原则二：

1. 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根无效和未预料到的输入情况。

2. 检查程序是否 “未做其应该做的” 仅是成功的⼀半，测试的另⼀半是检 查程序是否 “做了其不应该

   做的” 。（是上⼀条原则的必然结果）

3. 计划测试工作时不应默许假定不会发现错误。

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

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

（2）万能公式

设计测试用例的万能公式 ：

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

A. 功能测试

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

• 物体：这个物体是用来干什么的
• 软件：软件实现功能

功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户的角度对程序行为的精确描述。功能测试通常是一项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例，本课程中讨论的具体设计测试用例的方法尤其适用于功能测试。

然而，不仅是工作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？

• 查找其他相关⽂档，来帮助理解所要测试的产品需要完成的目标。

• 尽量多参加项⽬组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理

  解。

• 召集相关⼈员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的 case 了。

• 如果是⼀款已经上线的产品，可以多使⽤产品，有不懂的问产品经理。

• 也可以去看历史 Bug，可以了解到⼀些需要关注的东西。

B. 界面测试

• 物体：外表、材质、大小、容量…
• 软件：界面、字体大小、字体颜色、页面布局…

肉眼可以看到的部分都称为界面，界面所有的元素都需要测试。界面涉及到的内容：元素（大小、颜色、形状、性质（可以触摸到的））

对软件界面上所有的内容都需要进行测试。

要求：

• 整体界面测试界面的实现与设计图要求⼀致。

• 界面元素测试（

  控件操作验证）。

C. 性能测试

通常为一些极端的情况。

• 物体：使用寿命
• 软件：响应时间、吞吐量、并发数、CPU占用率

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

D. 兼容性测试

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

• 物体：物体除了本质的功能外，是否还有其它功能
• 软件：操作系统（电脑windows、mac、linux、手机ios、Android）、设备、浏览器版本

软件是部署在硬件系统之上，并依赖所需要的软件环境。如 QQ 可以在 PC 端打开，也可以在移动端打开；移动端⼜分为 IOS 系统和 Android 系统，且市面上手机又有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。

既然市面上有众多版本的机器，那么在执行兼容性测试时难道所有的机型都需要全面覆盖吗？

选取标准：

• 优先选择使用当前产品 top 级别的机型进行测试

实际在企业中，后台是可以获取到使用产品的机型，并以报表的形式统计在后台，供产品人员或其他人员制定策略参考。

• 选择主流的浏览器 / 机型进行测试

E. 易用性测试

具备简单易上手的属性。

• 易用性：经验（操作简单、操作流程）、人性化（符合人体工学）、见名知意

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

F. 安全测试

• 物体：物体材质是否有毒，物体是否会对人体健康造成伤害
• 软件：sql 注入、xxs 漏洞、输入有毒脚本、密码加密保存、权限控制

安全测试和性能测试⼀样都是比较大的领域。常见的安全问题如：

• 隐私数据明文显示。
• 参数未强校验导致 SQL 注入。
• 越权：普通用户也可以执行管理员权限的操作。

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

网络：

• 软件：2G~5G、弱网、Wifi

中断：

• 物体：闹钟、短信、电话
• 软件：切换到桌面

G. 弱网测试

弱网测试的目的就是为了覆盖更多的网络场景，尽可能保证用户体验，关注的关键点包括：

• 页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
• 页面呈现是否完成⼀致。
• 超时⽂案是否符合定义，异常信息是否显示正常。
• 是否有超时重连。
• 安全角度：是否会发生 DNS 劫持、登陆 IP 更换频繁、单点登陆异常等。
• 大流量事件风险：是否会在弱网下进⾏更新 Apk 包、下载文件等大流量动作。

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

1. fiddler 配置代理
2. fiddler 进行抓包（桌面 / 移动端）
3. fiddler 如何构造弱网条件

H. 安装卸载测试

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

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

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

基于需求设计测试用例是测试设计和开发测试用例的基础 ， 第一步就要分析测试需求，验证需求是否正

确、完整、无二义性，并且逻辑自洽。

在需求正确的基础上细化测试需求，从测试需求提炼出一个个测

试点或者测试项，然后根据每一个测试点进行测试用例的设计。

在分析测试需求时，一般分为

功能测试需求

和

非功能测试需求

。

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

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

下面以邮箱注册账号需求为例来设计测试用例：

【注册邮箱账号】

明确需求中的功能点：账号注册，账号登陆

结合万能公式设计测试点：

【163 邮箱注册】

（1） 功能需求测试分析

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来，功能测试需求包括以下，通常包括以下几个方面：

1. 系统各个功能界面的验证。
2. 借助业务把功能串起来进行测试。
3. 功能的一致性，交互性（多功能互操作）的测试。
4. 系统的不同输入，结果输出的业务数据测试。
5. 功能的错误操作，异常操作的测试（属于负面测试）。
6. 功能实现用到的算法验证，有时需要用运代码评审。
7. 用户操作的易用性，用户体验，往往结合功能测试同时验证。

针对具体的需求，可以根据业务分类，用户角色（餐厅的会员系统）或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。按照功能模块划分，业务模块划分是最常见的做法。

【日历系统的需求分析】

对日历根据

web

界面的功能布局分析出的功能框图如下：

也可以采用思维导图的方式，更为方便，有效，只管的呈现测试需求的分析结果，可以更好的支持测试分析思路的连贯性。

【 百度云盘手机端核心功能需求分析】

在进行需求分析的时候，我们还要考虑业务规则如，上传文件的大小有没有限制；一次性崔铎上传多少数量的文件，比如小于 100

个；文件夹最多有多少层等等；

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

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。

这里要说明的是对于每一个应用软件系统，非功能特性的质量需求都是存在的，但是不同的项目类型对各个非功能特性的要求是不一样的，这个需要根据具体的项目、具体需求和不同产品应用的特点进行分析。

A. 纯客户端软件

比如字处理软件（

Word

，

PPT)

，媒体（音频

/

视频）播放软件（电脑自带的）等。这类软件对系统的功能测试要求是最低的，但是对兼容性和稳定性，可移植性有一定的要求。

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

比如电子邮件，即时通信系统（飞

Q

，企业

QQ

）等，在系统功能测试需求上比纯客户端复杂，要求功能正确，稳定性能好。但是整体上看，对性能，安全性，兼容性要求不高。

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

比如电子商务，网上银行，视频网站（腾讯，优酷）等，除了有复杂的系统的功能测试需求外，在系统的性能，安全性，兼容性，容错性，可靠性等都有很高的要求。

此外，对于大型企业级应用系统，由于应用模式，系统架构的不同（分布式，微服务等），我们必须结合架构和应用模式来具体分析非功能性测试需求，特别是可扩展性，可靠性，安全性等。技术架构对功能的影响小，但是非功能性测试就要深入架构分析，才能更好的把我测试范围和测试方法。

举一个例子百度云盘非功能测试的例子：

用户需求:
购买3000块钱以内的华为智能手机
测试用例：
1.价格<=3000元
2.品牌为华为
3.智能手机
4.手机功能验证：
    4-1.打电话
    4-2.接电话
    4-3.发短信
    4-4.收短信
    ...

软件需求：
1.1.1.1.5.3 异常事件流
1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
**测试用例**
1-1、未收到邮件，登录时输入电子邮件及密码后，再次发送激活邮件
1-2、已收到邮件，登录时输入电子邮件及密码后，不发送激活邮件

2-1、收到邮件，未激活，24小时内进行激活
2-2、收到邮件，未激活，24小时后链接过期进行激活。
2-3、收到邮件，已激活，24小时后链接过期，再次点击激活？
页面检查：
1、收到激活邮件
2、邮件内容正确
3、激活URl正确，可激活
4、再次激活提示已激活
5、过期激活提示已过期

3、 具体的设计方法

（1）等价类

注册邮箱账号设计的测试用例存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样⼀个具体的需求该如何来设计测试⽤例呢？

测试的时候通过穷举法来测试 6 位、7 位、8 位 ……14 位，15 位是否测试通过，这样的方法能够满足测试的要求吗？若此时把范围从 “615位” 改成 “6150位呢”？这样⼀个简单的测试点需要测试多久呢，显示是不符合企业测试要求的。而 等价类法的出现就解决了穷举法不能解决的问题 。

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出⼀个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

⽣活中等价类的案例： 因材施教的例⼦：原

则上讲，老师应该依据每个学生自身的情况，指定符合的学习方案。

但是实际上学生太多，老师管不过来，

只能分成几类：

• 优等生强调知识面的扩展和综合能力的提升；

• 中等生强调夯实基础，

  查缺补漏；

• 差等生强调优先掌握重点，

  暂时跳过难点

• … …

思路：输入的集合是无穷的，

不能全都覆盖到。

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

• 有效等价类

  ：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验

  证程序是否实现了规格说明中所规定的功能和性能。 满足用户需求输入集合。

• 无效等价类

  ：根据需求说明书， 不满足用户需求输入的集合。

根据等价类设计测试用例的方式：

1. 确定有效等价类和无效等价类
2. 编写测试用例，设计具体测试数据

根据边界值将邮箱注册账号的用例进行完善：

缺点：等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

【超市买水果】
有效等价类：苹果、梨子、西瓜...
无效等价类：青菜、大米、饮料...

|用户名 | 必填，录入用户名 | 6至15

有效等价类：6~15位
无效等价类：小于6位 && 大于15位

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

1. 充分理解需求
2. 划分有效等价类和无效等价类
3. 针对有效等价类和无效等价类中设计测试用例。

（2） 边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

日常语言中的 “边界”

漏洞：考完试发成绩了,

老师布置寒假作业：

超过

60

分的，

所有题目抄写

1

遍，

低于

60

分的，

所有题目抄写

3

遍。

于是小明就没有写作业，

因为他刚好

60

分。

边界值包含 ：

边界值 + 次边界值 ​​​​​​​​​

1. 输入框长度为

   1~11

   ，取边界值为：

   1

   、

   11

   、

   12

   、

   0。

2. 运动员的参赛项目为

   1~3

   项，取边界值为：

   0

   项、

   1

   项、

   3

   项、

   4

   项。

3. 查询面页面有

   999

   行，每

   50

   行为一页，取边界值为：输出

   0

   行、

   1

   行、

   50

   行、

   51

   行、

   999

   行。

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

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

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

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

A. 边界点

上点：边界上的点。

内点：边界内的点（不管范围是闭区间开始开区间）。

离点：边界值附近的一个点（ 闭区间 ： 区间外 距离上点最近的点， 开区间 ： 区间内 距离上点最近的点）。

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

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

通过具体的方法能够将测试用例设计的更加完整和规范。

需求中会存在各种各样的场景，现在我们把需求改成如下的要求：

用户输入

的账号中包含 admin 字符，或者通过内部链接进入注册页面，提交注册按钮成为管理员身份；反之无管理员身份。​​​​​​​

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

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

a. 恒等

条件为真，结果一定为真。

b. 与

所有的条件都得满足，如果有一个条件不满足，

那么结果就为假。

c. 或

满足其中一个条件结果就为真，如果条件全部为假，那么结果就为假。

d. 非

条件为假，结果才为真。

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

1. 分析需求中所有可能的输入条件和输出条件。

2. 找出输入条件与输出条件之间的对应关系。

3. 设计判定表。

4. 根据判定表编写测试用例，

   把判定表对应到每一个测试用例。

C. 判定表

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

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

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

• 确认需求中输⼊条件和输出条件

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

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

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

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

• 画判定表

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

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

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

【 淘宝 618 活动 】

假设业务单据的处理规则为：

“

淘宝

618

活动，订单已提交，订单合计金额大于

300

元或有红包，则优惠”

。

a. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：

• 输入：订单已提交、金额大于

  300

  、有红包。

• 输出：优惠、不优惠。

b. 第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。

1. 订单已提交，订单金额大于

   300

   元，有红包，则优惠。

2. 订单已提交，订单金额大于

   300

   元，没有红包，则优惠。

3. 订单已提交，订单金额小于等于

   300

   元，有红包，则优惠。

4. 订单已提交，订单金额小于等于

   300

   元，没红包，则不优惠。

5. 订单不提交，订单金额大于

   300元，有红包，则不优惠。

6. 订单不提交，订单金额大于

   300元，没有红包，则不优惠。

7. 订单不提交，订单金额小于等于

   300元，有红包，则不优惠。

8. 订单不提交，订单金额小于等于

   300元，没红包，则不优惠。

c. 设计判定表：

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

可以在后面补充符合要求的测试要素。

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

通过等价类和边界值方法我们完成了部分用例的补充。

当前还剩下⼀个场景的用例未补充完成，“只填写部分选项”，这⾥到底要设计多少测试用例呢？

通常来说，为了保证系统的测试覆盖率，我们⾸先能够想到的就是排列组合。

假如当前有两个选项 A 和 B，可以设计出都填写、都不填写、填写 A、填写 B 四个测试用例（2²）。

假如当前有三个选项 A、B、C，通过设计可以得到 8 个测试⽤例（2³）。

… …

当前可选的选项是5个，分别是，姓名、电⼦邮箱、密码、确认密码、验证码。按照排列组合设计出来的⽤例是32个…..

因果法设计用例太多怎么办？

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

正交试验设计（

Orthogonal experimentaldesign）

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

正交表：

如图最简单的正交表是 L(4)(2(3))，含意如下：“L” 代表正交表；L 下角的数字 “4” 表示有 4 横行，简称行，即要做四次试验；括号内的指数

“3” 表示有 3 纵列，简称列，即最多允许安排的因素是 3 个；括号内的数 “2” 表示表的主要部分只有 2 种数字，即因素有两种水平 1 与 2。

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

• **因素

  （

  Factor**

  ）：

  对指标的影响条件，通常是正交表中的⼀列。

  在一项试验中，凡欲考察的变量称为因素（ 变量 ）。

• 水平

  （位级） **（

  Level**

  ）：

  因素对应的可选项。

  在试验范围内，因素被考察的值称为水平（ 变量的取值 ）。

• 正交表的构成

• 行数（

  Runs）

  ：

  正交表中的行的个数，即试验的次数，

  用

  N

  代表。

• 因素数（

  Factors）

  ：

  正交表中列的个数，用

  C

  代表。

• 水平数（

  Levels）

  ：

  任何单个因素能够取得的值的最大个数。正交表中的包含的值为从

  0

  到数

  “

  水平数

  -1”

  或从 1

  到

  “

  水平数

  ”

  ，用

  T

  代表。

A. 正交表的表示形式

L=

行数

(

水平数^

因素数

) L=N(TC)

B. 正交表的两条性质

1. 每一列 中， 不同的数字出现的次数 都

   一样多

   。

2. 任何两列中的各有序数对出现的次数都

   一样多

   （

   数字的排列方式齐全而且均衡

   ）。

根据正交表的性质，⼀般人很难通过手动设计出正交表。

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

• 找到因素和⽔平
• ⽤ allparis ⼯具⽣成正交表

1. 将因素和水平写入 Excel 表格中

2. allparis 目录下创建新的文本文件 new.txt，复制 Excel 中的因素和水平，直接粘贴到文本中保存

   并退出。

3. 使用 allparis 命令生成正交表：allparis.exe new.txt>zhengjiao.txt

• 根据正交表编写测试用例
• 补充遗漏的重要测试用例

充分理解需求（有哪些元素(变量)）

-> 确定因素水平（ 每个因素有哪几个水平(变量的取值) ）

-> 画正交表（ 选择一个合适的正交表，把变量的值映射到表中 ）

-> 补充正交表

-> 将正交表转换成测试用例（ 把每一行的各因素水平的组合作为一个测试用例，加上你认为可疑且没有在表中出现的用例组合 ）

【 注册的需求 】

以注册为例，采用正交法补全剩下的测试用例。

姓名、邮箱、密码、确认密码、验证码必须全部输入，才能进行注册。

A. 因素和水平

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

水平： 填写、不填写

B. 利用 allpairs 画正交表

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

b. 将 Excel 表格内容复制到 .txt 文件中

allparis 目录下创建新的文本文件 20240506.txt，复制 Excel 中的因素和水平，直接粘贴到文本中保存并退出。

c. Ctrl+S 保存到 allpairs 的下载路径

d. 进入 cmd（windows+R）将路径切换到 allpairs 安装路径下

进入到 allpairs 的目录下，执行命令： allpairs.exe 文件名 > 结果文件名

（将⽣成的正交表数据放入20240506_result.txt 文件中）

没有任何的提示表示生成成功。

至此，就可以看到生成了 20240506_result.txt：

根据生成的正交表来编写测试用例，继续将重要的用例补全（例如：全部填写 / 全部不填写）

注意 ：~ 意味着此时这个取值可以是任意的选项：可以填写，也可以不填写。

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

（5）场景设计法

场景设计法是针对整个流程进行设计的。

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的⼀种方法。用例

场景来测试需求是指 模拟特定场景边界发生的事情 ，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。

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

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

该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

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

【注册】

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

1. 用户激活后再次点击邮件激活链接。
2. 已注册用户再次注册。

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

1. 确定基本流
2. 确定备选流
3. 根据备选流补充测试用例
4. 编写测试用例

编写测试用例：

1. 输入正确的账号密码，点击注册后系统发出确认邮件并在 24H 内确认，注册成功。
2. 不输入账号密码，点击注册，提示重新输入
3. 只输入账号，不输入密码，点击注册，提示重新输入
4. …..

【ATM 取款】

通常情况下，需要将用户经常使用的功能模块串在一起进行测试。

（6）错误猜测法

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

错误猜测法更多依靠的是经验。 这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的 “

探索式测试方法

”

的基本思想一致，这类方法在 敏捷开发模式 下的投入产出比很高，被广泛应运于测试。

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

“武大郎”：憨厚，⽼实，为⼈坦诚，乐于助人。

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

张三要去卖瓜：

1. 张三这人不实诚，小新他缺斤少两
2. 张三这人粗心，小心他的瓜被压坏了
3. 张三这人小气，小心不要把他惹哭了

这个方法的缺点是难以系统化，并且过度依赖个人能力。

【注册】

1. 校验中特殊字符空格的处理。
2. 密码校验中的大小写。
3. 姓名中的特殊字符。
4. 密码发送是否明文。

注意

：笔试的时候编写测试⽤例需要使用传统的编写方式，须完整写出测试用例以及必要要素。面试的时候只需要按照思维导图模式说出测试用例。

针对测试用例编写测试文档：

如何模拟弱网？

1、借助工具（ Fiddler / Charles）

2、打开限速模式

打开弱网设置选项：

打开设置弱网的脚本：

打开弱网设置：

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

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

如何测试接口？（需要回顾）

1、借助工具（PostmanCanary）/ 代码

2、Http 方法进行测试

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

3、针对接口的参数进行测试

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

）

（1）参数通过 parameter 传递

• 传参数
• 不传参数
• 传入非法参数

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

（2）通过 json 传递

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

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

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

（3） 添加请求的方式

1. 手动填写
2. 复制请求并添加到 postman 中

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

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

（4）接口 管理

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

​​​​​​​

1. 针对当前接口进行保存
2. 选择保存的接口名称，可以自定义
3. 选择想要保存的文件夹

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

写一个冒泡参数，针对这个代码如何测试呢？

• 方法参数（参数类型、不给参数、参数传递为空等）
• 异常处理（除零错误）
• 代码规范
• 语句覆盖（涉及白盒测试）、条件覆盖、语句条件覆盖、判定覆盖…
• … …

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

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

功能测试：

• 打包的是一个不存在的文件
• 命令使用正确，文件存在，文件是否被压缩
• 能否一次性打包多个文件
• 打包后的文件内容是否有缺失

对不同的文件类型进行测试：

1. 普通的 txt 文件能够⽣成 zip 文件
2. 图片 / 视频 / zip 文件能够生成 zip 文件
3. 多个文件能够⽣成 zip 文件（混合文件）
4. 空文件夹可以生成 zip 文件
5. 错误的命令是否可以解压（zip zip / 没有写压缩包文件名称 / 没有源文件）
6. 其他参数的测试

界面测试：

• 打包后的 zip 高亮
• 打包后的文件后缀名为 .zip

1. 文件压缩成功命令行提示是否美观
2. 文件压缩报错命令行提示是否友好

易用性测试：

• 输入错误是否会有提示

1. zip 命令有使用帮助教程，如 zip –help 命令下会展示如何使用

性能测试：

• 打包 1Kb 的文件需要多长时间
• 打包 1Gb 的文件需要多长时间
• 一次打包多个文件需要多长时间

1. 文件大小超过 1G 时文件是否可以压缩
2. 文件大小超过 1G 时文件压缩消耗的时间是否在合理的时间范围内

兼容性测试：

1. zip 工具可以在多系统上使用，如 Windows、Linux、Mac

安全性测试：

1. 使用 zip 命令不会泄漏文件内容

【水杯测试用例】

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

三、测试用例的有效性

1、什么是测试用例的有效性

测试用例对应的功能已删除，不可操作了。比如：微信刚出来时与

QQ 可以

互发消息，下一个版本后就不可以发消息。

执行一条测试用例未发现

BUG

，实际该处有 BUG。iPhone

7

手机微信添加了

mobile

单车小程序，扫码不能开锁，只能使用

mobile APP 开锁，测试用例未涉及到 iPhone

7 微信小程序扫码开锁。

执行一条测试用例发现了 BUG。iPhone

7

手机微信添加了

mobile

单车小程序，用例已写到了 iPhone7

微信添加

mobile

小程序扫码开锁，问题被发现。

执行一条测试用例未发现

BUG

，实际该处

BUG 已修改。iPhone

7

手机微信添加了

mobile

单车小程序扫码开锁，可以正常开锁。

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

1、 测试用例的粒度

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试。

• 粒度 ：指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的操作步骤，指定测试的方法和工具等。

• （1）

  测试用例写得过于复杂或详细，会带来两个问题：一个是 效率 问题，另一个是 维护成本 问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

• （2）测试用例写得过于简单，则可能失去了测试周例的意义。过于简单的测试用例设计其实并没有进行 “

  设计

  ”

  ，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数测试团队编写的测试用例的粒度介于两者之间。而如何把握好粒度是测试用例设计的关键，也将影响测试用例设计的效率和效果。应该根据项目的实际情况、测试资源情况来决定设计出怎样粒度的测试用例。

主要考虑可以参考如下内容：

• 产品的质量要求。
• 项目对用例的要求。
• 测试时间和资源是否充分。

注意

：不管用例怎么简化，都不应该省略。

2、 测试用例的评价

测试用例设计出来了，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。评审分为正式和非正式评审。

• 同行评审
• 用户检查
• 项目组评审

（ 1 ）测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。

同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的 “

个体和交互比过程和工具更有价值”

，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。

（ 2 ）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的 “ 顾客的协作比合同谈判更有价值 ” 这一原则。

这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。

（3） 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。

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

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