转：测试用例的粒度是粗点好还是细点好？

不论是刚接触测试的同学还是做测试已经有一段时间的同学，都会在一个问题上有类似的困惑：我们测试用例的粒度是粗点好，还是细点好。尤其是在时间紧张，人力有限，需要别人执行，后续需要维护的情况下，抉择更加艰难。本届黑灯舞会就这个问题展开了激烈的辩论。并获得了具有一定指导意义的结果。

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

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

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

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

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

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

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

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

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

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

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

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

　　评委进行了精彩的点评：

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

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

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

本文转自：http://www.51testing.com/html/28/n-218628.html