一 、通读全文了解需求的目标

　　首先大概的浏览一下需求，大致了解一下整体的目标，要达到什么要求，与什么业务有关系，是全新的业务还是对某类老的业务进行改造等等。

　　二、仔细审阅每个功能点，寻找问题，理解需求

　　第2遍审阅需求需要非常仔细认真的审核每个功能点，使用鸡蛋里挑骨头的方式找出其中的问题或不理解的地方，记录下来。可以从系统角度考虑，从用户角度考虑，从测试人员角度考虑。比如系统可维护性，简单性，可测试行，易用性等等。

　　三、熟悉相关业务

　　如果是老业务的改版，需要是熟悉原来的系统，多操作老系统，熟悉各种业务，发现原来系统的优缺点，了解哪些地方需要优化，数据该如何准备，用列场景有哪些，心理有个数。从用户角度和测试人员的角度考虑问题，要改成什么样才认为更合理。如果是全新的业务，以前没有接触过的业务，需要查阅相关资料，了解同行的情况。

　　四、罗列出各功能点

　　从需求中整理出需要实现的功能点，哪些是本次要实现的功能点，哪些是以后需要实现的功能点。划分主次功能和优先级。

　　接下来需求评审的时候该问什么就问什么，把问题摆出来讨论，提出自己的建议。问题讨论如果没有结果记录下来下次需要再次评审，讨论出结果的记录讨论结果，会后要跟踪问题。

　　五、设计方案阶段，试着对一些模块进行设计

　　根据这些需求就测试人员也可以提前设计测试，画流程图之类的，甚至画草稿图都可以，形式不拘，这样就更进一步熟悉系统，测试人员需要对系统有一定了解，可以按照自己的思路设计，设计完成后可以和开发人员沟通和讨论自己的设计方案，使用各种反例来证明此方案是否正确，是否还有更简单的设计思路。

　　六、在设计方案评审前仔细审阅方案，看看一些异常情况下是否考虑到

　　另外开发人员的设计方案是否可行，一般正常逻辑都是符合的，可以从各种异常情况中来考虑此方案是否符合要求。

　　七、在设计方案评审阶段提出自己的见解

　　在设计方案评审的时候可以提出自己的方案和见解，看看是否可行，目的是为了找出更简单可行的方案。

　　八、记录评审问题，便于跟踪问题

　　评审中任何不确定问题都需要记录下来保存文档，便于跟踪问题。会后发送项目组成员。

　　当然这些自然要在项目前期投入较多时间才行，如果项目前期没有什么时间投入的话就另当别论了。

回想这次做项目，由于是从详细设计阶段加入进去的，所以评审的时候我纯粹俺设计思路来理思路，自己不仅没有好好研读需求分析和设计文档，更何况去提建设性的意见和发现早期的BUG了，以后做项目一定要发挥自己的主观能动性，多学习，多熟悉业务，掌握设计思想，多思考，发挥出自己的作用，也避免后期的BUG。这次zs项目就如此，重要的调度模块没有好好理清业务和系统关系和数据转换，所以导致后期编码的时候开发设计人员临时抱佛脚，转变思想，自己写测试用例和测试的时候，是赶鸭子上架，现炒现卖，测试也是很不顺利。深刻教训……