設計測試用例的四條原則

　　測試用例設計的最基本要求：覆蓋住所要測試的功能。這是再基本不過的要求了，但別看只是簡單的一句話，要能夠達到切實覆蓋全面，需要對被測試產品功能的全面了解、明確測試范圍(特別是要明確哪些是不需要測試的)、具備基本的測試技術(如：等價類劃分等)等。那么滿足了上述這條要求是不是設計出來的測試用例就是好的測試用例了呢?答案：在理論上是，但在實際工程中還遠遠不是。之所以理論和實際會有這樣的差別，是因為在理論上不要考慮的東東，而在實際工程中是不得不考慮的 - 成本。這里的成本包括：測試計劃成本、測試執行成本、自動化測試用例、測試自動化成本，測試分析成本，以及測試實現技術局限、測試環境的Bug、人為因素和不可預測的隨機因素等引入的附加成本等。

　　由于成本因素的介入，決定了工程中設計好的測試用例原則不只有“覆蓋住所要測試的功能”這一條，下面是我根據自己的工作經驗總結出的其它四條原則，在這里拋磚引玉，希望大家拍磚和指正。這些原則特別是針對那些需要被自動化，并且是要被經常執行的測試用例。

　　1. 單個用例覆蓋最小化原則。

　　這條原則是所有這四條原則中的”老大“，也是在工程中最容易被忘記和忽略的，它或多或少的都影響到其它幾條原則。下面舉個例子來介紹，假如要測試一個功能 A，它有三個子功能點 A1，A2 和 A3，可以有下面兩種方法來設計測試用例：

　　方法1 ：用一個測試用例覆蓋三個子功能 -Test_A1_A2_A3，

　　方法2 ：用三個單獨的用例分別來覆蓋三個子功能 - Test_A1，Test_A2，Test_A3

　　方法1適用于規模較小的工程，但凡是稍微有點兒規模和質量要求的項目，方法2則是更好的選擇，因為它具有如下的優點：

　　測試用例的覆蓋邊界定義更清晰

　　測試結果對產品問題的指向性更強

　　測試用例間的耦合度最低，彼此之間的干擾也就越低

　　上述這些優點所能帶來直接好處是，測試用例的調試、分析和維護成本最低。每個測試用例應該盡可能的簡單，只驗證你所要驗證的內容，不要“摟草打兔子”捎帶著把啥啥啥啥都帶進來，這樣只會增加測試執行階段的負擔和風險。 David Astels在他的著作《Test Driven Development：A Practical Guide》曾這樣描述，最好一個測試用例只有一個Assert語句。此外，覆蓋功能點簡單明確的測試用例，也便于組合生成新的測試，在Visual Studio中就引入了Ordered Test的概念。

　　2. 測試用例替代產品文檔功能原則。

　　通常我們會在開發的初期(Scrum每個Sprint的頭兩天)用Word文檔或者OneNote的記錄產品的需求、功能描述、以及當前所能確定的任何細節等信息，勾勒將要實現功能的樣貌，便于團隊進行交流和細化，并在團隊內達成對產品功能共識。假設我們在此時達成共識后，描述出來的功能為A，隨著產品開發深入，團隊會對產品的功能有更新的認識，產品功能也會被更具體細化，在一個迭代或者Sprint結束的時候最終實現的功能很可能是A+。如此往復，在不斷傾聽和吸收用戶的反饋，修改產品功能，多個迭代過后，原本被描述為A的功能很可能最終變為了Z。這是時候再去看曾經的Word文檔和OneNote頁面，卻仍然記錄的是A。之所以會這樣，是因為很少有人會去(以及能夠去)不斷更新那些文檔，以準確反映出產品功能當前的準確狀態。不是不想去做，而是實在很難!這里需要注意：早期的Word或者OneNote的文檔還是必要的，它至少能保證在迭代初期團隊對要實現功能有一致和準確的認識。

　　就沒有什么東西能夠一直準確地描述產品的功能了嗎?答案：當然有，那就是產品代碼和測試用例。產品代碼實現了產品功能，它一定是準確描述了產品的當前功能，但是由于各種編程技術，如：面向對象、抽象、設計模式、資源文件等等，使得產品代碼很難簡單地就能讀懂，往往是在知道產品功能的前提下去讀代碼，而不是反過來看代碼來了解功能。好的代碼會有詳細的注釋，但這里的注釋是對實現代碼的解釋和備注，并不是對產品功能的描述。這里有一篇很老的博客 Reading Code Is Hard，介紹了如何能夠使代碼更可讀一些編寫技巧。

原文轉自：http://www.uml.org.cn/Test/201107202.asp