过犹不及，这是古代《论语》中的一个成语，做得过了就好比没有做够一样。在软件测试行业中同样也会存在过度测试的情况，今天我就班门弄斧一下说说我对过度测试的理解。

　　很详细的需求文档会导致维护成本剧增

　　我所经历过的项目中有过几种很有代表性的PRD（product requirement document的简称，即产品需求文档）：

　　1、很详细的文档，详细到会定义一个链接是新开一个tab还是在原tab打开，告诉你你想知道的一切信息；

　　2、包含了产品主要功能流程的文档，会以流程图辅助说明，不会太细化，细节性的内容更多要通过交流和讨论获取；

　　3、一封邮件说明或直接几个人讨论决定。

　　特别对于互联网项目，需求变更频繁，需求信息巨多，对于PM（产品经理）来说，完成一篇很详细的文档需要的时间不说，每次的需求变更或评审后的需求漏洞都需要更新到PRD中，对于测试人员而言，需要重新阅读PRD中改动的部分，而且详细的需求就需要更详细的用例来覆盖，是否有必要这么详细的文档呢？对于互联网项目能保持一年不大改都是少有的了，我们是否有必要考虑下不为文档所累呢。

　　详细的测试用例会拖累我们

　　以前我的观点一直都是秉承着一个基准来要求我自己和团队其他人来写用例：让不懂业务的人也能顺手拈来执行用例。而在后来的一段时间，用例维护起来竟是如此头疼，每次更新详细的测试步骤和结果都需要大量的时间，而且发现项目中很少有让一个不熟悉业务的人来执行这些用例的时候，即便是新人来了看着用例仍然比较迷惑，仍然会多次询问详细的业务，发现还是PRD看着更系统更有逻辑条例，能更快的了解业务内容。毕竟看着用例，我们仿佛执行了40，50条用例仍然在一个功能上，根本不能跟其他功能串起来，对于业务的熟悉是多大的阻碍啊。我觉得从宏观到微观再到宏观才是正确之道。而对于测试技能则更需要导师指导，并不能从用例中掌握太多东西，除了考虑问题的周密性外。

　　之前在维护用例的目录时也有过度维护的情况，比如有AB两个页面都有一个子功能C，每次回归测试时需要对AB两个页面上功能进行回归，避免遗漏，就把C对于的用例都copy到AB两个目录下了，那么每次更新维护时也都需要维护多份，重复的工作可想而知。

　　如何让用例不拖累我们呢？

　　标题能说明的就无需步骤和结果，内容太多实在是放不下的时候再有详细步骤和结果说明，可以以附件形式上传excel表格的多条用例，不要为了规范而规范，而且用例多是给测试执行人员使用的，不是为了让新人了解业务而存在的。目录结果过于臃肿的再优化，比如C有专门的目录存放用例，AB下建个目录仅说明有C这项功能，好比是linux下的软链接，原来那种方式连硬链接都不如，它不能同步更新（PS.我们使用的是QC管理用例）。

　　过度设计的用例会降低我们的效率

　　你是否遇到过这样的情况，比如有三个输入框，但是没有很强的逻辑关联，只不过他们是必填项决定着是否能成功提交，如果设计出8个case来覆盖是必填项这个条件才够放心的话，对于有更多的输入框时我们是否会崩溃掉呢？

　　另外一种情况，比如需要调用第三方分享，就说微博吧，我们是否需要覆盖含有特殊字符的文字内容能否成功分享，超长文本内容能否成功分享？

　　上面这两种很显然是过度设计，我们完全没有必要为了这类等价类边界值的case用判定表方式来完成，像这类型很简单的页面控件，应该编写好统一的测试用例集，不同的也就是字符长度限制了。我们也没有必要花心思来测试第三方软件。当然工作中可能还有很多类似这样过度设计的案例，工作经验比较足的人都能从过往中总结出我们更有效的测试思路。