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線的瑕疵。
建議人力資源部在入職考試中加入連連看測試和成績入檔案。