BUG管理规范与流程
- 格式:doc
- 大小:787.00 KB
- 文档页数:12
B U G管理规范与流程-标准化文件发布号:(9556-EUATWK-MWUB-WUNN-INNUL-DDQTY-KIIBUG管理流程与规范目录1概述 (4)1.1编写目的 (4)1.2适用范围 (5)2关键角色及应负责任 (5)3BUG流程图 (6)4活动描述 (6)5BUG书写规范 (7)5.1测试人员BUG提交 (7)5.1.1主题 (7)5.1.2步骤 (8)5.1.3实际结果 (8)5.1.4预期结果 (8)5.1.5备注 (9)5.2开发人员解决BUG (9)6BUG严重等级 (11)6.1致命 (11)6.2严重 (11)6.3一般 (11)6.4优化 (12)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已解决 (13)8.4无法重现 (13)8.5延期处理 (13)8.6新增/变更需求 (13)9BUG状态 (13)9.1激活 (13)9.2已解决 (13)9.3关闭 (13)10其他要求 (13)11相关文件 (13)12附件 (14)1概述1.1编写目的本文档定义bug的整个生命周期,规范bug的管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。
1.2适用范围本文档适用测试人员、开发人员。
2关键角色及应负责任5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题,不要写成一大段•以进入问题模块路径开头,方便项目经理分派任务,以及开发人员定位问题•描述问题时要详细、简练、抓住要点,直接切入正题,不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号,一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤,避免问题被以“不能重现”关掉•设置区域需要详细描述,如:各设置项值为默认、**值更改为“”,其他设置项值为默认;•尽量用动词作为开头,描述每个步骤。
BUG管理规范引言概述:在软件开发过程中,出现BUG是不可避免的。
为了保证项目的顺利进行和软件质量的提高,建立一套严格的BUG管理规范是非常重要的。
本文将从五个大点来阐述BUG管理规范的重要性和具体实施方法。
正文内容:1. BUG管理流程1.1 缺陷提交:用户或测试人员发现BUG后,应该及时将BUG提交到缺陷管理系统中。
1.2 缺陷分类:根据BUG的严重程度和影响范围,对BUG进行分类,以便后续处理。
1.3 缺陷分析:开发人员对提交的BUG进行分析,确定出现BUG的原因和解决方案。
1.4 缺陷修复:开发人员根据分析结果进行BUG修复,并在缺陷管理系统中记录修复的过程和结果。
1.5 缺陷验证:测试人员对修复后的BUG进行验证,确保修复的有效性。
1.6 缺陷关闭:验证通过后,将BUG关闭,并在缺陷管理系统中记录关闭的原因和结果。
2. 缺陷报告的要求2.1 准确描述:缺陷报告应该准确描述出现的问题,包括复现步骤、环境信息等。
2.2 具体说明:缺陷报告应该详细说明问题的现象、预期结果和实际结果的差异。
2.3 附加信息:缺陷报告中可以附加一些截图、日志等信息,以便开发人员更好地分析和解决问题。
2.4 优先级和严重程度:缺陷报告应该明确指定问题的优先级和严重程度,以便开发人员能够及时处理。
3. 缺陷管理工具的选择3.1 功能全面:选择一款功能全面的缺陷管理工具,包括缺陷提交、分析、修复、验证、关闭等功能。
3.2 用户友好:缺陷管理工具应该具有良好的用户界面和操作体验,方便用户使用。
3.3 数据统计:缺陷管理工具应该能够提供缺陷统计和分析功能,帮助项目管理者了解项目的进展和质量情况。
3.4 可扩展性:选择一款具有良好的可扩展性的缺陷管理工具,能够满足项目的特殊需求。
4. 缺陷管理的注意事项4.1 及时响应:对于用户提交的缺陷报告,应该及时响应并进行处理,避免用户的不满。
4.2 优先级管理:根据缺陷的优先级和严重程度,合理安排开发人员的工作任务,确保重要的缺陷能够及时解决。
实用标准文档BUG管理流程与规范目录1概述 (4)1.1编写目的 (4)1.2适用范围 (4)2关键角色及应负责任 (4)3BUG流程图 (5)4活动描述 (5)5BUG书写规范 (7)5.1测试人员BUG提交 (7)5.1.1主题 (7)5.1.2步骤 (7)5.1.3实际结果 (7)5.1.4预期结果 (7)5.1.5备注 (8)5.2开发人员解决BUG (8)6BUG严重等级 (9)6.1致命 (9)6.2严重 (9)6.3一般 (10)6.4优化 (10)7BUG优先级 (10)7.1紧急 (10)7.2高 (11)7.3中 (11)7.4低 (11)8BUG解决方案 (11)8.1设计如此 (11)8.2重复BUG (11)8.3已解决 (11)8.4无法重现 (11)8.5延期处理 (11)8.6新增/变更需求 (11)9BUG状态 (11)9.1激活 (11)9.2已解决 (11)9.3关闭 (11)10其他要求 (12)11相关文件 (12)12附件 (12)1概述1.1编写目的本文档定义bug的整个生命周期,规范bug的管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。
1.2适用范围本文档适用测试人员、开发人员。
2关键角色及应负责任5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题,不要写成一大段•以进入问题模块路径开头,方便项目经理分派任务,以及开发人员定位问题•描述问题时要详细、简练、抓住要点,直接切入正题,不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号,一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤,避免问题被以“不能重现”关掉•设置区域需要详细描述,如:各设置项值为默认、**值更改为“”,其他设置项值为默认;•尽量用动词作为开头,描述每个步骤。
BUG管理规范一、背景介绍在软件开辟过程中,难免会浮现各种各样的BUG(缺陷),这些BUG可能会影响软件的正常运行和用户体验。
为了保证软件质量和开辟效率,需要建立一套科学规范的BUG管理流程和标准,以便及时发现、跟踪和解决BUG。
二、BUG管理流程1. BUG的发现- BUG可以通过测试人员在测试过程中发现,也可以通过用户反馈、日志分析等途径获得。
- 测试人员应该在测试过程中,根据测试计划和测试用例进行全面的测试,尽可能发现所有的潜在BUG。
- 用户反馈的BUG应该及时记录,并尽快进行验证。
2. BUG的记录- 每一个发现的BUG都应该被记录下来,以便后续跟踪和解决。
- BUG的记录应包括以下内容:- BUG的现象描述:清晰、准确地描述BUG的现象,包括浮现的条件、频率等。
- BUG的复现步骤:详细描述如何复现该BUG,以便开辟人员能够重现问题。
- BUG的影响范围:描述该BUG对软件功能、性能、稳定性等方面的影响。
- BUG的优先级和严重程度:根据BUG的影响程度和紧急程度,给出相应的优先级和严重程度评估。
- BUG的截图或者日志:提供相关的截图或者日志,以便开辟人员更好地理解和分析问题。
3. BUG的分析和解决- 开辟人员应及时分析BUG,并尽快进行解决。
- 开辟人员在解决BUG时,应遵循以下原则:- 先解决严重程度高、优先级高的BUG。
- 解决BUG时,应尽量保证解决方案的稳定性和可靠性。
- 解决BUG后,应进行相应的单元测试和回归测试,以确保解决BUG的同时不引入新的问题。
4. BUG的验证和关闭- 开辟人员在解决BUG后,应通知测试人员进行验证。
- 测试人员应按照BUG的复现步骤进行验证,并确认BUG是否已经解决。
- 如果BUG已经解决,测试人员应将BUG状态更新为已验证,并关闭该BUG。
- 如果BUG没有解决或者解决不彻底,测试人员应将BUG状态更新为重新打开,并提供详细的验证结果和反馈,以便开辟人员进一步分析和解决。
BUG管理规范一、引言在软件开发过程中,经常会出现各种各样的问题和错误,其中最常见的就是软件缺陷(BUG)。
为了有效地管理和解决这些问题,制定一套BUG管理规范是非常重要的。
本文旨在提供一套详细的BUG管理规范,以帮助团队成员更好地管理和解决BUG。
二、BUG管理流程1. 提交BUGa. 开发人员在发现BUG后,应及时记录并提交BUG报告。
b. BUG报告应包含以下内容:BUG的描述、复现步骤、期望结果、实际结果、BUG的严重程度、影响范围等。
c. 开发人员应尽量提供详细的复现步骤和截图等辅助信息,以便测试人员更好地理解和复现BUG。
2. 分类和优先级a. 测试人员在接收到BUG报告后,应对BUG进行分类和评估优先级。
b. 常见的分类包括功能性BUG、性能BUG、界面BUG等。
c. 优先级评估应根据BUG的严重程度和影响范围来确定,常见的优先级包括高、中、低三个级别。
3. 分配和跟踪a. 测试人员将已分类和评估优先级的BUG分配给相应的开发人员。
b. 开发人员在接收到BUG后,应及时确认并开始解决。
c. 开发人员应在解决BUG的过程中,及时更新BUG状态,并保持与测试人员的沟通。
4. 解决和验证a. 开发人员在解决BUG后,应及时更新BUG的解决方案,并提交给测试人员进行验证。
b. 测试人员应根据解决方案进行验证,并在验证通过后关闭相应的BUG。
c. 如果验证不通过,测试人员应重新打开相应的BUG,并提供详细的验证结果和反馈给开发人员。
5. 统计和分析a. 测试团队应定期进行BUG统计和分析工作,以便发现和解决常见的BUG问题。
b. 统计和分析的内容包括BUG的数量、解决速度、解决率等。
c. 根据统计和分析的结果,测试团队应及时调整和改进BUG管理流程,以提高BUG的解决效率和质量。
三、BUG管理工具为了更好地管理和追踪BUG,团队可以使用专业的BUG管理工具。
常见的BUG管理工具包括JIRA、Bugzilla、Mantis等。
时间 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)描述不能执行正常的功能操作,或者因产品原因导致系统死机,需即将修复的问题部份功能存在严重缺陷,尚可继续测试,不影响产品稳定性;次要功能或者界面存在的一些错误,不影响正常测试;测试对于产品的一些改进建议;描述影响测试,需即将修复;必须在版本发布之前修改完;必须修改,不一定即将修改,需讨论确定在某个特定的里程碑前修改完对产品的影响比较小,在时间不允许的情况下可以暂时不修改在提交一个缺陷的缺陷,首先尽量描述这个缺陷的属性。
BUG管理规范一、背景介绍在软件开发过程中,由于各种原因可能会出现各种BUG(缺陷),这些BUG会对软件的功能、性能和稳定性产生影响。
为了有效地管理和解决这些BUG,制定一套科学规范的BUG管理流程非常必要。
二、BUG管理流程1. BUG的发现- BUG的发现可以通过测试、用户反馈、代码审查等方式进行。
- 发现BUG的人员应及时记录并详细描述BUG的现象、复现步骤和环境等相关信息。
- BUG应按照严重程度进行分类,并进行优先级排序。
2. BUG的记录- 所有发现的BUG都应该被记录在BUG管理系统中,以确保及时跟踪和解决。
- 每个BUG应该有唯一的标识符,便于后续的跟踪和查询。
- 记录BUG时应包括以下信息:BUG的描述、现象、复现步骤、环境、严重程度、优先级、发现人、发现时间等。
3. BUG的分析和确认- 由开发人员对BUG进行分析,确认该BUG是否属实。
- 如果BUG属实,则确认该BUG的严重程度和优先级,并进行相应的处理。
4. BUG的解决- 开发人员根据BUG的严重程度和优先级进行解决。
- 解决BUG时应编写相应的代码,并进行单元测试和集成测试,确保解决的有效性。
- 解决完BUG后,应及时更新BUG管理系统中的相关信息,并通知相关人员。
5. BUG的验证- 验证已解决的BUG是否完全修复。
- 验证可以通过复现步骤进行,确保修复后的软件功能正常。
- 验证通过后,应及时更新BUG管理系统中的相关信息,并通知相关人员。
6. BUG的关闭和归档- 当BUG被验证通过后,可以将其关闭,并进行归档。
- 归档后的BUG可以作为经验教训,供后续项目参考和学习。
三、BUG管理系统为了更好地管理和追踪BUG,建议使用专门的BUG管理系统,如JIRA、Bugzilla等。
这些系统可以提供BUG的记录、分析、解决、验证和归档等功能,方便团队成员之间的协作和沟通。
四、BUG管理的注意事项1. 严格按照BUG管理流程进行操作,不得随意跳过任何环节。
BUG管理规范一、引言在软件开发过程中,不可避免地会出现各种BUG(缺陷、错误)。
为了更好地管理和解决这些BUG,提高软件质量和用户满意度,制定一套BUG管理规范是非常必要的。
本文旨在规范BUG管理流程、责任分工、报告格式以及解决方案的编写,以便团队成员能够高效地处理和解决BUG。
二、BUG管理流程1. 发现BUG:任何团队成员在测试、开发、运维过程中发现的BUG都应该及时记录下来。
2. 报告BUG:BUG应该以统一的报告格式进行记录,包括但不限于以下内容:- BUG的标题:简明扼要地描述BUG的主要问题。
- BUG的描述:详细描述BUG的现象、复现步骤、影响范围等。
- BUG的优先级:根据BUG的严重程度和影响范围,给出优先级评估。
- BUG的截图或日志:提供相关的截图或日志,以便更好地理解和复现BUG。
- BUG的归属者:指定负责处理该BUG的团队成员。
3. 确认BUG:由归属者对报告的BUG进行确认,验证是否为真实存在的问题。
4. 分类和优先级评估:归属者对已确认的BUG进行分类,并根据其严重程度和影响范围进行优先级评估。
5. 分配处理:根据优先级评估,将已确认的BUG分配给相应的团队成员进行处理。
6. 解决BUG:团队成员根据分配的BUG进行分析、定位和解决。
7. 验证修复:修复BUG后,归属者应进行验证,确保BUG已经被解决。
8. 关闭BUG:验证修复后,归属者应将BUG标记为已关闭,并给出解决方案和关闭原因。
三、责任分工1. 归属者:负责对报告的BUG进行确认、分类、优先级评估、分配处理、验证修复以及关闭BUG。
2. 处理者:负责根据分配的BUG进行分析、定位和解决,并及时反馈处理进度给归属者。
3. 验证者:负责验证修复后的BUG,确保问题已经解决。
四、报告格式1. BUG的标题应简明扼要地描述BUG的主要问题,方便快速理解。
2. BUG的描述应详细描述BUG的现象、复现步骤、影响范围等,以便归属者和处理者能够准确理解和复现BUG。
BUG管理规范一、引言在软件开发过程中,难免会出现各种各样的BUG(缺陷),这些BUG对软件的功能和性能造成了影响。
为了更好地管理和解决BUG,制定一套BUG管理规范是非常必要的。
本文将详细介绍BUG管理规范的内容。
二、BUG管理流程1. BUG的发现- BUG可以通过测试、用户反馈、代码审查等方式发现。
- 发现BUG后,应立即记录并进行分类,包括BUG的严重程度、影响范围、发现人等信息。
2. BUG的记录- 使用专门的BUG管理工具进行记录,如JIRA、Bugzilla等。
- 记录时应包括BUG的描述、重现步骤、环境信息、截图等详细内容。
- 记录时要确保准确、清晰,以便开发人员能够迅速理解和解决BUG。
3. BUG的分析和优先级确定- 开发人员应对BUG进行分析,确定其产生原因和解决方案。
- 根据BUG的严重程度、影响范围和紧急程度等因素,确定BUG的优先级。
- 优先级的确定应充分考虑用户体验、系统稳定性等因素。
4. BUG的解决- 开发人员根据分析结果,制定相应的解决方案。
- 在解决BUG的过程中,应及时与测试人员进行沟通,确保解决方案的有效性。
- 解决BUG后,应及时进行验证,确保BUG已被完全修复。
5. BUG的验证和关闭- 测试人员应对已解决的BUG进行验证,确认BUG已被修复。
- 验证通过后,将BUG状态更新为已关闭,并记录验证结果。
- 如果验证未通过,应重新分析和解决BUG,直至BUG被完全修复。
6. BUG的统计和分析- 对已解决的BUG进行统计和分析,包括BUG的数量、解决时间、解决率等指标。
- 根据统计结果,及时调整BUG管理策略,提高软件质量和开发效率。
三、BUG管理规范的要求1. 规范的记录格式- BUG的记录应采用统一的格式,包括标题、描述、重现步骤、环境信息等内容。
- 记录时要注意语言准确、清晰,避免歧义和误解。
2. 及时响应和处理- 对于发现的BUG,应及时进行响应和处理,避免影响软件的正常使用。
BUG管理规范与流程一、引言在软件开发过程中,无论是开发示例项目,还是商业应用程序,都难免会出现一些错误和问题。
为了有效地管理和解决这些错误,需建立一套完善的BUG管理规范与流程。
本文将从如下几个方面介绍BUG管理的规范和流程,包括BUG的定义、分类、报告、处理、验证、跟踪以及BUG管理工具的选择等。
二、BUG的定义和分类1.定义BUG是指在软件开发或测试过程中,出现的程序错误、逻辑缺陷、功能失效或其他不符合需求的问题。
它会导致系统的异常行为、崩溃、漏洞和性能问题等。
2.分类常见的BUG分类包括以下几种:(1)功能性BUG:软件无法按照需求或规格文档的要求进行正确操作,或功能模块未能达到预期的效果。
(2)界面问题:指界面设计不合理、布局错乱、风格不统一等问题。
(3)兼容性问题:软件在不同平台、浏览器或设备上存在兼容性问题。
(4)性能问题:软件运行过程中出现的卡顿、响应缓慢、资源占用过高等问题。
(5)安全问题:软件存在的漏洞、不安全的接口或数据泄露等问题。
三、BUG管理流程1.报告BUG(1)发现BUG:开发人员、测试人员、用户或客户等任何人发现BUG 后,应及时报告BUG。
(2)记录BUG信息:报告者应提供相关的BUG信息,包括BUG的现象、重现步骤、失败截图或录像、操作环境以及影响和紧急程度等。
(3)分配BUG:由BUG管理员或项目负责人将BUG分配给合适的开发人员进行处理。
2.处理BUG(1)确认BUG:开发人员应仔细分析BUG报告,并进行问题确认,确保其确实是一个有效的BUG。
(2)定位问题:开发人员需要利用日志、调试工具等手段定位并复现BUG,以便找出问题的根源。
(3)修复BUG:开发人员根据定位结果,进行相应的代码修改或操作调整,以修复BUG。
(4)代码评审:开发人员修复BUG后,需进行代码评审,确保修复的代码符合规范。
(5)重新编译和测试:修复BUG的代码重新编译后,由测试人员进行验证。
BUG管理流程与规范目录1概述 (4)1.1编写目的 (4)1.2适用范围 (4)2关键角色及应负责任 (4)3BUG流程图 (5)4活动描述 (5)5BUG书写规范 (7)5.1测试人员BUG提交 (7)5.1.1主题 (7)5.1.2步骤 (7)5.1.3实际结果 (7)5.1.4预期结果 (7)5.1.5备注 (8)5.2开发人员解决BUG (8)6BUG严重等级 (9)6.1致命 (9)6.2严重 (9)6.3一般 (10)6.4优化 (10)7BUG优先级 (10)7.1紧急 (10)7.2高 (11)7.3中 (11)7.4低 (11)8BUG解决方案 (11)8.1设计如此 (11)8.2重复BUG (11)8.3已解决 (11)8.4无法重现 (11)8.5延期处理 (11)8.6新增/变更需求 (11)9BUG状态 (11)9.1激活 (11)9.2已解决 (11)9.3关闭 (11)10其他要求 (12)11相关文件 (12)12附件 (12)1概述1.1编写目的本文档定义bug的整个生命周期,规范bug的管理流程。
Bug在流转的过程中有章可循。
规范bug严重等级与bug解决优先级,使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决。
1.2适用范围本文档适用测试人员、开发人员。
2关键角色及应负责任序号角色应负责任01 测试工程师1)提交bug,用bug级别反映bug的严重程度,2)验证bug是否已被解决02 测试负责人1)审核测试人员提交的bug ;2)定位测试工程师提交的bug优先级3)定期对bug库进行分析,描绘出曲线图等,报告现状、预测趋势,在测试总结报告中给出意见。
4)分析项目测试过程中存在的风险03 开发工程师1)分析bug,写出问题原因,修改bug,2)实行bug优先原则,严重程度5个以上的,停止新功能的开发。
04 开发负责人1)每天对bug进行分配,标注处理意见2)定期对bug库分析,对bug多的模块,进行代码走查。
3)分析bug修复进度,对项目的质量、进行风险评估。
4)跟踪被需求确认可延期处理的bug05 系统工程师1)解释需求,给出处理意见,2)将bug库中的建议整理成为需求文档3)当开发和测试存在意见分歧时,进行需求确认。
Bug 管理流程测试工程师测试主管开发工程师开发主管系统工程师跟踪阶段提出bug修复阶段验证阶段提交bug判断是否是bug提交并激活确认与分配Y 分析是否是bug指定优先级确认并指派bug修复bug ,并说明产生原因Bug 验证是否修复关闭bugY 描述不清楚或不是bug判定不是bug 或重复bug分析是否是bug仲裁是否是bug 指派给需求确认大的变更需求/新增需求,修改需求文档确认是问题应变更或新增需求需求确认不是bug是否是bug开发分析不是bug修复bug重新激活bug ,并指派修改状态为已修复Y 是否 在该版本修复Y确认bug 为延期修复,但bug 状态为已解决,不能关闭,在修复完成以后需要指派给测试人员进行验证确认是bug ,但该版本不修复并指定修复版本是否确认延期修复需求确认为必须在该版本修复是否延期修复立即修复Y开发确认是bug 但该版本不修复确认bug 为无效bug ,关闭bug确认不是bug修改状态为已修复需求判定为延期指派给开发主管是否新增/变更需求分析是问题但应该变更需求确认是bug ,需求如此或很小的改动需求,在备注中说明,并激活bug需求确认是bug ,指派给开发指派给测试Bug 状态:激活,已修复,已关闭解决方案:设计如此,重复Bug ,已解决,无法重现,延期处理,新增/变更需求4 活动描述序号活动名称 参与角色活动描述输入、输出信息 处理时限01提交bug测试工程师详细书写Bug ,指派给对应的测试负责人输入信息:无输出信息: 在禅道上提交bug ----02Bug 确认与分配测试负责人根据<<软件需求>>判定是否是Bug ,给出意见输入信息:测试人员提交的bug ,测试用例,软件需求输出信息:确定bug 优先级,指派给开发负责人。
0.5个 工作日 03分析确认并指派Bug开发负责人根据<<软件需求>>判定是否是Bug ,给出意见输入信息:测试负责人指派的bug ,软件需求,程序源代码等0.5个 工作日输出信息:分析Bug,指派给对应的开发工程师,不是bug或应该需求变更时,指派给相关人员04 修复Bug 开发工程师修改Bug,给出解决方案,修复再次激活的bug。
输入信息:开发负责人确认指派的bug,软件需求输出信息:Bug的解决方案,产生bug的原因,指派给对应的测试工程师0.5个工作日05 验证Bug 测试工程师验证Bug,给出验证结果输入信息:开发工程师指派的已修复的Bug,需求确认转为变更或新增需求的bug输出信息:如果Bug未修改,激活并指派给对应的开发工程师;如果Bug已修改或系统工程师确认转为需求的bug,关闭bug,0.5个工作日06 确认bug延期测试主管分析bug,确认bug是否能延期处理输入信息:开发或系统工程师指派的延期bug输出信息:确认是否能延期处理,对应延期的bug在开发修复的版本进行激活视实际情况而定07 Bug仲裁系统工程师根据<<软件需求>>判定是否是Bug,给出处理意见输入信息:测试主管指派的延期bug或需要系统工程师确认的bug,开发主管指派的新增/变更需求的bug。
0.5个工作日输出信息:给出明确处理结果,属于新增/变更需求的bug需要在需求文档中记录相关需求。
5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题,不要写成一大段•以进入问题模块路径开头,方便项目经理分派任务,以及开发人员定位问题•描述问题时要详细、简练、抓住要点,直接切入正题,不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号,一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤,避免问题被以“不能重现”关掉•设置区域需要详细描述,如:各设置项值为默认、**值更改为“”,其他设置项值为默认;•尽量用动词作为开头,描述每个步骤。
如:打开、点击、设置、选择、插入、双击等•不要在一个步骤中描述不相关的多个操作。
如果是相关的一系列操作,可以使用“→”来连接描述。
•按照你写的步骤去执行,看问题能否重现•不要在步骤中使用含糊不清的缩写词描述5.1.3实际结果•实际只描述一个问题•同样的操作步骤产生多种现象,要在一个缺陷报告中加以描述•不同的操作步骤产生不同的问题,分别报bug•如果有截图,请列出所附的图片信息5.1.4预期结果•不要加入实际结果的描述信息•描述要清晰,不要使用含糊不清的缩写词描述•如果有截图,请列出所附的图片信息5.1.5备注•避免写成大段落,要写得简单、易读•问题的特征•出现问题后的解决方法•对终端客户的影响情况•如果有必要,列出产生问题的配置环境5.2开发人员解决BUG1.BUG的原因。
2.BUG的修改方法3.BUG可以在哪个版本上进行验证。
4.测试人员验证bug时,需要写明:验证了什么,在什么版本验证,是否通过,如果不通过需写明原因。
如果在验证当前bug时有新现象产生阻碍了验证此bug,则该bug不能关闭,写明没有验证的原因,并为新现象提bug。
举例1:现象:修改后:6BUG严重等级6.1致命不能执行正常工作功能或重要功能,因软件原因导致系统死机等,须马上修正致命错误。
通常有如下情况:1.内存泄漏2.由于执行程序引发数据库发生死锁3.用户数据丢失或破坏4.系统崩溃5.死机6.程序无法启动或异常退出7.因错误操作导致的程序中断8.功能设计与需求严重不符6.2严重影响系统功能或操作,应用模块错误使业务中止无法进行后续操作,主要功能存在严重缺陷,但不会影响到系统稳定性。
具体基本上可分为:1.功能未实现2.功能错误3.业务中止,无法进行后续操作4.数据库的表、业务规则、缺省值未加完整性等约束条件5.数据库表结构错误,字段长度不够,缺少表、存储6.语音或数据通讯错误7.数值计算错误8.前台提示存储报错9.系统所提供的功能或服务受明显的影响6.3一般影响系统正常运行的缺陷,主要功能出现错误,影响到产品的使用。
例如:次要功能不能正常实现;查询错误,数据错误显示;简单的输入限制未放在前台进行控制具体基本上可分为:1.操作界面错误(包括数据窗口内列名定义、含义是否一致)2.报表打印内容、格式错误、取值错误3.页面查询结果错误,自动读值项取值错误4.边界条件下错误5.提示信息错误(包括未给出信息、信息提示错误等)6.简单的输入限制未放在前台进行控制7.长时间操作无进度提示8.光标跳转设置不好,鼠标(光标)定位错误6.4优化使操作者不合理或者不方便或操作遇到麻烦,但它不影响执行工作功能或重要功能,次要功能,对产品使用影响不大。
例如:程序在一些显示上不美观,不符合用户习惯,或是一些文字的错误。
具体基本上可分为:1.界面格式等不规范2.辅助说明描述不清楚3.操作时未给用户提示4.可输入区域和只读区域没有明显的区分标志5. 个别不影响产品理解的错别字6.文字排列不整齐等一些小问题7.提示窗口文字未采用行业术语7BUG优先级7.1紧急阻止与此密切相关功能的进一步测试,需要立即修复7.2高必须修改,发版前必须修正7.3中必须修改,不一定马上修改,但需确定在某个特定里程碑结束前须修正7.4低对系统的影响较小,如果时间允许应该修改8BUG解决方案8.1设计如此设计如此,测试人员理解错误,无需改动,即无效的bug8.2重复bug以前已经有同样的bug。
8.3已解决Bug已经被修改正确,待测试进行验证8.4无法重现根据测试写的重现步骤,无法重现bug。
8.5延期处理确实是bug,但现在不解决,以后处理。
8.6新增/变更需求分析确实是存在问题,但需求没有描述清晰,应指派给需求确认,进行需求的新增或变更。
9BUG状态9.1激活1.新创建的bug;2.已关闭的bug重新出现需要再次激活;3.已解决但验证未通过的bug。
9.2已解决开发已经修改完成的bug。
9.3关闭已验证通过的bug或系统工程师确认转为需求的bug。
10其他要求Bug的描述与Bug的流向严格遵守流程规范。
11相关文件文件编号文件名称12附件文件编号文件名称保存时间保管部门附件。