追蹤 Bug

當您執行測試以驗證需求時，一定會發現 Bug。 請使用 Bug 工作項目來描述及追蹤您找到的每個 Bug 進度。

如需如何建立 Bug 工作項目的詳細資訊，請參閱使用 Team Web Access 執行手動測試。 找到 Bug 時，請遵循本主題中的程序設定它們的優先權、確定已修正它們，並且確定您記錄了該工作和相關的決策。

將 Bug 分級

在專案的開發工作和測試已開始之後，應該於設定的時間間隔舉行分級會議。 舉行會議的頻率以及會議時間的長度，應該取決於您的狀況。

通常 Bug 分級會議是由專案經理主持，並由小組組長、商務分析師以及能夠針對特定專案風險發言的專案關係人參與。 專案經理可以針對新的 Bug 以及重新開啟的 Bug 使用 [待處理的 Bug] 查詢，產生要分級的 Bug 清單。

在分級開始之前，請先設定一組準則，以便判斷哪些 Bug 應該修正，且優先權為何。 這套準則應該能夠辨認出 Bug 的嚴重性，以及與重要價值 (或重要延遲機會成本) 的功能或其他專案風險相關聯的 Bug。

分級準則應該儲存在您 Team 專案的 [文件] 資料夾。 隨著時間過去，將會更新文件。 我們假設您的專案已開啟版本控制，且專案上任何時刻使用中的特定準則都可以進行擷取，以便進行稽核和評價證明。

在專案的早期，您可能會決定修正大多數分級的 Bug。 然而隨著專案的進行，可能會提高分級準則 (或門檻)，以減少修正的 bug 數目。

提高分級準則門檻，以及允許報告的 Bug 維持未修正，是一種取捨。 之所以要取捨，是因為修正 Bug 比較達到專案範圍、預算和排程而言較不重要。

請使用您的準則來判斷哪些 Bug 應該修正，以及如何設定它們的 [狀態]、[優先權]、[嚴重性] 及其他欄位。 根據預設，範本提供了四種優先權：1 代表「必須修正」，而 4 代表「不重要」。如果您在流程範本中變更定義，則應該要跟著更新指引、說明文字以及任何準則文件。

修正 Bugs

Bug 通過分級並已設定優先權之後，它應該要被指派給開發人員以進行額外的調查。

Bug 工作項目有 repro 步驟的索引標籤，這應該可提供您重現 Bug 所需的東西。 不過您也可以使用 IntelliTrace 來幫助您重現困難的 Bug。 如需 IntelliTrace 的詳細資訊，請參閱追蹤軟體品質。

開發人員決定好一系列的動作之後，他們應該在 Bug 工作項目中記下他們的決定。

關於修正的決定

與其他小組成員合作時，開發人員建議的修正可能會對程式碼的其他區段造成隱含的影響，且可能需要大量的迴歸測試。 任何與評量此類修正之風險相關的討論，都應該記錄在 Bug 工作項目記錄中，因為它為稽核或 Standard CMMI Appraisal Method for Process Improvement (SCAMPI) 評價記錄了有用的決策分析和風險管理證據。 如需 CMMI 的詳細資訊，請參閱 CMMI 的背景。

更新並執行單元測試以修正 Bug

單元測試會驗證程式碼單元的正確實作。 撰寫和執行單元測試能夠在測試開始之前識別 Bug，也因此能幫助降低品質控制的成本。 在實作開發工作或是實作 Bug 修正時，開發人員必須撰寫所有程式碼的單元測試。 如需詳細資訊，請參閱使用單元測試驗證程式碼。

在測試優先的開發策略中，您可能會偏好在進行任何程式碼修正之前先撰寫單元測試。 敏捷的軟體開發人員會偏好這種類型的策略。 CMMI 並不要求以特定的順序撰寫單元測試，只要求要達到有效的功能驗證。

CMMI 評價需要有不僅撰寫並且已執行單元測試的證據。 請務必將測試連結到程式碼修正工作的工作項目，並將那些工作連結到 Bug 工作項目。 這提供了 SCAMPI 主要評估者將會查看的證據可追蹤性。

檢閱及重構程式碼以修正 Bug

程式碼檢閱是用來確定新的或已變更的程式碼達到既定的品質門檻，然後才將程式碼整合到每日的組建。 品質考慮事項包括程式碼標準、架構與設計一致性、效能、可讀性以及安全性。 程式碼檢閱也提供從其他開發人員對於程式碼應該如何撰寫的其他深入觀點。 如需如何檢閱及重構程式碼的詳細資訊，請參閱實作開發工作。

關閉 Bugs

當 Bug 獲得修正後，您應該將它指派給測試人員以驗證問題已解決，然後才能關閉 Bug 工作項目。

驗證修正

為了驗證修正，測試人員應該試圖重現 Bug、尋找其他意外的行為，並且在必要時重新啟動 Bug。

在驗證 Bug 解決方案時，您可能會發現 Bug 並未完全修正，或是您可能不同意這個解決方案。 在此情況下，您要與解決 Bug 的人討論、達成協議，並且可能要重新啟動 Bug。 若您真的重新啟動 Bug，請確定您在 Bug 描述中包含了重新啟動 Bug 的原因，以便保留資訊。

關閉 Bug 工作項目

Bug 的關閉原因有許多。 在簡單的情況中，Bug 已經過驗證為已修正，因此也就可以關閉。 不過，Bug 可以延期到產品的下個版本、證明無法重現，或是確認是重複的 Bug。 這些原因每一項都必須記錄，且 Bug 必須正確地關閉，以確保其關閉原因沒有任何的混淆。