一、背景
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應該在測試中關注並找到