质量部版本测试流程 V14.docx

版本1.4部版本测试流程质量部版本测试流程撰 写 人：质量部完 成 日 期：文档使用部门：研发人员 产品人员客户（市场） 维护人员 用户批准人 ：批准日 期：版本更新历史版本版本更新日期作者版本更新原因目录一、范围4二、定义41、流程定义42、角色定义4三、版本转测流程51、版本转测前52、版本转测条件5四、版本打回流程61、版本打回条件6五、版本发布流程6六、监督机制61、监督前提62、监督机制7一、 范围本文档对版本的转测、打回、发布流程的进行说明，同时作为质量部日常工作的指引文档之一，同时对研发移交测试版本做出一定约束。适用人员范围：开发人员、测试人员二、 定义1、流程定义测试流程包括三个部分：版本转测、版本打回、版本发布；2、角色定义测试流程主要设计三类角色：开发、测试、服务支撑；三、版本转测流程1、版本转测前1) 一般情况下，开发人员需要在接收到开发任务时与对应的测试人员提前沟通计划时间，进行二次确认，确保测试人员可以有效的制定测试计划。2、版本转测条件1) 必须同时将测试版本、版本升级说明（如果涉及到数据库变更需要提交建表脚本和数据字典）、送测单提交到04-developlib05-测试1-可执行程序、2-源代码、3-项目文档目录下，否则不允许转测。2) 必须通过邮件分别将需求、修改说明或实现机制、svn地址、测试点发送给测试人员，否则不允许转测；同时SVN版本记录必须清晰明确。四、版本打回流程1、版本打回条件Ø 开发实际的功能与需求不一致：需要测试人员与项目经理、服务支撑人员或产品人员对需求进行二次确认，如果确实存在不一致的情况，版本将打回；Ø 开发实际的功能不完整或部分功能点未完全实现；Ø 程序无法正常启动、程序启动异常退出、页面报错 ；在测试过程中出现以上情况时，测试人员将会以邮件形式将版本打回给开发人员，同时抄送项目经理，待开发人员修改问题后再次提交测试。五、版本发布流程1、 测试人员通过邮件将测试报告发送给开发人员、抄送给项目经理、测试经理及相关人员2、 测试人员将发布版本、升级说明提交到03-productlib02-发布目录中，并标明日期，同时填写发布记录。如有特殊原因等网络问题等个例，需要测试人员与服务支撑人员确认程序获取方式。3、 测试人员通过邮件将发布版本、升级说明的保存路径发送给服务支撑人员、抄送给开发人员、项目经理、测试经理，4、 版本和代码等相关测试文档上传受控库，并有对应发布记录文档进行记录版本和代码的对应关系。六、监督机制为了提高的各个部门对该制度的执行力，制定以下监督机制确保规范制度的执行。1、监督前提1.1 服务支撑部助理、产品中心项目管理员、质量部QA需要项目信息同步；1.2 服务支撑部及时反馈上线计划、上线情况反馈；2、监督机制提供两种机制意见，需要与其他部门商议确定方式一：由质量部QA每周对本周项目进行版本发布和版本打回的数据统计并输出结果。由质量部直接对人员就行考核方式二：由QA直接把数据反馈给对应部门，对应人员的考核将由该部门负责。监督环节监督要求处罚措施1.版本提交开发人员提交测试时需要按照版本测试流程中规定进行版本提交，否则视为违规违反一次将邮件部门级通报批评（如产品中心、质量部、服务支撑部），邮件对象部门全体、其他项目组内人员再次违反将扣除该人员当月所有KPI绩效2.版本打回测试人员需要按照版本打回流程进行版本打回，否则视为违规违反一次将邮件部门级通报批评（如产品中心、质量部、服务支撑部），邮件对象部门全体、其他项目组内人员再次违反将扣除该人员当月所有KPI绩效3.版本发布测试人员需要按照版本发布流程进行版本发布，否则视为违规违反一次将邮件部门级通报批评（如产品中心、质量部、服务支撑部），邮件对象部门全体、其他项目组内人员再次违反将扣除该人员当月所有KPI绩效4.上线返回服务器支撑部人员需要对发布版本的上线情况（三日内）反馈违反一次将邮件部门级通报批评（如产品中心、质量部、服务支撑部），邮件对象部门全体、其他项目组内人员再次违反将扣除该人员当月所有KPI绩效 第7页 / 共7页