bug規範初稿

一、背景

bug是開發和測試質量的重要指標,從bug數量、嚴重性等可以看出RD的開發質量,從發現問題的階段可以看出QA的測試意識和測試質量,從問題分類、問題來源等可以看出產品開發、測試質量的一些固有模式,幫助RD和QA提升開發和測試質量。總之窺一斑而見全豹,因此統計和分析bug十分有必要。

各端都將bug管理工作遷移到效率雲,正好可以在客戶端各端建立統一的規則,既便於各端的質量分析,又便於橫向對比。

 

二、bug規範

Bug記錄包含內容和tag兩部分。

2.1 內容模板

bug描述——bug的直觀簡短的描述

登錄信息——如果需要登錄才能復現的bug,提供登錄的賬號和密碼,可缺省

bug復現步驟——對於操作步長超過3的,且RD難以理解怎麼復現的問題,提供復現問題的步驟。

預期結果——描述需求預期的結果,必要時輔以截圖說明

實際結果——描述RD實現後的實際結果,必要時輔以截圖說明

 

2.2 tag

tag部分包括以下幾項(必填):

優先級——需要RD修復的緊急程度,是問題嚴重性和對測試block程度的綜合考慮

嚴重級別——問題嚴重程度,可理解爲被用戶接受的程度

問題分類——描述問題本身的屬性,是最直接、最直觀的一個分類方式

問題發現階段——描述QA發現問題的階段,是評估QA測試質量的重要指標

問題引入方式——評估RD開發質量的重要指標

問題來源——比較粗放的一種分類方式,作一個大體的分類

解決結果——描述bug修復情況

發現版本——發現問題的版本,統一爲x.x.x

修復版本——修復問題的版本,統一爲x.x.x

 

2.3 重要說明

關於問題分類、問題發現階段、問題引入方式、問題來源的設計思路,做如下說明:

問題分類,描述問題本身的屬性,是最直接、最直觀的一個分類方式,也是我們關注最多的一種分類方式,可選項如下:

序號

名稱

描述

1

NA邏輯實現問題

NA邏輯實現錯誤

2

Server邏輯實現問題

Server邏輯實現錯誤

3

NA和Server接口聯調問題

接口名稱、接口字段錯誤

4

NA兼容性問題

與機型、系統有關的兼容問題

5

視覺和體驗問題

文案、樣式、交互細節問題

6

需求問題

需求不明確、臨時需求撤換、變更

7

性能問題

NA在流量、內存、CPU、電量等方面的問題

8

其他

不能歸類爲以上問題的問題

 

1-4一定是問題,是RD不能和QA argue的問題;

5,7是協商考慮是否接受和解決的問題(性能問題嚴重的不能接受);

6是在流程上要充分溝通和確認的問題,這部分容易引起RD的argue,會認爲不是bug。

 

問題發現階段描述QA發現問題的階段,是評估QA測試質量的重要指標。可選項如下:

序號

名稱

描述

1

新功能測試階段

新功能測試階段

2

集成測試階段

新功能測試已完成,進入集成測試階段

3

上線前冒煙測試階段

新功能和系統集成測試已完成,進入

上線前的checklist檢查的階段

4

已上線階段

已上線階段

 

這裏整體分爲4個階段,沒有做更細的區分,是爲了各端上都能統一,因爲一些兼容性測試、迴歸測試等各端是靈活進行的。對QA而言,越早發現bug越好,最好95%的bug都在新功能測試階段,而3在上線前的冒煙測試階段發現問題則是比較危險的,這意味着很可能帶着未知的bug上線,而4已上線階段發現bug則是QA應該儘量避免的。

 

問題引入方式是評估RD開發質量的一個指標,可選項如下:

序號

名稱

描述

1

歷史遺留

歷史遺留問題,在之前的版本中未解決

2

新功能導致老功能出問題

新老功能存在耦合,導致老功能出問題

3

修復bug引起問題

修復bug引起的問題

4

新功能出問題

新開發的功能本身有問題

5

重構與優化引起問題

重構或優化已有功能、模塊引起問題

 

1越多,說明在之前的版本中開發和測試質量都不過關;2,3,5都考察RD在開發過程中對整體工程的把握,對代碼之間耦合的理解。

 

問題來源是一個比較粗放的分類,可選項如下:

序號

名稱

描述

1

髒數據問題

因爲髒數據導致的問題

2

代碼提交問題

代碼提交不全、代碼合併導致的問題

3

代碼配置問題

配置錯誤、線上線下配置錯亂等

4

邏輯實現問題

代碼邏輯實現不到位

5

第三方問題

第三方庫、資源、sdk等引起的問題,通常不可控

6

需求問題

需求理解、溝通不一致引起的問題

 

1-3是開發測試中應該儘量避免的問題,需要QA和RD做好幾時的溝通,避免因爲這類問題降低測試效率和測試質量。對於1-3類問題的界定,可以考慮由RD提供;5作爲低頻的、難以控制的問題,可以作爲bad case積累;6是應該充分溝通,降低出現頻率的問題。

 

解決結果描述bug的修復情況,可選項如下:

序號

名稱

描述

1

已修復

問題已修復

2

不是Bug

因爲QA的理解錯誤,界定爲bug,實際上不是bug

3

以後修復

因爲排期、優先級或者技術實現不可達,後續再修復

4

重複

QA提了重複的bug

5

無法復現

bug真實存在過,但是難以復現

6

設計如此

雖然與需求不一致,但是PM認可這種實現,定義爲設計如此

 

2,4是QA需要儘量避免的,這會給RD或PM質疑QA測試的專業性;對於5,QA應該在測試中關注並找到

發佈了41 篇原創文章 · 獲贊 12 · 訪問量 5萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章