設(shè)計測試用例的四條原則

1、設(shè)計測試用例的四條原那么測試用例設(shè)計的最基本要求:覆蓋住所要測試的功能。這是再基本不過的要求了，但別 看只是簡單的一句話，要能夠到達切實覆蓋全面，需要對被測試產(chǎn)品功能的全面了解、 明確測試范圍（特別是要明確哪些是不需要測試的）、具備基本的測試技術(shù)（如：等價類劃 分等）等。那么滿足了上述這條要求是不是設(shè)計出來的測試用例就是好的測試用例了呢? 答案：在理論上是，但在實際工程中還遠遠不是。之所以理論和實際會有這樣的差異， 是因為在理論上不要考慮的東東，而在實際工程中是不得不考慮的-本錢。這里的成 本包括：測試計劃本錢、測試執(zhí)行本錢、自動化測試用例、測試自動化本錢,測試分析 本錢，以及測試實現(xiàn)技術(shù)局限

2、、測試環(huán)境的Bug、人為因素和不可預(yù)測的隨機因素等引 入的附加本錢等。由于本錢因素的介入，決定了工程中設(shè)計好的測試用例原那么不只有覆蓋住所要測 試的功能這一條，下面是領(lǐng)測國際根據(jù)自己的經(jīng)驗總結(jié)出的其它四條原那么，在這里拋 磚引玉，希望大家拍磚和指正。這些原那么特別是針對那些需要被自動化，并且是要被經(jīng) 常執(zhí)行的測試用例。.單個用例覆蓋最小化原那么。這條原那么是所有這四條原那么中的老大，也是在工程中最容易被忘記和忽略的， 它或多或少的都影響到其它幾條原那么。下面舉個例子來介紹，假如要測試一個功能A , 它有三個子功能點Al , A2和A3 ,可以有下面兩種方法來設(shè)計測試用例：方法1 :用一個測試用

3、例覆蓋三個子功能-Test_Al_A2_A3 ,方法2 :用三個單獨的用例分別來覆蓋三個子功能-Test_Al ,Test_A2 ,Test_A3方法1適用于規(guī)模較小的工程，但但凡稍微有點兒規(guī)模和質(zhì)量要求的工程，方法2 那么是更好的選擇，因為它具有如下的優(yōu)點：測試用例的覆蓋邊界定義更清晰測試結(jié)果對產(chǎn)品問題的指向性更強測試用例間的耦合度最低，彼此之間的干擾也就越低上述這些優(yōu)點所能帶來直接好處是，測試用例的調(diào)試、分析和維護本錢最低。每個 測試用例應(yīng)該盡可能的簡單，只驗證你所要驗證的內(nèi)容，不要摟草打兔子捎帶著把 啥啥啥啥都帶進來，這樣只會增加測試執(zhí)行階段的負擔(dān)和風(fēng)險。David Astels在他的

4、著作Test Driven Development : A Practical Guide曾這樣描述，最好一個測試 用例只有一個Assert語句。止矽卜，覆蓋功能點簡單明確的測試用例，也便于組合生成 新的測試，在Visual Studio中就引入了 0rdered Test的概念。.測試用例替代產(chǎn)品文檔功能原那么。通常我們會在退的初期（Scrum每個Sprint的頭兩天）用Word文檔或者 OneNote的記錄產(chǎn)品的需求、功能描述、以及當前所能確定的任何細節(jié)等信息，勾勒 將要實現(xiàn)功能的樣貌，便于團隊進行交流和細化，并在團隊內(nèi)達成對產(chǎn)品功能共識。假 設(shè)我們在此時達成共識后，描述出來的功能為A，隨

5、著產(chǎn)品開發(fā)深入，團隊會對產(chǎn)品的 功能有更新的認識，產(chǎn)品功能也會被更具體細化，在一個迭代或者Sprint結(jié)束的時候 最終實現(xiàn)的功能很可能是A+。如此往復(fù)，在不斷傾聽和吸收用戶的反響，修改產(chǎn)品功 能，多個迭代過后，原本被描述為A的功能很可能最終變?yōu)榱?Zo這是時候再去看曾經(jīng) 的Word文檔和OneNote頁面，卻仍然記錄的是Ao之所以會這樣，是因為很少有人 會去（以及能夠去）不斷更新那些文檔，以準確反映出產(chǎn)品功能當前的準確狀態(tài)。不是不想去做，而是實在很難!這里需要注意：早期的Word或者OneNote的文檔還是必要 的，它至少能保證在迭代初期團隊對要實現(xiàn)功能有一致和準確的認識。就沒有什么東西能夠一直準確地描述產(chǎn)品的功能了嗎?答案：當然有，那就是產(chǎn)品 代碼和測試用例。產(chǎn)品代碼實現(xiàn)了產(chǎn)品功能，它一定是準確描述了產(chǎn)品的當前功能，但 是由于各種程技術(shù)，如：面向?qū)ο?、抽象、設(shè)計模式、資源文件等等，使得產(chǎn)品代碼 很難簡單地就能讀懂，往往是在知道產(chǎn)品功能的前提下去讀代碼，而不是反過來看代碼 來了解功能。好的代碼會有詳細的注