1.描述bug不清晰,就一句話,沒有具體的操作步驟。
比如:撥打電話出現(xiàn)死機。(就簡單的一句話,就啥都沒了,撥打什么號碼–沒寫,在什么情況下?lián)艽螂娫?ndash;沒寫)
2.提交的bug看不懂啥意思,不知所云。
這種bug只有測試工程師自己能看懂,別人根本看不懂,他卻以為別人能懂。
3.bug發(fā)生的前提條件都不寫。
比如:bug描述是充電圖標(biāo)顯示重疊。但是沒有寫什么條件下出現(xiàn),開機狀態(tài)?還是關(guān)機狀態(tài)?開發(fā)工程師懵逼,還要自己去一個個去試,浪費開發(fā)人員的時間,描述不詳細但是測試工程師還覺得自己沒毛病,一切挺好。
4.沒有寫出現(xiàn)的概率。
偶發(fā)的bug沒有l(wèi)og和其他更多信息,有的bug概率很小,小到不影響用戶使用,如果不寫清楚,開發(fā)人員將浪費大量時間去定位問題。
5.測試工程師描述bug,卻不寫預(yù)期結(jié)果。
開發(fā)都不知道要修改成什么樣,一臉懵逼。結(jié)果開發(fā)理解錯了,修改的結(jié)果不是預(yù)期的結(jié)果,這就浪費開發(fā)的時間了,你想想此刻開發(fā)人員的心情是怎樣的?
6.bug等級亂定位
比如一個很小的甚至是建議性的問題,把bug等級提到高。
軟件開發(fā)一看,全是致命性1級bug,仔細一看很多小問題也被提為1級bug,此時開發(fā)人員的心情肯定的奔潰的。
7.出現(xiàn)問題的軟件版本沒寫清楚,開發(fā)人員不知道是在哪個軟件版本出現(xiàn)的。
8.bug出現(xiàn)的模塊沒有劃分清楚,所有的bug都提到一塊,看的眼花繚亂。
推薦閱讀:
本文內(nèi)容不用于商業(yè)目的,如涉及知識產(chǎn)權(quán)問題,請權(quán)利人聯(lián)系SPASVO小編(021-60725088-8054),我們將立即處理,馬上刪除。