缺陷跟踪流程管理—角色分解
缺陷管理流程
缺陷管理流程文件编号：缺陷管理流程修改履历修改编号版本修改条款及内容修改日期1 V0.1 初稿目录1.概述 (4)1.1目的 (4)1.2适用范围 (4)1.3角色职责 (4)1.4入口标准 (4)1.5输入 (4)1.6输出 (4)1.7出口标准 (4)2.流程 (5)2.1流程图 (5)2.2流程说明 (5)2.2.1提交问题 (5)2.2.2分析定位缺陷 (6)2.2.3修改缺陷 (6)2.2.4验证缺陷 (6)2.2.5统计数据 (6)2.2.6测试监控 (6)3.缺陷定义 (7)3.1.1缺陷状态 (7)3.1.2缺陷类型 (7)3.1.3缺陷严重级别 (7)3.1.4缺陷优先级别 (8)4.度量指标 (8)5.沟通机制 (9)1.概述1.1目的本文为缺陷管理模块缺陷跟踪处理流程介绍及操作指南，目的是对测试室在进行缺陷管理的过程中提供参考。
1.2适用范围本流程适用于银行测试缺陷管理工作。
1.3角色职责角色（岗位）职责测试执行岗1.执行测试工作，负责提出新问题，并对开发岗已修改的问题进行验证开发岗 1.负责对待修改的问题进行修复需求分析岗1.分析缺陷，并为测试方和开发方在缺陷有效性的分歧上，进行仲裁测试主管岗1.测试执行过程中，对缺陷提交情况、修复情况进行监控1.4入口标准正式执行测试，测试方发现问题1.5输入测试用例1.6输出含结果测试用例缺陷跟踪表1.7出口标准完成测试，所有问题进行修复验证或其他方式处理缺陷数量按版本呈明显收敛趋势遗留缺陷不能大于有限缺陷的8%2.流程2.1流程图缺陷管理流程输出需求分析岗开发岗测试执行岗输入提交新问题待确认打开问题修改问题待修改验证中待验证是否通过修改确认通过测试用例含结果测试用例缺陷跟踪表退回修改是否修改问题待修改待验证确认为开发问题确认是否为缺陷是仲裁分歧是否为程序缺陷是否需求缺陷修改确认通过无效缺陷关闭2.2流程说明2.2.1提交问题测试执行岗在执行测试中，若发现问题，登录缺陷管理系统进行新问题的提交，描述问题时必须详细（必要时需附上截图），确保内容正确，定位准确。
bug跟踪管理系统bug跟踪流程
bug跟踪管理系统 bug跟踪流程Bug跟踪流程1. 目的本文档主要是为了规范产品缺陷的跟踪解决、保证每个发现的缺陷都能有效跟踪，直到缺陷解决关闭。
2. 适用范围本文档适用于公司所有产品的缺陷跟踪。
需要测试、软件开发人员、硬件开发人员协调执行。
3. 角色和职责 3.1 测试工程师测试工程师负责问题提交、问题验证。
测试工程师不能把new状态、reopen状态的bug更改为fixed等其他状态。
测试工程师不能把没有修改的问题直接关闭。
测试工程师要及时验证问题，确保问题的及时关闭；如果验证不通过的问题要及时reopen，以便软件工程师能尽快了解情况，尽快解决问题。
3.2 开发工程师软、硬件工程师负责修改问题，在问题修改完把问题状态修改为fixed状态。
如果软、硬件工程师认为是非问题的，要及时和测试工程师讨论决定，如果不能形成一致意见的，可以上报上一级主管讨论。
如果经过讨论后一致认为不是问题的可以置为Invalid，或者确认是问题、讨论后决定不修改的问题可以置为wontfix, 然后由问题提交人关闭问题。
如果软、硬件工程师自己发现问题，原则上要求软、硬件工程师自己提交问题，把问题纳入跟踪。
软、硬件工程师不能关闭不是自己提交的问题。
3.3 缺陷库管理员缺陷库管理员一般由测试主管兼任，负责缺陷库的日常管理、维护。
在特殊情况下可以直接关闭部分问题（例如软件或硬件、测试一致同意关闭的问题）。
4. Bug跟踪流程流程图：过程说明：A．New bug：测试人员、市场反馈的问题由测试人员填写bug。
开发人员发现的问题由开发人员填写。
Bug填写完成后提交给相应的软、硬件开发人员。
Bug填写要求见“bug填写规范”。
B．Fix bug：开发人员修改自己负责的bug；修改完成并合入版本后把bug的状态修改成fixed。
C．Close bug：问题验证通过后，由问题提交人关闭bug。
D．Reopen：问题验证没有通过，发现问题还存在，或者问题只修改了一部分，则重新打开这个bug。
(完整版)Bug管理规范及流程
时间 2022.6.19版本1.0 创建人Bug 属性规范及流程 (1)1. 目的 (3)2. 范围 (3)3. 工具 (3)4. 角色和职责 (3)5. Bug 属性定义 (4)5.1．bug 类型 (4)5.2．bug 严重性 (5)5.3 bug 优先级 (5)6. Bug 管理流程 (6)6.1 提交 bug (6)6.2 分配 bug (6)6.3 解决 bug (7)6.4 验证 bug (7)6.5 遗留 bug (7)6.5.1 跟踪遗留 bug (7)6.5.2 产品发布后发现的 bug (8)6.6bug 分析 (8)本文档定义 bug 的整个生命周期，规范 bug的解决方案及管理流程。
Bug 在流转的过程中有章可循。
规范 bug 严重等级与 bug 解决优先级，使开辟人员与测试人员能根据此文档准确判断 bug的严重程度并加以解决；禅道：序号010203角色测试工程师开辟负责人开辟工程师职责1) 提交 bug ，用 bug 级别反映 bug的严重程度2) 验证 bug 是否已被解决1) 确认 bug ，并进行 bug 分配2) 分析 bug 修复进度，对项目的质量、进行风险评估1) 修改 bug，并备注处理方式开辟人员、测试人员属性名称来源bug 类型严重性优先级标题描述附件概率Bug 类型功能Ui接口性能其他描述包含所属产品、所属模块、所属项目、影响版本，选择bug 来源利于开辟定位并解决；根据 bug 的自然属性划分的 bug 种类因 bug 引起的故障对软件产品的影响程度Bug 必须被修复的紧急程度用一句简洁的语言将问题的核心描述出来详细描述 bug浮现的步骤和结果为 bug 添加更核心的说明，更有说服力的证据，包括截图、视频、 log 等描述 Bug 复现的概率描述产品功能方面的 bug ：包括模块功能实现、功能使用性、逻辑性等 bug UI 表现，包括对话框样式和文字描述问题与其他组件、模块或者设备驱动程序、调用参数、控制块或者参数列表相互影响的 bug不满足系统可测量的属性值，如：并发量、数据量、事务处理速度等设计、安装、挪移性等Bug 严重性致命(1)严重(2)普通(3)优化(4)Bug 优先级紧急(1)高(2)中(3)低(4)描述不能执行正常的功能操作，或者因产品原因导致系统死机，需即将修复的问题部份功能存在严重缺陷，尚可继续测试，不影响产品稳定性；次要功能或者界面存在的一些错误，不影响正常测试；测试对于产品的一些改进建议；描述影响测试，需即将修复；必须在版本发布之前修改完；必须修改，不一定即将修改，需讨论确定在某个特定的里程碑前修改完对产品的影响比较小，在时间不允许的情况下可以暂时不修改在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。
缺陷跟踪流程
缺陷跟踪流程
缺陷跟踪流程是指在软件开发过程中，及时记录和追踪所有已发现的缺陷，并确保它们得到适当的解决和修复的一系列步骤。
以下是通常的缺陷跟踪流程：
1. 缺陷记录：当测试人员或用户发现某个软件缺陷时，他们应该立即将其记录下来。
记录应包括缺陷的描述、复现步骤、预期结果和实际结果等信息。
2. 缺陷分类和优先级评估：根据缺陷的种类和严重程度，将其进行分类，并评估其优先级。
通常，严重程度分为低、中、高三个级别，优先级分为低、中、高三个级别。
3. 缺陷分配：将每个缺陷分配给相应的责任人，通常是开发人员或相关的技术支持人员。
每个责任人应负责解决分配给他们的缺陷。
4. 缺陷解决：责任人需对分配给他们的缺陷进行解决。
这可能包括修复代码、修改配置或更新文档等。
5. 缺陷验证：在缺陷解决后，测试人员需要验证缺陷是否得到了正确的修复。
他们需要重新执行之前的测试用例，以确保修复后的软件没有其他问题。
6. 缺陷关闭：当缺陷已被修复并通过验证后，缺陷被标记为已关闭。
通常会记录关闭的原因和关闭的版本号。
7. 缺陷反馈和文档更新：在解决和关闭缺陷的过程中，可能会发现一些对软件改进或文档更新的建议。
这些建议需要被反馈给相应的团队成员，并对文档进行相应的更新。
8. 缺陷报告和分析：定期生成缺陷报告，包括缺陷的数量、状态、分类和解决情况等。
对这些报告进行分析可以帮助团队发现软件开发过程中的潜在问题，并采取相应的措施进行改进。
以上是一个简化的缺陷跟踪流程，具体的流程可能会因组织或项目的需求而有所不同。
测试缺陷跟踪处理规程-9.06
文件会签页___________ 签名审核 —部门____________ 签名_____ 审核 —部门 ____________ 签名 ____________ 审核 ____________ 部门____________ 签名 ____________ 审核 ____________ 部门 ____________ 签名 ____________ 审核部门签名 审核 部门I____________ 签名 ____________ 审核部门____________ 签名签名 生效日期:文件标题测试缺陷跟踪处理规程 会签文件编号I分发清单签名 编制 部门签名 审核 部门 签名 审核 部门 签名 审核 部门 签名 审核 部门 签名 审核 部门 签名 审核 部门 审批批准 □霍生口张工□集团综合办公室 □集团人力资源部□采购中心 f □ 制造中心□ 供应商管理□ 生技部□ 生产物料采购 □ 部件部 □ 工程物料采购□ 机加工□ 整机一部 □运营中心 □ 整机二部 □ * 无优运营部□ 整机三部 □ 天馈运营部□ 整机四部 曲口 射频部件运营部 □ 天线一部 -□ 无线传输与接入□ 天线二部运营部 □ 天线三部 □ 物控中心□ 功放生产部□ 射频部件部 □ 供应链体系质检部 □ 无线传输与□ 新产品导入办公室接入生产部□广州研究部 □ 功放研发部□ 南京研究所 □ 天馈事业部□覆盖接入产品研发部□无线优化产品事业部 □无线传输与接入事业部□无线解决方案部□ 网管业务中心 □ 企业合作部 □ 质量技术中心 □ 信息中心 □ 系统公司 □ 京信国际加盖受控章文件历史记录1.目的.......................... . (1)2.范围 (1)3.术语和定义 (1)4.角色与职责.................... Jr1 J f y5.缺陷定义和属性 (2)5.1缺陷定义 (2)5.2缺陷属性 (3)5.3缺陷类型 (3)y5.4缺陷等级 (3)5.5缺陷状态 (5)5.6缺陷完成度 (5)6.缺陷管理工具 (6)7.测试缺陷跟踪处理流程 (6)7.1 准入 (6)7.2 输入 (6)7.3 测试缺陷跟踪处理流程图 (6))7.4 流程说明 (7)7.5 输出 (9)7.6 准出 (9)缺陷跟踪处理规程1. 目的规范测试过程中的缺陷跟踪处理活动、确保发现缺陷得到有效及时处理。
缺陷跟踪流程
一、过程描述测试人员按照测试用例逐项进行测试活动，并对测试结果不通过的填写缺陷单，并针对缺陷整个生命周期进行跟踪。
二、角色定义测试人员：负责具体测试执行及跟踪人员在测试过程中发现的缺陷，填写缺陷报告并通过缺陷管理工具提交给项目经理，对开发人员修改后的缺陷进行返测，确认缺陷修改是否正确；对于非Fixed的问题，仍需进行二次确认。
测试组长：负责测试执行及跟踪，包括BUG单的一次审阅。
除了同测试人员一样的职责外，还需对已经提交到QC中的BUG单进行一次审阅，保证提交的BUG都是有效BUG，此过程在流程图中不体现出来。
项目经理：对测试人员提出的BUG进行审核及分配。
对新提交及重新Open的缺陷进行审核及分配，包括对ＢＵＧ解决时效及是否有效BUG进行判定；并对开发人员的解决方案负责。
开发人员：对分配到个人的BUG进行解决。
对项目经理分配的缺陷进行判断及修订，同时具备对提交错误的缺陷具有拒绝修改的权限。
三、状态定义1.New（新）：测试人员提交BUG的初始化状态；责任人：项目经理2.Open（打开）：项目经理分配到开发人员；责任人：开发人员3.Delay（延迟）：项目经理判定该BUG延迟解决；责任人：项目经理4.Reopen（重新打开）：测试人员验证未通过重新打开；责任人：项目经理5.Fixed（已解决）：开发人员已解决；责任人：开发人员6.Close（已关闭）：测试人员验证已修复；责任人：开发人员7.Rejected（拒绝修改）：项目经理或开发人员验证该BUG提交错误或其它原因拒绝修改；责任人：测试人员或项目经理8.Cancel（取消）：项目经理认为该BUG为此项目中没有必要修改的问题，但并非BUG提交错误的情况下，可将此BUG置为Cancel；责任人：项目经理。
注意：在以下流程图中，仅在状态变更为Open、Reopen、Rejected时，需要变更责任人，变更为其它状态时，均不需要变更责任人。
四、控制流程图缺陷控制图缺陷跟踪控制流程第2页。
软件测试教学PPT-缺陷跟踪管理
（八）缺陷跟踪管理
本章要点
缺陷管理地目地与意义 缺陷管理工具地分类 缺陷管理工具地使用
缺陷管理工具概述
缺陷管理地目地与意义 缺陷地跟踪管理一般而言有如下目地: 确保每个被发现地缺陷都可以被解决,这里解决
地意思不一定是被修复,也可能是其它处理方式 （例如,在以后地版本修复或是不修复）,总之, 对每个被发现地Bug地处理方式需要可以在开发 组织达到一致; 收集缺陷数据并根据缺陷趋势曲线识别测试过 程地阶段;决定测试过程是否结束有很多种方式, 通过缺陷趋势曲线来确定测试过程是否结束是常 用并且较为有效地一种方式; 收集缺陷数据并在其上行数据分析,作为组织地 过程财富。
查询Bug
生成报表
问题跟踪工具JIRA
JIRA地特点
灵活可配置地工作流。提供用于缺陷管理地默认工作流。工作流可以 自定义,工作流数量不限。每个工作流可以配置多个自定义动作与自 定义状态。每一个问题类型都可以单独设置或用工作流。可视化工作 流设计器,使工作流配置更加直观。自定义工作流动作地触发条件,工 作流动作执行后,自动执行指定地操作。
期望结果。 Priority:Bug优先级,取值包含Highest,High,Medium,Low与Lowest。 Labels:填写该字段有助于以后过滤出特定类型地Bug。 Linked Issue:选择依赖或者被依赖地Bug。 Assignee:负责解决Bug地。 Epic Link:Bug所属地Epic。 Sprint:Bug所属地Sprint。
缺陷管理工具概述
缺陷管理工具地分类 纯粹地缺陷管理工具: Bugzilla,Bugzero属于这一类,它们可以
为软件组织建立一个完善地缺陷跟踪体系, 包含报告缺陷,查询缺陷记录并产生报表, 处理解决缺陷; 包含缺陷管理模块地项目管理工具 第二类是以Redmine,JIRA为代表地项目管 理工具,它们集项目计划,任务分配,需求 管理,缺陷跟踪于一体,功能强大,易于使 用。缺陷管理作为其地一个子功能而发挥 作用。
缺陷管理流程
缺陷管理流程缺陷管理是软件开发过程中非常重要的一环，它涉及到对软件中出现的问题进行有效的识别、记录、跟踪和解决。
一个完善的缺陷管理流程能够帮助团队及时发现和解决问题，提高软件质量，保障项目顺利进行。
下面将详细介绍一套完整的缺陷管理流程。
1. 缺陷识别。
缺陷识别是缺陷管理流程中的第一步，团队成员需要通过测试、代码审查、用户反馈等渠道来发现软件中存在的问题。
在这个阶段，需要将问题准确描述，并尽可能地重现问题，以便后续的跟踪和解决。
2. 缺陷记录。
一旦发现问题，团队成员需要将问题记录在缺陷管理系统中，包括问题的描述、重现步骤、影响范围、严重程度等信息。
同时，还需要为每个问题分配一个唯一的标识符，以便后续的跟踪和查询。
3. 缺陷确认。
在记录缺陷之后，团队需要对问题进行确认，确保问题的存在并且可以被复现。
只有经过确认的问题才能够进入后续的处理流程，否则将被标记为“无法复现”并关闭。
4. 缺陷分析。
经过确认的问题将进入缺陷分析阶段，团队需要对问题进行深入分析，找出问题的根本原因。
这个阶段需要开发人员、测试人员、产品经理等多方参与，以确保问题分析的全面性和准确性。
5. 缺陷解决。
在分析清楚问题原因之后，团队可以着手解决问题。
开发人员根据分析结果进行代码修改，测试人员进行验证，直到问题得到解决。
在这个过程中，需要及时更新缺陷管理系统中的问题状态，并记录解决方案。
6. 缺陷验证。
解决问题之后，测试人员需要对问题进行验证，确认问题是否得到了彻底解决。
只有经过验证的问题才能够被关闭，否则将被重新打开并继续处理。
7. 缺陷跟踪。
即使问题得到了解决和验证，团队也需要对问题进行跟踪，确保问题不会再次出现。
此外，还需要对问题的解决过程进行总结和反思，以便在未来的项目中避免类似问题的发生。
以上就是一套完整的缺陷管理流程，通过严格执行这个流程，团队可以及时发现和解决问题，提高软件质量，保障项目顺利进行。
同时，缺陷管理流程也需要不断地进行优化和改进，以适应不断变化的项目需求和团队情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试组长
开发组长
开发人员 （缺责任人）
缺陷跟踪管理流程
分配给
开始状态
测试组长 O
测试组长 测试组长 测试组长
O O 测试人员 测试人员 测试人员 测试人员 测试人员 开发组长 开发组长 开发人员 开发人员 开发人员 测试组长 测试组长 测试组长 测试组长 O 开发组长 开发组长 开发组长 开发组长
关闭已重复的缺陷 关闭已否决的缺陷 分配给测试人员验证缺陷 重新分配缺陷的验证对象（测试人员）
发现缺陷已重复 将已否决的缺陷分配给测试人员 将已重复的缺陷分配给测试人员
将新建的缺陷分配给开发组长 将验证失败的缺陷分配给开发组长重新修改
将缺陷分配给开发人员 重新分配缺陷的修改对象（开发人员） 缺陷验证失败，需要开发人员重新修改缺陷
缺陷已经修正 不是缺陷，否决
缺陷重复 缺陷重复 由于某种原因（如：功能未实现、当前版本无法修改），此缺陷需要延迟修改 缺陷已经修正 缺陷重复 不是缺陷，否决 重新分配缺陷的修改对象（开发人员）
X 已修改 已修改 已修改 已否决 已重复 已否决 已修改 重新分配 新建缺陷 已否决 已重复 新建缺陷 重新修改 新建缺陷 重新分配 重新修改 已修改 已否决 已重复 新建缺陷 新建缺陷、重新修改 修改缺陷 修改缺陷 修改缺陷 修改缺陷
“X”—>“无状态”，“O”—>“自己”
缺 陷 跟 踪 管 理 流 程 —— 角 色 分 解
结束状态
新建缺陷 关闭
重新分配 重新修改 重新修改
关闭 关闭 已修改 已修改 已重复 已否决 已重复 新建缺陷 重新修改 修改缺陷 修改缺陷 修改缺陷 已修改 已否决 已重复 已重复 暂缓处理 已修改 已重复 已否决 重新分配
，“O”—>“自己”
理 流 程 —— 角 色 分 解
备注
发现系统错误， 新建缺陷 关闭已经验证通过的已修改的缺陷 发现缺陷不是自己的缺陷、或者其他的测试人员有同样的缺陷，需要组长重新分配 缺陷验证失败，需要开发人员重新修改缺陷 的确为缺陷，请开发人员重新修改