大型外包企业的缺陷管理Word格式.docx
《大型外包企业的缺陷管理Word格式.docx》由会员分享，可在线阅读，更多相关《大型外包企业的缺陷管理Word格式.docx（11页珍藏版）》请在冰豆网上搜索。
使用excel方式的一大问题就是，如果发现一个缺陷就马上提交的话，不但在收发邮
件通知上需要消耗大量工作，而且很难进行跟踪；
而如果聚集一定数量，统一提交的话，就会出现测试集体等待修改或者开发集体等待缺陷的阶段性工作时间的浪费。
1.2.反复严重
山于excel的局限，测试无法保证能够完全准确描述缺陷的信息，开发者无法保证能够完全准确描述修改方式，缺陷在开发测试之间来回传递的现象屡有发生，一直无法根除。
1.3.交流不便
测试发现一个缺陷，使用excel提交到开发那边以后，如果有所补充，需要另起一封邮件加以说明，十分不便。
1.4.难以跟踪
之前的缺陷，经常出现很多漏改漏测的现象。
很多缺陷在测试那边提交了，而在开发那边分配修改并儿经转手，最终修改的缺陷已经远远少于之前所提交的缺陷，同样的悄况下，测试也会出现遗漏的现象。
1.5.记录保存困难
Excel传递过程中，难免出现传递错误或者遗漏，如果配置管理还出现问题，那么以往的缺陷记录很容易就会丢失。
1.6.统计不便
采用excel记录缺陷，一个项目往往需要很多份表格，如果公司的项目乂很多，那对于缺陷的统汁，经验数据的保留，就需要非常巨大的工作量。
2.流程分类
根据不同开发阶段的需要，并且经过不断完善，我们设计了3种缺陷流程一一单元测试流程、系统测试流程、发布后流程。
2.1.单元测试流程
单元测试流程用于开发组内部测试，由开发人员提交并留档，过程中需要经过测试经理以及项U经理审核。
2.2.系统测试流程
由于系统测试基本是山发包方完成，因此在系统测试阶段，相对单元测试，需要对缺陷进行公司内部的预验证。
另外，在配置管理的约束下，对发包方提供的版本必须经过基线化，所以，在系统测试流程中，增加了SCM基线化的环节。
2.3.发布后流程
由于发布后流程中所包含的缺陷均由用户或者发包方代替用户提交，因此，这个流程基本与系统测试流程一样，需要进行2次确认，不同点是发布后流程需要用户填写产品的版本号以便确认。
3.流程实现
3.1.单元测试
3.1.L人员与角色
参加单元测试的均为公司内部人员，主要有项LJ经理、测试经理、开发、测试、
SCCB、其他。
角色
职责
项目经理
分配缺陷给修改人员
验证缺陷修改描述以及逻辑的准确性
测试经理
验证缺陷描述以及逻辑的准确性
分配修改完成之后的验证人员
测试
提交缺陷
验证缺陷的修改并关闭
开发
修改缺陷
SCCB
裁决缺陷的处理方式
其他
包括SQA、部门经理以及技术经理，用于监控项U缺陷状况
基本流程：
测试-＞测试经理（受付中）-〉项目经理中）-〉开发（対応中）-〉项口经
理（対応确认中）-〉测试经理（试験结果报告中）-〉测试（受入试験中）-＞关闭（完了）
特殊流程：
发生原因
流程
重复缺陷或者非缺陷
测试经理（受付中）-〉测试（取消待）-〉关闭（取消）
缺陷描述不准确或误测
测试经理（受付中）-〉测试（现象确认中）-〉测试
经理（受付中）
开发与测试意见发生严重
分歧
测试经理（受付中）-＞SCCB（SCCB决済中）-〉项
目经理（PGA中）
测试经理（受付中）-〉SCCB（SCCB决済中）-〉测
试经理（受付中）
项目经理（PG＞中）-〉SCCB（SCCB决済
中）-〉测试经理（受付中）
项目经理（PG了廿■＜A中）-〉SCCB（SCCB决済中）-〉项目经理（PGA中）
缺陷延时修改
项目经理（PG中）-〉项目经理（保留）-
〉项目经理（PGA中）
开发认为非缺陷
开发（対応中）-〉项目经理（PGA中）->
测试经理（受付中）
缺陷验证未通过
测试（受入试験中）-〉测试经理（试験结果报告中）-〉项目经理（PGA中）
3.1.3.字段设计
字段名
出现位置
说明
説明
对缺陷的描述
再现方法
重现缺陷所需的操作步骤
种类
缺陷类型，包括：
缺陷、新需求、需求变
更，需求确认
修正L性
yr
开发（対応中）-〉项
目经理（対応确认
中）
修改的文件列表
対応方法
开发（対応中）->
项
修改的方式
其他步骤采用系统自带的标题和内容进行描述。
3.2.系统测试
3.2.1.人员与角色
系统测试中，发包方是测试人员，为了与内部测试人员加以区别，在系统测试阶段,加入了新的角色一一日本SE。
另外，基于配置管理的需要，为发包方提供的版本需要经山SCM基线化以后才能发出，所以，系统测试流程中还加入了另外一个角色一一SCMo
分配发包方的验证人员
验证缺陷的修改
日本SE
SCM
基线化以后处理相关版本的缺陷
3.2.2.流程设计
基本流程:
日本SE-＞测试经理（受付中）-＞测试（现象确认中）-＞测试经理（受付中）-〉项U经理（PG＞中）-〉开发（対応中）-〉测试经理（TS＞中）-＞测试（対応确认
中）-〉SCM（八一声mA管理）-〉测试经理（试験结果报告中）-〉日本SE（受入试験中）-＞关闭（完了）
特殊流程:
测试经理（受付中）-〉日本SE（取消待）-〉关闭
（取消）
测试经理（受付中）-＞SCCB（SCCB决済中）-〉测
项目经理（PG>
中）-〉SCCB（SCCB决済
中）-〉项目经理（PGA中）
项目经理（PGA中）-〉项目经理（保留）-
缺陷内部预测试未通过
测试（対応确认中）-〉项目经理（PG>
缺陷发包方验证未通过
3.2.3.字段设计
缺陷、新需求、需求变更，需求确认
y7
开发（対応中）-〉测
试经理（TS7^^>
试经理（TS>
3.3.发布后
3.3.1.人员与角色
在人员配置上，发布后流程与系统测试流程的人员配置完全一样（用户与发包方共用
一个群组）。
3.3.2.流程设计
日本SE-〉测试经理（修正依頼）-〉测试（现象确认中）-〉测试经理（修正依頼）-〉项目经理（现象确认済）-〉开发（修正対応中）-〉测试经理J亍入卜依頼）-〉测试（亍;
^卜実施）-〉SCM（八一声3A管理）-〉测试经理（试験结果报告中）-〉日本SE（受入试験中）-〉关闭（完了）
测试经理（修正依頼）->
日本SE（取消待）->
关闭（取消）
SCCB（SCCB决済中）->
项目经理（现象确认済）
测试经理（修正依頼）
项目经理（现象确认済）->
SCCB（SCCB决済中）-
>
项LI经理（现象确认済）-〉项LI经理（保留）-〉项
目经理（现象确认済）
项LI经理（现象确认済）-〉测试
经理（修正依頼）
测试经理发现修改不完整
测试经理J〒入卜依頼）->
项目经理（现象确认済）
测试J〒入卜実施）-〉项口经理（现象确认済）
测试（受入试験中）-〉测试经理（试験结果报告中）-〉项目经理（现象确认済）
登録番号
（奉行）
产品版本号（奉行）
（儿卜彳＞）
产品版本号（丿1/卜彳A）
（Addon）
产品版本号（Addon）
修正L上
试经理行入卜依
頼）
试经理（亍灭卜依
3.3.3.
字段设计
4.数据统计
产品版本关闭后，对于某个版本中出现的缺陷分布进行统计，并且收集这些数据进行归档。
4.1.缺陷分布统计
缺陷分布统讣就是根据模块对各模块缺陷的分布状况进行统讣，山此可以推断下一阶段的工作重点，使测试团队能够有针对性的进行测试。
4.2.缺陷趋势统计
缺陷趋势统讣是按照时间对缺陷数量进行统计，通过这项统讣，测试组可以推断产品LI前的质量状况，以及需要进行的测试周期的数量。
4.3.缺陷原因统计
缺陷原因统计是根据项LI中缺陷发生原因进行统计，统计完成后，能够推断项LI的工期变化、工期变化原因以及产品缺陷率，并为其他项LJ提供参考数据。
5.拓展计划
5.1.管理流程
除了缺陷管理，公司正准备加入部分行政管理，客户管理和营业管理的流程到
urtracker中，使之全面成为公司的日常工作平台。
5.2.知识库管理
公司计划开启一个咨询管理平台，通过流程实现资源互通，通过事务流程管理，让每一位员工可以在urtracker上面提出技术疑问，并将这些信息与缺陷库、管理库的信息一同合并到知识库中，成为公司知识积累的平台。
升级会员 