认识达内从这里开始

过度设计是我们在进行软件测试性能分析的时候经常能够遇到的一些问题，不是说需求没有实现，而是过度设计会增加代码的复杂性和代码质量等。下面我们就一起来了解一下，什么样的设计会被判断为过度设计。

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

回忆一下公司创业初期，那时做项目也没有特别规范的文档，一般就是几个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级，分类非常严谨，可是展开目录，阅读的时候，就很不方便了。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。