設計測試用例就好比程式設計師編寫**。程式設計師講究的是**是否有很高的可讀性、邏輯是否完整無漏洞。測試人員也一樣，也需要講究用例是否有很好的可讀性，邏輯是否完整清晰。
禁忌1. 設計的用例邏輯性差
乙個模組，若干個測試點需要用幾十甚至上百條用例來全面覆蓋到。邏輯性差的用例，瀏覽完這若干條用例後，給人的感覺是想到了什麼測試點就寫了什麼，並不能很快總結出哪些測試點未覆蓋到。因為整個瀏覽的過程你的思維是緊跟著設計者走的，設計者思路不清晰，讀者也會沒有頭緒。而邏輯性強的用例，閱讀時你能馬上找到設計者是思維過程，條例清晰，知道他在設計用例時思考的順序是什麼。這點不光對評審用例者、閱讀用例者幫助很大，對設計用例人員來說，也能更全面的覆蓋測試點，減少遺漏點的發生。
禁忌2. 用例標題概括性不足
標題可以說是整條用例的核心。它告訴了閱讀者這條用例的測試點是什麼，設計目的是什麼。甚至熟悉該產品的人，不需要看用例的步驟就知道如何執行這條用例。但是在評審用例時，發現了大量的用例，存在標題概括性不足，甚至標題和步驟中的測試點並不匹配的情況。比如乙個用例中包括了測試點a1、a2、a3，但標題中只能體現出a1，甚至b1。
禁忌3.用例設計不合理
這個屬於高階一級的要求了。用例標題準備，思路清晰且覆蓋了全部的測試點，這就已經達到了標準。如果你想高要求，讓你的用例更完美，就需要考慮如何設計你的用例才更合理，可執行性更高，效率更高。比如功能a，有3個測試點a1、a2、a3，但執行時，想要測試a3，所包含的必經步驟就一定會完成a2。你可以設計3條用例分別對應a1、a2、a3。但更好的方式一定是設計2條用例a1和a2_a3。這樣設計，提高了執行用例者的工作效率。尤其是一些太基礎的測試點，沒必要單獨設計成一條用例，如下拉框中有值，下拉框中的值可以被選擇這些。
當然如果是自動化測試用例，有可能就另當別論了。因為a2_a3這樣的用例，在執行自動化測試時，會造成失敗分析相對複雜。你不能直觀的判斷是a2出錯還是a3出錯。
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...
測試用例設計
1.名稱與標識 2.測試追蹤 3.用例說明 4.測試的初始化要求 5.測試的輸入 6.期望的測試結果 7.評價測試結果的準則 8.操作過程 9.前提和約束 10.測試終止條件 編寫用例規範 1 系統性 對系統業務流程要完整說明整個系統的業務需求 系統由幾個子系統組成以及它們之間的關係 對模組業務流程...
測試用例設計
測試用例格式 用例編號 a b c d a 產品或專案名稱 b 用例屬性 st,it,ut c 客戶管理 新增客戶，什麼型別的客戶 d編號 例 crm st 客戶管理 新增客戶 001 測試項 針對於某種物件的測試用例 客戶管理 新增客戶 20個字元的客戶資訊 新增名稱包含單引號的客戶資訊 用例屬性...