如何記錄一個(gè)合格的Bug

如何記錄一個(gè)大家認(rèn)為好的，尤其是開發(fā)人員認(rèn)為好的Bug呢？撰寫缺陷報(bào)告的一個(gè)基本原則是：客觀地陳述所有相關(guān)事實(shí)。

一個(gè)合格的Bug報(bào)告應(yīng)該包括完整的內(nèi)容，至少應(yīng)該包含五個(gè)方面：發(fā)現(xiàn)問題、預(yù)期行為的描述、問題重視步驟、問題出現(xiàn)的環(huán)境、錯誤行為的描述。報(bào)告發(fā)現(xiàn)問題的版本，開發(fā)人員需要知道問題出現(xiàn)的版本，才能獲取一個(gè)相同的版本來進(jìn)行問題的重視。版本的標(biāo)識有助于分析和總結(jié)問題出現(xiàn)的集中程度，需要注意的是，有些Bug可能會在不同的版本中出現(xiàn)，例如，某個(gè)BUG在版本1.1中出現(xiàn)了，測試人員錄入了Bug，ID為101，開發(fā)人員也進(jìn)行了修改，經(jīng)驗(yàn)證關(guān)閉了。但是，改Bug到了版本1.4時(shí)又出現(xiàn)了，這時(shí)，有些測試人員回頭把Bug101的狀態(tài)改成Reopen，這時(shí)錯誤的，因?yàn)檫@個(gè)Bug是在新的版本中出現(xiàn)的，即使是同一種現(xiàn)象，甚至是同一個(gè)原因造成的，也不應(yīng)該Reopen，而是新加一個(gè)，因?yàn)檫@代表了一個(gè)質(zhì)量回歸問題。這個(gè)缺陷確實(shí)又出現(xiàn)了，因?yàn)檫@個(gè)缺陷造成了損失，測試人員需要重新測試、驗(yàn)證并進(jìn)行報(bào)告，開發(fā)人員需要再次修改程序并編譯，如果Reopen,則可能造成質(zhì)量統(tǒng)計(jì)時(shí)漏算了一個(gè)缺陷。

正確的做法是，錄入之前再多做幾次嘗試，盡量把操作步驟縮減到必須要執(zhí)行才能重現(xiàn)錯誤的幾個(gè)步驟。