做缺陷分析需要投入不少的人力和時間，所以在缺陷分析之前首先我們必須明確我們?yōu)槭裁匆鋈毕莘治鋈榉幔毕莘治瞿芙o我們帶來什么泌参。是效率的提升還是開發(fā)質(zhì)量的提高。

接下來我們要確定缺陷分析的粒度巾钉，如果粒度太大，無法分析出具體有用的結(jié)果秘案，如果粒度太小砰苍，投入的人力時間太多，與最終得到的成效相比阱高，代價過大赚导。

缺陷分析主要不是解決缺陷，而是防止缺陷的再次發(fā)生赤惊。正如我們應(yīng)該提高自身身體素質(zhì)辟癌，防止生病，而不僅僅是治病荐捻。

進行缺陷分析首先我們要從缺陷的來源下手，來源主要分成兩類：

1.產(chǎn)品發(fā)布以后的缺陷

數(shù)據(jù)：產(chǎn)品發(fā)布以后的缺陷主要來源于用戶報的問題寡夹，當然也有一部分是自己內(nèi)部員工發(fā)布的問題处面，可以是產(chǎn)品經(jīng)理，測試菩掏，開發(fā)或者其他的員工魂角。

目的：分析這部分缺陷能讓我們知道我們測試工作中的不足，找到相關(guān)的原因智绸，提高測試工作的質(zhì)量野揪。同時访忿，可以發(fā)現(xiàn)用戶遇到的問題，在之后的開發(fā)工作中避免這種問題再次出現(xiàn)斯稳，提升用戶體驗海铆。

指標：計算出平均修復(fù)時間指標，知道我們維護階段處理缺陷的效率挣惰。提高效率卧斟，提升用戶的滿意度。

2.產(chǎn)品發(fā)布之前的缺陷

數(shù)據(jù)：產(chǎn)品發(fā)布之前的缺陷主要來源是測試開的bug憎茂。

目的：分析這部分的缺陷珍语，能發(fā)現(xiàn)需求上描述不清楚或者不合理的地方，編碼容易出錯的地方竖幔，流程上不合理需要改進的地方板乙，軟件薄弱的地方等。我們逐個擊破拳氢，提高整個開發(fā)團隊的素質(zhì)募逞。

指標：同時通過缺陷分析，計算出缺陷指標饿幅，評估風險以及開發(fā)階段軟件的質(zhì)量和需要的工期凡辱。

下面我們要重點介紹的缺陷分類方法叫漏斗模型缺陷分析法。模型從上到下是一個逐漸縮小的過程栗恩，讓我們從一開始的缺陷到最后找到導(dǎo)致這個缺陷的部門和生產(chǎn)過程透乾，以便有針對性的進行改進。

模型從右到左是生產(chǎn)的反向過程磕秤，在右邊的生產(chǎn)活動如果缺陷過多乳乌，就會掩蓋掉其左邊的生產(chǎn)活動，我們必須先解決掉右邊活動存在的問題市咆，減少它產(chǎn)生的缺陷汉操，這樣才能看到模型左邊的生產(chǎn)活動存在的問題。 模型如下圖蒙兰，綠色的是缺陷的分類磷瘤，藍色的是生產(chǎn)活動，紅色的是對應(yīng)的責任職位搜变。

我們?nèi)绾卫眠@個模型進行分類呢采缚。可以分為以下幾步挠他。

1.對缺陷進行分類

把所有的缺陷按照模型的最上面一層進行分類扳抽。如果是老的缺陷，那會比較麻煩，需要重新分析老的缺陷贸呢，然后給老的缺陷分類镰烧。如果打算忽略老的缺陷，直接在之后的缺陷里進行統(tǒng)計楞陷，那可以直接在創(chuàng)建缺陷的時候加入一欄“缺陷類別”怔鳖，而類別就是模型里的第一層，之后的統(tǒng)計中就會方便很多猜谚。

2.計算出每個類別的缺陷數(shù)目败砂，然后對應(yīng)到生產(chǎn)活動。

我們的生產(chǎn)活動主要有：

-- 編寫需求

-- 理解需求

-- 系統(tǒng)設(shè)計

-- 編碼

-- 設(shè)計測試用例

-- 功能測試

-- 回歸測試

-- 性能測試

-- 實施

然后按照缺陷個數(shù)的高低進行分析每一個生產(chǎn)行為魏铅，分析產(chǎn)生缺陷的原因昌犹，是因為人還是因為制度還是因為流程。然后進行相應(yīng)的改進览芳。

以我目前的一個項目來舉例斜姥，首先我提取了最近一個月發(fā)布前的缺陷。（這里主要的是沧竟，缺陷數(shù)目越多铸敏，能發(fā)現(xiàn)的問題更多，也更具有代表性悟泵。我這里取一個月的缺陷杈笔，只是為了說明，因為數(shù)據(jù)量太小實際參考效果不佳糕非。）

先根據(jù)缺陷類別統(tǒng)計每一個類別的缺陷個數(shù)蒙具，然后對應(yīng)到生產(chǎn)活動。我們發(fā)現(xiàn)排名第一的是編碼朽肥，第二的是需求禁筏，需求產(chǎn)生的缺陷個數(shù)居然有29個，占比32.6%衡招。需求的缺陷占比如此之高是不太常見的篱昔。從另一方面來說如果解決了需求這一塊存在的問題，在效率的提高和產(chǎn)品質(zhì)量的提高上會有很大的幫助始腾。一般如果是由于需求導(dǎo)致的缺陷州刽，如果找到原因并且采取有效措施后會比較容易在以后的工作中避免。

那我們來具體分析下為什么會有這么多需求的缺陷浪箭。需求缺陷中穗椅，其中主要的問題是需求描述不清楚，其次是多語言翻譯山林，最后是用戶體驗。?

需求為什么會描述不清楚，一是因為產(chǎn)品人員沒有真正理解產(chǎn)品驼抹，很多情況沒有考慮全面桑孩。 二是描述語言不夠清晰，邏輯不夠清楚框冀。三是業(yè)務(wù)上沒弄清楚真正需要的是什么流椒。對于第一點，一方面產(chǎn)品人員要加強對于自身產(chǎn)品的理解明也，測試人員也可以在這方面給產(chǎn)品人員把關(guān)宣虾，盡量保證需求考慮足夠全面。 對于第二點温数，產(chǎn)品人員在寫需求的時候盡量理清思路再寫绣硝。對于第三點，這一點比較難撑刺，需要產(chǎn)品人員多提升專業(yè)知識鹉胖。?

對于多語言翻譯，一開始產(chǎn)品人員就應(yīng)該明確哪些語句需要支持多語言够傍，并且列在一個表里甫菠，保證他們都翻譯了。而不是通過測試冕屯，發(fā)現(xiàn)問題寂诱，報告缺陷，然后解決安聘，再去驗證痰洒。這樣對于測試資源是一張浪費，特別是在測試資源緊缺的時候搞挣，更是雪上加霜带迟。

對于用戶體驗方面，希望產(chǎn)品人員多提升在用戶體驗方面的認知囱桨，在設(shè)計產(chǎn)品的時候時刻注意仓犬，不能是一拍腦門做決定。

總結(jié)下來舍肠。對于需求產(chǎn)品的缺陷搀继，只要產(chǎn)品人員在平時工作中多加注意，相信這一方面的缺陷會少很多翠语。整個組的效率也會提升很多叽躯。

接下來我們來分析下編碼導(dǎo)致的缺陷，編碼導(dǎo)致的缺陷中占比比較大的是肌括，邏輯錯誤点骑，遺漏功能，和不同組直接的依賴。這里面我們能努力的方面是遺漏功能和不同組之間的依賴黑滴。

遺漏功能一方面是對于需求沒有了解清楚憨募，另一方面是沒有考慮全面，比如特殊的數(shù)據(jù)處理袁辈，特殊場景的處理等菜谣。改進的方向是，在做之前確認自己是否真的理解了需求晚缩，還有就是積極參加測試用例評審大會尾膊，聽一聽測試人員的測試用例，看自己有什么遺漏的地方荞彼。 另外就是自己整理一份特殊數(shù)據(jù)冈敛，特殊場景的情況，每次做到有關(guān)的內(nèi)容的時候卿泽，都提醒下自己是否考慮到了莺债。

不同組之間的遺漏，在于組之間的不透明签夭。對于相互影響的模塊齐邦，可以考慮創(chuàng)建一個組之間模塊依賴表，每一個組設(shè)置一個接頭人第租，一旦有依賴的模塊發(fā)生變化了立刻通知到其他組措拇。對于上下游的模塊，每次下游測試前要和上游確認所有的需要的準備工作已經(jīng)完成慎宾。

前面的這些分析都是按照缺陷個數(shù)進行的分析丐吓。當然有些缺陷個數(shù)很少，可是影響卻很惡劣趟据，對于這種缺陷我們必須強烈避免券犁，按照漏斗模型找到對應(yīng)的生產(chǎn)活動對應(yīng)的負責人，case by case的處理汹碱。堅決避免此類情況再次發(fā)生粘衬。

在我們?nèi)粘５墓ぷ髦校蠹覍τ谌毕莘治龅闹匾暥炔⒉粔蚩却佟Ｒ环矫媸遣恢涝撊绾卫萌毕莸膬r值稚新，如何進行分析，另一方面是記錄的缺陷不規(guī)范跪腹，要進行缺陷分析難度太大褂删。我所處的項目組由于業(yè)務(wù)多，時間上緊冲茸，所以大家都很忙很累屯阀，大家都意識到流程上業(yè)務(wù)上存在問題缅帘，可是卻無法知道具體問題出在哪里，如何改進难衰，更沒有數(shù)據(jù)可以用來說服老板或者其他人進行改變股毫。直到某天我意識到，缺陷就是開發(fā)過程的產(chǎn)物召衔，它最能說明我們的開發(fā)過程到底存在什么問題，然后我就開始進行缺陷分析祭陷，不過一開始沒想好從哪個維度入手苍凛，也不清楚缺陷該如何分類，分類的粒度應(yīng)該多大兵志。于是慢慢的嘗試醇蝴，最終整理出來的漏斗模型里面列的那些分類，因為整個圖很像漏斗加上分析的過程就像用漏斗一樣想罕，一遍遍的過濾信息悠栓，最終找到根本問題，所以我把它叫做漏斗模型按价。希望大家能從我這篇文章中得到幫助惭适。