一、背景
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 重要說明
問題分類，描述問題本身的屬性，是最直接、最直觀的乙個分類方式，也是我們關注最多的一種分類方式，可選項如下：
序號名稱
描述na邏輯實現問題
na邏輯實現錯誤
server邏輯實現問題
server邏輯實現錯誤
na和server介面聯調問題
介面名稱、介面字段錯誤
na相容性問題
與機型、系統有關的相容問題
視覺和體驗問題
文案、樣式、互動細節問題
需求問題
需求不明確、臨時需求撤換、變更
效能問題
na在流量、記憶體、cpu、電量等方面的問題
其他不能歸類為以上問題的問題
1-4一定是問題，是rd不能和qa argue的問題；
5，7是協商考慮是否接受和解決的問題（效能問題嚴重的不能接受）；
6是在流程上要充分溝通和確認的問題，這部分容易引起rd的argue，會認為不是bug。
問題發現階段描述qa發現問題的階段，是評估qa測試質量的重要指標。可選項如下：
序號名稱
描述新功能測試階段
新功能測試階段
整合測試階段
新功能測試已完成，進入整合測試階段
上線前冒煙測試階段
新功能和系統整合測試已完成，進入
上線前的checklist檢查的階段
已上線階段
已上線階段
這裡整體分為4個階段，沒有做更細的區分，是為了各端上都能統一，因為一些相容性測試、回歸測試等各端是靈活進行的。對qa而言，越早發現bug越好，最好95%的bug都在新功能測試階段，而3在上線前的冒煙測試階段發現問題則是比較危險的，這意味著很可能帶著未知的bug上線，而4已上線階段發現bug則是qa應該盡量避免的。
問題引入方式是評估rd開發質量的乙個指標，可選項如下：
序號名稱
描述歷史遺留
歷史遺留問題，在之前的版本中未解決
新功能導致老功能出問題
新老功能存在耦合，導致老功能出問題
修復bug引起問題
修復bug引起的問題
新功能出問題
新開發的功能本身有問題
重構與優化引起問題
重構或優化已有功能、模組引起問題
1越多，說明在之前的版本中開發和測試質量都不過關；2，3，5都考察rd在開發過程中對整體工程的把握，對**之間耦合的理解。
序號名稱
描述髒資料問題
因為髒資料導致的問題
**提交問題
**提交不全、**合併導致的問題
**配置問題
配置錯誤、線上線下配置錯亂等
邏輯實現問題
**邏輯實現不到位
第三方問題
第三方庫、資源、sdk等引起的問題，通常不可控
需求問題
需求理解、溝通不一致引起的問題
1-3是開發測試中應該盡量避免的問題，需要qa和rd做好幾時的溝通，避免因為這類問題降低測試效率和測試質量。對於1-3類問題的界定，可以考慮由rd提供；5作為低頻的、難以控制的問題，可以作為bad case積累；6是應該充分溝通，降低出現頻率的問題。
解決結果描述bug的修復情況，可選項如下：
序號名稱
描述已修復
問題已修復
不是bug
因為qa的理解錯誤，界定為bug，實際上不是bug
以後修復
因為排期、優先順序或者技術實現不可達，後續再修復
重複qa提了重複的bug
無法復現
bug真實存在過，但是難以復現
設計如此
雖然與需求不一致，但是pm認可這種實現，定義為設計如此
2，4是qa需要盡量避免的，這會給rd或pm質疑qa測試的專業性；對於5，qa應該在測試中關注並找到
bug管理規範
1 2 3 4級bug判定標準如下 1 緊急 致命錯誤，例如主程式不能正常執行，基本業務功能未實現，交易資料不準確或不一致，從而使得後續流程無法正常進行 作業系統崩潰 宕機 頻繁造成資料庫死鎖或資料丟失 造成交易資料不準確 收銀對賬不一致 使用者無法註冊 登陸 正常操作，從而無法進行無法正常使用 在...
提交bug規範以及bug跟蹤
常見的軟體測試面試題 一條軟體缺陷 或者叫bug 記錄包含了哪些內容？標準答案是 標題 嚴重等級 前置條件 步驟 bug描述 期望結果 實際結果 實際上在我們日常軟體測試過程中，提交乙個bug，不僅僅是這6要素這麼簡單的事情。以下是個人總結了日常測試工作中常見的一些問題 個人總結了乙個健全的缺陷，應...
Bug報告提交規範
首先宣告，bug的測試規範應該在公司的正式文件建立。本建議非正式文件，有些內容可能不正確，有些內容可能需要繼續商榷，甚至有些內容同公司規範有衝突。如果發現問題，直接忽略本文相應內容。本帖本意僅就工作中的一些現象記錄，可以通過簡單規範讓大家工作輕鬆，高效。後續繼續補充修改，也請大家補充修改。其次，本帖...