我在測試或測試自動化類的東西非常新。現在我已經分配了一個項目來自動化WPF應用程序的UI測試。在對MSDN和其他人進行一些搜索之後，我對是否應該使用Microsoft UI自動化庫或VS 2010的新編碼UI測試功能感到困惑。我沒有清楚地瞭解這些應用中哪一個適用在哪些場景中，哪一個比另一個更有優勢，哪一個適合我（再次，我有一個像WPF應用程序那樣缺少大量AutomationIds的CAD，並且我必須使其ui測試自動化）。請幫忙 ！！！微軟UI自動化庫VS編碼UI測試
基本上，Microsoft UIA是.NET 4.0中的新的訪問庫。 WPF應用程序和控件通過AutomationPeer類具有對UIA的內置支持。
編碼UI測試是一個記錄&播放自動化工具，它使用下面的Microsoft UIA Library。由於與在C＃中編寫代碼相比，它是一種工具，它可以提高QA生產力以記錄更多測試用例。
對於計劃使用自動化支持的應用程序，Coded-Ui應該足夠了。如果AutomationID缺失，請確保控件具有一些獨特的屬性，如名稱。使用UIVerify或Inspect檢查。
如果沒有獨特的屬性是avialble，還有其他下面提到的技術，您可以結合使用Coded-UI。
從事件 當你的應用程序接收UI自動化事件，傳遞到事件處理程序的源對象是AutomationElement。例如，如果您訂閱了焦點更改的事件，則傳遞給您的AutomationFocusChangedEventHandler的源是收到焦點的元素。有關更多信息，請參閱訂閱UI自動化事件。
從某個點開始： 如果您有屏幕座標（例如光標位置），則可以使用靜態FromPoint方法檢索AutomationElement。
從窗口句柄： 要從HWND檢索AutomationElement，請使用靜態的FromHandle方法。
來自專注的控制： 您可以檢索一個AutomationElement，它代表來自靜態FocusedElement屬性的集中控制。
如果您可以利用並使用Coded UI Test那麼去那條路線。確保驗證您的給定configuration is supported。
UI自動化庫解析代碼背後的所有內容。這會迫使你使用像UISpy這樣的工具訪問控件內部，這樣你就可以構建出你的測試。
另一方面，編碼UI測試仍然有代碼背後，但它允許通過給定的應用程序，你正在測試的步驟記錄，這將大大增加可以創建的測試數量。
爲了補充上述反應，請參閱CUITE，這對您有所幫助，可能對您有所幫助。
我開始使用CodedUITest庫'rolling-my-own''semi-framework'，並設計了一個從（C＃）代碼中分離出自動化細節的範例。 基本上，我創建的驅動程序可以從電子表格中讀取需要做什麼，其中每行都是測試步驟（或指向不同工作表中的方案的指針）。 目前，不完整，但很有希望，我對WPF應用程序的工作有部分成功。 其中一個主要問題是開發人員忽視了唯一一致地識別控件。
貝
UI自動化庫是一個低級別的庫。通常，你不想直接編寫測試，因爲它需要相當大量的工作。
我建議看看更多的高級庫。你提到了其中之一 - 編碼UI;另一個不錯的選擇是來自TestStack的White。他們都適合不同類型的項目。如果您不想在測試套件中投入大量精力，則編碼UI很有用。同時，如果你要寫很多測試，它的規模不會太大，所以你最好選擇White。
這裏我比較兩個框架更詳細：Coded UI vs White