在前面的文章当中,也提到了什么是测试用例。
测试用例就是测试人员向被测试系统提供的一组测试数据。
包括:
测试环境、测试步骤、测试数据、预期结果。
那么,下面将来聊一聊,具体怎样设计测试用例。
简称:两能、两性、安全、界面
目录
一、设计测试用例的万能思路(6个方面)
下面,通过一个例子:测试水杯来简单聊一下功能测试是什么样的
功能测试
①装水、喝水;
②水杯如果有安全刻度,那么到了安全刻度有没有溢出的风险。
③水杯是否是保温杯?如果是保温杯,保温功能怎样。
④水杯是否隔热?
⑤如果可以折叠,怎样折叠,支持反复折叠吗?
对于软件:
用户的基本功能需求是否可以实现。
性能测试
①如果是保温杯,那么保温的性能怎样?最久可以保温多久?
②如果有隔热功能,那么装的热水温度达到了多少摄氏度,用户会感觉到烫手?加入了沸水会烫手吗?
③抗摔性:在合理范围的高度内,测试水杯坠落的时候是否出现变形?破损?或者其他材质上面的损耗。
④水杯的使用寿命(最好以月为单位)
⑤合理的范围内测试耐热性、耐冻性、耐腐蚀性。
⑥水杯是否抗压?抗压性能怎样。
软件的性能
响应时间(1秒以内/或者2秒以内)。
多个人同时访问,服务器是否来得及响应。
兼容性测试
既然是水杯,那么可不可以装下其他的液体,例如油、盐、汽水等等;
软件的兼容性
1、各个版本的操作系统是否兼容?
2、能否在各个浏览器上面兼容?
3、运行的环境:PC端,微信端,移动端等等。
4、能否在各个版本的浏览器、操作系统上面运行。
易用性测试
这个水杯是否便携;
这个水杯是否老少皆宜;
这个水杯开盖、装水、喝水的过程容不容易。
对于软件
用户的使用体验怎样?对于关键性的功能,是否可以令用户比较明显地看到?
对于不那么明显的功能,是否有明显的提示,有无用户的引导?
安全测试
这个水杯如果装了高温的水,那么会不会在水中检测出有毒的物质?
如果装了其他的常见液体,会不会发生恶性的化学反应。
这个水杯会不会在装了热水之后热胀冷缩发生爆炸。
对于软件
是否存在SQL注入的问题?
是否存在XSS漏洞?
是否做好权限管理?包括垂直越权,水平越权。用户不登陆可不可以访问到需要访问的页面
界面测试
字面意思:水杯的外观怎样,例如:
形状是否合理、大小是否合理、颜色是否符合用户需求、是否有图案、图案是否符合用户需求等。
软件的界面:
文字/输入框/图片/下拉框.....颜色、形状、大小、形状、大小、布局。
是否存在错别字、病句、折行、折叠、重叠等都需要进行测试。
二、设计测试用例的方法
①基于需求进行测试用例设计
用户提出的需求是什么,那么软件开发就根据这一个需求来进行设计。
例如:邮箱注册,可以这样进行:设计测试用例:(脑图)
②等价类
分区分块:使用较少的测试用例达到符合的系统测试覆盖。
概念:
针对需求的输入范围划分为若干个等价类,从其中一个等价类当中取一个测试用例来进行测试。如果该测试用例通过,则认为该测试用例所在的等价类是通过的。
根据等价类划分测试用例的步骤
1、确定有效等价类和无效等价类;
有效等价类:针对需求来说,有效并且有意义的数据构成的集合。
无效等价类:针对需求来说,无效并且没有意义的数据构成的集合。
2、编写测试用例
针对每一个模块的有效等价类、无效等价类分别设计测试用例。
下面,举一个例子:
用户需求为:姓名的长度为6-200个字符的长度。
那么,就可以这样设计等价类:
③边界值(对于等价类的补充)
边界值法通常是对于等价类的一种补充方法。一般都是在等价类设计的测试用例的基础上面,考虑一些比较临界的情况表而设计的测试用例。
例如在上面的地方:需求为:密码长度为6-200字符。那么我设计的测试用例可以是在6(边界值),200(边界值),5(次边界值),7(次边界值),199(次边界值),201(次边界值)位的字符里面设计,测试这样的设计是否可以通过。
④判定表法
判定表法设计测试用例的步骤:
同样,现在有一个需求有待测试:
当用户名的长度>600字符的时候,那么提示用户名称过长。
当用户名称的长度<6字符的时候,那么提示用户名过短。
其余情况合格
1、确认输入条件和输出条件
输入条件:
条件Ⅰ:用户名的长度>600;
条件Ⅱ:用户名的长度<6;
条件Ⅲ:用户名的长度在【6,600】之间。
输出条件:
输出1:用户名合格;
输出2:用户名不合格;
2、找出输入条件和输出条件之间的关系
其实就是首先对于输入条件和输出条件进行组合,然后判定哪些组合是合法的,哪一些是不合法的。
条件Ⅰ:输出2;
条件Ⅱ:输出2;
条件Ⅲ:输出1。
3、画判定表
依据输入条件、输出条件以及输入条件和输出条件和对应的情况组成的二维表。建立如图所示的关系。
情况1 | 情况2 | 情况3 | ||
输入条件: | 条件Ⅰ:用户名的长度>600 | Y | ||
条件Ⅱ:用户名的长度<6 | Y | |||
条件Ⅲ:用户名的长度在【6,600】之间 | Y | |||
输出条件: | 用户名合格 | Y | ||
用户名不合格 | Y | Y |
4、根据判定表编写测试用例
测试用例1:用户名长度>600,用户名不合格。
测试用例2:用户名长度<6,用户名不合格。
测试用例3:用户名长度在【6,600】之间,用户名合格。
判定表法的优势
适用优势:需要考虑输入输出之间的组合关系,不同的组合对应的输出结果不一致。
因果图&判定表
因果图画判定表法比较多余,而且因果图实际在设计测试用例的时候并没有多大的意义。
判定表当中根据输入、输出结果已经得出了测试用例了。
⑤正交法
下面有一个需求是:
用户注册信息填写:姓名、电子邮箱、密码、确认密码、验证码。
那么,可以认为:
因素数(输入条件):
姓名、电子邮箱、密码、确认密码、验证码。
水平数(输入条件的可选项):
对于因素数当中的内容,选择填写/不填写。
下面,需要借助一个工具:allpairs来生成正交表。
下载allpairs的步骤:
下载官网:Allpairs - Satisfice, Inc.
然后点击下载:
下载到本地磁盘当中的时候,需要进行解压缩,变成一个普通的文件夹。
然后,在pairs文件夹当中,写一个excel表格。接下来,可以在excel表格当中填写因素数&水平数
填写完成之后,在pairs目录下面,新建一个文件夹,命名为:革凡成圣.txt
然后,打开cmd,切换到pairs所在的目录:
接着,继续在cmd当中输入以下内容:
allparis.exe 革凡成圣.txt>hello.txt
那么,这样的话,就可以生成正交表了。
4、补充其他测试用例
使用allpairs生成的内容,不一定完整。于是,还需要新增一些其他的测试用例。
然后,根据这些测试用例进行测试。
⑥场景设计法(了解)
主要分为基本事件流和多个备用事件流。
基本事件流:
对于一个场景的最基本的事件流。
备用事件流:
对于一个业务可能发生异常情况的场景进行测试。