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