缺陷生命周期(2)

　　記錄：在缺陷總結階段，需要對一些支持數據信息進行記錄，例如：缺陷關閉時間、文檔更新完成時間等。

　　分類：針對缺陷進行確認測試和相關的回歸測試以后，就可以將缺陷的狀態進行分類，例如：關閉狀態、延遲狀態或者合并到其他項目中去等。

　　確定影響：對在缺陷識別階段、缺陷調查階段和缺陷改正階段中得到的影響分析進行合適的檢查，并在需要的時候進行更新。

　　表5列出了缺陷總結階段的分類數據。

　　表4 缺陷總結階段的分類表

　　5、案例

　　本節介紹一個根據IEEE Std 1044-1993制定的缺陷生命周期案例，如圖2所示。

　　圖2 缺陷狀態轉換圖

　　圖2是某項目的缺陷生命周期中的缺陷狀態轉換圖。下面分別從角色、狀態、嚴重程度和優先級四個方面闡述該項目使用的缺陷生命周期。

　　(1)相關角色

　　測試人員：主要是指發現和報告缺陷的測試人員。通常情況下，測試人員需要對該缺陷后續相關的狀態負責，包括回答相關人員對這個缺陷信息的詢問，以及在正式版本上進行再測試和回歸測試。

　　開發人員：主要指對缺陷進行調查和修復的開發人員。注意在提交測試人員正式再測試之前，需要對修改后的缺陷在開發環境上進行驗證。

　　缺陷評審委員會：主要由項目經理、測試經理、質量經理、開發經理以及資深的開發人員、測試人員等組成。他們對缺陷進行確認，并將其分配給相應的開發人員進行修復，同時對有爭議的缺陷進行仲裁。

　　版本經理：負責將已經解決的缺陷相關的配置信息合并到新的版本。

　　(2)缺陷狀態

　　新缺陷(New)：軟件中新發現的缺陷通常由測試人員提交。當然也可能是開發人員自己在組件測試或代碼走讀過程中提交，還有可能是從軟件使用的最終用戶或使用現場反饋得到的缺陷報告。具體缺陷發現的階段包括：

　　需求和設計階段：文檔評審過程中發現的缺陷。

　　編碼階段：代碼評審和代碼靜態分析過程中發現的缺陷。

　　測試階段：動態測試過程中發現的缺陷。

　　使用階段：用戶反饋的缺陷。

　　接受(Accepted)：相關人員提交的缺陷報告，需要經過缺陷評審委員會的評審。缺陷評審通過后，將缺陷狀態置為接受。缺陷評審委員會評審的主要內容包括：

　　報告中描述的問題是否確實是一個缺陷。

　　提交的缺陷報告是否符合要求。

　　分配(Assign)：將缺陷狀態為接受的缺陷分配給相關人員進行問題定位和修復。相應的缺陷狀態被置為分配。

　　打開(Open)：當缺陷處于打開狀態時，說明開發人員已經開始對該缺陷進行修復。

　　交付(Deliver)：解決缺陷的方法已經找到，并且已經將修改后的代碼等打上標簽，交付給版本經理。

　　解決(Resolved)：版本經理將相關的標簽等合入某個版本，交付給相關的開發小組進行驗證，測試通過，則缺陷狀態置為解決。

　　已修改(Fixed)：版本經理將已經解決的缺陷標簽合入某個版本，交付給相關的測試小組進行確認測試，測試通過，則缺陷狀態為已修改。

　　結束(Closed)：缺陷狀態處于已修改后，缺陷評審委員會對整個缺陷修復過程進行評審，評審通過后將缺陷狀態修改為結束狀態。

　　上面介紹的缺陷狀態是在缺陷管理過程中主要的狀態，或者是在缺陷處理順利時所經歷的狀態。實際上，缺陷還有一些其他的狀態，分別是：

　　研究(Investigate)：當缺陷分配給開發人員時，開發人員并不是都能直接找到相關的解決方案。開發人員需要對缺陷和引起缺陷的原因進行調查研究，這時候可以將缺陷狀態改為研究狀態。

　　詢問和回答(Query&Reply)：假如負責缺陷修復的人員認為缺陷描述的信息不夠明確，或希望得到更多與缺陷相關的配置和環境條件等，可以將缺陷狀態改為詢問和回答。

　　拒絕(Declined)：缺陷評審委員會通過討論研究，認為提交的問題不是缺陷;或通過開發人員的研究分析，認為不是缺陷，開發人員可以將具體的理由加入到缺陷描述中，缺陷評審委員會據此將缺陷狀態修改為拒絕。

原文轉自：http://www.uml.org.cn/Test/201405223.asp