如何編寫更好的測試用例(二)[2] 測試用例設計
用語言提高可測試性
測試步驟應該編寫在生動的用例中。告訴測試者做什么。例如：
● 做這個。做那個。
● 瀏覽購物車頁面。
● 對比車中物品和屏幕捕獲的物品。
● 點擊
應始終明確的是，是測試者做一些事，還是系統做它。如果一個測試者讀到， “按鈕被按下，”這意味著他或她應該按下按鈕呢，還是它意味著已經按下后驗證系統顯示它?搞亂測試者最好的一種辦法是混淆活動和結果。比如，活動總是在左側，結果在右側。測試者做什么總是一個活動。系統顯示什么或者做什么始終是一個結果。
如果我們知道一個對象的內外，養成一個簡單的習慣，就是以不同的方式提及相同的事情。測試語言要一絲不茍地命名顯屏、字段、服務器、Web網頁、或其他測試對象。在一個開發團隊，我們習慣于在某些對象甚至是原型以前，一般就提到它，如“電子郵件答復屏幕，”而它的標簽實際將指：“訂單確認�！被蛘呶覀兛赡苡脭底种敢粋�顯屏，無論測試者在哪兒看它，數字都不會出現。測試必須有精確的參考來指導測試者。
如果您為了測試者注意以后將核實的輸入，建立了結構化的字段，測試可能加速。例如，如果你正在測試一個審核日志，你事先不能知道測試者將完成一個審核活動的確切分鐘。如果你告訴他們注意它，它可能被胡亂地寫在測試中，紙片上，或加進一個臨時文件。他們可能不會找麻煩來標明什么是什么，并可能不得不到處搜尋來找到它。最好是在測試中留下一個標記的空格，在這里，他們可以寫下輸入，示例：
刪除條目日期：________時間： _______
條目編號：________
測試者登錄ID ：________
通過控制長度來提高可測試性
一個測試用例應該多長?一個好的分步用例長度是10-15步，除非測試者不節省他們的工作。保持測試這么簡短有幾個好處：
● 簡短的用例用更少的時間來測試每一個步驟
● 測試者不太可能受迷惑，犯錯誤，或需要幫助。
● 測試經理可以準確估計需要多少時間來測試
● 結果更容易追蹤
不要試圖在10-15個步驟的標準上作弊，把很多活動填滿一個步驟。
一個步驟應該是一個明確的輸入或測試任務。您總可以在相同的步驟中添加一個簡單的完成標志，如單擊
保持單個測試簡短的目標并不是不符合用最少數量的測試來測試應用系統的傳統的目標。傳統目標標準的目的是要精巧，當合理的測試業務場景或用例(use case)和需求一樣多時，會工作到10-15步。該標準的目的還在于避免重復，即在一些測試中測試相同的需求。你可能不想通過使每一個測試都很長，來創建最低數量的測試，因為對于測試或維護來說，這將是一個惡夢�？蠢系摹白畹蛿盗康臏y試，”的更好的方法是，衡量是否是一個“最低數量的步驟�！蹦敲赐ㄟ^將50個步驟放入一個中以創造較少的測試是感覺不到好處的。
對于一個矩陣，一個好的長度是可以測試約20分鐘。
自動化腳本的長度不是一個測試執行問題，因為測試通常是幾秒鐘。相反，問題是內容、維護和缺陷跟蹤的管理。每個腳本一個業務場景或用例是足夠的。它可以根據需要循環多次來加載數據或執行變量組合。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
