PRD是项目中的重要输入文件，对测试人员来说，PRD是判断bug的基准，是测试执行的源头。入职半年以来，经手的PRD大小也有20+了，有的PRD写的十分详细，有的则截两张图草草了事，对这种PRD，测试是十分头疼的，然而，非要等PRD完美后才投入项目是不可能的，因为PRD不够完美就带着情绪进入项目更是不可取。以下是经过了各种令人头疼的PRD后的一些感悟，总结一下。

　　1、事无巨细的PRD固然很好，但现实的PRD肯定会有一些不完善的地方，学会不抱怨，接受PRD的不完美，针对如何提高PRD质量提出自己的建议和意见，协助PD将PRD整理的更好，业务逻辑和流程都更突出，流畅。

　　2、PRD读一遍是不够的。重要的业务细节，只有不断的推敲才能发现更多的用例，甚至不合理的地方，测试不仅要从文字上理解PRD，还需要去考虑更为细节的部分，也许这部分是没有写到的，需要我们刨根问底的。孙子兵法有云“不知山林、险阻、沮泽之形者，不能行军”，测试也一样，应考虑下应用的上下游或者强依赖的应用，防止隐藏bug。

　　3、进行PRD review时，更应该注意的是，业务逻辑是否描述清楚，流程是否明确。进行review的PRD，P0，P1，P2，P3级别的需求必须明确，级别低的问题可以直接在评审上通过询问PD加以确定。

　　4、PRD评审（二次评审）时，PRD（或者修改后的PRD）必须实现发出，且留有阅读的时间。与在评审上被PD牵着走相比，测试静下心来看PRD，能发现更多需求和设计上的问题。

　　5、功能分解图必须基于明确后的PRD，建议完成功能分解图后，再对照PRD看是否有可以优化的地方。

　　6、测试一定要跟踪PRD的更新，最好自己维护一份PRD样本，有需求更改时就直接在样本上修改，并注明修改详情。测试自己整理一份PRD的好处是，不会因PD发出的PRD版本太多或修改细节太乱而导致需求不清、遗漏测试点。

　　以上。