1、能發現到目前為止沒有發現的缺陷的用例是好的用例：
首先要申明，其實這句話是十分有道理的，但我發現很多人都曲解了這句話的原意，一心要設計出發現“難于發現的缺陷”而陷入盲目的片面中去，忘記了測試的目的所在，這是十分可怕的。我傾向于將測試用例當作一個集合來認識，對它的評價也只能對測試用例的集合來進行，測試本身是一種“V&V”的活動，測試需要保證以下兩點：
* 程序做了它應該做的事情
* 程序沒有做它不該做的事情
因此，作為測試實施依據的測試用例，必須要能完整覆蓋測試需求，而不應該針對單個的測試用例去評判好壞。
2、測試用例應該詳細記錄所有的操作信息，使一個沒有接觸過系統的人員也能進行測試;
不知道國內有沒有公司真正做到這點，或者說，不知道有國內沒有公司能夠將每個測試用例都寫得如此詳細。在我的測試經歷中，對測試用例描述的詳細和復雜程度也曾有過很多的彷徨。寫得太簡單吧，除了自己沒人能夠執行，寫得太詳細吧，消耗在測試用例維護(別忘了，測試用例是動態的，一旦測試環境、需求、設計、實現發生了變化，測試用例都需要相應發生變化)上的時間實在是太驚人，在目前國內大部分軟件公司的測試資源都不足的情況下，恐怕很難實現。但我偏偏就能遇到一些這樣的老總或者是項目負責人，甚至是測試工程師本身，全然不顧實際的資源情況，一定要寫出“沒有接觸過系統的人員也能進行測試”的用例。
在討論這個問題之前，我們可以先考慮一下測試的目的。測試的目的是盡可能發現程序中存在的缺陷，測試活動本身也可以被看作是一個Project，也需要在給定的資源條件下盡可能達成目標，根據我個人的經驗，大部分的國內軟件公司在測試方面配備的資源都是不足夠的，因此我們必須在測試計劃階段明確測試的目標，一切圍繞測試的目標進行。
除了資源上的約束外，測試用例的詳細程度也需要根據需要確定。如果測試用例的執行者、測試用例設計者、測試活動相關人對系統了解都很深刻，那測試用例就沒有必要太詳細了，文檔的作用本來就在于溝通，只要能達到溝通的目的就OK。
在我擔任測試經理的項目中，在測試計劃階段，一般給予測試設計30% - 40%左右的時間，測試設計工程師能夠根據項目的需要自行確定用例的詳細程度，在測試用例的評審階段由參與評審的相關人對其把關。
3、測試用例設計是一勞永逸的事情;
這句話擺在這里，我想沒有一個人會認可，但在實際情況中，卻經常能發現這種想法的影子。我曾經參與過一個項目，軟件需求和設計已經變更了多次，但測試用例卻沒有任何修改。導致的直接結果是新加入的測試工程師在執行測試用例時不知所措，間接的后果是測試用例成了廢紙一堆，開發人員在多次被無效的缺陷報告打擾后，對測試人員不屑一顧。
文章來源于領測軟件測試網 http://www.kjueaiud.com/