更全面的記錄缺陷，你需要了解這些

很多朋友在軟體測試這條路上，都具有很強的業務邏輯分析能力，甚至具有多門語言的編碼能力，認為

bug找到了，開發也確診了，記錄bug就不那麼重要了，可事實是真的如此麼？你是否：

在測試新版本時，接二連三的被開發拉去重現bug？

在測試思路清晰的時候，開發跑過來跟你再三確診bug現象？

在同事幫你迴歸bug的時候，直介面頭跟你總結bug的步驟？

在新人剛來公司不久，迴歸你提的問題單是，只回歸了一種場景？

……

這些都是可以透過更好的記錄bug問題單而解決的。那麼bug記錄單應該都包含哪些內容呢？

一、測試環境

幾乎在所有公司，測試環境都不只一套，只在一個環境上存在問題其它測試環境沒有問題的情況並不少

見，這是其一；其二：只要開發跟你確診過測試環境正常，就可以自己去環境上取相關定位資訊，省去

了不少因為環境而引發的問題；其三：迴歸時也都儘量保證驗證了原測試環境的情況下多回歸幾個其它

的環境，哪怕是在測試環境只有一個的情況下，也為了規範bug記錄而寫上。

二、預置條件

並不是所有bug所存在預置條件，一般是在特定的bug步驟或現象下才會有，但是一般編寫bug問題單時，

預置條件也會算成其中一項。比如，當使用者登入時存在異常，那麼在預置條件中，一定要寫清楚存在的

使用者名稱與密碼，這樣會減輕編寫操作步驟的壓力，從而讓步驟看起來更簡單易懂。

三、操作步驟

操作步驟一定要詳細與全面，但又不能囉嗦，你懂的步驟別人不一定懂，但是過於囉嗦又讓別人看不下

去，舉例：記事本的開啟

正確的步驟：點選“開始”->“程式” ->“附件” ->“記事本”開啟記事本軟體；

錯誤的步驟：開啟”記事本“

錯誤的步驟：點選”開始“，再點選程式，再選擇附件，選擇記事本，雙擊開啟

在操作步驟中，值的注意的是，當一個現象產生的原因有多個場景時，應該在步驟中用case進行區分與

編寫，要注意的是這裡不是指的一個bug中記錄兩個問題

四、預期結果

預期結果是每個提bug的人都會寫的，但是這一塊寫的時候不能讓人產生歧義與誤解。比如，當使用者名稱輸

入特殊字元時，應該給出提示，具體給出什麼樣的提示在預期結果中應該更具體體現，讓任何一個小白

遇到這個現象都能理解正常情況是什麼樣子。

同樣，當操作步驟存在多種case的時候，相應的在預期結果中也應該相對應的給出不同的case

五、實際結果

實際結果只需簡單闡述存在的問題就好。

當操作步驟存在多種case時，一定要在此處寫上每種case所對應的實際結果

六、錯誤截圖

藉助截圖加備註來說明實際結果

七、日誌定位

對於問題出現，測試人員一定要盡所有能力收集所有相關的日誌，並且根據相關的步驟，指出問題產生

的時間點、日誌間資料的聯絡、開發人員拿到日誌就可以直接定位。

八、附件上傳

將所有日誌與附件打包上傳

bug的記錄，雖然存在多種不同的場景，有先發現問題跟開發確認了再記錄的，有先讓開發定位再記錄跟

蹤的，也有現場返回在家裡做記錄的，不管哪種場景也不管現象的複雜與否，bug的記錄都應該保持好的

風格與習慣，只有這樣，才能讓自己有更多的時間去測試更多的bug