最近一直在忙于各种工作上的事情，加上周末设计与录制在腾讯课堂上放的各种课程，没有太多的去写文档，以至于最近微信公众号上发布的都是以往收集的内容。鉴于最近在和大家交流的过程中，发现不少同学的功能测试的基本功不太牢，就准备设计一套 “功能测试知识体系与技能大全” 系列文章，本篇是第一篇：

本篇我们讲解 “测试人员如何进行需求评审”，主要包括以下内容：

一，何为需求评审?

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

1，严格规范模板的需求文档
内容包括需求产生的背景，需求级别，即将产生的收益，需求的内容，业务流程，交互示例，需求可能影响到的业务说明等。一般大型公司比较规范，有相应的需求模板，产品经理之间会进行需求的确认等。

2，一句话的描述的需求
需求文档没有规范，通常需求描述比较简单，几句话或是一句话的需求，或是在项目管理平台上创建一个任务，写上一两句话就开始进行需求的开发工作。

3，口头的需求
产品经理有个什么想法，直接去找相应的开发人员，口口相传需求，一边讲解一边调整最初的想法，与不同的人讲解需求的时候还可能有出入。

二，为什么要进行需求评审？

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

1，保证产品，开发，测试相关人员了解需求
无论是完整规范的需求文档，还是口口相传的需求，都会存在需求参与人对需求理解不一致的情况。在一个需求开始实施之前，召开需求评审会议，统一讲解一下需求，保证需求参与人员听到的是统一的版本。在需求讲解的时候，解答大家存在的疑问，确保所有人员对需求的理解是一致的。

2，讨论需求实现过程中可能遇到的困难及解决方案
需求评审还要讨论出在实施过程中可能遇到的问题以及对应的解决方案。产品经理从产品角度来设计需求，开发人员要从技术角度来分析解决方案，要实施产品的需求，存在技术难题吗？如果有，提前提出来，大家一起讨论解决方案或是优化产品，不能在开发过程中再提出，到时会严重影响项目的进度的。

3，明确职责及预估项目周期
需求的完全实施过程中，还要明确相关人员的职责。这个需求相应的开发人员，设计人员，测试人员是谁？需要完成的工作是什么？什么时候能参与进来？都需要提前确定的。同时在需求评审的结束之后，大家要根据对需求的理解，给出自己负责内容的完成时间，以便产品来预估项目周期。

三，如何进行需要评审？

在了解了需求评审的重要性之后，产品，开发，设计和测试人员都应该重视需求评审工作，可是应该如何进行需求评审呢？

1，什么项目需要进行需求评审
我们强调需求评审，并不是所有的项目都要进行需求评审，尤其是现在快速迭代的情况下。需要进行评审的项目应该是：
（1）项目周期比较长，涉及的内容较多，需要通过评审让参与人员全面了解需求。
（2）需求存在异义较多的情况，不同的人员对需求理解有出入，需要进行讨论统一认识。
（3）跨部门的需求，由于存在一定的沟通成本，所以需要提前进行需求评审可以有效地降低后期沟通的成本。
小型的需求或是涉及人员较少，不存在较多异义的需求可以适当进行需求评审。

2，需求评审有谁来组织？

 需求评审一般有产品来进行讲解需求，由产品来组织的情况较多。不过我们测试人员在发现了需求存在理解困难，有较多异义的时候，也要积极主动的去组织需求评审，邀请产品对需求进行讲解。测试要发现积极主动性，不能在提测后才开始工作，要做到测试前置。

3，需求评审要参加的人员有哪些儿

在组织需求评审的时候，需要确定相关参与人员。需求产品负责需求讲解，由开发负责人，测试负责人安排相关的开发和测试人员，同时如果涉及跨部门合作时，相关部门的参与人员都必须参加需求评审。约定需求评审会议的时候，相关人员的时间必须都合适，不能因为没有时间参加，后期存在异义造成影响项目进度。

4，需求评审要做些什么内容

产品讲解需求的产生背景，需求要实现的效果，业务逻辑，用户交互等，保证相关的参与人员充分理解需求；解答大家对需求存在的任何问题，最终达到对需求的一致性认识。开发从技术角度来分析实现方案，实现难易程度。如果实现中存在问题，有没有好的解决方案，在预定的时间内会影响项目进度吗？设计从交互角度给出适当的建议，有没有不合理的交互流程，是否存在可优化的地方？测试从用户角度来给出产品逻辑上是否存在不合理的建议，对需求实施需求测试，提前介入项目。


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


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

1，测试人员如何推进需求评审

测试人员要想很好地推进需求评审，需要做到以下几个方面：
（1）关注公司，部门规划 ------- 明确发展进度。对未来要做的需求达到心中有数，才能做到合理规划自己的工作，根据项目进度来安排需求评审，编写测试用例等等的工作。
（2）准确分辨需求类型，选择需要评审的需求。不能钻牛角尖，并不是所有项目都需要进行需求评审的，要根据业务发展，需求的类型等合理安排需求评审。
（3）关注产品规划，确定相关参与人员。在做需求的时候，一定要明确相关的参与人员，做到项目的每个阶段可以明确想着的负责人沟通存在的问题。
（4）积极配合产品进行项目推进，督促项目负责人或是产品进行需求评审。在项目的关键阶段，对应的交付物有没有交付，及时进行风险预警，推进项目的按期完成。
（5）提前阅读需求文档，做好充分准备。在需求评审前，一定要先阅读需求文档，带着问题去参加需求评审，以便能更好地理解需求，提出自己的不同意见。

2，在需求评审的时候如何进行需求测试

我们常听到要进行需求评审，可是如何进行需求评审呢？
（1）明确测试在需求评审阶段已经开始。测试工作是贯穿于项目的整个流程中的，并不是在开发完成编码提测后才开始的。需求阶段要进行需求评审，每个阶段都有测试需要做的工作，测试人员首先要有这个意识。
（2）认真听取需求评审过程中不同的意见，相关内容的修改的地方。参加需求评审的过程中，必须认真的听取需求讲解的内容，大家讨论的不同意见。不可认为需求评审和自己关系不大，就参加一下会议是不行的。因为在需求评审的过程中大家讨论的不同意见，可能存在修改需求的情况；同时这些地方也是在测试过程中必须着重关注的地方。
（3）积级从以往的经验中提出自己不同的意见。在需求评审的过程中，根据自己以往的测试经验，对业务的掌握情况，客户使用的习惯，对本次需求提出不同的意见。从需求评审阶段对需求进行测试，及早地发现需求中存在的问题。
（4）督促大家对所有异议达成一致。需求评审时难免出现不同的意见，大家需要进行讨论一下，从而找到最优的解决方案。当然也有对异议达不成一致地方，测试需要协助会议的组织者督促大家达成一致，或是给出解决方案的时间节点。对需求有任何修改的地方，确保产品修改相应的文档，确保需求变动的文档化。

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


（1）根据需求内容明确测试范围；确定本次需求需要保证的内容，可能影响的原有业务，是否需要其他业务的支持等等。
（2）根据需求类型选择测试方案，比如：需求确认 ---- 功能测试，并发需求 ---- 性能测试，安全相关 ---- 安全测试，影响范围 ----- 回归测试等。

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


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

2，需求相应的交付物跟踪与确认

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

3，审核与调研测试方案

需要评审完成后，需要确认一下当前需求需要的测试方案是否可以随时实施。存在哪些问题可以影响实施，解决这些问题需要多长时间，是否影响项目的正常测试？同时需要着手编写测试用例设计，包括冒烟与全功能测试用例，并且要保证冒烟测试用例优先完成。编写完成用例后，组织进行用例评审，邀请产品，相应模块的开发人员来一起评审用例，查漏补缺。在用例得到了三方的认可后，将冒烟测试用例交给开发人员，同时将整体测试用例交付需求相关参与人员。
4，需求的维护及管理 
测试人员还需要保证需求相关的交付物的维护和管理工作，在需求评审的时候，如果有需求变动，有没有更新到需求文档上？产品设计交付，代码设计文档有没有统一管理。如果在开发实现代码的过程中，因技术问题引起的需求修改，有没有落实到文档，有不有同步给大家？测试人员作为质量保证的最后一关，一定要有高度的质量意识。从项目开始，就需要从各个方面，采取必要的手段来保证项目的质量。

六，总结

本篇文档我们介绍了测试人员如何进行需求评审，需求评审的必要性，需要评审过程中要做的事情，以及需要评审是如何保证项目的质量的。测试人员在项目实施的过程中往往处于被动，这对于保证项目质量非常不利，所以要发挥积极主动性，从需求开始就介入测试，勇敢担当起项目经理的职责。