InfoQ: 讨论:测试用例的粒度——粗细之争
来源:互联网 发布:c语言随机生成一个数字 编辑:程序博客网 时间:2024/06/06 09:07
讨论:测试用例的粒度——粗细之争
作者 崔康 发布于 2010年8月5日 下午9时31分
分享 |
测试用例的粒度一直是软件测试领域的热点问题,无论是粗粒度还是细粒度,都各有利弊。最近,淘宝测试团队针对该问题举行了内部辩论会,相关内容值得借鉴和思考。
正方观点:测试用例的粒度应该细点,主要体现测试细节。主要论据:
- 测试用例的编写就像是织网,而BUG就像是鱼,网织得越密,捕捉到的BUG就越多。
- 测试思想的学习并不是一蹴而就的。对一个新人来说,这种学习是一个渐进的过程,具体到每个项目,更需要用更精细的用例来保证测试的覆盖率。
- 设计详细的用例便于执行,便于新人理解,便于知识传承。
反方观点:测试用例的料度应该粗点,主要体现测试思想。主要论据:
- 粗并不等于简单。测试用例的粒度粗点,是建立在我们对需求完全理解,对设计完全掌握的基础上的粗粒度。这样我们可以避免繁琐的流程,提高测试执行的效率,把握重点需求。测试粗粒度可以避免陷入机械性的测试。
- 粗粒度的测试设计可以使我们把重点关注于设计,可以让测试往前走,在时间,资源有限的情况下,更高效地进行测试,保证产品质量。
随后,双方展开了自由辩论,其中不乏精彩的言论:
反方:思想就像大脑,测试用例是骨骼。在时间有限,资源有限时,必须要有所取舍,抓住主干测试,所以我们会追求白盒覆盖率而不是路径覆盖率。测试技能的提高是测试思想的不断丰富,测试手段的不断完善,而不是用例越写越细。
正方:在测试领域有8:2原则,80%的bug源于经常修改的20%代码,测试用例的数量提升有利于减少这种bug遗漏。并且,越精细的用例越便于定位BUG。
反方:就是因为我们的用例过细,导致在时间,资源紧张的情况下,导致覆盖率低,没有发现尽可能多的BUG,相反,如果我们在测试设计的时候,放得粗,可以把主要精力放在测试思想上,这样就可以提高测试覆盖率,发现更多的BUG。测试用例的设计要先搭一个整体的框架,然后再逐步完善。最后,评委做了总结发言:
......从管理者角度来看,还是希望测试用例的粒度细点好。
测试用例的粒度取决于项目质量的要求、时间的要求、用户的要求。如果时间充足,就可以把用例写细一些,时间紧张,就写粗些。有个词叫测试艺术家。就是要我们掌握质量与效率之间的平衡。
我们的用例不管是细还是粗,它都是为了达到最终目的——保证产品质量。测试用例写粗点还是细点,可以用一个例子来说明。当我们刚学车的时候,什么时候打方向盘,什么时候踩离合,什么时候踩油门。都需要教练一步步教,要一步步来,这些都很明确的。当开车有一段时间后,什么情况下要做什么动作都会很自然,一气呵成。当我们的新人在进行测试的时候,需要很明确地知道怎么做,这时候用例就得细些。当成为一个很熟练的测试工程师的时候,设计用例时就不必纠结于这些细节了。每个阶段不同,做事方式就不同,只要满足结果就好。
InfoQ: 讨论:测试用例的粒度——粗细之争
- InfoQ: 讨论:测试用例的粒度——粗细之争
- shiro权限控制之粗细粒度的区别(转)
- 什么是测试用例的设计粒度?
- 粗细粒度权限 --权限
- 测试用例的粒度是粗还是细?
- UML 用例的粒度
- 用例粒度与函数粒度的思考
- [全程建模]系统用例和业务用例的区别以及用例粒度的讨论
- InfoQ: Naresh Jain讨论“简单设计与测试”及其专题会议
- 确定用例的粒度几个基本原则
- InfoQ: 一次敏捷测试的实战
- 成长之路——InfoQ视频心得笔记
- 深入浅出Docker(四):Docker的集成测试部署之道(infoq)
- OO系统分析员之路--用例分析系列(2)--用例的类型与粒度
- OO系统分析员之路--用例分析系列(2)--用例的类型与粒度
- OO系统分析员之路--用例分析系列(2)--用例的类型与粒度
- OO系统分析员之路--用例分析系列(2)--用例的类型与粒度
- 测试用例标准讨论
- 如何使用HIVE-based Registry
- LINQ体验(10)--LINQ to SQL语句之开放式并发控制和事务
- 修改和重写
- ado 变量类型长度
- 把SQL Server表中的自动编号ID重新开始排列
- InfoQ: 讨论:测试用例的粒度——粗细之争
- 为什么析构函数要声明成virtual呢?
- 点击按钮复制文本框(Div)值(已测试 支持IE但不支持火狐)
- 命名管道的简单使用
- Oracle中的几个循环
- 近期学习记录
- CommandName属性和CommandArgument属性
- MyEclipse 8.6原来可以绿色的
- 【转】MFC 常用