隨著需求的不斷變化和迭代的深入，代碼庫不可避免的會有頻繁的簽入和簽出，此時測試人員一項很重要的任務就是要預防回歸問題發生。執行手工測試用例可以幫助我們預防及和發現回歸問題，但是它的執行效率太低，無法勝任頻繁執行的要求。這時就我們需要考慮采用自動化測試用例完成這項工作。決定是否采用自動化測試是有很多因素決定，其中很重要的一條就是自動測試的收益，下面的公式從概念上解釋了如何來計算這個收益，當收益值大于1的時候，實施自動化測試就是合算的；否則，就是不合算的。

圖1：計算收益公式

　　這其中，開發和維護自動測試的成本是影響這個收益的重要因素，為此VS 2010提供了一整套的解決方案，幫助測試團隊減少這部分成本，這包括前面我們所提到的測試計劃和用力管理工具，以及后面將會要介紹的生成和實驗室管理。此外，Visual Studio 提供了多種測試工程模板，幫助測試人員開發自動化的測試用例，如下圖所示。

圖2：Visual Studio提供的多種測試模板

　　這些測試工程模板可以幫助測試自動化工程師，在Visual Studio 集成開發環境中創建和管理單元測試、功能測試、Web性能測試、負載測試等等一系列的自動化測試用例。這其中，編碼的UI測試（Coded UI Test，以下簡稱為CUIT）是首次出現，是VS 2010測試部分一大亮點。測試人員可以通過它使用C#或者 VB.NET語言編寫自動化測試用例，從用戶界面層驅動Web、Winform或者是WPF的應用。

　　CUIT為測試用例的自動化提供了一個框架、API和可擴展的接口，測試人員可以很輕松地開發出所要的自動化測試用例。其實CUIT背后的測試自動化實現技術對大家并不陌生，下面列出針對Web、WinForm和WPF應用的測試技術基礎。對每種技術的支持采用的是插件的形式實現的，VS 2010包括了如下的三種插件：

• Document Object Model（DOM）插件 : IE 7/8 HTML/AJAX
• User Interface Automation（UIA）插件 : WPF
• Microsoft Active Accessibility（MSAA）插件 : Winform，Win32和MFC 。MSAA插件是默認選項，用來支持出其它兩者之外的任何應用。

　　CUIT 現在支持主要的微軟平臺，詳細的內容可以參見MSDN : Supported Configuration and Platforms for Coded UI Tests and Action Recordings。對于那些尚不支持的平臺或者UI控件，CUIT提供了很好的擴展機制，允許大家針對自己的特殊應用進行擴充，下圖就是CUIT框架的體系結構圖 。

圖3：CUIT框架的體系結構

　　開發自動化測試用例對于有效預防回歸問題的出現時非常必要，在實際應用中應該特別注意它的合理比例關系和靈活的策略，包括：自動化用例和手工用例的比例、UI和非UI測試用例的比例關系。自動化測試用例、執行、分析和維護它們都是需要一定投入的，對于敏捷項目而言時間資源的緊缺尤為突出，所以在任何時候團隊都要根據自身的資源，有選擇性進行測試用例的自動化，通常情況下應該優先自動化那些高優先級的測試用例。

　　對于UI和非UI的自動化測試用例而言，應該是以非UI 的單元測試和功能測試為主，UI測試未必要的補充。基于UI自動化測試用例有它獨特優點，例如：它從真實用戶角度出發進行測試，即涵蓋了界面層、邏輯層和數據層，自動化人員不需要了解被測試應用的代碼實現細節等；但是相對于非UI測試它也有著先天的不足，包括：執行速度相對比較慢、易受干擾不穩定等。所以在自動化過程中，能用非UI測試覆蓋的功能盡可能采用非UI的測試覆蓋，如：API單元測試等，UI測試用例只用來實現最基本用戶故事的驗收測試（Acceptance Test）。

　　早測試和經常測試——封閉簽入和滾動生成

　　敏捷開發中最可怕的事情莫過于在迭代最后一兩天進行測試，結果發現了嚴重功能缺陷或者回歸缺陷，導致不能按計劃發布給用戶試用。要想徹底解決這樣的問題，一方面要在迭代開發階段測試人員就要參與進來，從客戶的角度出發對功能需求和設計文檔進行文檔測試，即文檔評審。測試人員和開發還有項目經理一起從源頭上保障將要實現的功能是用戶想要的。另一方面就是要在迭代的早期就開始就開始測試，特別前幾個迭代已經實現好的自動化測試用例，盡早的執行它們可以有效地避免回歸問題的出現。在TFS 2010上專門提供封閉簽入（Gated Check-in）、滾動生成（Rolling Builds）和持續集成（Continuous Integration）等功能，幫助敏捷團隊實現早測試和經常測試。這其中封閉簽入和滾動生成是對敏捷團隊比較實用的功能。

圖4：選擇簽入方式

　　封閉簽入是TFS 2010提供的一種新的代碼簽入方式，在配置這項功能后，當用戶要簽入任何代碼時，系統會先將用戶本地要簽入的代碼打包成一個擱置集（shelve-set），然后提交到服務器端，TFS生成（Build）服務先從TFS源代碼控制器中同步項目的最新代碼，再將提交的代碼與之進行自動合并，然后進行編譯，如果編譯成功，則執行配置的自動化測試用例，如果測試用例全部通過則代碼會被自動簽入到代碼庫中，否則返回錯誤信息給用戶，代碼是不會進入到代碼庫。表面上看是與產品測試沒有直接關系，但實際上它和測試以及最終產品質量的密不可分。

　　因為代碼簽入是整個開發過程中發生最為頻繁的操作，每次簽入代碼的質量直接影響著日常的開發活動。對于絕大多數的開發團隊來說，check in代碼前不僅要保證編譯通過，同時還要最大限度的保證新代碼不會破壞已有的功能，也就是要執行測試用例去驗證。Gated Check-in中提到的“Build成功”，實際上包含兩部分內容：編譯成功和測試用例執行成功，有了它作為保護代碼庫的第一道屏障，就可以保證它在任何適合都是可編譯，并且達到一定質量標準的。

　　滾動生成是在VS 2008種就有的功能，當TFS檢測到在它所監控的范圍內有任何新的代碼變化被簽入后，它就啟動對最新的代碼庫進行生成驗證，該驗證包括編譯和運行指定的自動化測試用例。之所以稱之為“滾動”，因為它是在一個生成驗證操作完成后再去探測有沒有新的簽入發生，對這期間發生的所有新簽入進行新的生成驗證。這里需要再強調一下滾動生成的重要意義：它看似只是一個自動生成代碼的功能，但實際上起著協調整個開發團隊、時刻監控代碼庫質量、以及盡早暴露產品問題的作用。

　　因為滾動生成時刻都在不停的運轉著，對于任何代碼簽入它都保持著警覺，會去自動驗證編譯是否成功，自動化測試用例是否都能通過。它就像一個不知疲倦的“代碼守護者”一樣監控著代碼庫，第一時間發現其中的任何問題，將問題通知給整個團隊，從而避免了問題的積累和拖延。這非常符合敏捷開發中“今日問題今日解決，不要拖到以后”的原則，它幫你最早的發現問題、報告問題，開發團隊則應該建立制度要及時響應滾動生成所報告的問題，把它作為Priority 為0或1的高優先級問題去對待和解決。

　　封閉簽入和滾動生成都是來保護代碼庫的正確性和產品質量，它們是否在功能上重復反而讓我們不敏捷了呢？其實兩者并不重復，只是各有側重，將它們搭配使用才會發揮其最大效能。封閉簽入是在代碼進入代碼庫之前進行驗證，簽入提交者一般希望竟快知道結果，以便決定下一步的工作，所以封閉簽入的時間（編譯和運行測試用例）不要太長（10-20分鐘）。這也就決定了我們加入的測試用例不能太多，只添加那些高優先級的測試用例，保證主要的用戶故事不被破壞。

　　滾動生成是在代碼簽入后在后臺執行的，由于不存在著與用戶的交互等待，所以它執行時間可以更長（幾個小時），可以為它加入更多的測試用例，從而全面驗證代碼庫的質量，一旦有任何問題它可以及時通知團隊進行修復，這種驗證是在幾個小時或者每天都在發生的，保證了敏捷對頻繁測試的。

　　完整的自動化測試解決方案——實驗室管理

　　在談到軟件自動化測試的時候，很多人會誤以為實現了自動化測試用例就是自動化測試，其實不然，自動化測試僅是測試自動化的一個重要步驟，絕對不等同于自動化測試。一個完整的自動化測試應該包括：構建、部署、執行測試用例、分析測試結果并作出結論。在前面的自動測試的收益公式中，我們可以看到減少自動測試的維護成本，是提高自動測試收益的重要因素之一。VS 2010的實驗室管理（Lab Management）與測試用例管理、生成管理、源代碼控制、工作項管理等功能相結合，為自動化測試提供了這樣一個完整的解決方案，目標就是要降低了自動測試的運營和非維護成本，下面這張圖展示了實驗室環境的系統構架圖。

圖5：實驗室環境的系統構架圖

　　實驗室管理功能充分利用了微軟的虛擬化技術，包括：Hyper-V和 System Center Virtual Machine Manager （SCVMM），快速創建干凈的虛擬測試環境并進行產品生成和部署，然后執行指定的測試用例集，將結果以報表的形式呈現出來，方便對此產品質量進行分析，如下圖所示：

圖6：虛擬測試環境

圖7：測試結果

　　同時，利用虛擬技術的環境快照功能，對于那些難于復現或者環境相關的Bug，利用虛擬環境的快照技術，可以為開發人員準確的復現Bug出現的環境，從而能夠快速的進行診斷和及時修復。

　　總結

　　Visual Studio 2010作為Visual Studio系列中一個非常重要的版本，為測試人員和團隊提供了一整套解決方案，包括：測試計劃和用例管理、創建自動化測試用例、測試用例的自動執行、以及實驗室管理等。這些功能強調了測試作為整個軟件過程的重要角色的作用，促進了測試人員與其它角色的有效溝通與協作，非常適合于敏捷團隊使用來完成測試工作。

　　工具不是萬能的，但沒有合適的工具輔助也是萬萬不能的。對于工具在敏捷開發的作用，應該用辯證的觀點來看待。不能片面唯工具論，畢竟軟件開發過程是人、工具和過程三者共同作用的結果，工具影響著人和過程，同時人和過程也影響著工具所能發揮的效力。所以這決定了工具的引入和部署應該是一個漸進的和逐步適應的過程，特別是對Visual Studio 2010這樣比較大型和綜合性的工具。下面是三個向大家推薦的與Visual Studio測試相關的微軟論壇，希望能夠對大家有所幫助。

　　相關文章：應用Visual Studio 2010輔助敏捷測試（上）