1. 測試 前細化需求，保證對需求理解正確，避免提交存在歧義的缺陷：
測試人員不能在測試時僅僅憑自己的經驗、想法來隨意提交缺陷，每個缺陷必須有對應的需求作爲支撐。如果認爲是需求存在歧義，這樣的情況，應該是在測試前與項目組成員進行溝通，達成一致觀點。儘量減少理解上的歧義，力爭儘早消除無效或爭議的軟件缺陷。
2. 對於自己把握不準的缺陷，提交前進行討論：
在測試過程中，特別是介入項目時間較短的測試人員，由於對業務或需求理解不深，很有可能遇到對缺陷把握不準的情況，這個bug是否該提交呢？這種情況， 最好是跟有經驗的測試人員或者需求人員討論一下，在大家意見一致時再提交。否則，項目中出現了這樣的bug，不僅很難說服開發人員去修改，還有可能讓開發 人員懷疑你的能力。
3. 在提交bug之前，一定要保證bug能夠重現，並且在bug中清楚的描述重現步驟：
有些測 試人員在一發現bug，就馬上提交到缺陷系統，甚至連bug出現的環境，重現的步驟都沒有搞清楚，結果到後來開發人員看不明白，自己也無法重現。這種情況 出現多了，提交缺陷的認可度就會大大降低。所以，在提交bug之前，最好自己多次重現這個bug，搞清楚是在什麼情況下，按什麼步驟會出現這個問題（最好 是找出重現 bug的最簡單步驟），另外，一定需要有截圖，讓開發人員認識到這個問題的確存在，增強說服力，並且也讓開發人員更加容易定位缺陷。
對於較難重現的bug，需要截圖，並且說明在什麼情況下出現的概率，最好是在保留測試環境的情況下，及時找開發人員跟蹤，弄清楚原因。
4. 保證測試環境的準確性，並且做好版本的配置管理 ：
有些bug只有在測試環境中纔可以出現，而在開發環境下是不能重現的。這樣的缺陷很容易讓開發人員認爲是提交了無效的缺陷，實際上是開發與測試的版本不 一致。對於這種情況，我們需要做好版本的配置管理，保證測試環境版本的正確，測試環境部署正確，以及測試環境的獨立性。只有這樣，纔可以減少一些不必要的 溝通，輕鬆說服開發人員修改bug。