首先宣告，bug的測試規範應該在公司的正式文件建立。
本建議非正式文件，有些內容可能不正確，有些內容可能需要繼續商榷，甚至有些內容同公司規範有衝突。如果發現問題，直接忽略本文相應內容。
本帖本意僅就工作中的一些現象記錄，可以通過簡單規範讓大家工作輕鬆，高效。
後續繼續補充修改，也請大家補充修改。
其次，本帖也僅就填寫bug報告的行為進行了一些梳理和建議，不能取代正式的bug測試流程或質量管理過程。
內容：填寫bug報告，可能是專門的測試人員或者開發人員，甚至其他臨時幫忙或者終端使用者。
發現bug和解決bug是一件非常重要的工作。大家的目的都是為了軟體能夠安全、穩定執行起來，提交bug的人同解決bug的人目標是一致的，而不是對立的，不是找麻煩。
測試工作其實非常複雜和繁重，發現問題僅僅是第一步，更重要的是確定是bug，是不是可以重現，跟正確結果的差別在**。
最終提交的bug不要讓修復者重複太多工作才能重現，也不要讓修復者猜測或者試驗力。最快讓修復者找到問題是關鍵。
如果修復者花費太長時間琢磨乙個bug報告的重現，最好還是直接演示給他看，這是最有效的方式。
基於這些共識，我們希望達成一致的規範。
提交者規範建議：
1. 提交bug是針對真實存在的缺陷。那些偶爾出現的bug，提交者盡量找到重現的真正原因。如果可能，盡量在2個不同終端上可以確定重現。如果沒有2臺終端，至少用2種瀏覽器或者2個虛擬機器等方式模擬重現出來。
2. 如果是瀏覽器相容問題，確定重現步驟後，bug報告中盡量寫清哪個型別瀏覽器，版本號，語言，以及設定方式。
3. 描述清楚。有些bug是需求沒有滿足，但是沒有其他崩潰結果哦出現，盡量將「期待」的內容和「實際」的情形區別開，
如，乙個bug，乙個按鈕點選後的「需求」是開啟視窗，實際執行結果是轉到另外乙個位址。轉移位址是錯誤的，就要告訴修復者。
而不是報告：這個點選按鈕後轉到了乙個新位址。
修復者有時理解成需求是要轉移到乙個新位址，結果他看到的就是這個結果。修復這可能要仔細對照需求說明書，才能知道這是乙個錯誤。他記憶中的需求可能就是轉移到乙個新位址。
建議寫成：「需求」是開啟視窗，「當前」的bug是轉到另外乙個位址。
4. 縮小範圍。如果能將bug出現定位在乙個確定的範圍，則減少了重現和定位的重複工作，也更加清晰bug的關鍵內容。
如，bug報告中如果是這樣一條報告，修復者會是一腦門子汗。
論壇**上不去！
這個bug的範圍太廣泛。有如下幾種具體bug都可以說成是**上不去。
內網能上，外網不能上。
用ie瀏覽器可以上，用chrome不能上
**的頁面打不開，一直等待
**的頁面開啟了報錯，全部英文，不能顯示有用文字。
**的網頁可以開啟，但是沒有登入的部分。
**登入框正確填寫使用者名稱口令後，還是提示「使用者名稱密碼不能驗證通過」
**登入框正確填寫使用者名稱口令後，無反應。
**登入框正確填寫使用者名稱口令後，頁面變成錯誤資訊。
所以，bug報告也是有質量的，要有質，而不是量。這也正式測試人員不能以bug數量計算工作量的原因。
提交bug規範以及bug跟蹤
常見的軟體測試面試題 一條軟體缺陷 或者叫bug 記錄包含了哪些內容？標準答案是 標題 嚴重等級 前置條件 步驟 bug描述 期望結果 實際結果 實際上在我們日常軟體測試過程中，提交乙個bug，不僅僅是這6要素這麼簡單的事情。以下是個人總結了日常測試工作中常見的一些問題 個人總結了乙個健全的缺陷，應...
bug管理規範
1 2 3 4級bug判定標準如下 1 緊急 致命錯誤，例如主程式不能正常執行，基本業務功能未實現，交易資料不準確或不一致，從而使得後續流程無法正常進行 作業系統崩潰 宕機 頻繁造成資料庫死鎖或資料丟失 造成交易資料不準確 收銀對賬不一致 使用者無法註冊 登陸 正常操作，從而無法進行無法正常使用 在...
bug規範初稿
一 背景 bug是開發和測試質量的重要指標，從bug數量 嚴重性等可以看出rd的開發質量，從發現問題的階段可以看出qa的測試意識和測試質量，從問題分類 問題 等可以看出產品開發 測試質量的一些固有模式，幫助rd和qa提公升開發和測試質量。總之窺一斑而見全豹，因此統計和分析bug十分有必要。各端都將b...