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