缺陷的應用與度量

測試人員在每次版本迭代中，會對項目的總體質量有一個把控：

對於項目常見的問題，開發常常犯的錯誤都會有所瞭解。

爲了不或者減小這樣的錯誤或不規範的事情在發生，測試人員能夠對缺陷進行分析總結，

提出有針對性的預防意見及規避措施，以提升產品的質量。

那麼，能夠從那幾個方面進行缺陷分析呢？

1、可分析缺陷因子

一、缺陷嚴重程度

• Fatal(致命的)

致命的錯誤，形成系統崩潰、死機，或形成數據丟失、主要功能徹底喪失等。

• Critical(嚴重的)

嚴重錯誤，指功能模塊或特性沒有實現，主要功能部分喪失，次要功能所有喪失，或致命的錯誤聲明。

• Major(重要的)

不太嚴重的錯誤，如次要功能模塊喪失、提示信息不夠準確、用戶界面差和操做時間長等。

• Minor(次要的)

一些小問題若有個別錯別字、文字排版不整齊等，對功能幾乎沒有影響，軟件產品仍可以使用。

二、缺陷產生模塊

記錄對應模塊，所產生的缺陷，不一樣的項目<模塊>的顆粒度不同，可視狀況選擇。

• 按照系統子模塊進行劃分

顆粒度較細，適用於小型項目，20個模塊左右的適用此維度。

• 按按照大組件模塊進行劃分

顆粒度適中，適用於中型項目，一個組件下面有多個模塊，組件個數5+以上。

• 按照應用服務進行劃分

顆粒度較大，適合微服務類型項目，但不建議超過20+以上的分類。

• 按照前端、後端、接口服務等進行劃分

顆粒度太大，不建議使用，問題主要分爲爲前端、後端、對外接口。

三、缺陷產生緣由

• 需求設計問題

模糊不清的需求、說不明白的PRD、分析不到位等

• 開發設計漏洞

設計缺失、功能遺漏、場景未考慮、容錯性不高等

• 代碼編寫漏洞

純屬開發我的技能不嫺熟、編碼質量不高、方法函數應用補數量、調試腳本未清除等。

• 部署配置問題

配置方案不完整、集成出錯、配置缺失遺漏、受其它外在資源的影響等。

四、缺陷產生階段

1. 需求分析：對應缺陷產生餘需求分析設計階段
2. 開發設計：對應缺陷產生於開發詳細設計階段
3. 開發自測：開發自測產生的缺陷
4. 產品部署：安裝過程當中發現的缺陷
5. 提測階段：需求測試階段
6. 上線應用：線上反饋的問題，更多來源於客戶

五、缺陷類型

1. 服務接口
2. 數據計算
3. 數據校驗
4. 數據顯示
5. 業務功能
6. 業務流程
7. 參數配置
8. 安全問題
9. 性能問題

六、缺陷修復週期

對應不一樣嚴重程度問題的解決效率與週期。

根據大型網站的可用性指標0,999-0.999999，對於致命性問題的修復時間限定在5分鐘到500分鐘之間不等。

不過平常生產過程當中，沒有這麼高的要求，但高效率的團隊儘可能要作到：致命性問題當天內要獲得解決；嚴重問題兩天內獲得解決；

• Fatal(致命的) ：當天內修復
• Critical(嚴重的) ：兩天修復
• Major(重要的)：一週內修復
• Minor(次要的)：根據其它問題的修復狀況，若有剩餘時間，可按需修復

七、缺陷修復率

整個項目階段所產生的缺陷的修復狀況統計，可對比歷史項目或版本的數據。

可統計維度：對應模塊問題的修復率、對應缺陷等級問題的修復率、對應責任人產生缺陷的修復率等等。

八、缺陷責任人

對應缺陷的責任人：多是產品、開發、項目、測試、運維或客戶自身。

九、缺陷投入

各職能人員在缺陷上的投入，包含產品、研發、測試、運維等。

2、缺陷分析維度

上述缺陷因子中，單一因子的分析，這裏就很少介紹，使用中直接使用餅圖分析便可。

重點從多因子組合的狀況有哪些維度能夠分析統計。

一、缺陷等級

二、缺陷等級&缺陷責任人

根毫不同缺陷等級進行預設分數，結合缺陷責任人產生缺陷的數量進行分數評估。

對項目組各成員對產品質量的「貢獻」，有數據上的評判--可參考。

三、缺陷等級&缺陷產生模塊&缺陷修復率

根毫不同缺陷等級進行預設分數，結合對用模塊產生缺陷的數量進行分數評估。

對項目各功能模塊質量有一個量化的認識，便於針對性的開展質量改進與分析總結。

各模塊缺陷等級分佈

四、缺陷產生模塊&缺陷類型

分析模塊缺陷數量以及對應什麼問題類型較多，便於後續版本或項目有意識規避相似問題，引發相關人員的重視。

 五、缺陷等級&缺陷產生階段

分析各階段不一樣等級缺陷分佈狀況。

 

六、缺陷產生階段&缺陷等級&缺陷投入

在缺陷產生階段及缺陷等級的基礎上延伸，能夠統計各階段在缺陷上的消耗。

3、總結

上述的因子還能夠擴充，缺陷的應用分析也還有不少維度，不侷限與上述列到的內容。

缺陷分析與度量工做是一個須要積累的過程，最終的目的仍是經過不一樣維度不一樣圖表的分析，更多量化的來評判軟件的質量。

從而幫助項目成員認識到問題，並在後續版本迭代或新項目中有序規避。