軟件缺陷的有效管理

“這次發布之前怎么這么多的缺陷，是不是需要分析一下啊？” 答案是肯定的，可是這個時候才想起要分析已經有點晚了，有可能這些缺陷很難分析了。這是發生過的一個真實場景，所記錄的缺陷包含信息很有限，很難有效的做好分析！本文就來聊聊如何有效的管理和分析缺陷。

缺陷記錄

曾經有個項目是在 QC (Quality Center)里記錄缺陷，需要填寫很多必填屬性字段，加上 QC 服務器在國外，訪問速度非常的慢，每次記錄缺陷成為了大家極其痛苦的一件事情。于是，很多時候，發現了缺陷也不愿意往 QC 里填，而是直接寫個紙條簡單記錄下，驗證完了它的生命周期就結束了，這樣后面就沒辦法去很好的跟蹤和分析了。（題外話：當時采用腳本稍微減輕了點痛苦。）

也有的項目對缺陷的格式和屬性沒有嚴格要求，記錄的時候很簡單也很自由，這樣記錄的缺陷由于很多必要信息的缺失，對后續的跟蹤和分析也是極為不利。

還有一種情況就是記錄缺陷時同樣有一些屬性要求填寫，但是這些屬性值可能不是那么有意義，導致存儲的信息不僅沒用，反而添加混亂，也是不利于跟 蹤和分析的。比如，其中的“根源（root cause）”屬性的值如下圖 1 所示，這些值根本就不是根源，這是一個沒有意義的搗亂屬性。

圖 1 某缺陷根源屬性值

缺陷記錄應該做到盡量簡單，且包含必要的信息。

1. 標題：言簡意賅，總結性的語句描述是什么缺陷

2. 詳情：包括重現步驟、實際行為、期望結果等，根據具體情況確定其詳細程度，必要時可以添加截圖、日志信息等附加說明。

3. 重要屬性：優先級、嚴重性、所屬功能模塊、平臺（OS、瀏覽器、移動設備的不同型號等）、環境、根源等，這些屬性對應的值需要根據不同項目的情況自己定義，其中“根源”是相當關鍵的一個屬性，后面有示例可以參考該屬性對應的值有哪些。

4. 其他：每個項目對應的還會有其他信息需要記錄的，自行定義就好。

在敏捷開發環境中，測試人員可能隨時在測試、隨時都會發現缺陷，包括還在開發手里沒有完成的功能。什么時候發現的缺陷需要記錄呢？通常情況下， 開發還沒完成的用戶故事（story），測試人員發現缺陷只需要告訴開發修了，在該故事驗收的時候一起檢查就好了，無需單獨記錄；在開發已經完成，交到測 試人員手里正式測試的故事，再發現缺陷就需要記錄來跟蹤了；后續的所有階段發現的缺陷都需要記錄。

缺陷分析

比較推薦的一種缺陷分析方法是魚骨圖分析法，可以將跟缺陷相關的各個因素填寫到魚骨圖里，對缺陷進行分析，如下圖 2 示：

圖 2. 魚骨圖缺陷分析法

缺陷相關的各屬性拿到了，就可以用表格、曲線圖、餅圖等統計各個屬性對應的缺陷數量，分析缺陷的趨勢和原因。下面是我在項目上做過的分析報告圖：

圖 3. 功能與環境對應缺陷數量統計表和缺陷根源比例圖

圖 4. 缺陷根源統計表和比例圖

圖 5. 缺陷迭代趨勢分析圖

分析完得到統計的結果就要采取對應的措施，從而防范更多的缺陷產生。比如：修缺陷（上面示例中的“bug fixing”）引入的新缺陷比較多，可以在修復缺陷后添加對應的自動化測試；瀏覽器兼容性問題相關的缺陷較多的話，可以在開發完成驗收的時候在多種瀏覽 器上驗收，等等。

什么時候該進行缺陷的分析呢？通常，推薦每個迭代周期分析一次，并且跟以往各個迭代進行對比，進行趨勢對比。當然，有時候可能一個迭代發現的缺陷非常少，分析的周期可以根據具體情況做出調整。

總結

缺陷記錄是為更好的跟蹤和分析缺陷做準備的，而缺陷分析是軟件質量保證的重要環節，對于軟件過程的改進，軟件產品的發布來說具有十分重要的參考價值，建議各項目定期都要做做缺陷分析。