情景2：测试同学小C拿到需求文档后，对需求文档进行分析和总结后，静待产品开需求讨论会。当需求讨论会提出自己的问题时，大家对个别case结论讨论了较长时间……..

为了让项目高效运行，我们今天就针对需求评审阶段，梳理一下测试到底都要做哪些事情？

• 明确产品方向、基本功能、用户需求
• 分析需求合理性，提前发现问题，避免后期过多的需求变更或实现变更
•  产品、开发、测试三方对需求理解保持一致

• 项目负责人拆分需求模块，分配对应的模块负责人，产出模块&负责人对应表

目的：若需求模块较多，可以有效防止需求跟进遗漏

• 模块负责人进行需求了解、分析

       如何进行需求评审？想了解方法、技巧，文章末尾有干货链接哦~~~

•  模块负责人整理需求疑问、建议等，若时间允许，提前发送邮件或口头与产品进行确认

需要产出的内容：

•  模块及对应负责人列表
•  需求了解完毕后的疑问、建议、问题等文档或邮件

• 在产品进行需求讲解过程中，积极提出自己的需求疑问、需求建议、想法、观点
• 记录评审会议过程中内容

① 需求讨论后，给出的结论性内容

② 需求变更内容

③ 技术无法实现的内容

④ 后续需要跟进的todo事项

⑤ 需求逻辑产生的风险备忘

⑥ 对应问题的开发&测试负责人

• 评估是否需要进行下次需求会议讨论，并进行确认如果会议中未确定的问题较多或较严重，影响到后续开发实现，需要在会议结尾和开发、产品确认是否需要进行下次会议

需要产出的内容：

• 需求评审会议记录

• 由项目负责人或模块负责人，统一将会议记录的内容分类整理后，邮件公示给项目中的开发、产品、测试，以作后期备忘和跟进

• 邮件发出后，测试模块负责人需要及时推进问题的反馈，提醒开发或产品给出结论
• 需求问题确定后，提醒产品更新需求文档至对应的目录，一般是svn

需要产出的内容：

• 需求评审会议记录

邮件模板如下：

需求了解要做什么？

需求文档规范