自動化測試的實現

編寫自動化測試也許對很多測試人員來說比較陌生。所幸的是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中提供的一些工具來實現並管理自動化測試。在介紹了自動化測試的方法和工具後，我將在下一篇中進一步為大家介紹如何計劃和執行自動化的測試用例。