51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4471|回复: 7
打印 上一主题 下一主题

[转贴] 测试用例的粒度是粗点好还是细点好?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-8-9 22:16:00 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
不论是刚接触测试的同学还是做测试已经有一段时间的同学,都会在一个问题上有类似的困惑:我们测试用例的粒度是粗点好,还是细点好。尤其是在时间紧张,人力有限,需要别人执行,后续需要维护的情况下,抉择更加艰难。本届黑灯舞会就这个问题展开了激烈的辩论。并获得了具有一定指导意义的结果。

      正方观点认为:测试用例的粒度应该细点,主要体现测试细节

      反方观点认为:测试用例的料度应该粗点,主要体现测试思想

      论辩先由正方一辩马雯佳同学发言:“我方认为, 测试用例的粒度应该细点,主要体现测试细节。原因有(1)测试用例的编写就像是织网,而BUG就像是鱼,网织得越密,捕捉到的BUG就越多(2)测试思想的学习并不是一蹴而就的。对一个新人来说,这种学习是一个渐近的过程,具体到每个项目,更需要用更精细的用例来保证测试的覆盖率(3)设计详细的用例便于执行,便于新人理解,便于知识传承。”虽然做为一个新人,雯佳略显青涩,但言辞却很犀利。

      然后是反方一辩达海发言:“我方认为, 测试用例的粒度应该粗点,主要体现测试思想。(1)粗并不等于简单。测试用例的粒度粗点,是建立在我们对需求完全理解,对设计完全掌握的基础上的粗粒度。这样我们可以避免繁琐的流程,提高测试执行的效率,把握重点需求。测试粗粒度可以避免陷入机械性的测试。(2)粗粒度的测试设计可以使我们把重点关注于设计,可以让测试往前走,在时间,资源有限的情况下,更高效地进行测试,保证产品质量。

      随后进入激烈的自由辩论环节。双方你来我往,引起大家的阵阵喝彩。

      正方:“测试用例过粗,当拿着过粗的用例都执行不下去时,如何让新人在执行中得到提升?”

      反方:“如果都按照师父的提供的测试用例去测试,是否可以达到技能提升。”

      反方:“思想就像大脑,测试用例是骨骼。在时间有限,资源有限时,必须要有所取舍,抓住主干测试,所以我们会追求白盒覆盖率而不是路径覆盖率。测试技能的提高是测试思想的不断丰富,测试手段的不断完善,而不是用例越写越细”

      正方:“在测试领域有8:2原则,80%的bug源于经常修改的20%代码,tc的数量提升有利于减少这种bug遗漏。并且,越精细的用例越便于定位BUG”

      反方:“就是因为我们的用例过细,导致在时间,资源紧张的情况下,导致覆盖律低,没有发现尽可能多的BUG,相反,如果我们在测试设计的时候,放得粗,可以把主要精力放在测试思想上,这样就可以提高测试覆盖率,发现更多的BUG。测试用例的设计要先搭一个整体的框架,然后再逐步完善”

      正方:“逐步完善的过程是不是用例越来越细?”

      在激烈的辩论中,时间到了。大家意犹未尽。

      评委进行了精彩的点评:

      辩论会是一种很好的形式,可以活跃大家思维。正方一辩马雯佳思路清晰,在立论阶段提出了很多很好的论据。可惜在后面的论辩过程中并没有展开。从管理者角度来看,还是希望测试用例的粒度细点好。

      测试用例的粒度取决于项目质量的要求,时间的要求,用户的要求。如果时间充足,就可以把用例写细一些,时间紧张,就写粗些。有个词叫测试艺术家。就是要我们掌握质量与效率之间的平衡。

      我们的用例不管是细还是粗,它都是为了达到最终目的“保证产品质量”。测试用例写粗点还是细点,可以用一个例子来说明。当我们刚学车的时候,什么时候打方向盘,什么时候踩离合,什么时候踩油门。都需要教练一步步教,要一步步来,这些都很明确的。当开车有一段时间后,什么情况下要做什么动作都会很自然,一气呵成。当我们的新人在进行测试的时候,需要很明确地知道怎么做,这时候用例就得细些。当成为一个很熟练的测试工程师的时候,设计用例时就不必纠结于这些细节了。每个阶段不同,做事方式就不同,只要满足结果就好。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    2#
    发表于 2010-8-10 22:15:02 | 只看该作者
    这个平衡点,需要丰富的经验才能掌握好
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    擦汗
    2015-9-7 11:00
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    3#
    发表于 2010-8-12 18:33:39 | 只看该作者
    要看产品需求
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2010-8-12 22:50:03 | 只看该作者
    对于大多数项目,你都不需要精细的流程和文案。从轻量级的流程开始,哪怕它比需要的流程还要“轻量”。在做的过程中,不停地调整,在一些部分补上遗漏,在一些部分减少负担。

    在大多数时候,不需要“细”的测试用例。需要的是缜密的思考,而思考的根源来自真实的测试。要从粗的用例开始,不断细化测试策略和方法,查漏补缺。至于新人,不犯错误,怎么成长?要考虑更好的培训方法,例如:结对测试。结对看似浪费人力,实际对两个人都有很好的促进作用。结对2天,远胜过1周的新员工培训。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-8-18 17:36:57 | 只看该作者
    说说自己的感受,就是在测试用例粒度很细时,测试思路就会局限,常常忘了对立面的测试。测试用例粒度粗时,可能一些较深的点测试不到。。。。。纠结中
    正在学习,谢谢LZ
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2010-8-18 18:20:08 | 只看该作者
    一切看离里程碑时间还长不
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-8-19 21:52:59 | 只看该作者
    看时间呗,但是要记住没有cases能把所有scenario都包含进去,这就是为什么再牛的公司出的软件都有bug的原因,所以我们要做的有cases覆盖全部功能的测试,但是组合操作的测试是要给测试人员多余的时间去sanity测试的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2010-8-20 22:54:57 | 只看该作者
    我这里说的测试粒度,主要是指test cases的分类和组织以及划分等,不管是TEST CASES设计的粗的还是细的,前提条件是要能覆盖到所有的Product Requirements...具体粗细由个人爱好和兴趣,并根据项目情况自行决定,下面从Automation  test来说明该问题:

    Test cases设计的比较粗的话,总体上来说test cases的数量相对会比较少,方便测试代码维护和修改,以后如果test steps或者UI变化的话,需要改的地方就,一般来说相对比较少~~`比较费事的地方就是在test case failed的时候,你需要就逐一排查哪个验证点出问题了等.......比较细的test cases design则反之

    另外要说的是,象我们在外企上班的,一般我们的BOSS都会对automation rate有所要求的...假如写的比较粗,TEST CASE是2个(1个能够automation,,另外一个CASE不能automated或者需要很大effort才能automated..那么automation rate=1/(1+1)=50%...如果设计的比较细一点,比如把那个可以automated的case拆为3个,那么automated rate=3/(3+1)=75%...数据上来看明显要比前者漂亮很多~
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-8 21:04 , Processed in 0.072112 second(s), 32 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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