目標驅動的需求評審度量應用

來自專欄構建高效的軟體測試知識體系2 人贊了文章

作為靜態測試的評審，其主要目的是測試人員儘早參與儘早發現盡量多的缺陷，避免在後續階段出現更多的缺陷。從這個意義而言，儘早參與評審可以作為缺陷預防的一種有效手段。但在評審實踐過程中，其效果並不是令人滿意。

本文將從評審過程中收集與分析度量入手，闡述一個好的評審應該去收集和分析哪些度量，以評估評審效果是否滿足了要求。評審過程中需要收集各種度量，以確保：

1.評估評審對象的質量；

2.評估評審過程的效率和有效性；

3.評估評審的投資回報率；

但在評審實踐過程中，針對評審收集度量數據往往會處在兩個極端：一種是幾乎沒有評審度量數據，評估和監控只是憑感覺；而另一種是羅列一堆度量數據，看得你眼花繚亂，好像告訴你 - 你自己看著辦吧，喜歡哪個你就選擇哪個。這也是大家覺得討論度量時的第一種感覺：度量好遙遠，和我沒有什麼關係。但是，針對度量我們正確的態度應該是：

度量（量化的結果）不是目的，而是監控與管理的手段！

因此羅列一堆度量數據沒有啥用。我們需要做的是將相關的度量數據進行收集和分析，以發現當前我們所處的狀態，並與你的目標進行比較：假如當前狀態與目標之間出現較大的偏差，此時採取必要的應對手段就是必需的，即作為監控與管理的手段。因此，合理的度量應用應該是目標驅動的！更多關於目標驅動的度量應用，可以參考（Goal - Question - Metric）GQM（以後有機會寫篇文章詳細描述），GQM的層次結構圖如下：

回到評審上面，根據上面羅列的3個目標，我們就可以有針對性的收集與分析度量數據，從而可以更高效對它們進行評估、監控和管理（本文只是提供了建議收集的數據，並沒有對其中的數據進行分析，僅供參考。具體的還需要你根據實際情況做調整，適合你的才是最好的，畢竟測試是基於上下文的）。

1.評估評審對象的質量

評估評審對象的質量，主要從3個方面進行數據收集與分析，分別是：

1）評審檢測缺陷密度 = 檢測的缺陷/頁數，或者檢測的缺陷/KLOC；

2）評審遺漏缺陷密度 = 遺漏的缺陷/頁數，或者遺漏的缺陷/KLOC；其中遺漏的缺陷數目，可以來自項目前期根據KLOC之類估算得到的需求階段的缺陷數目，減去當前檢測缺陷數目；或者作為項目結束之後一段時間，統計得到的需求階段的缺陷數目與當前缺陷檢測數目之差；

3）缺陷集群：根據需求評審中發現的缺陷在不同功能模塊的分布，可以幫助選擇後續的測試重點，也可以作為將來過程改進中根本原因分析的輸入；

2.評估評審過程的效率和有效性

評估評審過程的效率，可以收集與分析下面的數據：

1）評審效率 = 頁數（或KLOC）/時間（或工作量）；

1）缺陷檢測百分比DDP = 評審發現的缺陷數/總的缺陷數；

2）缺陷遺漏百分比DOP = 評審遺漏的缺陷數/總的缺陷數；

3）評估評審對象質量的一些度量，也可以作為評審過程有效的參考輸入；

3.評估評審的投資回報率

評估評審的投資回報，可以收集與分析下面的數據：

1）評審質量成本分析 = 缺陷數目/成本（或工作量）；對於不同階段發現缺陷的質量成本分析，就可以幫助分析評審的投資回報率，同時也可以獲取通過評審能夠解決的項目時間；

關於更多軟體測試和思維能力的分享，可以關注我的知乎文章：鄭文強；或者個人網站：鄭文強的專欄。