缺陷管理流程

Version 1.0文档模板变更记录

文件状态：

[ ]草稿

[√]正式发布当前版本：V1.0

作者：罗伟

审核人：朱守民

发布日期：2009-9-10

修订号修改内容描述修改人修改日期备注1

2

3目录

1. 引言 (1)

1.1. 文档目的 (1)

1.2. 适用范围 (1)

1.3. 读者对象 (1)

1.4. 术语与缩略语 (1)

2. 缺陷跟踪流程 (1)

2.1. 缺陷状态 (1)

2.2. 缺陷生命周期 (3)

2.2.1. 缺陷流程图 (3)

2.2.2. 流程图说明 (3)

3. 角色与职责 (4)

3.1. 测试组长/经理 (4)

3.1.1. 职责 (4)

3.1.2. MQC权限 (4)

3.2. 测试人员 (4)

3.2.1. 职责 (4)

3.2.2. MQC权限 (4)

3.3. 开发组长/经理 (5)

3.3.1. 职责 (5)

3.3.2. MQC权限 (5)

3.4. 开发人员 (5)

3.4.1. 职责 (5)

3.4.2. MQC权限 (5)

3.5. 项目经理 (5)

3.5.1. 职责 (5)

3.5.2. MQC权限 (6)

3.6. 需求方专家 (6)

3.6.1. 职责 (6)

3.6.2. MQC权限 (6)

3.7. 配置管理员 (6)

3.7.1. 职责 (6)

3.7.2. MQC权限 (6)

3.8. QA (7)

3.8.1. 职责 (7)

3.8.2. MQC权限 (7)

3.9. 浏览者 (7)

3.9.1. 职责 (7)

3.9.2. MQC权限 (7)

4. 缺陷提交规范 (7)

4.1. 缺陷提交原则 (7)

4.2. 缺陷填写要求 (8)

5. 附录 (9)5.1. 缺陷属性定义 (9)1.引言

1.1.文档目的

本文档对测试工作中角色、测试流程、缺陷管理规范、缺陷跟踪规范进行了定义，并明确了测试工作中每个角色的职责，保证测试流程的正确执行，保证测试工具被正确地使用。

1.2.适用范围

本文档适用于本公司各研发类与实施类项目的功能测试和系统测试阶段的测试活动，从开发人员提交第一次测试开始，到项目结束期间的测试工作。

1.3.读者对象

本流程读者对象为公司项目组所有成员。

本流程是保证缺陷跟踪流程顺利运行的前提，所有项目组成员需要按流程规范履行职责。对缺陷管理流程有特殊要求的项目组，可告知项目组PQA人员做适当的调整。

1.4.术语与缩略语

MQC：Mercury Quality Center，HP公司的综合测试管理工具，用于组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。

2.缺陷跟踪流程

2.1.缺陷状态

缺陷通过一个跟踪修复过程的进展情况。包括：新建（New）、打开（Open）、重新打开（Reopen）、已修复（Fixed）、关闭（Closed）、拒绝（Rejected）、挂起/冻结（Suspend）和无效（No bug）。

新建（New）为测试人员新问题提交所标志的状态。

打开（Open）为任务分配人（项目经理授权）对该问题准备进行修改并对该

问题分配修改人员所标志的状态，表示缺陷解决中的状态，由

任务分配人改变。

重新打开（Reopen）为测试人员对修改问题进行验证后没有通过所标志的状态；或

者已经修改正确的问题，又出现新的错误，由测试人员改变。

已修复（Fixed）为开发人员修改问题后所标志的状态。

关闭（Closed）为测试人员对修改问题进行验证后通过所标志的状态，由测试

人员改变。

拒绝（Rejected）开发人员认为不是缺陷、描述不清、重复、不能复现、不采纳

所提意见建议、或虽然是个错误但还没到非改不可的地步故可

忽略不计、或者测试人员提错，从而拒绝的问题。由缺陷分配

人或者开发人员来设置。

无效（No Bug）测试人员确认拒绝的缺陷，如缺陷拒绝的合理，置状态为无效。

挂起/冻结（Suspend） 1.开发人员和测试人员对问题有不同意见需要讨论时，可将

缺陷暂时设为该状态，由提交此缺陷的测试人员负责后续

跟踪处理；

2.对于有些缺陷，开发组也承认的确是个问题，但本阶段不

进行修改，而是只保留做将来参考之用或其它用途，则开

发组长/经理对其作挂起处理，对本阶段而言是缺陷最终状

态之一。

2.2.缺陷生命周期

2.2.1.缺陷流程图

2.2.2.流程图说明

Ø正常缺陷生命周期流程：新建—打开—已修复—关闭。

Ø由测试人员发现缺陷，并加入缺陷列表，缺陷状态为“新建”。

Ø开发经理（或授权人）分析缺陷，确认则设置状态为“打开”，并分配给相应开发人员。Ø如果不是缺陷或不能重现，项目经理（授权人）和开发人员都有权限将缺陷状态置为“拒绝”，并在QC的comment说明原因。

Ø测试组验证“拒绝”状态的缺陷，并和项目组进行讨论直至达成一致，如果确认拒绝的问题合理置状态为“无效”，如果不合理则由项目经理（授权人）置状态为“打开”并分配，对于不能解决和延期解决的缺陷，置状态为“挂起（冻结）”，均需要在QC的comment说明原因。

Ø开发人员修复缺陷后，把缺陷由“打开”置为“已修复”，需要在QC中的comment注明修改方式及版本号。

Ø测试人员对缺陷进行回归测试，如果修改正确，把缺陷状态由“已修复”置为“关闭”，如果缺陷还是存在，则置为“重新打开”，重新提交开发人员。

3.角色与职责

3.1.测试组长/经理

3.1.1.职责

Ø负责项目测试管理工具MQC的搭建，包括建立用户、分配权限、使用讲解和工具维护。Ø负责设置角色、角色权限、检查监督错误跟踪流程。

Ø审核测试人员提交的缺陷，对长期处于中间状态的缺陷查找原因，使其继续流转下去。Ø定期对缺陷库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见。

3.1.2.MQC权限

Ø可新增、修改、删除缺陷。

Ø缺陷状态可执行：任何状态->任何状态。

3.2.测试人员

3.2.1.职责

Ø发现问题时按缺陷提交规范要求提交新的缺陷。

Ø跟踪自己提交的问题，对状态为已修复的问题进行确认回归测试。

Ø对状态为拒绝的问题，及时检查拒绝原因，如果不同意拒绝，则主动与开发人员沟通，确定缺陷的状态。

Ø对状态为挂起的问题，主动查看原因后与开发人员讨论后进行后续处理。

3.2.2.MQC权限

Ø可新增，修改缺陷，不能删除缺陷

Ø缺陷状态可执行：已修复->关闭、重新打开；拒绝->无效、挂起、重新打开；挂起->打开、关闭。

3.3.开发组长/经理

3.3.1.职责

Ø每天对新建的问题进行分配（也可授权技术负责人进行），并根据缺陷原因，标注处理意见，给定紧急程度。

Ø对于咨询类、理解错误类等不是缺陷的问题，置状态为“拒绝”，并在注释中签名并填写原因；对于确实是缺陷的问题，置状态为“打开”并分配给相应开发人员。

Ø对开发人员拒绝的问题，进行分析，及时确定问题状态。

Ø每天对新增的挂起类问题进行处理，标注处理意见，更新其状态。

3.3.2.MQC权限

Ø可新增，修改缺陷，不能删除缺陷

Ø缺陷状态可执行：新建->打开，拒绝，挂起；打开->已修复、拒绝、挂起；

重新打开->已修复；挂起->打开。

3.4.开发人员

3.4.1.职责

Ø负责对分配给自己的缺陷在QC中跟踪修复。

Ø负责对缺陷进行设计开发和内部测试

3.4.2.MQC权限

Ø可新增，修改缺陷，不能删除缺陷

Ø缺陷状态可执行：打开->已修复；打开->拒绝；重新打开->已修复。

3.5.项目经理

3.5.1.职责

Ø负责对缺陷库中所有的问题进行跟踪处理。

Ø每天对新增的挂起类问题进行处理，标注处理意见，更新其状态。

Ø定期对缺陷库分析，找出常出错的模块，进行代码审查。

3.5.2.MQC权限

Ø可新增，修改缺陷，不能删除缺陷

缺陷状态可执行：任何状态->任何状态

3.6.需求方专家

3.6.1.职责

Ø对存在业务不理解与需求不明确的问题给出修改建议。

Ø对开发方与客户方存在分歧的问题给出修改建议。

3.6.2.MQC权限

Ø可新增，修改缺陷，不能删除缺陷

Ø缺陷状态可执行：已修复->关闭、重新打开；拒绝->无效、挂起、重新打开；

挂起->打开、关闭。

3.7.配置管理员

3.7.1.职责

Ø负责从开发人员处获取最新程序代码，发布测试环境并确定版本，以及该版本更新的内容。

Ø一个版本经测试人员测试完毕后，配置管理员从MQC中获取该版本出现的缺陷，与下一次的版本更新内容做对比，进行版本管理和版本控制。

Ø对在多个版本反复出现的问题进行跟踪。

3.7.2.MQC权限

Ø可新增、修改缺陷

Ø缺陷状态可执行：已修复->关闭、重新打开；拒绝->无效、挂起、重新打开；

挂起->打开、关闭。

3.8.QA

3.8.1.职责

Ø质量管理人员负责对整个缺陷流程的跟踪。

Ø负责指导流程相关方正确使用需求跟踪工具MQC。

Ø负责提供《缺陷状态报告》。

3.8.2.MQC权限

Ø可新增、修改、删除缺陷。

Ø缺陷状态可执行：任何状态->任何状态。

3.9.浏览者

3.9.1.职责

Ø对有查看要求的人员赋予该职责

3.9.2.MQC权限

Ø不可新增、修改、删除缺陷。

Ø缺陷状态可执行：无

4.缺陷提交规范

4.1.缺陷提交原则

缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查缺陷描述，检查是否描述清楚了缺陷，具体要求为：

Ø问题描述一般格式：问题描述时，建议分几步描述：模块或功能点=>测试步骤=>期望结果=>实际结果=>其它信息，可依实际情况调整；

Ø简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；

Ø再现：问题必须在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）；

Ø复杂的问题应附截图补充说明或直接通知指定的修改人

Ø报告中不允许使用抽象词句：比如“有错误”、“是不是？”“请开发人员确认”等等之类；

Ø有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在缺陷报告中标识；

4.2.缺陷填写要求

（1）问题摘要：必填，要求简单扼要的描述缺陷出现的以及缺陷的特征。

（2）已分配给：必填，新提交的问题分配给相应的开发人员。

（3）检测人：问题提交者，默认为自己。

（4）检测版本：必填，问题最开始发现的软件版本号，对应开发的版本号。

（5）测试日期：问题最开始提交的时间，默认为当天。

（6）紧急程度：由开发组长填写，问题要求解决的优先级，越高表示开发尽快修复问题。

（7）严重程度：必填，问题本身的严重级别，越高表示越严重（严重级别请以项目划分的严重级别规则进行划分）。

（8）问题状态：问题的状态，新提交时默认为“新建”。

（9）主题：必填，问题属于哪个模块，关联测试计划根目录。

（10）问题描述：必填，详细描述问题，描述中必须包括预期结果和实际结果，尽量附图，如有建议，写出修改建议。

（11）问题类别：必填，问题实际发生的原因。

（12）问题处理意见：项目人员对缺陷给出处理的建议，均可读写。

（13）项目经理处理意见：项目经理对缺陷给出处理的建议，只有项目经理可写。

（14）需求方处理意见：需求方专家对缺陷给出处理的建议，只有需求方专家可写。

Ø缺陷描述规范

摘要简练描述什么模块出现什么类型的错误

描述以什么用户登录系统执行什么操作

产生什么错误结果

缺陷管理流程

第9页/共9页

预期结果

截图 提供错误页面的截图，附在缺陷中

Comment 交流缺陷修改情况

5.附录

5.1.缺陷属性定义