EEPW论坛

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

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

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

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

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

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

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

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

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