大家都知道如果能把缺陷扼杀在编码之前可以节约很多成本，缺陷发现越晚花费的成本越高，尤其是设计上的缺陷如果到了编码后期甚至即将上线才发现也许会导致整个项目失败。所以现在越来越重视需求评审和设计评审，在前期投入的时间也会越来越多，但是有时候往往没有想象的那么好，投入的时间和收获不成正比例。那么在需求评审和UC评审阶段测试人员应该注意哪些呢，该怎么做比较好呢？当遇到几十页几百页需求压下来的时候不好好整理一下真的很困惑。下面讲一下我个人认为在需求阶段能够起到明显效果的几点做法：

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

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

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

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

　　三、熟悉相关业务

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

　　四、罗列出各功能点

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

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

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

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

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

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

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

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

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

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

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