起航学习网

之前的分享中我们介绍了用例编写的相关方法，这种方法写出来的用例覆盖率是很高的，但是也有不少人反馈，说这种方法写出来的用例太多，存在重复用例，我们之前讲方法的时候就有说过，这种方法比较适合初学者，提高用例覆盖度的，用例会出现一定程度的冗余，今天我们就来分析一下如何将用例进行精简~

小编分析了一下用例冗余的方面，有如下两个：

用例重复

无效用例

用例重复→用例合并：

所谓用例重复，不是说很多用例完全一样，而是说部分用例的检查点或影响因素相同，操作步骤相同，使用例看起来像是重复的用例一样，对于这种情况，可以进行合并

如：对象相似

对象A和对象B的部分功能类似，检查点和影响因素相同，操作步骤相同，则可以将相同的部分进行合并，合并完后就变为

对象A+对象B

检查点1

影响因素1

对象A

检查点2

影响因素2

对象B

检查点3

影响因素3

同理，如果是检查点和影响因素相同，合并的方式也是一样的

这种用例精简方式适用于一个操作步骤，可以检查多个检查点的情况，如果只是检查点相同，但是步骤不同，仍然不建议进行合并

无效用例→删除用例

在分析功能时，我们会针对测试对象，找出相关的检查点，再由检查点出发，发散影响因素，这种用例方式是纯黑盒的用例设计方法，但是在很多时候，我们并不是只进行纯黑盒，而是灰盒，因为我们会去了解开发的实现，功能内部逻辑对我们来讲就不是黑的了，在了解完开发实现后，会发现纯黑盒情况下发散出来的一些影响因素其实没有没有必要，直接去掉就可以

如窗口测试

检查点：窗口的UI显示

影响因素1：不同分辨率

影响因素2：不同位色

影响因素3：不同字体

影响因素4：不同系统主题

我们去跟开发了解一下这个窗口的实现方式

如果开发表示，他使用的系统自带的窗口函数绘制的，那么这些影响因素就需要保留;

如果开发表示，他是自己写的窗口函数绘制的，不会适配系统的当前情况，那么这些影响因素就会有多余的，系统相关的修改不会影响到自绘窗口的显示，如主题，字体，分辨率等

如果开发表示，他是自己写的窗口函数，但是会根据系统的情况进行适配，那么需要进一步了解会适配哪些情况

说了以上这些，大家应该都明白了，这种用例精简的方式是根据开发实现，对用例进行增删改，这个的粒度就看对开发实现了解的粒度了

还有一种精简方式是简化用例结构

如用例可以不写详细步骤，将简单步骤放在用例目的中，从而达到节约用例编写时间的目的

以上就是小编在工作过程中总结出来的用例精简的方向，大家有什么好的用例精简方法也可以跟小编说一下，共同进步~

软件开发测试人才四大魅力元素

——就业竞争小

——高薪没商量

——就业质量高

——无性别歧视

套用狄更斯那句话说：对于急需软件开发测试人员的企业来说，这是一个最坏的时代，但对软件开发测试人才来说，这是一个最好的时代。“随着软件市场的成熟，人们对软件作用的期望值也越来越高，软件的质量和功能可靠性也正逐渐成为人们关注的焦点。”

文章出自：http://qh.itpxw.cn/jyzn/202179531.html

文章标题：黑盒测试进阶之用例精简，你值得拥有！

免责声明：本站文章均由入驻起航学习网的会员所发或者网络转载，所述观点仅代表作者本人，不代表起航学习网立场。如有侵权或者其他问题，请联系举报，必删。侵权投诉