http://blog.csdn.net/zzzmmmkkk/article/details/9205495
过犹不及，这是古代《论语》中的一个成语，做得过了就好比没有做够一样。在软件测试行业中同样也会存在过度测试的情况，今天我就班门弄斧一下说说我对过度测试的理解。
很详细的需求文档会导致维护成本剧增
我所经历过的项目中有过几种很有代表性的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用判定表方式来完成，像这类型很简单的页面控件，应该编写好统一的测试用例集，不同的也就是字符长度限制了。我们也没有必要花心思来测试第三方软件。当然工作中可能还有很多类似这样过度设计的案例，工作经验比较足的人都能从过往中总结出我们更有效的测试思路。
过度回归测试会导致测试周期延长
什么叫过度回归测试呢？我总结成两点：1. 测试过程中环境的不稳定性导致之前测试结果的不可信赖，刚刚还好好的地方又出现问题了，又得回过头来跑一遍原来的用例，这样反复何时才是个头啊?! 2. 回归测试时我们总是要善于判断哪些功能需要回归，如果不想漏掉任何一个功能会导致测试周期严重延长，也就需要全部回归。
第一点解决好了测试环境的稳定性就可以避免，在测试每一轮次过程中保持代码不随意更新，数据库不任意更改不删除插入数据，各种服务不任意重启，让每个case运行结果都是可信的，那么会节省我们很多时间。
而回归测试时，我们只要判断好软件功能间是否有依赖，内容就明确了。
1. 有关输入：这些功能会不会处理同样的输入？？
2. 有关输出：这些功能会不会在用于界面上显示在同一个区域？会产生同一个输出吗？
3. 有关数据：是否会操作同样的数据？是读取还是修改？
以上只要有一个答案是肯定的，那必然有依赖，就需要回归一下。
过度自动化会让我们力不从心
我经历过以下两种情况：1. 我们有时候为了盲目追求覆盖率，会对一些简单的基于页面层面的case实现自动化，而这些内容适合自动化吗？2. 有些自动化case种都是基于某个前提下完成的(比如登陆)，而为了追求case间独立性，每一条都实现了该前提(登陆)，是否属于过度自动化呢？
如果页面改版，登陆功能重设计，对于代码的改动量可想而知，我们需要找出那些频繁地被拿来手动执行的用例，属于业务核心的用例进行自动化开发，而且我们完全可以在测试方法之外额外实现一个方法来实现登陆，只需要以下的所有测试方法都有异常捕获并且在该方法运行成功之后才执行。