一、与实际项目设立有关的事项

介绍项目情况、当前项目阶段情况、项目市场预测和项目时间讨论。

资源:需要人力、物力、技术、工具、常用的开发语言、工具、测试工具、系统运行需要的工具。

情况:参与部门，主要负责人，部门只需要职责，后期主要工作内容。

与项目相关的文件:指导文件、技术文件、项目介绍文件等。

项目的里程碑:开发开始和结束时间，测试开始和结束时间，发布时间，可能还有详细的分期时间等。

二、小程序项目立项会议

项目介绍:项目介绍文件。

测试团队人员介绍:开发人力，多少，测试人力。

测试团队模块分配:模块被分配给人员。

测试团队准备测试相关事宜:工具准备、设备准备、人员招聘等。

三、项目规则

根据不同的项目制定不同的规则，如:

1.邮箱配置:方便工作中与不同部门、同事沟通，做好记录。

2.如何处理项目中遇到的问题，比如找什么部门，负责人介绍，相关人员联系方式制定。

3.项目中的时间安排。

4.电子邮件使用规则:注意事项、标题、休假、附件订单等规则。

四、项目测试团队此时的任务

准备测试相关的设备、工具和人力安排；

产品出来后熟悉系统，比如画功能模块图。如果没有出来，研究项目相关的文档，比如项目介绍；

完成项目建立中的相关任务，如邮箱配置，确认邮箱可以正常使用，包括显示名称和发件人名称设置。

一、与实践中的项目评价有关的事项

1.评审概念

需求评审是对产品需求文件的评审。需求文档是根据用户的需求抽象提炼成产品需求，对于我们的技术人员来说也是一个相对直观的需求文档。通过这个文档，技术人员可以知道用户想要什么样的产品，它是用户和技术人员之间的桥梁，所以它的审查非常重要。

按照标准流程，项目中提交的任何文件都要经过审核，但在实际工作中，有些文件会不经过审核直接使用，在使用中会进行修改、更新和维护。

评审采用的方法一般是同行评审。

2.审查目标

首先，产品需求文档能够全面清晰地描述产品的功能和性能；

第二，项目组成员对用户需求有相同的理解；

第三，形成可以指导研发的最终文件，后续工作要在此文件的基础上进行。

3.评审流程

4.审查的对象包括：

概念:产品需求规格。

阶段:系统计划和项目计划。

开发阶段:详细设计、单元测试用例(方案)、集成测试用例(方案)、代码、数据库脚本等。一般来说，在编码之前，应该进行详细的设计评审，以确保程序的正确性，减少后续修改带来的不利影响。

验证阶段:系统测试计划、系统测试方案和系统测试用例。

发布阶段:安装文档和使用文档

5.审查中的原则:

预审期间应使用检查表，以避免发现缺陷和不知道记录在哪里。

避免过度依赖清单。

评审会议以2小时为限，避免长时间讨论偏离评审会议主题。

评论的对象是产品，而不是制作人(作者)，所以要避免对作者本人的人身攻击。

“磨刀不误砍柴”，需要给陪审员提供足够的预审时间，一般提前两天比较好。

如果一些与会者没有准备好，会议将被推迟；如果有人真的抽不出时间，重新安排/取消复习。

二、小程序项目需求评审

因为小程序提供的需求文档没有提供太多内容，所以只审查提供的需求。

采用审前机制。首先发布需求文档，测试人员研究并填写评审表。

召开评审会议，对提交的问题进行确认和反馈，包括:检查提交的内容是否规范、正确，是否属于需求文件的问题，以及产品或作者提交后应做的相应处理。

之后，安排进一步的系统熟悉:

·无产品时，根据需求单，细化模块和功能点。

· 当有产品或需求单时，两者结合提炼模块和功能点。

· 当没有需求文档和产品时，根据产品实施细化模块和功能点。

三、与需求评估相关的面试问题

什么是需求评审？

为什么需要进行需求评审？

需求评审的参与者？

一个好的需求文档的特征是什么？

贵公司的需求评估活动是如何开展的？

复习中需要注意什么？

这次复习活动从开始到结束有没有遇到什么问题？怎么解决？

如何提高评估效率？

在快速迭代的今天，如何维护需求文档？

你在评审中有没有提出什么有效的建议？这是什么？

进行了多少次需求审查？

需求文档有几个版本？

四、测试团队此时的任务

· 继续测试相关设备

· 熟悉测试相关技术，如界面、自动化、工具使用。

· 评审需求并确认需求。

· 根据需求文档，熟悉系统，细化功能模块图和功能点，再细化到测试点。

注意:在这个阶段，测试团队的任务主要是熟悉系统，越熟悉越好被例会覆盖。