軟件測試——關于提交bug隨筆

　　所謂bug也就是進行某一輸入后，軟件輸出是錯誤的或者不是我們所期望的結果。 bug在英語中是臭蟲的意思。在以前的大型機器中，經常出現有些臭蟲破壞了系統的硬件結構，導致硬件運行出現問題，甚至崩潰。時間長了，bug被引伸為錯誤的意思，什么地方出了問題，就說什么地方出了bug.

　　提交bug時描述的越詳細越好。隨著測試管理工具的完善、利用，提交bug時很多項系統已幫我們自動實現了，如提交者姓名、提交日期等。但有些項仍然需要我們自己填寫。如摘要、操作步驟、預期結果、輸出結果等。

　　下表是提交一個一般都要包含的信息，根據實際項目的不同，需要適當進行增加：如硬件配置、測試環境等。

　　注意：

　　摘要：要求用一句簡短的話概括出提交的問題;

　　預置換條：也就是我們的測試環境，出現某一問題時的先決條件，如果沒有說明則為默認情況;

　　操作步驟：最好使用傻瓜式，一步步地把具體操作步驟詳細的描述出來;

　　預期結果：我們預期的正確輸出結果是什么樣的;

　　實際結果：實際的輸出結果是什么樣的;

　　……

　　提交bug的一些注意事項：

　　1. 發現一個問題時，不必急著提交，可以先做驗證(包括復現、對比測試等)進行證實，看是概率性問題還是每次必現的問題，需要時也應使用不同版本不同機器做對比驗證，當然，如果已經很確信是一個bug了，也就不用浪費時間去對比驗證了。

　　2. 描述要清晰、準確。關于這點，如測試游戲時，提交一個bug描述為“游戲幫助說明中有錯別字”，并沒有說出哪一頁哪一行以及具體哪個字錯了，應該修改成什么樣的。因此就不能說是個好的描述。下面一些bug描述如“藍牙的名稱顯示錯誤”、“插充電器無提示”之類的則就不是一個明確的描述了。

　　3. 要考慮開發人員的感受，有些問題尤其是有些主觀性比較強的問題，在問題描述中一般不要出現帶強烈感情色彩的詞語標點符號，如“要求”、“必須”和感嘆號等(特殊情況除外)。在提交此類問題時可以使用一些諸如“建議……”、“希望……”、“請……”之類比較委婉些的詞語。

　　4. 不能確認一個現象是不是一個bug的時候可以向其他人或者開發人員進行確認，然后再去提交;

　　5. 概率性的問題，測試過程中難免遇到一些概率性問題，很難找出其產生的規律，甚至該問題在測試過程中只出現一次，對于此類問題也一定要提交，并補充說明無法復現或者無規律;

　　6. 描述問題時，要實事求是，不要夸大，比如概率性問題，本來出現的概率只有10%，你把它寫成50%都是不應該的!

　　7. 提交bug時，應該在描述清楚問題點的時候把正確的預期輸出結果寫明，即正確的結果應該是什么樣的，這點很重要?，F在我們提交的bug中有些測試和開發雙方都知道該修改成什么樣子了，而在bug描述中未寫出修改成什么樣子的，如“來電時按掛機鍵不能拒接來電”這樣描述一個bug，并沒有寫明該如何修改，一般這樣描述大家一看就知道該如何修改，所以寫不寫預期正確結果大家都可以接受。但對于有些bug的描述一定要把預期的正確結果給寫進去，否則開發人員會無所適從，不知道該修改成什么樣子的。

　　8. 如果語言文字難以清楚的描述出問題，最好能附件圖片或者log記錄等做輔助說明。

　　9. 提交測試bug的時候，如果該問題在某一特定環境下才能出現，一定要將該問題產生的環境(硬件、軟件)描述清楚;

　　10. 提交問題前要清楚的知道軟件需求、規格定義。相信很多人都遇到過這樣的尷尬情況，提交了一個重要問題后，卻被告知其實那并不是一個問題，軟件就是那樣設計的或者需求就要求那樣處理的。真是沒面子!

　　11. 有些問題出現了，不一定就是我們測試軟件本身的問題，也可能是其他一些問題導致的，如“手機通話時自動掉線”問題，這有可能是信道切換失敗導致的，是網絡的問題，不是我們手機本身的問題。類似情況還會很多，這都我們有著豐富的產品背景知識。

　　12. Bug提交完畢后，并不是就萬事大吉了，后續跟蹤驗證等還多著呢。

原文轉自：http://www.anti-gravitydesign.com