验收测试流程.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.测试发起11时间确认（1）项目组与测试接口人初步沟通，提供项目资料，说明测试内容，测试深度，需要覆盖的浏览器。（2）测试负责人根据项目资料和测试内容，制定测试计划，预估测试时间。测试时间包含：冒烟测试，系统测试，回归测试（仅包含测试时间，debug时间由项目组预估）。（3）项目组与测试部门共同协商，确定测试最终起止时间。a.项目组给定测试时间充足，最终测试时间以测试计划为准b.项目组给定测试时间紧张，测试时间无法协调，由测试负责人根据给定测试时间，提出测试存在的风险，与项目组确认削减部分测试内容，降低测试深度，重新制定测试计划。12发起方式（1）各个项目负责人以邮件方式发起测试需求。（2）经领导或相关人员邮件审批通过后，测试工作正式发起成功。（3）发起时间距离开始测试时间不应少于两周。13发起内容需求方邮件提供测试相关细节信息，内容如下：（1）测试内容版本（2）测试起止时间包含：冒烟测试，系统测试，回归测试，研发debug各阶段的起至时间）（3）目标测试服务器（4）测试要点需求（5）测试浏览器（6）最新需求资料（7）进度推进人和项目接口人14需求资料（1）当前测试版本的产品说明书，所有测试模块的最新策划文档、数据文档、辅助测试工具。（2）需求资料尽量早（提前两周）的发送到测试部门，进行前期的测试用例编写工作。文档资料发送时间和测试开始时间重合，测试过程可能无测试用例辅助，测试的有效执行时间将大幅降低。2测试流程21测试准备（1）开始条件 策划文档开发完毕；（时间在冒烟开始之前）（2）准备内容 测试用例编写；测试账号申请22测试执行测试执行分为冒烟测试，系统测试，回归测试三个阶段。达到开始条件，才能开启当前测试阶段，上一个测试阶段正常结束，才能进入下一个测试阶段。221 冒烟测试（1）开始条件当前游戏版本所有功能模块研发完毕；服务器环境稳定；测试工具建立完成。（2）测试策略验证测试工具可用；验证所有模块和功能点研发完全；各模块基本正向流程可走通，功能可用；（3）结束条件正常结束：各个模块，没有影响进一步细致测试的BUG遗留异常结束：达不到正常结束的条件，冒烟测试结束时间和系统测试开始时间后延222系统测试（1）开始条件系统测试开始时间点，冒烟测试阶段，影响各个模块进一步测试的BUG解决验证完毕（2）测试策略对各个功能模块进行正向，逆向和特殊操作等的详细测试，测试过程参照测试用例和策划文档。（3）结束条件测试覆盖所有需求模块功能点，包含正向与逆向测试流程；测试阶段发现的所有问题，全部提交BUG223回归测试（1）开始条件正常开始：回归测试开始时间点，系统测试阶段的bug解决验证完毕。异常开始：回归测试开始时间点，系统测试阶段的bug未解决验证完毕；如果时间紧，与项目组沟通确认，可有少量低严重级别bug遗留（2）测试策略回归测试一般分为一次回归测试、二次回归测试，视项目情况可以合并为只有一次回归测试，根据项目组的要求进行。对系统测试的进一步验证及补充。对各个功能模块再次进行测试，重点是正向流程功能测试和覆盖系统测试中未测试到的分支功能点。回归测试对系统测试出错的功能点，重点测试，出错模块的修改可能会引起各种新问题。（3）结束条件所有模块功能及界面测试覆盖到。产品问题尽可能发现完毕。23测试沟通231进度汇报（1）初始版本的项目，每日测试工作完毕，邮件汇报进度（非初始版本可阶段性汇报）。汇报内容包括：当日测试内容概述，bug情况，测试中的重大缺陷。（2）测试负责人日报，周报中汇报测试进度和阻碍测试的问题。项目推进人根据每日进度汇报，调整优先级，推进解决问题。232实时沟通（1）测试过程中重大阻碍测试进度事宜，重大缺陷及时和接口人或者项目负责人，项目经理沟通协调。（2）服务器拓机等引起整个测试团队15分钟以上无法工作，邮件发送项目接口人推进解决。233里程碑确认（1）里程碑I：系统测试完成，根据系统测试的整体情况，由项目经理、研发经理进行确认，目标测试项版本是否正常开始回归测试。（2）里程碑II：里程碑I结束后，第一次回归测试开始前的期间请各位项目负责人、项目经理合理预估，避免修复时间过于乐观压缩回归测试时间，甚至延后项目整体结束时间。（3）里程碑III：回归测试结束后，测试负责人提供测试报告供各位项目负责人、制作人等相关人员进行版本评估判定，目标版本质量是否必要开始第二次回归测试或者版本完成测试对外发布。234需求变更（1）测试过程中，因策划文档调整，新增的工作量，测试负责人评估测试时间，由项目经理、研发经理进行确认，目标测试版本调整测试策略或延长测试时间。（2）测试过程中，新增测试需求引起新增的工作量，测试负责人评估测试时间，由项目经理、研发经理进行确认，目标测试项版本调整测试策略或延长测试时间或需求内容延迟上线。24接口配合（1）测试过程中尽量保证测试服务器的稳定和正常，不建议测试服务器和研发调试服务器混用。（2）优先更新解决阻碍整体测试工作执行的缺陷。（3）为保证测试结果严谨有效不建议测试中途频繁停机更新维护，而推荐第一轮功能测试完成后，开始第一次回归测试前统一更新维护，以上工作的监督协调由项目接口人把控。（4）需要研发配合才能执行的测试用例，项目组能积极配合，不造成测试停滞和测试时间的虚耗。3测试结束31结束标准（1）测试时间耗尽测试申请中，测试终止时间到达，测试部门分配的项目测试人力下阶段需要处理其他项目的测试工作。测试工作扫尾，保持3工作日0.25人力的追踪工作。（2）发布时间临近测试过程中测试结束时间调整，和预期产品发布时间重合。测试工作被迫结束，测试工作扫尾，保持3工作日0.25人力的追踪工作。（3）项目临时取消测试版本内容完整程度以及成熟度严重低于预期，产品本身或者其他特殊情况，经项目负责人、制作人或者其他领导裁定后，目前版本不适合测试介入。目前测试工作被迫结束，等待下次测试工作发起。下次测试工作的发起，重新走测试发起流程。（4）产品测试完成参考软件测试退出标准。对于非严格系统模块可以采用“基于测试用例”的准则。同时满足以下条件允许结束测试：功能性测试用例通过率达到100；非功能性测试用例通过率达到90时。32测试报告（1）发送时间测试对象宣告结束，项目对外发布前（2）报告内容a. 版本现状b. 测试时间和人力c. 测试覆盖d bug情况e. 风险预估f. 问题和建议总结测试过程和分析测试结果，确定该版本功能的实现是否符合策划的需求，质量是否达到了可更新的程度，给予项目组和相关领导作为参考，对于项目的质量有直观的认识。5开服测试根据项目要求，在测试结束之后，产品对外发布之前，进行开服测试。（1）测试发起 由运营部门接口人以邮件方式发起测试需求，需求中包含服务器信息，配置文档，测试时间，测试账号。（2）开始条件回