?
回顧校園生活中，我們參加每一場考試后都會對錯題進行分析總結并補缺補漏，以便能更好地去應對更重要的考試，回到軟體系統開發中，我們記錄和跟蹤缺陷的目的是什么，僅僅是為了在軟體系統開發程序中跟蹤Bug直至修復么？應該不止于此，我們也可以對專案缺陷進行分析，分析其共性進而分類，從而建立專案的“錯題集”，為下一次“考試”提供寶貴的經驗，
如圖1-1所示，通常一條缺陷記錄會包含缺陷編號、缺陷標題、狀態、缺陷描述、嚴重程度、優先級、開發負責人、測驗負責人、缺陷型別、功能模塊、對應版本和對應環境等資訊，那么，我們可以從哪些方面來分析和總結專案的缺陷呢？
一、缺陷分析維度
如圖1-2所示，我們可以按專案缺陷的嚴重程度維度來統計，圖中分別展示了專案各個嚴重程度的缺陷數和缺陷占比，從圖中可以看出該專案有25個嚴重程度為一般的Bug，占Bug總數的50%，嚴重程度為較小的Bug占據到了28%，嚴重和致命程度的Bug占總的22%，
基于上述各類嚴重程度缺陷占比資料，我們可以怎么分析專案情況呢？從占比上看，本次專案的嚴重及以上的Bug占比不到總的1/4，說明本次開發專案的整體提測質量還是比較高的，但是，從Bug總數上看，由于Bug總數較多，嚴重程度較小和一般的缺陷數達到了39個，將近總數4/5，為什么會有這么多嚴重程度不高的Bug？
我們可以繼續從缺陷型別維度分析，如圖1-3所示，這里我們可以看到，功能問題類的缺陷還是占據了一半以上，同時，界面和互動問題也占據了28%，說明開發對于產品比較細節的功能點以及產品界面和互動重視和理解程度不夠，導致提交測驗的產品大問題不多，但是小問題不少，這部分問題是不是可以避免或者減少的呢？這就是我們要思考的了，
為了減少下次同類問題頻繁發生，我們可以在開發方案和測驗要點評審節點明確各功能細節、界面和互動點，讓開發人員在開發程序中盡量避免此類問題，
如圖1-4所示，我們還可以從功能模塊維度進度分析，從圖中我們可以看到模塊B和模塊C的缺陷占據了總的82%，相對于模塊A和模塊D，我們可以理解為模塊C和模塊D的實作復雜度應該比較高，為了提高該模塊的開發質量，這次版本交付后可以督促開發去做總結和復盤，同時下次產品迭代涉及到這兩個模塊的時候也要做好研發方案評審，
如圖1-5所示，除了從缺陷的各個角度去分析，我們也可以從開發負責人維度來分析，假定這個專案有四個開發人員共同開發，且分配給他們的任務在作業量和作業難度上沒有太大的差異，從圖中我們看出RD_張開發任務的缺陷數遠遠少于其他三個開發人員，可以說明其對需求的理解以及開發的質量意識是比較高的，可以公開對其開發能力進行肯定，也可以讓其總結和分享開發經驗，引導其他開發人員進行改進，
二、總結
上文分析的缺陷資料并沒有包含所有專案的缺陷情況，但是大家可以嘗試去分析自己負責的模塊或者是整個專案的缺陷資料，并思考可能影響專案質量的原因，進而采取一定的措施去改進，不太可能一步到位完成，但是可以持續改進，這樣同樣型別或者是重復出現的缺陷就會越來越少，我們也能有更多的精力去應對更有價值的缺陷，
作者簡介：Chaofan，愛測角成員之一，專注探索和分享軟體質量保障，
如果需要上文缺陷分析模版檔案，可以瀏覽原文獲取，
原文地址：《漫談測驗成長之探索——缺陷分析》
?
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/502471.html
標籤：其他
上一篇：OAuth2.0協議安全學習