学习过测试理论的同学肯定都知道，测试人员参与项目的第一步，大部分都是需求评审，但是不少测试同学反馈，自己很少参与需求评审，需求会议也很少喊测试人员参与。

我觉得这一方面可能是流程上各角色配合的问题，另一方面可能是因为测试在评审过程中没有体现出参与的价值。

针对第一个可能，需要测试主动找产品沟通，一方面表达希望参与需求评审的意愿，另一方面也要求他们在需求评审时喊上测试。

针对第二个可能，就需要测试人员从自身上做改进了，为什么这么说呢？我曾经参加过几次需求评审会议，就发现产品在那讲需求，开发偶尔会提一些技术实现上的细节问题，测试就只是在那听了，会议结束后，回去该干嘛干嘛，既然我们测试参与需求评审时不能产生什么价值，那产品怎么能在评审的时候想起来喊我们呢？

终于到了今天我们要说的主题了，作为测试，参与需求评审时我们可以贡献什么价值？下面我说下我的观点。

1.需求评审的作用

回答上面的问题前，我们先看看需求评审到底是干嘛的？先不管书上怎么说，从我的经验看，需求评审就两个作用：

1.同步产品对于需求的详细设计
2.收集大家对于需求的各种反馈

对于需求设计，肯定是产品发起并负责的了，那么作为测试人员参与需求评审，着重点就在于第二点，关于需求的反馈上面了。

2.需求评审的形式

最开始我提到有同学说没有参与过需求评审，有部分是面试的同学说的，但是详细问过之后，才知道他说的是形式的问题。

比如他理解的需求评审就是大家一起弄个会议室，产品讲需求，开发和测试怼产品这样的，而实际情况是，产品把需求往群里一扔，大家就七嘴八舌的讨论开了，又或者产品直接跑过来，在开发和测试的工位上当面沟通一下就算完事了，恩，我说这也算需求评审呀，形式不重要，重要的是做这事的目的和效果。

3.测试是否需要参与需求评审

废话，必须十分完全有必要呀，仅仅从同步需求设计的角度看，当面的同步一下需求，肯定比文字上的传达效果要好的多了，而最重要的其实还是测试在需求评审中提出的反馈，才是最宝贵的，所以下面我就主要说说测试对于需求反馈的价值主要都体现在哪些方面。

4.需求评审之需求合理性

需求合理性，这是开发和测试怂产品最多的地方之一。

弹这么大个框，太打搅用户了吧？我建议缩小二分之一。
卸载个软件，还要确认这么多次，用户该烦了吧？我建议点击卸载按钮就完事。
首页内容已经很多了，再加一个会有效果么？是不是再精简点内容比较好？我建议一屏不超过 5 条内容。
这操作流程有点反人类呀，交互咋设计的呀？我建议主要操作一步即达，次要的三步以内完成。

恩，虽然最后拍板可能还是产品是说了算，但是作为种子用户，该提意见还是要提的，特别是有些地方其实产品也没有定论，这时候的意见非常有可能会被采纳，如果建议被采纳的次数多了，自己的建议就会更受大家重视，那么话语权也就会相应的有提升了。

然而，很多人其实是不会反驳需求合理性的，大不了就内心里吐吐槽「这么脑残的设计，亏的能想出来」，也许这是和公司环境有关系，但是如果自己真的有什么好的建议，还是建议找机会提出来，毕竟咱们是测试嘛，用户体验的质量也是质量范畴内的事噢。

5.需求评审之需求全面性

前面说的需求合理性，需要我们站在用户的角度去考虑问题，不是所有人都能做到，这也情有可原，但是需求全面性这个确实是需求评审中必须要考虑的问题啦，这个不仅仅针对产品设计，也包括开发实现逻辑。

如果用户登录超时了，产品怎么展现？
如果用户输入了非规定范围内的数据，逻辑上是否做了异常处理，怎么告知用户？
如果用户长时间不关机，逻辑上是否有问题，如何处理？
如果多用户同时登录，会出现啥问题？
如果系统休眠后恢复，产品如何处理？

针对这部分内容，大多是对于使用场景的覆盖，很多产品考虑需求时，只覆盖了常规用户的主要操作分支，而异常情况考虑的比较少，对于测试来说，异常场景的考虑正是我们的长处，所以在需求评审阶段尽可能多的和产品确认各种异常场景的处理，可以极大的避免在测试过程中出现问题后被返工的情况。

好了，罗罗嗦嗦说了这么多，希望对大家有帮助，有任何有疑问的地方，欢迎留言沟通。