當前位置：首頁 > 科技 > 軟件

分析Bug的維度

來源：責編：時間：2023-11-16 09:40:18 290觀看

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

作者 | 常雨桐

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

一、Bug分析的維度

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

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

1.Bug發現的環境 (Env)

(1) 維度定義：

描述該Bug是在什么環境中被測試人員/開發團隊成員/客戶/用戶發現的。

(2) 分析目的：

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

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

(3) 維度示例：

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

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

2.Bug引入時機 (Timing)

(1) 維度定義：

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

(2) 分析目的：

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

(3) 維度示例：

常見的引入時機如下：

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

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

(1) 維度定義：

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

(2) 分析目的：

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

(3) 維度示例：

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

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

(1) 維度定義：

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

(2) 分析目的：

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

(3) 維度示例：

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

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

(1) 維度定義：

描述寫出Bug代碼的原因。

(2) 分析目的：

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

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

(3) 維度示例：

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

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

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

(1) 維度定義：

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

(2) 分析目的：

適當的自動化測試覆蓋與適當的運行頻率可以極大地提高問題代碼的反饋效率，所以此維度可以用于識別系統自動化覆蓋的情況。識別出自動化測試薄弱的功能/微服務后可以單抽時間對其補充必要的自動化測試。

(3) 維度示例：

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

7.發現的問題不屬于Bug的場景(Timing_not_bug)

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

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

示例：

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

最后

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

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

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

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

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

本文鏈接：http://www.www897cc.com/showinfo-26-26570-0.html分析Bug的維度

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： 14個Vue3開源后臺管理項目，優選、多星！

下一篇：通過 Java 的 BCI 應用開發了解腦機接口

標簽：

熱門焦點

28個SpringBoot項目中常用注解，日常開發、求職面試不再懵圈

前言在使用SpringBoot開發中或者在求職面試中都會使用到很多注解或者問到注解相關的知識。本文主要對一些常用的注解進行了總結，同時也會舉出具體例子，供大家學習和參考。注解
十個可以手動編寫的 JavaScript 數組 API

JavaScript 中有很多API，使用得當，會很方便，省力不少。你知道它的原理嗎? 今天這篇文章，我們將對它們進行一次小總結。現在開始吧。1.forEach()forEach()用于遍歷數組接收一參
K8S | Service服務發現

一、背景在微服務架構中，這里以開發環境「Dev」為基礎來描述，在K8S集群中通常會開放：路由網關、注冊中心、配置中心等相關服務，可以被集群外部訪問；圖片對于測試「Tes」環境或者
一年經驗在二線城市面試后端的經驗分享

忠告這篇文章只適合2年內工作經驗、甚至沒有工作經驗的朋友閱讀。如果你是2年以上工作經驗，請果斷劃走，對你沒啥幫助~主人公這篇文章內容來自「升職加薪」星球星友的投稿，坐
超閉合精工鉸鏈徹底消滅縫隙三星Galaxy Z Flip5與Galaxy Z Fold5發布

2023年7月26日，三星電子正式發布了Galaxy Z Flip5與Galaxy Z Fold5。三星新一代折疊屏手機采用超閉合精工鉸鏈，讓折疊后的縫隙不再可見。同時，配合處
三星Galaxy Z Fold5今日亮相：厚度縮減但仍略顯厚重

據官方此前宣布，三星將于7月26日也就是今天在韓國首爾舉辦Unpacked活動，屆時將帶來帶來包括Galaxy Buds 3、Galaxy Watch 6、Galaxy Tab S9、Galaxy
機構稱Q2全球智能手機出貨量同比下滑11% 蘋果份額依舊第2

7月20日消息，據外媒報道，研究機構的報告顯示，由于需求下滑，今年二季度全球智能手機的出貨量，同比下滑了11%，三星、蘋果等主要廠商的銷量，較去年同期均有下
英特爾Xe-HP項目終止，將專注Xe-HPC/HPG系列顯卡

據10 月 31 日消息報道，英特爾高級副總裁兼加速計算系統和圖形事業部總經理表示，Xe-HP“ Arctic Sound” 系列服務器 GPU 已經應用于 oneAPI devcloud 云服
聯想小新Pad Pro 12.6將要推出，搭載高通驍龍 870 處理器

聯想小新Pad Pro 12.6將于秋季新品會上推出，官方按照慣例直接在發布會前給出了機型的所有參數。聯想小新 Pad Pro 12.6 將搭載高通驍龍 870 處理器，重量為 5

日韩成人免费在线_国产成人一二_精品国产免费人成电影在线观..._日本一区二区三区久久久久久久久不

分析Bug的維度

一、Bug分析的維度

1.Bug發現的環境 (Env)

2.Bug引入時機 (Timing)

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

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

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

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

7.發現的問題不屬于Bug的場景(Timing_not_bug)

最后

28個SpringBoot項目中常用注解，日常開發、求職面試不再懵圈

十個可以手動編寫的 JavaScript 數組 API

K8S | Service服務發現

一年經驗在二線城市面試后端的經驗分享

超閉合精工鉸鏈徹底消滅縫隙三星Galaxy Z Flip5與Galaxy Z Fold5發布

三星Galaxy Z Fold5今日亮相：厚度縮減但仍略顯厚重

機構稱Q2全球智能手機出貨量同比下滑11% 蘋果份額依舊第2

英特爾Xe-HP項目終止，將專注Xe-HPC/HPG系列顯卡

聯想小新Pad Pro 12.6將要推出，搭載高通驍龍 870 處理器

最新推薦

猜你喜歡

熱門推薦

相關資訊