Bug報告提交規范

首先聲明，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數量計算工作量的原因。

5.
如果界面的一些細小問題，請將你發現的問題截圖。截圖后，一定要用明顯標記的方式，指出錯誤所在。
如果有可能，將正確的截圖也提供出來，而且也明顯標記出對應的位置。

6.
多個關聯的bug，盡量將每一個bug單獨提交，並且通過bugfree進行明確的關聯。缺陷的分解也體現測試者的工作到位。

修復者規范建議：
1.
尊重bug提交者的勞動，認真對待每一個bug。
2. 如果有不清楚的bug報告，盡快聯系提交者，以便重現bug，意見達成一致。
3.
如果屬於其他人的問題，盡快轉發。
4.
多練“找不同”、“找茬兒”、“連連看”之類的游戲，提高眼力。尤其是幾面中一個像素或者1px線的瑕疵。
建議人力資源部在入職考試中加入連連看測試和成績入檔案。