我把這個測試用例分為三層結構，表單測試、邏輯判斷、業務流程。
第一層，表單測試為最底層(最基礎的)。這部分的測試用例是對登陸窗口這個界面的輸入框、按鈕功能、界面等最基本功能的測試。一般來說登陸用戶名和登陸用戶密碼是輸入框的形式體現，那么，我們需要的是針對這兩個輸入框進行功能的測試。這時，我們只要考慮這個輸入框的功能，而不需要考慮業務方面的內容。這樣，我們考慮就是這個輸入框的長度限制是多少?能否輸入特殊字符?能否輸入全角字符?當然，登陸窗口還有其他按鈕，例如登陸按鈕、退出按鈕、界面設計等，這一層的測試用例只對他們最簡單的功能的測試。我覺得這一層的測試用例對新開發項目很重要，也必須執行，因為這些是最基本的功能保證，當項目進入維護階段后，如果沒有修改就不需要執行這部分的測試了或者說把這層的用例優先級置為最低，時間不充足的情況就不用去執行。
第二層，邏輯判斷層。根據需求的設計，各功能之間的簡單邏輯聯系。以登陸窗口為例，賬號登錄，賬號和密碼必須對應才能登錄，否則登錄失敗。根據這一點，我們就可以從這個要求設計這一層測試用例。例如，賬號和密碼不一致時;賬號為空時;密碼為空時;賬號密碼對應時等等情況。輸入這些情況時，程序是作怎么樣的邏輯控制的?控制是否正確?是否有相應的提示信息?我覺得，這一層的用例時最常規的一層，平時使用這個軟件用經常碰到的一些情況，在常規測試或修改這部分的功能之后，這一部分的測試用例也必須執行。
第三層，業務流程層。這部分不關心軟件的本身的基本功能，而是關心這個軟件的業務有沒有實現，不同的需求就有不同的業務需求。以登陸窗口為例，就可能有不同的需求，可能用戶要求停用的賬號能夠登錄系統(可能要求登錄后不允許進行其他操作)，也可能用戶直接要求停用的用戶賬號不準登錄系統。根據不同的業務需求，就有不同的業務流程。這樣這層的測試用例，我們就只要考慮業務需求，仍然以登錄窗口為例，我們就只要考慮刪除的用戶能否登錄?停用的用戶能否登錄?超級用戶是如何登錄的?普通用戶是何種方式登錄的?簡單的說，這層的用例只描述業務流程，不關心具體這個業務是怎么實現的，執行這部分用例時，不要考慮哪個輸入框控制了多少長度，能否輸入空格等其他功能，因為這部分的測試需要基于上面兩層的測試用例都已經測試通過了，所以在項目維護階段或者說時間很緊迫的階段，我們只需要執行這部分的用例，保證業務能夠通暢的完成。其實個人覺得在執行這部分用例時，對包含了對基本功能的測試，一些明顯的問題應該能被發現，雖然嚴格來說測試覆蓋率很低，但是基本能達到要求。
這三層的組合起來才是一個完整的測試用例。這是我個人對測試用例設計的一個思路和方法。真正設計這個測試用例的時候，可能會使用到黑盒測試用例的方法，例如等價類劃分、邊界值分析、錯誤猜測法(主要是個人經驗)、正交分解等方法針對具體情況設計測試用例。分層測試用例的思路主要來自對自動測試實現的考慮。因為我覺得，如果需要實現自動化測試就必須對測試用例進行細分，劃分得越細就越有利于自動化的實現。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
