测试用例的设计思路及方法
目录
前言
一、测试用例
二、设计思路
1. 设计原则
2. 通用思路
三、设计方法
1. 等价类与边界值
2. 正交法
3. 判定表法
4. 场景法
5. 错误猜测法
四、用例设计示例
1. 登录功能用例设计
2. 命令行程序用例设计
前言
本文系统介绍了软件测试用例的设计方法与应用。首先阐述了测试用例的组成要素，以邮箱注册为例展示完整的测试用例模板。接着提出测试用例设计的通用思路，包括功能、性能、界面等多个维度的测试覆盖。重点讲解了五种设计方法：1）等价类与边界值分析法；2）正交法减少测试组合数量；3）判定表法处理复杂逻辑关系；4）场景法区分基本与备用事件流；5）错误猜测法基于经验补充用例。最后通过登录功能和命令行程序示例，展示了测试用例的实际应用。这些方法为软件测试提供了系统化的设计思路。
一、测试用例
测试用例是为了实施测试向被测试系统提供的一组集合，这组集合包括：测试环境，操作步骤，测试数据，预期结果等要素；
以注册邮箱为例：
| 用例编号 | test-01 |
| 标题 | 成功注册邮箱 |
| 测试方式 | 手工测试 |
| 功能模块 | 注册登录 |
| 重要性 | 重要 |
| 测试前提 | 系统正常运行，邮件服务器已开启 |
| 测试环境 | win10 Microsoft Edge 141.0.3537.92 (正式版本) (64 位) |
| 测试数据 | 邮箱地址：admin123@123.com 密码：123456 手机号：12312312399 |
| 测试步骤 | 1. 打开Microsoft Edge浏览器，输入邮箱注册地址； 2. 输入邮箱地址，密码和手机号，获取验证码并输入； 3. 点击注册按钮； |
| 期望结果 | 展现注册成功结果页，并且使用刚注册的账号可以正常登录并进入邮箱首页； |
这是传统的测试用例的编写方式，敏捷模型中，也经常使用思维导图的方式来编写测试用例。
二、设计思路
1. 设计原则
如果根据产品的某一功能去设计测试用例，仅保证功能是正确的，这种思路是非常局限的，设计出来的测试用例也会比较少；
设计测试用例不仅需要给定有效的输入预料到的输入，也要给定无效的和未预料到的输入；
设计测试用例不仅需要检查产品是否未做其应该做的，还要检查其是否做了其不应该做的；
2. 通用思路
测试者可以考虑从功能测试，性能测试，界面测试，兼容性测试，易用性测试，安全测试这几个方面入手去设计测试用例，尽可能覆盖产品的各个方面；
需要使用网络的产品，也需要考虑进行弱网测试；
需要安装和卸载的产品，也需要考虑安装和卸载测试；
以上面注册邮箱为例，设计测试用例：
三、设计方法
1. 等价类与边界值
等价类分为有效等价类和无效等价类；
边界值分为边界值和次边界值；
以用户密码为例，要求用户密码长度为6~ 16位：
- 设计密码长度为10位，即有效等价类，设计密码长度为18位，即无效等价类；
- 6和16即边界值，5和17即次边界值；
- 6和16即边界值；
- 5和17即次边界值；
对于6~16位的密码，实际测试不可能穷举，因为通过设计等价类和边界值的方式，可以设计如下的测试用例：
- 设计密码长度为6位的测试用例；
- 设计密码长度为16位的测试用例；
- 设计密码为5位的测试用例；
- 设计密码为17为的测试用例；
2. 正交法
以邮箱注册为例，需要填写用户名，电子邮箱，密码，确认密码以及验证码，每个条目分别有填写和不填写两种情况，我们按照排列组合的设计方式，需要测试32种情况；
正交法是为了减少测试用例的数目，用尽量少的组合覆盖输入的两两组合；
以L4(2(3))为例，L表示正交表，4表示一共有4行，3表示一共有3个因素，2表示每个因素有两个取值，也称作两个水平；
正交表通常是通过工具进行生成，而不是手写。下面借助allpairs生成正交表：
1. 将因素和水平填入到excel中，保持格式为默认格式不变；
2. 创建要转换的文件test01.txt，将表中的数据复制到txt中；
3. 使用命令行，转换test01.txt为正交表，将转换的正交表保存到res-test01.txt；
4. 检查转换后的正交表；
~表示可以是填写，也可以是不填写；
通过正交表，我们设计6个测试用例即可，不需要设计32个；
但是我们也需要测试全部都不填写的情况，因为增加一个测试用例；
3. 判定表法
需求中通常也会有多种场景，以下场景为例：
用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮，成为管理员身份，反之无管理员身份；
1. 确认需求中的输入条件和输出条件；
- 输入条件：
- a. 用户输入的账号中包含admi字符；
- b. 通过内部链接进入注册页面；
- 点击注册按钮；
- 输出条件：
- 管理员身份；
- 无管理员身份；
2. 找到输入和输出之间的关系；
- a, b, c, ab, 非abc -> 无管理员身份；
- ac, bc, abc -> 管理员身份；
3. 画判定表；
4. 根据判定表编写测试用例；
- a. 账号包含admin，非内部注册链接，不点击提交按钮，无管理员身份；
- b. 账号不包含admin，内部注册链接，不点击提交按钮，无管理员身份；
- c. 账号不包含admin，非内部注册链接，点击提交按钮，无管理员身份；
- d. 账号包含admin，内部注册链接，不点击提交按钮，无管理员身份；
- e. 账号包含admin，非内部注册链接，点击提交按钮，管理员身份；
- f. 账号不包含admin，内部注册链接，点击提交按钮，管理员身份；
- g. 账号包含admin，内部注册链接，点击提交按钮，管理员身份；
- h. 账号不包含admin，非内部注册链接，不点击提交按钮，无管理员身份；
4. 场景法
场景分为基本事件流和备用事件流；
还是以注册邮箱为例：
基本事件流：
- 输入账号密码->点击注册->发送确认邮件->确认邮件->注册成功；
备选事件流：
- 输入错误的账号密码->点击注册->重新输入账号密码->点击注册->发送确认邮件->确认邮件->注册成功；
- 输入账号密码->点击注册->发送确认邮件->网络异常接收邮件失败->重新发送邮件->确认邮件->注册成功；
- 输入账号密码->点击注册->发送确认邮件->未确认邮件，邮件超时->重新发送邮件->确认邮件->注册成功；
- ......
5. 错误猜测法
根据对被测试软件的理解，及过往经验，推测软件存在的缺陷，从而针对性的设计测试用例；
比如：
- 密码校验中的大小写；
- 姓名中的特殊字符；
- 密码发送是否明文；
四、用例设计示例
1. 登录功能用例设计
2. 命令行程序用例设计
命令行程序zip和unzip能够实现对文件的压缩和解压缩，针对这个功能设计测试用例；
