對于一個測試人員來說測試用例的設計與編寫是一項必須掌握的能力。但有效的設計和熟練的編寫卻是一個十分復雜的技術，它需要你對整個軟件不管從業務還是功能上都有一個明晰的把握。如何系統、結構的對用例加以規范將直接影響到其后的測試效率和效果，同時測試用例也將用來控制軟件的整體執行覆蓋，對最后的測試結果給出一種量化的評估標準。
一、問題：
許多測試類的書籍都有大幅篇章介紹用例的設計方法，如等價類劃分，邊界值，錯誤推斷，因果圖，判定表等。但實際應用中這些理論卻不能給我們很明確的行為指導，尤其是業務復雜，關聯模塊緊密，輸入標準和輸出結果間路徑眾多時，完全的遵循這些方法只能讓我們在心理上得到一種滿足，而無法真正有效的提高測試效率，并且我們也沒有足夠的時間和資源編寫完備的用例。通常我們只能依靠以前項目的用例編寫經驗(或習慣)，希望能在這一個項目中更加規范，但多數情況下我們規范的只是“書寫的規范”，在用例設計上以前存在的問題現在依舊。
當好不容易用例基本完成，我們卻發現面對隨之而來的眾多地區特性和新增需求，測試用例突然處于一種十分尷尬的境地：
* 從此幾乎很少被執行
* 已經與程序的實現發生了沖突(界面變動，功能變動)
* 執行用例發現的bug很少
* 根本沒有時間為新的功能需求增補用例
* 有時間補充，但用例結構越來越亂
* 特性的用例與通性用例之間聯系不明確(以新增需求為主線列出所有涉及到的更改，但特性與通行之間的數據或業務聯系在用例中逐漸淡化)
知道怎樣執行這個用例，但它要說明什么呢?(多數用例給我們的感覺是只見樹木，不見森林，只說明某一功能的實現，無法串起)
通過上面的一系列問題可以看到，似乎測試用例給我們帶來的問題遠多于益處，也正是因為在實際過程中遇到的問題積累，導致我們有很充分的理由忽視或拒絕用例的應用。
但沒有用例或簡略用例的編寫我們又會舒服很多么?不言自明，誰也不想倒退發展。
二、原因：
事實上我們在測試用例編寫和設計上遇到的一系列問題只是一種表面的呈現，究其原因我認為有如下幾點：
1、沒有適合的規范
“適合的規范”或稱“本地化的規范”。這是我們在測試過程中遇到的第一個問題，通常也是很容易習慣且淡忘的。我們擁有相當多的流程文檔、指導步驟和書本上的定義，但它適合我們當前的項目么?
每一個測試工程師在進入這個職業的初期都會了解一些測試上的概念和術語，進入公司或項目組后也會進一步學習相應的文檔，例如怎樣規范編寫，怎樣定義bug級別，軟件實現的主要業務等。但當測試經理開始給我們分配某一模塊的用例編寫時，又有多少人知道該怎樣去寫，怎樣寫算是好?
在測試論壇中常能看到介紹用例編寫方法的帖子，而迷茫于怎樣應用到實踐的回復也不為少數。為何我們無法在公司和項目組內找到明確且適合的規范?于是我們只得選擇從書本或之前的用例中復制，不管是結構還是方式都依賴于以往的經驗，我并不是說這樣就是錯誤的，但不能總結成文的經驗無法給予測試更多幫助。我們有太多經驗，但卻沒有形成適合的規范。
2、功能與業務的分離
我們知道怎樣列舉一個輸入框的用例，但卻很少考慮說明這個輸入框是用來做什么的，如果仔細分析不難發現，用例中這種功能與業務的分離越來越普遍也越來越明顯。
邊界值、等價類劃分、因果圖，這些用例方法是一種高度提純的方法，本身就很偏向于功能及代碼，所以怎樣編寫業務的用例我們就從理論上失去了參考。
復雜的業務會貫穿于整個軟件，涉及眾多功能點，里面組合的分支更不可勝數。測試用例務求簡潔、明確，這一點也與業務“格格不入”。功能用例依賴程序界面，業務描述依賴需求文檔。于是我們更偏向于根據已實現的界面編寫功能用例，列舉出眾多的邊界值、等價類。流程的操作只有憑借經驗和理解，這時測試出的bug是最多的，但我們卻無法使這個bug對應到一個用例中(點擊一個按鈕報出的錯誤有時原因并不在這個按鈕或按鈕所在的窗體)，只能自己添加note向開發人員指出可能出錯的源頭。正因為我們沒有很好的積累業務上的用例，才使得我們感到執行用例時發現的bug不多。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
