作者 | 常雨桐

在軟件開發(fā)交付過程中，難免會出現(xiàn)Bug。針對每一個已發(fā)現(xiàn)問題的Bug，完成修復工作后，我們可以對其進行全面的根本原因分析。本文從測試人員的角度，嘗試梳理出一些常見的Bug根本原因分析的維度，并列舉每個維度中的根本原因的例子。

一、Bug分析的維度

建議盡量用便于統(tǒng)計和維護的方式，記錄分析的結果(比如使用Jira系統(tǒng)提供的label功能，下文中括號內(nèi)的英文是可參考的label名稱)，以便周期性地進行全面的Bug分析。

每個Bug常見的可用于分析的根因維度如下：

1.Bug發(fā)現(xiàn)的環(huán)境 (Env)

(1) 維度定義：

描述該Bug是在什么環(huán)境中被測試人員/開發(fā)團隊成員/客戶/用戶發(fā)現(xiàn)的。

(2) 分析目的：

正常來講軟件開發(fā)過程中，越早發(fā)現(xiàn)問題，修復問題所需要的成本也就越小。為此，需要關注開發(fā)過程中的問題是否可以在早期被發(fā)現(xiàn)。

分析此維度可以評估現(xiàn)在項目的Bug發(fā)現(xiàn)時機。制定針對性的改進措施，以保證Bug可以被盡早發(fā)現(xiàn)。

(3) 維度示例：

各個項目所擁有的測試環(huán)境并不相同，請根據(jù)實際情況來進行分類。

• 開發(fā)環(huán)境/測試環(huán)境 (參考Label名：Env_QA / Env_DEV) 。項目人員最常接觸的環(huán)境，也是鏈條最前端的環(huán)境。大部分的Bug應該在此被發(fā)現(xiàn)。
• 集成環(huán)境(Env_Integration) 。常用于連接到外部或其他團隊系統(tǒng)的環(huán)境，容易發(fā)現(xiàn)外部集成相關的Bug。
• 用戶驗收環(huán)境 / 預發(fā)布環(huán)境(Env_UAT / Env_Pre-release / Env_Rehearsal) 。客戶對交付的系統(tǒng)做驗收測試或上線前演練/回歸用的環(huán)境，數(shù)據(jù)和環(huán)境配置都會更貼近生產(chǎn)環(huán)境。
• 生產(chǎn)環(huán)境 (Env_Production) 。真正提供給線上用戶的環(huán)境，生產(chǎn)環(huán)境發(fā)現(xiàn)的Bug擁有較高的處理優(yōu)先級。

2.Bug引入時機 (Timing)

(1) 維度定義： 

描述引發(fā)該Bug的代碼/配置是在什么時機或者什么活動中被引入到產(chǎn)品中的。

(2) 分析目的：

通過分析Bug的引入時機，有機會識別出質量保證體系中薄弱的點，或團隊在開發(fā)/測試流程中的問題。

(3) 維度示例：

常見的引入時機如下：

• 開發(fā)新需求時產(chǎn)生的新功能的Bug（Timing_Developing_New_Requirement）。在開發(fā)新功能時，產(chǎn)生的新功能中的行為與需求不符的問題。
• 開發(fā)新需求時破壞原有功能 (Timing_Developing_Other_Requirement) 。在開發(fā)新功能時，破壞了原有的已驗收過的功能的正確行為。
• 修復Bug破壞原有功能（Timing_Fix_Bug）。在修復其他Bug時，引入了新Bug。
• 重構破壞原有功能（Timing_Refoctor）。在對代碼進行重構的過程中，導致原有功能被破壞。雖然正常來講重構活動是會在開發(fā)新卡時一起進行，理應分在開發(fā)新功能時機，但是考慮到重構行為的特殊性，以及為了后期分析重構時是否有足夠的自動化測試保證原功能正常工作?？梢砸暻闆r把重構單獨作為一個引入時機進行分析。
• 前人代碼遺留的Bug（Timing_Legacy_Issue）。中途接手的項目，在團隊入場前就存在的問題。或者超出目前項目預期范圍的原有問題。一般PM會更加關注此類問題，以防團隊為遺留問題花費太多effort，影響正常工作的展開和新需求的交付進度。
• 部署環(huán)境或運行腳本（Timing_Env_Deployment_or_Script）。在部署/配置環(huán)境過程中引發(fā)的問題，或直接操作數(shù)據(jù)庫數(shù)據(jù)引發(fā)的問題。
• 不屬于Bug(Timing_Not_Bug) 。有時會發(fā)現(xiàn)該問題不屬于Bug，本文后面會詳細敘述這種情況。

3.Bug所屬的前后端/微服務/功能模塊

(1) 維度定義：

描述該Bug的代碼問題出現(xiàn)在前后端/微服務/功能模塊。

(2) 分析目的：

統(tǒng)計前后端/微服務/功能模塊的Bug比例分布，后續(xù)可以有針對性地進行補充自動化測試及分配測試資源。

(3) 維度示例：

各個項目所擁有的前后端并不相同，可以根據(jù)實際情況來進行分類。

4.Bug產(chǎn)生的直接代碼原因 (Root Cause)

(1) 維度定義：

描述引發(fā)該Bug的代碼的問題，可以與開發(fā)人員合作來分析。

(2) 分析目的：

結合下一個維度，評估團隊人員上下文以及技術的掌握情況。通過進行session/文檔同步上下文的方式進行查漏補缺。

(3) 維度示例：

• 代碼業(yè)務邏輯錯誤 (RC_wrong_bussiness_logic) 。代碼實現(xiàn)時對業(yè)務的錯誤理解或者遺漏，導致了代碼邏輯跟業(yè)務邏輯不一致。
• 代碼邊界條件/Edge case未覆蓋 (RC_uncovered_edge_case) 。代碼實現(xiàn)時遺漏了某些業(yè)務場景/遺漏了對某些接口或函數(shù)的特殊返回值的處理。
• 框架或依賴功能/接口的錯誤使用 (RC_wrongly_use_dependency)。代碼實現(xiàn)時使用了現(xiàn)有的函數(shù)，或者其他微服務提供的接口。但是對其 業(yè)務含義/調用方法/返回處理 理解有誤導致的問題。
• 踩了使用的框架或依賴的原有的坑/技術債 (RC_dependency_original_issue) 。受到原有的代碼或系統(tǒng)的設計問題影響，所產(chǎn)生的Bug。
• 代碼/腳本實現(xiàn)錯誤 (RC_wrong_coding) 。單純的代碼寫錯了，比如對于函數(shù)的誤用，或者寫代碼時的手誤。
• 環(huán)境，設施，數(shù)據(jù)庫配置問題 (RC_misconfiguration) 。環(huán)境/基礎設施/數(shù)據(jù)庫 的參數(shù)配置錯誤引發(fā)的問題。
• 前后端接口協(xié)議不一致 (RC_FE&BE_protocol_not_match)
• 前端排版顯示問題 (RC_UI_display_issue)
• 兼容性 (RC_compatibility) 。未覆蓋不同操作系統(tǒng)/不同設備/不同客戶端/不同窗體大小的差異，引發(fā)的問題。
• 非功能性需求 - 性能問題 (RC_performance)
• 非功能性需求 - 安全問題 (RC_security)
• 非功能性需求 - 健壯性問題 (RC_robust) 。連續(xù)點擊，并行，弱網(wǎng)等情況引發(fā)的問題。
• 技術架構升級 (RC_tech_upgrade) 。依賴的包或框架升級版本引發(fā)的問題。

5.Bug產(chǎn)生的人員原因 (Reason)

(1) 維度定義：

描述寫出Bug代碼的原因。

(2) 分析目的：

結合上一個維度，評估團隊人員上下文以及技術的掌握情況。通過進行session/文檔同步上下文的方式進行查漏補缺。

當分析涉及具體人員的原因時，對應人員可能害怕被追責，會不自然地產(chǎn)生抵抗心理。所以在我們分析人維度的根因的時候，側重點應該是團隊對于上下文的掌握情況，而不是某個成員的個體原因，為團隊成員建立有安全感的氛圍，這樣才能保證此維度的分析能持續(xù)進行下去。

(3) 維度示例：

• 需求中業(yè)務需求不夠明確 (Reason_uncovered_detail_in_requirement) 。需求的某些部分可能沒有清晰地表述出期望的過程和結果，在開發(fā)的流程中，開發(fā)人員對于該部分內(nèi)容團隊各個成員也沒有識別到該問題。導致最終驗收時，實現(xiàn)的內(nèi)容與客戶/業(yè)務分析人員預先期望(或者說直覺性的期望，因為可能寫需求的時候就沒想到這部分內(nèi)容)的內(nèi)容不同。
• 需求業(yè)務理解錯誤 (Reason_requirement_misunderstanding) 。開發(fā)人員對于需求的業(yè)務場景理解與實際業(yè)務有偏差導致的問題。
• 未考慮到邊緣用例 (Reason_unconsidered_case) 。開發(fā)時未考慮到處理某些邊界值或者邊緣場景導致的問題。
• 業(yè)務上下文缺失 (Reason_not_familiar_with_business_context) 。團隊成員對于需求相關的系統(tǒng)業(yè)務上下文的了解不夠全面，導致的問題。比如對于接口的業(yè)務價值不了解，從而導致接口返回錯誤的結果。
• 代碼實現(xiàn)上下文缺失 (Reason_not_familiar_with_code_context) 。團隊成員對于需求相關的現(xiàn)有系統(tǒng)代碼結構的了解不夠全面，導致的問題。比如更改現(xiàn)有代碼時，漏掉了某個不熟悉的模塊中的部分相關代碼。
• 對于依賴的接口/工具細節(jié)不了解 (Reason_not_familiar_with_dependency) 。對應Root cause中的“框架或依賴功能/接口的錯誤使用”。
• 開發(fā)過程中的疏忽 (Reason_negligence) 。單純的開發(fā)過程中的疏忽。

未考慮到系統(tǒng)健壯性或其他非功能性需求 (Reason_unconsidered_non_functional_requirements)

6.自動化測試覆蓋情況 (Original Automation Test)

(1) 維度定義：

描述該Bug相關的代碼的自動化測試情況，自動化測試代碼為何沒有發(fā)現(xiàn)該Bug。包括單元/接口/端到端測試。

(2) 分析目的：

適當?shù)淖詣踊瘻y試覆蓋與適當?shù)倪\行頻率可以極大地提高問題代碼的反饋效率，所以此維度可以用于識別系統(tǒng)自動化覆蓋的情況。識別出自動化測試薄弱的功能/微服務后可以單抽時間對其補充必要的自動化測試。

(3) 維度示例：

• 功能沒寫測試(OT_none) 。因為effort或其他原因，單純地沒寫測試。
• 寫了測試但是沒有覆蓋到邊界情況(OT_not_cover_edge_case) 。寫了功能對應的測試，但是未覆蓋到某些邊界情況。
• 測試數(shù)據(jù)跟實際數(shù)據(jù)不符(OT_data_mismatch_reality) 。寫了功能對應的測試，但是所構造的數(shù)據(jù)與業(yè)務的正常數(shù)據(jù)不同，導致沒有發(fā)現(xiàn)問題。
• 重構改動過大，原有測試無法繼續(xù)使用(OT_remove_by_refactor) 。重構改動過大，導致原有功能已有的測試無法繼續(xù)使用。同時重構后的新的測試代碼覆蓋不全。
• 測試技術/框架所限無法覆蓋(OT_none_tech_limited) 。因技術/框架原因，寫自動化測試的effort過大，或者無法實現(xiàn)自動化測試。
• 測試代碼錯誤(OT_wrong_logic) 。單純地測試代碼錯誤導致未識別到Bug。

7.發(fā)現(xiàn)的問題不屬于Bug的場景(Timing_not_bug)

有時我們最終發(fā)現(xiàn)看到的問題不屬于系統(tǒng)的Bug，我們可以把這種情況單獨分作一類進行分析其出現(xiàn)的原因(Root Cause維度)。

當某種原因出現(xiàn)頻率過高的時候，我們也需要采取對應的行動去減少此類的問題的出現(xiàn)，以防在大量的調查處理工作中浪費QA及團隊其他成員的時間。

示例：

• 臟數(shù)據(jù) (RC_dirty_data) 。存在于測試環(huán)境的臟數(shù)據(jù)導致的問題，常見的臟數(shù)據(jù)的來源可能是未完全開發(fā)完成的代碼，團隊成員對于數(shù)據(jù)庫數(shù)據(jù)的手動更新或插入。一般發(fā)現(xiàn)是臟數(shù)據(jù)導致的問題時，需要追查臟數(shù)據(jù)的來源。如果來源是現(xiàn)有代碼，則需要單獨建Bug處理創(chuàng)造臟數(shù)據(jù)的代碼問題。
• 新需求 (RC_new_requirement) 。Bug所期望的系統(tǒng)行為并不屬于任何的需求中所約定的開發(fā)內(nèi)容，需要新建卡來進行交付。
• 需求問題(需求錯誤、遺漏) (RC_requirement) 。Bug所提及的內(nèi)容與需求中所約定的開發(fā)內(nèi)容一致，但是與實際業(yè)務不符，需要新建卡來進行修正。
• 無法重現(xiàn) (RC_cant_reproduce) 。無法重現(xiàn)Bug所描述的問題，可能是瞬時的環(huán)境問題，或問題已經(jīng)被無意中修復。
• 基礎設施問題 (RC_unstable_env) 。由于基礎設施無法工作導致的問題，比如環(huán)境/數(shù)據(jù)庫無法訪問。
• 外部系統(tǒng)不穩(wěn)定 (RC_unstable_external_system) 。由于外部系統(tǒng)停止工作或者無法連接導致的問題。
• 依賴的卡未完成開發(fā) (RC_dependent_story_unfinished) 。Bug所描述功能的相關卡還未完全開發(fā)完成。需要開發(fā)完后再重新進行測試。
• 設計如此 (RC_by_design) 。Bug創(chuàng)建者理解有誤或不了解上下文，其實系統(tǒng)的設計與現(xiàn)有行為一致。

最后

雖然列出了這么多維度和原因，但是畢竟每個項目各有各的情況。所以在bug分析這件事上面，并沒有適用于所有項目的模板。

但是不管分析的方式及維度如何，我們做Bug分析的目標是一致的：

• 分析根因，防止未來出現(xiàn)類似Bug。
• 分析流程和質量保障，提前未來Bug被發(fā)現(xiàn)的時機，減少修復成本。
• 分析趨勢，識別項目質量風險。

所以，只要滿足上面的目標而且適合項目現(xiàn)狀的分析方式就是好的方式。

以上是我對于Bug分析維度的一些思考和歸納，歡迎大家指正或提出自己的見解。