自動程式碼 UI 測試的最佳作法
本主題將說明開發自動程式碼 UI 測試時要遵循的最佳做法。
需求
- Visual Studio Ultimate, Visual Studio Premium
最佳作法
使用下列方針有助於建立彈性的自動程式碼 UI 測試。
盡可能使用 [自動程式碼 UI 測試產生器]。
不要直接修改 UIMap.designer.cs 檔案。如果這樣做，該檔案的變更將會被覆寫。
依照錄製方法的順序建立測試。如需如何錄製方法的詳細資訊，請參閱 自動程式碼 UI 測試。
每個錄製方法都應處理單一頁面、表單或對話方塊。為每個新的頁面、表單或對話方塊建立新的測試方法。
建立方法時，請使用有意義的方法名稱來代替預設名稱。有意義的名稱可協助識別方法的用途。
盡可能將每個錄製方法限制為少於 10 個動作。如果 UI 變更的話，這種模組方式可以很容易取代方法。
使用 [自動程式碼 UI 測試產生器] 建立每個判斷提示，這個工具會自動將判斷提示方法加入至 UIMap.Designer.cs 檔案中。
如果使用者介面 (UI) 變更，請重新錄製測試方法或判斷提示方法，或是重新錄製現有測試方法之受影響的區段。
在待測應用程式中為每個模組建立個別的 UIMap 檔案。如需詳細資訊，請參閱測試含有多個 UI 對應的大型應用程式。
在待測應用程式中建立 UI 控制項時，請使用有意義的名稱。這樣要比自動產生的控制項名稱更有意義且易於使用。
如果透過 API 撰寫程式碼的方式建立判斷提示，請在 UIMap.cs 檔案的 UIMap 類別部分中為每個判斷提示建立方法。從測試方法呼叫這個方法，以便執行判斷提示。
如果直接透過 API 撰寫程式碼，請盡可能地在程式碼中使用 UIMap.Designer.cs 檔案中產生之類別的屬性和方法。這些類別可使工作容易進行、更可靠，並有助於提高生產力。
自動程式碼 UI 測試會自動隨著使用者介面中的許多變更而改變。例如，如果 UI 項目已經變更位置或顏色，則在大部分情況下，自動程式碼 UI 測試仍會找出正確的項目。
在進行測試回合期間，測試架構會透過一組搜尋屬性 (適用於 [自動程式碼 UI 測試產生器] 所建立之定義中的每個控制項類別)，在 UIMap.Designer.cs 檔案中尋找 UI 控制項。搜尋屬性包含屬性名稱和屬性值的名稱/值組，可用來識別控制項，例如控制項的 FriendlyName、Name 和 ControlType 屬性。如果搜尋屬性未變更，自動程式碼 UI 測試會成功找到 UI 中的控制項。如果搜尋屬性已變更，自動程式碼 UI 測試的智慧比對演算法會套用啟發式來尋找 UI 中的控制項和視窗。當 UI 已變更時，您可以修改先前所識別之項目的搜尋屬性來確認找到它們。
使用者介面變更時要執行的動作
在開發期間使用者介面會經常變更。以下是減少這些變更影響的一些方式：
尋找參考此控制項的錄製方法，並使用 [自動程式碼 UI 測試產生器] 重新錄製此方法的動作。您可以對方法使用相同名稱，以覆寫現有的動作。
如果控制項具有無效的控制項：
刪除包含判斷提示的方法。
從測試方法移除此方法的呼叫。
透過將交叉線按鈕拖曳至 UI 控制項上來加入新的判斷提示，開啟 UI 對應並加入新的判斷提示。
如需如何紀錄自動程式碼 UI 測試的詳細資訊，請參閱使用 UI 自動化驗證程式碼。
如果必須等背景處理序完成後測試才能繼續，該怎麼辦
您可能必須等到處理序完成後才能繼續下一個 UI 動作。若要這樣做，您可以在測試繼續之前使用 WaitForReadyLevel 進行等候，如下列範例所示。
// Set the playback to wait for all threads to finish
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
// Press the submit button
this.UIMap.ClickSubmit();
// Reset the playback to wait only for the UI thread to finish
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.UIThreadOnly;
請參閱
參考
Microsoft.VisualStudio.TestTools.UITesting