Bug 类型：
这里缩小范围，单指我们测试人员在测试过程中发现的缺陷，发现产品缺陷其实就是测试人员工作的主要目的。当然，你要确定一个问题的类型，也需要对项目（或产品）有比较深的理解。是代码缺陷还是设计缺陷有时候就不太容易区分，当然，这个划分，对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。
- 划分方式一：
- 代码错误
- 设计缺陷
- 界面优化
- 配置相关
- 安装部署
- 性能问题
- 标准规范
- 测试代码
- 其它
- 划分方式二：
- 功能类（function）
- 性能类（performance）
- 界面类（UI）
- 易用性类（usability）
- 兼容性类（compatibility）
- 其它（else）
这个分类当然是可以自定义的，可以拿来做特定环境下的系统来使用，或想用这个系统来指派任务，那么自定义类型为前端任务、后端任务、测试任务、配置部署等。
几款处理工具
- BugLogHQ
BugLogHQ 是一款免费和开源的工具，主要功能是处理多个应用中的 Bug 和可能遇到的问题。它能提供统一标准的错误信息显示，允许用户简单的进行搜索，图形化，甚至是跟踪 Bug 报告。它还会提供一个仪表板来显示聚合的数据视图，帮助用户监控整个项目的健康情况。
- LogDigger
LogDigger 是个拥有终极套件工具的软件，帮助用户分类和收集用户基于 Java 应用的详细错误报告信息。它能运行任意的 Java 开发框架，而且体积非常小，只有 500KB。同时，它还能通过 HTTP POST 来构建自定义模块，发送到 BugDigger 进行自动排序。它的界面非常直观，不存在任何易用性问题。
- Bugnet
Bugnet 是一款开源的问题跟踪&项目管理工具，基于最新的 ASP.NET 框架、SQL Server 和微软服务器平台。Bugnet 可同时管理多个项目、自定义属性、字段、附件、注释、邮件通知等等。
- Bugify
Bugify 是个非常简单的问题跟踪系统，并且功能非常强大。它的主要功能：问题优先级，搜索过滤，邮件通知，标签，问题链接，键盘快捷键，Mardown 格式化，最突出的功能就是支持无限种其他语言。
- Lighthouse
Lighthouse 能帮助用户简化工作流程，然后用户可以专心的完成主要的任务。用户可以免费试用此应用。这款应用非常易于使用，能很好的跟踪整个项目的开发，除此之外，它还包括：简单的导航、ticket 分组，活动流和在线文档，这些都能帮助用户更好的进行协作开发。
- FogBugz
FogBugz 是世界上最简单的 Bug 跟踪系统，提供 Wiki 项目管理、共享式计划表、问题追踪、电子邮件和讨论组等实用工具，可以让管理者方便的安排轻重缓急的任务顺序，以及在项目中随时调整成员的工作和监控进度。
处理流程
下面通过一个比较完整的bug的处理流程图，更深刻的理解bug的状态以一个bug的生命周期。
提交（打开）缺陷：在提交一个缺陷的缺陷，首先尽量描述这个缺陷的属性。Bug重现环境，bug类型，bug等级，bug的优先级以及详细的重现步骤，结果与期望等。
分配（转交）缺陷：这一步不是必须的，跟项目模式有关，有些公司测试部门与开发部门独立，那么测试人员就不确定自己测试的模块是由哪位开发人员负责的，在这种情况下，测试人员统一把问题指派给项目组长或经理，由项目组长（或经理）对问题进行确认后再次分配给相应的开发人员；有些测试人员是穿插到不同研发团队中的，所以对不同的开人发员负责的开发模块非常清楚，这个时候就可以将问题直接指派给相应的开发人员；也有一种情况，本来此问题应该由A开发人员负责，但由于A开发人员的调离或辞职，些问题为转交给其它人员处理。“分配”强调是上级对下级；“转交”强调的是平级之间。
确认缺陷：当开发人员接到一个缺陷时，首先是对其进行分析与重现，如果对其进行分析发现不是缺陷或无法对此问题进行重现，那么就需要将此问题反回给测试人员，并注明原因。如果确认为缺陷则需要对其进行处理。
推迟处理：在处理问题之后，还需要进行一次判断，是否需要推迟处理，有些需求已经确认了是问题，由于其可能在极端情况下才会出现，或需要对系统架构进行改动，或其优先级非常低，所以暂时不需要对此问题进行处理。
固定：对于推迟处理的问题可以暂时进行固定（“固定”为QC中的叫法。）一般固定的问题需要经过项目经理与测试经理协商后才能固定。
处理缺陷：开发人员在确认完一个问题需要处理时，那么就对其进行处理工作。（例如，redmine 是支持处理人时时更新问题处理进度的，如 已处理30% ，已处理80% 等，当然，对于短时间内可以修复的问题就没必要时时的去更新处理进度。）
回归缺陷：回归缺陷对于测试人员来说是非常重要的工作，其有三个入口两个出口。1）确认非缺陷问题：对于提交的一个缺陷，开人员处理为非问题或无法重现，然后直接转交给测试人员回归。测试人员再次确认，如果真如开发人员所说，则将问题关闭。如果非开发人员所说，是由于问题描述模糊或其它原因喂重现问题，则再次注明原因转给开发人员。2）确认修复问题：对开发人员修复的问题再次进行确认，确认能过，则关闭问题。确认不通过，将问题再次打开并转给开发人员。3）确认固定问题：有计划的对固定问题进行确认，有些固定问题随着时间的推移，版本的更新或已经不存在了，对这类问题应该及时关闭。有些固定问题依然存在且变得紧急，对于这类问题应该及时打开交给开发人员处理。
关闭缺陷：对于已经修复的缺陷进行关闭，这也是一个缺陷的最后一个状态。
閱讀更多 咱小二 的文章
