測試人員在每次版本迭代中，會對項目的整體質量有一個把控：
對於項目常見的問題，開發經常犯的錯誤都會有所了解。
為了避免或者減少這樣的錯誤或不規范的事情在發生，測試人員可以對缺陷進行分析總結，
提出有針對性的預防意見及規避措施，以提高產品的質量。
那么，可以從那幾個方面進行缺陷分析呢？
一、可分析缺陷因子
1、缺陷嚴重程度
- Fatal(致命的)
致命的錯誤，造成系統崩潰、死機，或造成數據丟失、主要功能完全喪失等。
- Critical(嚴重的)
嚴重錯誤，指功能模塊或特性沒有實現，主要功能部分喪失，次要功能全部喪失，或致命的錯誤聲明。
- Major(重要的)
不太嚴重的錯誤，如次要功能模塊喪失、提示信息不夠准確、用戶界面差和操作時間長等。
- Minor(次要的)
一些小問題如有個別錯別字、文字排版不整齊等，對功能幾乎沒有影響，軟件產品仍可使用。
2、缺陷產生模塊
記錄對應模塊，所產生的缺陷，不同的項目<模塊>的顆粒度不一樣，可視情況選擇。
-
按照系統子模塊進行划分
顆粒度較細，適用於小型項目，20個模塊左右的適用此維度。
-
按按照大組件模塊進行划分
顆粒度適中，適用於中型項目，一個組件下面有多個模塊，組件個數5+以上。
-
按照應用服務進行划分
顆粒度較大，適合微服務類型項目，但不建議超過20+以上的分類。
-
按照前端、后端、接口服務等進行划分
顆粒度太大，不建議使用，問題主要分為為前端、后端、對外接口。
3、缺陷產生原因
- 需求設計問題
模糊不清的需求、說不明白的PRD、分析不到位等
- 開發設計漏洞
設計缺失、功能遺漏、場景未考慮、容錯性不高等
- 代碼編寫漏洞
純屬開發個人技能不嫻熟、編碼質量不高、方法函數應用補數量、調試腳本未清除等。
- 部署配置問題
配置方案不完整、集成出錯、配置缺失遺漏、受其它外在資源的影響等。
4、缺陷產生階段
- 需求分析：對應缺陷產生余需求分析設計階段
- 開發設計：對應缺陷產生於開發詳細設計階段
- 開發自測：開發自測產生的缺陷
- 產品部署：安裝過程中發現的缺陷
- 提測階段：需求測試階段
- 上線應用：線上反饋的問題，更多來源於客戶
5、缺陷類型
- 服務接口
- 數據計算
- 數據校驗
- 數據顯示
- 業務功能
- 業務流程
- 參數配置
- 安全問題
- 性能問題
6、缺陷修復周期
對應不同嚴重程度問題的解決效率與周期。
根據大型網站的可用性指標0,999-0.999999，對於致命性問題的修復時間限定在5分鍾到500分鍾之間不等。
不過日常生產過程中，沒有這么高的要求，但高效率的團隊盡量要做到：致命性問題當天內要得到解決；嚴重問題兩天內得到解決；
- Fatal(致命的) ：當天內修復
- Critical(嚴重的) ：兩天修復
- Major(重要的)：一周內修復
- Minor(次要的)：根據其它問題的修復情況，如有剩余時間，可按需修復
7、缺陷修復率
整個項目階段所產生的缺陷的修復情況統計，可對比歷史項目或版本的數據。
可統計維度：對應模塊問題的修復率、對應缺陷等級問題的修復率、對應責任人產生缺陷的修復率等等。
8、缺陷責任人
對應缺陷的責任人：可能是產品、開發、項目、測試、運維或客戶自身。
9、缺陷投入
各職能人員在缺陷上的投入，包含產品、研發、測試、運維等。
二、缺陷分析維度
上述缺陷因子中，單一因子的分析，這里就不多介紹，使用中直接使用餅圖分析即可。
重點從多因子組合的情況有哪些維度可以分析統計。
1、缺陷等級
2、缺陷等級&缺陷責任人
根絕不同缺陷等級進行預設分數，結合缺陷責任人產生缺陷的數量進行分數評估。
對項目組各成員對產品質量的“貢獻”，有數據上的評判--可參考。
3、缺陷等級&缺陷產生模塊&缺陷修復率
根絕不同缺陷等級進行預設分數，結合對用模塊產生缺陷的數量進行分數評估。
對項目各功能模塊質量有一個量化的認識，便於針對性的開展質量改進與分析總結。
各模塊缺陷等級分布
4、缺陷產生模塊&缺陷類型
分析模塊缺陷數量以及對應什么問題類型較多，便於后續版本或項目有意識規避類似問題，引起相關人員的重視。
5、缺陷等級&缺陷產生階段
分析各階段不同等級缺陷分布情況。
6、缺陷產生階段&缺陷等級&缺陷投入
在缺陷產生階段及缺陷等級的基礎上延伸，可以統計各階段在缺陷上的消耗。
三、總結
上述的因子還可以擴充，缺陷的應用分析也還有很多維度，不局限與上述列到的內容。
缺陷分析與度量工作是一個需要積累的過程，最終的目的還是通過不同維度不同圖表的分析，更多量化的來評判軟件的質量。
從而幫助項目成員認識到問題，並在后續版本迭代或新項目中有序規避。