如何記錄一個(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)境、錯(cuò)誤行為的描述。報(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í)錯(cuò)誤的,因?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)錯(cuò)誤的幾個(gè)步驟。