缺陷分析：缺陷漏斗模型 | 讓一個缺陷都不能漏
「缺陷分析主要不是解決缺陷，而是防止缺陷的再次發生。正如我們應該提高自身身體素質，防止生病，而不僅僅是治病。」
做缺陷分析需要投入不少的人力和時間，所以在缺陷分析之前首先我們必須明確我們為什麼要做缺陷分析，缺陷分析能給我們帶來什麼。是效率的提升還是開發質量的提高。
接下來我們要確定缺陷分析的粒度，如果粒度太大，無法分析出具體有用的結果，如果粒度太小，投入的人力時間太多，與最終得到的成效相比，代價過大。
缺陷分析主要不是解決缺陷，而是防止缺陷的再次發生。正如我們應該提高自身身體素質，防止生病，而不僅僅是治病。
進行缺陷分析首先我們要從缺陷的來源下手。
來源主要分成兩類：
1.產品釋出以後的缺陷
資料：產品釋出以後的缺陷主要來源於使用者報的問題，當然也有一部分是自己內部員工釋出的問題，可以是產品經理，測試，開發或者其他的員工。
目的：分析這部分缺陷能讓我們知道我們測試工作中的不足，找到相關的原因，提高測試工作的質量。同時，可以發現使用者遇到的問題，在之後的開發工作中避免這種問題再次出現，提升使用者體驗。
指標：計算出平均修復時間指標，知道我們維護階段處理缺陷的效率。提高效率，提升使用者的滿意度。
2.產品釋出之前的缺陷
資料：產品釋出之前的缺陷主要來源是測試開的bug。
目的：分析這部分的缺陷，能發現需求上描述不清楚或者不合理的地方，編碼容易出錯的地方，流程上不合理需要改進的地方，軟體薄弱的地方等。我們逐個擊破，提高整個開發團隊的素質。
指標：同時通過缺陷分析，計算出缺陷指標，評估風險以及開發階段軟體的質量和需要的工期。
下面我們要重點介紹的缺陷分類方法叫漏斗模型缺陷分析法。
模型從上到下是一個逐漸縮小的過程，讓我們從一開始的缺陷到最後找到導致這個缺陷的部門和生產過程，以便有針對性的進行改進。
模型從右到左是生產的反向過程，在右邊的生產活動如果缺陷過多，就會掩蓋掉其左邊的生產活動，我們必須先解決掉右邊活動存在的問題，減少它產生的缺陷，這樣才能看到模型左邊的生產活動存在的問題。
模型如下圖，綠色的是缺陷的分類，藍色的是生產活動，紅色的是對應的責任職位。
我們如何利用這個模型進行分類呢。可以分為以下幾步。
1.對缺陷進行分類
把所有的缺陷按照模型的最上面一層進行分類。如果是老的缺陷，那會比較麻煩，需要重新分析老的缺陷，然後給老的缺陷分類。如果打算忽略老的缺陷，直接在之後的缺陷裡進行統計，那可以直接在建立缺陷的時候加入一欄“缺陷類別”，而類別就是模型裡的第一層，之後的統計中就會方便很多。
2.計算出每個類別的缺陷數目，然後對應到生產活動。
我們的生產活動主要有：
-- 編寫需求
-- 理解需求
-- 系統設計
-- 編碼
-- 設計測試用例
-- 功能測試
-- 迴歸測試
-- 效能測試
-- 實施
然後按照缺陷個數的高低進行分析每一個生產行為，分析產生缺陷的原因，是因為人還是因為制度還是因為流程。然後進行相應的改進。
以我目前的一個專案來舉例，首先我提取了最近一個月釋出前的缺陷。（這裡主要的是，缺陷數目越多，能發現的問題更多，也更具有代表性。我這裡取一個月的缺陷，只是為了說明，因為資料量太小實際參考效果不佳。）
先根據缺陷類別統計每一個類別的缺陷個數，然後對應到生產活動。
我們發現排名第一的是編碼，第二的是需求，需求產生的缺陷個數居然有29個，佔比32.6%。需求的缺陷佔比如此之高是不太常見的。
從另一方面來說如果解決了需求這一塊存在的問題，在效率的提高和產品質量的提高上會有很大的幫助。一般如果是由於需求導致的缺陷，如果找到原因並且採取有效措施後會比較容易在以後的工作中避免。
那我們來具體分析下為什麼會有這麼多需求的缺陷。需求缺陷中，其中主要的問題是需求描述不清楚，其次是多語言翻譯，最後是使用者體驗。
需求為什麼會描述不清楚，一是因為產品人員沒有真正理解產品，很多情況沒有考慮全面。 二是描述語言不夠清晰，邏輯不夠清楚。三是業務上沒弄清楚真正需要的是什麼。對於第一點，一方面產品人員要加強對於自身產品的理解，測試人員也可以在這方面給產品人員把關，儘量保證需求考慮足夠全面。 對於第二點，產品人員在寫需求的時候儘量理清思路再寫。對於第三點，這一點比較難，需要產品人員多提升專業知識。
對於多語言翻譯，一開始產品人員就應該明確哪些語句需要支援多語言，並且列在一個表裡，保證他們都翻譯了。而不是通過測試，發現問題，報告缺陷，然後解決，再去驗證。這樣對於測試資源是一張浪費，特別是在測試資源緊缺的時候，更是雪上加霜。
對於使用者體驗方面，希望產品人員多提升在使用者體驗方面的認知，在設計產品的時候時刻注意，不能是一拍腦門做決定。
總結下來。對於需求產品的缺陷，只要產品人員在平時工作中多加註意，相信這一方面的缺陷會少很多。整個組的效率也會提升很多。
接下來我們來分析下編碼導致的缺陷，編碼導致的缺陷中佔比比較大的是，邏輯錯誤，遺漏功能，和不同組直接的依賴。這裡面我們能努力的方面是遺漏功能和不同組之間的依賴。
遺漏功能一方面是對於需求沒有了解清楚，另一方面是沒有考慮全面，比如特殊的資料處理，特殊場景的處理等。改進的方向是，在做之前確認自己是否真的理解了需求，還有就是積極參加測試用例評審大會，聽一聽測試人員的測試用例，看自己有什麼遺漏的地方。 另外就是自己整理一份特殊資料，特殊場景的情況，每次做到有關的內容的時候，都提醒下自己是否考慮到了。
不同組之間的遺漏，在於組之間的不透明。對於相互影響的模組，可以考慮建立一個組之間模組依賴表，每一個組設定一個接頭人，一旦有依賴的模組發生變化了立刻通知到其他組。對於上下游的模組，每次下游測試前要和上游確認所有的需要的準備工作已經完成。
前面的這些分析都是按照缺陷個數進行的分析。當然有些缺陷個數很少，可是影響卻很惡劣，對於這種缺陷我們必須強烈避免，按照漏斗模型找到對應的生產活動對應的負責人，case by case的處理。堅決避免此類情況再次發生。
在我們日常的工作中，大家對於缺陷分析的重視度並不夠。一方面是不知道該如何利用缺陷的價值，如何進行分析，另一方面是記錄的缺陷不規範，要進行缺陷分析難度太大。
我所處的專案組由於業務多，時間上緊，所以大家都很忙很累，大家都意識到流程上業務上存在問題，可是卻無法知道具體問題出在哪裡，如何改進，更沒有資料可以用來說服老闆或者其他人進行改變。直到某天我意識到，缺陷就是開發過程的產物，它最能說明我們的開發過程到底存在什麼問題，然後我就開始進行缺陷分析，不過一開始沒想好從哪個維度入手，也不清楚缺陷該如何分類，分類的粒度應該多大。
於是慢慢的嘗試，最終整理出來的漏斗模型裡面列的那些分類，因為整個圖很像漏斗加上分析的過程就像用漏斗一樣，一遍遍的過濾資訊，最終找到根本問題，所以我把它叫做漏斗模型。希望大家能從我這篇文章中得到幫助
如何學習？學習沒有資料？請關注本公眾號，回覆「M」試試，獲得更多視訊資料和入群資格。
【宣告】：上文為本站編輯轉載，文章版權歸原作者所有。文章內容為作者個人觀點，本站只提供轉載參考，目的在於傳遞更多專業資訊，普惠測試相關從業者，開源分享，推動行業交流和進步。如涉及作品內容、版權和其它問題，請原作者及時與本站聯絡，我們將第一時間進行處理。本站擁有對此宣告的最終解釋權！