领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
讨论：测试用例的粒度——粗细之争
作者 崔康 发布于 2010年8月5日
测试用例的粒度一直是软件测试领域的热点问题，无论是粗粒度还是细粒度，都各有利弊。最近，淘宝测试团队针对该问题举行了内部辩论会，相关内容值得借鉴和思考。
正方观点：测试用例的粒度应该细点，主要体现测试细节。主要论据：
- 测试用例的编写就像是织网，而BUG就像是鱼，网织得越密，捕捉到的BUG就越多。
- 测试思想的学习并不是一蹴而就的。对一个新人来说，这种学习是一个渐进的过程，具体到每个项目，更需要用更精细的用例来保证测试的覆盖率。
- 设计详细的用例便于执行，便于新人理解，便于知识传承。
反方观点：测试用例的料度应该粗点，主要体现测试思想。主要论据：
- 粗并不等于简单。测试用例的粒度粗点，是建立在我们对需求完全理解，对设计完全掌握的基础上的粗粒度。这样我们可以避免繁琐的流程，提高测试执行的效率，把握重点需求。测试粗粒度可以避免陷入机械性的测试。
- 粗粒度的测试设计可以使我们把重点关注于设计，可以让测试往前走，在时间，资源有限的情况下，更高效地进行测试，保证产品质量。
随后，双方展开了自由辩论，其中不乏精彩的言论：
反方：思想就像大脑，测试用例是骨骼。在时间有限，资源有限时，必须要有所取舍，抓住主干测试，所以我们会追求白盒覆盖率而不是路径覆盖率。测试技能的提高是测试思想的不断丰富，测试手段的不断完善，而不是用例越写越细。
正方：在测试领域有8:2原则，80%的bug源于经常修改的20%代码，测试用例的数量提升有利于减少这种bug遗漏。并且，越精细的用例越便于定位BUG。
反方：就是因为我们的用例过细，导致在时间，资源紧张的情况下，导致覆盖率低，没有发现尽可能多的BUG，相反，如果我们在测试设计的时候，放得粗，可以把主要精力放在测试思想上，这样就可以提高测试覆盖率，发现更多的BUG。测试用例的设计要先搭一个整体的框架，然后再逐步完善。
最后，评委做了总结发言：
......从管理者角度来看，还是希望测试用例的粒度细点好。
测试用例的粒度取决于项目质量的要求、时间的要求、用户的要求。如果时间充足，就可以把用例写细一些，时间紧张，就写粗些。有个词叫测试艺术家。就是要我们掌握质量与效率之间的平衡。
我们的用例不管是细还是粗，它都是为了达到最终目的——保证产品质量。测试用例写粗点还是细点，可以用一个例子来说明。当我们刚学车的时候，什么时候打方向盘，什么时候踩离合，什么时候踩油门。都需要教练一步步教，要一步步来，这些都很明确的。当开车有一段时间后，什么情况下要做什么动作都会很自然，一气呵成。当我们的新人在进行测试的时候，需要很明确地知道怎么做，这时候用例就得细些。当成为一个很熟练的测试工程师的时候，设计用例时就不必纠结于这些细节了。每个阶段不同，做事方式就不同，只要满足结果就好。
淘宝内部辩论会结束了，但是对于测试用例的粒度的研究还在持续，读者对于这个问题怎么看？欢迎加入到讨论中！
崔康 热情的技术探索者，资深软件工程师，InfoQ编辑，从事企业级Web应用的相关工作，关注性能优化、Web技术、浏览器等领域。
转载请注明出处
发表人
xuan chen
发表于
Re: 转载请注明出处
发表人
崔 康
发表于
又不是吃拉面，什么粗了细了的，乱弹琴！
发表人
高 翌翔
发表于
Re: 又不是吃拉面，什么粗了细了的，乱弹琴！
发表人
victor cai
发表于
一个不算瑕疵的缺少
发表人
治辉 周
发表于
Re: 一个不算瑕疵的缺少
发表人
崔 康
发表于
Re: 一个不算瑕疵的缺少
发表人
治辉 周
发表于
Re: 一个不算瑕疵的缺少
发表人
崔 康
发表于
细粒度+自动化测试
发表人
he ren
发表于
Re: 细粒度+自动化测试
发表人
he ren
发表于
Re: 细粒度+自动化测试
发表人
崔 康
发表于
-
转载请注明出处
-
在新闻中已经写明了“淘宝测试团队”，带有博文的超链接，并且采用了引用的格式，请问有什么问题吗？
-
泛泛地讨论测试用例的粒度没有任何实际意义，口舌之争罢了！
关键在于应该从实践中总结一套编写测试用例的指导原则，
然后再结合具体项目情况，根据指导原则该繁则繁，当简则简，从而做到游刃有余！
不妨从测试驱动开发中借鉴经验，最早编写是基本功能用例，保证系统的基本功能可用，
然后开始编写，异常分支的测试用例，保证系统在可预见的异常情况下做出正确处理，
至此，这些都是必须要编写的用例，根本不存在任何粒度问题，测试与功能紧密相连！
如果出现某个测试用例无法通过，那么或者说明相应功能尚未实现，或者说明此用例不符合需求！
TDD 是单元测试与开发相结合的开发模式。
不知淘宝团队所讨论的测试属于哪个阶段的测试？！ -
总结的太漂亮了
可惜的没有一个给我们这些没有太多经验和心得的人一个量化的基点。
遗憾，太遗憾，可以补上不。 -
顶你
-
总结的太漂亮了
可惜的没有一个给我们这些没有太多经验和心得的人一个量化的基点。
遗憾，太遗憾，可以补上不。
以我个人的经验来说，对于不同的项目、人员组织来说，量化的基点是很难一致的，只能给予方向性的指导，如本文所说。 -
测试用例当然是细粒度的好，好处不单单只是新人容易上手，还有：
1.从测试的角度检视需求的完整性；
2.便于同行（负责需求的系统分析员）评审；
3.利于知识的积累和传承。 -
为了减少测试成本，可以使用自动化测试工具进行自动化回归测试，提高测试效率。
-
测试用例当然是细粒度的好，好处不单单只是新人容易上手，还有：
1.从测试的角度检视需求的完整性；
2.便于同行（负责需求的系统分析员）评审；
3.利于知识的积累和传承。
测试用例当然细粒度的好，这个观点我也赞同，从纯技术角度看没有问题，但是在现实的项目开发中，时间、人员、资金、自动化程度等等都是制约因素，从上而下，也间接影响着测试用例的划分， 不得不做出折衷，另外提到了自动化测试，自动化是个好东西，但是有相当部分的测试还是需要手动来做或者人工干预，所以我觉得“细粒度+自动化测试”是我们追求的目标，但是现阶段还是要做一些让步。 -
同意你的观点，不同项目不同的量化基点。
但是在公司运作中一般要有一个普遍的基本标准，要不标准跟着人了，相当乱，不好管理。 -
同意你的观点，不同项目不同的量化基点。
但是在公司运作中一般要有一个普遍的基本标准，要不标准跟着人了，相当乱，不好管理。
是的，对于一个成熟的测试团队来说，量化基点或者制定量化基点的标准在长期的实践过程中不断地完善，从而形成一种规范的模式，大家采用这种模式来思考和设计测试用例，并在失败教训中继续改进。跟着人走，太可怕了。
11 条回复
关注此讨论 回复