自動化測試的實現
編寫自動化測試也許對很多測試人員來說比較陌生。所幸的是Visual Studio中爲實現自動化測試提供了一系列的工具，單元測試（Unit Test）、編碼UI測試（Coded UI Test）、壓力測試（Stress Test）、網頁性能測試（Web Performance Test）、數據庫單元測試（Database Unit Test）等等，讓實現自動化測試變得輕鬆。這裏我想着重介紹2種最基本的，也是在我們的產品開發中最常用的測試：單元測試和編碼UI測試。
1. 單元測試
單元測試是Visual Studio中最基本、應用最廣泛的一種測試。通常開發人員可以選擇爲一個方法或是一個部件創建單元測試，來保證其邏輯正確。
要在Visual Studio中創建單元測試，可以在源代碼的上下文菜單中選擇“創建單元測試”，並在彈出的窗口中選擇需要爲其創建單元測試的方法（如圖一、圖二所示）。這樣Visual Studio就會自動創建出一系列單元測試的代碼框架，以及針對private/internal等無法直接調用的方法的訪問器（Accessor），用戶只需修改或添加具體測試邏輯即可。訪問器會隨着源代碼的每一次編譯自動更新，爲用戶節省了不少麻煩。當然，用戶也可以使用單元測試嚮導創建，或是直接添加一個單元測試（測試->新建測試）文件再自行添加邏輯代碼。
圖一 創建單元測試
圖二 創建單元測試對話框
單元測試通常以[TestClass]屬性來表示一個測試類，在測試類中使用5種不同的屬性標示方法：[ClassInitialize]、[TestInitialize]、[TestMethod]、[TestCleanup]、[ClassCleanup]。一個測試類中可包含多個測試方法（Test Method），但是僅可以有一個類初始化方法（Class Initialize）、一個測試初始化方法（Test Initialize）、一個測試清理方法（Test Method）、一個類清理方法（Class Cleanup）。在測試運行時，類的初始化會被首先調用，然後在運行每一個測試方法之前運行測試初始化，之後運行測試清理，在測試方法運行結束後，類清理方法將被運行。除測試方法外，其他的輔助方法都不是必須的。大家可以根據實際需要來安排代碼邏輯。
成功編譯後，所有測試方法都會在測試視圖（Test View）窗口中列出，在該窗口中還可以對測試方法進行過濾、查詢和排序，選擇一個或多個測試方法後，可以運行或調試測試用例。測試的結果（是否通過）會顯示在測試結果（Test Result）窗口中，雙擊任意一條測試結果都會打開具體的測試結果日誌以獲取更詳細的信息，如圖三所示。單元測試還可以通過直接在測試方法代碼中右鍵選擇“運行測試”，或是在命令行中直接執行mstest命令來運行。
圖三 測試視圖和測試結果
此外，單元測試工具不僅可以用作單元測試的目的，也可以作爲一種載體，來實現驗收測試或是功能測試。我們在實踐中大量利用了Visual Studio對單元測試的管理、運行、日誌等功能，通過在測試代碼中實現驗收測試、功能測試的具體邏輯來完成各種不同類型的測試。
2. 編碼UI測試
雖然單元測試框架適用於各種不同的測試，不過其本身卻沒有提供太多對測試代碼實現上的支持。對於自動化測試中常常令人無從下手的UI操作的自動化，Visual Studio 2010中添加了一種新的測試類型——編碼UI測試，以幫助用戶克服這一難題。編碼UI測試是一種能輕鬆上手，迅速創建出UI測試的框架。
一種最簡單的創建UI測試的方法是直接從手動測試入手。如果此前我們曾在Test Manager中創建了測試用例，並曾在手動執行時錄製過其測試步驟，那麼我們就可以直接將錄製的步驟轉化爲編碼UI測試的代碼。在Visual Studio中選擇創建一個編碼UI測試後，會跳出一個對話框詢問用戶是使用已有的操作錄製還是重新錄製，選擇第二項“Use an existing action recording（使用現有操作錄製）”後即可通過查詢測試用例工作項將相應的測試轉化爲自動化測試代碼（見圖四）。
圖四 創建編碼UI測試
如果之前沒有錄製過測試步驟，或是想重新創建測試的話，可以在圖四對話框中選擇第一項“Record actions, edit UI map or add assertions（錄製操作、編輯 UI 映射或添加斷言）”，這樣編碼UI測試生成器（Coded UI Test Builder）就會出現。在編碼UI測試生成器中，用戶可以自由選擇爲測試錄製操作步驟（圖五）、手動添加某些UI控件或是斷言（圖六），然後就可以爲這些內容生成代碼。這一過程可以通過在代碼的上下文菜單中選擇“Generate Code for Coded UI Test（爲編碼UI測試生成代碼） ”反覆執行，需要提醒用戶的一點是每一次所有的代碼都將被重新生成，所以手動修改生成的代碼是沒有意義的，除非此後不再借助編碼UI測試生成器生成代碼。
圖五 編碼UI測試生成器——錄製
圖六 編碼UI測試生成器——添加UI控件和斷言
此外，用戶還可以不借助Visual Studio提供的這些工具，直接利用編碼UI測試提供的API（Microsoft.VisualStudio.QualityTools.CodedUITestFramework等）編寫代碼，實現UI自動化測試。
編碼UI測試的運行方法、運行結果等都與單元測試類似，此處不再贅述。
這裏要強調的是自動生成的自動化UI測試並不能解決UI測試固有的不穩定的問題。尤其是這種編碼UI測試是通過UI控件之間的包含關係來尋找控件並對其執行操作的，就導致瞭如果運行測試時UI排列與錄製時不盡相同時，測試可能無法正確運行。確保運行時UI環境的一致、在各操作步驟之間添加對UI控件狀態的判斷、在生成的代碼的基礎上編寫自己的代碼是能提高編碼UI測試穩定性的一些方法。
3. 其他類型測試
除了上述兩種常用的測試類型之外，Visual Studio針對不同類型的測試以及測試對象，提供了各種其他的測試工具。例如，網頁性能測試通過記錄用戶每一步操作選擇的地址和發送的信息來實現網頁測試的自動化；負載測試幫助用戶模擬多用戶各種不同測試環境下的負載；數據庫單元測試提供了直接針對數據庫的測試支持。這裏我就不再一一詳細介紹了，有興趣的讀者可以自己在MSDN上查詢使用方法或者直接試用這些功能。
自動化測試的管理
對於手動測試，測試用例工作項已經能很好的描述測試的內容以及記錄測試的結果。而自動化測試的不同之處在於其需要代碼的支持。我們通常將測試代碼和產品代碼一起保存在Team Foundation Server的源代碼控制中，這樣一方面便於代碼的統一管理，另一方面讓測試用例也能利用到TFS提供的版本控制、擱置集等功能。另外，我們還可以通過設置TFS的測試用例工作項中包含的“關聯的自動化測試”域的值將測試計劃中的測試用例和實際的代碼聯繫起來。
小結
在這一篇中，我們討論了手動測試和自動化測試各自的優勢和侷限性，兩者互補和平衡能幫助測試人員更好的在敏捷開發的環境中完成測試任務。此外，我們還了解了如何藉助Visual Studio中提供的一些工具來實現並管理自動化測試。在介紹了自動化測試的方法和工具後，我將在下一篇中進一步爲大家介紹如何計劃和執行自動化的測試用例。