實例！軟件缺陷數據度量和分析

　　缺陷報告，是軟件測試這個職位最重要得產出之一。甚至對軟件測試這個行業你能夠用比較狹隘的描述去定義他爲：‘測試就是爲了找到缺陷’。 測試人員報出的缺陷，能夠很好的反應產品中的問題，修復了這些問題，就能夠有效的下降產品風險。其實缺陷報告不僅僅能幫助研發團隊發現問題，他也能夠起到重要的過程反饋做用。

　　缺陷報告是咱們測試報告的兩大核心要素之一，他與測試執行狀況一塊兒組成了咱們測試報告的主要內容。那麼缺陷報告，咱們應該報告一些什麼，是否是僅僅是缺陷數量呢？咱們今天就來講說怎麼用‘量化分析’的形式，來製做咱們的缺陷報告。

 

　　咱們用一個實際項目缺陷報告來闡述這個課題，這個項目狀況是這樣的：

• 該項目爲一個COTS產品的定製性二次開發項目
• 項目週期計劃爲4個月，實際完成時間爲6個月
• 項目是一個整體人員不到10人的小型項目
• 採用持續集成，高速迭代的研發方式

 

　　1.　　咱們要看到的第一個報表叫作‘缺陷到達率報告’，見下圖：

　　

　　

　　缺陷到達率指的是單位時間內，報出缺陷的數量。 上圖按照每個月報出的缺陷數量進行了統計，而且按嚴重級別進行了分類。

　　解析：

　　① 缺陷到達率在前四個月內呈明顯降低趨勢

　　② 五月份的缺陷量回升主要體如今低嚴重級缺陷數量上

　　③ 缺陷數的嚴重級別成正態分佈

　　④ 六月份缺陷明顯回升

 　　

　　結合着項目的實際咱們對這個報表進行分析：後兩個月的bug數量上升主要是由於在這段時間咱們的測試分別引入了集中的迴歸測試和驗收測試（咱們將UAT測試中，客戶報出的bug導入到了咱們的缺陷管理系統內）。客戶報出的缺陷方面，嚴重級偏高，這多是由於客戶對於缺陷嚴重級別的理解，與咱們研發團隊的理解並不一致所形成的。咱們有可能須要跟客戶就這個方面進行更好的交流和溝通。

 

　　2.　　缺陷移除率分析：

　　

　　

　　缺陷移除率指的是咱們在研發各階段明確和解決的本階段引入的缺陷的比例。

　　在軟件測試的基礎理論裏面咱們強調，軟件測試應該儘早的介入項目，通常要求在需求分析階段就進行參與，而且咱們要用靜態測試的方法去對各階段的產出進行測試。在本階段咱們就應該去追求去儘可能明確本階段所產生的問題缺陷。而缺陷移除率表現的就是咱們在當階段明確發現該階段引入的缺陷及問題的能力，反過來他又能體現出有多少問題被從一個階段遺留到了下一階段。

　　好比說，在需求階段，咱們的產出：需求文檔裏面就引入了10個缺陷，咱們在當階段經過需求評審測試等工做，發現並明確其中的2個缺陷。那麼該階段的缺陷移除率就是2/10=20%。而缺陷遺留率就是（10-2）/10=80%，有80%的缺陷被遺留進了下一個階段。

　　更直觀的來講咱們還能夠作出下面的表格和圖表：

　　

　　

　　解析：對咱們以上的報表進行分析，咱們可能能夠得出如下結論：　

　　① 需求階段缺陷移除率較低，說明需求評審工做的缺失

　　② 驗收階段報出需求問題數量可觀，說明需求團隊與用戶的溝通不順暢

　　③ 單元測試總體發現缺陷數太低

　　④ 測試之外的人員缺陷報告數較低

 

 　　除此以外，經過實際項目調查咱們發現，實際團隊除測試小組的其餘人員有着不愛報bug的傾向。實際上，一個項目的質量是應該與團隊全部人員都息息相關的，而不只僅是測試團隊的任務。咱們是否是應該更鼓勵項目其餘方面人員去主動提交缺陷，是值得咱們思考的一個問題。

 

　　3.　　缺陷分佈率分析

　　

　　

　　缺陷分佈率指的是針對不一樣的功能模塊，所報出的缺陷數量。 上圖是一個小型電子商務平臺的缺陷分佈率狀況。

　　解析：

　　① 商品瀏覽模塊報出的整體缺陷量較多

　　② 支付模塊報出嚴重缺陷較多

 

　　這個圖表在直觀度上有所欠缺，並且也不能最準確的表述各模塊的質量特徵。這裏咱們能夠作一次加權處理：好比不一樣嚴重級的缺陷，給他不一樣的分數，進行二次計算，再來從新統計。

　　例：嚴重缺陷權值5，關鍵缺陷權值3，其餘權值1，得出：

　　

　　能夠看到支付模塊的佔比上升了，他與瀏覽展現模塊構成項目質量指標最值得關注的兩大部分，從而能夠指導咱們測試資源的投入。

 

　　4.　　缺陷修復率分析

　　

　　缺陷修復率指的在必定單位時間內，報出的，被修復的以及遺留的缺陷數量的對比。這是比較直觀的一種報表。

　　

　　解析：

　　① 缺陷報出數量在經歷了穩定降低以後，在項目後期迎來了回升

　　② 開發團隊的bug修復能力在4月份出現滑坡，據調查是由於開發核心人員受到了抽調

　　③ 項目收尾時的bug遺留數量不容樂觀，主要是因爲最後兩個月報出bug數量激增形成

　　

　　經過這樣報表展現和分析，咱們也能夠得出一些有用的結論：好比咱們是否應該考慮將回歸測試的動做前移；又好比咱們能夠發現團隊核心成員的穩定性是一個項目成功的重要要素。

 　　

　　其餘還有不少形式的統計報表咱們能夠考慮，好比：

　　5.　　缺陷修復輪次統計

　　

　　缺陷修復輪次統計經過統計缺陷被激活的次數，來觀察缺陷都須要通過多少輪的修復才能被關閉這樣的數據。

　　

　　解析：　

　　① 項目大部分缺陷經歷了屢次修復

　　② 反映了開發與測試團隊存在必定程度的溝通問題

　　③ 部分緣由在於測試團隊的測試描述不充分

 

　　6.　　缺陷有效率統計

　　

　　缺陷有效率指的是咱們報出的缺陷中間，有效缺陷的百分比。

　　

　　解析： 能夠明顯看到，測試環境問題已經很大程度影響到了測試的有效率

 

　　7.　　階段缺陷分佈統計

　　

　　階段缺陷分佈指的是在必定時間階段內，咱們彙報的bug嚴重級別上又怎樣的分佈狀況。

　　

　　解析： 5月份有明顯的次嚴重級bug數上升 6月份有最嚴重級bug數上升

 

　　8.　　缺陷類型分佈統計

　　

　　

　　解析： 大部分缺陷類型集中爲功能性，可能揭示了咱們在其餘質量指標的關注不足

 

　　9.　　測試活動缺陷率統計

　　

 

　　解析：

　　① 系統測試的效率並無咱們想象中的那麼高（200多個缺陷中，只有不到40%來源於系統測試階段）

　　② 外部測試的缺陷數使人擔心（指的實際上UAT測試的結果）

　　③ 迴歸測試和探索性測試發現了系統測試沒有發現的問題，說明他們都是很是有效並且必要的測試活動

 

　　以上咱們討論了在測試缺陷數據度量上，咱們可以去考慮的報表統計的類型的思路，也結合着實際項目情況對每一個報表進行了必定的解析。實際工做中，咱們還能夠作出不少別的類型的報表，只要咱們認爲該方面的統計數據能夠給咱們帶來有用信息和思考的，咱們均可以去對他進行彙報。

　　

　　還有幾點問題要談到：

　　首先：咱們的這個實例裏，採樣樣本數量是偏小的，形成的問題是數據隨機性會偏大，有可能出現失真的狀況。若是項目規模夠大，採樣樣本更多，咱們的缺陷數據度量分析就能更準確的反映項目測試過程狀態已經咱們的產品質量特性。

　　其次：若是咱們老是在項目結尾階段纔去作缺陷數據度量，那麼他對於項目反饋的做用就很是有限了--畢竟項目都已經收尾了。其實咱們在談到測試報告時，應該知道測試報告不僅僅只有測試完成報告，還有測試過程報告。若是咱們在測試過程報告裏就引入缺陷數據度量，那麼咱們就能更好的對測試和研發過程進行反饋，從而達到過程改進的效果。

　　最後：若是想要在測試報告時，可以收集到更多有用的缺陷數據，就要求咱們在缺陷所包含的信息進行更詳細的定義。好比說要求開發在解決缺陷的同時，明確的填入該缺陷所產生的根源階段，這樣咱們才能統計出咱們在第二個節點作出的缺陷泄露率/移除率報告。