软件过程测试与发版规程V1.0

密级：内部资料测试与发版规程（信息技术部）XXX公司测试与发版规程文件修改控制目录一、概述 (1)1.1目的 (1)1.2目标 (1)1.3适用范围 (1)1.4适用对象 (1)二、测试组角色与职责 (1)2.1内部测试负责人(TL) (1)2.2测试人员(T EST) (1)2.3公共测试人员(T EST-P) (2)三、组织结构 (2)四、测试工作流程 (2)4.1整体流程 (2)4.2详细流程 (2)4.2.1 测试策划 (2)4.2.2 需求理解 (3)4.2.3 测试设计 (3)4.2.4 测试执行 (4)4.2.5 测试管理 (5)4.2.6 测试总结 (5)五、测试标准 (6)5.1单元测试 (6)5.2接收测试标准 (6)5.3集成/功能测试 (7)5.4系统测试 (8)六、版本发布 (8)6.1正式发版流程 (8)6.2紧急发版流程 (12)6.2.1 紧急需求定义 (12)6.2.2 紧急发版执行流程 (12)6.2.3 紧急发版后续流程 (15)6.2.4 紧急版本跟踪 (15)6.3发版制度与要求 (15)6.3.1 测试团队验收制度与要求 (15)6.3.2 以客户方验收制度与要求 (16)6.3.3 项目评价说明 (17)附录 (18)附录1B UG等级描述 (18)附录2软件项目的缺陷分类 (19)附录3相关测试报告要求 (21)一、概述1.1 目的➢主要用于指导信息技术中心软件项目的软件测试、版本发布相关工作，及制定研发团队需遵循的相关标准。

1.2 目标➢规范测试与版本发布相关流程。

1.3 适用范围➢适用XXX信息技术中心。

1.4 适用对象➢执行项目和研发产品二、测试组角色与职责2.1 内部测试负责人(TL)测试负责人TL（Test-Leader）：指质量管理部投入项目组的测试负责人，负责策划、核心模块测试用例编写；与测试人员进行用例评审、监控和总结测试活动；总体把握测试阶段质量，并以客户方的角度验收交付版本质量。

2.2 测试人员(Test)测试人员Test: 指质量管理部投入到项目组的测试人员，负责各测试用例编写与测试计划执行，配合测试负责人完成测试度量数据的收集。

2.3 公共测试人员(Test- P)测试资源池Test-P(Test-Pool)：为公共测试人员，供质量负责人临时申请时调度。

调度原则：根据主要的公共业务方向进行测试临时任务支持及组织级专项能力培养。

职责详细参见《测试工作手册》文档。

三、组织结构在质量管理部的领导下，协同项目管理委员会共同完成本部门的质量保证工作。

质量管理部组织结构，参见《测试工作手册》文档。

四、测试工作流程4.1 整体流程图4-1 整体流程图注：各项目组可以在通用流程的基础上，根据各自的项目特点进行特有流程的添加。

4.2 详细流程对测试体系活动详细说明活动与子活动，对应的输入与输出及责任人。

4.2.1测试策划表4-1 测试策划4.2.2需求理解表4-2 需求理解4.2.3 测试设计表4-3 测试设计4.2.4 测试执行表4-4 测试执行4.2.5 测试管理表4-5 测试管理4.2.6 测试总结表4-6 测试总结五、测试标准5.1 单元测试要求：●类编译通过后，要求进行单元测试。

●单元测试工作量、单元测试用例通过率为90%；或者缺陷密度大于8个/千行；5.2 接收测试标准●接收测试出现一级Bug或者Blocking问题，视为不通过1次。

●接收测试版本，每轮迭代最多接收3次，三次未通过。

测试负责人后续与开发人员协商测试延期的周期，同时要求开发人员再次提交时给出修改记录及自测功能列表。

（通常情况下测试负责人要考虑手头上工单情况），最后按照协商后的时间点再次接收测试。

●接收测试提交三次未通过的，在测试月报中进行通报。

●接收测试用例由测试负责人进行选取，被测模块的用例个数占总用例的10%。

没有一级Bug或者Blocking问题的情况下，测试用例执行结果通过率小于75%的，接收评价结果为不佳；测试结果通过率为76%~85%，接收评价结果为一般；测试结果通过率为86~92%为良好；测试结果通过率大于92%为优秀。

●测试达到评价结果至少为一般时，方可进入正式的集成/功能测试阶段，或系统测试阶段。

5.3 集成/功能测试开始标准：●单元测试工作满足单元测试要求；●依据概要设计/功能设计说明书，完成集成/功能测试用例的编写，且测试用例通过评审；●利用集成/功能测试用例对代码质量进行抽样检查，Bug数需小于4个/100用例。

结束标准：●没有一级和二级Bug，三级Bug得分总和控制小于10分；●按测试轮次进行Bug统计，发现的Bug数要符合标准的Bug收敛曲线（即发现Bug数目先增加，达到一定的数量后逐步减少，最后趋近于0）；【说明】各产品线Bug数的标准，根据产品的特点逐渐形成每条产品线的量化结束标准。

●按体系要求输出了测试用例、BugList和测试总结，测试总结中包含对Bug的分析。

考虑到集成/功能测试阶段的工作量较大且会涉及到许多与业务紧密相关的需求，需要采取白盒测试，对于问题突出的项目可以考虑参照下表对集成/功能测试进行阶段细化。

5.4 系统测试开始标准：●在系统测试前进行了集成/功能测试且集成/功能测试工作满足集成/功能测试结束标准；●依据需求文档及概要设计说明书，完成系统测试用例的编写，且测试用例通过评审；●利用系统测试用例对代码质量进抽样检查，Bug数需小于1个/100用例。

结束标准：●没有一级和二级Bug，三级Bug得分总和控制小于5分。

●按测试轮次进行Bug统计，发现的BUG数要符合标准的Bug收敛曲线（即发现Bug数目先增加，达到一定的数量后逐步减少，最后趋近于0）；【说明】各产品线Bug数的标准，根据产品的特点逐渐形成每条产品线的量化结束标准。

●按体系要求输出了测试用例、BugList和测试总结，测试总结中包含对Bug的分析。

六、版本发布版本发布分为：正式发布和应急发布。

整体要求与版本规范，参见《版本发布细则》文档。

6.1 正式发版流程1、经测试团队测试通过后，由研发项目组CML发布内容放入发布库中，编译后可执行包到质量管理部FTP服务器中，详细请参见《配置库结构&权限使用规则表.xlsx》中的SVN配置库使用规则说明；2、正式版本测试包括集成测试、部署测试、系统测试、性能测试[应急版本可裁剪]，TL判定正式版通过，由开发方CML发布到发布库，可执行文件和项目版本发布映射表放入FTP服务器中，同时要求编译版本带上Version信息（命名与发布版本命名相同），TL测试通过后按质量管理部要求更新FTP服务器对应文件，告知QA和质量部CML，由质量部CML发布给申请人；3、正式版本发布释放标准，需达到以客户方验收的标准，方可形成发布基线。

详见《6.3.2以客户方验收制度与要求》相关条款。

4、测试通过后，由TL把测试报告发给开发方CML，由TL正式通知项目组、QA、质量管理部配置管理员，形成测试基线后，通过打标签的方式由TL放入Acceptance_Test目录中，QA进行审计通过后，由质量管理部管理员正式发布给现场。

详见《生命周期流程指南》设计与实现详细说明。

5、正式版回退现场人员接收正式发布版本后，如果出现遗漏那么打回项目组，如果是变更那么项目经理按变更流程执行。

说明：现场测试，要求由实施人员进行测试并记录BugFree中，如果没有实施人员可向质量管理部申请测试人员，进行现场测试支持，项目经理申请期限与质量管理部负责人进行协商。

到达申请时间进行释放测试人员。

（目前提供现场测试支持服务为北京测试团队）图6-1 设计与实现—正式发布局部截图第10 页/ 共22 页图6-2 设计与实现-试运行—现场测试局部截图第11 页/ 共22 页6.2 紧急发版流程紧急流程的目的是快速解决当前Blocking客户/业务部门工作的问题，通常需要发布临时版本供客户/业务部门暂时使用。

待正式版本发布后，对临时版本再予以替换。

由于简单开发、测试快速，质量和需求难以完全保证，因此需要客户/业务主管领导和技术部门负责人共同签字确认，方可按紧急需求处理。

6.2.1 紧急需求定义紧急需求：系统出现的问题导致用户无法正常使用；或新需求关系到当前业务能否进行，且目前没有替代方案可以使用。

Blocking问题：由测试环境制约或者由于依赖功能失败制约而导致的不能测试。

1、首先有上线压力。

2、系统出现的问题导致用户无法正常使用。

3、或新需求关系到当前业务能否进行，且目前没有替代方案可以使用。

4、如果不升级，会带来客户一定的经济损失。

特征：紧急需求的开发，因其特殊性，以解决Blocking问题为主，实现简单可以快速开发、可以进行快速测试。

6.2.2 紧急发版执行流程研发项目组在申请迭代周期内，需要紧急发布务必按照签字流程执行，紧急版本获取及发版，直接从开发库发版。

紧急发版输入物：需求申请单、小需求或紧急需求，使用《[产品名称]_X.Yr修订号bT_测试申请单_emergency.xls模板》作为统一填写要求。

1、需求紧急申请A/当需求申请人有紧急需求（或小需求）时，需填写书面“需求申请单”，并需申请方相关负责人（通常为项目经理和部门经理级别）确认签字或邮件确认，同时抄送业务主管、质量管理部负责人；B/当客户方提出需求变更时，由变更方提交书面“需求变更单”。

C/研发中心设立需求申请及变更的接口人（可以由PM兼任），要求接口人对补全文档列表进行审计与确认。

2、变更影响分析技术经理组织项目经理、开发人员、产品经理对变更影响进行分析，包括对项目成本、进度、质量的影响。

分析结果记录在“需求变更单”中。

（如果是小需求、紧急需求，不做变更影响分析，需由CCB负责人（技术负责人）同意后，再直接进入步骤5--直接反馈步骤）3、大变更审批影响较大的需求，需提交《项目管理委员会》业务主管领导进行签字或邮件审批，审批结果记录在“需求变更单”中的“变更评审”处，若影响到项目计划的变更，则填写“项目风险管理列表”并更新项目计划。

4、小变更审批影响较小的需求，需提交CCB变更控制委员会负责人进行签字或邮件审批，审批结果记录在“需求变更单”中的“变更评审”处。

5、直接反馈说明：对于CCB审批结果，如果不影响到客户的承诺，那么不需要客户审批确认。

技术经理或模块负责人将“需求申请单”反馈给PM，PM与客户方负责人进行确认及需求审批。

6、快速测试项目组与测试组高效配合、快速迭代，最终达到需求申请单要求。

开发人员与测试专人快速理解需求，完成测试。

最小输出物：《软件修改报告》、《需求变更列表》、《交付程序》与《测试问题报告》。

7、达成一致后按照需求申请单，项目团队、测试团队、客户三方的质量标准要达成共识，同时给出邮件承诺（期限3~5天）补全文档列表。