1、為什么我們需要UI自動化測試？UI自動化測試的focus應該在哪幾個方面？
測試自動化並不是為了贏得老板的贊賞，或者認為這是一個很潮的技術，不用就會落后，而是為了發現問題，提高產品的質量。做UI自動化測試的主要目的也是基於此的。 除此之外，UI自動化測試還可以從一個最終用戶（end user）的角度來發現問題，對大數有UI的系統來說，UI是最理想的集成/系統測試入口，也是最需要測試的地方。
UI自動化測試應該集中在：
1）UI的文本，圖片顯示正確性
2）UI的交互邏輯正確性測試
3）UI上的用戶行為正確性測試
4）如果可能，UI的用戶體驗性測試（這個通常並不適合）
2、什么是GUI自動化測試的難點？
對比手工UI測試，UI自動化測試有如下的難點：
1）從UI測試的角度來說，一個非“預期”產生的缺陷很難被自動化測試發現，而手工測試則能輕松的發現這個缺陷；
2）UI本身的變化性，要想達到和手工測試相同的覆蓋率，單純的UI自動化測試往往很難證明自己的投資回報；
3）UI控件元素本身識別的復雜性；
4）UI自動化測試出現問題時，恢復到下一條測試case執行的場景是復雜的。因為出現這種問題的意外，是非“預期”的；
5）UI的測試case，有很多是關於用戶交互方面的，而這方面也其一定的復雜性；
3、如何做出更好的UI自動化測試？
1）要盡量避免UI自動化測試。這點似乎與我們的初衷有點背道而馳。但細想一下，它還是有一定道理的。其原因是API和功能層級來說更加穩定，所以其自動化和維護的成本都比較低。相比而言，UI自動化測試因為有上述的諸多難點，所以其實施起來比較困難，導致它的開發成本和維護成本都要高出許多。因此，有的公司的自動化測試就有一個721原則，即70%的測試工作集中在底層接口測試和單元測試，20%的測試工作為集成測試，其他10%的測試即為界面測試。
2）對於UI本身的變化性和UI控件識別的復雜性，利用ID/Name定位元素設定UI Map，與開發團隊約定元素的命名規則，在盡可能的情況下，確保UI的可自動化測試性。當業務發生變更時，一個好的模式或者框架來讓測試自動化更加便捷，包括要對業務進行分層，關注數據存儲和數據驅動，做到測試數據與測試代碼的隔離，UI自動化操作與業務測試邏輯的分離。
3）對UI自動化出現問題時，不能很好的恢復到下一條case的正確執行場景（我們可以稱之為恢復測試場景或batch run），可以通過組織良好的case，我們寫Case的時候傾向於Case之間是沒有關聯的。我們希望一個Case在執行的時候，它自己能夠將初始化和結尾的工作先做好，A Case和B Case不應該有關系，B Case的成功與失敗不應該依賴於A Case的成功與失敗，一個好的Case應該這樣設計。但是有時候A Case做完，我們需要先添加一個用戶，然后再刪除這個用戶，這種情況下，如果沒添加就去刪除，則是失敗的，兩者之間存在一種依賴關系。在這種設計的情況下，有一個解決的思路是支持Case間的依賴，你可以定義一個標簽去說明某個Case依賴於其他的Case，這樣就先執行被依賴的Case，然后再執行這個Case，確保了執行的順序。
從本質上講，非UI測試和UI測試，是互為補充的，根據其成本和特性的不同，在實際工程應用中也應該領會運用。其基本原則：非UI自動化測試用例為主，UI自動測試為必要的補充，考慮成本因素，UI自動測試可以被手動測試所取代。那么到底哪些情況下需要基於UI的自動化測試用例的，根據我的經驗列出下面幾種情況，供大家參考：
- 基本用戶場景測試和驗收確認(acceptance）測試用例。這 類測試用例要求從真實用戶的使用角度去測試產品的實現，只有包括了UI層才完整和驗證了產品的真實用戶體驗。從實現的角度來看，這類用例應該是只覆蓋最基 本和核心的端到端的用戶場景（End-to-End user scenario），對於敏捷開發，會在用戶故事中描述用戶使用的基本場景。一般不使用基於UI測試實現那些步驟復雜，或者邊邊角角(corner case)的測試用例。
- 邏輯與用戶界面綁定在的一起，無法繞過UI直接測試核心邏輯模塊。這 種情況也是不得已而為之，在實際工程中也最經常出現的，它反映了軟件構架設計方面存在的問題，即沒有很好的模塊化、模塊之間過度耦合。如果是一個全新的軟 件和功能，在項目初期，測試人員應該與開發人員/構架師仔細探討一下可測試性(Testability)問題，特別是針對自動化測試的可測是性， 比如：邏輯與UI分離，是否易於進行接口測試等。一旦錯過這個階段，到了產品的中后期，就很難為了測試再修改產品代碼。