測試團(tuán)隊在項目或版本測試完成后，需要對本次項目或版本所發(fā)現(xiàn)的缺陷做統(tǒng)計分析，在分析的過程中，總結(jié)項目或版本在哪些方面可以進(jìn)行改進(jìn)，為下個項目或版本的管理，做更好的管理和風(fēng)險預(yù)防。

分析缺陷一般從以下角度來進(jìn)行：

以某個項目為例，此項目共涉及6個關(guān)聯(lián)系統(tǒng)，整個項目周期，發(fā)現(xiàn)的缺陷數(shù)共508個（缺陷數(shù)已按等級進(jìn)行換算）。下面從各方面分析缺陷的分布情況。

從缺陷的根本原因上分析

上表中，根本原因中，各項內(nèi)容的含義如下：

文檔問題

指的是在靜態(tài)測試（包括文檔的正式及非正式評審）時，測試人員發(fā)現(xiàn)的各類文檔的問題，投產(chǎn)手冊的問題。

程序代碼問題

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

需求分析不全

需求分析不全面導(dǎo)致的部分場景或功能未實現(xiàn)。

需求變更

由于出現(xiàn)缺陷，導(dǎo)致需求需要變更。

環(huán)境問題

部署操作不正確；

參數(shù)設(shè)置沒按投產(chǎn)手冊要求執(zhí)行；

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

數(shù)據(jù)質(zhì)量問題

不符合需求的測試數(shù)據(jù)，測試中產(chǎn)生的臟數(shù)據(jù)。

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

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

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

從以上可以看出，項目組需要加強文檔編寫質(zhì)量、需求的充分評審和代碼評審及走查。測試交付團(tuán)隊方面的問題，數(shù)據(jù)質(zhì)量問題和環(huán)境的問題共占比9.8%，數(shù)據(jù)質(zhì)量問題單項占到6.3%，這個比例偏高，測試團(tuán)隊?wèi)?yīng)該管理好測試數(shù)據(jù)的質(zhì)量，以免由于不合規(guī)的數(shù)據(jù)浪費大家的時間和精力。

環(huán)境問題，交付團(tuán)隊?wèi)?yīng)該在項目或是版本開始時，測試環(huán)境的配置與生產(chǎn)環(huán)境的配置一致，以保證測試版本的有效性，在部署時，需要與測試團(tuán)隊先做溝通，避免一些沒有必要的環(huán)境問題。

從缺陷發(fā)現(xiàn)的階段分析

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

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

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

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

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

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

各個階段出現(xiàn)的缺陷數(shù)量，也可以分析項目組或是測試團(tuán)隊在哪個階段是否有問題。

從缺陷的引入系統(tǒng)上分析

缺陷數(shù)已按等級進(jìn)行換算：

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

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

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

缺陷密度以1為基準(zhǔn)，缺陷密度高于1的系統(tǒng)，可能需要分析一下程序的質(zhì)量，看問題出在哪里。

從測試漏檢上分析

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

總結(jié)

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

除此之外，還能收集各團(tuán)隊的項目指標(biāo)，與公司的基準(zhǔn)數(shù)據(jù)做對比，看是否與之相匹配，是否存在改進(jìn)的方面，能以更好的姿態(tài)去迎接下一次挑戰(zhàn)。

最后：在我的V ：atstudy-js，可以免費領(lǐng)取一份10G軟件測試工程師面試寶典文檔資料。以及相對應(yīng)的視頻學(xué)習(xí)教程免費分享！其中包括了有基礎(chǔ)知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進(jìn)階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構(gòu)開發(fā)測試框架、性能測試、安全測試等。