【软件测试】编写测试用例篇
前面部分主要是编写测试用例的方法和方向，后面一部分是编写出具体的测试用例
目录
什么是测试用例
背景：我们在写程序或者刷题的时候，要想验证自己写的程序是否正确，都会代入几个特殊值去测试该程序，通过程序的结果就能判断出来。而对于我们的项目也是一样，但是测试用例会非常的多喝复杂，所以也就需要我们去学习，做到全方面的想出测试用例。
因此，对于设计测试用例有一个原则：
测试用例中一个必需部分 是 对预期输出或者结果进行定义
什么意思呢？使用当前的测试用例，就一定会有一个预期的结果，是通过或者失败。然后通过测试，就能显而易见的对比结果了。
（1）对新自行车进行测试
对于一个新项目，我们需要测试。那我们现在对一辆新买的自行车也需要测试，就需要设计测试用例，才能知道从哪些方面入手。
- 是否可以正常骑行
- 刹车是否灵敏/正常
- 坐垫是否舒服
- 外观是否有掉漆
- 等等等
这些都是我们从脑子里面想出来的一些测试用例，如果不进行记录，很快就会忘记，而且会想的不全面，因此，我们就有一些记录测试用例的手段。
（2）记录测试用例的手段
第一种：通过excel表格
第二种：通过思维导图/脑图
我们在日常学习和面试中，都是推荐使用第二种。
下面，我们通过第二种举例说明。
（3）使用脑图设计测试用例
下面是对一个键盘进行设计的测试用例
虽然通过脑图记录了很多的测试用例，但是不够具体，远远不可以作为工作中具体的测试依据。而且对于不同的对象，每次去设计测试用例都是要重新出发。
因此，我们就需要去学习设计测试用例的万能公式和方法，后续在设计测试用例的时候，就可以固定的从大多数方向入手，设计的也快，也更加全面和具体。
1.设计测试用例的万能公式
这里介绍的万能公式有两个方面，一方面是思维上的万能公式，另一个方面是具体的万能公式（方向）
1.1.从思维出发
对于设计测试用例，都需要哪些思维呢？也就是需要往那些方向去思考。
常规思考 + 逆向思维 + 发散性思维
因此，得出设计测试用例也存在几条原则
（1）测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未料到的输入情况
比如我们测试登陆页面，不仅要测试输入正确密码时的情况，也要测试错误密码时的情况或者其他的格式
（2）检查程序是否“未做其应该做的”仅是成功的一半，还应该测试另一半是否“做了其不应该做的”
和上一条一样，输入错误的就是不应该做的，也要进行测试
（3）计划测试工作时不应该默许假定不会发生错误
和上面的一样，不应该默认输入的密码都是正确的
上述只是设计测试用例的一些思维，仅供一些方向，但是还不够，还需要一些具体的方法。
1.2.万能公式
（1）万能公式
功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全性测试
这就是设计测试用例的万能公式，可以帮助我们从哪些方向出发，进行设计测试用例。
（2）每个方向应该测试的
- 功能测试
从产品的功能出发，验证功能是否正常（功能就是此类产品通常都具有的）
- 界面测试
我们肉眼可以看到的成为界面。可以从颜色、大小、外观入手进行测试
- 性能测试
也就是测试一些极端的情况
- 兼容性测试
例如，测试不同系统的版本、不同的浏览器等等
- 易用性测试
是否具备一些新手引导教学或者看起来易操作
- 安全性测试
是否可以保证用户的隐私安全，信息是否容易被窃取等情况
（3）登陆页面-测试用例
这些是自己通过万能公式设计的一些设计用例，看起来都非常的少。
我们看一下比较官方的设计：
上述的万能公式也只是针对大部分场景，还有一些特殊情况可能还未测试到
1.3.弱网测试
（1）弱网测试的目的
目的是尽可能保证用户的使用体验。具体的点包括下面：
- 页面响应时间是否可以接受（不同网络下，页面刷新成功的时间是否可以接受）
- 页面呈现是否完成一致（比如只加载了部分内容）
- 超时文案是否符合定义，异常信息是否显示正常（是否会提升加载超时等）
- 是否有超时重连
- 安全角度
- 大流量事件风险
（2）如何进行弱网测试
我们需要借助抓包工具，我们就以fiddler为举例
步骤：
第一步：打开fiddler
第二步：开启弱网
第三步：打开脚本编辑器设计网速
出现该页面
查询
输入关键词：m_simulateModem
找到可以设计网速的代码位置
通过前面勾选的弱网开关，就会执行里面的代码，也就是会按照里面设置的网速执行。
如何设计网速？
里面的两个数字，设置的越大，网速就越慢，反之越快。
1.4.安装与卸载测试
对于一些需要安装的软件，我们也需要进行安装和卸载的测试
主要包括两个方面
（1）安装
- 安装包是否可以正常安装
- 卸载之后，再次选择安装是否可以安装
（2）卸载
- 安装后是否可以卸载
- 安装一天后再进行卸载
- 反复多次安装和卸载
- 卸载到一半退出，卸载是否成功或者卸载一半
2.设计测试用例的方法
2.1.基于需求的设计方法
比如，要测试一个登陆的界面，首先根据万能公式写出大概得方向，然后针对每个方向，都会有很多的需求，根据需求来设计测试用例。
比如：登陆账号密码，可以分出测试登陆成功和登陆失败的两种测试用例；然后需要很限制密码的长度，针对密码的长度，也进行设计测试用例，这就是基于需求的设计测试用例方法
2.2.等价类
我们为什么要设计等价类呢？举个例子，比如上述的密码长度规定在6-15位，那如何更快的测试呢？总不能一个个长度的密码都要测试吧？显然这是不科学的做法，因此就需要有等价类。
（1）等价类概念
依据需求将输⼊（特殊情况下会考虑输出）划分为若⼲个等价类，从等价类中选出⼀个测试⽤例，如果?这个测试⽤例测试通过，则认为所代表的等价类测试通过，这样就可以⽤较少的测试⽤例达到尽量多的?功能覆盖，解决了不能穷举测试的问题。
解决的问题：可能需要穷举的测试
（2）等价类分类
等价类分为：有效等价类和无效等价类
1.有效等价类：满足需求的集合、有效的输入。比如密码长度要求6-15位，那么在这个范围内的等价类就成为有效等价类
2.无效等价类：根据需求说明书，不满足需求的集合。比如上面的，测试密码长度不在合理范围内的等价类就称为无效等价类
（3）有效、无效等价类举例
根据密码长度6-15位举例：
有效等价类：6位密码长度、15位密码长度，10位密码长度
无效等价类：5位密码长度、16位密码长度
（4）边界值
简介：边界值是基于等价类的一种补充，也就是测试边界值的一个黑盒方法，这里的边界也就是来自等价类的边界。
1）边界值分为：边界值+次边界值
1.有边界值是有效等价类中的数据，那么次边界值是无效等价类中的边界
2.若边界值是无效等价类中的数据，那么次边界值为有效等价类中的边界
2）举例：
需求范围1：密码有效长度为：[6,15]
有效等价类的范围：[6,15]，无效等价类：<6或者>15
边界值：6,15-----边界值属于有效等价类中的数据，所以次边界值为5,16，也就是无效等价类的边界
需求范围1：密码有效长度为：(6,15)
有效等价类的范围：[7,14]，无效等价类：<=6或者>=15
边界值：6,15-----边界值属于无效等价类中的数据，所以次边界值为：7,14；也就是有效等价类的边界值
2.3.正交法
这种方法比较困难，实际中一般很少直接使用，就算进行使用，也是借助工具生成的。
对于一些场景，比如部分填写信息，那得设计多少的测试用例？是庞大的一个数字，所以我们就需要通过正交法来辅助编写测试用例。
比如有如下的信息，姓名、电子邮箱、密码、确认密码、验证码，这五个信息，每个选项都有填写/不填写，组合起来就是32可能，实际肯定不会采取这种方案，因此就需要通过正交法产生一个正交表，正交表中就可以帮助我们编写测试用例了。
（1）概念
正交表的两个性质：
- 每一列中，不同的数字出现的次数相等
- 任意两列中数字的排列方式齐全而且均衡
对于性质1，比如第一列因素中：数字1、数字2、数字3都出现了3次，次数相同。
性质2：这就是对比两列得出的结果了，比如数字1在每一行中都出现过，数字2、3同理。
（2）设计正交表的步骤
1）根据需求找出因素和水平
2）将因素和水平写入到表格中（表格不需保存）
3）在allparis.exe同级文件夹下创造一个txt文件，将excel表格中的内容复制进去（可以保证格式没有问题，否则后续操作会出问题）
4）使用allparis.exe工具对txt文件生产正交表文件（通过cmd控制台，使用allparis.exe test01.txt > res-test01.txt，两个txt是文件名字，可随意）
5）根据生成的正交表编写测试用例
（3）使用正交法编写测试用例
1）根据需求找出因素和水平
2）将因素和水平写入到表格中（表格不需保存）
3）在allparis.exe同级文件夹下创造一个txt文件，将excel表格中的内容复制进去（可以保证格式没有问题，否则后续操作会出问题）
创造txt文件
复制内容
4）使用allparis.exe工具对txt文件生产正交表文件（通过cmd控制台，使用allparis.exe test01.txt > res-test01.txt，两个txt是文件名字，可随意）
第一步：
第二步：
第三步：查看新文件
5）根据正交表，编写测试用例
其中，~的意思是可以填写，也可以不填写
- 姓名填写，电子邮箱填写，密码填写，确认密码填写，验证码填写
- 姓名填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写
- 姓名不填写，电子邮箱填写，密码不填写，确认密码填写，验证码不填写
- 姓名不填写，电子邮箱不填写，密码填写，确认密码不填写，验证码填写
- 姓名~填写，电子邮箱填写，密码填写，确认密码不填写，验证码不填写
- 姓名~填写，电子邮箱不填写，密码不填写，确认密码填写，验证码填写
- 姓名不填写，电子邮箱不填写，密码不填写，确认密码不填写，验证码不填写
2.4.场景法
目前很多的软件的每个功能都可以形容成一个个事件，也就是一个个流程，所以我们就可以根据场景来设计测试用例
（1）概念
我们通常以正常的⽤例场景分析开始，然后再着⼿其他的场景分析。场景法⼀般包含基本流和备⽤流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备⽤流来完成整个场景。
场景主要包括4种主要的类型：正常的⽤例场景，备选的⽤例场景，异常的⽤例场景，假定推测的场景。
（2）举个例子
我们以去逛街买衣服为例
正常的流程就是：逛街-->到达服装店-->选上衣服-->拿下衣服。但是呢，在实际生活中，难免会出现一些意外或者突发情况，就会导致无法按照正常的流程完成，即使这样，最终也是完成了买衣服的任务。
所以，我们就可以根据不同的流程去测试软件的功能。
（3）场景法软件测试举例
我们以登陆邮箱为例
正常流程：输入正确邮箱账号，输入正确密码，在输入验证码，点击登陆即可完成。但是我们也要测试一些其他的流程，也就是备用流
测试1：输入正确邮箱账号，输入正确密码，输入验证码，点击登陆，登陆成功。
测试2：输入正确的邮箱账号，输入正确的密码，输入错误验证码，登陆失败，输入正确验证码，登陆成功。
测试3：输入正确邮箱账号，输入错误密码，输入正确验证码，登陆失败，重新输入正确密码和验证码，登陆成功。
……
像这样的场景测试用例有很多很多，大家可以去试试看。
2.5.判定表法
对于上面的一些方法，显然还不能应付所有的场景，比如说，有几个选项，不同的组合会造成结果不一样，如果使用正交法就无法解决了。
判定表法是一种逻辑判断工具，几种条件组合在一起会得出一个结果
（1）步骤
1）确认需求中输入条件和输出条件
2）找出输入条件和输出条件之间的关系
3）画判定表
4）根据判定表编写测试用例
下面我们以上面的步骤来进行举例
（2）举例
有一个需求是这样的，对于邮箱注册，如果账号中包含admin字符，或者通过内部链接进入注册页面，最后提交注册按钮，就可以成为管理员身份，反之都不行。
所以成为管理员身份有两个条件
1）确认需求中输入条件和输出条件
输入条件：账号包含admin字符，或者内部链接，最后提交注册按钮
输出条件：管理员身份/非管理员身份
2）找出输入条件和输出条件之间的关系
账号包含admin字符，提交注册按钮，成为管理员身份；
通过内部链接进入注册页面，提交注册按钮，成为管理员身份
其他的条件，都不能成为管理员身份
3）画判定表
我们以上面的表格为例使用excil画出表格
4）根据判定表书写测试用例
比如上述有8列，就可以编写出8个测试用例
- 账号包含admin，提交注册按钮，成为管理员身份；
- 内容链接进入注册页面，提交注册按钮，成为管理员身份
- 账号包含admin，不提交注册按钮，不能成为管理员身份
- 账号包含admin，通过内部链接进入，提交注册按钮，成为管理员身份
- ……
以上就是关于测试用例篇的全部内容了，感谢各位观看
原文地址：https://blog.csdn.net/2301_77053417/article/details/140078343
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！