BUGFREE使用说明
一、BUG管理
1、BUG的3种状态
2、BUG 生命周期
新建的Bug处于Active状态，可以通过编辑指派给合适的解决者。
解决Bug之后，Bug状态变为Resolved，并自动指派给创建者。
创建者验证Bug。
如果未修复，再重新激活，Bug状态重新变为Active；如果已经修复则可以关闭，Bug状态变为Closed，Bug生命周期结束。
已经Closed的Bug如果重新复现，也可以直接激活。
具体流程如下图所示。
3、BUG的七种解决方案
4、BUG 字段说明
Bug 标题：为包含关键词的简单问题摘要，要有利于其他人员进行搜索或通过标题快速了解问题。
项目名/模块路径：指定问题出现在哪个项目的哪个模块。
Bug处理过程中，需要随时根据需要修改项目或模块，方便跟踪。
如果后台管理指定了模块负责人，选择模块时，会自动指派给负责人。
指派给：Bug的当前处理人。
如果不知道Bug的处理人，可以指派给Active，项目或模块负责人再重新分发、指派给具体人员。
如果设定了邮件通知，被指派者会收到邮件通知。
状态为Closed 的Bug，默认会指派给Closed，表示Bug生命周期的结束。
抄送给：需要通知相关人员时填写，例如测试主管或者开发主管等。
可以同时指派多个，人员之间用逗号分隔。
如果设定了邮件通知，当Bug有任何更新时，被指派者都会收到邮件通知。
严重程度：Bug的严重程度。
由Bug的创建者视情况来指定，其中1为最严重的问题，4为最小的问题。
一般1级为系统崩溃或者数据丢失的问题；2级为主要功能的问题；3级为次要功能的问题；4级为细微的问题。
优先级：Bug处理的优先级。
由Bug的处理人员按照当前业务需求、开发计划和资源状态指定，其中1的优先级最高，4的优先级最低。
一般1级为需要立即解决的问题；2级为需要在指定时间内解决的问题；3级为项目开发计划内解决的问题；4级为资源充沛时解决的问题。
创建Build：Bug是在哪个版本（Build或者Tag）被发现的。
解决Build：Bug是在哪个版本（Build或者Tag）被解决的。
解决方案：参考Bug的七种解决方案。
如果解决方案为Duplicated，需要指定重复Bug的编号。
处理状态：Bug处理过程的附属子状态，例如Local Fix表示已在本地修复；Checked In表示修复代码已经提交；Can’t Regress表示修复的问题暂无法验证等。
机器配置：测试运行的硬件环境，例如Dell G280 2G/200G。
关键词：主要用于自定义标记，方便查询。
关键词之间用逗号或者空格分隔。
例如，对于跨团队的项目开发，可以约定一个关键词统一标记项目。
相关Bug：与当前Bug相关的Bug。
例如，相同代码产生的不同问题，可以在相关Bug注明。
相关Case：与当前Bug相关的Case。
例如，测试遗漏的Bug可以在补充了Case之后，在Bug 的相关Case注明。
上传附件：上传Bug的屏幕截图，Log日志或者Call Stack等，方便处理人员。
复现步骤：[步骤]要描述清晰，简明扼要，步骤数尽可能少；[结果]说明Bug产生的错误结果；[期望]说明正确的结果。
可以在[备注]提供一些辅助性的信息，例如，这个bug在上个版本是否也能复现，方便处理人员。