測出Bug就完了？教你從4個方面分析缺陷

測試團隊在項目或版本測試完成后，需要對本次項目或版本所發現的缺陷做統計分析，在分析的過程中，總結項目或版本在哪些方面可以進行改進，為下個項目或版本的管理，做更好的管理和風險預防。

分析缺陷一般從以下角度來進行：

以某個項目為例，此項目共涉及6個關聯系統，整個項目周期，發現的缺陷數共508個（缺陷數已按等級進行換算）。下面從各方面分析缺陷的分布情況。

從缺陷的根本原因上分析

上表中，根本原因中，各項內容的含義如下：

文檔問題

指的是在靜態測試（包括文檔的正式及非正式評審）時，測試人員發現的各類文檔的問題，投產手冊的問題。

程序代碼問題

程序存在各種的代碼問題，程序未按需求功能實現等。

需求分析不全

需求分析不全面導致的部分場景或功能未實現。

需求變更

由于出現缺陷，導致需求需要變更。

環境問題

部署操作不正確；

參數設置沒按投產手冊要求執行；

控版出錯（含：未與生產同步、未與上一個版本同步等）。

數據質量問題

不符合需求的測試數據，測試中產生的臟數據。

項目組的問題由程序代碼問題、需求分析不全和文檔問題組成。

其中，程序代碼問題的占比是最高的，程序代碼問題表現在：一是程序員在編碼時只考慮正常場景的情況，一些異常和特殊的場景的情況都沒考慮到；二是修改一個缺陷后，引出另外的缺陷。

需求分析不全、和文檔問題，加起來占比6.7%，從另一方面說明項目組不重視文檔及文檔質量，對功能分析不透徹。

從以上可以看出，項目組需要加強文檔編寫質量、需求的充分評審和代碼評審及走查。測試交付團隊方面的問題，數據質量問題和環境的問題共占比9.8%，數據質量問題單項占到6.3%，這個比例偏高，測試團隊應該管理好測試數據的質量，以免由于不合規的數據浪費大家的時間和精力。

環境問題，交付團隊應該在項目或是版本開始時，測試環境的配置與生產環境的配置一致，以保證測試版本的有效性，在部署時，需要與測試團隊先做溝通，避免一些沒有必要的環境問題。

從缺陷發現的階段分析

測試分析階段處于測試人員對需求文檔、概要設計文檔的評審（評審包括文檔的測試和評審會），這個階段的缺陷數，主要由文檔問題、評審問題組成。

測試執行階段包括冒煙測試、第一輪、第二輪和回歸測試。在這個階段，測試團隊對整個項目或是版本做全面的測試，用各種測試方法來驗證項目或版本是否符合上線標準。

冒煙測試：只對項目或是版本做主流程的驗證。

第一輪、第二輪測試，是執行所有的測試用例，對所有的功能做全面的驗證，測試類型包括了功能測試、性能測試、可靠性測試、安全性測試、接口測試等等。

回歸測試是對項目或是版本做全面的回歸測試，包括第一或第二輪測試過程中，本來測試通過的用例，再加上此次未改造的功能。

補丁測試，指的是在項目或版本已經定版后，仍存在非改不可的，影響流程性的缺陷。

各個階段出現的缺陷數量，也可以分析項目組或是測試團隊在哪個階段是否有問題。

從缺陷的引入系統上分析

缺陷數已按等級進行換算：

系統2和系統3的改造量排名第一和第二，難道就證明了改造量大的，出的缺陷就多嗎？

也不是，像系統4的改造量只是比系統3少了10%，但缺陷數卻少了3分之一。

雖然系統與系統之間的缺陷沒有什么可比性，但如果加上各個系統的開發工作量，計算出各個系統的缺陷密度，雖然可比性的不大，但是以整體來看項目組的程序質量來說，這樣子有一定的可比性了。

缺陷密度以1為基準，缺陷密度高于1的系統，可能需要分析一下程序的質量，看問題出在哪里。

從測試漏檢上分析

此次項目上線運行一個月內，生產上出現的故障數量如上表所示。從上面可以看出，測試團隊在漏檢的問題上占了3個，是總故障數量的一半，且測試分析遺漏一個，用例遺漏一個，而執行還遺漏了一個，這說明測試團隊的內部存在流程或溝通的問題。需要測試團隊進行分析具體的原因。

總結

以上從各個方面來分析項目或版本的缺陷，都是希望從各種渠道來了解項目組和測試團隊的情況，分析是否他們存在內部規范或是流程上的問題，需在哪一方面做進一步改進措施。

除此之外，還能收集各團隊的項目指標，與公司的基準數據做對比，看是否與之相匹配，是否存在改進的方面，能以更好的姿態去迎接下一次挑戰。

最后：在我的V ：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯網程序原理、Mysql數據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續集成、測試架構開發測試框架、性能測試、安全測試等。