1、用例覆蓋程度
毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標準，如果漏測就杯具了。
2、用例是否已經達到工作量最小化
在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試對象，也有不同的方法來保證：對于網頁背后的php邏輯，可以通過在網頁上測試后，用一些工具比如xdebug來統計代碼覆蓋率;對于向外提供接口的server，采用的方式就是分析在外面暴露的接口設計用例，大致的通過接口參數來估計一下分支判斷的情況。
3、用例的分類以及描述是否足夠清晰
用例的分類，在這里是指相同類型的用例是否放在一起了。例如：接口類的用例，參數的取值范圍是1-3，但是現在卻傳入4;數據類用例，狀態機現在位于狀態2，卻要求狀態跳轉到無法到達的4;邏輯類用例，正常功能的產出等。將相同類型的用例放在一起，有助于理清思路，清楚了解用例設計是否完備。
用例的描述，是指描述的清晰程度是否能夠形成文檔。例如上面參數取值范圍的例子，用例這樣寫：“傳入錯誤的值”或者“傳入非1-3的值”，明顯沒有寫成“傳入值4”有效。這與寫程序一樣，總是寫閉區間的范圍而不是開區間。
4、用例是否表明了測試目的
寫明用例的測試目的，對文檔的易于理解性和工作交接的好處不言而喻，現代軟件工程不可能只有一個人在做事情，項目于人員的變動也是難免的。在過程中留下足夠的信息，可以在后續工作提高很多效率。
5、測試用例的易于維護性
如果被測對象有所升級，測試用例的說明或者腳本是不是容易維護呢?例如在有狀態機的情況下，測試用例之間是相互依賴的(即需要一定的執行順序)，這樣被依賴的用例修改后，后端不需要同步根據修改。而如果用例之間沒有相互依賴關系(如用例是自己造的數據，不是依賴于前端的產出)，可能一旦有變化，就需要修改這兩個。當然，這兩種情況不能絕對的說哪種好，是需要看實際使用時候的情況進行取舍的。不過，通過一些系統性的工具支持，也會出現一種做法絕對性的好于另外一種的情況，情況很多，做法也有很多，在這里就不多說了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
