51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 2027|回复: 0
打印 上一主题 下一主题

[讨论] 你必须知道到的黑盒测试用例的精简之道

[复制链接]
  • TA的每日心情
    奋斗
    2021-8-16 14:04
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2018-4-20 13:41:42 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    之前的文章介绍了黑盒测试的几种用例设计,包括等价类划分法、边界值分析法、错误推测法、因果图法、
    判定表驱动法、正交试验设计法、功能图法等。

    通过这些方法设计的用例覆盖率是很高的,当然用例太多,也意味着更多的工作量,那没问题来了,在确
    保用例的一定覆盖率的情况下,尽量减少我们的工作,达到最高的效率,例如大量的重复用例和无效用例
    需要怎么去判断,今天就用例进行精简方面说说我的想法

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

    当对象部分功能类似,检查点和影响因素相同,操作步骤相同,则可以将相同的部分进行合并。如果是检
    查点和影响因素相同,合并的方式也是一样的,这种用例精简方式适用于一个操作步骤,可以检查多个检
    查点的情况,如果只是检查点相同,但是步骤不同,仍然不建议进行合并

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

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

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

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

    这种用例精简的方式是根据开发实现,对用例进行增删改,这个度就看对开发实现进度了。

    所以想要高效的完成app功能测试或者其他软件功能测试,不仅需要一款合适的功能测试工具辅助,更重要
    的是用例的设计方式,和对用例精简已,帮助我们更高效的测试。


    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-4-25 14:35 , Processed in 0.065920 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表