您的位置:軟件測(cè)試 > 開源軟件測(cè)試 > 開源Bug管理工具 >
開源工具Bug追蹤過程中注意的問題
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時(shí)間:[ 2013/12/12 11:12:33 ] 推薦標(biāo)簽:

很多朋友都問我,為什么那么喜歡研究bug報(bào)告,其實(shí)個(gè)人一直覺得bug報(bào)告高于一切,它是測(cè)試人員價(jià)值的體現(xiàn)。也許是工作的性質(zhì),我經(jīng)常將香港的同事和深圳同事做比較,發(fā)現(xiàn)他們一個(gè)優(yōu)點(diǎn)特別值得我們學(xué)習(xí):做什么事一般不會(huì)去衡量事情的終利益,更多的是決定后考慮如何更好地把事情做好。

腳踏實(shí)地,希望我自己也能夠這樣努力下去。
•盡量減少重現(xiàn)的步驟以達(dá)到用少的步驟來重現(xiàn)問題;這對(duì)編程人員來說是很有幫助發(fā)現(xiàn)問題根源的。
 
•好由報(bào)bug的人驗(yàn)證bug是否可以關(guān)閉。任何人都可以修復(fù)bug,但只有那個(gè)發(fā)現(xiàn)bug的人才能夠確信bug是否真正的已被修復(fù)。
•在將bug解決時(shí)要分清楚解決的方式。一般的bug系統(tǒng)允許你通過例如“fixed(已修復(fù))”, “won't fix (不打算修復(fù))”, “postponed(以后修復(fù))”, “not repro(不可重現(xiàn))”, “duplicate(重復(fù))”或“by design(設(shè)計(jì)如此)”方式來解決bug。同時(shí)好寫上解決的方式或非正常解決問題(如以上幾種類型)的原因。
 
•當(dāng)你的bug報(bào)告以“not repro(不可重現(xiàn))”打回給你時(shí),先檢查一個(gè)步驟是否有遺漏或清晰,再去找編程人員。編程人員通常是在無法用bug報(bào)告中的步驟重現(xiàn)bug時(shí)才選擇這個(gè)選項(xiàng)。

 
•仔細(xì)地追蹤版本信息。你給測(cè)試人員的每一個(gè)build都應(yīng)該有一個(gè)build ID編號(hào),這樣剛?cè)腴T的測(cè)試人員不會(huì)重新測(cè)試壓根沒有修復(fù)的那個(gè)版本。
•如果你是個(gè)編程人員,并且正陷入讓測(cè)試人員使用bug管理庫的苦惱中,你只要不用其他方法接受bug報(bào)告。如果你的測(cè)試人員習(xí)慣將bug報(bào)告用郵件的形式發(fā)給你,你只需用一個(gè)簡(jiǎn)短的消息回復(fù)他們:“請(qǐng)將它們輸入到bug庫中,因?yàn)槲覠o法追蹤?quán)]件。”
•如果你是一個(gè)測(cè)試人員,并且正陷入讓測(cè)試人員使用bug管理庫的苦惱中,你只要不和他們說任何有關(guān)bug的事――將bug輸入到數(shù)據(jù)庫中,數(shù)據(jù)庫會(huì)自動(dòng)發(fā)送email給他們。
•不要添加太多的新字段。有些人喜歡添加一些新的字段來追蹤他所需的信息。試想一下,測(cè)試人員要花多長(zhǎng)的時(shí)間去填寫一個(gè)幾十個(gè)字段的表單,而且又有多少人還愿意填寫下一個(gè)bug呢。
•如果知道bug出現(xiàn)模塊的負(fù)責(zé)人員或?qū)⒔鉀Qbug的開發(fā)人員,請(qǐng)?jiān)跇?biāo)題中明確的指出,例如你發(fā)現(xiàn)的bug是有關(guān)增加人員的,那么在標(biāo)題中可以指出“增加人員時(shí)出現(xiàn)xx錯(cuò)誤”。

•如果用英文報(bào)bug,好使用現(xiàn)在時(shí)或過去時(shí),例如用"appears"而不是"will appear"。

•不要使用完全的大寫形式,那樣會(huì)讓人感覺象控訴。不要使用感嘆號(hào)或其他表現(xiàn)個(gè)人感情色彩的詞語或符號(hào)。

•不要使用含糊的詞語(例如,好像,似乎)來描述發(fā)現(xiàn)的現(xiàn)象。

•請(qǐng)考慮如下問題:
1.同一軟件中的相似功能是否有相同的問題?
2.其他的瀏覽器是否有相同的問題?
3.其他的軟硬件配置是否有相同的問題?
4.其他的區(qū)域(locales)是否有相同的問題?
5.不同的安排設(shè)置是否有相同的問題?
6.以前的版本否有相同的問題?

•編寫bug report沒有什么定式,沒有的范本,基本的是能夠讓客戶或目標(biāo)修改,瀏覽bug report人員看懂,而且在短時(shí)間內(nèi),而不需反復(fù)思考的。其他有時(shí)要考慮目標(biāo)讀者的一些喜歡。例如有些類似的bug到底是合并還是單獨(dú)提交,bug的步驟劃分(到底是每一步都為一點(diǎn),還是有些點(diǎn)可以合并)。在這一點(diǎn)上我覺得“靈活和適應(yīng)”是很關(guān)鍵的。

•在發(fā)現(xiàn)一個(gè)Bug并填寫完bug report之后,在review的時(shí)候,需要特別注意的一點(diǎn)是:這個(gè)bug report會(huì)不會(huì)讓其他人還有聯(lián)想或發(fā)揮的空間。一個(gè)好的bug report是不可以細(xì)分的,  換句話說是這個(gè)bug是不會(huì)讓他人覺得你還有些地方需要在測(cè)試一下,或許還有其他的問題。例如,有個(gè)測(cè)試人員發(fā)現(xiàn)在輸入16這個(gè)數(shù)字(允許范圍內(nèi))且提交時(shí)系統(tǒng)會(huì)返回一個(gè)錯(cuò)誤:不能輸入48以下的數(shù)字。這確實(shí)是一個(gè)錯(cuò)誤,但是如果只按現(xiàn)在的步驟提交,另一個(gè)可能會(huì)有這樣的想法:是不是輸入48以下的數(shù)字都會(huì)有這樣的問題呢?這樣他有可能要求你在測(cè)試其他的數(shù)據(jù)。這樣延長(zhǎng)了這個(gè)bug的生命期,而且浪費(fèi)了大家的時(shí)間。

軟件測(cè)試工具 | 聯(lián)系我們 | 投訴建議 | 誠(chéng)聘英才 | 申請(qǐng)使用列表 | 網(wǎng)站地圖
滬ICP備07036474 2003-2017 版權(quán)所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd