1、用例覆蓋程度
毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例
的最重要評價標準，如果漏測就杯具了。
2、用例是否已經達到工作量最小化 在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如
條件覆蓋
，分支覆蓋，正交覆蓋等方法。面對不同的測試物件，也有不同的方法來保證：對於網頁背後的php邏輯，可以通過在網頁上測試後，用一些工具比如xdebug來統計**覆蓋率；對於向外提供介面的server，採用的方式就是分析在外面暴露的介面設計用例，大致的通過介面引數來估計一下分支判斷的情況。
3、用例的分類以及描述是否足夠清晰 用例的分類，在這裡是指相同型別的用例是否放在一起了。例如：介面類的用例，引數的取值範圍是1-3，但是現在卻傳入4；資料類用例，狀態機現在位於狀態2，卻要求狀態跳轉到無法到達的4；邏輯類用例，正常功能的產出等。將相同型別的用例放在一起，有助於理清思路，清楚了解用例設計是否完備。
用例的描述，是指描述的清晰程度是否能夠形成文件。例如上面引數取值範圍的例子，用例這樣寫：「傳入錯誤的值」或者「傳入非1-3的值」，明顯沒有寫成「傳入值4」有效。這與寫程式一樣，總是寫閉區間的範圍而不是開區間。
4、用例是否表明了測試目的 寫明用例的測試目的，對文件的易於理解性和工作交接的好處不言而喻，現代軟體工程不可能只有乙個人在做事情，專案於人員的變動也是難免的。在過程中留下足夠的資訊，可以在後續工作提高很多效率。
5、測試用例的易於維護性
如果被測物件有所公升級，測試用例
的說明或者指令碼是不是容易維護呢？例如在有狀態機的情況下，測試用例之間是相互依賴的（即需要一定的執行順序），這樣被依賴的用例修改後，後端不需要同步根據修改。而如果用例之間沒有相互依賴關係（如用例是自己造的資料，不是依賴於前端的產出），可能一旦有變化，就需要修改這兩個。當然，這兩種情況不能絕對的說哪種好，是需要看實際使用時候的情況進行取捨的。
什麼樣的測試用例是好的測試用例
1 用例覆蓋程度毫無疑問，這一點應該是最重要的，無需多說，覆蓋率最大化是一套測試用例的最重要評價標準，如果漏測就杯具了。2 用例是否已經達到工作量最小化 在滿足用例覆蓋程度最大化的前提下，應該盡量減小執行用例所需要的工作量。這些方面的方法有不少，如條件覆蓋，分支覆蓋，正交覆蓋等方法。面對不同的測試物...
不能發現BUG的測試用例不是好的測試用例嗎？
一般情況下技術崗面試都需要經歷面試和筆試部分，面試過程中主要採用問答的形式，一般沒有完全固定的回答，主要是根據自己的工作經驗應答面試官的問題，而筆試部分更注重基礎知識以及問題的常規解決方案。下面it技術宅男為大家整理了18個常見的問題 1 專案中相關需求問題，測試可以直接和客戶溝通嗎？a1 可以，最...
好的測試用例應具備的條件
每個測試新人都會有這樣的困惑 乙個怎樣的測試用例，才是好的測試用例呢。不同的公司對用例的要求雖都不同，但用例三要素 編號，標題，步驟是都包含的。只是如何把握乙個用例的步驟，期望等細化程度。基本是各執一詞。對於功能測試來說，衡量乙個測試用例的好壞，還是有一些共性可參考的。注 該共性來自肖利瓊老師的 軟...