Bug 趨勢報表

發行項
06/10/2015

您可以使用 [Bug 趨勢] 報表來協助追蹤小組找出並解決 Bug 的速率。這個報表會顯示某段時間內所回報、解決和關閉之 Bug 數的移動平均值。當您要管理龐大的小組或大量 Bug 時，您可以每週監視 [Bug 趨勢] 報表，以了解小組實際找出、解決和關閉 Bug 的情形。

如需如何存取、重新整理或管理報表的詳細資訊，請參閱報表 (SQL Server Reporting Services)。

注意事項
這份報表會要求您使用 SQL Server Reporting Services 來佈建包含 Team 專案的 Team 專案集合。當您開啟 Team Explorer並展開 Team 專案節點時，如果沒有顯示 [報表]，就無法使用這份報表。

本主題內容

報表中的資料
設定反覆項目的持續期間
解譯報表
篩選報表

您可以使用這份報表來回答下列問題：

小組每天報告、解決和關閉多少個 Bug？
小組處理 Bug 的整體趨勢如何？
Bug 啟動率和解決率在反覆項目接近結束時有如預期般地下降嗎？

必要的使用權限

若要檢視此報表，您必須在 SQL Server Reporting Services 中具有 [瀏覽] 角色，或屬於具有該角色的群組。如需詳細資訊，請參閱將使用者加入至 Team 專案或管理使用權限。

報表中的資料

[Bug 趨勢] 報表會根據您指定的篩選，計算小組已開啟、已解決和已關閉之 Bug 數的移動平均值。滾動平均以計算當日的前七天為基礎。也就是說，報表會將計算當日前的 7 天內每天每種狀態的 Bug 數加總再除以 7，以得出平均值。此資料衍生自資料倉儲。

下圖顯示 [Bug 趨勢] 報表的範例。

Bug 趨勢報表範例

這個報表最多可顯示三個線條圖，每個線條圖各表示已啟動、已解決和已關閉之 Bug 數的移動平均值。

您可以用下列方式篩選報表：

變更報表的開始和結束日期。
指定反覆項目路徑和區域路徑，或是指定 Bug 狀態、優先權或嚴重性，來篩選報表中計入的 Bug。

如需詳細資訊，請參閱本主題後面的篩選報表。

用於追蹤 Bug 的所需活動

若要讓 [Bug 趨勢] 報表變得更加實用與精確，小組必須執行下列活動：

定義 Bug，並指定其 [反覆項目] 和 [區域] 路徑。
在修正、確認和關閉每個 Bug 時，更新該 Bug 的 [狀態]。
在分級期間指定每個 Bug 的 [優先權] 和 [嚴重性]。

您可以使用 [分級] 活頁簿來快速更新 Bug 的反覆項目、區域、狀態、優先權和嚴重性。如需詳細資訊，請參閱分級活頁簿。

設定期程 (Sprint) 或反覆項目的持續期間

若要了解目前反覆項目的 Bug 趨勢，報表的開始和結束日期必須符合您目前反覆項目週期的開始和結束日期。

若要變更反覆項目的持續期間

按一下 [反覆項目開始 (日期)] 或 [反覆項目結束 (日期)] 旁的行事曆圖示，然後按一下日期。
按一下 [檢視報表]。

解譯報表

Bug 率應該要隨您在產品開發週期中所處的階段變動。小組在早期反覆項目發現的 Bug 應該要比在晚期反覆項目發現的少。產品週期快結束時，小組應已關閉反覆項目中大部分的 Bug。

解譯 Bug 率最好的方式，就是在檢閱這些數字時，同時對照目前 Team 專案活動，以及 [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。

當小組解決 Bug 的速度比發現 Bug 的速度快時，作用中 Bug 的數目會開始減少。當小組發現的 Bug 開始變少，表示產品正趨於穩定。

狀況不良的報表版本

狀況不良的 [Bug 趨勢] 報表可能顯示隨著出貨日期逼近，小組發現 Bug 的速率變快，但解決 Bug 的速度卻變慢。 Bug 未獲得修正，造成小組的 Bug 待處理項目數漸增，這時您就應該要調查原因。下圖顯示的報表指出小組發現許多 Bug、解決的 Bug 數比發現的 Bug 數少，而且關閉的 Bug 數比解決的 Bug 數少。

狀況不良的 Bug 趨勢報表版本