測試用例的設計一般從分析需求設計說明書開始，了解開發人員設計這個專案的思路、設計的要求、實現的功能等（最好有use case，這樣看起來更清晰）。軟體測試的w模型，就要求測試與開發同步，在開發設計需求設計說明書的時候就開始測試流程，一般情況下，討論需求設計的時候需要測試主管或者組員的參與，了解這個專案設計的總體情況。事實上，測試用例的編寫一般是在需求設計說明書定下來之後才真正的開始的。因為測試用例的內容要以需求設計說明書為依據，設計說明書上沒體現的功能，不需要在測試用例中體現。
編寫測試用例（這裡指功能測試用例的編寫），首先要做的就是設計測試用例的模板。每個公司都有適合自己公司用例編寫的模板，各有各的特點。測試用例的格式包括，測試用例摘要、測試用例需求編號（乙個需求設計說明書可以分好幾個用例編寫）、編寫用例的日期、編寫人員、編寫日期、前置條件、準備資料等等。格式沒有固定的要求，可以根據自己測試用例設計的思路，對測試用例的格式作相應的改變。下面以乙個登陸視窗為例，說說我設計登陸介面的思路和方法。
我把這個測試用例分為三層結構，表單測試、邏輯判斷、業務流程。
第一層，表單測試為最底層（最基礎的）。
這部分的測試用例是對登陸視窗這個介面的輸入框、按鈕功能、介面等最基本功能的測試。一般來說登陸使用者名稱和登陸使用者密碼是輸入框的形式體現，那麼，我們需要的是針對這兩個輸入框進行功能的測試。這時，我們只要考慮這個輸入框的功能，而不需要考慮業務方面的內容。這樣，我們考慮就是這個輸入框的長度限制是多少？能否輸入特殊字元？能否輸入全形字符？當然，登陸視窗還有其他按鈕，例如登陸按鈕、退出按鈕、介面設計等，這一層的測試用例只對他們最簡單的功能的測試。我覺得這一層的測試用例對新開發專案很重要，也必須執行，因為這些是最基本的功能保證，當專案進入維護階段後，如果沒有修改就不需要執行這部分的測試了或者說把這層的用例優先順序置為最低，時間不充足的情況就不用去執行。
第二層，邏輯判斷層。
根據需求的設計，各功能之間的簡單邏輯聯絡。以登陸視窗為例，賬號登入，賬號和密碼必須對應才能登入，否則登入失敗。根據這一點，我們就可以從這個要求設計這一層測試用例。例如，賬號和密碼不一致時；賬號為空時；密碼為空時；賬號密碼對應時等等情況。輸入這些情況時，程式是作怎麼樣的邏輯控制的？控制是否正確？是否有相應的提示資訊？我覺得，這一層的用例時最常規的一層，平時使用這個軟體用經常碰到的一些情況，在常規測試或修改這部分的功能之後，這一部分的測試用例也必須執行。
第三層，業務流程層。
這部分不關心軟體的本身的基本功能，而是關心這個軟體的業務有沒有實現，不同的需求就有不同的業務需求。以登陸視窗為例，就可能有不同的需求，可能使用者要求停用的賬號能夠登入系統（可能要求登入後不允許進行其他操作），也可能使用者直接要求停用的使用者賬號不准登入系統。根據不同的業務需求，就有不同的業務流程。這樣這層的測試用例，我們就只要考慮業務需求，仍然以登入視窗為例，我們就只要考慮刪除的使用者能否登入？停用的使用者能否登入？超級使用者是如何登入的？普通使用者是何種方式登入的？簡單的說，這層的用例只描述業務流程，不關心具體這個業務是怎麼實現的，執行這部分用例時，不要考慮哪個輸入框控制了多少長度，能否輸入空格等其他功能，因為這部分的測試需要基於上面兩層的測試用例都已經測試通過了，所以在專案維護階段或者說時間很緊迫的階段，我們只需要執行這部分的用例，保證業務能夠通暢的完成。其實個人覺得在執行這部分用例時，對包含了對基本功能的測試，一些明顯的問題應該能被發現，雖然嚴格來說測試覆蓋率很低，但是基本能達到要求。
測試用例設計
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個字元的客戶資訊 新增名稱包含單引號的客戶資訊 用例屬性...