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

一現狀及場景

1、缺失bug根因分析環節

工作10年，雖然不是一線城市，也經歷過幾家公司，規模大的、規模小的都有，針對於測試行業很少有Bug根因環節，主流程基本上都是測試提交bug-開發修改-測試驗證-傳送報告，測試環節結束。

往往有下面幾個原因：

·時間壓力：在專案開發週期緊張的情況下，測試團隊可能會因時間壓力而忽略深入的BUG根源分析。解決方案：合理規劃測試時間，將足夠的時間用於分析和解決問題。

·技能和經驗不足：一些測試人員可能缺乏足夠的技能和經驗來進行深入的BUG根源分析。解決方案：提供培訓和指導，提升團隊成員的技能水平。

·溝通不暢：缺乏與開發團隊和其他相關團隊的有效溝通，可能導致問題的根本原因難以獲得。解決方案：加強跨團隊溝通，確保問題描述準確傳達。

·工具和資源不足：沒有合適的工具和資源來支援深入的BUG根源分析。解決方案：投入適當的工具和資源，提升分析效率。

·重視程度不足：一些團隊可能在BUG根源分析環節沒有足夠的重視，將其視為次要環節。解決方案：強調BUG根源分析的重要性，確保每個問題都得到適當的分析。

·缺乏流程和規範：缺乏明確的BUG根源分析流程和規範，可能導致分析過程不一致或混亂。解決方案：建立明確的分析流程和規範，確保每個團隊成員都按照標準進行分析。

·缺乏反饋機制：沒有及時的反饋機制，測試人員可能難以得知他們提出的問題的分析結果和解決方案。解決方案：建立反饋機制，確保分析結果被及時傳達給相關人員。

·忽視根本原因：有時測試團隊可能只關注問題的表面症狀，而忽視了問題的根本原因。解決方案：鼓勵團隊進行深入分析，追溯問題的根本原因。

2、適用場景

本篇內容針對系統上線後對所有相關係統進行的資料流業務測試發現的bug

針對這些線上bug進行分析彙總，大概50個左右，找到一些底層的原因及規律。

二Bug分析四步走

BUG根因分析的核心思路是要從中發現測試策略問題並及時改正，避免下次再犯同樣的問題

下面是我如何針對這50個bug進行分析的過程

記錄-》缺陷原因分析-》角色歸因-》提升方案

1、記錄環節

記錄環節也就是測試過程中發現的bug進行記錄整理到buglist中，以excel表格形式呈現，如下圖：

2、標記缺陷原因分析

增加一列：缺陷原因分析

針對每一個bug，分析根本原因，有一些自己測試過程中就已經瞭解了可以寫上，不瞭解的或者記不起的內容可以統一諮詢相關開發人員，他們是最瞭解問題的第一人。

3、針對角色歸因

查了一些分析方法，其中有魚骨圖法、Whys（5個為什麼）這兩個分析方法還可，但感覺都不太適用我們公司，初步階段不需要弄的那麼複雜，所以採用最簡單的方式主要責任人就兩類：開發和測試，所以以此為基準展開如下幾大類

開發人員：

·缺少自測

·自測不足

·系統間聯調不充分

測試人員：

·漏測

·測試人員業務理解不足

具體包括：

1）公共方法名稱重複，忘記刪除

2）生產檔案不是最新

3）透過介面調，未走實際流程

4）程式碼邏輯錯誤

5）用例不詳細

6）開發、測試業務理解不透

4、可提升方案

針對測試方面想到幾點可提升點如下：

用例詳細：

1）增加工作臺列表校驗；2）測試結果現象需描述清晰；3）功能與功能之間頁面名稱需要統一。

測試流程

1）原理--維護功能梳理表格

從需求階段到測試整個過程中一直維護這個表格，對所有疑難點梳理清晰

2）跑主流程使用全新的基礎資料環境

這次發現的一部分問題之前沒發現的原因也是我們實際測試過程中，環境都在已搭建基礎上開始，或者經過很多次測試，所以像這種聯調測試在測試環境儘量保證資料的

3）增加源資料修改流程

有幾個重要問題都是修改原始檔導致其他功能不好用

所以在寫用例時需要考慮修改資料後，接下來流程的正確性

4）redmine新增bug原因（必填項）

這個主要目的應用於平時專案中，每一個bug流程開發修改完成後點選已修改前，新增bug根因，目的其一可以對bug產生原因有跟蹤，方便測試後續統計，其二開發對自己本身技能提升也有幫助。

三總結

在寫文件前，我也猶豫了一下要不要具體分析？萬一分析完成後全是測試漏測怎麼辦，大多數都是測試原因呢？分析的不專業怎麼辦？事開頭難，奔著提升的心態，發現一個問題解決一個問題，我們才能夠成長，只要邁出這一步，重複的進行慢慢的就有了經驗。