6、如果版本未更新，
1）建議著重進行業務邏輯方面測試，在電腦上以文檔形式畫出簡單的業務邏輯圖片，重點說明：一定 要盡量考慮所有的情 況，因為這樣的BUG要么就沒有，一旦有就是HIGH
2）建議進行環境測試（當然要根據需求測試相應的環境）
3）嚴格核對需求文檔，防止需求遺漏
7、嚴格按照缺陷提交說明提交BUG，因為這有可能涉及BUG的統計問題，（一般公司的缺陷描述：系統名稱_功能模塊，缺陷描述，要具體問題具體對待）
優先級和嚴重程度不要夸大也不要降低，實事求是，因為這與開發和測試的績效考評有掛鉤，要是夸大缺陷，會影響開發的績效考評，降低會影響自己的績效考評，建議：系統級（影響流程）和跳黃頁（報服務器錯誤的，這類缺陷有的是服務器配置錯誤導致）建議為高，功能實現建議為中，界面易用，或者不影響系統使用的其他問題建議為低，具體級別公司會有規定，如果沒有規定，可以參考一下我的建議
8、測試沒有空閑。項目在不同階段，會有些時間很‘空閑’。建議：
1）把測試管理工具中的缺陷全部分類導出，總結一下哪些模塊容易產生哪些缺陷，重點看一下自己沒發現或沒有考慮到的缺陷，有多余時間可以看一下 CLOSED_NBUG的缺陷，這類BUG一般都是需求不明確，需求變更而產生的，看一下這類缺陷，可以總結一下哪些需求容易產生誤解，和出現了哪些新需求。
2）把測試管理工具中的用例細細看幾遍，學習別人的用例編寫方法和思想，空閑時間可以自己試著編寫，看自己編寫的與別人編寫的用例差距在哪，從而不斷完善。
3）進入一些測試論壇，比如51testing，把自己的困惑和經驗和大家一起分享，共同學習，共同進步！
好了，今天先寫這些了，都是自己的一些體會，要是有什么不對的地方，希望大家多多指正，謝謝！主要針對新人寫的，大蝦看了別見笑，測試經驗中有的不適合大蝦。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
