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

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

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

回忆一下公司创业初期，那时做项目也没有特别规范的文档，一般就是几个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说清楚了，根本不用分这么多目录结构，如下图：