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

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

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

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

從缺陷的根本原因上分析

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

文檔問題

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

程序代碼問題

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

需求分析不全

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

需求變更

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

環(huán)境問題

部署操作不正確；

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

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

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

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

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

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

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

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

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

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

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

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

冒煙測試：只對項(xiàng)目或是版本做主流程的驗(yàn)證。

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

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

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

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

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

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

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

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

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

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

從測試漏檢上分析

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

總結(jié)

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

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

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