禅道bug管理基本流程
禅道里面的bug基本流程是：测试人员提出bug -> 开发人员解决bug -> 测试人员验证关闭。
下面我们来演示下具体的使用方法。
一、创建产品
使用bug管理功能之前，需要先创建产品。禅道里面设计的理念是bug主要附属在产品概念下面的，后面我们会详细讲述产品和项目之间的关系。
新增产品的时候，需要设置产品的名称、代码，几个负责人信息。
二、提出bug
有了产品之后，我们就可以来创建bug了。
?在创建bug的时候，必填的字段是影响版本，bug标题，重现步骤这些基本的信息。
?所属项目，相关产品，需求可以忽略。
?创建bug的时候，可以直接指派给某一个人员去处理。如果不清楚的话，可以保留为空。
三、解决bug
当一个bug指派给某一位研发人员之后，他可以来验证解决这个bug。
3.1 通各种标签和检索条件找到需要自己处理的bug
在对bug进行出来之前，需要先要找到需要自己处理的bug。禅道提供了各种各样的检索方式，比如指派给我，可以列出所有需
要我处理的bug。
3.2 解决bug
研发人员解决bug，选择解决方案，一般来讲有效的解决bug方案是”已解决“。
四、关闭bug
当研发人员解决了bug之后，bug会重新指派到bug的创建者头上。这时候测试人员可以来验证这个bug是否已经修复。如果验证通过，则可以关闭该bug。
Weilu
BUG处理情况 一、详尽的项目测试 在项目建设过程中，必须加强测试工作，采取如下措施： 需求转测试 需求人员在完成需求工作后，可以部分转换到测试组，这样可以很好的进行项目移交，保证测试用例的完整性。 测试方案提前编写 测试方案应提前到设计阶段进行编写，当需求初步定型或评审通过后，就开始测试方案的编写工作。测试人员技术设计人员背靠背工作，这就给测试方案的编写争取了更多的时间，保证测试用例的全面性和质量。 测试自动化 测试工作的展开完全靠手工进行是不现实的，必须借助有关的测试工具，提高测试的效率和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. 如果不可重现，应说明 附件：添加错误附图或错误信息。
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优先原则，严重程度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描述要求’的有关内容。
软件缺陷管理办法 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中延期处理部分。
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的生命周期：
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处理流程标准 版本变更记录 一、制定本标准的目的 制定本标准的目的是控制产品质量、相关发布流程等，以统一的标准来度量待发布产品及版本，为质量控制提供依据。 本标准实施的主要依据是产品测试及其缺陷分析。 发布标准的制定有利于规范产品发布要求，使产品符合公司的质量要求。 二、缺陷分类 缺陷分类和定级要从客户、使用者以及公司利益的角度出发，而不是从设计者的角度，评估该缺陷可能给客户或者公司带来的影响、造成的损失，从而确定缺陷等级。 具体缺陷级别的指定，由测试人员根据本缺陷分类原则进行。 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 BUG管理流程 (1) 2 报告缺陷注意事项 (2) 3 需要注意的地方 (3) 4 Bug的严重级别 (3) 1BUG管理流程
2报告缺陷注意事项 1．测试人员提交新缺陷时，尽量用最简洁的语言最清晰的描述出BUG的出处、操作步骤、现象、（建议），并尽量截图； 2.测试人员在精简语句的同时，应该再仔细检查BUG描述是否会产生误解的地方。测试人 员应该尽量避免使用模糊的，会产生歧义的、主观的词语。目标是使用能够表述事实、清楚的，不会产生争执的词语； 3 不要使用感叹号或其它表现个人感情色彩的词语或符号； 4. 不要使用含糊的词语（例如，好像，似乎）来描述发现的现象； 5. 当BUG指派给你，在下一个版本发布之后，第一时间跟踪BUG的修复情况。
3需要注意的地方 当你发现一个BUG时，请考虑如下问题： 1. 同一软件中的相似功能是否有相同的问题？ 2. 其他的浏览器是否有相同的问题？ 3. 其他的软硬件配置是否有相同的问题？ 4. 其他的区域是否有相同的问题？ 5. 以前的版本是否有相同的问题？ 4Bug的严重级别 目前，BUG严重级别分为：严重缺陷、较严重缺陷、一般性缺陷、建议性缺陷。 一、严重缺陷主要包括： 1、由于程序所引起的死机,非法退出； 2、死循环； 3、数据库发生死锁； 4、因错误操作导致的程序中断； 5、功能错误； 6、与数据库连接错误； 7、程序错误； 8、程序接口错误。 二、较严重缺陷 1操作界面错误（包括数据窗口内列名定义、含义是否一致）； 2、打印内容、格式错误； 3、简单的输入限制未放在前台进行控制； 4、删除操作未给出提示； 5、数据库表中有过多的空字段。 三、一般性缺陷
软件缺陷管理办法 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处理流程说明 一、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．造成程序非法退出、死循环、通讯中断或异常 ◆严重错误包括：
杭州家和物联技术有限公司 附件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处理流程图： 流程描述： 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 开发人员确 认bug Bug?开发Fix bug 测试验证bug 验证通过? 关闭bug Y Y N 延期修复 项目经理 确认 挂起 Y N Y 测试人员 重新确认Bug?N Y N
三、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质量，帮助测试组和开发组进行更好的沟通。此文档的阅读者包括开发人员、测试人员以及项目组管理人员。 二、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。
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提出和处理流程规范 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重现环境 这个应该是我们重现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 类型： 这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。 下面看一些常见的分类：