软件测试缺陷管理流程图
Bug状态流程
-Yang
Bug状态流程图 Bug状态流程图
Bug 处理流程
开发组长/ 开发组长/经理 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产 品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是 留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出 留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出 错的模块，进行代码审查。 开发人员 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B Major类或紧急程度 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度 3-High类以上（包含）bug5个或5个以上，停止新功能的开发。 High类以上（包含）bug5个或5 需求人员 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计 划 测试人员 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解 测试组长/ 测试组长/经理 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测 趋势。在测试总结报告中给出意见 产品人员 可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺
新Bug 复测时新出现的Bug 偶发性 原来修改过的问题又重新出现 需求要求但没有做的功能 需求需要完善 与需求不一致 设计要求但没有做的功能
BUG管理规范与流程图
. BUG管理流程与规目录1概述 (5)1.1编写目的 (5)1.2适用围 (5)2关键角色及应负责任 (5)3BUG流程图 (6)4活动描述 (6)5BUG书写规 (8)5.1测试人员BUG提交 (8)5.1.1主题 (8)5.1.2步骤 (8)5.1.3实际结果 (8)5.1.4预期结果 (8)5.1.5备注 (9)5.2开发人员解决BUG (9)6BUG严重等级 (10)6.1致命 (10)6.2严重 (10)6.3一般 (11)6.4优化 (11)7BUG优先级 (12)7.1紧急 (12)7.2高 (12)7.3中 (12)7.4低 (12)8BUG解决方案 (12)8.1设计如此 (12)8.2重复BUG (12)8.3已解决 (12)8.4无法重现 (12)8.5延期处理 (12)8.6新增/变更需求 (12)9BUG状态 (12)9.1激活 (12)9.2已解决 (13)9.3关闭 (13)10其他要求 (13)11相关文件 (13)12附件 (13)1概述1.1编写目的本文档定义bug的整个生命周期，规bug的管理流程。
Bug在流转的过程中有章可循。
规bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug 的严重程度并加以解决。
1.2适用围本文档适用测试人员、开发人员。
2关键角色及应负责任5BUG书写规5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。
软件测试管理制度
软件测试管理制度XXX软件测试管理制度编写目的本文档旨在规范公司软件测试管理流程，明确测试团队的组织结构、职能和职责划分，以及测试流程和规范。
测试团队构成2.1 组织结构公司测试团队由测试经理领导，下设若干测试组，每个测试组由一名测试组长带领，测试人员根据项目需要分配到不同的测试组。
2.2 测试组职能测试组主要负责测试计划的制定和执行，测试用例的编写和执行，缺陷的管理和跟踪，测试报告的撰写和提交。
2.3 职责划分测试经理负责测试团队的整体管理和协调，测试组长负责测试组的日常管理和指导，测试人员负责按照测试计划执行测试任务，及时发现和报告缺陷。
测试流程及规范3.1 测试流程图测试流程分为计划与设计阶段、执行阶段和验收阶段。
每个阶段的具体流程如下图所示。
插入测试流程图）3.1.1 Bug状态流程图缺陷的状态分为新建、已分配、已解决、已验证和已关闭。
具体状态转换如下图所示。
插入Bug状态流程图）3.2 计划与设计阶段3.2.1 立项会议在项目立项会议上，测试经理与项目经理一起确定测试计划和测试目标，制定测试用例和测试环境要求，明确测试人员和测试工具的需求。
以上是对文档格式错误和明显有问题段落进行了删除和改写，使得文章更加清晰明了。
3.2.2 需求评审在需求评审阶段，测试团队需要与业务分析师和开发团队一起审查需求文档。
测试团队应该关注以下方面：是否有明确的需求文档，是否有可测试的需求，是否有任何不一致或模糊的需求，是否有未解决的问题或疑问。
测试团队应该在这个阶段提出任何关于需求的问题，并确保所有问题得到解决。
3.2.3 测试设计阶段在测试设计阶段，测试团队需要确定测试用例、测试数据和测试环境。
测试用例应该覆盖所有的需求，并且应该针对每个需求编写至少一个测试用例。
测试数据应该是真实的，并且应该涵盖各种情况。
测试环境应该与生产环境相同，以确保测试的准确性。
3.2.4 设计内容评审在设计内容评审阶段，测试团队需要与开发团队一起审查测试设计文档。
软件测试缺陷管理流程图
缺陷管理流程图是为了有效的跟踪，管理bug的处理情况，指导测试团队和开发人员有效的处理相关的bug。
不同角色的人，对bug处理的权限不一样，我们需要借助类似缺陷管理工具比如：QC进行实施。
下面就不同角色的人主要的只能进行简单说明：
测试人员：提交bug，并对修复的bug进行审核；
测试组长：审核bug，并将bug提交给开发组长；
开发组长：将确认正确的bug分配给相应的开发人员；
开发人员：修复开发组长分配的bug。
具体的测试流程，请参见图1 缺陷管理流程图：
每个状态表示的具体含义说明如下：
不断的总结，才能不断的提高；不断的思考，才能不断的进步！。
缺陷管理过程中bug流向示意图
缺陷管理过程中bug 流向示意图Bug 由测试人员发现并上报，最终状态还要落回到测试人员。
说明：1. new ——》fixed ——》closetester 发现新问题，developer 修改问题（fixed ），tester 验证问题通过，关闭bug 。
2. New ——》fixed ——》open ——》fixed ——》closeTester 发现新问题，developer 修改问题（fixed ），tester 验证问题没有通过（open ），developer 再次修改问题（fixed ），tester 验证问题通过，关闭bug 。
3. New ——》worksforme ——》invalidTester 发现新问题，developer 发现问题不能重现（worksforme ），且由于tester 自身操作错误引起，tester 将此bug 置为invalid ，此bug 无效。
4. New ——》worksforme ——》laterTester 发现新问题，developer 发现问题不能重现（worksforme ），或只能偶尔复现，在不影响进度的前提下，tester 可暂时将此bug 置于later ，表示之后版本或指定时间修改。
5. New ——》worksforme ——》open ——》fixed ——》closeTester 发现新问题，developer发现问题不能重现（worksforme），经过测试人员演示，问题确实存在，但在之后的版本可能由于其他bug的修改致使此bug也被修改，tester重新open这个bug给developer，进入fixed ——》close流程。
6. New ——》Duplication ——》invalidTester 发现新问题，developer发现这个问题已经有原理类似的bug或完全一致的bug，则将此bug置为Duplication，表示重复了，tester确认是否真的和其他bug重复，如果是，就将此bug置为invalide。
缺陷处理流程
缺陷处理流程1缺陷处理流程1.缺陷处理流程图如下：2.缺陷处理流程图中判定说明：1)是否打开缺陷：开发组长/经理查阅缺陷，确认为缺陷后，指定优先级、估计修复日期再指派给相关开发人员；如果确认为不是缺陷的，注释中说明理由，予以否决。
2)处理缺陷：开发处理缺陷；如果缺陷短期内进行修复存在困难，且该缺陷对于功能实现影响不大的，应该给开发组长/经理说明情况，让开发组长/经理与缺陷相关人员协调后延期处理该缺陷，并在注释中说明理由，估计修复日期和指明计划关闭版本。
3)是否关闭：测试人员对回归通过的缺陷进行关闭；否则重新打开缺陷。
并在注释中说明重新打开理由。
3.缺陷处理流程图中流程说明：1)新建缺陷：测试人员（其他人员）根据缺陷填写说明，新建缺陷。
2)已否决：对已否决的缺陷，最后由测试发起会议（形式可以根据情况而定），找到缺陷相关人员进行确认。
如果确认为是无效的缺陷，保持“已否决”状态，否则重新打开缺陷，并指派给相关处理人员。
3)（重新）打开：开发人员应该处理自己手上“打开”和“重新打开”的缺陷。
4)延期处理：开发组长/经理根据情况，对缺陷进行延期处理。
5)已经修复：开发人员处理完缺陷后，把缺陷状态改为“已修复”状态。
并通知测试人员进行回归。
6)回归测试：测试人员对已经修复的缺陷进行回归。
7)关闭缺陷：测试人员回归测试通过后，对缺陷进行关闭。
4.为了说明各个角色在缺陷处理流程中的职责，据测试流程所画泳道图如下：如果上面判定和流程中，某一方存在异议的，应及时反馈上级。
然后上级根据缺陷优先级、实际情况等，找恰当的时间发起会议（或其他）的方式找到缺陷相关人员进行沟通、协调和处理。
2缺陷填写说明1.BUG全部提交到QC中（指定域名的指定项目下）。
2.“摘要”，用简单明了的语句说明白你这个BUG，相当于BUG的中心语句。
3.详细信息填写规范：1)“分配给”，选择这个BUG所属模块是属于那个研发人员，并把问题指派给他（如果不知道，就直接提交给该负责人）。
软件缺陷管理流程图
软件缺陷管理办法1.目的本文档定义了软件缺陷管理流程和相关规则，确保软件缺陷管理的系统性和规范性，以保证项目研发质量。
2.适用范围适用于部门项目研发过程的缺陷管理，对各阶段的缺陷管理过程进行指导和规范。
3.定义3.1 术语缺陷（Defect）：存在于软件之中偏差，可被激活，以静态形式存在于软件内部。
Bug：缺陷一种表现形态，系统或程序存在的任何一种破坏正常运转能力的问题。
3.2 缺陷定义（1）软件未达到需求规格说明书的功能；（2）软件出现了需求规格说明书指明不会出现的错误；（3）软件功能超出需求规格说明书的范围；（4）软件未达到需求规格说明书未指出但应达到的目标；（5）测试工程师认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
4.缺陷生命周期4.1 缺陷生命周期图4.2 缺陷状态说明5. 缺陷处理过程5.1 正常处理过程（1）创建问题在测试管理系统中，所有用户都可以创建新问题，包括需求问题和软件缺陷等。
创建问题时，需要描述清楚，并选择正确的选项，详细请参考5.4和5.5。
（2）指派问题创建问题时，创建者通常要指派给该项目开发负责人，再由其指派任务，或直接指派给相应模块的开发工程师。
如果指派人是错误的，或者需要他人确认或帮助，则可以重新指派给合适的工程师，写上相关备注。
（3）确认问题通常开发工程师收到新问题后，需要分析和确认此问题是否为Bug。
如果是Bug，则选择“确认状态”；如果认为非Bug，则注明原因并指派回创建者。
当创建者收到确认指派时，需要进行及时确认。
如果同意为非bug，则及时关闭它；如果不同意，则需要注明理由并指派回相关工程师。
如果问题确认指派次数大于6次时，需要进入“争议处理”流程，详细请参考5.2。
（4）解决问题此为开发工程师的主要职责，包括Bug的复现、修改和修改验证。
开发工程师需要及时对确认状态Bug进行分析和解决，并自己验证通过，则操作为解决状态，解决方案规则请参考5.4中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。
软件缺陷管理制度
软件缺陷管理规定1 目的缺陷是产品与规定要求不相符的部分。
软件缺陷是开发、评审、测试和使用的过程中，发现的软件产品与用户需求，设计要求不符的部分，这些部分造成使用不方便或在某种程度上不能满足用户的要求。
软件缺陷的同义词有：bug，issue，defect，问题等，这里通称为缺陷。
缺陷会存在于软件产品的整个生命周期中：可以是软件代码的问题、系统文档（开发文档和测试文档等）存在的问题，或者是用户的帮助文档和使用指南方面的问题等。
本文规定了软件缺陷登记跟踪处理的完整过程规范。
2 范围适用于软件的整个生命周期。
不限于测试过程发现的缺陷。
评审，用户使用等过程中发现的缺陷都是应当按照本流程进行登记跟踪管理。
3 职责3.1 测试工程师：在这里主要是指发现和报告缺陷的测试人员。
在一般流程中，他需要对这个缺陷后续相关的状态负责：包括相关人员对这个缺陷相关信息的询问回答，以及验证测试。
3.2 开发工程师：这里主要指对这个缺陷进行研究和修改的开发人员。
同时，他需要对修改后的缺陷在提交测试人员正式测试验证之前需要进行验证测试。
3.3 其他参与人：主要有项目负责人、测试经理、用户等组成。
他们对缺陷进行优先级划分，负责人进行确认并调解争议。
3.4 配置管理员：负责缺陷库的创建和权限管理，并监督指导缺陷库的定制。
4 缺陷管理流程缺陷管理流程图，下图描述缺陷管理的工作程序，缺陷的生命周期状态。
4.1 登记缺陷发现后，由测试人员登记到缺陷库。
具体项目也可以允许用户向缺陷库提交缺陷。
缺陷登记后，提交前可以反复编辑，补充缺陷记录的信息。
测试人员必须保证登记的缺陷信息可以被处置负责人员理解，具体要求参见5.10登记后的缺陷状态是“新”。
4.2 提交测试人员确认缺陷已经表述清楚，可以提交缺陷。
提交后的缺陷状态是“已提交”缺陷提交前必须分配一个具体的开发人员负责，如果测试人员不确定谁负责，可以把缺陷分配给测试经理或项目负责人，再由他们重新分配负责人。
软件测试的5个基本流程图
软件测试的5个基本流程图软件测试是软件开发过程中至关重要的一环，可以帮助开发人员发现和解决潜在的问题和错误。
在进行软件测试时，遵循一定的流程和方法可以确保测试的有效性和可重复性。
本文将介绍软件测试的五个基本流程，并提供相应的流程图。
1. 需求分析和测试计划软件测试的第一个基本流程是需求分析和测试计划阶段。
在这个阶段中，测试团队与产品负责人合作，了解软件的需求和功能。
测试团队根据需求文档或者其他相关文档编写测试计划。
测试计划包括测试的范围、测试目标、测试策略、测试资源等内容。
流程图如下：graph TDA[需求分析和测试计划阶段]A --> B[了解软件的需求和功能]A --> C[编写测试计划]2. 测试设计和测试用例在需求分析和测试计划阶段完成后，测试团队开始进行测试设计和编写测试用例。
测试设计阶段包括根据需求和功能设计测试方案，确定测试的覆盖范围和测试的方法。
测试用例是测试工作的核心，它描述了不同场景下的输入、操作和预期的输出结果。
流程图如下：graph TDA[测试设计和测试用例阶段]A --> B[根据需求和功能设计测试方案]A --> C[编写测试用例]3. 环境准备和测试执行测试设计和测试用例阶段完成后，测试团队开始进行环境准备和测试执行。
环境准备阶段包括搭建测试环境、准备测试数据和测试工具等。
在测试执行阶段，测试团队根据测试计划和测试用例执行测试，记录测试结果，并将测试结果进行整理和分析。
流程图如下：graph TDA[环境准备和测试执行阶段]A --> B[搭建测试环境]A --> C[准备测试数据和测试工具]A --> D[执行测试]A --> E[记录测试结果]A --> F[整理和分析测试结果]4. 缺陷管理和缺陷修复在测试执行阶段，测试团队可能会发现软件中的缺陷或问题。
在这个阶段，测试团队需要进行缺陷管理和缺陷修复。
缺陷管理包括缺陷的提交、缺陷的跟踪和缺陷的验证。
软件测试教学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. SPDM需要每天查询owner为自己的Bug，确认bug是否属于本部门。如果是，根据Bug 的实际描述分配给TL/Feature owner，重新定义Bug解决优先级别以及计划解决Bug的 due date；如果不是，需要和HPDM沟通确认后再修改owner department为HW/ME
14.HWVersion:发生Bug的硬件版本
15.FoundMethod：Bug的发现途径，具体定义参考附录“FoundMethod definition”
16.MEVersion: SW测试部门和SW部门可选，主要是PV,HW&ME部门使用；
发生Bug的结构版本
17.Repeatable：Bug发生频率，具体定义参考附录“Frequency definition”
•Notes: •All actions which are marked by pink color are done by ST.
缺陷管理流程
•角色和职责
Roles
•Actions
SPDM
Submit
✓
Assign
✓
Postpone
✓
Open
Reopen
✓
Fail
Resolve
Release
Reject
5.确认参与了Bug管理过程培训 QA会为项目组成员培训Bug管理过程，如果是新加入到项目组的工程师且 没有参加过培训，请联系QA
缺陷管理流程
缺陷跟踪流程—状态转移图
•Action: •Submit •Assign •Open •Resolve •Release •Verify •Close
•Postpone •Fail •Monitor •Reject •Duplicate •Discard •Reopen •Re-Verify •Re-reject •Re-duplicate
CMMI质量管理体系——软件测试缺陷管理ppt课件
单缺击陷此管处理编相辑关母属版性标题样式
缺陷属性
缺陷描叙（Summary） 缺陷发现提交者（Detected By） 缺陷发现时间（Detected on Date） 缺陷严重性（Severity） 缺陷分给谁（Assigned to） 缺陷在哪个版本发现(Detected in Version) 缺陷被修改的时间（Modified） 计划修复时间（Plan fixed Data） 缺陷优先级（priority） 缺陷所属项目（Project） 是否是重现缺陷(Reproducible) 缺陷的状态(Status) 缺陷所属于的模块（subject） 缺陷详细描述（Description）
CMMI质量管理体系
——缺陷管理
中 国 领 先 的 整 合 IT 服 务 商
神州数码信息服务股份有限公司
单缺击陷此管处理编概辑念母及版目标的题样式
什么是缺陷管理？ 缺陷管理是在软件生命周期中识别、管理、沟通任何缺陷的 过程（从缺陷的识别到缺陷的解决关闭），确保缺陷被跟踪 管理而不丢失。
缺陷管理目的：对各阶段测试发现的缺陷进行跟踪管理，以 保证各级缺陷的修复率达到标准。主要实现以下目标：
软件缺陷:软件缺陷是存在于软件(文档,数据,程序)之中的那些不希望或不 可接受的偏差.其结果是软件运行于某一特定条件时出现软件故障,这时称软 件被激活.
软件故障:软件故障是指软件运行过程中出现的一种不希望或不可接受的内 部状态.比如:软件处于执行一个多余循还过程时,我们可以软件出现故障.若 此时没有适当的措施(容错)加以处理,便产生软件失效.软件故障是一种动态 行为.
5
bug管理流程-图解
状态流程图：软件错误的状态新信息(New)：测试中新报告的软件缺陷；打开 (Open)：被确认并分配给相关开发人员处理；修正(Fixed)：开发人员已完成修正，等待测试人员验证；拒绝(Declined):拒绝修改缺陷；延期(Deferred): 不在当前版本修复的错误，下一版修复关闭(Closed)：错误已被修复；人员角色new—tester（测试工程师）declined-not bug--Test Supervisor（测试主管）declined-duplicated--Test Supervisor（测试主管）open--Project Manager/Technical Manager（项目经理/技术主管）fixed—programer（工发工程师）closed—tester（测试工程师）deferred-next build--Test Supervisor（测试主管）deferred-next main release--TestSupervisor（测试主管）Bug管理的一般流程1. 测试人员提交新的Bug入库，错误状态为New。
2. 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。
如果不是错误，则拒绝，设置为Declined(拒绝)状态。
3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。
不能解决的Bug，要留下文字说明及保持Bug为Open状态。
对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。
软件错误流程管理要点为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，可以重复。
软件测试缺陷跟踪与管理PPT课件
精品ppt
16
如何更好的报告缺陷（2）
• 不要在bug report中夸大缺陷。同样，也不要太轻 描淡写了。
• 不管bug是多么的令人讨厌，别忘了是bug令人讨厌， 而不是开发人员。永远不要冒犯开发人员的努力。 使用委婉些的说法。“混乱的UI”可以被温和些改为 “不正确的UI”。这样开发人员的努力将会得到尊重。
精品ppt
34
手工软件缺陷报告和跟踪
• 表单可以容纳标识 和描述软件缺陷的 必要信息
• 书面表单的问题在 于效率比较低
精品ppt
35
自动软件缺陷报告和跟踪
精品ppt
36
缺陷跟踪工具
• 原来的软件项目开发中的缺陷跟踪都是通过 EXCEL表格的形式来完成的，这种表格虽然也可 以进行项目管理和项目执行度的交互，但效率与 实时性不高，同时也不好维护和统计，因此就出 现了缺陷跟踪系统，通过软件技术来解决软件项 目的管理问题。
• 目前缺陷跟踪系统还是比较多的，比较有名的像 Mercury的TestDirector，Seapine的Test Track Pro，TechExcel的DevTrack，Atlassian的JIRA以 及IBM的ClearQuest。
精品ppt
37
测试跟踪工具Bugzilla介绍（1）
• Buzilla作为一个产品缺陷的记录及跟踪工具， 它能够为你建立一个完善的Bug跟踪体系， 包括报告Bug、查询Bug记录并产生报表、 处理解决、管理员系统初始化和设置四部 分。
缺陷跟踪流程
软件缺陷跟踪管理流程 软件缺陷跟踪管理流程 缺陷
• • • • • 角色释义 角色释义 缺陷状态转换 转换图 缺陷状态转换图 缺陷状态含义解释 缺陷的严重度、 缺陷的严重度、优先级和缺陷类别 遗留缺陷处理
• 缺陷评审
• 注意事项
缺陷评审
• 仲裁评审（针对各方处理有争议的缺陷）和定期的缺陷状态评审可 以放在一起进行。评审方式为组织会议进行小组评审来收集各方意 见。 评审会议由测试组长发起，并组织各方参与评审，可以参考以下列 表邀请测试服务干系人：
• 2-中： 中
次要功能没有完全实现但不影响使用。
• 3-低： 低
较小的问题，对业务流程没有或只有极小的影响。
缺陷的优先级
• 1-高： 高
尽快修复，缺陷阻碍或严重影响了其它工作，在缺陷修复前进一步 的开发和测试不能进行或系统使用受到了严重的影响。建议修复时间为 1天；
• 2-中： 中
下轮前修复，在正常的开发轮次中解决问题。建议修复时间为3天；
缺陷状态转换图
缺陷状态转换表
状态1 状态 1 角色2 角色 2 测试执行人员 状态2 状态 2 新建 角色3 角色 3 开发负责人 开发人员 开发负责人 测试执行人员 测试执行人员 测试执行人员 开发人员 测试执行人员 开发负责人 重新打开 固定 开发负责人 测试执行人员 状态3 状态 3 打开 修改完成 拒绝修改 固定 已关闭 重新打开 重新打开 已取消 修改完成 固定 拒绝修改 重新打开
• 3-低： 低
上线前修复或推迟到将来主要发布版本中修复。建议修复时间为5天 。
缺陷的类别
• 1-程序： 程序： 程序
程序不能正常执行的缺陷；
• 2-需求： 需求： 需求
与需求文档描述不符的缺陷；
JIRA-缺陷生命周期流程图
NEW
缺陷发现者发现并确认缺陷，最后提交缺陷。
POSTPONE OPEN
DUPLICATE ABANDON
PM/CCB 发现提交的缺陷是优先级低的，决
定延迟
PM/CCB 发现提交的缺陷是优先级比较高的，决定打开
缺陷
PM/CCB 发现提交的缺陷并不是真正的缺陷
PM/CCB 发现提交的缺陷和以前的缺陷重
复了
DEV （开发人员）
FIXED
TESTER （测试人员）
REOPEN
最后期限初始化
CLOSED
REJECTED
开发人员认为该缺陷不是DEFECT
PM/CBB （项目经理/变更控制委员
会）
开发人员确认该缺陷是DEFECT
在测试中后期，PM/CCB 不得不打开延迟的DEFECT
TESTER （测试人员）
回归测试未通过
回归测试通过
测试人员发现该缺陷确实是DEFEC T
测试人员发现该缺陷确实重复
PM/CBB （项目经理/变更控制委员会）
测试人员认为确实是DEFE CT
TESTER （测试人员）
测试人员发现提交的缺陷并不是真正的缺陷。
缺陷管理流程(附图)
缺陷管理流程【背景】缺陷管理流程背景：自动化报告存在失败或错误的问题，出现这些问题的原因可能是软件bug，也可能是自动化相关bug。
其中软件bug会提在现有的重构TD库中，而自动化的bug并没有记录。
现在增加一套自动化的TD库，可以记录自动化相关bug（服务器复现而本机不复现问题），并定期改掉这些bug。
【缺陷管理目的】1.提出的软件bug，作为度量报告有效率的指标2.记录下服务器复现的问题，以便定期做出修改3.统计并分析服务器复现问题产生的原因，找到解决办法，提高自动化脚本质量【整体流程】（参见下面的流程图）I.每份自动化报告，按照既定原则（即规定的或临时分配的），某成员负责整个报告或其中一部分报告的分析。
II.需要自己分析的报告，如果发现了软件bug，则提软件bug；如果此报告是通性报告，并且是非一次性报告，在本机运行不复现后，则提bug。
分析报告的人即为记录bug的人。
（注：一次性报告是在某个时间段只运行一次的版本报告，如临时版报告；而非一次性报告是在某个时间段内运行多次的版本报告）III.软件bug1.发现软件bug后，首先判断软件bug是通性问题还是特性问题2.通性bug可以选择一个即将发版的地区来提，这样可以很快改掉3.特性bug则提在该地区注意：(1)提bug的位置：同软件手工测试提出bug的位置（目前为TD库，网址为http://server-pmc/tdbin/start_a.htm，Project选择GBQ_Rebuild_Main），测试阶段选择自动化(2)提出bug后，如果此bug阻塞自动化，则给相关负责人发邮件，注明bug id号并且说明影响自动化（如果不影响自动化，可以只提出bug，后续由大区人员跟踪）(3) bug负责人（即发邮件的对象）：需求问题由需求人员负责，数据问题由数据人员负责，软件问题由大区开发负责人负责自动化bug当报告为通性、非一次性报告并且本机运行不复现后，则由分析报告的人提出bug，流程如下：1. 提出bug，状态为默认为new,并置服务器复现次数字段为第一次。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
缺陷管理流程图是为了有效的跟踪，管理bug的处理情况，指导测试团队和开发人员有效的处理相关的bug。
不同角色的人，对bug处理的权限不一样，我们需要借助类似缺陷管理工具比如：QC进行实施。
下面就不同角色的人主要的只能进行简单说明：
测试人员：提交bug，并对修复的bug进行审核；
测试组长：审核bug，并将bug提交给开发组长；
开发组长：将确认正确的bug分配给相应的开发人员；
开发人员：修复开发组长分配的bug。
具体的测试流程，请参见图1 缺陷管理流程图：
每个状态表示的具体含义说明如下：
不断的总结，才能不断的提高；不断的思考，才能不断的进步！。