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

　　那么就只有測試用例了，測試也應該忠實反映了產品功能的，否則的話測試用例就會執行失敗。以往大家只是就把測試用例當作測試用例而已，其實對測試用例的理解應該再上升到另一個高度，它應該是能夠扮演產品描述文檔的功能。這就要求我們編寫的測試用例足夠詳細、測試用例的組織要有調理、分主次，單靠Word、 Excel或者OneNote這樣通用的工具是遠遠無法完成的，需要更多專用的測試用例管理工具來輔助，例如 Visual Studio 2010引入Microsoft Test Manager。

　　此外，對于自動化測試用例(無論是API或者UI級別的)而言，代碼在編寫上也應該有別產品代碼編寫風格，可讀性和描述性應該是重點考慮的內容。在測試代碼中，當然可以引入面向對象、設計模式等優秀的設計思想，但是一定要適度使用，往往面向過程的編碼方式更利于組織、閱讀和描述。

　　3. 單次投入成本和多次投入成本原則。

　　與其說這是一條評判測試用例的原則，不如說它是一條思考問題的思維角度和原則。成本永遠是任何項目進行決策時所要考慮的首要因素，項目中的測試也是如此，對成本的考慮也應該客觀和全面的體現在測試的設計、執行和維護的整個階段中。當你在測試中遇到一些左右為難的問題需要決策時，嘗試著從成本角度去分析一下，也許會對你的決策有所幫助。

　　測試中的成本按其時間跨度可以分為：單次投入成本和多次投入成本。例如：編寫測試用例可以看作是單次投入成本，因為編寫測試用例一般是在測試的計劃階段進行(Scrum每個Sprint的開始階段)的，雖然后期會有小的改動，但絕大多數是在一開始的設計階段就基本上成型了;自動化測試用例也是如此，它也屬于是一次性投入;測試用例(包括：手工和自動化測試用例)的執行則是多次投入成本，因為每出一個新版本Build時都要執行所有的測試用例(或者進行 BVT測試僅執行高優先級的測試用例)、分析測試結果、調試失敗測試用例、確定測試用例的失敗原因(產品缺陷、測試用例缺陷、測試框架缺陷還是隨機問題導致了測試用例的失敗)，以驗證該版本整體質量是否達到了指定的標準。

　　之所有要引入單次和多次成本的思考，是希望能夠通過區分測試中不同活動對測試成本的影響，從而進行幫助我們合理布局在不同階段的投入和做出正確的決策，以保證在有限可負擔測試成本的前提下，最大限度地有效開展測試工作。例如，當我們意識到了，測試用例的設計和自動化屬于是一次性投入，而測試用例的執行則是反復多次的投入時，就應該積極思考如何能夠提高需要反復投入的測試執行的效率，在一次投入和需要多次活動需要平衡時，優先考慮多次投入活動的效率，其實這里是有很多工作可以做。

　　例如：第一條原則-單個用例覆蓋最小化原則 - 就是一個很好的例子，測試A功能的3個功能點A1，A2和A3，從表面上看用Test_A1_A2_A3這一個用例在設計和自動化實現時最簡單的，但它在反復執行階段會帶來很多的問題：

　　首先，這樣的用例的失敗分析相對復雜，你需要確認到底是哪一個功能點造成了測試失敗;

　　其次，自動化用例的調試更為復雜，如果是A3功能點的問題，你仍需要不斷地走過A1和A2，然后才能到達A3，這增加了調試時間和復雜度;

　　第三，步驟多的手工測試用例增加了手工執行的不確定性，步驟多的自動化用例增加了其自動執行的失敗可能性，特別是那些基于UI自動化技術的用例;

　　第四，(Last but not least)將不相關功能點耦合到一起，降低了盡早發現產品回歸缺陷的可能性，這是測試工作的大忌。例如：如果Test_A1_A2_A3是一個自動測試用例，并按照A1->A2->A3的順序來執行的，當A1存在Bug時，整個測試用例就失敗了，而A2和A3并未被測試執行到。如果此時A1 的Bug由于某些原因需要很長時間才能修復，則Test_A1_A2_A3始終被認為是因為A1的Bug而失敗的，而A2和A3則始終是沒有被覆蓋到，這里存在潛在的危險和漏洞。當你在產品就要發布前終于修復了A1的Bug，并理所當然地認為Test_A1_A2_A3應該通過時，A2和A3的問題就會在這時爆發出來，你不得不繼續加班修復A2和A3的問題。不是危言聳聽，當A2/A3的代碼與A1的Bug修復相關時，當你有很多如此設計的測試用例時，問題可能會更糟… …，真的!:(

　　綜上所述，Test_A1_A2_A3這樣的設計，減少地僅是一次性設計和自動化的投入，增加地卻是需要多次投入的測試執行的負擔和風險，所以需要決策時(事實上這種決策是經常發生的，尤其是在設計測試用例時)選擇Test_A1_A2_A3還是Test_A1、Test_A2和Test_A3，請務必要考慮投入的代價。

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