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