1.前言

BUG相比大家都知道,程序運(yùn)行出錯(cuò)或者與預(yù)期不符就是BUG.現(xiàn)在我們來用測試人員的角度來看待BUG.

2.如何描述/創(chuàng)建一個(gè)BUG

測試人員要測試開發(fā)人員的代碼,找出開發(fā)人員可能忽略的問題.然后把這個(gè)問題反饋給開發(fā)人員.
如何把BUG清晰簡潔明了的描述出來,會(huì)涉及到很多東西.這并不只是簡單說一下遇到BUG的情況.
一個(gè)合格BUG的描述分為以下幾部分:

• 發(fā)現(xiàn)問題的版本: 大部分軟件的版本應(yīng)該是很多的,測試人員需要知道出現(xiàn)問題對(duì)應(yīng)的版本,才能獲取對(duì)應(yīng)版本的代碼進(jìn)而重現(xiàn)故障
• 問題出現(xiàn)的環(huán)境: 環(huán)境分為硬件環(huán)境和軟件環(huán)境,如果是WEB項(xiàng)目,還需要描述瀏覽器的版本,客戶機(jī)的操作系統(tǒng)等.如果是APP項(xiàng)目,需要描述機(jī)型,分辨率,操作系統(tǒng)等.詳細(xì)的環(huán)境描述有利于故障的定位.
• 錯(cuò)誤重現(xiàn)的步驟: 描述問題重現(xiàn)的最小步驟.
• 預(yù)期行為的描述: 以用戶的角度指導(dǎo)開發(fā)人員怎么樣才是正確的.
• 錯(cuò)誤問題的描述: 出現(xiàn)BUG時(shí)的場景

描述一個(gè)BUG并不意味著只能有以上這些部分,還可以有別的方面的描述,例如:這個(gè)BUG是前端問題還是后端問題,BUG的級(jí)別等.

能夠描述好一個(gè)BUG,創(chuàng)建BUG就很容易了.

3.BUG的級(jí)別

BUG存在不同的嚴(yán)重級(jí)別.BUG的定義每個(gè)公司都不一致，在定義級(jí)別之前需要查看公司規(guī)范。
舉個(gè)例子:

• Blocker（崩潰）:阻礙開發(fā)或測試工作的問題；造成系統(tǒng)崩潰、死機(jī)、死循環(huán)，導(dǎo)致數(shù)據(jù)庫數(shù)據(jù)丟失，與數(shù)據(jù)庫連接錯(cuò)誤，主要功能喪失，基本模塊缺失等問題。如：代碼錯(cuò)誤、死循環(huán)、數(shù)據(jù)庫發(fā)生死鎖、重要的一級(jí)菜單功能不能使用等（該問題在測試中較少出現(xiàn)，一旦出現(xiàn)應(yīng)立即中止當(dāng)前版本測試）。
• Critical（嚴(yán)重）：系統(tǒng)主要功能部分喪失、數(shù)據(jù)庫保存調(diào)用錯(cuò)誤、用戶數(shù)據(jù)丟失，一級(jí)功能菜單不能使用但是不影響其他功能的測試。功能設(shè)計(jì)與需求嚴(yán)重不符，模塊無法啟動(dòng)或調(diào)用，程序重啟、自動(dòng)退出，關(guān)聯(lián)程序間調(diào)用沖突，安全問題、穩(wěn)定性等。如：軟件中數(shù)據(jù)保存后數(shù)據(jù)庫中顯示錯(cuò)誤，用戶所要求的功能缺失，程序接口錯(cuò)誤，數(shù)值計(jì)算統(tǒng)計(jì)錯(cuò)誤等（該等級(jí)問題出現(xiàn)在不影響其他功能測試的情況下可以繼續(xù)該版本測試）。
• Major（一般）：功能沒有完全實(shí)現(xiàn)但是不影響使用，功能菜單存在缺陷但不會(huì)影響系統(tǒng)穩(wěn)定性。如：操作時(shí)間長、查詢時(shí)間長、格式錯(cuò)誤、邊界條件錯(cuò)誤，刪除沒有確認(rèn)框、數(shù)據(jù)庫表中字段過多等(該問題實(shí)際測試中存在最多）
• Minor（次要）：界面、性能缺陷，建議類問題，不影響操作功能的執(zhí)行，可以優(yōu)化性能的方案等。如：錯(cuò)別字、界面格式不規(guī)范，頁面顯示重疊、不該顯示的要隱藏，描述不清楚，提示語丟失，文字排列不整齊，光標(biāo)位置不正確，用戶體驗(yàn)感受不好，可以優(yōu)化性能的方案等（此類問題在測試初期較多，優(yōu)先程度較低；在測試后期出現(xiàn)較少，應(yīng)及時(shí)處理）

4.BUG的生命周期

測試人員在執(zhí)行測試的過程中,如果有對(duì)應(yīng)的BUG,需要在對(duì)應(yīng)的BUG 管理平臺(tái)來創(chuàng)建BUG.
每個(gè)公司、每一個(gè)工具對(duì)bug生命周期的定義都是不一致的.
舉個(gè)例子:

• New:測試人員創(chuàng)建BUG
• Open: 開發(fā)人員確認(rèn)是否是BUG,如果是BUG 狀態(tài)就會(huì)改為Open
• Rejected：如果認(rèn)為不是Bug，則拒絕修改。
• Fixed: 開發(fā)人員修復(fù)完BUG,狀態(tài)就改為Fixed
• Delay: 確認(rèn)BUG后,BUG的級(jí)別不高或開發(fā)人員不能立即修復(fù)BUG,狀態(tài)就改為Delay.
• Closed: BUG確認(rèn)修復(fù)完成,測試人員將BUG改為Closed
• Reopen: 開發(fā)人員修復(fù)BUG,但BUG并沒有修復(fù)完成,BUG狀態(tài)改為Reopen

5.跟開發(fā)產(chǎn)生爭執(zhí)怎么辦

測試人員畢竟是要想方設(shè)法測試開發(fā)人員的代碼,并提出BUG.如果處理不好,很容易與開發(fā)產(chǎn)生爭執(zhí).如果產(chǎn)生爭執(zhí)怎么辦?
針對(duì)這個(gè)問題: 我們要堅(jiān)持"對(duì)事不對(duì)人".

1. 要有"批判性思維",想一想是不是自己描述的BUG不夠清晰等.
2. 如果開發(fā)人員對(duì)BUG的級(jí)別不認(rèn)可,我們要保證BUG的級(jí)別有理有據(jù).
3. 提出BUG會(huì)增加開發(fā)人員的工作量, 小問題可能不想解決.這時(shí)可以引導(dǎo)開發(fā)人員進(jìn)行換位思考,“如果你是用戶,出現(xiàn)這樣的情況你能接受嗎?”
4. 不僅要提出BUG,最好也能提出解決方案
5. 如果確實(shí)是BUG,此時(shí)友好溝通不能解決問題,那么就召開BUG評(píng)審.

以上的答案僅供參考,如有更好的想法,也可以加上.

補(bǔ)充:BUG評(píng)審需要參加的人員有產(chǎn)品經(jīng)理,開發(fā)代表,測試代表等,討論內(nèi)容一般分為兩部分:1.如果解決BUG 2.如何避免類似的問題發(fā)生.

感謝你的觀看!希望這篇文章能幫到你!
專欄:《軟件測試》在不斷更新中,歡迎訂閱!
“愿與君共勉,攜手共進(jìn)!”
文章來源地址http://www.zghlxwxcb.cn/news/detail-441509.html

到了這里，關(guān)于【軟件測試】測試&開發(fā)的一生之?dāng)?BUG的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！