bug報告編寫的大概流程

今天正式進入一個project，由于Leader今天請假，導致沒有case給我執行，再加上又出了一個需求版本，結果我一邊看Build 1技術文檔上說的功能點一邊看需求……真不是一般的累。

 PM叫我做測試……我狂汗，沒人跟，叫開發給我講講，然后叫我自己找bug，然后要寫bug報告。下午找了半天，發現幾個貌似bug的bug，問了問開發那邊，有幾個都是需求理解不正確，最后只有一個是bug……還好，沒有空手而歸。需求的理解真不容易……尤其是對新手來說。

 接著我旁邊那個人告訴我bug報告的模版要注意事項，我們公司用的是IBM的LOTOS NOTES，然后基于DOMINO開發的DB，好復雜……我現在都沒有搞清楚那個具體干什么，東西太多，又全是英文的。

 一個BUG報告，標題要描寫清楚，讓開發人員能從標題找到那里出現了問題。其實這個標題很多地方都提到過，具體的編寫方法也有人說，只是自己想做好那就是另外一回事了。接著是B的版本，Bug的編號。軟硬件環境，Server和Client的配置。

 Bug的狀態其實就那么多，只要熟悉了就好了，知道那個流程。其實我們有權利修改的狀態還是很少的……大多都要經過PM的手。優先級自己憑感覺給吧……這里存在兩個：缺陷的優先級，有修改的優先級。

 主要的體現還是在bug的重現步驟上面，如何準確的重現bug，具體到你每一步如何操作的，知道出現了現象為止。最好把每一步都寫得很詳細，比如有什么樣權限的用戶登錄，你點擊了什么菜單，點擊什么按鈕。預期結果是說正確的操作后應該出現什么樣的情況。實際結果是說這個bug會出現什么樣的情況，最好截圖說明。尤其是有的bug不會經常出現的，記得每次有bug先截圖吧~~

大概就是這樣了……說起來也不難，只是需要理解，還有編寫的時候多注意。

原文轉自：http://www.kjueaiud.com