黑盒测试进阶之用例精简
作者:搜狗测试 发布时间:[ 2016/10/26 11:02:35 ] 推荐标签:测试用例 黑盒测试
之前的分享中我们介绍了用例编写的相关方法,这种方法写出来的用例覆盖率是很高的,但是也有不少人反馈,说这种方法写出来的用例太多,存在重复用例,我们之前讲方法的时候有说过,这种方法比较适合初学者,提高用例覆盖度的,用例会出现一定程度的冗余,我们来分析一下如何将用例进行精简~
小编分析了一下用例冗余的方面,有如下两个:
用例重复
无效用例
用例重复→用例合并:
所谓用例重复,不是说很多用例完全一样,而是说部分用例的检查点或影响因素相同,操作步骤相同,使用例看起来像是重复的用例一样,对于这种情况,可以进行合并
如:对象相似
对象A和对象B的部分功能类似,检查点和影响因素相同,操作步骤相同,则可以将相同的部分进行合并,合并完后变为
对象A+对象B
检查点1
影响因素1
对象A
检查点2
影响因素2
对象B
检查点3
影响因素3
同理,如果是检查点和影响因素相同,合并的方式也是一样的
这种用例精简方式适用于一个操作步骤,可以检查多个检查点的情况,如果只是检查点相同,但是步骤不同,仍然不建议进行合并
无效用例→删除用例
在分析功能时,我们会针对测试对象,找出相关的检查点,再由检查点出发,发散影响因素,这种用例方式是纯黑盒的用例设计方法,但是在很多时候,我们并不是只进行纯黑盒,而是灰盒,因为我们会去了解开发的实现,功能内部逻辑对我们来讲不是黑的了,在了解完开发实现后,会发现纯黑盒情况下发散出来的一些影响因素其实没有没有必要,直接去掉可以
如窗口测试
检查点:窗口的UI显示
影响因素1:不同分辨率
影响因素2:不同位色
影响因素3:不同字体
影响因素4:不同系统主题
我们去跟开发了解一下这个窗口的实现方式
如果开发表示,他使用的系统自带的窗口函数绘制的,那么这些影响因素需要保留;
如果开发表示,他是自己写的窗口函数绘制的,不会适配系统的当前情况,那么这些影响因素会有多余的,系统相关的修改不会影响到自绘窗口的显示,如主题,字体,分辨率等
如果开发表示,他是自己写的窗口函数,但是会根据系统的情况进行适配,那么需要进一步了解会适配哪些情况
说了以上这些,大家应该都明白了,这种用例精简的方式是根据开发实现,对用例进行增删改,这个的粒度看对开发实现了解的粒度了
还有一种精简方式是简化用例结构
如用例可以不写详细步骤,将简单步骤放在用例目的中,从而达到节约用例编写时间的目的
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11