一種行之有效的軟件測試策略

　　在最近的一個大型項目中，我們在早期就定下了一個目標：不會在軟件中使用大量QA人員專注于手工測試。通過手工測試發現bug極其耗時且成本高昂，這促使團隊嘗試盡可能的將質量內嵌到產品內部。但這并不意味著手工測試毫無價值，因為人們總能在怎樣使用軟件上給你一些特別的驚喜。

　　這是一個為期18個月左右，周期很長的項目，并且后續也會持續更新。 在項目初期，團隊就意識到項目成功的重中之重在于一個優秀的測試策略，尤其是讓我們的團隊能夠做到：1)隨著項目時間的推移能夠持續的提高團隊的工作效率。2)不管面對的變更是大是小都能夠具有足夠的信心。

　　我們花費了很長時間才確定了一種有效的策略。這在很大程度上是因為我們不得不學習怎樣讓我們的程序在所有層上都具有可測性。雖然所有的項目團隊成員都具有TDD(測試驅動開發)的經驗，但僅僅這樣并不足以建立有效的測試策略。

　　測試分層

　　給不同的測試分類是一件令人煩惱的事。有功能測試，集成測試，單元測試，驗收測試，slow tests，fast tests，UI測試...等等等等。然后我們發現屬于我們的測試主要有三種類型：

　　系統測試

　　皮下測試

　　單元測試

　　它們之間的區別主要在于被測試內容的范圍。系統測試指的是通過應用的外部接口進行運作，無論對象是一個瀏覽器，文件下拉菜單，隊列，window窗體應用或者其他的什么東西。

　　皮下測試運行在外部用戶接口之下。如果測試的是Web應用，皮下測試在我們理解就是指在真實的類

　　以及環境部署到位的情況下，通過命令處理器進行發送的表單對象。繞過UI層邏輯，直接到達domain層。發送表單對象，拋出”成功/失敗”的執行結果。

　　對于最底層而言，我們有單元測試。單元測試用于測試一個類，并且可以是fast test 或者 slow test中的一種。Fast Test 即是常規的TDD測試，用于增量的類設計。Test doubles曾被認為是必要的，但是除非系統交互非常值得關注，否則嚴格的 基于交互的測試 并不是那么有價值。我們同樣也有slow 單元測試，其同樣可被分類為 交互測試。當然它們同樣可歸類為 repository tests, persistence tests等。

　　單元：皮下：系統 測試在我們的測試工作中各自占的比重差不多是 10:2:1。 為了完成項目我們做了大約 5000 個單元測試，1000個皮下測試，500個使用 WaitN 以及 Gallio驅動瀏覽器的系統測試。6000個單元/皮下測試的執行時間大概是10分鐘，而剩下的500個UI測試大概需要50分鐘完成。

　　單元測試策略

　　單元測試是在嚴密的TDD模式下開發的。我們在功能實現之前編寫單元測試，并用這些測試驅動代碼設計。這些測試可以幫助發現設計問題、封裝問題、代碼異味等。

　　我們努力避免編寫純粹用于提供測試的代碼。它們常常意味著我們有設計問題、責任錯位或封裝已被破壞。

　　隨著我們越來越深入項目管道，我們對交互測試的重視越來越少。 如果你真的對交互感興趣，那么通過mock進行的交互測試也僅僅是有趣而已。但更多的時候，我們更感興趣的是附加作用，而交互只是一個實現細節。反之，我們經常做的是模擬(mock)出過慢或不可測的代碼，比如存儲庫、基于外部服務的外觀、配置類等等。否則，我們有限的模擬只是模擬了我們感興趣的那些觀察點。

　　在大型項目中的某些時間點，為了提取出能加快功能交付的理念，設計往往需要做大型的重構。在我們上一個項目中，我們發掘出了如下理念：

　　AutoMapper

　　將表單作為單獨的命令消息處理

　　Input builders

　　有了以上這些，單元測試是重構時的保障。但只有我們依賴這些測試來捕獲應用程序中所有有趣的行為時，才能有保障的作用。為了允許有效的大中型重構，我們需要增加額外的測試層級。

　　皮下測試策略

　　皮下測試，顧名思義，所有的測試都是在用戶界面之下進行的。在MVC應用程序中，皮下測試是測試控制器下面的所有內容。對于Web service，一切測試都在終端下進行。皮下測試的思想是，應用程序的最上層不執行任何實際的業務邏輯，而只是外部接口與底層服務之間的連接。

　　皮下測試的重要性體現在我們希望在拋開如用戶接口和外部服務這類外部連接點的情況下，能夠在整個系統運行的同時測試業務邏輯。相對于單元測試關注小模塊的設計，皮下測試關注的不涉及設計，而是測試整個系統的基本輸入和輸出。

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