验收测试流程.doc

验收测试流程 一．验收测试流程图 前期测试沟通 前期测试沟通 项目组发起测试申请 测试准备工作 冒烟测试 是否通过？ 系统测试 回归测试 发送测试报告 是 否 是 是否通过？ 否 测试结束？ 否 是 开服测试 是否打回？ 是 否 是否打回？ 否 是 二.测试流程简要说明 1.测试流程说明 （1）项目组与测试负责人沟通确认测试时间 （2）项目接口人发起测试申请，申请通过后进入测试准备阶段 （3）测试准备阶段，测试部门编写测试用例，准备测试账号，准备完毕进入冒烟测试阶段 （4）冒烟测试通过，进入系统测试。 测试版本仅少量严重程度低的bug未修改引起的不通过，反馈项目组，通知延长冒烟测试时间； 测试版本符合冒烟测试打回标准，冒烟测试不通过，直接打回，结束测试。待游戏测试完成度满足冒烟测试开始条件，重新发起测试申请。 （5）系统测试通过，进入回归测试。 测试版本仅少量bug未修改引起的不通过，反馈项目组，通知延长系统测试时间； 测试版本符合系统测试打回标准，系统测试不通过，直接打回，结束测试。待游戏测试完成度满足系统测试开始条件，重新发起测试申请。 （6）回归测试通过，测试正常结束。 回归测试不通过，时间允许的情况，项目组沟通确认延长系统测试时间； 如果无法延长测试时间，项目时间耗尽，发布时间临近或项目取消，则异常结束。 （7）测试结束，测试部门发送测试报告；运营提供签署ReleaseReadiness文档。 （8）产品发布前期，运营邮件申请进行开服测试。 2.测试通过打回标准 2.1冒烟测试 （1）通过标准：bugfree剩余严重程度为2以上的bug的数量为0 （2）打回标准：bugfree剩余严重程度为2以上的bug的数量3-5，根据产品不同，数量暂定 2.2系统测试 （1）通过标准：bugfree剩余严重程度为3以上的bug的数量为0 （2）打回标准：bugfree不存在严重程度为2以上的bug，严重程度为3的bug数量8-10，根据产品不同，数量暂定 2.2回归测试 （1）通过标准：bugfree不存在严重程度为3的bug，剩余严重程度为4以上的bug的数量小于8 三.测试阶段输出 阶段 测试部 协作部门 　 输出 负责人 输出 负责人 发起阶段 测试计划 测试负责人 测试版本产品说明书最新策划文档最新数据文档辅助测试工具测试申请邮件 项目接口人 测试准备 测试用例测试账号 测试负责人 稳定的测试服务器有效的测试工具 项目接口人 测试执行 进度汇报邮件测试结果 测试负责人 测试环境搭建配合 研发负责人 测试结束 测试报告 测试负责人 ReleaseReadiness文档 运营接口人 开服测试 测试结果反馈邮件 测试负责人 测试申请邮件测试账号 运营接口人 四．测试流程分解 1.测试发起 1．1时间确认 （1）项目组与测试接口人初步沟通，提供项目资料，说明测试内容，测试深度，需要覆盖的浏览器。 （2）测试负责人根据项目资料和测试内容，制定测试计划，预估测试时间。测试时间包含：冒烟测试，系统测试，回归测试（仅包含测试时间，debug时间由项目组预估）。 （3）项目组与测试部门共同协商，确定测试最终起止时间。 a.项目组给定测试时间充足，最终测试时间以测试计划为准 b.项目组给定测试时间紧张，测试时间无法协调，由测试负责人根据给定测试时间，提出测试存在的风险，与项目组确认削减部分测试内容，降低测试深度，重新制定测试计划。 1．2发起方式 （1）各个项目负责人以邮件方式发起测试需求。 （2）经领导或相关人员邮件审批通过后，测试工作正式发起成功。 （3）发起时间距离开始测试时间不应少于两周。 1．3发起内容 需求方邮件提供测试相关细节信息，内容如下： （1）测试内容版本 （2）测试起止时间 包含：冒烟测试，系统测试，回归测试，研发debug各阶段的起至时间） （3）目标测试服务器 （4）测试要点需求 （5）测试浏览器 （6）最新需求资料 （7）进度推进人和项目接口人 1．4需求资料 （1）当前测试版本的产品说明书，所有测试模块的最新策划文档、数据文档、辅助测试工具。 （2）需求资料尽量早（提前两周）的发送到测试部门，进行前期的测试用例编写工作。文档资料发送时间和测试开始时间重合，测试过程可能无测试用例辅助，测试的有效执行时间将大幅降低。 2．测试流程 2．1测试准备 （1）开始条件 策划文档开发完毕；（时间在冒烟开始之前） （2）准备内容 测试用例编写； 测试账号申请 2．2测试执行 测试执行分为冒烟测试，系统测试，回归测试三个阶段。 达到开始条件，才能开启当前测试阶段，上一个测试阶段正常结束，才能进入下一个测试阶段。 2．2．1 冒烟测试 （1）开始条件 当前游戏版本所有功能模块研发完毕； 服