在 Azure Boards 中定義、擷取、分級和管理軟體 Bug

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

如何追蹤和管理程序代碼中的瑕疵？ 如何確定軟體問題和客戶意見反應能快速解決，以支援高質量的軟體部署？ 如何取得新功能的良好進展，並解決您的技術債務？

您至少需要一種方式來擷取軟體問題、排定優先順序、將它們指派給小組成員，以及追蹤進度。 您想要以符合敏捷式做法的方式管理程式碼瑕疵。

為了支持這些案例，Azure Boards 提供特定的工作專案類型來追蹤名為 Bug 的程式代碼缺失。 Bug 工作專案會與其他工作項目類型的所有標準功能共用一些。 如需標準功能的概觀，請參閱 關於工作專案和工作項目類型。

Bug 也提供下列功能：

• 每個小組選擇如何追蹤 Bug 的選項
• 用來擷取 Bug 的測試工具
• 跨 Azure DevOps 的內建整合，以追蹤連結至組建、發行和測試的 Bug

注意

基本程式無法使用 Bug 工作項目類型。 基本程式會追蹤 Bug 作為問題，而且當您從 Azure DevOps Services 或 Azure DevOps Server 2019.1 或更新版本建立新專案時可以使用。

必要條件

• 專案存取： 新增 至專案。

• 權限：

  • 將 [檢視此節點 的工作專案] 和 [編輯此節點 中的工作專案] 權限設定為 [ 允許]。 根據預設， 參與者 群組具有這些許可權。 如需詳細資訊，請參閱 設定工作追蹤許可權。

  • 若要將新的標籤新增至工作專案，請具有 基本 存取權或更高許可權，以及專案層級 的 [建立新的標籤定義 ] 權限設定為 [允許]。 根據預設， 參與者 群組具有此許可權。

    注意

    項目關係人 無法新增標籤，即使許可權已明確設定，因為其存取層級。 如需詳細資訊，請參閱專案關係人存取快速參考。

• 電子郵件工作專案：所有項目成員，包括讀者群組中的項目成員，都可以傳送包含工作專案的電子郵件。

提示

若要回報 Bug，使用者至少 必須具有項目關係人 存取權。 用戶必須將此 節點 許可權中的 [編輯工作專案] 設定為 [允許 ]， 才能新增 Bug 的區域路徑 。 如需詳細資訊，請參閱 設定工作追蹤許可權

Bug 工作項目類型

下圖顯示 Scrum 程式的 Bug 工作項目類型。 Agile 和 Capability Maturity Model Integration （CMMI） 程式的 Bug 工作專案類型會追蹤類似的資訊。 它會出現在產品待辦專案上，以及需求或工作面板上以及工作。

注意

您從入口網站看到的影像可能會與您在本文中看到的影像不同。 這些差異源於對 Web 應用程式的更新、您或系統管理員啟用的選項，以及建立專案時選擇的程式：Agile、Basic、Scrum 或 CMMI。 基本程序適用於 Azure DevOps Server 2019 Update 1 和更新版本。

Bug 特有的欄位

Bug 工作項目類型會使用一些 Bug 特定欄位。 若要擷取初始問題和進行中的探索，請使用下表所述的欄位。 如需功能成熟度模型整合 （CMMI） 程式所定義 Bug 專屬欄位的相關信息，請參閱 Bug、問題和風險字段參考。 如需所有其他欄位的相關信息，請參閱 工作專案欄位索引。

---

欄位、群組或索引標籤

使用方式

---

重現 的步驟 （易記名稱=重現步驟）

使用 來擷取足夠的資訊，讓其他小組成員完全瞭解程式代碼缺失。 包含尋找或重現 Bug 和預期行為的動作。

---

在組建中找到的系統資訊

與要套用之 Bug 和測試相關的軟體和系統組態相關信息。 當您透過測試工具建立 Bug 時，會自動填入 [建置中的系統資訊] 和 [找到]。 這些欄位會指定軟體環境的相關信息，並建置發生 Bug 的位置。 如需詳細資訊，請參閱 測試不同的組態。

---

接受準則

提供準則以符合，然後才能關閉 Bug。 開始工作之前，請盡可能清楚地描述客戶驗收準則。 Teams 應使用此準則作為驗收測試的基礎，並評估專案是否順利完成。

---

整合在組建中

指定組建的名稱，其中包含修正 Bug 的程式代碼。 當您解決 Bug 時，應該指定此欄位。

針對內部部署 Azure DevOps，若要存取已執行之所有組建的下拉功能表，您可以更新 FIELD [在組建中找到] 和 [整合式組建] 的定義，以參考全域清單。 全域清單會隨著每個執行的組建自動更新。 如需詳細資訊，請參閱 根據組建和測試整合欄位進行查詢。

如需如何定義組建編號的資訊，請參閱 傳統管線設定。

---

^{優先順序 1}

• 1：產品需要成功解決工作專案，才能儘快出貨並加以解決。
• 2：產品在出貨前需要成功解決工作專案，但不需要立即解決。
• 3：根據資源、時間和風險，解決工作專案是選擇性的。

---

嚴重性¹

專案或軟體系統上 Bug 或工作專案影響的主觀評等。 例如：如果使用者介面內的遠端連結（罕見事件）導致應用程式或網頁當機（嚴重的客戶體驗），您可以指定 嚴重性 = 2 - 高 優先順序 = 3。 允許的值和建議的指導方針如下：

• 1 - 重大：必須修正。 導致終止一或多個系統元件或完整系統的瑕疵品，或造成廣泛的數據損毀。 沒有可接受的替代方法可達成所需的結果。
• 2 - 高：請考慮修正。 導致終止一或多個系統元件或完整系統的瑕疵品，或造成廣泛的數據損毀。 可接受的替代方法存在，以達到所需的結果。
• 3 - 中:(預設） 導致系統產生不正確、不完整或不一致結果的瑕疵。
• 4 - 低：有可接受的因應措施可達到所需結果的次要或整容瑕疵。

---

[部署]

部署控制項支援包含工作專案之版本的連結和顯示。 若要使用 控制項，您必須啟用版本的設定。 如需詳細資訊，請參閱 本文稍後將工作項目連結至版本 。

---

開發

開發控制項支援對開發物件所建立連結的連結和顯示。 這些物件包括 Git 認可和提取要求，或 TFVC 變更集和已建立版本的專案。 您可以從工作項目或認可、提取要求或其他開發物件定義連結。 如需詳細資訊，請參閱 本文稍後將工作專案連結至開發 。

---

備註

¹ 若要變更功能表選取專案或選擇清單，請參閱 自定義工作追蹤體驗。 自定義方法取決於您專案所使用的進程模型。

選擇小組追蹤 Bug 的方式

您的小組可以將 Bug 追蹤為需求或工作。 若要支援小組選擇，請考慮下列因素。

• 小組的大小。 較小的小組可以視需要追蹤 Bug 來維護輕量型使用量。
• 追蹤工作的組織需求。 如果您的小組需要追蹤時數，請選擇追蹤 Bug 作為工作。
• 組織小組的工作。 如果您的小組依賴產品待辦專案來排定工作優先順序並新增 Bug，請視需求追蹤 Bug。
• 您的小組想要使用的工具，例如 [規劃] 窗格、速度圖表、預測、匯總和傳遞計劃。 追蹤錯誤，因為工作會防止使用其中數個工具。

下表摘要說明小組必須追蹤 Bug 的三個選項。 若要深入瞭解並設定小組的選項，請參閱 在待辦專案和面板上顯示 Bug。

---

選項

選擇您要...

---

將 Bug 追蹤為需求

• 排定優先順序或堆棧排名，以及需求
• 預估預測的 Bug 工作
• 更新面板上的 Bug 狀態
• 在速度圖和累積流程圖中包含 Bug
• 能夠使用 預測工具來 支援短期衝刺規劃
• 將 Bug 拖曳至 [ 規劃 ] 窗格，將 Bug 指派給短期衝刺
• 檢視傳遞計畫的 Bug

注意

• 錯誤會指派給需求類別

---

將 Bug 追蹤為工作

• 估計類似工作的 Bug 工作
• 更新短期衝刺任務板上的 Bug 狀態
• 將 Bug 連結至需求作為子專案
• 將 Bug 拖曳至 [規劃] 窗格，將 Bug 指派給短期衝刺

注意

• 錯誤會指派給工作類別目錄
• 使用者案例 （Agile）、產品待辦專案 （Scrum） 或需求 （CMMI） 是 Bug 的自然父工作項目類型
• 傳遞計劃上看不到 Bug

---

Bug 不會出現在待辦專案或面板上

• 使用查詢管理 Bug

注意

• Bug 與 Bug 類別相關聯，而且不會出現在待處理專案或面板上
• 待辦專案、面板、短期衝刺待辦專案、任務板或傳遞計劃上看不到 Bug
• 您無法將 Bug 拖曳至 [規劃] 窗格，將 Bug 指派給短期衝刺

---

自訂工作項目類型

您可以自訂 Bug 和其他工作項目類型。 或者，建立自定義類型來追蹤軟體問題或客戶意見反應。 針對所有工作項目類型，您可以自定義下列元素：

• 新增或移除自定義欄位
• 在工作專案窗體內新增自定義控件或自定義索引標籤
• 自訂工作流程狀態
• 新增條件式規則
• 選擇工作項目出現的待辦專案層級

在自定義程式之前，建議您先檢閱 關於設定和自定義 Azure Boards。

若要自定義您的特定進程，請參閱 自定義繼承程式。

新增或擷取錯誤

您可以從數個不同的 Azure DevOps 工具定義 Bug。 這些工具包括待辦專案和面板和測試工具。

提示

根據預設，當您 建立 Bug 時，[標題 ] 欄位是唯一必要的欄位。 您可以使用 Azure Boards，以新增使用者劇本或產品待辦專案的方式新增 Bug。 您可以根據狀態變更來新增條件式規則，以建立一些必要欄位。 如需詳細資訊，請參閱 將規則新增至工作項目類型。

從待辦專案或面板新增 Bug

如果您的小組選擇 以需求管理 Bug，您可以從產品待辦專案或面板定義 Bug。 如需詳細資訊，請參閱 建立產品待辦專案 或使用 面板。

• 從產品待辦專案新增 Bug

  

• 從面板新增 Bug

  

提示

當您從產品待辦專案或面板新增 Bug 時，錯誤會自動指派為小組定義的預設區域路徑和反覆項目路徑。 如需詳細資訊，請參閱 待辦專案和面板所參考的小組預設值。

從短期衝刺待辦專案或工作面板新增 Bug

如果您的小組選擇使用 工作來管理 Bug，您可以從面板、產品待辦專案、短期衝刺待辦專案或短期衝刺工作面板定義 Bug。 您會將 Bug 新增為子專案至產品待辦專案。

• 從短期衝刺待辦專案新增連結的子 Bug

  您新增 Bug 的方式與將工作新增至短期衝刺待辦專案的方式相同。 如需詳細資訊，請參閱 將工作新增至待辦專案。

  

• 從面板新增連結的子 Bug

  您新增 Bug 的方式與將工作新增至待辦專案的方式相同。 如需詳細資訊，請參閱 將工作或子專案新增為檢查清單。

  

從測試工具建立 Bug

您可以在測試時用來新增 Bug 的兩個測試工具包括入口網站測試執行器和測試與意見反應擴充功能。

• 測試執行器：執行手動測試時，您可以選擇建立 Bug。 如需詳細資訊，請參閱 執行手動測試。

  

• 測試與意見反應延伸模組：執行探勘測試時，您可以選擇 [建立 Bug] 或 [建立工作]。 如需詳細資訊，請參閱 使用 Test 和 Feedback 擴充功能進行 Exploratory 測試。

  

Bug 生命週期和工作流程狀態

如同所有其他工作項目類型，Bug 工作專案類型具有妥善定義的工作流程。 每個工作流程都包含三個以上的狀態和原因。 原因會指定專案從某個狀態轉換到另一個狀態的原因。 下列影像說明針對 Agile、 Scrum 和 CMMI 程式定義的預設 Bug 工作流程。

敏捷式	Scrum	CMMI

針對 Scrum Bug，您會將 [狀態] 從 [認可] 變更為 [完成]。 針對 Agile 和 CMMI，您必須先解決 Bug，然後選取指出 Bug 已修正的原因。 一般而言，建立 Bug 的人員接著會驗證修正，並將狀態從 [已解決] 更新為 [已關閉]。 如果您在解決或關閉 Bug 之後發現更多工作，請將 [狀態] 設定為 [認可] 或 [作用中] 來重新啟用它。

注意

敏捷式程式 Bug 工作專案類型先前有一個規則，會將 Bug 重新指派給建立 Bug 的人員。 此規則已從預設系統進程中移除。 您可以藉由新增規則來恢復此自動化。 如需繼承程式，請參閱 根據狀態變更自動重新指派。

確認修正程式

若要驗證修正，開發人員或測試人員會嘗試重現 Bug，並尋找更非預期的行為。 如有必要，它們應該重新啟用 Bug。

驗證錯誤修正時，您可能會發現 Bug 未修正，或您可能會不同意解決方案。 在此情況下，請與已解決問題的人員討論 Bug、達成協定，並可能重新啟用 Bug。 如果您重新啟用 Bug，請在 Bug 描述中包含重新啟用 Bug 的原因。

關閉 Bug

當小組成員確認其為已修正時，您就會關閉 Bug。 不過，您可能也會因為下列其中一個原因而關閉 Bug。 可用的原因取決於專案程式和 Bug 轉換狀態。

敏捷式程式：

• 延遲：延遲錯誤修正，直到下一個產品版本為止。
• 已修正：錯誤已驗證為已修正。
• 重複：Bug 會追蹤目前定義的另一個 Bug。 您可以使用連結類型的重複/重複連結連結每個 Bug，並關閉其中一個 Bug。
• 設計方式：功能會如設計般運作。
• 無法重現：測試證明無法重現 Bug。
• 已過時：Bug 的功能已不在產品中。
• 複製到待辦專案：已開啟用戶劇本來追蹤 Bug。

Scrum 程式：

• 不是 Bug：Bug 已確認它不是 Bug。
• 重複：Bug 會追蹤目前定義的另一個 Bug。 您可以使用連結類型的重複/重複連結連結每個 Bug，並關閉其中一個 Bug。
• 已從待辦專案中移除：錯誤已確認它不是 Bug。 從待辦專案中移除 Bug。
• 工作已完成：Bug 已驗證為已修正。

CMMI 程式：

• 延遲：延遲錯誤修正，直到下一個產品版本為止。
• 重複：Bug 會追蹤目前定義的另一個 Bug。 您可以使用連結類型的重複/重複連結連結每個 Bug，並關閉其中一個 Bug。
• 已拒絕：錯誤已確認它不是 Bug。
• 已驗證：錯誤已驗證為已修正。

提示

在錯誤關閉且修正已在部署中主動發行之後，建議的做法是不要因為回歸而重新開啟。 相反地，您應該考慮開啟新的 Bug，並連結至較舊的已關閉 Bug。

最好描述在討論欄位中關閉 Bug 的任何更多詳細數據，以避免未來對錯誤關閉的原因造成混淆。

合併提取要求時自動關閉錯誤

如果您的小組使用 Git 存放庫，您可以設定連結 Bug 中的狀態和其他工作專案，以在成功合併提取要求時關閉。 如需詳細資訊，請參閱 本文稍後在提取要求 中設定工作項目狀態。

列出和分級 Bug

大部分小組，無論他們選擇追蹤 Bug 的選項為何，都會定義一或多個 Bug 查詢。 透過查詢，您可以列出作用中的 Bug、未指派的 Bug、過時的 Bug、Bug 趨勢等等。 您可以將查詢和查詢圖表新增至小組儀錶板，以監視 Bug 狀態和進度。

Bug 查詢

開啟共享查詢或使用 查詢編輯器 來建立有用的 Bug 查詢，例如下列選項：

• 依優先權的作用中錯誤 （State <> Done 或 State <> Closed）
• 進行中的 Bug （State = Committed 或 State = Active）
• 修正目標版本的 Bug （Tags Contains RTM）
• 最近的 Bug，例如過去三周開啟的 Bug （Created Date > @Today-21）

當您有小組感興趣的查詢時，您可以 建立狀態或趨勢圖表。 您也可以將您建立的 圖表新增至儀錶板。

查詢結果中的分級模式

開始撰寫和測試之後，請舉行定期分級會議，以檢閱和排名您的 Bug。 一般而言，項目擁有者會執行 Bug 分級會議。 小組負責人、商務分析師和其他項目關係人，他們可以討論特定項目風險，並出席分級會議。

項目擁有者可以定義新的和重新開啟 Bug 的共享查詢，以列出要分級的 Bug。

從查詢結果頁面，您可以使用向上和向下箭號，在 Bug 工作項目清單中上下移動。 當您檢閱每個 Bug 時，您可以指派它、新增詳細資料或設定優先順序。

組織和指派 Bug 給短期衝刺

如果您的小組 追蹤 Bug 作為需求，請檢視待辦專案的作用中 Bug 清單。 使用篩選函式，您可以只專注於 Bug。 您也可以從產品待辦項目執行下列工作：

• 組織待辦專案上的 Bug。 堆疊排名與其他專案。 啟用篩選時，會停用堆棧排名。
• 使用 [規劃] 窗格，將 Bug 指派給待辦專案中的短期衝刺。
• 使用 [對應] 窗格，將父代 Bug 對應至功能或其他組合待辦專案。
• 檢視組合待辦專案的工作匯總。

如果您的小組 追蹤 Bug 作為工作，請使用受控查詢來列出和分級 Bug。 在每個短期衝刺中，您會看到從短期衝刺待辦專案或 Taskboard指派給短期衝刺的錯誤。

任務板項目與查詢清單專案

您可能會注意到並想知道短期衝刺任務板上顯示的項目為何與對應短期衝刺待辦專案中建立的查詢清單不同。

可以將工作或 Bug 指派給反覆專案，但無法將它們連結至父待辦專案。 這些專案會出現在已建立的查詢中，但可能不會顯示在Taskboard本身。 系統會執行查詢，然後在顯示Taskboard專案之前套用幾個背景進程。

這些原因可能會導致屬於工作類別的工作專案不會出現在短期衝刺待辦專案或Taskboard上：

• 工作或 Bug 未連結至父待辦專案。 只有 Bug 和工作會連結至父產品待辦專案 （Scrum）、使用者劇本 （Agile） 或需求 （CMMI），並將反覆運算路徑設定為短期衝刺出現在短期衝刺待辦專案頁面上。
• 工作或 Bug 是另一個工作或 Bug 的父代，或者用戶劇本是另一個使用者劇本的父代。 如果您建立工作、Bug 或使用者劇本的階層，則只會顯示階層底部的子層級工作或子層級的故事。 如需詳細資訊，請參閱 針對重新排序和巢狀問題進行疑難解答。
• 工作或 Bug 的連結父代會對應至為另一個小組定義的待辦專案。 或者，工作或 Bug 父待辦專案的區域路徑與工作的 或 Bug 區域路徑不同。

建立連結至 Bug 的內嵌測試

當小組 追蹤 Bug 作為需求時，您可以使用面板來新增測試來驗證錯誤修正。

更新錯誤狀態

您可以將 Bug 拖放到面板上的新資料行，以更新 Bug 狀態。

• 如果您的小組 追蹤 Bug 作為需求，您可以使用面板，如下圖所示。 如需詳細資訊，請參閱 更新工作項目狀態。

  

• 如果您的小組 追蹤 Bug 做為工作，您可以使用 Taskboard。 如需詳細資訊，請參閱 更新和監視您的工作面板。

  

自訂您的面板以追蹤中繼狀態

您可以新增中繼資料行來追蹤面板上的 Bug 狀態。 您也可以定義根據面板資料行狀態篩選的查詢。 如需詳細資訊，請參閱下列文章：

• 將資料行新增至面板
• 自定義短期衝刺任務板
• 查詢面板的變更

根據工作流程狀態自動重新指派錯誤

若要自動選取動作，請將自定義規則新增至 Bug 工作項目類型。 例如，新增規則，如下圖所示。 此規則指定將 Bug 重新指派給小組成員解決 Bug 的人員。 一般而言，該人員會確認 Bug 已修正並關閉 Bug。 如需詳細資訊，請參閱將規則套用至工作流程狀態（繼承程式）。

在提取要求中設定工作項目狀態

當您建立提取要求時，您可以在描述中設定 連結工作項目的狀態 值。 遵循語法： {state value}: #ID。

當您合併提取要求時，系統會讀取描述並更新工作項目狀態。 下列範例會將工作專案 #300 和 #301 設定為 Resolved，並將 #323 和 #324 設定為 Closed。

跨 Azure DevOps 整合

Azure DevOps 用來支援整合的其中一種方法是將對象連結至其他物件。 除了將工作項目連結至工作專案之外，您也可以將工作項目連結至其他物件。 連結至建置、發行、分支、認可和提取要求等物件，如下圖所示。

您可以從工作項目或組建和發行物件新增連結。

將工作專案連結至開發

開發控件支持連結和顯示建置、Git 認可和提取要求的連結。 使用 TFVC 存放庫時，它支援變更集和版本設定項目的連結。 選擇連結會在新的瀏覽器索引標籤中開啟對應的專案。如需詳細資訊，請參閱 從工作專案驅動 Git 開發。

將工作專案連結至發行

部署控制項支援包含工作專案之版本的連結和顯示。 例如，下圖顯示包含目前工作專案連結的數個版本。 您可以展開每個版本，以查看每個階段的詳細數據。 您可以選擇每個版本和階段的連結，以開啟對應的發行或階段。 如需詳細資訊，請參閱 將工作項目連結至部署。

將工作項目連結至管線執行

管線通常會定義為在 Git 存放庫發生新認可時自動執行。 如果您自定義管線設定，則與認可管線相關聯的工作專案會顯示為管線執行的一部分。 如需詳細資訊，請參閱 自定義管線。

在建置失敗時建立或編輯工作專案

如果您使用傳統管線（而非 YAML），您可以在建置失敗時建立工作專案。 如需詳細資訊，請參閱 在失敗時建立工作專案。

監視錯誤狀態、指派和趨勢

您可以使用可繪製圖表並新增至儀錶板的查詢來追蹤 Bug 狀態、指派和趨勢。 例如，以下是兩個範例，依狀態顯示作用中的 Bug 趨勢，以及依一段時間的優先順序顯示作用中的 Bug 趨勢。

如需查詢、圖表和儀錶板的詳細資訊，請參閱 受控查詢、 圖表和 儀錶板。

使用分析檢視和分析服務來建立 Bug 報告

Analytics 服務是 Azure DevOps 的報告平臺。 它會根據 SQL Server Reporting Services 取代先前的平臺。

分析檢視提供預先建置的篩選來檢視工作專案。 Bug 報告支援四種分析檢視。 您可以依照定義使用這些檢視，或進一步編輯這些檢視來建立自定義的篩選檢視。

• Bug - 依月份的所有歷程記錄
• Bug - 過去 26 周
• Bug - 過去 30 天
• Bug - 今日

如需使用分析檢視的詳細資訊，請參閱關於分析檢視和根據自定義分析檢視在 Power BI 中建立作用中的 Bug 報表。

您可以使用 Power BI 建立比查詢更複雜的報表。 如需詳細資訊，請參閱 使用Power BI資料連接器連線。

Marketplace 擴充功能

有多個 Bug 相關的 Marketplace 擴充功能。 請參閱 Azure DevOps 的 Marketplace。

如需延伸模組的詳細資訊，請參閱 Microsoft 所開發的 Azure Boards 擴充功能。

下一步

使用範本來新增和更新工作專案

相關文章

• 拿掉、刪除或還原工作專案
• 複製或複製工作專案

產品待辦專案和面板

• 使用待辦專案來管理專案
• 建立待辦專案
• 定義功能和 Epic
• 組織待辦專案，並將子工作項目對應至父系
• 以互動方式篩選待辦專案、面板、查詢和計劃
• 預測您的產品待辦專案

委員會

• 關於 Boards 和 Kanban
• 使用您的面板
• 重新排列卡片
• 將工作或子專案新增為檢查清單

短期衝刺待辦專案和任務板

• 瞭解 Scrum 最佳做法
• 將待辦專案指派給短期衝刺
• 新增工作
• 更新您的工作面板

Azure DevOps 內的整合

• 鏈接使用者劇本、問題、Bug 和其他工作專案
• 遵循工作專案或提取要求
• 設定執行或組建編號

產業資源

• 亨里克·克尼伯格（以及TDD如何説明）的好壞技術債務（以及TDD如何説明）
• 管理 Sven Johann 和 Eberhard Wolff 發佈的技術債務