软件测试中的过度设计

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

  出现“过度测试”的原因非常简单:忽视了软件测试工作的终极目标与核心价值,而过于关注测试活动过程。这里我列出一些“过度测试”的案例,我们一起分析一下。

  测试工作必须依赖完整规范的需求文档

  回忆一下公司创业初期,那时做项目也没有特别规范的文档,一般就是几个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,如果我们把目录结构设计很严谨的话,会产生下面这种目录:

原文转自:http://www.uml.org.cn/Test/201107072.asp