需求评审时测试人员都需要做什么？

需求评审是产品经理将一个即将实施的需求，讲解给相关参与人，如开发、设计、测试人员等以达到大家对需求理解一致，解决对需求存在的任何异意，最终保证大家向着统一的目标而开展相应的工作的活动。

为什么要进行需求评审？

由于存在不同形式的需求，所以在需求推进的过程中可能存在很多问题，从而影响整个项目的实施效果。对适当的需求进行合适的需求评审还是非常必要的，需求评审主要解决以下三个问题：

保证产品，开发，测试相关人员了解需求，无论是完整规范的需求文档，还是口口相传的需求，都会存在需求参与人对需求理解不一致的情况。在一个需求开始实施之前，召开需求评审会议，统一讲解一下需求，保证需求参与人员听到的是统一的版本。在需求讲解的时候，解答大家存在的疑问，确保所有人员对需求的理解是一致的。
讨论需求实现过程中可能遇到的困难及解决方案，需求评审还要讨论出在实施过程中可能遇到的问题以及对应的解决方案。产品经理从产品角度来设计需求，开发人员要从技术角度来分析解决方案，要实施产品的需求，存在技术难题吗？如果有，提前提出来，大家一起讨论解决方案或是优化产品，不能在开发过程中再提出，到时会严重影响项目的进度的。
明确职责及预估项目周期，需求的完全实施过程中，还要明确相关人员的职责。这个需求相应的开发人员，设计人员，测试人员是谁？需要完成的工作是什么？什么时候能参与进来？都需要提前确定的。同时在需求评审的结束之后，大家要根据对需求的理解，给出自己负责内容的完成时间，以便产品来预估项目周期。

测试人员在需求评审中的角色 

很多测试人员认为一个项目只有要提测之后自己的工作才开始，其实不是这样的，在项目开始之初测试人员必须介入进来。测试人员在需求评审中承担什么角色呢？

1、测试人员如何推进需求评审  测试人员要想很好地推进需求评审，需要做到以下几个方面

（1）关注公司，部门规划 ------- 明确发展进度。对未来要做的需求达到心中有数，才能做到合理规划自己的工作，根据项目进度来安排需求评审，编写测试用例等等的工作。

（2）准确分辨需求类型，选择需要评审的需求。不能钻牛角尖，并不是所有项目都需要进行需求评审的，要根据业务发展，需求的类型等合理安排需求评审。

（3）关注产品规划，确定相关参与人员。在做需求的时候，一定要明确相关的参与人员，做到项目的每个阶段可以明确想着的负责人沟通存在的问题。

（4）积极配合产品进行项目推进，督促项目负责人或是产品进行需求评审。在项目的关键阶段，对应的交付物有没有交付，及时进行风险预警，推进项目的按期完成。

（5）提前阅读需求文档，做好充分准备。在需求评审前，一定要先阅读需求文档，带着问题去参加需求评审，以便能更好地理解需求，提出自己的不同意见。

2、在需求评审的时候如何进行需求测试  我们常听到要进行需求评审，可是如何进行需求评审

（1）明确测试在需求评审阶段已经开始。测试工作是贯穿于项目的整个流程中的，并不是在开发完成编码提测后才开始的。需求阶段要进行需求评审，每个阶段都有测试需要做的工作，测试人员首先要有这个意识。

（2）认真听取需求评审过程中不同的意见，相关内容的修改的地方。参加需求评审的过程中，必须认真的听取需求讲解的内容，大家讨论的不同意见。不可认为需求评审和自己关系不大，就参加一下会议是不行的。因为在需求评审的过程中大家讨论的不同意见，可能存在修改需求的情况；同时这些地方也是在测试过程中必须着重关注的地方。

（3）积级从以往的经验中提出自己不同的意见。在需求评审的过程中，根据自己以往的测试经验，对业务的掌握情况，客户使用的习惯，对本次需求提出不同的意见。从需求评审阶段对需求进行测试，及早地发现需求中存在的问题。

（4）督促大家对所有异议达成一致。需求评审时难免出现不同的意见，大家需要进行讨论一下，从而找到最优的解决方案。当然也有对异议达不成一致地方，测试需要协助会议的组织者督促大家达成一致，或是给出解决方案的时间节点。对需求有任何修改的地方，确保产品修改相应的文档，确保需求变动的文档化。

3、在需求评审中进行测试方案的选择  

（1）根据需求内容明确测试范围；确定本次需求需要保证的内容，可能影响的原有业务，是否需要其他业务的支持等等。

（2）根据需求类型选择测试方案，比如：需求确认 ---- 功能测试，并发需求 ---- 性能测试，安全相关 ---- 安全测试，影响范围 ----- 回归测试等。

需求评审结束后要做的内容 

1、会议上要确认的内容是否达成一致在需求评审会议即将结束的时候，需要确认在评过程中存在不一致的地方，是否达成了一致？异议达成一致的方案是否已经确认？如果方案没有确认，是否影响整体规划？何时能给出确认方案？不能存在讨论了很久，最终没有准确的解决方案，这种情况是无法进行需求的开发与实施的。

2、需求相应的交付物跟踪与确认在需求评审结束后，需求文档是否需要修改？开发和设计人员有什么需要准备的内容吗？预定的时间节点是否已经确定？如果没有，何时能给出具体的时间？以下的关键节点需要给出准确的时间：（1）需求更改交付时间（2）设计完成时间（3）测试用例评审时间（4）提测试时间（5）测试开始与结束时间（6）上线时间

3、审核与调研测试方案  需要评审完成后，需要确认一下当前需求需要的测试方案是否可以随时实施。存在哪些问题可以影响实施，解决这些问题需要多长时间，是否影响项目的正常测试？同时需要着手编写测试用例设计，包括冒烟与全功能测试用例，并且要保证冒烟测试用例优先完成。编写完成用例后，组织进行用例评审，邀请产品，相应模块的开发人员来一起评审用例，查漏补缺。在用例得到了三方的认可后，将冒烟测试用例交给开发人员，同时将整体测试用例交付需求相关参与人员。

4、需求的维护及管理测试人员还需要保证需求相关的交付物的维护和管理工作，在需求评审的时候，如果有需求变动，有没有更新到需求文档上？产品设计交付，代码设计文档有没有统一管理。如果在开发实现代码的过程中，因技术问题引起的需求修改，有没有落实到文档，有不有同步给大家？测试人员作为质量保证的最后一关，一定要有高度的质量意识。从项目开始，就需要从各个方面，采取必要的手段来保证项目的质量。