BUG 參考標準(網路轉載)

一、目的

        對 BUG 概念、類型劃分、 BUG 狀態、 BUG 嚴重程度等內容進行定義和規範，以便進一步指導我們的測試工作。

二、概念

        BUG ：軟體中存在的瑕疵，可能會導致系統失效。簡單的說就是軟體系統中存在的可能導致系統出錯、失效、死機等問題的錯誤或缺陷。

三、 BUG 的類型劃分

•  功能類

A. 重複的功能

B. 多餘的功能

C. 功能實現與設計要求不相符

D. 功能使用性、方便性、易用性不夠

•  介面類

A. 介面不美觀

B. 控制項排列、格式不統一

C. 焦點控制不合理或不全面

•  資料處理類

A. 資料有效性檢測不合理

B. 資料來源不正確

C. 資料處理過程不正確

D. 資料處理結果不正確

•  流程類

A. 流程式控制制不符和要求

B. 流程實現不完整

•  提示資訊類

A. 提示資訊重複或出現時機不合理

B. 提示資訊格式不符和要求

C. 提示框返回後焦點停留位置不合理

6 、建議類

A. 功能性建議

B. 操作建議

C. 檢校建議

D. 說明建議

7 、效能類

A. 並發量

B. 資料量

C. 壓縮率

D. 回應時間

8 、常識類

A. 違背正常習俗習慣的，比如日期 / 節日等

9 、特殊類

A. 不符合 OEM 版本或 DEMO 版本特殊要求的

四、 BUG 狀態

        已提交：測試員發現 BUG 後提交到 BUG 管理系統中的狀態。（初始狀態）

        已修改：程式員在修改了 BUG 後提交到 BUG 管理系統中的狀態。

        不修改：程式員或專案經理根據需求分析、概要設計、詳細設計說明書等上的要求經過考慮後決定對 BUG 不進行修改。其 BUG 的狀態為不修改，需要說明理由。

        延遲：根據目前項目進程或計劃等情況，暫時延期的狀態

        待討論：需要進行討論後才能決定是否需要修改的 BUG 的狀態。

        已驗證：已經解決的並經過測試員複測的 BUG 的狀態。

        關閉：完全解決了，只供以後備查的狀態

        重新開啟：重新出現在新的版本中，重新開啟以前關閉的 bug 狀態

        ( 當然在 bug 工具中，可以自己定製適合項目的狀態項目，比如廢除，拒絕等 )

五、 BUG 的等級劃分與優先順序

1 、嚴重：死機，資料丟失，主要功能完全喪失，系統懸掛等錯誤。修改優先順序為最高，該層級需要程式員立即修改。

2 、較高：主要功能喪失，導致嚴重的問題，或致命的錯誤聲明。修改優先順序為高，該層級需要程式員儘快修改。

3 、一般：次要功能喪失， 不太嚴重，如提示資訊不太準確。修改優先順序為中，該層級需要程式員修改。

4 、輕微：微小的問題，對功能幾乎沒有影響，產品及屬性仍可使用，如有個錯別字。修改優先順序為低，該層級需要程式員修改或不修改。

六、 BUG 的優先順序 （一般與 BUG 等級掛鈎）

參考 1 、緊急、非常高、高、中等、低

　參考 2 、下一個 build 版本 ,a 測試 ,b 測試 , 發布版本，最終發布版本

七、 BUG 記錄內容

•  編號

•  標題

•  項目模組

•  測試階段

•  類型

•  作業環境 ( 作業系統 ,IE 等軟硬體環境 )

•  嚴重程度（等級及優先順序）

•  BUG 狀態

•  測試員

•  程式員（解決者）

•  解決方案

•  解決日期

•  測試日期

•  詳細描述（步驟、結果、期望、備忘）

編號		測試日期
標題
項目模組		測試階段
測試員		作業環境
BUG 類型		等級及優先順序
詳細描述
•  步驟（操作、資料輸入等） •  結果 •  期望 •  備忘
程式員		解決日期
解決方案

備忘：根據項目具體情況，定製真正適合項目的 bug 規範，一切以提高產品品質及公司效益為根本， bug 沒有統一規範只有共同的目的。