1.清晰地描述Bug：描述Bug時要用簡短的陳述句并能準(zhǔn)確指出問題所在。描述中可能需要提供一些步驟來重現(xiàn)這個 Bug，同時這個簡短Bug描述必須能夠準(zhǔn)確地表達(dá)出問題的本質(zhì)所在。例如，假如針對一個來自服務(wù)器的錯誤，Bug描述要對當(dāng)完成什么操作時，這個服務(wù)器錯誤就會發(fā)生做詳盡的說明。
2.不要放過你判斷：雖然你滿懷信心地確信你發(fā)現(xiàn)的Bug的真實性，但你沒寫到Bug報告中，這好像代表你正放過這個發(fā)現(xiàn)的Bug。很可能會發(fā)生一起論戰(zhàn)，這將反映出你作為測試人員的優(yōu)越感。你主要的目標(biāo)應(yīng)該是讓你的Bug報告令人信服，以支持你發(fā)現(xiàn)的Bug，唯一的目的是讓Bug 最終關(guān)畢。在Bug報告中試著使用外交的表達(dá)方式，而不要使用官方的表述來贊成這個Bug，這樣你的報告反而會令人不愉快。最好的方法是使用建議的方式。愉快的方式總能被采用。
3．重現(xiàn)的步驟：如何利用對條件設(shè)置的解釋以重現(xiàn)并獲得Bug的精確點，這必須要在Bug報告中講述清楚。例如，對于一個繪圖軟件，測試人員在找Bug之前，需要和開發(fā)人員就他已經(jīng)做了什么進(jìn)行交流。細(xì)節(jié)必須詳細(xì)說明，像按什么順序，點擊了哪個按鈕。對于按照提示輸入命令而運行的程序，在測試Bug之前，應(yīng)該詳細(xì)地說明輸入命令的詳細(xì)信息。
4.使用簡潔的語言：人們不喜歡讀包含復(fù)雜的專業(yè)術(shù)語和繞口的大段的段落。一個好的Bug報告要包含短的但是表達(dá)清晰的語子。它應(yīng)該只包含與Bug有關(guān)的論述。不必要把Bug報告做的過于復(fù)雜和寫太多事實而篇幅過于長。避免解說過多對重現(xiàn)Bug沒有任何幫助的細(xì)節(jié)。大家都普遍知道的事，就不必寫在Bug報告中了。
5.引用相關(guān)的例子：大部分情況下，要重現(xiàn)一個特殊的Bug，必須輸入一些特殊的數(shù)據(jù)。但是不要做模糊的表述，像提供一個聯(lián)系表中無效的人名并保存，應(yīng)該說在名字域中輸入像035bbb@$%這樣無效的輸入并點擊保存。為了使Bug能快速得到處理，測試人員必須努力提供所有相關(guān)的、關(guān)鍵的信息來幫助開發(fā)人員。
6.提供參考信息：以防一個特殊的Bug與說明文檔或其他的關(guān)于工程的文檔相沖突，Bug報告必須得供充分的關(guān)于這種特殊情況的參考信息或與文檔中相沖突條款的數(shù)目。
7.為Bug分配優(yōu)先級和嚴(yán)重等級——沒有為Bug設(shè)置嚴(yán)重級別和優(yōu)先級別的Bug報告是不完整的。
Bug嚴(yán)重級別：指的是這個Bug破壞系統(tǒng)的危險程度。Bug嚴(yán)重級別說明了這個Bug的破壞程度。嚴(yán)重級別是與Bug緊密聯(lián)系、永恒不變的一個特性。
Bug的嚴(yán)重級別分為四類，下面進(jìn)行分別描述：
Bug的優(yōu)先級：指的是Bug 要求被解決的緊急程度。它描述了Bug的重要性。Bug的優(yōu)先級別可能會根據(jù)測試的日程安排而改變。一共有三個優(yōu)先級別，如下：
8.通過抓屏截圖來解釋——正如諺語說的“一圖勝千言”。當(dāng)我們發(fā)現(xiàn)一個錯誤，最好對這個錯誤進(jìn)行抓屏截圖。如果錯誤是可見的，抓屏將幫助開發(fā)者準(zhǔn)確地理解這個問題。這個階段開發(fā)者應(yīng)該首先集中集力清晰理解這個問題，而不用試著去解決這個問題。
這樣的抓屏應(yīng)該做為證劇附在Bug報告中。這樣測試人員就可以很好地更清晰地和開發(fā)人員交流解釋這個Bug。
9.時刻準(zhǔn)備著向開發(fā)人員展示你發(fā)現(xiàn)的Bug：Bug報告中最有趣的部分是，軟件測試人員需要時刻準(zhǔn)備著向開發(fā)人員展示他發(fā)現(xiàn)的Bug，同時需要說服開發(fā)者，報告中的Bug都是真實存在的且需要解決的，因為它們將影響應(yīng)用的性能。在這個過程中，軟件測試工程師一定要為下面的幾種情況做好準(zhǔn)備：
?。?）開發(fā)者通常會說某個特定Bug不能重現(xiàn)。報告這個Bug的最好方法是向開發(fā)者展示它?？梢哉堥_發(fā)者看看在你計算機(jī)上運行的情景，加載應(yīng)用，為這個問題提供真實的證明。這樣他們可以真實地看到并了解你是如何操作應(yīng)用的，如何和應(yīng)用交互的，軟件對提供的輸入有怎樣的反應(yīng)。應(yīng)該避免在最短的時間內(nèi)一腔熱情地報告大量的不能重現(xiàn)的Bug。
?。?）有時軟件測試人員會在特定的環(huán)境中發(fā)現(xiàn)偶爾才會發(fā)生的缺陷。當(dāng)壓力達(dá)到最大極限，處于測試中的應(yīng)用處于崩潰狀態(tài)時才會出現(xiàn)這種缺陷。當(dāng)軟件測試人員向開發(fā)者展示同樣情景以證明這種缺陷時，這時應(yīng)用程序又運行正常了，這讓測試人員很覺尷尬。因些一個好的測試人員要有耐心，同時要保留測試數(shù)據(jù)和抓屏等信息，為證明自己的觀點建立一個可防御的機(jī)制。
?。?）如果測試人員提供給開發(fā)人員一個包含各種操作和輸入數(shù)據(jù)等的表，當(dāng)開發(fā)人員按表中的說明在他的系統(tǒng)上運行時，并沒有發(fā)現(xiàn)任何錯誤。這說明測試人員沒有提供足夠的信息。開發(fā)者所用的系統(tǒng)和測試人員的系統(tǒng)有可能在配置上會有所不同，這個會導(dǎo)致一些錯誤并不能在開發(fā)者的計算機(jī)系統(tǒng)上出現(xiàn)。測試人員也可能沒有完全理解程序的需求，測試人員和開發(fā)人員看的是同樣的界面，但卻有著不同的看法。對于同一個測試結(jié)果，測試人員認(rèn)為它是錯誤的但開發(fā)人員卻認(rèn)為它是正確的，這種情況也可能會發(fā)生。所以為了避免這種情況，最好從你認(rèn)為的需求是什么，你真正看到了什么,發(fā)生了什么來支持你的觀點。
