软件bug管理系统(业务流程图)
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跟踪流程
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管理规范与流程图
. 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步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。
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关键角色及应负责任5BUG书写规范5.1测试人员BUG提交5.1.1主题•用一个简短的句子描述问题，不要写成一大段•以进入问题模块路径开头，方便项目经理分派任务，以及开发人员定位问题•描述问题时要详细、简练、抓住要点，直接切入正题，不要罗嗦•不要夸大或缩小问题的严重程度5.1.2步骤•用数字编号，一步步的描述重现问题的所有操作步骤•提供明确的再现问题的步骤，避免问题被以“不能重现”关掉•设置区域需要详细描述，如：各设置项值为默认、**值更改为“”，其他设置项值为默认；•尽量用动词作为开头，描述每个步骤。
Tester+T零基础阶段-BUG的编写及管理流程
始化） • 7、安全相关（密码：123456******准规
范（UI:所有的导航格式，菜单,国标规范） • 9、测试脚本（数据库脚本，） • 10、其他划分：功能类、界面类、性能
禅道-运用（编辑）
禅道-运用
BUG的基本要素
• 缺陷ID，状态，类型，所属项目， 所属模块，缺陷提交时间，缺 陷提交人（检测者），严重程 度，优先级别，缺陷描述信息， 测试步骤，测试前置条件，测 试数据，期望结果，实际结果
• BUG：504
BUG的描述概要
BUG描述详细说明
怎样创建一个高质量的BUG
• 4.极少众机型适配问题，建议类bug，可修可不 修，修了最好，不修不影响发版
BUG的优先级和测试用例优先级的区别
BUG的状态标准
• 1.待处理（提交—激活） • 2.已确认 • 3.已处理=已解决 • 4.已修改=已关闭---最终BUG状态 • 5.仍存在=重新打开 • 6.不是BUG • 7.暂不处理=挂起
BUG的定义&分类
• BUG的定义：电脑程序里的错误， 而现在更是将其延生为漏洞，错 误，可改进的细节、或与需求一个有伟 大历史意义的生物，由格蕾 丝·穆雷·霍波上尉首次确认并命 名
BUG的分类
• 对bug的划分，禅道为例，包括： •） • 1、代码错误-错误页 • 2、设计缺陷-需求原因，【待确认】 • 3、界面优化--UI问题（折行，重影，宽
• 2.产品的功能实现和需求不符合，没有达到预期 的效果，或是性能问题、安全性问题。产品出 现此类问题，可能会导致用户投诉，或者转入 竞争对手的产品。
软件运维管理系统产品需求流程图(附流程图)
软件运维管理系统-需求管理流程一、软件运维管理系统需求管理流程图
二、流程说明
1.创建需求
需求提出人：编写需求内容、所属系统、紧急程度、需求类型、预期完成时间、上传原始需求等。
2.需求评估
项目经理：对需求做可行性评估，需求拆解分析，工作量评估，制定总体计划目标，指定开发负责人。
3.制定计划
开发负责人：任务、开发维度对需求进行拆解，并对拆分后的需求进行任务分配，制定开发、测试人员、开发起止时间等。
4.需求开发
开发人员：接收任务，每天更新开发进度，开发进度达到100%系统自动创建测试任务，并将测试任务推送给测试人员。
5.功能测试
测试人员：接收测试任务，执行测试工作，填写测试结果，如有BUG，填写BUG票并推送给开发人员。
6.发布申请
需求提出人：选择要发布的任务，提交发布申请。
7.环境部署
开发负责人：根据发布申请，部署交付测试换进，填写发布申请单，包括数据库发布内容、前后端发布内容等。
8.交付测试
需求提出人：需求提出人对发布需求进行测试，验证需求实现度，反馈测试结果。
9.产品发布
开发负责人：根据发布清单，执行产品发布任务，并反馈发布结果。
缺陷管理过程中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。
bug管理的简单流程
Bug管理的简单流程：BUG的各种状态：◆新错误(New)：测试中新报告的软件缺陷。
◆打开 (Open)：错误被确认并分配给相关开发人员处理。
◆修正(Fixed)：相关开发人员已完成修正，等待测试人员验证。
◆拒绝(Rejected)：拒绝修改缺陷。
包括两种情况：拒绝-不是错误（Rejected-Not Bug）：报告的错误不是错误。
拒绝-重复（Rejected-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误ID编号。
◆重新打开（Reopen）：没有正确修复的错误，需要进一步修复。
◆延期修改(Deferred)：不在当前版本修复的错误，以后的版本修复。
◆不能重现(Reproduct):开发人员在自己的环境下不能重现的缺陷。
◆关闭(Closed)：错误已被修复。
BUG管理的基本流程：1、测试人员提交新的Bug入库，此时BUG状态为New。
2、错误被确认，项目经理将Bug分配给相应的开发人员，设置Bug状态为Open,与此同时，测试人员和开发人员同时收到改变Bug状态的邮件。
特殊时候若测试人员非常了解Bug所属，测试人员也可直接分配Bug给开发人员，并设置置Bug状态。
3、开发人员查询状态为Open和Reopen的Bug，若Bug反映的问题是由于开发平台本身的缺陷或是测试人员操作错误引起时，置Bug状态为Rejected；4、当Bug反映的内容不包含在当前需求规格说明中，属于升级或者优化功能,且该Bug的存在不影响客户操作的顺利进行,开发人员可以延迟修复时间，置Bug的状态为Deferred；是Bug则解决并置状态为Fixed，Rejected和Deferred的Bug，开发人员要留下文字说明。
5、测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。
Bug的状态每改变一次，都会邮件周知相关的人员，让其明确Bug的当前状态。