軟件缺陷工作流程和缺陷報告

　　近在讀《How We Test Software at Microsoft》

　　其中的缺陷和測試用例管理，發現很多思路和做法跟目前我們在進行的也頗為相似，總結如下：

　　缺陷管理和用例管理是一個軟件測試項目的必備，無論是數千人的國際化大企業，還是三五人的小軟件作坊。這都是測試隊伍的兩大工作成果。其中，測試用例描述測試過程的意圖，缺陷則描述這些測試用例的結果，今天談談缺陷工作流程。

　　缺陷工作流程為：

　　文字描述如下：

　　產品代碼-》運行測試用例-》創建缺陷報告-》三方會審討論缺陷

　　如果缺陷沒有批準-》把缺陷當作不修正來解決-》關閉缺陷

　　如果缺陷批準了要調查-》研究是代碼錯誤還是設計錯誤

　　如果是代碼錯誤，提議修正代碼錯誤-，在提交三方會審-》如果修正批準了-》修改代碼-》解決缺陷-》重現缺陷-》通過了則關閉缺陷;不通過，則重新激活-》重新調查是代碼錯誤還是設計錯誤

　　如果是設計錯誤，修正錯誤直到批準-》再進行三方會審。其他后續流程和以前類似。

　　在這里需要注意的是，有些缺陷需要綜合考慮優先級別，產品發布周期等因素，標注為不予修復。也就是說雖然承認該缺陷，但不會修正，或者決定推遲修正，即該缺陷會在未來的版本修正。這些不予修正的缺陷應該在releasenotes中予以注明。

　　這里所說的三方會審，一般意義上指的是開發測試和項目管理。

　　缺陷報告中應該經常避免的幾個錯誤：

　　1、電子郵件討論

　　電子郵件和缺陷系統是大多數的工程師常用的工具，所以很多時候兩者被混用就不足為怪了。然后除了開發工程師和測試工程師之外，缺陷報告還有其他的廣泛用途，所以和缺陷不直接相關的信息不應該被寫入報告。

　　2、缺陷漸變

　　缺陷漸變是說在同一個缺陷的報告中，缺陷從一個問題演變成另外一個不相關的問題。這種現象有時候發生很快，有時候過幾天或者幾個月。不管怎么樣，都要極力避免缺陷漸變。對于已經變形的缺陷，通常很難分析其中根本原因，產品支持工程師在搜索相關問題時候還會發生混淆。如果一個缺陷報告開始演變，要及時停止，并就新問題重新報告一個新的缺陷。

　　3、對個缺陷

　　如果測試人員很忙碌，他們可能會相關的缺陷記錄放在一個缺陷報告中。盡管我們盡力避免這類問題，在一個缺陷報告中報告幾個問題從來就不是好主意。這會帶來一系列的問題，比如：

　　(1)缺陷的優先級別不能單獨設置

　　(2)缺陷的決定不能單獨設置，比如立即修復還是推遲到下一版本

　　(3)雖然缺陷在類似領域，但是可能需要分配給不同的開發工程師

　　(4)在分析產品缺陷的根本原因時候，同一缺陷報告中的每個缺陷可能有不同的錯誤根源。

　　關于缺陷報告的時候

　　這似乎是管理層最喜歡干的事情，這些報告發掘和代表了各種各樣的數據。比如下面的一些度量：

　　(1)修復的缺陷/所有解決了的缺陷：可以衡量缺陷修正和其他決斷的比例

　　(2)缺陷發現率

　　(3)缺陷修正率：當缺陷會審標準提高時候，修正的百分比下降

　　(4)每個組件的缺陷數：根據功能排序可以影響哪些領域需要更多的測試

　　(5)如何發現缺陷：了解缺陷如何發現可以幫助根源分析和實現缺陷防止技術

　　(6)每個測試活動發現的缺陷：分析測試類別包括結構化測試，發布前測試，測試用例開發，自動化測試等

　　(7)平均解決缺陷的時間：跟蹤開發團隊對輸入的缺陷的響應速度

　　(8)平均關閉缺陷的時間：跟蹤缺陷的平均反應時間

　　缺陷數據唯一不能使用的時候：績效衡量

　　缺陷數據具有太多的可變量，比如：

　　(1)所測試功能的復雜性

　　(2)開發人員的編程能力

　　(3)規格完整性

　　(4)缺陷預防和缺陷發現

　　(5)報告的及時性

原文轉自：http://www.anti-gravitydesign.com