1、單個用例覆蓋最小化原則
舉個例子，假如測試乙個功能a，它有三個子功能點a1、a2和a3，可以有如下兩種用例設計方法：
方法1:用乙個測試用例（主要指用例的邏輯部分）覆蓋三個子功能-test_a1_a2_a3
方法2:用三個單獨的用例分別來覆蓋三個子功能-test_a1,test_a2,test_a3
適用範圍：方法1適用於規模較小的工程，但凡是稍微有點兒規模和質量要求的專案，方法2則是更好的選擇，因為它具有如下優點：
1）測試用例的覆蓋邊界定義更清晰
2）測試結果對產品問題的指向性更強
3）測試用例間的耦合度最低，彼此之間的干擾也就越低
上述這些優點的直接好處就是，測試用例的除錯、分析和維護成本最低。每個測試用例應該盡可能的簡單，只驗證你所需內容，不要「摟草打兔子」捎帶著雜七雜八的東西，這樣只會增加測試執行階段的負擔和風險。
此外，覆蓋功能點簡單明確的測試用例，也便於組合生成新的測試。
2、單次投入成本和多次投入成本原則
例如：第一條原則一單個用例覆蓋最小化原則-就有乙個很好的例子，測試a功能的3個功能點a1、a2和a3，從表面上看test_a1_a2_a3這乙個用例在設計和自動化實現時最簡單，但它在反覆執行階段會帶來很多問題：
首先，這樣的用例的失敗分析相對複雜，你需要確認到底時哪乙個功能點造成了測試失敗；
其次，自動化的除錯更為複雜，如果是a3功能點的問題，你仍需要不斷地走過a1和a2，然後才能到達a3，這增加了除錯時間和複雜度；
第三、步驟多的手工測試用例增加了手工執行的不確定性步驟多的自動化用例增加了其自動化執行失敗的可能性，特別是那些基於ui自動化技術的用例；
第四，將不相關的功能點耦合到一起，降低了盡早發現產品回歸缺陷的可能性，這是測試工作的大忌。
例如：如果test_a1_a2_a3是乙個自動化測試用例，並按照a1-a2->a3的順序來執行，當a1存在bug時，整個測試用例就失敗了，而a2和a3並未被執行到。如果此時a1的bug由於某些原因需要很長時間才能修復，則test_a1_a2_a3始終被認為是因為a1的bug而失敗的，而a2和a3則始終沒有被覆蓋到，這裡存在潛在的危險和漏洞。當你在產品就要發布前終於修復了a1的bug，並理所當然地認為test_a1_a2_a3應該通過時，a2和a3的問題就會在這時爆發出來，你不得不繼續加班修復a2和a3的問題。不是危言聳聽，當a2或a3的**與a1的bug修復相關時，當你有很多如此設計的測試用例時，問題可能會更糟。
綜上所述，test_a1_a2_a3這樣的設計，減少地僅是一次性設計和自動化的投入，增加的卻是需要多次投入的測試執行的負擔和風險，所以需要決策時（事實上這種決策是經常發生的，尤其是在設計測試用例時）選擇test_a1_a2_a3還test_a1,test_a2,test_a3，請務必考慮投入的代價。
3、使測試結果分析和除錯最簡單化原則
這條原則實際上是上一條-單次投入成本和多次投入成本原則-針對自動化測試用例的擴充套件和延續。在編寫測試用例測試**時，要重點考慮如何使得測試結果分析和測試除錯更為簡單，包括：用例日誌，除錯輔助資訊輸出等。因為測試用例的執行屬於多次投入，測試人員要經常去分析測試結果、除錯測試用例，在這部分活動上的投入相當可觀的。
介面測試用例設計點
1.是否滿足前提條件 有些介面需要滿足前提條件才能獲得資料 2.是否攜帶預設引數 帶預設的引數不填寫，不傳參，必填參正確填寫測試，其他不填寫 3.根據業務和功能需求進行設計 4.引數是否必填 每一條引數用例只設計某乙個必填引數不填，其餘都正常填寫進行測試 5.引數直接存在制約和關聯 根據實際關聯設計...
測試用例 測試用例設計的關鍵點總結
測試用例設計是每位軟體測試工程師必須的基本技能之一。無論是靠測試經驗，還是靠理論，在時間充足的情況下，最好一 一設計測試點，避免在執行測試時部分測試點被遺漏 在時間緊急的情況下，也應以思維導圖的方式列出測試點。測試用例，即執行測試之前編寫的指導測試過程的文件，主要包括 用例編號 測試目的 用例描述 ...
測試用例設計需要注意的幾個點
測試用例需要注意以下幾點 1 單個用例覆蓋最小化原則下面舉個例子來介紹，假如要測試乙個功能 a，它有三個子功能點 a1，a2 和 a3，可以有下面兩種方法來設計測試用例 方法1 用乙個測試用例 確卻的說是用例的邏輯部分 覆蓋三個子功能 test a1 a2 a3，方法2 用三個單獨的用例分別來覆蓋三...