很多朋友都問我，為什么那么喜歡研究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í)間。