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

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

 

1、缺陷管理庫

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

1.1 缺陷定義

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

 

1.2 缺陷信息

爲了便於缺陷定位、跟蹤和修改，須要收集儘可能多的有效信息，比較常見的缺陷信息以下：

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

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

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

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

 

2、缺陷分析

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

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

 

3、宏觀缺陷分析技術

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

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%。這個結果說明，咱們須要從新審視需求評審，加大需求評審力度。另外，編碼階段的缺陷大部分依賴於系統測試發現，很顯然，項目開發過程當中的單元測試和集成測試活動開展不夠深刻。咱們能夠進一步分析這些系統測試出來的測試缺陷，是否是能夠被更前端的評審/測試/設計討論活動所替代。

4、微觀缺陷分析技術

微觀缺陷分析是指從單個有價值的缺陷入手，追蹤和分析缺陷產生的本質緣由。
並非全部的缺陷都有必要去作微觀缺陷分析，所以首先須要挑選"合適的缺陷"。這裏給出幾點建議

• 選擇典型有表明性的：同類型的一系列問題
• 選擇有發現難度：積累缺陷庫，對測試用例作補充
• 選擇有推廣意義的：該缺陷很廣泛，能夠推廣到其餘業務線
• 再挑選合適的缺陷後，咱們緊接着須要收集該缺陷相關的有效信息進行下一步缺陷緣由分析。這些缺陷信息包括提交缺陷時信息，同時也包括和開發討論獲取的信息。

接着就是追蹤缺陷產生的真正緣由。網絡上有不少總結的分析方法，有"望、聞、問、切"診斷法，有"5W"法，還有"探案分析法"。其實我的以爲在這一步驟中，更多須要積累經驗，善於追根究底，多問爲何，多理解產品實現邏輯，產品設計思路，有了這些基礎以後，合理的推理分析便可。
下面這兩篇文章是很是好的結合實踐總結的微觀缺陷分析，你們能夠經過他們的分析積累經驗。

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

缺陷分析的正逆向

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