bug管理规范与流程

bug 管理规范及流程

、概述1

本文档定义 bug 的整个生命周期，规范 bug

的解决方案及管

理流程。Bug 在流转的过程

中有章可循。规范bug严重等级与bug 解决优先级，使开发人员与测试人员能根据此文档

准确判断bug 的严重程度并加以解决；

2、关键角色及职责

角色职责

1.根据规范提交bug；测试工程师

2.及时验证bug 是否已解决；

3.及时关注开发拒绝bug，和相关人员沟通讨论解决方式；

1.审核测试工程师提交的bug；测试经理

2.定期review bug ，报告现状，并给出解决意见； 1.以优先级为依据分析解决bug开发工程师

1.定期review bug，对bug多的模块加强code review和单元测试；开发主管

2.分析bug 解决进度，对产品质量及进度进行风险评估；

1、当开发和测试存在意见分歧时，进行需求确认产品

2、从产品角度划分bug 修改的优先级；

3、Bug 生命周期

4、Bug 书写规范

4.1 BUG 标题

1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题；

2)描述问题时要简练、直接切入主题，但是要抓住要点；

偶现bug 在主题前标注出现的次数；3)

4) 有些模块功能比较多，可以在主题描述前标注上具体得操作；示例：

次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息【偶现 3

次】添加载体库时程序停止运行【偶现 2

重现步骤4.2

出现时间、截图、日志说明区域包括：步骤、预计结果、实际结果、测试环境、bug

用数字编号，一步步的描述问题的重现步骤；1)

汇报一个问题；bug 2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个

bug 出现的时间、提供截图以及日志；3)偶现问题必须明确

解决方案5、Bug

天内全部审核一遍，当天提交的新建状态2 bug，对应的开发人员需在分成以下bug将

类：拒绝、进行中、延期、反馈（给产品）；3

状态置为已解决；同时添加说明验证版本号、错误原因、解决办bug：将开发已修复的bug法；

示例：

号可以验证）11 V1.0.1.1101 验证版本：（1101 表示在月 1 问题原因：未作条件判断

解决方法：进行合理边界判断

状态置为已拒绝；指派给：将bug开发认为不是bug提出者；同时注明拒绝理由；bug

示例：

设计，测试人员理解错误；XXX参考

缺乏必要的信息，bug 提出者；（无法重现状态置为已拒绝bug将无法重现：bug）；指派给

同时注明拒绝理由；

示例：

缺少必须日志；

状态置为关闭，并注明通过版本号；bug：将bug开发已修复，测试验证通过的

示例：

验证通过V1.0.1.1103

状态置为打回（bug开发已修复，测试验证不通过的：将bug），并根据实际情况注明激活

反馈理由；

示例：

版本验证此问题仍然存在；V1.0.1.1103

XXX步骤：

XXX出现时间：

XXX测试环境：

截图、日志；

bug：指派给对应产品经理，进行讨论确认修改方案；由产品

经理编辑测试、开发有争议的转为需求，并注明理由。/ bug 状态为激活不予处理/

示例：

地址设置错误，应该提示用户，而不应该程序出现停止运行；测试认为ip

，并注明公认理由；状态修改为公认不予解决外部原因( / ) bug无法修复的：将bug

无法重现的：主要依赖日志分析问题原因，然后进行对应的修改；开发修改后，测试追bug

个版本、或者使用测试工具反复测试，如没有重现则先关闭；并注明关闭版本号；溯3

示例：

暂未复现，先关闭；V1.0.1.1103

的日期；并注明延：将bug需延期的bug状态修改为低，计划完成日期修改为计划解决bug

期理由；

示例：

需求变更，改动量很大，影响版本发布时间；

产品确认需要修改的bug：将bug状态修改为打回，指派给对应的开发人员，并注明修改内

容；

产品确认不需要修改的bug：将bug状态修改为已解决，并注明不需要修改原因；

不是本端的bug：由bug所在端（本端）人员给出分析说明，转给对应端和开发人员，并口

头通知；

6、Bug 跟踪类别

bug：测试人员判定为bug 的问题；

优化：功能已实现，需要做性能优化的问题；建议：测试对于产品的一些改进建议；

需求：需要产品重新梳理的需求问题；

7、Bug 状态

新建：测试人员新提交的bug、优化或者建议的问题状态；进行中：开发人员已确认是bug，需要修改的问题状态；已解决：开发人员已修复的问题状态；

已关闭：测试验证，确定已解决的问题状态；

已拒绝：开发认为不是bug，拒绝给测试的问题状态；

反馈：反馈给产品确认的问题状态；

公认：确认是bug，但是无法解决的问题状态；

打回：测试验证已解决bug，仍然没有修复的问题状态；

8、Bug 严重程度

致命：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题

示例：

程序无法启动，或者登录；

程序崩溃、停止运行，系统死机，无法进行下一步的操作

严重：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；

示例：

偶现的程序崩溃、停止运行

功能未实现

数据不同步

功能错误，无法进行后续操作

一般：次要功能或者界面存在的一些错误，不影响正常测试；示例：

界面UI 显示和效果图不一致；

提示语不正确；

错别字；

查询结果显示错误

建议：测试对于产品的一些改进建议；

9、Bug 优先级

4低：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；

3中：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；

2高：必须在版本发布之前修改完；

紧急：影响测试，需立即或者下一个版本修复；1．

10、其他注意事项

开发人员没有关闭bug 的权限，所有问题均需经过测试验证无误后才可关闭；1)

2)开发、测试双方有争议的，必须经过产品的确认才可进行下一步的操作；bug

；3)测试需及时验证已修复bug

解决的优先级；产品人员可以根据产品的阶段性需求重新分配bug 4)

QQ 告知对方；5)重新指派bug 后，需要口头或者bug 的优先级划分比较重要；6)

提交流程参考：、禅道bug 11

https://www.wendangku.net/doc/f412663793.html,/book/zentaopmshelp/133.html

附件：

V1.0 bug 管理规范禅道

等级）bug 禅道系统bug 严重程度（即

，致命1= bug

，bug2=严重

，bug3=一般

建议。4=

：致命bug

不能完全满足应用要求导致应用闪退和应用停止运行：严重bug

或产生错误结果，使应用不稳定、严重地影响应用需求或基本功能

BUG管理规范

Bug管理规范

一、概述 本规范是常规的bug管理流程，适用于项目过程中的bug管理

二、BUG周期

三、Bug的分类、状态、级别 3.1 bug分类 1. 功能 A.重复的功能；B.多余的功能；C.功能没有达到设计的要求；D.功能实现与设计要求不相符。 2. 易用性 A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面；B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3. 安全性 A.数据有效性检测不合理；B.重要数据在传输中没有加密；C.缺少身份认证机制或认证不合理； 4. 可靠性 A.数据存贮的可靠性；B.业务处理的可靠性； 5. 性能 A.并发量；B.吞吐量；C.响应时间。 6. 兼容性不同厂商的浏览器以及浏览器的不同版本，手机app指不同操作系统 3.2 bug状态 Bug的状态主要分为新建、已分派、已解决、重新打开、已关闭、挂起。 ?新建状态（NEW ）：Bug创建后的初始状态。 ?已分派状态（ASSIGNED）：经过确认为有效问题后分配给开发人员的状态。 ?已解决状态（RESOLVED）：开发人员对软件问题进行处理或修改后的状态。 ?重新打开状态（REOPENED）：对开发人员修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。 ?关闭状态（CLOSED）：Bug解决后测试人员验证通过，则将其状态修改为已关闭 ?挂起状态：经过项目经理确认延期修改的bug 3.3 bug严重等级和优先级定义 bug的严重级别定义：

BUG优先级定义： 四bug描述规范 bug描述要简洁明了，方便开发人员重现和后续跟踪。 版本：当前测试的版本号 平台：测试使用的平台说明 摘要：概要描述问题。 描述：应该描述问题发现的步骤、期望结果和实际结果 描述可分为“步骤”、“结果”（含：期望结果、实际结果）、“补充说明”三部分，各部分之间用空行隔开。“补充说明”部分可根据实际情况选择是否需要描述。具体格式如下： 步骤： 期望结果： 实际结果： 补充说明： 1. 如果多处出现类似问题，应描述出现该问题的所有模块或界面。 2. 如果不可重现，应说明 附件：添加错误附图或错误信息。

bug管理规范及流程审批稿

b u g管理规范及流程 YKK standardization office【 YKK5AB- YKK08- YKK2C- YKK18】

bug管理规范及流程 1、概述 本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug的严重程度并加以解决； 2、关键角色及职责 ?

3、Bug生命周期 4、Bug书写规范 BUG标题 1)以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问

题； 2)描述问题时要简练、直接切入主题，但是要抓住要点； 3)偶现bug在主题前标注出现的次数； 4)有些模块功能比较多，可以在主题描述前标注上具体得操作； 示例： 【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息 【偶现2次】添加载体库时程序停止运行 重现步骤 说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志 1) 用数字编号，一步步的描述问题的重现步骤； 2) 不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题； 3) 偶现问题必须明确bug出现的时间、提供截图以及日志； 5、Bug解决方案 当天提交的新建状态bug，对应的开发人员需在2天内全部审核一遍，将bug分成以下3类：拒绝、进行中、延期、反馈（给产品）； 开发已修复的bug：将bug状态置为已解决；同时添加说明验证版本号、错误原因、解决办法； 示例： 验证版本：（1101表示在11月1号可以验证） 问题原因：未作条件判断 解决方法：进行合理边界判断

缺陷管理Bug状态流程图说课讲解

Bug状态流程图 对Bug的处理 开发组长/经理 每天对Bug进行分配，标注处理意见，给定优先级（发版前必须三方：需求、开发、产品共同确定）。问题分配时，应尽可能将咨询类、理解错误类等问题处理掉，而不是留给开发人员。有可能是需求的问题，分配给需求人员。定期对Bug库分析，找出常出错的模块，进行代码审查 开发人员 分析Bug，写出问题原因，修改Bug；实行Bug优先原则，严重程度B-Major类或紧急程度3-High 类以上（包含）bug5个或5个以上，停止新功能的开发。 需求人员 解释需求，给出处理意见，将Bug库中的建议整理成需求文档。评审确定后列入开发计划 测试人员 不参与问题的优先级的定位，只用Bug级别反映Bug的严重程度。验证Bug是否已被解决 测试组长/经理 审核测试人员提交的Bug。定期对Bug库进行分析，描绘出曲线图等，报告现状、预测趋势。在测试总结报告中给出意见 产品人员 可以对优先级和处理意见等进行审核，如果有意见，和项目组商量定夺

Bug状态(Status)：指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected等 Bug严重级别(Severity，Bug级别)：是指因缺陷引起的故障对软件产品的影响程度。由测试人员指定。 Bug优先级(Priority)：指缺陷必须被修复的紧急程度。由Bug分配者（开发组长/经理）指定。 功能模块(Subject)：TD中需在Test Plan页中定义好Subject，才能在Defects页中使用。 问题描述、附件附图请参见后面第四部分‘Bug描述要求’的有关内容。

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的当前状态。 对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。 一般输入到库中的Bug，原则性不能删除，及开发人员和测试人员没有删除的权限。 一般管理员有此权限。 对于测试人员和开发人员要加适当的使用权限，测试人员一般只有新增、查询、验证等权限，开发人员一般只有查询、解决等权限。测试负责人和项目经理可以适当地加大使用权限。 Bug的生命周期：

JIRA bug提交管理规范

Bug提交管理规范 修订历史

目录 1. BUG管理工具介绍 (3) 2. BUG定义 (3) 1. BUG分类 (3) 2. Bug等级 (3) 3. Bug状态 (4) 4. Bug优先级 (4) 3. BUG的生命周期 (4) 4. BUG管理规范 (5) 1) 项目的创建 (5) 项目名称及代号规范 (5) 项目的模块及版本划分规范 (5) 用户角色权限分配规范 (6) 2) BUG提交规范 (6) BUG的报告内容 (6) 主题，即BUG简要描述 (7) 严重程度选择 (7) 优先级选择 (8) 模块及版本选择 (8) 环境 (9) BUG详细描述 (9) 其他规范 (9) 3) BUG分配及处理 (10) BUG的分配 (10) BUG处理 (10) 4) BUG验证及关闭 (10)

1.BUG管理工具介绍 常用的BUG管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb等。我们公司采用的是JIAR，JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2.BUG定义 1.BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG进行分类。 1、从功能方面分，产生BUG的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A.界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B.缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E．网络安全性：开放端口、服务； F．系统日志、审计。 4、从可靠性方面分，BUG可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C．硬件可靠性：如打印机；D.应急处理措施； E．数据备份、恢复。 5、从性能方面考虑，BUG可划分为三种： A．并发量； B．吞吐量； C．响应时间。 6、从兼容性方面考虑，BUG有两种： A．硬件兼容性； B．软件兼容性。 7、从可维护性方面考虑，可划分为两种原因： A．可扩展性； B．方便升级。 2.Bug等级 BUG等级是根据BUG出现在系统中的严重程度来分的，主要定义如下5级： 1级——致命：系统重要功能无法正常使用，系统崩溃；系统设计存在重大隐患；导致用户利益受到重大损失。该级别需要程序员修改。 2级——严重：系统主要功能无法正常实现，系统业务受到严重影响；导致用户利益受到损失。该级别需要程序员修改。 3级——一般：系统次要功能无法实现；主要功能部分失效；系统业务受到影响；导致用户利益受到一定损失。该级别需求程序员修改。

Bug处理流程标准

华途Bug处理流程标准 版本变更记录 一、制定本标准的目的 制定本标准的目的是控制产品质量、相关发布流程等，以统一的标准来度量待发布产品及版本，为质量控制提供依据。 本标准实施的主要依据是产品测试及其缺陷分析。 发布标准的制定有利于规范产品发布要求，使产品符合公司的质量要求。 二、缺陷分类 缺陷分类和定级要从客户、使用者以及公司利益的角度出发，而不是从设计者的角度，评估该缺陷可能给客户或者公司带来的影响、造成的损失，从而确定缺陷等级。 具体缺陷级别的指定，由测试人员根据本缺陷分类原则进行。 1.缺陷分类原则 i．A级（致命）BUG： 原则：可能导致客户网络中断、业务中断的故障，可能给公司利益造成重大损失的，无论必现或偶现，都定为5级缺陷。 例如： <1>设备崩溃、重启、死机、网络不通等 <2>执行直接导致系统死机、挂起或是程序非法退出； <3>软件的安全缺陷导致重要数据丢失或损坏，导致系统无法启动或正常工 作； <4>程序执行过于缓慢或是占用过大的系统资源，有时系统失去响应； <5> 数据通讯失败 ii．B级（严重）BUG： 原则：主要功能，或功能的主要部分无法正常运行，影响客户网络或者业务的，可能损失公司形象或者利益的，定为4级缺陷。 例如： <1>规格中定义的功能点或需求点没有实现或无法使用； <2>软件的实际执行过程与需求有较大的差异； <3> 主功能块功能失败，偶现，或者在某些环境下无法实现； <4> 产品性能低下，达不到设计要求； <5> 主功能块功能正常，经常用子模块功能失败； <6> iii．C级（一般）BUG：

原则：子功能失败、不稳定，对客户使用造成一定影响的，定为3级缺陷。 例如： <1>功能子模块中，非经常用模块功能失败 <2>子功能中参数失败、错误； <3>子功能失效； <4> 程序的提示信息错误或者无法正确指明错误原因的； <5> 软件的易用性不好，导致用户根据软件提示无法正常完成安装和执行主要 功能同时缺乏提示； <6> iv．D级（轻微）BUG： 原则：功能正常，不影响使用，但是给客户理解或者使用造成困难的，定为2级缺陷。 例如： <1>软件交互性不好，文字表达对于用户可能造成难于操作和理解； <2> 有明显的错别字，或者格式不统一； <3> 程序的提示信息描述容易使用户产生混淆，对功能没影响； <4> 界面操作注释信息容易引起混淆 <5> 提示框返回后焦点停留位置不合理 v．E级（建议）BUG： 原则：使用不便，认为需要改进的地方，定为1级缺陷。 例如： <1>产品建议； 2.BUG分类冲突协商办法 缺陷提交和定级由测试人员（T）进行，若其他人员有异议的（C），按照以下优先次序进行解决： i．C和T直接沟通，解释说明等，若认可，则由T在缺陷跟踪系统上写明等级变更或缺陷取消的原因。 ii．C的上级和T的上级（测试经理）进行沟通，若认可，则由T的上级在缺陷跟踪系统上写明等级变更或者缺陷取消的原因，同时，T也把自己意见在缺陷跟踪系统上标明（可坚持自己意见）。 iii．若沟通无法解决，提交CCB后，以CCB讨论意见为准，以及最后结论写入缺陷跟踪系统。 3.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中解决方案定义部分，在缺陷管理系统中解决方案选择相应的选项，解决后系统将自动指派回给创建者。 如果Bug无法解决或修改影响比较大，可申请进入“延期解决”流程，请参考5.2中延期处理部分。 （5）验证问题 创建者需要及时对解决状态的Bug在对应版本上面进行验证。如果验证通过，则可关闭Bug；如果验证不通过，则激活此Bug，系统将自动指派回给解决者。

《bug处理流程》

BUG处理流程说明 一、B UG处理流程图： 流程描述： 1、测试人员发现bug提交给开发。 2、开发人员判断是否是bug。 3、如果是bug，进行修改，修改完成后更改bug状态为已解决。 4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因， 或者不能重现。

5、开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。 6、验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。 7、测试人员需要对开发人员退回的bug进行确认。 8、确认不是bug关闭。 9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。 10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。 注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。 二、各角色应关注的状态 1.开发人员：激活、重新打开 激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解 决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。 重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需 要继续修改。 2.测试人员：已解决、无法重现、设计如此、外部原因、延期处理 已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解 决，要将其置为“关闭”。否则“重新打开” 无法重现：测试人员发现状态为“无法重现”的BUG，要及时修改，把步骤描 述清楚，并将其状态置为“重新打开”。 设计如此：测试人员发现状态为“设计如此”和“外部原因”的BUG，要及时 通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行定期 跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责 人。 3.项目经理：设计如此、外部原因、延期处理 设计如此：因为这些BUG都是测试人员和开发人员有争议的BUG，因此项目经 理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关 闭”，如果需要立刻解决置成“重新打开”，否则置成“以后解决”。同时，项目 经理也要关注“延期处理”的BUG，以免其被漏掉或遗忘从而影响到项目上线。 三、缺陷严重级别及类型定义 ◆致命错误包括： 1．造成系统崩溃、死机 2．造成程序非法退出、死循环、通讯中断或异常 ◆严重错误包括：

Bug处理流程

杭州家和物联技术有限公司 附件2： Bug 处理流程 Bug 处理流程 市场客服 产品测试 继续处理 研发 测试报告填写缺陷与限制，bug 入库，设置状态New 研发对提交的Bug 进行重现、评估 Bug 收集整理 邮件抄送 邮件发送Bug 处理 判定为无效Bug ，在反馈的测试报告上状态设为Invalid 否 在JIRA 上创建问题，状态设置为” 开始“ 是 判定为拒绝修改或搁置的Bug 测试、产品研发讨论是否 搁置 是Bug 是否解决 JIRA 平台将问题状态设为”已解决“测试测试报告中设Bug 状 态为解决 是 测试报告中将Bug 状态设为Wontfix 并注明原 因 否 缺陷与限制邮件反馈 验证Bug 是否 修正 缺陷与限制邮件反馈 是 在JIRA 平台上将对应问题状态设为“重新打开” 否 定期跟踪关注未解决的Bug 继续解决 JIRA 平台相问题注释进度。测试报告中设Bug 状态为未解决 测试报告中将Bug 状态 设置为close 否报告Bug ，填写描述情况。 紧急bug 的处理 综合技术的Bug 处理结果，更新缺陷与限制 分表 在JIRA 平台上将对应问题状态设置为“关闭”Bug 管理邮件抄送回复客户 反馈流程说明： 1、 测试员提交的测试报告缺陷与限制分表将新的Bug 入库，错误状态为New 。 2、 测试员将测试报告发送给相应的开发人员并抄送给产品。 3、 研发对测试报告的缺陷与限制分表中的bug 进行评估反馈。 4、 对于测试报告提交的无效Bug ，研发在表格上其状态置为Invalid 。 5、 对于测试报告提交的Bug ，研发拒绝修改或搁置不改的在表格上设置为Wontfix 。 6、 对于测试报告提交的普通Bug,，研发在JIRA 问题管理平台上创建相关条目，并开始处理，该问 题状态为开始，研发修复Bug 后，在平台上将其状态设置为已解决。 7、 对于不能修改或者建议不修改的问题，及时反馈给测试和产品，经讨论决定后，才能置为暂时不 修改Wontfix 。 8、 测试员在JIRA 问题管理平台上查询状态为已解决的Bug ，然后验证Bug 是否已解决，如解决则 将测试报告缺陷与限制分表中设置Bug 的状态为Close ，如没有解决则让研发在JIRA 问题管理平台上将Bug 状态设置为重新打开。

禅道bug提交管理规范

禅道Bug提交管理规范 修订历史

目录 目录 (2) 1. 目的 (3) 2. 禅道系统Bug流程图 (4) 3. Bug流程操作及其Bug相关信息解释 (5) 3.1.测试人员发现bug (5) 3.2.测试人员创建Bug (5) 3.3.开发人员设定Bug优先级别并确认Bug (7) 3.4.开发人员解决Bug (8) 3.5.测试人员验证Bug (9)

1.目的 本文档定义了bug管理流程及其bug相关信息内容。 本文档适用范围： ●本文档适用于新产品以及以后新产品的项目。原有项目的bug管理仍然用JIRA系 统进行管理。 ●本文档适用于新产品以及以后新产品的项目相关的测试人员和开发人员。

2. 禅道系统Bug流程图

3. Bug流程操作及其Bug相关信息解释 3.1.测试人员发现bug 3.2.测试人员创建Bug 测试人员登录禅道系统，创建Bug。Bug状态为激活（未确认） 创建Bug页面截图： 页面字段注释： 所属产品：选择发现Bug的产品，必填项。 所属模块：选择发现Bug的对应模块，必填项。 所属项目：选择测试所属的项目。必填项。 影响版本：选择发现bug的版本。必填项。 当前指派：选择指派的开发人员。必填项。 Bug标题：用简单明了的语句说明Bug内容，相当于BUG的中心语句。必填项。 在标题上注明bug出现的频率（稳定出现/经常出现/很少出现/出现一次）重新步骤：重现步骤格式如下。必填项。 [环境]：如果系统/浏览器信息不能够全部说明发现Bug的环境，需要在 重现步骤里详细描述环境信息，以便于开发定位和解决问题。 [步骤]：写明出现Bug的操作步骤，要求简单，去掉与Bug无关的步骤。 [结果]：写明操作的实际结果。

《bug处理流程》

BUG处理流程说明 一、BUG处理流程图： 流程描述： 1、测试人员发现bug提交给开发。 2、开发人员判断是否是bug。 3、如果是bug，进行修改，修改完成后更改bug状态为已解决。 4、如果不是bug，退回给测试人员并描述退回原因，或为设计如此，或为外部原因， 或者不能重现。

5、开发人员修改完成的bug，由测试人员进行验证，确认修改正确，关闭bug。 6、验证未通过的bug重新激活，开发人员继续修改，直至验证通过，关闭bug。 7、测试人员需要对开发人员退回的bug进行确认。 8、确认不是bug关闭。 9、如与开发人员意见不一致，认为是bug，需提交项目负责人仲裁。 10、项目负责人确认是bug由开发人员修改，不是bug由测试人员关闭。 注：除提交项目负责人仲裁环节外，其他环节都可以在禅道上完成。 二、各角色应关注的状态 1.开发人员：激活、重新打开 激活：开发人员要对处于激活状态的bug进行处理，处理后将其状态置成“已解 决”、“设计如此”、“无法重现”、“外部原因”、“重复bug”或“延期处理”。 重新打开：重新打开的bug是已解决的bug经过测试人员验证，未修改正确，需 要继续修改。 2.测试人员：已解决、无法重现、设计如此、外部原因、延期处理 已解决：测试人员发现状态为“已解决”的BUG，要及时验证，如果确实已解 决，要将其置为“关闭”。否则“重新打开” 无法重现：测试人员发现状态为“无法重现”的BUG，要及时修改，把步骤描 述清楚，并将其状态置为“重新打开”。 设计如此：测试人员发现状态为“设计如此”和“外部原因”的BUG，要及时 通知项目经理，由项目经理来决定是否修改；对“延期处理”的问题要进行定期 跟踪，如发现问题没有按注释进行修改要及时通知开发人员或汇报给相关负责 人。 3.项目经理：设计如此、外部原因、延期处理 设计如此：因为这些BUG都是测试人员和开发人员有争议的BUG，因此项目经 理必须及时关注这些BUG，及时给出合理的定夺，如果不需修改把状态置成“关 闭”，如果需要立刻解决置成“重新打开”，否则置成“以后解决”。同时，项目 经理也要关注“延期处理”的BUG，以免其被漏掉或遗忘从而影响到项目上线。 三、缺陷严重级别及类型定义 ◆致命错误包括： 1．造成系统崩溃、死机 2．造成程序非法退出、死循环、通讯中断或异常 ◆严重错误包括：

Bug流程管理规范

一、文档目的 作为质量管理体系的一部分，Bug管理对一个项目组是否具有规范化的流程显得尤其重要。编写此文档的目的是为了完善项目组的Bug管理流程，提高Bug质量，帮助测试组和开发组进行更好的沟通。此文档的阅读者包括开发人员、测试人员以及项目组管理人员。 二、Bug管理流程 为了更直观的阐述Bug管理流程，本文以流程图的方式来说明。如下图：

Bug状态(Status)和解决状态(Resolution)的说明： Status： New——当测试人员新提交一个Bug, Bug的状态默认为New Open——测试组长对新提交的Bug进行确认，如为有效Bug，Bug指给相关开发人员并且把Bug状态设置为Open In Progress——开发人员确认为有效Bug，并且开始处理Bug时，修改Bug的状态为In Progress Resolved——开发人员对Bug完成处理，把Bug状态设置为Check In，并且把Bug指回给开发人员进行验证 Reopen——开发人员已解决问题，测试不认同开发人员的解决方案时，将Bug重新打开Closed——当Bug已经确认被解决或者确认不是Bug的时候将Bug的状态设置为Closed Resolution： Need More Information——需要更多信息。当测试组长确认Bug，发现Bug描述不够详尽时，把Bug指回给Bug的Reporter，并且把Resolution项设置为Need More Information，对应的状态为Open；当开发人员处理Bug时，需要测试人员提供更多的Bug信息，把Bug指回给Bug的Reporter，并且把Resolution项设置为Need More Information，对应的状态为In Progress。 Invalid——无效。测试组长确认Bug，发现该Bug无效时，把Resolution项设置为Invalid，对应的状态为Closed；当开发人员处理Bug，发现该Bug无效时，把Resolution 项设置为Invalid，对应的状态为Resolved。 Duplicate——重复。测试组长确认Bug，发现该Bug和已有Bug重复时，把Resolution 项设置为Duplicate，对应的状态为Closed；当开发人员处理Bug，发现该Bug和已有Bug重复时，把Resolution项设置为Duplicate，对应的状态为Resolved。 Fixed ——已修复。开发人员对Bug修改完成并且已经登记，等待测试人员确认，把Bug 指回给Bug的Reporter，并且把Resolution项设置为Fixed，对应的状态是Resolved；测试人员对Bug完成验证并且确认已修复，把Resolution项设置为Fixed，对应的状态是Closed。 Unable To Reproduce——无法复现。被指派的开发人员对Bug进行修改但发现Bug始终不能再现的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Unable To Reproduce, 对应的状态是Resolved；测试人员对Bug完成验证并且确认无法复现，把Resolution项设置为Unable To Reproduce，对应的状态是Closed。 Won’t fix——不准备修。开发人员确认Bug有效但是不准备修改这个bug的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Won’t fix，对应的状态是Resolved；测试人员对Bug完成验证并且确认Bug不需要修复的时候，把Resolution项设置为Won’t fix，对应的状态是Closed。 Suspended ——延期。开发人员确认Bug有效但是在当前版本不准备修复该Bug，下个版本再提供解决方案的时候，把Bug指回给Bug的Reporter，并且把Resolution项设置为Suspended，对应的状态是Resolved；测试人员对Bug完成验证并且确认当前版本不准备修复该Bug时，把Resolution项设置为Suspended，对应的状态是Closed。

JIRA的BUG管理规范

xxxxxxxxxxxxxxxxxxxxxxxxxx 测试组BUG管理规范

版本历史

目录 1BUG管理工具介绍 (3) 2BUG定义 (3) 2.1BUG分类 (3) 2.2Bug 等级 (4) 2.3Bug 状态 (4) 2.4Bug优先级 (5) 3BUG的生命周期 (5) 4BUG管理规范 (6) 4.1项目的创建 (6) 4.1.1项目名称及代号规范 (7) 4.1.2项目的模块及版本划分规范 (7) 4.1.3用户角色权限分配规范 (7) 4.2BUG提交规范 (7) 4.2.1BUG 的报告内容 (8) 4.2.2问题类型选择 (9) 4.2.3BUG 简要描述 (11) 4.2.4优先级选择 (11) 4.2.5模块及版本选择 (11) 4.2.6BUG 详细描述 (11) 4.2.7其他规范 (12) 4.3BUG分配及处理 (12) 4.3.1BUG 的分配 (12) 4.3.2BUG 处理 (13) 4.4BUG验证及关闭 (13)

1 BUG管理工具介绍 常用的BUG 管理工具有JIRA、BugFree、Bugzilla、Mantis、XPWeb 等。我们公司采用的是 JIAR ，JIRA 是Atlassian 公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 2 BUG定义 2.1BUG分类 BUG 就是指系统存的各种缺陷，可以从很多角度对BUG 进行分类。 1、从功能方面分，产生BUG 的原因大体可以归结为以下四种： A.重复的功能； B.多余的功能； C.功能没有达到设计的要求； D.功能实现与设计要求不相符。 2、从易用性方面分，可以归结为三点： A. 界面不美观，控件排列、格式不统一，焦点控制不合理或不全面； B .缺少帮助信息，或者帮助信息不完全； C.功能操作复杂，提示信息不合理，易产生歧义。 3、从安全性方面分，BUG 可以划分为以下几类： A.数据有效性检测不合理； B.重要数据在传输中没有加密； C.缺少身份认证机制或认证不合理； D.数据产生缺乏随机性； E.网络安全性：开放端口、服务； F.系统日志、审计。 4、从可靠性方面分，BUG 可划分为以下几类： A.数据存贮的可靠性； B.业务处理的可靠性； C.硬件可靠性：如打印机； D.应急处理措施； E.数据备份、恢复。 5、从性能方面考虑，BUG 可划分为三种： A .并发量； B .吞吐量； C .响应时间。

BUG处理流程规范

BUG提出和处理流程规范 1引言 1. 1目的 提高测试以及产品缺陷修改效率，避免出现搁置和遗漏的缺陷，从而提高产品的质量，降低质量检查和缺陷修改成本 1. 2适用范围 适用于研发部门（Confernece、Flash、监控），质量保证部门 1.3 定义 bug：通过测试检查出的产品缺陷； 新建、打回、已确认、已指派、已解决、已关闭：测试中bug的不同状态，详细信息见本规范第3部分； 1. 4参考资料 无 2 BUG提交和处理规范说明 1、在测试人员提交bug的时候，必须对bug信息进的描述必须详细全面、清晰明确，如果有条 件，需要描述使用的环境，在BUG出现前的具体操作，如果抓图，必须抓取jpg全屏图象，但不能使用BMP格式上传到BUG库中，有抓包文件需要上传BUG库，空间不够需要放到\\192.168.0.254\qa\测试\bug日志目录中，标题以BUG号区分； 2、在测试人员提交bug的时候，必须按具体情况，填写重要级别、出现频率、优先级别三个栏 目，而非测试人员不得对上述信息进行直接改变，如觉得这三个信息填写不恰当，可以在该bug下的注解中提出意见，并“打回”给bug提交人员或质量部经理处，经过确认后修改；

3、开发人员对bug进行处理后的变更状态成“打回”时，或“指派”给产品部门时以及变更成 “已确认”时必须进行必要的描述和说明,在状态变更时，必须要指定具体接收人； 4、开发人员在注解中描述该BUG计划什么时候解决或做其他阐述的时候，要明确写清承诺的 具体版本号，禁止使用“上一版本”、“本版本”、“下一版本”等字样，以免造成误会或混淆； 修改完成的BUG注释中加入相关的确认信息，如“XXX Review并通过。 5、如果已经是“关闭”状态的BUG，测试人员在后期测试中又出现了需要重新打开，重开后 的BUG状态为“打回”，测试人员需要再多一个操作，即“指派”给具体的研发人员。 6、一直处于“打回”状态的BUG，测试人员需要经过两轮（即两个版本）测试后仍然没有重 现的，可以关闭。但是此两轮测试在该BUG中必须有注释，比如：“XX版本（要求有具体版本号）测试没有重现”，当第二轮测试仍没出现时也需要注释一次，即可进行关闭。 3 Mantis Mantis是PHP/MySQL/Web-based缺陷跟踪系统。 其特点： 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件； 支持多项目、多语言； 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动； 主页可发布项目相关新闻，方便信息传播； 支持上传文件，提供进一步的bug信息； 支持上传项目文档； 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷； 缺陷报告可打印或输出为CSV格式。支持可定制的报表输出，可定制用户输入域； 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel 中进一步分析； 流程定制不方便，但该流程可满足一般的缺陷跟踪。 在提交bug时需要填写相关信息，还可以上传相关文件（如出错的log或者截图等），对于bug添加注释（允许再次更新）。下面是基本信息的介绍 [出现频率] 可重现-- 稳定地能重现 经常-- 比较经常出现 偶尔-- 偶尔出现 不可重现-- 无法重现 N/A -- 其他情况 [严重性] 不合理或别扭-- 使用不方便，吹毛求疵的标准 文本错误-- 文本错误 崩溃死锁-- 导致死机的bug 严重错误-- 导致功能无法正常运行下去

Bug定义规范

BUG定义规范Revision History

1.目的 对BUG概念、BUG提交和验证、BUG状态、BUG严重程度等内容进行定义和规范，以便进一步指导我们的测试工作 2.概念 BUG:软件中存在的瑕疵，可能会导致软件失效。简单的说就是软件系统中存在的可能导致系统出错、失效、死机等问题的错误或缺陷 3.BUG管理工具 以Quality Center 9.0为提交、跟踪等工具 4.BUG提交和验证要求 以QC中的字段为准 提交时必选字段有：摘要，跟踪类型，检测者，检查日期，计划关闭版本，可重现，分 派给，严重程度，状态，描述 验证后，需要修改字段：关闭于版本，关闭日期，状态BUG描述模板如下： [问题概要]: [重现步骤]: 步骤1. 步骤2. [隔离分析]: [期望结果]: [重现概率]: [Test Case No.]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） [Test Case]:（若没有用例，则标注‘NA’，若是地区版本上的问题，则标注地区名称） QC中优先级和严重程度的区别：优先级由软件开发人员填写，严重程度由测试人员填写 计划关闭版本定义： 有2重含义：1.由测试人员填写当前发现bug的版本号；2.开发人员必须在此版本上修改 5.BUG验证 开发人员必须提供修改此bug会涉及到的功能点列表，并将此信息填写到bug描述中。 测试人员除验证此bug外，还需要将开发列出的功能点逐一验证，同时写入自己考虑到的功能点验证情况 来自需求和测试自己提交的问题，测试人员都需要验证，并填写测试结果，其中来自自己的bug，若验证通过，则修改状态为“关闭”；来自需求人员的bug，则修改状态为“验证完毕”，由需求人员来关闭（适用于胜算组）。 6.BUG状态流程 在正在BUG生命周期中，可能会经历很多状态，如：新建、提交验证、已关闭、重新打开、已挂起、重复提交等。 新建：新发现的问题 提交验证：开发修改bug后，会将状态变为提交验证，让测试工程师来执行验证操作已关闭：测试工程师经过验证后，发现此问题已经被修复，则修改状态为已关闭

bug定义规范

Bug定义规范 1、bug类型的划分 功能类： 1、重复的功能 2、多余的功能 3、功能实现与设计要求不符合 4、功能使用性、方便性、易用性不够 5、功能未实现 界面类： 1、界面不美观 2、控件排列、格式不统一 3、焦点控制不合理或不全面 数据处理类： 1、数据有效性检测不合理 2、数据来源不正确 3、数据处理过程不正确 4、数据处理结果不正确 流程类： 1、流程控制不符合要求 2、流程实现不完整 提示信息类： 1、提示信息重复或出现时间不合理 2、提示信息格式不符合要求 3、提示框返回后焦点停留位置不合理 建议类： 1、功能性建议 2、操作建议 3、检校建议 4、说明建议 2、bug等级定义 Level 1-致命的bug：100%程序崩溃、重启、死机，自动退出，用户数据丢失，缺少主要功能。 1、程序无法正常使用，在正常操作流程中（特别是操作步骤不复杂，用户很容 易就用到）出现崩溃、死机现象 2、100%导致用户数据丢失的问题 3、被测试数据系统频繁崩溃，程序出错，使功能不能继续使用 4、性能与需求不一致 5、系统资源引发性能问题 6、系统配置引发错误 7、安全性问题

Level 2-严重的bug：所产生的问题导致系统瘫痪，重要功能未实现，严重影响用户使用的问题，关键用户需求未实现或软件功能与需求严重不符。 1、功能与需求不一致，或功能未实现 2、功能有错误 3、数据传输有错误 4、安装与卸载有问题 Level 3-一般的bug：所产生的问题会导致系统部分功能不正常，虽然产生的问题严重，但不影响下一步的测试，严重的界面提示问题。 1、功能有错误，但不影响使用 2、重要界面的显示问题 3、内存泄露导致某些功能无法正常使用，释放内存重启后系统恢复正常 4、复现率较低的死机、重启问题，步骤多用户不易操作到 5、边界条件出错 Level 4-轻微的bug：轻微界面显示问题，对用户使用无影响的问题。 1、微小功能问题，如闪烁中间界面、界面刷新慢 2、轻微的界面显示错误，界面设计不规范，交互不友好 3、消息、提示信息不准确 4、用户可以接受，对功能不影响 5、某些次要功能，在进行某些很特殊的操作后某些功能不能正常响应 Level 5-建议性bug：功能运作正常，可是有改进的空间，建议性问题所产生的问题不会导致系统任何问题。 1、可以忽略不计的问题，对用户使用没有任何影响，但有改进空间 2、软件设计有问题 3、文档不完整或不准确 4、其他建议性问题 3、BUG状态 （初始状态） 1、已提交：测试人员员发现BUG后提交到BUG管理系统中的状态。 2、已修改：开发人员在修改了BUG后提交到BUG管理系统中的状态。 3、不修改：程序员或产品人员根据需求分析、概要设计、详细设计说明书等经过考虑后决定对BUG不进行修改。其BUG的状态为不修改，需要说明理由。 4、延迟：根据目前项目进程或计划等情况，暂时延期的状态 5、待讨论：需要进行讨论后才能决定是否需要修改的BUG的状态。 6、已验证：已经解决的并经过测试员复测的BUG的状态。 7、关闭：完全解决了，只供以后备查的状态 8、重新打开：重新出现在新的版本中，重新打开以前关闭的BUG的状态

禅道系统_BUG流程分析

Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提，如果没有这个前提，我们可能会无法重现问题，或者跟本就无从下手。 操作系统 这个是一般软件运行的一大前提，基本上所有的软件都依赖于操作系统之上的，对于一个软件来说，要想在某个操作系统上运行，必须要对这个操作系统支持，这就需要有真对性的设计与开发。对于不同的操作系统，其可能存在差异（如：win xp 与 win 7）或本质的区别（如 win 7 与 CentOS linux ），所以，操作系统环境是重现问题的一个重要前提。浏览器 对于B/S系统，或面向大众的互联网产品（网站，邮箱等），浏览器的兼容性也是必须测试的一个重点，对于现在的浏览器市场，各式的浏览器都有其用户群，要想使产品大众化，必须考虑这些产品的兼容性问题。 不同的浏览器之间（IE、 firefox、chrome、opera 等），甚至同一系列不同版本（ie6/ie7/ie8/ie9等）都可能存在兼容性问题，所以，对于这类应用，浏览器环境重现bug 前提条件之一。 其它（这个“其它”非常重要） 对于不同的系统发现重现问题，都会有其特定的前提，拿我测试的邮箱来说，必须要描述其是在测试线还是现网环境，而且还要附带一重现问题的帐号等。 对于c/s软件，可能还要考虑与其它常用软的兼容等，例如，是在安装的某款软件后，对本

软件的安装和使用造成影响。这些都是重现问题的必须描述的环境。 问题类型 根据JIRA的管理系统的划分，bug 只是问题的一种，它可以用于跟踪多种不同类型的问题（其实，他只是将bug做为一子类而已）。 JIRA系统缺省提供的问题类型（大部分的系统都可以自定义类型的，这样就增加了灵活性。） Bug : 测试过程、维护过程发现影响系统运行的缺陷。（这就是一般测试人员所提交的bug）New Feature : 对系统提出的新功能。（单个的小需求可以，如果大的话，就相当于一个需求，放到这里是不合理的。） Task : 需要完成的一任务。（开发或测试任务指派。） Improvement : 对现有系统功能的改进。（一般产品经理或产品体验师做的事）当然，不同的公司，他们的人员定位与职责是不太相同的，按照上面的分类，JIRA就不是简单的缺陷管理系统了，它涵盖一项目（或产品）所需要处理的任务、需求与缺陷。 Bug 类型： 这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。 下面看一些常见的分类：