1、文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 1 页 共 12 页测试管理流程版本号 拟制部门 拟制责任人 拟制/修订 日期 拟制/修订内容 及理由 审核人 最终批准人相关部门会签：部 门 会签人员 会签意见项目管理部研发中心职能系统开发部门户系统开发部数据中心一、目 的规范软件测试的过程，保证交付件的质量。文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 2 页 共 12 页二、范 围所有IT部自行开发的软件项目、外包项目、系统变更（包含程序类、外购程序补丁类、基础架构类、系统配置类）的测试流程边界：需求
2、确定后或版本规划流程规范完成后，进入该流程，直到确认上线发布前结束。应知应会：IT项目管理部、研发中心、职能系统开发部、门户系统开发部、数据中心一般了解：需求提出方、IT服务中心三、输 入1、详细需求说明书2、版本规划说明书3、系统设计说明书4、转测试申请书四、输 出1、测试计划（大型项目需要测试方案）2、预测试用例3、测试用例4、测试报告5、用户验收测试报告6、部署说明书五、流程概要或说明测试管理流程分为如下阶段：1、 测试准备阶段 （根据版本规划说明书和详细需求说明书，进行测试设计。包括测试计划、测试用例、测试方案。）2、 预测试阶段 （开发完成后，部署到预测试环境，开发人员进行预测试。）
3、文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 3 页 共 12 页3、 测试执行阶段（开发部门向测试组提交转测试申请，测试组执行测试，组织用户验收测试，得出测试结论，向正式发布提供相关材料及依据。）六、职责与技能要求角色或部门名称 流程职责说明 技能要求需求提出方1、 参加用户测试，填写用户测试报告，并对报告内容负责；2、 参与测试评审，并对评审结果负责；1、 熟悉该系统相关的公司业务逻辑；2、 熟悉系统需求内容；3、 了解用户习惯；4、 了解系统操作；项目管理组1、 参与测试评审，并对评审结果负责；2、 协调用户测试资源；3、 参与用户验收测试；
4、1、 熟悉该系统相关的公司业务逻辑；2、 熟悉系统需求内容；3、 了解系统操作；开发组经理1、 提交系统设计说明书；2、 收集版本内代码、元数据、脚本等内容，创建开发分支，并对分支正确性负责；3、 编写并提交转测试申请书，并对申请书完整性和准确性负责；4、 参与测试评审，并对评审结果负责；5、 协助解决预测试环境、测试环境的部署问题。1、 熟悉版本规划内容及需求内容；2、 熟悉分支、合并操作；3、 熟悉测试流程；开发员1、 完成分支BUG修改后，将代码、元数据合并的操作，并对代码合并完整性负责；2、 进行有效预测试；3、 参与编写转测试申请书；4、 参与测试评审；1、 熟悉版本规划内容及需求内
5、容；2、 熟悉分支、合并操作；3、 熟悉测试流程；4、 熟悉系统操作；测试组经理1、 获取需求文档，分配测试任务；2、 接收并审核转测试申请书；3、 记录各时间节点；4、 组织测试评审，并对评审结果负责；5、 审核测试用例测试轮次及测试报告书；1、 熟悉版本规划内容及需求内容；2、 熟悉测试流程；3、 熟悉系统操作；文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 4 页 共 12 页6、 组织用户测试；测试人员1、 获取需求文档，制定测试计划、测试用例2、 执行测试过程；3、 编写并提交测试报告，并对测试结果负责；1、 熟悉版本规划内容及需求内容；2
6、、 熟悉测试流程；3、 熟悉系统操作；4、 熟悉用例编写方法；部署员1、 获取开发分支，创建测试分支；2、 部署预测试环境、测试环境（代码、元数据、脚本），并对测试环境正常使用负责；1、 熟悉部署操作方式；2、 熟悉分支操作；标准管理部人员1、 获取检查表，监督测试流程执行；2、 监督各交付件的编写与传递。3、 监督评审会议；1、 了解测试流程交付件的格式；2、 了解测试流程时间点。IT服务中心1、 参与用户验收测试，以便熟悉系统操作。2、 完成用户手册。1、了解系统操作。数据中心1、 根据发布标准进行系统发布；2、 对基础架构、系统配置、外购补丁类变更进行审核及调研；3、 主导基础架构、系统
7、配置、外购补丁类变更的测试及验收；4、 对基础架构、系统配置、外购补丁类变更进行实施验收1、 了解系统的基础架构、配置信息；2、 了解系统变更的测试内容；3、 了解系统变更后的实施操作；文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 5 页 共 12 页七、流程图测试流程测试准备阶段预测试阶段测试执行阶段项目管理组 开发组 测试组需求提出方制定测试计划 （ 1 0 1 ）编写测试用例 （ 1 0 2 ）提交预测试用例 （ 1 0 4 ）软件开发流程部署测试环境 （ 1 0 6 ）执行测试并修正 b u g （ 1 0 7 ）是否开始评审 （ 1 0
8、3 ）审核是否满足开发转测试标准（ 1 0 5 ）审核是否满足测试转发布标准（ 1 0 9 ）否结束用户验收测试 （ 1 0 8 ）是文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 6 页 共 12 页B u g 处理流程I T 服务中心测试组开发组项目管理组用户报告发现问题 （ 2 0 1 ）问题分类及严重度划分 （ 2 0 2 ）问题类型需求管理流程修复 b u g （ 2 0 4 ）定义为新需求 定义为 b u g提交 b u g 平台（ 2 0 3 ）测试管理流程八、流程说明8.1 测试流程活动编号活动名称 流程活动说明 角色/部门 活动输入
9、输出101 制定测试计划在项目需求评审通过或者版本规划确认后，完成测试计划的制定。包括测试人员安排、具体时间计划。对于项目型系统，须由项目组协调资源进行测试。测试组输入：版本规划说明书输出：测试计划102 编写测试用例根据详细需求说明书，进行测试用例设计。包括预测试用例和其他测试用例。测试用例需要在开发完成前2天内上传SVN,并由开发员审核测试用例的覆盖率。若开发员同意测试用例的覆盖率，在转测试的前1天内将其转回测试组；若开发员不同意测试用例的覆盖率，注明原因将其打回，由测试员进行完善。测试组输入：详细需求说明书输出：测试用例103 评审必须评审的测试用例参考IT评审流程中的相关规定。 对于需
10、要测试评审的用例，由测试组组织测试用需求提出方、项目管理组、开发组、测输入：测试用例、测试计划输出：确认后的文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 7 页 共 12 页例评审会。评审参与者对用例的可靠性及评审结果负责。对于评审不通过的用例完善后重新组织评审，直到通过为止。试组 测试用例及测试计划、评审纪要104提交预测试用例根据评审结果和版本规划内容，测试组负责筛选出能够代表主要正向流程的测试用例作为预测试用例，并提交给开发组进行预测试。提交时间在开发完成时间前2天。进入软件开发过程，参考软件开发流程。测试组 输出：预测试用例105审核是否满
11、足开发转测试标准开发转测试需要满足以下3个条件：一、转测试申请内容包含：转测试申请书、预测试报告、差异对比报告、执行的脚本、存储过程、初始化脚本及需上传的打印模版（若有脚本按模板提交，若没有脚本模版等可以不包含），由开发组提供各组内部脚本的执行顺序，测试组审核脚本执行顺序。如果出现多部门都有脚本的情况，由测试组按照各版本转测试的时间顺序，依次来决定最终脚本的执行顺序，并合并为统一的数据库执行脚本说明书。二、转测试当天九点前将转测试申请内容提交至SharedDOCIT部项目管理库版本规划书（正式版）日期版本三、转测试申请书提交后，测试组经理或者指定人员进行审核。以下条件中任意一条将会导致审核不合
12、格退回：1、未包含转测试申请任一内容2、转测试申请书填写不完整；3、测试内容中包含版本外内容，且未进行版本变更；4、未通过预测试；5、开发分支未正确建立；6、其他导致系统不稳定或无法测试的情况。若转测试不通过需要开发组重新提交相关材料。开发组、测试组输入：转测试申请书、数据库执行脚本说明书输出：审查通过的转测试申请书、数据库执行脚本说明书106 部署测试环境1、获取预测试环境中的对应代码包，部署测试环境；2、创建测试分支。不同版本涉及到同一包的，先提交转测试申请的先测试上线，然后再测试其他版本。若后一包确定紧急需要先上线，则由提出方进行版本变更。并申请将需要上线的内容合并到前一稳定开发分支中进
13、行测试上线。测试环境部署时间为：每天9：30-9：45一次。每天13：45-14：00一次。每天16：00-16：15一次。其余时间不部署。开发员必须在部署时间之前上传所有代码、元数据。测试组 输出：可以测试的测试环境文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 8 页 共 12 页搭建预测试环境也同样受以上限制。107执行测试并修正BUG1、根据测试计划和测试用例，测试组以轮次的方式进行测试。测试用例要记录每轮测试的记录（确保最后一轮测试所有用例全部被测试到），原则上，普通版本规划项目进行两次轮次测试。2、测试组发现问题及时反馈开发员，并进入BU
14、G处理流程。3、测试报告最晚反馈为部署日前一天下午5点，需要经过测试组经理的审核。部署前24小时内，发现2级及以上严重度BUG，开发员须在2小时内给予响应。截止部署日当天15：00，仍未测试通过，则该版本直接延期。如确有紧急功能要上线的，由开发部高级经理级以上人员签署部署确认表，开发组修改BUG，测试通过后，才能可上线。4、测试组、开发组输入：可以测试的测试环境；输出：BUG信息；测试报告书108 用户验收测试对需求中明确要求需用户验收测试的，由测试组组织用户进行验收测试。验收通过后，需签署用户验收报告。验收不通过的进入BUG处理流程。完成用户操作手册。（明确操作文档编写人）需求提出方、项目管
15、理组、IT服务中心输出：用户验收测试报告用户操作文档109审核是否满足测试转发布标准测试转发布需要满足以下3个条件：一、缺陷指数不超过10分。缺陷指数=3级BUG数量*1+4级BUG数量*0.5；二、最后一轮次测试需要一次性测试所有的测试用例且不允许出现1级或2级BUG；三、转测试申请书、测试报告需要测试经理审核通过。以上任意一条未满足，为测试不通过；项目管理组、测试组、开发组输入：用户验收测试报告、测试报告输出：缺陷指数报告版本规划执行记录表基础架构、系统配置类测试说明：一、由数据中心或其他各小组经理提出申请；二、由数据中心负责人对变更申请审批，并且主导制定实施方案，根据实施方案执行测试；三
16、、由数据中心和各需求提出部门经理主导验收。ERP性能测试指标说明：对于一线部门每天都使用，且每天使用频率在 50次及以上的， 对于重要功能点在 203测试服务器正常压力下（无特别的程序在运行时）响应时间不得超过 2秒。当以上功能点在测试环境中响应时间超过 2秒时，需要进行整改。直到符合标准后才能部署到正式环境中。如果功能点不符合标准，但又合理理由需要部署，需要由直管（需求、开发、测试）高级经理以上签字确认后才能部署。8.2 BUG处理流程文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 9 页 共 12 页201 报告发现问题当发现正式系统问题时，无论
17、哪个部门发现的线上BUG，都只能提交给相应的测试组经理。当发现测试系统问题时，向开发组报告问题。BUG提交时需要注意BUG环境，包括2类环境：线上BUG、线下BUG（友好型优化属于线下BUG一种，线上BUG禁止提友好型优化）。用户、项目管理组、开发组、测试组、IT服务中心202问题分类及严重度划分根据问题分类标准，划分该问题的类型以及严重程度（1-4级）。分类标准见附件问题分类标准。若是新需求，不能提交BUG平台，直接走需求管理流程。用户、项目管理组、开发组、测试组、IT服务中心203提交BUG平台一、BUG提交信息：1、线上BUG在提交时需要以电子邮件的形式通知到相应的项目管理组、开发组、测
18、试组经理，并由测试组经理审核确认为线上BUG后，再分配给相应的开发组经理，由开发经理分配给开发员；2、线下BUG由测试员分配给相应的开发员即可（若为友好型优化由测试组提交BUG平台，并由开发组经理审核确认为友好型优化后，再分配给相应的开发人员）；二、BUG包含信息：BUG的信息必须准确详细的重现BUG步骤；1、BUG出现的前置条件：环境、其他特殊条件；2、BUG出现的操作步骤；3、BUG出现的现象描述，并且记录错误信息；4、BUG出现的环境,确认是线上还是线下；5、必要的附图。 三、BUG处理信息：相关人员打回BUG时必须备注打回原因；开发员处理BUG时须填写，涉及哪些相关内容及测试建议.用户
19、、项目管理组、开发组、测试组、IT服务中心输出：BUG记录204 修复BUG对于严重度为1级的BUG：开发组必须在2小时内回复解决情况。对于严重度为2级的BUG：开发组必须在24小时内回复解决情况。对于严重度为3级的BUG：开发组可以根据情况在下一次版本规划中解决。对于严重度为4级的BUG：开发组可以自行决定解决时间。BUG修复后进入测试流程。当前版本发现的BUG，必须在当前版本的开发分支上进行修改。上线后发现的2级及以上BUG，包含在下一版本中修改，测试通过后上线。所有BUG的解决须由开发人员主导，测试人员、部署人员协助。开发组文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称
20、： 测试管理流程 页号：第 10 页 共 12 页九、流程关键控制环节103、106、108、110十、流程负责人由IT标准管理部负责解释.十一、责任划分差错描述 起因描述 主要责任部门/责任人 问题解决方式开发分支创建有误或延期。 开发组分支创建负责人转测试申请书提交有误或延期。 开发组转测试申请负责人预测试测试用例提交不及时。 测试组测试用例负责人未通过预测试，测试驳回。 开发组功能开发员BUG处理不及时，造成当前版本或其他版本计划延期。开发组BUG所指派开发员未按照测试计划进行，测试延期。 测试组测试负责人代码质量差，测试轮次过多（4次以上） 开发组功能开发员1、责任方负责发起版本变更申
21、请，申请延期。2、项目管理部负责用户沟通及最终上线计划调整。1、版本计划延 期。2、引发后期版本延期。由于测试服务器故障导致测试周期延长。中间件部署问题：测试组其他：数据中心1、恢复服务器正常使用。2、责任方负责发起版本变更申请。3、项目管理部负责用户沟通及最终上线计划调整。测试不完整。 测试组提交正式部署程序包错误。 测试组由于程序关联包引起。如果开发组提供关联包信息有误：开发组其他：测试组正式系统异常。开发分支包含版本外代码。如果差异对比不一致，且未确认后上线：测试组其他：开发组视问题严重情况，回滚或解决后紧急部署。*如果对责任划分结果有分歧或其他未在上表内明确的，则各部门协商划分。责任方
22、负责主导问题的解决。文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 11 页 共 12 页十二、文档模板ERP类 转 测 试 申 请 书.doc 性 能 指 标 签 字 模 版 .xlsx EOS类 转 测 试 申 请 书（ 版 本 规 划 类 ） .xlsx 数 据 脚 本 提 交 模 板 .xlsx十三、BUG 分类标准问题等级 问题所在系统 问题描述 处理方式正式系统1、常规操作造成系统崩溃、死机。2、常规操作造成系统非法退出、死循环、通讯中断、数据丢失或数据库异常。3、常规操作造成数据异常。4、系统任何一个常用功能完全丧失。5、问题影响波及面
23、广，影响核心业务继续进行。6、重要数据显示不正确。进入重大事故处理流程1级（严重）测试系统1、未完成系统详细需求说明功能。2、无法继续业务流程。3、常规操作造成系统崩溃、死机。4、常规操作造成系统非法退出、死循环、通讯中断、数据丢失或数据库异常。5、常规操作造成数据异常。6、某一被测功能完全丧失。7、系统异常导致无法测试。8、重要数据显示不正确。9、其他影响测试进度的BUG。开发人员必须在2小时内回复进展情况。正式系统1、常规操作造成系统运行缓慢。2、非重要数据显示不完整。（例如精度等）3、系统某非常用功能完全丧失。4、系统异常对少量用户有影响。但不影响业务操作。（例如数据导出等）修改BUG，
24、包含在下一版本中。2级（重要）测试系统1、实现功能与需求说明书中不一致。2、非常规操作造成系统崩溃。3、非常规操作造成系统数据异常。4、非报表类的业务操作类，响应时间超过0.5分钟。（视数据量可进行协商调整响应时间。）24小时内回复解决情况。3级（次要） 任意系统1、提示信息内容有误。2、非常规操作导致非核心数据错误，且发生概率小。3、偶然发生异常。4、不存在业务输入导致系统问题。（例如代收货款999999时报错）根据情况，至少在下一版本上线前修改完成。4级（建议） 任意系统1、提示不规范，但不影响用户理解。2、界面不规范，例如字体不统一等。3、显示格式不规范。4、界面存在错别字。开发人员自行确定修改时间。需求 任意系统 1、用户需要使用的功能，但在需求说明书中没有描述。2、用户操作不便利。 进入需求管理流程文件编码： 统一编码 版本：V1.3业务类别： 项目管理文件名称： 测试管理流程 页号：第 12 页 共 12 页3、对原有数据查询的内容、条件修改。
