软件测试中的过度设计

lsekfe

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

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

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

回忆一下公司创业初期，那时做项目也没有特别规范的文档，一般就是几个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、自动脚本）的寿命都是短暂的，测试团队如果花费大量的成本来维护这些文档，很容易造成“测试过度”，疲惫不堪。不同于传统软件行业，互联网软件的测试团队，更注重于灵活轻便，善于应对频繁的软件变化，对自己的产品有着透彻的了解，不管是业务需求还是程序结构，这一点非常重要。

文章出自：http://www.uml.org.cn/Test/201207034.asp

puchonghui

这文章怎么看都像是在抱怨-_-

关于2 3 4条，tc的管理，其实有个简单的办法：牵涉关键业务路径的正向的测试用例写详细步骤，其他相似路径的可以引用。 逆向的测试用例用checklist。

我一向同意简化tc的管理，因为毕竟是个内部文档，受众都是专业人士。然而，如果按我说的这个原则来管理，文章里说的目录还是表格的说法就是扯谈了。  他真的认为按他说的条件只要画这么个表格就行了么。。。