注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

那些星星点点的微芒,终会成为燃烧生命的熊熊之光

 
 
 
 
 

日志

 
 

读淘测试(软件测试中的过度设计)有感  

2012-12-13 18:32:15|  分类: 软件工程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

这篇文章的主要内容有原文+我的一点小感触,在此拿出来与大家分享交流。有疑问或歧义的地方欢迎指正。


原文来至:http://www.taobaotest.com/blogs/qa?bid=10339

以下是原文内容:

中国有句老话:过犹不及。软件开发中也有一个概念:“过度设计”,说的是为了实现一些简单的功能需求,设计出非常臃肿的结构,代码间的继承、依赖、调用非常复杂,开发工作量大并且难以维护。在软件测试工作中,也存在类似“过度设计”的问题,特别是大中型的软件企业,人数比较多,各方面工作流程趋于稳定和规范,问题更容易发生。

出现“过度测试”的原因非常简单:忽视了软件测试工作的终极目标与核心价值,而过于关注测试活动过程。这里我列出一些“过度测试”的案例,我们一起分析一下。
测试工作必须依赖完整规范的需求文档
回忆一下公司创业初期,那时做项目也没有特别规范的文档,一般就是几个Excel表格、一些Word说明,不过项目也都顺利完成了。可是现在好像如果没有规范的文档,测试工作就寸步难行了,为什么呢?我们经常看到测试工程师整天催PD和DEV把文档补全,催得很辛苦也很郁闷,看起来就像是测试团队要为文档的质量负责一样。有时甚至出现了,测试团队自己动手维护需求文档的现象。是不是测试团队不拿着一份完善的文档,就寝食难安呢?
对于测试团队来说,需求文档确实很重要,但是我们真正的目标是,弄清用户的需求和开发的实现方案,然后便可以设计测试方案。阅读文档是方法之一,交流和讨论其实更重要,期待文档中能说明一切信息,是有点不实际的,特别是互联网公司,需求信息爆炸,创新层出不穷,文档更像是字典,只记录重要的原子信息,而要把它们串联起来,更多是靠人与人的沟通。
过分纠缠于文档的细节,会消耗测试工程师很多工作量,而且心情也搞坏了。如果你加入一个文档很完善很规范的项目组,那么恭喜你。如果你遇到一个文档不全的项目,也不用懊恼,想办法把需求弄清楚,把关键的逻辑搞明白,找出需求中的重要漏洞,就可以了。有的人会问:文档不全,以后怎么传承给测试的新人呢?在这篇文章里,“传承给测试新人”这个概念会经常出现,并且成为“过度测试”的主要原因之一了。这里请大家思考一下,新人培训到底应该怎么做,是不是非要投入这么大,做得面面俱到。况且,互联网的需求变化极快,即使要传承,又能传多久呢?
每个测试用例都要让一个完全不懂业务的新人看懂
这个观点跟测试用例(TC)的编写详细程度有关。在这个观点的指引下,每个TC都写成了一个小型的说明书,阅读起来确实很详细,不过测试工作量陡然增加,不禁怀念以前用Excel写TC的年代。
要分析这个问题,首先要看一下设计TC、执行TC的实际场景。在设计TC时,往往都是针对一个功能模块,设计一组TC,也就是测试集(TestSuite)。这一组TC有着相似的操作过程,前置条件,校验手段,它们不同的是输入数据、输出结果。在执行TC的时候,测试集的概念更加明显。熟练的测试人员肯定不是看一个TC执行一个TC,而是把一组TC放在一起,一口气执行。所以设计TC的时候,应该是以测试集为对象,而不是把一个TC作为一个对象。
再说说如何让新人看懂TC。请大家思考一下,TC的作用究竟是为了指导测试执行,还是为了让新人熟悉业务?一组TC每个月可能会被新人阅读1~2次,但是会被测试执行人员阅读20-30次,我们写TC是不是更应该方便执行人员而不是新人。TC不是培训资料,我们不能靠把每个TC都写得无比详细,来对新人进行“培训”。新人要学习业务和测试技巧,需要依靠的是师傅指导,是知识沉淀文档。
互联网的产品,需求变化非常快,基本上1年就会发生一次很大的变化,所以一般的TC寿命也只有1年,何苦为了TC这么纠结呢?只要TC写出来能发挥它本来的作用,就可以了。
测试用例的目录结构要进行严格的分类
现在很多测试团队都使用商业软件来管理TC,一般都是用一个“目录树”来对TC进行分类,类似于windows的文件夹,目录的主要作用是让TC的读者清楚的了解TC设计逻辑。TC目录怎么组织,也是有一些讲究的,并不是分类越细越好。我曾经看到过,TC目录超过10级,分类非常严谨,可是展开目录,阅读的时候,就很不方便了。
看一个例子:比如我们测试windows的复制文件功能,需要考虑文件大小、文件类型、磁盘分区这3个维度,每个维度有很多数据,比如磁盘分区有FAT、FAT32、NTFS,这些数据组合起来,就形成了一组TC,如果我们把目录结构设计很严谨的话,会产生下面这种目录:
其实我们用一个Matrix就足以把这一组TC说清楚了,根本不用分这么多目录结构,如下图:
商业工具给我们提供目录功能,是想帮助我们整理设计思路,不过如果我们设计过度,就会把自己搞晕,所以目录结构的设计,尽量扁平,多使用Matrix来描述TC。
对页面控件的静态校验TC要设计得很完整
我在参与一些项目的TC评审的时候,经常能看到大量的WEB控件静态校验TC,比如文本框的“不填任何字符”、“填数字”、“填汉字”、“填超过20个字符”,再比如Grid控件的“上一页”、“下一页”、“最后一页”等等。其实这些TC模样都差不多,不同的只是控件的名称,还有控件属性(例如最大字符数)。编写这些TC无疑要花费大量的人力,有的甚至为了写一个“不填任何字符”这样的简单TC,要写出上百个汉字来。
对于这些非常成熟的WEB控件,一般每个开发团队都会有一套成熟的框架,出错的可能性不是很大。另一方面,成熟的测试团队也必然会沉淀出一些对控件进行静态测试的方法和规范。即使我们不写这些TC,只要我们搞清楚每个控件的属性,明确每个控件的标准测试方法,是完全可以很好的覆盖这些静态TC的,实在没有必要让“等价类”、“边界值”这些测试理论在静态校验上发挥的淋漓尽致。我们关注的重点应该是业务逻辑,还有程序的内部结构。
自动化覆盖率越高越好
关于自动化覆盖率的问题,争论一直没有停止。大家也都同意,自动化脚本多了不好,少了也不行,至于到底多少才是最好,谁也说不清。其实我也说不清,所以这里也不多罗嗦了,只想说一点,互联网软件的特点是创新多,变化快,因此相应文档(比如需求、TC、自动脚本)的寿命都是短暂的,测试团队如果花费大量的成本来维护这些文档,很容易造成“测试过度”,疲惫不堪。不同于传统软件行业,互联网软件的测试团队,更注重于灵活轻便,善于应对频繁的软件变化,对自己的产品有着透彻的了解,不管是业务需求还是程序结构,这一点非常重要。


小感触————————————

自看到这篇文章时,都深有感触,只是一直没记录下来。可能今天突然吃错药了、要么是忘记吃药的缘故吧。

相信很多童鞋了解过敏捷测试吧,需要了解的童鞋请移动鼠标点击蓝色字体~~

个人认为”蓝色字体指向的页面,书写是敏捷开发与测试流程性的东西,有过于统笼(不是说写的不好哈)。虽然敏捷开发讲究开发和测试不分,而这篇原文(小感触以上的部分)是站在测试的角度来说的,各要点写的灰常不错也很详细,所以自己觉得这篇文章有点敏捷测试的意思,但这不是重点“。

本来软件测试的流行,就是由国外引进来的,还记得起初微软的内个事件吧。本来想在这个事件上加个链接的,暂时没找到...以后见着了,更新下。

拿一些小的公司来讲,我们一致的去模仿大公司和国外的流程或方法来开展项目及工作流程,我们是否想过别人的方案拿到自己这,是否有弊端?好比测试用例的书写;我们效仿其他公司设计用例写用例,抛开覆盖率不讲,流程和方法对我们自己当前的项目真的合适?有没有感觉会影响项目进展呢?其实用例的细化程度还没说。

话说回来,并不是大公司流程上就没问题的,这里不针对细节上的东西。继续。

如果我们把书写用例的时间抽出30%或40%来,当然,此刻的用例就变成了测试点(也可以叫用例,只是细化程度不一)。抽出的时间去和相关部门沟通、去了解当前项目业务逻辑和实现规则或者拿来完善流程再或者去学习各种知识,这样会不会好点呢?会不会减少之后的沟通成本呢?如果需求变更较大,这个测试点(或者喊他用例)改起来会不会简单点呢?我们一再的强调沟通、要好好沟通;但我们是否真正做到了呢?

其实不然,每个公司都有适合我们自己的流程和方法,或许我们从另一个角度来看待会好点。这里只拿出了一个关于用例的例子,其实有好多地方可以优化和改善,童鞋你看到了吧?

在这互联网高速发展的时代下,需要的是效率、是优越的产品,当然产品质量也是前提。


以上只是我的一点小感悟。可能写的有点刻薄了(可能切糕吃多了)。因为大家都奔着同一个把项目以最短的时间和靠谱的质量交付出目的。

  评论这张
 
阅读(67)| 评论(0)
推荐

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017