【落叶313】告诉你如何从执行测试到管理测试（7）

文/秋之川

【目录】

这是《落叶》文集里第 313 片落叶，希望你能喜欢，不为别的，只为这份坚持。

第七章 天哪，我怎么可能了解所有的需求？（下）

我经历了什么

我带着下面几个问题回到了座位上，开始找资料。

1. 需求评审的意义是什么？
2. 需求评审的作用有哪些？
3. 什么样的需求评审才有作用？
4. 怎么样才能让需求评审发挥作用？

老大说，只有知道了需求评审是什么？为什么要做需求评审？你才能真正理解需求评审里要做的那些事情的意义何在。

我的理解：

1. 需求评审的意义和作用我觉得都是：让设计、开发和测试跟产品经理在对需求的理解上，是站在同一个层面上的，从而减少实现过程中的差异，降低后期返工的成本。
2. 我觉得能真正起作用的评审，现场应该是有条不紊的介绍和提问，现场解答应无疑义和无异议，所有问题都需要记录在案，会后持续跟进更新；
3. 要求产品经理前一定时间量将需求文档发出来，参加会议的设计、开发和测试等相关的与会人提前仔细阅读，带着问题参加评审会议；

需求评审

是由一组评审者按照规范的步骤对产品需求（需求文档和产品原型）进行仔细地检查，以找出和消除其中的缺陷。需求评审为新手提供产品功能需求的培训途经，后备和后续的相关人员（设计、开发、测试等）也可以通过正规需求评审熟悉产品需求。
评审小组至少由3人组成（包括被审材料作者，即产品经理），一般根据评审阶段不同，参与人数不同。通常，需求文档的初评需要较少评审人员（设计、开发、测试的项目负责人参加即可），需求定稿的详细评审，需要较多的评审人员（设计、开发、测试的具体负责人也需要参加）。

我收获了什么

按自己的理解给出了那些问题的答案，并重新认识和了解了一下什么是需求评审之后，我发现，当我站在测试项目负责人的角度去看待需求评审时，有一些不一样的收获：

作为需求的测试责任人，我在阅读需求时：

因为要基于需求梳理测试点和设计测试用例，所以我们要找出需求中的缺陷：

1. 错误的地方；
2. 不合理的地方；
3. 描述不清晰的地方；
4. 有歧义的地方；

作为测试的项目负责人，我在阅读需求时：

因为我是整个项目的测试负责人，所以我不能再着眼于某一个需求：

1. 要将关注的视角提到上一个层级，以前是着眼于某个点的分析，得延展成某个面的分析；
2. 要判断每个需求之间是否有冲突、依赖和调用等关联关系；
3. 要从需求的应用场景去判断是否该需求有性能测试的需要；
4. 要从需求的应用场景去判断是否该需求有安全测试的需要；
5. 要从需求的应用场景去判断是否该需求有兼容性测试的需要，包括历史数据兼容和功能兼容；

《告诉你如何从执行测试到管理测试》带你迈出第（7）步！，点击这里可查看完整地图

作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵

【目录】