例項！軟體缺陷資料度量和分析
缺陷報告，是軟體測試這個職位最重要得產出之一。甚至對軟體測試這個行業你可以用比較狹隘的描述去定義他為：‘測試就是為了找到缺陷’。 測試人員報出的缺陷，可以很好的反應產品中的問題，修復了這些問題，就可以有效的降低產品風險。其實缺陷報告不單單能幫助研發團隊發現問題，他也可以起到重要的過程反饋作用。
缺陷報告是我們測試報告的兩大核心要素之一，他與測試執行情況一起組成了我們測試報告的主要內容。那麼缺陷報告，我們應該報告一些什麼，是不是僅僅是缺陷數量呢？我們今天就來說說怎麼用‘量化分析’的形式，來製作我們的缺陷報告。
我們用一個實際專案缺陷報告來闡述這個課題，這個專案情況是這樣的：
- 該專案為一個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測試的結果）
③ 迴歸測試和探索性測試發現了系統測試沒有發現的問題，說明他們都是非常有效而且必要的測試活動
以上我們討論了在測試缺陷資料度量上，我們能夠去考慮的報表統計的型別的思路，也結合著實際專案狀況對每個報表進行了一定的解析。實際工作中，我們還可以做出很多別的型別的報表，只要我們認為該方面的統計資料可以給我們帶來有用資訊和思考的，我們都可以去對他進行彙報。
還有幾點問題要談到：
首先：我們的這個例項裡，取樣樣本數量是偏小的，造成的問題是資料隨機性會偏大，有可能出現失真的情況。如果專案規模夠大，取樣樣本更多，我們的缺陷資料度量分析就能更準確的反映專案測試過程狀態已經我們的產品質量特性。
其次：如果我們總是在專案結尾階段才去做缺陷資料度量，那麼他對於專案反饋的作用就非常有限了--畢竟專案都已經收尾了。其實我們在談到測試報告時，應該知道測試報告不單單隻有測試完成報告，還有測試過程報告。如果我們在測試過程報告裡就引入缺陷資料度量，那麼我們就能更好的對測試和研發過程進行反饋，從而達到過程改進的效果。
最後：如果想要在測試報告時，能夠收集到更多有用的缺陷資料，就要求我們在缺陷所包含的資訊進行更詳細的定義。比如說要求開發在解決缺陷的同時，明確的填入該缺陷所產生的根源階段，這樣我們才能統計出我們在第二個節點做出的缺陷洩露率/移除率報告。
轉載自：https://www.cnblogs.com/yingyingja