編寫測試用例(這裡指功能測試用例的編寫)，首先要做的就是設計測試用例的模闆。每個公司都有适合自己公司用例編寫的模闆，各有各的特點。

　　測試用例的格式包括，測試用例摘要、測試用例需求編号(一個需求設計說明書可以分好幾個用例編寫)、編寫用例的日期、編寫人員、編寫日期、前置條件、準備數據等等。格式沒有固定的要求，可以根據自己測試用例設計的思路，對測試用例的格式作相應的改變。

　　下面以一個登錄窗口為例，說說我設計登錄界面的思路和方法。我把這個測試用例分為三層結構，表單測試、邏輯判斷、業務流程。

　　第一層，表單測試為最底層(最基礎的)

　　這部分的測試用例是對登錄窗口這個界面的輸入框、按鈕功能、界面等最基本功能的測試。一般來說登錄用戶名和登錄用戶密碼是輸入框的形式體現，那麼，我們需要的是針對這兩個輸入框進行功能的測試。

　　這時，我們隻需要考慮這個輸入框的功能，而不需要考慮業務方面的内容。這樣，我們考慮的就是這個輸入框的長度限制是多少?能否輸入特殊字符?能否輸入全角字符?當然，登錄窗口還有其他按鈕，例如登錄按鈕、退出按鈕、界面設計等，這一層的測試用例隻是對他們最簡單的功能的測試。

　　我覺得這一層的測試用例對新開發項目很重要，也必須執行，因為這些是最基本的功能保證，當項目進入維護階段後，如果沒有修改就不需要執行這部分的測試了或者說把這層的用例優先級置為最低，時間不充足的情況就不用去執行

　　第二層，邏輯判斷層

　　根據需求的設計，各功能之間的簡單邏輯聯系。以登錄窗口為例，賬号登錄，賬号和密碼必須對應才能登錄，否則登錄失敗。根據這一點，我們就可以從這個要求設計這一層測試用例。

　　例如，賬号和密碼不一緻時;賬号為空時;密碼為空時;賬号密碼對應時等等情況。輸入這些情況時，程序是怎麼樣的邏輯控制的?控制是否正确?是否有相應的提示信息?

　　我覺得，這一層的用例是最常規的一層，平時使用這個軟件用經常碰到的一些情況，在常規測試或修改這部分的功能之後，這一部分的測試用例也必須執行。

　　第三層，業務流程層

　　這部分不關心軟件本身的基本功能，而是關心這個軟件的業務有沒有實現，不同的需求就有不同的業務需求。

　　以登錄窗口為例，就可能有不同的需求，可能用戶要求停用的賬号能夠登錄系統(可能要求登錄後不允許進行其他操作)，也可能用戶直接要求停用的用戶賬号不準登錄系統

　　根據不同的業務需求，就有不同的業務流程。這樣的測試用例，我們就隻要考慮業務需求，仍然以登錄窗口為例，我們就隻要考慮删除的用戶能否登錄?停用的用戶能否登錄?超級用戶是如何登錄的?普通用戶是以何種方式登錄的?

　　簡單地說，這層的用例隻描述業務流程，不關心具體這個業務是怎麼實現的，執行這部分用例時，不要考慮哪個輸入框控制了多少長度，能否輸入空格等其他功能，因為這部分的測試需要基于上面兩層的測試用例都已經測試通過了，所以在項目維護階段或者說時間很緊迫的階段，我們隻需要執行這部分的用例，保證業務能夠通暢的完成。

　　其實個人覺得在執行這部分用例時，包含了對基本功能的測試，一些明顯的問題應該能被發現，雖然嚴格來說測試覆蓋率很低，但是基本能達到要求。

　　總結：

　　這三層的組合起來才是一個完整的測試用例。這是我個人對測試用例設計的一個思路和方法。真正設計這個測試用例的時候，可能會使用到黑盒測試用例的方法，

　　例如等價類劃分、邊界值分析、錯誤猜測法(主要是個人經驗)、正交分解等方法針對具體情況設計測試用例。分層測試用例的思路主要來自對自動測試實現的考慮。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!