软件工程/工具/Bug跟踪系统简介
Bug跟踪系统是一种软件应用程序，旨在帮助质量保证人员和程序员跟踪其工作中报告的软件错误。它可以被视为一种问题跟踪系统。
许多Bug跟踪系统，例如大多数开源软件项目使用的系统，允许用户直接输入Bug报告。其他系统仅在进行软件开发的公司或组织内部使用。通常，Bug跟踪系统与其他软件项目管理应用程序集成。
拥有Bug跟踪系统在软件开发中非常宝贵，并且被开发软件产品的公司广泛使用。一致地使用Bug或问题跟踪系统被认为是“优秀软件团队的标志”之一。[1]
Bug跟踪系统的主要组件是记录已知错误信息的数据库。信息可能包括错误报告的时间、严重程度、错误的程序行为以及如何重现错误的详细信息；以及报告错误的人员的身份和任何可能正在解决错误的程序员。[2]
典型的Bug跟踪系统支持Bug生命周期的概念，该生命周期通过分配给Bug的状态进行跟踪。Bug跟踪系统应允许管理员根据状态配置权限，将Bug移动到其他状态或删除Bug。该系统还应允许管理员配置Bug状态以及将处于特定状态的Bug可以移动到的状态。当添加新记录或状态发生更改时，某些系统会向相关人员（例如提交者和分配的程序员）发送电子邮件。
Bug跟踪系统的主要优势是提供对开发请求（包括错误和改进，边界通常很模糊）及其状态的清晰、集中概述。待办事项的优先级列表（通常称为积压工作）在定义产品路线图或可能只是“下一个版本”时提供宝贵的输入。
在企业环境中，Bug跟踪系统可用于生成程序员修复错误效率的报告。但是，这有时会产生不准确的结果，因为不同的错误可能具有不同的严重程度和复杂程度。错误的严重程度可能与修复错误的复杂程度没有直接关系。管理人员和架构师之间可能存在不同的意见。
本地Bug跟踪器 (LBT) 通常是一个计算机程序，由应用程序支持专业人员（通常是帮助台）团队使用，以跟踪与软件开发人员沟通的问题。使用 LBT 允许支持专业人员以“自己的语言”跟踪错误，而不是“开发人员的语言”。此外，LBT 允许支持专业人员团队跟踪有关打电话投诉用户的特定信息 - 这些信息可能并不总是需要在实际的开发队列中。因此，当 LBT 存在时，存在两个跟踪系统。
Bug和问题跟踪系统通常作为集成项目管理系统的一部分实施。这种方法允许将Bug跟踪和修复纳入一般的产品开发流程，修复多个产品版本中的Bug，自动生成产品知识库和发行说明。
某些Bug跟踪器旨在与分布式版本控制软件一起使用。这些分布式Bug跟踪器允许开发人员在脱机时方便地读取、添加到数据库或更新Bug报告。[3] 分布式Bug跟踪器包括 Bugs Everywhere 和 Fossil。
最近，商业Bug跟踪系统也开始与分布式版本控制集成。例如，FogBugz 通过源代码控制工具 Kiln 实现了此功能。[4]
虽然维基和Bug跟踪系统通常被视为不同类型的软件，但 ikiwiki 也可以用作分布式Bug跟踪器。它还可以以集成的分布式方式管理文档和代码。但是，它的查询功能不如其他一些非分布式Bug跟踪器（如 Bugzilla）先进或用户友好。[5] 关于 org-mode 可以做出类似的陈述，尽管它本身不是维基软件。
虽然传统的测试管理工具（如 HP Quality Center 和 Rational Software）自带 Bug 跟踪系统，但其他工具与流行的 Bug 跟踪系统集成。[需要引用]
- ↑ Joel Spolsky (2000 年 11 月 8 日)。"轻松的 Bug 跟踪". 检索于 2010 年 10 月 29 日.
{{cite web}}: 检查日期值：|date=(帮助) - ↑ 多个（维基）。"Bug 报告". Docforge. 检索于 2010-03-09.
- ↑ Jonathan Corbet (2008年5月14日). "分布式错误跟踪". LWN.net. 检索于 2009年1月7日.
{{cite web}}: 请检查日期值的格式：|date=(帮助) - ↑ "FogBugz 功能". Fogbugz.com. 检索于 2010-10-29.
{{cite web}}: 引用中存在空的参数：|1=(帮助) - ↑ Joey Hess (2007年4月6日). "Ikiwiki 集成问题跟踪". LinuxWorld.com. IDG. 检索于 2009年1月7日.