一、与实际项目设立有关的事项
介绍项目情况、当前项目阶段情况、项目市场预测和项目时间讨论。
情况:参与部门，主要负责人，部门只需要职责，后期主要工作内容。
与项目相关的文件:指导文件、技术文件、项目介绍文件等。
项目的里程碑:开发开始和结束时间，测试开始和结束时间，发布时间，可能还有详细的分期时间等。
二、小程序项目立项会议
项目介绍:项目介绍文件。
测试团队人员介绍:开发人力，多少，测试人力。
测试团队模块分配:模块被分配给人员。
测试团队准备测试相关事宜:工具准备、设备准备、人员招聘等。
三、项目规则
根据不同的项目制定不同的规则，如:
1.邮箱配置:方便工作中与不同部门、同事沟通，做好记录。
2.如何处理项目中遇到的问题，比如找什么部门，负责人介绍，相关人员联系方式制定。
3.项目中的时间安排。
4.电子邮件使用规则:注意事项、标题、休假、附件订单等规则。
四、项目测试团队此时的任务
准备测试相关的设备、工具和人力安排；
产品出来后熟悉系统，比如画功能模块图。如果没有出来，研究项目相关的文档，比如项目介绍；
完成项目建立中的相关任务，如邮箱配置，确认邮箱可以正常使用，包括显示名称和发件人名称设置。
一、与实践中的项目评价有关的事项
1.评审概念
需求评审是对产品需求文件的评审。需求文档是根据用户的需求抽象提炼成产品需求，对于我们的技术人员来说也是一个相对直观的需求文档。通过这个文档，技术人员可以知道用户想要什么样的产品，它是用户和技术人员之间的桥梁，所以它的审查非常重要。
按照标准流程，项目中提交的任何文件都要经过审核，但在实际工作中，有些文件会不经过审核直接使用，在使用中会进行修改、更新和维护。
评审采用的方法一般是同行评审。
2.审查目标
首先，产品需求文档能够全面清晰地描述产品的功能和性能；
第二，项目组成员对用户需求有相同的理解；
第三，形成可以指导研发的最终文件，后续工作要在此文件的基础上进行。
3.评审流程
4.审查的对象包括：
概念:产品需求规格。
阶段:系统计划和项目计划。
验证阶段:系统测试计划、系统测试方案和系统测试用例。
发布阶段:安装文档和使用文档
5.审查中的原则:
预审期间应使用检查表，以避免发现缺陷和不知道记录在哪里。
避免过度依赖清单。
评审会议以2小时为限，避免长时间讨论偏离评审会议主题。
评论的对象是产品，而不是制作人(作者)，所以要避免对作者本人的人身攻击。
“磨刀不误砍柴”，需要给陪审员提供足够的预审时间，一般提前两天比较好。
如果一些与会者没有准备好，会议将被推迟；如果有人真的抽不出时间，重新安排/取消复习。
二、小程序项目需求评审
因为小程序提供的需求文档没有提供太多内容，所以只审查提供的需求。
采用审前机制。首先发布需求文档，测试人员研究并填写评审表。
召开评审会议，对提交的问题进行确认和反馈，包括:检查提交的内容是否规范、正确，是否属于需求文件的问题，以及产品或作者提交后应做的相应处理。
之后，安排进一步的系统熟悉:
·无产品时，根据需求单，细化模块和功能点。
· 当有产品或需求单时，两者结合提炼模块和功能点。
· 当没有需求文档和产品时，根据产品实施细化模块和功能点。
三、与需求评估相关的面试问题
什么是需求评审？
为什么需要进行需求评审？
需求评审的参与者？
一个好的需求文档的特征是什么？
贵公司的需求评估活动是如何开展的？
复习中需要注意什么？
这次复习活动从开始到结束有没有遇到什么问题？怎么解决？
如何提高评估效率？
在快速迭代的今天，如何维护需求文档？
你在评审中有没有提出什么有效的建议？这是什么？
进行了多少次需求审查？
需求文档有几个版本？
四、测试团队此时的任务
· 继续测试相关设备
· 熟悉测试相关技术，如界面、自动化、工具使用。
· 评审需求并确认需求。
· 根据需求文档，熟悉系统，细化功能模块图和功能点，再细化到测试点。
注意:在这个阶段，测试团队的任务主要是熟悉系统，越熟悉越好被例会覆盖。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
