大约在我刚刚毕业参加工作那会儿，我们的小组就在推举需求评审这件时间，本人有幸跟着我们组那个时候充满男子气概的老大，整天沉迷于需求评审，怼天怼地怼需求怼开发。非常幸运的是当时的团队也非常的虚心抗怼，所以这件事情总体产生了一个比较正向的结果。

1、为什么要做需求评审？

最初在做需求评审的时候，我还没有了解到测试左移这个概念，只是那个时候作为一个测试执行角色， 被在后期才发现需求不明确的一些问题困扰着，并且往往会影响到版本的发布。随便回忆一下都可以列举一系列罪状：

--版本即将发布的时候才意识到我们所生产的产品与策划或者原始需求方产生了偏差，那么这个时候我们去修改的成本已经相当的大了。

--版本测试过程中发现多处需求不清晰，在了解了策划的意图以后程序又反馈目前的架构上不支持这样的做法。

--程序在开发的过程中意识到需求不明确私下和策划进行沟通却没有通知到其他干系人，导致大家的理解出现偏差。

。。。。诸如此类等等

需求作为整个产品版本的领头部分，哪怕出现一个细微的小问题在越往后期越会被无限的放大。

2、需求评审的成本与完成的质量。

能力成本:作为一个质量保证人员，我们要如何在前期去保证需求的质量呢，有些同学会说，我们如何在前期去预料到后期一系列的事情发生呢？这对相应人员的能力要求，会比较高，不同能力或者不同思维的人员来做需求评审所产生的结果与质量也是不同的。

时间成本：但是在推行需求评审的过程中其实也会存在许多的质疑，需求评审同样需要成本，需要评审人员在版本前期去花费较多的精力去理解需求、质疑需求，而且也不是在这样的时间段能够马上提出所有的疑问，随着案子的演进与更改也会带来和程序一样的小型质量演进。没有做好正确的管控可能无限拉长版本前期周期。

即便投入了这些成本，就能够产生好的效果吗？

所以如何更快更好的完成需求评审？这需要需求存在质量，保证质量的人员思维足够完善，完整的一套流程来共同努力。

3、把握需求评审质量。尽量让每一个需求评审员思维大方向不出现遗漏。

需求评审会

这个会议会邀请开发、策划、QA等干系人一起参加，大家在会议上各抒己见最后敲定需求。目前我参与过的比较多的项目中QA的存在感都很低，基本上一言不发听完全程。这样的会议对与QA来说不像是评审会倒像是知照会，甚至有些需求评审会会忘记去通知QA到场。为什么呢，因为QA在里面没有产出价值或者说目前暂时无法产出价值。针对这一点毫无疑问我们需要提升每一个需求评审员的评审技能。

控制需求评审环节的输入与输出。

    一开始实行需求评审的时候，我们是采用一带一的模式，也就是开头说的由导师带领去参加需求评审会议，说实话这样比较靠经验也比较慢。毕竟每个需求案是不一样，而且我发现每次总会有一些我知道方向遗漏考虑了。于是我给自己列了一个需求检查表，并且在每次版本过程或者评审过程中去补充一些被遗漏考虑的方向。后来这张表同样也可以推广给一些需要去需求评审的人员手上，我通过各自的经验来共同分享与维护这张表。详细说明见需求评审检查表与报告。

有了这份检查表以后我们也慢慢意识到，在测试左移的过程中，仅仅增设某个环节是远远不够的，我们需要拥有一些看得见摸得着的检验标准与环节成果。

需求评审环节：

需求输入：策划案、需求评审会议

评审输出：策划案逻辑流程图，需求评审报告，更新的策划案。

需求评审报告：基本是基于检查表产出的一些成果。对于高职级的同学需要去审阅这样的报告快速了解当前案子需求质量情况。对于后续测试同学更需要去了解需求的一些约定与风险。

策划案逻辑流程图：本章不细节描述，详细见：让测试过程图表化

4、需求评审流程。

接收到案子--》组织需求评审会议--》输出需求评审报告--》策划更新案子同步各方--》对策划案质量进行打分--》QA组内评审。

前几个模块在前面都已经有所提及，这里不赘述了。主要提一下对策划质量进行打分这个环节。如果只是不断去做某个环节的检查和反馈问题，而对上游没有任何的改进和推进，是很被动的做法。在需求评审了一段时间发现策划案的质量永远存在很多问题的时候，我就萌生了能不能对策划案进行打分去反向促进的想法，这个想法当时也只是一闪而过没有去落地。一年多以后由另外一个组处发起了。打分表更加注重的是策划案的质量。后来在我们两个团队的融合下终于形成了现在一表在手，需求我有的一个局面。（这里纯属吹牛）

在需求评审的过程中，有一个不可忽视的问题，需求在不断地因为各种问题而迭代，这种迭代信息如何能够每次都快速的同步到各方干系人手里是一个值得思考的问题。

QA组内评审。这个环节可以根据情况进行，这个环节QA将自己作为介绍案子的角色，相互之间进行评审，同时也便于将一个大版本之前不同案子之间的联系关联起来。

5、需求评审检查表与报告。

检查元素：

需求角度

1、原始需求

结合原始需求评估该案子的可行性以及与原始需求是否符合。

真正的需求评审应该是QA也能够对产品的发展方向需求的合理有能力去评估。但是目前由于水平限制，我们把更多的重心放在了需求的检查上。

在真正的需求评审过程中，我们需要将策划案与原始需求的吻合度做个匹配。因为在项目中有出现过策划案与原始需求出现偏离的案例（捂脸）。

举个栗子：

    之前在做一个项目的时候，原始需求方提出需要提供一款产品给学生作为考试工具，很粗略的体验了我们的产品后说认为现在产品的总体的功能就可以，那么策划方就提了一个很简单的策划案：现有的功能支持离线使用，并提高质量。

    但是在实际开发的过程中，原始需求陆续提来要求，需要也支持在线模式给学生进行试用和适应，以及现在产品不支持xxx功能需要进行支持。而此时产品已经修复了某些bug进入了测试阶段，这个时候再来不断的增加需求，耗费了非常大的成本。

所以在这个环节我们需要注意的时候策划方有没有和原始需求方进行充分的沟通，原始需求方会在什么样的场景需求下使用我们的产品，是否有潜在需求被遗漏。

2、了解目标用户

辅助评估可能达到的用户量，分析用户行为。这一个环节给我们后续进行测试能够起到很大的指导作用

假设我们是要开发一个产品推向市场，根据现有的销售渠道目标支持用户是30w，再设计测试的时候就需要去考虑对应的性能测试。又或者我们的目标用户是某些年轻的群体，某些地区的群体，那么我们可以通过分析这些群体使用机型占比来考虑适配测试的优先级等等。

3、竞品分析

可以通过竞品分析了解细节，提出优化建议。

比如说我们在做一个链接收藏的功能的时候觉得现有的设计并不好用或者不好实现，例如如何爬取网络标题信息，如果没有标题信息怎么展示比较美观，如何管理大量的链接。由于我们不是专业的设计人员，我们可以去参考一些竞品，例如QQ来对比我们和对方方案的优劣。

4、情景分析

结合情景分析，覆盖用户场景用例，用户可能在什么场景下使用这些功能等等。

举个栗子：

还是上文的那个案例，我们的工具是提供给学生进行考试的，那么这个考试具备着特殊的地点、操作和持续时长，我们在设计测试场景的时候就会着重考虑系统的适配、特定的操作用例和稳定性测试

功能角度

1、运行环境的兼容。

考虑这个功能在各个平台的兼容差异，提醒策划做出需求方面的制定。

2、版本的向下兼容。

功能兼容：

1、新增功能在旧版本上是否会有展现与不兼容。  

数据兼容：

2、新的数据类型在旧版本上是否能够展示。  例如我们新增了一种微博类型，发布后在旧版本上能否正确展示 

3、旧版本的新/旧数据是否对新版本造成影响。 新版本出了一个被点赞三次即可获得奖励的功能，那么其他用户在旧版本上点赞是否可以触发相应的奖励给予。

兼容性的评估是我们在前期需求评审的时候就要去考虑的一个要素，如果新功能的推出势必会带来兼容问题，那么我们在版本发布是时候才发现久无法做好足够的应对。

3、版本的向后兼容

评估是否兼容未来的版本。这个部分我们需要去考虑未来产品的发展是否可能会对现在的功能产生兼容影响，这一点可能比较难理解，这里举个例子。

之前有设计了一个功能，通过配置cmp地址就可以跳转到指定的界面。那么这个时候需要去考虑我们未来增加了功能模块的cmp地址在现在的版本不存在需要如何响应。

4、功能完整性

哪里来？经过怎样的处理？到哪里去？这里可以通过梳理业务流程图来确认功能是否存在重大逻辑缺失。

例如这样一个需求案。

第一部分描述了用户上传资源

第二个部分描述了审核通过的资源展示在平台上

缺失了审核部分的需求描述。

5、功能交叉性

对已有功能的影响。评估新增功能是否改动到已有功能、评估可能影响的模块。具体可以考虑是否有重复的操作区域，是否有数据上的交互。

6、需求交叉性

新需求与新需求是否交叉，例如多个案子之间有协作依赖关系。

新需求与旧规则是否交叉，例如历史规则在这个版本得到变更。

QA角度评审

1、用户体验

交互是否符合用户操作习惯，是否简单好上手

是否对于错误或者异常有友好提示、操作保护、数据说明

是否有管理后台可操作配置

2、测试预期标准

服务端性能标准，安全标准，需要适配的设备，是否国际化

3、开发需求

设计方案在开发实现上的局限

例如策划希望可以达成某个效果，开发反馈在架构上不支持，需要巨大的开发量，性价比不高，这种时候也许我们需要考虑折中的方案。

4、前期风险评估

前期暴露出来的未来的测试风险、版本进度风险等等。

5、后期测试注意事项

需要把这个时期获得的一些信息与注意事项向后面的环节传递

打分元素

1、功能设计案的全面性

2、需求明确性、准确性

3、示意图的参考性是否准确

4、功能交叉性是否考虑完善

。。。。。。

由于这部分原创不是我所以只展示部分重要的点。