软件测试之测试用例设计(一)
文章目录
前言
随着IT行业的不断发展,软件测试这门技术也越来越重要,很多外行小白都开启了学习软件测试,本文就软件测试的入门内容展开介绍,尽可能的去帮助一些没有基础的同学。
以下是本篇文章正文内容,如有表达不全的问题还请指出,本文中插入的图片由网上下载,如涉及版权问题联系我删除。
一、理解软件测试
1.核心目标
尽快尽早尽多发现软件缺陷,促进软件质量与客户满意度的提升。
2.出发点
业务需求,即测试一组客户提出来的业务需求,以用户的角度出发,将各种有可能执行的情况尽可能都测试一遍,均能得到正确期望的结果,这些有可能出现的情况称之为测试用例,如果不能正确运行,可认定为是软件缺陷。
举个例子:
二、设计测试用例三部曲
- 要测试什么(要理解业务需求)
- 怎样测试(测试环境搭建)
- 判断测试正确与否
三、开展软件测试的设计方法
1.等价类划分
- 把输入域划分成若干等分,从每个部分中选取部分代表性数据作为测试用例;
- 每一类的代表数据都等价于这一类中的其他值;
- 用有效等价数据、无效等价数据两种测试用例来测试。
例如:输入“确认密码”,有效等价类就是和密码相同的值,无效等价类就是和密码不相同的值。
再例如:
分析:输入框中可以输入的年月有n种情况,但实际测试不会每一种都会测一遍,而是选取有代表性的用例测试,等价划分可选用例:有效数据(199001、202004等等,一个数据通过代表所有类似数据都通过);无效数据(205001、-1、####、!!%、2020-1-2等等,这类数据均不会通过。
2.边界值划分
从上面划分的有效等价类里测试边界数据。
例:上面例子中选取边界值,即199001和204912,还可以中间随机选择一个,比如202007。
3.因果图
以多种条件组合搭配关系来写测试用例。不过只适合局部功能,如果一个项目要测的点特别多,每个功能点都用这个方法去画原因—结果的因果图的话比较费时间精力。
解析:
- 有a这个原因就绝对会有b这个结果;
- 有a就无b,反之亦然;
- a/b/c有一个出现就一定会出现结果d;
- a/b/c三个都出现就会出现结果d
- 互斥:要么0个为1,要么1个为1;
- 包含:最少一个为1,也可以两个、三个;
- 唯一:有,且只有1个;
- 要求:例如要想获得验证码,那么必须填写手机号,必须填写手机号格式正确;要点登录,必须点同意协议的按钮;
- 屏蔽:有a就不能有b,例如抛硬币。
举个例子:
分析:编写测试用例:15元+雪碧、20元+红茶、20元+雪碧等。
类似该功能因果图画法以及判定表(1表示执行,0表示不执行):
解析判定表第一列:
投入1元硬币,按下橙汁,显示已投币已按钮,退还5角硬币,送出橙汁饮料,以此类推。
4.判定表驱动法
- 往往和因果图一起分析
- 有多个输入,和多个输出
- 输入与输入之间有相互的组合关系
- 输入和输出之间有相互的制约和依赖关系
判定表由四个部分组成:
例如:
5.用户故事
模拟用户行为。
例:
分析:不同场景下名词和动词不一样
6.错误推测
以反其道而行之的错误方式测试。
例:
四、工作中怎么写测试用例
编写完整的测试用例要有测试标题、输入条件、操作步骤、预期输出、实际输出、环境要求、用例之间的依赖性、测试人、测试时间等相关要素。按照下列模板格式写出来即可。
例:
五、一线企业工程师写测试用例的工具
1.excel表格
2.思维导图工具
一组需求涉及的测试用例太多,我们一般会采取画思维导图的方式去归纳用例节点,方便后期维护。
例:
如上图,将每个需求模块的测试用例按照分支节点的方式简洁明了的提取出来,后期任意一个分支/节点需要修改或新增都可直接操作。这种形式的展现适用于公司需求用例评审,方便解决客户、开发等人员在评审过程中发现测试用例覆盖不全的问题。
市面上有很多思维导图工具,例如FreeMind(推荐,下载地址:https://www.onlinedown.net/soft/101098.htm)、XMind等,还有其他好用的思维导图工具请在评论中发表。
总结
以上就是今天要讲的内容,本文仅仅简单介绍了软件测试入门的一些基础内容,有描述错误的地方请指出,感谢观看。