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

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

一、缺陷管理庫

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

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

作者：Glen.He

出處：http://www.cnblogs.com/puresoul/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利。