軟體工程/工具/Bug跟蹤系統簡介

Bug跟蹤系統是一種軟體應用程式，旨在幫助質量保證人員和程式設計師跟蹤其工作中報告的軟體錯誤。它可以被視為一種問題跟蹤系統。

許多Bug跟蹤系統，例如大多數開源軟體專案使用的系統，允許使用者直接輸入Bug報告。其他系統僅在進行軟體開發的公司或組織內部使用。通常，Bug跟蹤系統與其他軟體專案管理應用程式整合。

擁有Bug跟蹤系統在軟體開發中非常寶貴，並且被開發軟體產品的公司廣泛使用。一致地使用Bug或問題跟蹤系統被認為是“優秀軟體團隊的標誌”之一。

元件

Bug跟蹤系統的主要元件是記錄已知錯誤資訊的資料庫。資訊可能包括錯誤報告的時間、嚴重程度、錯誤的程式行為以及如何重現錯誤的詳細資訊；以及報告錯誤的人員的身份和任何可能正在解決錯誤的程式設計師。

典型的Bug跟蹤系統支援Bug生命週期的概念，該生命週期透過分配給Bug的狀態進行跟蹤。Bug跟蹤系統應允許管理員根據狀態配置許可權，將Bug移動到其他狀態或刪除Bug。該系統還應允許管理員配置Bug狀態以及將處於特定狀態的Bug可以移動到的狀態。當新增新記錄或狀態發生更改時，某些系統會向相關人員（例如提交者和分配的程式設計師）傳送電子郵件。

用途

Bug跟蹤系統的主要優勢是提供對開發請求（包括錯誤和改進，邊界通常很模糊）及其狀態的清晰、集中概述。待辦事項的優先順序列表（通常稱為積壓工作）在定義產品路線圖或可能只是“下一個版本”時提供寶貴的輸入。

在企業環境中，Bug跟蹤系統可用於生成程式設計師修復錯誤效率的報告。但是，這有時會產生不準確的結果，因為不同的錯誤可能具有不同的嚴重程度和複雜程度。錯誤的嚴重程度可能與修復錯誤的複雜程度沒有直接關係。管理人員和架構師之間可能存在不同的意見。

本地Bug跟蹤器 (LBT) 通常是一個計算機程式，由應用程式支援專業人員（通常是幫助臺）團隊使用，以跟蹤與軟體開發人員溝通的問題。使用 LBT 允許支援專業人員以“自己的語言”跟蹤錯誤，而不是“開發人員的語言”。此外，LBT 允許支援專業人員團隊跟蹤有關打電話投訴使用者的特定資訊 - 這些資訊可能並不總是需要在實際的開發佇列中。因此，當 LBT 存在時，存在兩個跟蹤系統。

Bug跟蹤系統作為整合專案管理系統的一部分

Bug和問題跟蹤系統通常作為整合專案管理系統的一部分實施。這種方法允許將Bug跟蹤和修復納入一般的產品開發流程，修復多個產品版本中的Bug，自動生成產品知識庫和發行說明。

分散式Bug跟蹤

某些Bug跟蹤器旨在與分散式版本控制軟體一起使用。這些分散式Bug跟蹤器允許開發人員在離線時方便地讀取、新增到資料庫或更新Bug報告。 分散式Bug跟蹤器包括 Bugs Everywhere 和 Fossil。

最近，商業Bug跟蹤系統也開始與分散式版本控制整合。例如，FogBugz 透過原始碼控制工具 Kiln 實現了此功能。

雖然維基和Bug跟蹤系統通常被視為不同型別的軟體，但 ikiwiki 也可以用作分散式Bug跟蹤器。它還可以以整合的分散式方式管理文件和程式碼。但是，它的查詢功能不如其他一些非分散式Bug跟蹤器（如 Bugzilla）先進或使用者友好。 關於 org-mode 可以做出類似的陳述，儘管它本身不是維基軟體。

Bug跟蹤和測試管理

雖然傳統的測試管理工具（如 HP Quality Center 和 Rational Software）自帶 Bug 跟蹤系統，但其他工具與流行的 Bug 跟蹤系統整合。

外部連結

• 錯誤跟蹤軟體 在 Curlie
• 如何有效地報告錯誤
• 分散式錯誤跟蹤軟體列表