淺說《測試用例》----給測試新手的(2)

　　項目時間不允許

　　這一項是不太厚道的做法，如果不是急需交付客戶的話，盡量不要這樣做;當然了，如果只是給客戶展示或試用，可以在之后進行補充和完善測試用例。

　　不要編寫不完整或別人看不懂的測試用例，那樣就沒有意義了。

　　============個人閑聊內容，歡迎指正========

　　四、停止軟件測試的標準。

　　語句覆蓋最低不能小于80%，測試需求覆蓋率達到100%，測試用例覆蓋率達到100%，一、二級缺陷修復率達到100%，三、四級修復率達到80%。

　　(上面一句是再網上找的，不是標準，只是個參考)

　　bug等級：

　　一級：非常嚴重的bug

　　二級：嚴重的bug

　　三級：一般性的bug

　　四級：建議性問題

　　五、關于探索性測試

　　完全的執行測試用例時一件非?？菰锏氖虑?，個人在執行測試用例時會做一些，其它的非常規性的操作，看系統是否會有相應的處理和提示。我的一部分bug就是再這種非常規操作下發現的。

　　當然了真正的探索性測試需要對產品的深入了解，以及軟件開發技術有一定的深度和寬度。姑且把我們的探索性測試看成是瞎搗鼓吧!呵呵。

　　六、 交叉測試

　　有木有發現，當我們第一遍測試系統時，會非常認真，但要我們測試第二遍時，我們不愿意像第一次那樣認真的去測了，這不能說明我們不負責，而是每個人都有的心理現象。這個時候，我們可以和其它測試人員交換功能來測試，提高效率，而且更容易發現問題。

　　七、測試的目的

　　1. 我們讓它做的它必須會做。

　　2. 我們不讓它做的它必須不會做。

　　可能你會發現有附加功能的時候，就是客戶沒有要求，我們加了這樣的功能，可能加了這點功能系統看上去會更好。這時怎么辦?算問題么?

　　作為開發人員，中規中矩的做東西最好，如果真的有非常好的功能要加的話，需要和客戶溝通，然后寫到需求里。畢竟多一點功能多一點風險。呵呵

　　作為測試人員，凡是不符合需求文檔的都需要當問題點提出。責任分明，以免后續麻煩。

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