軟件缺陷分析-軟件測試之犯罪心理學

　　作為一名測試人員，最大的成就就是像福爾摩斯一樣，利用超強的觀察力，嚴密的邏輯推理能力，迅速找出軟件的"罪犯"，將其繩之以法。可是在成為"福爾摩斯"之前，觀察力、邏輯推理能力，是需要不斷訓練的。這篇文章實際就是軟件測試的"犯罪心理學"(初級版)：利用軟件缺陷數據，對缺陷進行分類匯總，計算缺陷分析指標，進而發現軟件生命周期的各個階段的不足，制定相應改進方法，增強軟件過程人為活動的規范性，最終目標提升軟件交付質量，提升測試效率

 

一、缺陷管理庫

缺陷管理庫記錄了缺陷相關的資料，為缺陷分析提供了詳細的信息，而只有正確的信息，才能保障正確的分析結果。

1.1 缺陷定義

軟件缺陷是指在產品說明、設計、編碼階段中的任何不足。一般要求將需求評審、設計評審、代碼檢查、測試、項目組內部發現、用戶反饋等幾種手段發現的缺陷都統一記錄在缺陷跟蹤系統中，進行統一管理、統計。而目前很多項目缺陷跟蹤系統中往往只包含了測試階段的缺陷統計，在此基礎上的缺陷分析勢必存在局限性。

 

1.2 缺陷信息

為了便於缺陷定位、跟蹤和修改，需要收集盡量多的有效信息，比較常見的缺陷信息如下：

• 缺陷描述
  • 被測產品信息：比如App名稱、版本號
  • 測試環境：wifi、數據網絡、測試環境、生產環境
  • 測試機型：機型、系統版本號
  • 測試步驟
  • 預期及實際結果
  • 復現概率
  • 測試輔助信息：截圖、視頻、日志
• 缺陷狀態
• 缺陷優先級：標識處理和修正軟件缺陷的先后順序指標
• 缺陷嚴重程度
• 缺陷發生的組件
• 缺陷創建時間
• 缺陷發現人
• 缺陷責任修改人
• 缺陷修復時間
• 缺陷產生原因

在提交缺陷時，需要遵循以下5個原則：

• 准確性：缺陷每個組成部分描述准確，不會產生誤解
• 完整性：復現該缺陷完整的步驟、截圖、日志
• 一致性：按照一致的格式書寫全部缺陷信息
• 簡潔性：只包含必不可少的信息，不包括任何多余的內容
• 清晰性：每個組成部分的描述清晰，易於理解

這一步其實可以理解成培養測試人員的觀察能力，信息收集能力。只有不斷觀察、收集正確信息，才可以為后續的偵查做好准備工作。

 

二、缺陷分析

缺陷分析是在形成缺陷管理庫的基礎上，對缺陷進行宏觀及微觀緯度的分析。通過缺陷分析，發現各種類型缺陷發生的概率，確定缺陷集中的區域，明確缺陷的發展趨勢，追蹤和分析缺陷產生的原因。在此分析基礎上，對軟件生命周期中各個角色、項目流程做改善和優化，提高軟件測試質量，提升測試效率。

缺陷分析僅僅是一種手段，而非最終目的。利用缺陷分析結論，反思和回溯缺陷產生的各個階段，思考如何避免類似問題，不再踩坑，在下次測試中得到提升，才是我們想要的結果。同樣的，缺陷分析的成果是一個持續改進優化閉環的過程，它是測試人員潛移默化中測試能力的提升，也是項目流程中各個角色共同保障產品質量意識的推動。例如缺陷分析發現很多需求缺陷是到測試階段才發現，那么就有必要加大需求評審力度；缺陷分析發現開發修復缺陷引入新缺陷比例很高，那么開發團隊在修復缺陷的時候要考慮到對周邊區域的影響，並且要通知相關區域的專家加強代碼審查。當然測試團隊也要盡可能多的在相關區域做一些回歸測試。大家可以結合自身項目來利用缺陷分析優化項目實踐。

 

三、宏觀缺陷分析技術

宏觀缺陷分析是指對缺陷信息進行分類和匯總，利用統計的方法計算分析相關指標，編寫缺陷分析報告的活動。宏觀缺陷分析的方法很多，這里主要關注缺陷發展趨勢分析、缺陷分布狀況分析、缺陷注入-發現分析。

3.1 缺陷發展趨勢分析

項目管理中一項非常重要但十分困難的工作就是平衡進度、質量和成本。測試人員可以提供缺陷提交、缺陷修復的趨勢圖表，幫助管理者從中發現一些簡單的缺陷發展趨勢（這種缺陷可以是本文論述的廣義缺陷發現手段確定的，也可以是單純的測試手段發現的），從而了解軟件質量趨勢。
這里給出一個常用的分析圖，x軸代表時間，y軸代表以下四種類型缺陷的數量：

• 發現數：累計的所有被發現bug的數量
• 關閉數：累計的所有被關閉bug的數量
• 日（期）發現數：當日（期）發現的缺陷數量
• 日（期）關閉數：當日（期）關閉的缺陷數量

圖1：缺陷分析發展趨勢圖

 

3.2 缺陷分布狀況分析

3.2.1 缺陷嚴重程度分布

缺陷嚴重程度度量有助於識別不同嚴重程度缺陷在所有缺陷中的比重，有助於開發測試人員資源的計划和分配。
這里給出一個常用的缺陷嚴重程度分析圖，x軸代表時間，y軸代表各嚴重級別的缺陷數量。

圖2：缺陷嚴重程度分布圖

通過缺陷嚴重程度圖表，分析各嚴重程度缺陷發現趨勢，判斷產品質量是否趨於穩定。如果高嚴重程度的缺陷大量增加通常意味着產品質量出現問題。

3.2.2 缺陷模塊分布

按照缺陷對應的產品組成部分來匯總缺陷數據，利用這樣的分布，可以找出我們產品高危模塊，針對高危模塊，調整測試策略。

3.2.3 ODC（正交缺陷分析）

正交缺陷分類法（Orthogonal Defect Classification，ODC）介紹了一種不同於大家常用的非常有效的軟件缺陷分類及分析方法，它定義了八個正交的缺陷屬性用於對缺陷的分類。所謂正交性是指缺陷屬性之間不存在關聯性，各自獨立，沒有重疊的冗余信息。

• 對於缺陷提交者，他需要給這個缺陷分配“活動（Activity）”、“觸發（Trigger）”、“影響（Impact）”這三個屬性。
  • Activity：項目生命周期的一個階段，該缺陷發生在該階段，例如需求、設計、代碼階段，即缺陷發現階段
  • Trigger：可以理解成測試的手段
  • Impact：對用戶的影響，例如安全性、易用性
• 當一個開發人員關閉一個缺陷時，他可以分配“階段（Age）”、“來源（Source）”、“限定符（Qualifier）”、“類型（Type）”以及“目標（Target）”這五個屬性。
  • Age：描述缺陷對應的代碼屬於新代碼，舊代碼，還是修復bug引入
  • Source：定義缺陷來源，是自身代碼問題，還是第三方代碼導致
  • Qualifier：指明了所進行的修復應歸於缺失，錯誤或者還是外來的代碼或者信息
  • Type：缺陷真正的原因，例如初始化、算法等
  • Target：描述缺陷是由於設計還是編碼引入，即缺陷注入階段

關於ODC分析方法，需要結合實際項目，對不同屬性進行篩選，優化不同屬性對應的值。
軟件缺陷分析方法：ODC 這篇文章中詳細解釋了ODC各屬性及對應的值。

3.3 缺陷注入-發現矩陣

利用缺陷的兩個重要屬性：缺陷發現階段、缺陷注入階段，分析缺陷數據，繪制出"缺陷注入-發現矩陣"，從中分析項目生命周期各個環節的質量，優化相關流程。

• 缺陷移除率：（本階段發現的缺陷數/本階段注入的缺陷數)*100%，它反映的是該活動階段的缺陷清除能力
• 缺陷泄漏率：（下游發現的本階段的缺陷數/本階段注入的缺陷總數）*100%，它反映的是本階段質量控制措施落實的成效

圖3：缺陷注入-發現矩陣

如上圖例子，需求階段一共注入了34個缺陷，需求評審時只發現了4個，設計過程中發現了15個，編碼和單元測試階段發現了12個，系統測試階段發現3個。這樣，需求階段的缺陷移除率 4/34*100%=11.76%。這個結果說明，我們需要重新審視需求評審，加大需求評審力度。另外，編碼階段的缺陷大部分依賴於系統測試發現，很顯然，項目開發過程中的單元測試和集成測試活動開展不夠深入。我們可以進一步分析這些系統測試出來的測試缺陷，是不是可以被更前端的評審/測試/設計討論活動所替代。

四、微觀缺陷分析技術

微觀缺陷分析是指從單個有價值的缺陷入手，追蹤和分析缺陷產生的本質原因。
並不是所有的缺陷都有必要去做微觀缺陷分析，因此首先需要挑選"合適的缺陷"。這里給出幾點建議

• 選擇典型有代表性的：同類型的一系列問題
• 選擇有發現難度：積累缺陷庫，對測試用例做補充
• 選擇有推廣意義的：該缺陷很普遍，可以推廣到其他業務線
• 再挑選合適的缺陷后，我們緊接着需要收集該缺陷相關的有效信息進行下一步缺陷原因分析。這些缺陷信息包括提交缺陷時信息，同時也包括和開發討論獲取的信息。

接着就是追蹤缺陷產生的真正原因。網絡上有很多總結的分析方法，有"望、聞、問、切"診斷法，有"5W"法，還有"探案分析法"。其實個人覺得在這一步驟中，更多需要積累經驗，善於追根究底，多問為什么，多理解產品實現邏輯，產品設計思路，有了這些基礎之后，合理的推理分析即可。
下面這兩篇文章是非常好的結合實踐總結的微觀缺陷分析，大家可以通過他們的分析積累經驗。

不會做bug分析？套路走起~

缺陷分析的正逆向

原文作者：桃子媽咪
原文鏈接：http://www.jianshu.com/p/1bb7ff2d7c6f