如何記錄一個合格的Bug

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

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

正确的做法是，錄入之前再多(duō)做幾次嘗試，盡量把操作(zuò)步驟縮減到必須要執行才能(néng)重現錯誤的幾個步驟。