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

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

　　例如：第一條原則-單個用例覆蓋最小化原則 - 就是一個很好的例子，測試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，請務必要考慮投入的代價。

　　4. 使測試結果分析和調試最簡單化原則。

　　這條原則是實際上是上一條- 單次投入成本和多次投入成本原則 - 針對自動化測試用例的擴展和延續。在編寫自動化測試代碼時，要重點考慮如何使得測試結果分析和測試調試更為簡單，包括：用例日志、調試輔助信息輸出等。因為測試用例的執行屬于多次投入，測試人員要經常地去分析測試結果、調試測試用例，在這部分活動上的投入是相當可觀的。有時候，測試框架提功能的一些輔助API等就可以幫助很好實現這個原則。例如：Coded UI Test就提供了類似的API，詳見 - VS 2010 測試功能學習(18) – Coded UI Test三個必知的函數，來輔助基于Coded UI框架實現的自動化測試用例有更好的調試體驗。

　　測試理論為測試工作指明了大的前進方向，在實際工程中還需要我們不斷地“活化”這些理論，使理論和實踐更好的契合在一起。在我看來，軟件工程項目不論成敗和好壞，對我們每個參與者都是無比寶貴的。作為有心人，從中我們體會到很多書本上不曾提到過的東西，只要不斷地去觀察、體會和總結，你會有更多自己的認識、理解和發現。有很多人寫書稱贊，代碼之美、測試之美，其實工程項目也是很美，只是看你能不能更客觀地去看待它。

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