如何記錄一個合格的Bug

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

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

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