關(guān)鍵字：Bug追蹤
很多朋友都問(wèn)我，為什么那么喜歡研究bug報(bào)告，其實(shí)個(gè)人一直覺(jué)得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á)到用少的步驟來(lái)重現(xiàn)問(wèn)題；這對(duì)編程人員來(lái)說(shuō)是很有幫助發(fā)現(xiàn)問(wèn)題根源的。

·好由報(bào)bug的人驗(yàn)證bug是否可以關(guān)閉。任何人都可以修復(fù)bug，但只有那個(gè)發(fā)現(xiàn)bug的人才能夠確信bug是否真正的已被修復(fù)。

·在將bug解決時(shí)要分清楚解決的方式。一般的bug系統(tǒng)允許你通過(guò)例如“fixed(已修復(fù))”， “won’t fix (不打算修復(fù))”， “postponed(以后修復(fù))”， “not repro(不可重現(xiàn))”， “duplicate（重復(fù)）”或“by design(設(shè)計(jì)如此)”方式來(lái)解決bug。同時(shí)好寫(xiě)上解決的方式或非正常解決問(wèn)題（如以上幾種類型）的原因。

·當(dāng)你的bug報(bào)告以“not repro(不可重現(xiàn))”打回給你時(shí)，先檢查一個(gè)步驟是否有遺漏或清晰，再去找編程人員。編程人員通常是在無(wú)法用bug報(bào)告中的步驟重現(xiàn)bug時(shí)才選擇這個(gè)選項(xiàng)。

·仔細(xì)地追蹤版本信息。你給測(cè)試人員的每一個(gè)build都應(yīng)該有一個(gè)build ID編號(hào)，這樣剛?cè)腴T(mén)的測(cè)試人員不會(huì)重新測(cè)試壓根沒(méi)有修復(fù)的那個(gè)版本。

·如果你是個(gè)編程人員，并且正陷入讓測(cè)試人員使用bug管理庫(kù)的苦惱中，你只要不用其他方法接受bug報(bào)告。如果你的測(cè)試人員習(xí)慣將bug報(bào)告用郵件的形式發(fā)給你，你只需用一個(gè)簡(jiǎn)短的消息回復(fù)他們：“請(qǐng)將它們輸入到bug庫(kù)中，因?yàn)槲覠o(wú)法追蹤?quán)]件。”

·如果你是一個(gè)測(cè)試人員，并且正陷入讓測(cè)試人員使用bug管理庫(kù)的苦惱中，你只要不和他們說(shuō)任何有關(guān)bug的事――將bug輸入到數(shù)據(jù)庫(kù)中，數(shù)據(jù)庫(kù)會(huì)自動(dòng)發(fā)送email給他們。

·不要添加太多的新字段。有些人喜歡添加一些新的字段來(lái)追蹤他所需的信息。試想一下，測(cè)試人員要花多長(zhǎng)的時(shí)間去填寫(xiě)一個(gè)幾十個(gè)字段的表單，而且又有多少人還愿意填寫(xiě)下一個(gè)bug呢。

·如果知道bug出現(xiàn)模塊的負(fù)責(zé)人員或?qū)⒔鉀Qbug的開(kāi)發(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í)或過(guò)去時(shí)，例如用"appears"而不是"will appear"。

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

·不要使用含糊的詞語(yǔ)（例如，好像，似乎）來(lái)描述發(fā)現(xiàn)的現(xiàn)象。

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

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

·在發(fā)現(xiàn)一個(gè)Bug并填寫(xiě)完bug report之后，在review的時(shí)候，需要特別注意的一點(diǎn)是：這個(gè)bug report會(huì)不會(huì)讓其他人還有聯(lián)想或發(fā)揮的空間。一個(gè)好的bug report是不可以細(xì)分的，  換句話說(shuō)是這個(gè)bug是不會(huì)讓他人覺(jué)得你還有些地方需要在測(cè)試一下，或許還有其他的問(wèn)題。例如，有個(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ì)有這樣的問(wèn)題呢？這樣他有可能要求你在測(cè)試其他的數(shù)據(jù)。這樣延長(zhǎng)了這個(gè)bug的生命期，而且浪費(fèi)了大家的時(shí)間。