設計測試用例的四條原則

今天是2011年的第一天，2010年就這樣匆匆忙忙，緊緊張張地過去了。這一年裡來來去去，變化最大的就是很多一起工作了多年的同事離開了，很多都去了"更給力”的地方，呵呵!公司裡來來往往是很正常的，想想我最近一次換到“更給力”的地方，那都是5年前了。總之，現在的地方還是挺給力的，好好工作，爭取2011年有更大的進步，呱唧呱唧!
　　測試用例設計的最基本要求：覆蓋住所要測試的功能。這是再基本不過的要求了，但別看只是簡單的一句話，要能夠達到切實覆蓋全面，需要對被測試產品功能的全面瞭解、明確測試範圍(特別是要明確哪些是不需要測試的)、具備基本的測試技術(如：等價類劃分等)等。那麼滿足了上述這條要求是不是設計出來的測試用例就是好的測試用例了呢?答案：在理論上是，但在實際工程中還遠遠不是。之所以理論和實際會有這樣的差別，是因為在理論上不要考慮的東東，而在實際工程中是不得不考慮的 - 成本。這裡的成本包括：測試計劃成本、測試執行成本、自動化測試用例、測試自動化成本，測試分析成本，以及測試實現技術侷限、測試環境的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的文件還是必要的，它至少能保證在迭代初期團隊對要實現功能有一致和準確的認識。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11323760/viewspace-1062358/，如需轉載，請註明出處，否則將追究法律責任。