测试开发基础——测试用例的设计

三、测试用例的设计

1. 什么是测试用例

测试用例(Test Case)是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。

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

笔试的时候编写测试用例题，需要按照Excel表格的方式来答题

面试的时候回答测试用例，按照思维导图一一道出即可

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

为什么需要测试用例呢，不写测试用例可以进行测试吗？测试中可能会遇到很多问题，诸如：

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

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

2.1. 常规思考+逆向思维+发散性思维

正确设计测试用例的思想：常规思维+逆向思维+发散性思维

设计测试用例的原则二：

1. 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。
2. 检查程序是否“未做其应该做的”仅是成功的一半，测试的另一半是检查程序是否“做了其不应该做的”。(是上一条原则的必然结果)

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

2.2. ✨万能公式

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

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

①功能测试

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

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

• 查找其他相关文档，来帮助理解所要测试的产品需要完成的目标；
• 尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解；
• 召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了；
• 如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理
• 也可以去看历史bug,可以了解到一些需要关注的东西。

②界面测试

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

要求：

• 整体界面测试界面的实现与设计图要求一致。
• 界面元素测试：控件操作验证

③性能测试

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

④兼容性测试

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

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

选取标准：

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

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

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

⑤易用性测试

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

⑥安全测试

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

隐私数据明文显示。

参数未强校验导致SQL注入。

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

---

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

<1>弱网测试

弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：

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

ProcessOn Mindmap（网络测试要点）ProcessOn是一个在线协作绘图平台，为用户提供强大、易用的作图工具！支持在线创作流程图、思维导图、组织结构图、网络拓扑图、BPMN、UML图、UI界面原型设计、iOS界面原型设计等。同时依托于互联网实现了人与人之间的实时协作和共享。https://www.processon.com/embed/66a57e03760bf67a84e2b2eb?cid=66a57e03760bf67a84e2b2ee

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

1) fiddler配置代理

2) fiddleri进行抓包（桌面/移动端）

3) fiddler如何构造弱网条件

<2>安装卸载测试

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

3. 设计测试用例的方法

3.1. 基于需求的设计方法

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

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

以该注册邮箱账号需求为例来设计测试用例。

①明确需求中的功能点

账号注册，账号登录

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

ProcessOn Mindmap（结合万能公式设计测试点案例）ProcessOn是一个在线协作绘图平台，为用户提供强大、易用的作图工具！支持在线创作流程图、思维导图、组织结构图、网络拓扑图、BPMN、UML图、UI界面原型设计、iOS界面原型设计等。同时依托于互联网实现了人与人之间的实时协作和共享。https://www.processon.com/embed/66a582a95b45a425464e85bc?cid=66a582a95b45a425464e85bf

3.2. 具体的设计方法

①等价类

上述设计的测试用例，存在用例还未完全设计完成，“姓名必填，6~15位的字符类型”，这样一个具体的需求该如何来设计测试用例呢？

测试的时候通过穷举法来测试6位、7位、8位.14位，15位是否测试通过，这样的方法能够满足测试的要求吗？若此时把范围从“6~15位”改成“6~150位呢”？试想一下这样一个简单的测试点需要测试多久呢，显示是不符合企业测试要求的。

而等价类法的出现就解决了穷举法不能解决的问题

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

等价类分类：

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合。

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

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

完善上述未完成的用例

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

②边界值

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

边界值包含：边界值+次边界值

1. 输入框长度为1-11，取边界值为：1、11、12、0
2. 运动员的参赛项目为1-3项，取边界值为：0项、1项、3项、4项
3. 查询面页面有999行，每50行为一页，取边界值为：输出0行、1行、50行、51行、999行

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

③正交法

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

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

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

• 假如当前有两个选项A和B,可以设计出都填写、都不填写、填写A、填写B四个测试用例(2^2)。
• 假如当前有三个选项A、B、C,通过设计可以得到8个测试用例(2^3)
• 当前可选的选项是5个，分别是，姓名、电子邮箱、密码、确认密码、验证码。按照排列组合设计出来的用例是32个(2^5)

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

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

正交表：

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

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

因素：对指标的影响条件，通常是正交表中的一项

水平：因素对应的可选项

正交表的性质：

• 每一列中，不同的数字出现的次数相等
• 任意两列中数字的排列方式齐全而且均衡

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

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

1. 找到因素和水平
2. 用allparis工具生成正交表

a. 将因素和水平写入Ecel表格中

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

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

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

将上述用例通过正交法继续补充

1. 找到因素和水平

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

水平：填写、不填写

1. 用allparis工具生成正交表

a. 将因素和水平写入Ecel表格中

b. allparis目录下创建新的文本文件test0729.txt,复制Excel中的因素和水平，不进行任何修改直接粘贴到文本中保存并退出

上述图片是直接在txt里编辑然后去执行生成操作得到的结果，会出现报错，因为allpairs对格式要求很严格，所以在Excel中编辑以后直接复制过来即可

c. 使用allparis命令生成正交表：allparis.exe test0729.txt > 0729cs.txt（将生成的正交表数据放入0729cs.txt文件中）

~表示可以是任意选项：填写/不填写

1. 根据正交表编写测试用例

• 1) 姓名填写，电子邮箱填写，密码填写，确认密码填写，验证码填写
• 2) 姓名填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写
• 3) 姓名不填写，电子邮箱填写，密码不填写，确认密码填写，验证码不填写
• 4) 姓名不填写，电子邮箱不填写，密码填写，确认密码不填写，验证码填写
• 5) 姓名不/填写，电子邮箱填写，密码填写，确认密码不填写，验证码不填写
• 6) 姓名不/填写，电子邮箱不填写，密码不填写，确认密码填写，验证码填写

1. 补充遗漏的重要测试用例

• 7) 不填写姓名，电子邮箱，密码，确认密码，验证码

1. 将结果写入Excel表格

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

④判定表法

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

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

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

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

判定表

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

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

根据判定表法设计测试用例的步骤：

1. 确认需求中输入条件和输出条件
2. 找出输入条件和输出条件之间的关系
3. 画判定表
4. 根据判定表编写测试用例

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

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

输入条件：账号包含admin字符 (a)

内部注册链接 (b)

点击注册按钮 (c)

输出条件：管理员 (1)

无管理员 (2)

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

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

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

3. 画判定表

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

• a. 账号包含admin,非内部注册链接，点击注册按钮，为管理员身份
• b. 账号包含admin,内部注册链接，不点击注册按钮，非管理员身份
• c. 账号不包含admin,内部注册链接，点击注册按钮，为管理员身份
• d. 账号包含admin,内部注册链接，点击注册按钮，为管理员身份
• e. 账号包含admin,非内部注册链接，不点击注册按钮，非管理员身份
• f. 账号不包含admin,非内部注册链接，点击注册按钮，非管理员身份
• g. 账号不包含admin,非内部注册链接，不点击注册按钮，非管理员身份

⑤场景法

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

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

场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

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

针对场景法给出生活中的案例。以逛街买衣服为例，讲讲场景法的使用方法。

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

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

案例：

还是根据邮箱账号注册的案例，根据场景法来设计测试用例TODO

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

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

ProcessOn Flow（场景法）ProcessOn是一个在线协作绘图平台，为用户提供强大、易用的作图工具！支持在线创作流程图、思维导图、组织结构图、网络拓扑图、BPMN、UML图、UI界面原型设计、iOS界面原型设计等。同时依托于互联网实现了人与人之间的实时协作和共享。https://www.processon.com/embed/66a7c101760bf67a84e56d5f?cid=66a7c101760bf67a84e56d62

编写测试用例：

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

⑥错误猜测法

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

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

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应用于测试。

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

还是根据邮箱账号注册的案例，根据场景法来设计测试用例

以注册为例

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

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

⑦尝试进行“登录功能”设计测试用例

1. 明确需求
2. 使用万能公式+测试用例方法设计测试用例
3. 按照测试用例对系统进行测试
4. 记录测试，编写一篇测试博客

1. 项目背景
2. 项目功能
3. 对项目进行测试编

        ①写测试用例 

        用例截图

        ②执行测试

        选取几个用例的步骤截图放到这里仅做展示

      4. 测试总结

覆盖率多少个页面、用例是否全部执行通过，发现了多少bug，bug出现的原因/涉及到的页面在哪里

ProcessOn Mindmap（登录页面测试用例练习）ProcessOn是一个在线协作绘图平台，为用户提供强大、易用的作图工具！支持在线创作流程图、思维导图、组织结构图、网络拓扑图、BPMN、UML图、UI界面原型设计、iOS界面原型设计等。同时依托于互联网实现了人与人之间的实时协作和共享。https://www.processon.com/embed/66a8d0c6e51cb32576474e36?cid=66a8d0c6e51cb32576474e39

3.3. 更多场景用例练习

①命令行程序

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

zip命令

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

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

界面测试：

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

性能测试：

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

兼容性测试：

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

易用性测试：

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

安全性：

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

②web程序

对博客系统的博客详情页接口进行测试用例的设计

接口：http://192.168.47.135:8080/blog_system/blog?blogId=10

接口请求示例：

通过curl命令我们可以在命令行上请求接口，对接口进行测试

如何对当前接口设计测试用例呢？

不同的请求方式：

1. 以GET方式请求接口是否可以返回预期的响应数据
2. 以POST方式请求接口是否可以返回数据

参数组合（如果接口需要拼参数的情况下）：

1. 空参数
2. 多参数
3. 少参数
4. 参数对应的值为空/过长/特殊字符……

不同的参数格式：

1. url拼参
2. form-data格式
3. raw格式

接口性能：

1. 一千万个请求同时发起，是否能够返回响应
2. 并发情况下响应时间是否在大众接受范围内

对接口进行测试时，使用curl命令进行接口测试在操作上并不理想，实际在工作中我们常常使用接口测试工具来提供测试的质量和效率，常用的接口测试工具有postman