當(dāng)前位置：首頁 > 科技 > 軟件

分析Bug的維度

來源：責(zé)編：時間：2023-11-16 09:40:18 291觀看

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

作者 | 常雨桐

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

一、Bug分析的維度

建議盡量用便于統(tǒng)計和維護的方式，記錄分析的結(jié)果(比如使用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ù)問題所需要的成本也就越小。為此，需要關(guā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應(yīng)該在此被發(fā)現(xiàn)。
集成環(huán)境(Env_Integration) 。常用于連接到外部或其他團隊系統(tǒng)的環(huán)境，容易發(fā)現(xiàn)外部集成相關(guān)的Bug。
用戶驗收環(huán)境 / 預(yù)發(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的引入時機，有機會識別出質(zhì)量保證體系中薄弱的點，或團隊在開發(fā)/測試流程中的問題。

(3) 維度示例：

常見的引入時機如下：

開發(fā)新需求時產(chǎn)生的新功能的Bug（Timing_Developing_New_Requirement）。在開發(fā)新功能時，產(chǎn)生的新功能中的行為與需求不符的問題。
開發(fā)新需求時破壞原有功能 (Timing_Developing_Other_Requirement) 。在開發(fā)新功能時，破壞了原有的已驗收過的功能的正確行為。
修復(fù)Bug破壞原有功能（Timing_Fix_Bug）。在修復(fù)其他Bug時，引入了新Bug。
重構(gòu)破壞原有功能（Timing_Refoctor）。在對代碼進行重構(gòu)的過程中，導(dǎo)致原有功能被破壞。雖然正常來講重構(gòu)活動是會在開發(fā)新卡時一起進行，理應(yīng)分在開發(fā)新功能時機，但是考慮到重構(gòu)行為的特殊性，以及為了后期分析重構(gòu)時是否有足夠的自動化測試保證原功能正常工作。可以視情況把重構(gòu)單獨作為一個引入時機進行分析。
前人代碼遺留的Bug（Timing_Legacy_Issue）。中途接手的項目，在團隊入場前就存在的問題。或者超出目前項目預(yù)期范圍的原有問題。一般PM會更加關(guān)注此類問題，以防團隊為遺留問題花費太多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所屬的前后端/微服務(wù)/功能模塊

(1) 維度定義：

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

(2) 分析目的：

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

(3) 維度示例：

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

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

(1) 維度定義：

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

(2) 分析目的：

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

(3) 維度示例：

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

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

(1) 維度定義：

描述寫出Bug代碼的原因。

(2) 分析目的：

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

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

(3) 維度示例：

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

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

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

(1) 維度定義：

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

(2) 分析目的：

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

(3) 維度示例：

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

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

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

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

示例：

臟數(shù)據(jù) (RC_dirty_data) 。存在于測試環(huán)境的臟數(shù)據(jù)導(dǎo)致的問題，常見的臟數(shù)據(jù)的來源可能是未完全開發(fā)完成的代碼，團隊成員對于數(shù)據(jù)庫數(shù)據(jù)的手動更新或插入。一般發(fā)現(xiàn)是臟數(shù)據(jù)導(dǎo)致的問題時，需要追查臟數(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è)務(wù)不符，需要新建卡來進行修正。
無法重現(xiàn) (RC_cant_reproduce) 。無法重現(xiàn)Bug所描述的問題，可能是瞬時的環(huán)境問題，或問題已經(jīng)被無意中修復(fù)。
基礎(chǔ)設(shè)施問題 (RC_unstable_env) 。由于基礎(chǔ)設(shè)施無法工作導(dǎo)致的問題，比如環(huán)境/數(shù)據(jù)庫無法訪問。
外部系統(tǒng)不穩(wěn)定 (RC_unstable_external_system) 。由于外部系統(tǒng)停止工作或者無法連接導(dǎo)致的問題。
依賴的卡未完成開發(fā) (RC_dependent_story_unfinished) 。Bug所描述功能的相關(guān)卡還未完全開發(fā)完成。需要開發(fā)完后再重新進行測試。
設(shè)計如此 (RC_by_design) 。Bug創(chuàng)建者理解有誤或不了解上下文，其實系統(tǒng)的設(shè)計與現(xiàn)有行為一致。

最后

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

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

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

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

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

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

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

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

下一篇：通過 Java 的 BCI 應(yīng)用開發(fā)了解腦機接口

標簽：

熱門焦點

一加首款折疊屏！一加Open渲染圖出爐：罕見單手可握小尺寸

8月5日消息，此前就有爆料稱，一加首款折疊屏手機將會在第三季度上市，如今隨著時間臨近，新機的各種消息也開始浮出水面。據(jù)悉，這款新機將會被命名為“On
重估百度丨“晚熟”的百度云，能等到春天嗎？

©自象限原創(chuàng)作者｜程心排版｜王喻可2016年7月13日，百度云計算戰(zhàn)略發(fā)布會在北京舉行，宣告著百度智能云的正式啟程。彼時的會場座無虛席，甚至排隊排到了門外，在場的所有人幾乎都
品牌洞察丨服務(wù)本地，美團直播成效幾何？

來源：17PR7月11日，美團App首頁推薦位出現(xiàn)“美團直播”的固定入口。在直播聚合頁面，外賣“神槍手”直播間、美團旅行直播間、美團買菜直播間等均已上線，同時
華為HarmonyOS 4升級計劃公布：首批34款機型今日開啟公測

8月4日消息，今天下午華為正式發(fā)布了HarmonyOS 4系統(tǒng)，在更流暢的前提下，還帶來了不少新功能，UI設(shè)計也有變化，會讓手機煥然一新。華為宣布，首批機型將會在
蘋果、三星、惠普等暫停向印度出口筆記本和平板電腦

集微網(wǎng)消息，據(jù)彭博社報道，在8月3日印度突然禁止在沒有許可證的情況下向印度進口電腦/平板及顯示器等產(chǎn)品后，蘋果、三星電子和惠普等大公司暫停向印度
國行版三星Galaxy Z Fold5/Z Flip5發(fā)布售價7499元起

2023年8月3日，三星電子舉行Galaxy新品中國發(fā)布會，正式在國內(nèi)推出了新一代折疊屏智能手機三星Galaxy Z Fold5與Galaxy Z Flip5，以及三星Galaxy Tab S9
iQOO Neo8 Pro真機諜照曝光：天璣9200+和V1+旗艦雙芯加持

去年10月，iQOO推出了iQOO Neo7系列機型，不僅搭載了天璣9000+，而且是同價位唯一一款天璣9000+直屏旗艦，一經(jīng)上市便受到了用戶的廣泛關(guān)注。在時隔半年后，
與兆芯合作聯(lián)想推出全新旗艦版筆記本電腦開天N7系列

聯(lián)想與兆芯合作推出全新聯(lián)想旗艦版筆記本電腦開天 N7系列。這個系列采用兆芯KX-6640MA處理器平臺，KX-6640MA 處理器是采用了陸家嘴架構(gòu)，16nm 工藝，4 核 4 線
2021中國國際消費電子博覽會與青島國際軟件融合創(chuàng)新博覽會新聞發(fā)布會隆重舉行

9月18日，2021中國國際消費電子博覽會與青島國際軟件融合創(chuàng)新博覽會新聞發(fā)布會在青島國際新聞中心隆重舉行。發(fā)布會上青島市政府領(lǐng)導(dǎo)聯(lián)袂出席，對本次雙展會情

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

分析Bug的維度

一、Bug分析的維度

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

2.Bug引入時機 (Timing)

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

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

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

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

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

最后

一加首款折疊屏！一加Open渲染圖出爐：罕見單手可握小尺寸

重估百度丨“晚熟”的百度云，能等到春天嗎？

品牌洞察丨服務(wù)本地，美團直播成效幾何？

華為HarmonyOS 4升級計劃公布：首批34款機型今日開啟公測

蘋果、三星、惠普等暫停向印度出口筆記本和平板電腦

國行版三星Galaxy Z Fold5/Z Flip5發(fā)布售價7499元起

iQOO Neo8 Pro真機諜照曝光：天璣9200+和V1+旗艦雙芯加持

與兆芯合作聯(lián)想推出全新旗艦版筆記本電腦開天N7系列

2021中國國際消費電子博覽會與青島國際軟件融合創(chuàng)新博覽會新聞發(fā)布會隆重舉行

最新推薦

猜你喜歡

熱門推薦

相關(guān)資訊