正式進入一個project,由于Leader請假,導致沒有case給我執(zhí)行,再加上又出了一個需求版本,結果我一邊看Build 1技術文檔上說的功能點一邊看需求……真不是一般的累。
PM叫我做測試……我狂汗,沒人跟,叫開發(fā)給我講講,然后叫我自己找bug,然后要寫bug報告。下午找了半天,發(fā)現(xiàn)幾個貌似bug的bug,問了問開發(fā)那邊,有幾個都是需求理解不正確,后只有一個是bug……還好,沒有空手而歸。需求的理解真不容易……尤其是對新手來說。
接著我旁邊那個人告訴我bug報告的模版要注意事項,我們公司用的是IBM的LOTOS NOTES,然后基于DOMINO開發(fā)的DB,好復雜……我現(xiàn)在都沒有搞清楚那個具體干什么,東西太多,又全是英文的。
一個BUG報告,標題要描寫清楚,讓開發(fā)人員能從標題找到那里出現(xiàn)了問題。其實這個標題很多地方都提到過,具體的編寫方法也有人說,只是自己想做好那是另外一回事了。接著是B的版本,Bug的編號。軟硬件環(huán)境,Server和Client的配置。
Bug的狀態(tài)其實那么多,只要熟悉了好了,知道那個流程。其實我們有權利修改的狀態(tài)還是很少的……大多都要經(jīng)過PM的手。優(yōu)先級自己憑感覺給吧……這里存在兩個:缺陷的優(yōu)先級,有修改的優(yōu)先級。
主要的體現(xiàn)還是在bug的重現(xiàn)步驟上面,如何準確的重現(xiàn)bug,具體到你每一步如何操作的,知道出現(xiàn)了現(xiàn)象為止。好把每一步都寫得很詳細,比如有什么樣權限的用戶登錄,你點擊了什么菜單,點擊什么按鈕。預期結果是說正確的操作后應該出現(xiàn)什么樣的情況。實際結果是說這個bug會出現(xiàn)什么樣的情況,好截圖說明。尤其是有的bug不會經(jīng)常出現(xiàn)的,記得每次有bug先截圖吧~~
大概是這樣了……說起來也不難,只是需要理解,還有編寫的時候多注意。