軟件測試工程師怎么正確描述bug?
有些工程師心想:“作為測試工程師我怎么不知道提交bug嗎?難道還要你來教我嗎?好low的問題。”
正因為軟件測試工程師的這種傲慢,這種傲慢直接導(dǎo)致和開發(fā)人員沖突,經(jīng)常碰到開發(fā)人員抱怨測試提交的bug看不懂。

我先聲明下,我今天不是替軟件開發(fā)工程師說話,我只是站在一個客觀的角度看待問題。我剛開始做測試的時候也是不理解軟件開發(fā)的抱怨和責(zé)怪,隨時時間的推移才明白做人真的不易,每個崗位每個人都有他的難處,多理解他人的處境,要知道軟件開發(fā)整天面對密密麻麻的代碼很費腦,再碰到測試提交的很多bug,他們的內(nèi)心是排斥、抗拒的。
01、現(xiàn)在我們站在軟件開發(fā)人員的角度,看軟件測試工程師有哪些毛???
1.描述bug不清晰,就一句話,沒有具體的操作步驟。
比如:撥打電話出現(xiàn)死機。(就簡單的一句話,就啥都沒了,撥打什么號碼–沒寫,在什么情況下?lián)艽螂娫?ndash;沒寫)
2.提交的bug看不懂啥意思,不知所云。
這種bug只有測試工程師自己能看懂,別人根本看不懂,他卻以為別人能懂。
3.沒有寫出現(xiàn)的概率。
偶發(fā)的bug沒有l(wèi)og和其他更多信息,有的bug概率很小,小到不影響用戶使用,如果不寫清楚,開發(fā)人員將浪費大量時間去定位問題。
4.bug發(fā)生的前提條件都不寫。
比如:bug描述是充電圖標顯示重疊。但是沒有寫什么條件下出現(xiàn),開機狀態(tài)?還是關(guān)機狀態(tài)?開發(fā)工程師懵逼,還要自己去一個個去試,浪費開發(fā)人員的時間,描述不詳細但是測試工程師還覺得自己沒毛病,一切挺好。
5.bug等級亂定位
比如一個很小的甚至是建議性的問題,把bug等級提到最高。軟件開發(fā)一看,全是致命性1級bug,仔細一看很多小問題也被提為1級bug,此時開發(fā)人員的心情肯定的奔潰的。

6.測試工程師描述bug,卻不寫預(yù)期結(jié)果。
開發(fā)都不知道要修改成什么樣,一臉懵逼。結(jié)果開發(fā)理解錯了,修改的結(jié)果不是預(yù)期的結(jié)果,這就浪費開發(fā)的時間了,你想想此刻開發(fā)人員的心情是怎樣的?
7.出現(xiàn)問題的軟件版本沒寫清楚,開發(fā)人員不知道是在哪個軟件版本出現(xiàn)的。
8.bug出現(xiàn)的模塊沒有劃分清楚,所有的bug都提到一塊,看的眼花繚亂。
02、正確的提交bug才是我們和開發(fā)人員友好的溝通的最好方式。
1.bug標題要簡潔明了,不要啰嗦一堆。
2.要寫出現(xiàn)問題的前提條件。
什么情況才會出現(xiàn),必須要寫清楚。
3.操作步驟要分步驟一步步寫清楚,不要怕麻煩。比如步驟1,步驟2,步驟3。
4.要寫實際結(jié)果和預(yù)期結(jié)果,讓開發(fā)清楚要修改bug到達的預(yù)期效果。
5.要寫出現(xiàn)的概率,比如操作10次出現(xiàn)1次。
6.提供必要的截圖和log,甚至復(fù)雜的操作步驟要提供視頻。
7.bug等級要分類好,致命性bug、嚴重bug、一般性bug、建設(shè)性意見,必須嚴格按照標準劃分。
8.出現(xiàn)bug的軟件版本號,要寫清楚。
9.bug出現(xiàn)的模塊要寫清楚。
比如app–設(shè)置模塊出現(xiàn)了bug,就把bug歸類為設(shè)置模塊的bug,這樣分類讓人一目了然。
03、以下是完整的bug:
前提條件:
操作步驟:
1.
2.
3.
實際結(jié)果:
預(yù)期結(jié)果:
概率:
版本號:
log、截圖、視頻等
04、bug的分類嚴格遵守,如下:
1、致命(1級bug)
通常表現(xiàn)為:系統(tǒng)無法運行,崩潰。
應(yīng)用模塊無法啟動或異常退出,主要功能模塊無法使用。
比如:1.內(nèi)存泄漏;2.系統(tǒng)容易崩潰;3.系統(tǒng)無法登陸;4.循壞報錯,無法正常退出。
2、嚴重(2級bug)
通常表現(xiàn)為:影響系統(tǒng)功能或操作,主要功能存在嚴重缺陷,但不會影響到系統(tǒng)穩(wěn)定性。
比如:1. 功能未實現(xiàn);2.功能存在報錯;3.數(shù)值輕微的計算錯誤;4.亂碼;
5.程序里有有危害國家安全或帶有政治色彩的字樣。
3、一般(3級bug)
通常表現(xiàn)為:界面、性能缺陷。
比如:1.邊界條件下錯誤;2.極限條件下容易無響應(yīng);4.大數(shù)據(jù)操作時,沒有提供進度條;出現(xiàn)錯別字,但是不影響功能
4、建設(shè)性意見(4級bug)
通常表現(xiàn)為:易用性及建議性問題

