到了這裏，基本上所有關於自動化框架的內容已經完成了，其中我認爲web自動化中有三個核心（目的與安排、框架結構、元素定位），在最後這裏分享一下我所思考的ui自動化。
一、爲什麼要做自動化以及如何推進
又回到這個最開始我們做UI自動化的初衷，不管是爲了自動化而自動化、還是提高自己的技術能力、亦或者是爲了提高自己的工作效率，既然我們開始做web自動化後，就應該在做的時候去反思，爲什麼要去做自動化，自動化是否真的爲我們提升了效率，以及怎麼完善自動化的流程步驟。
自動化的目的：
毫無疑問自動化本身是爲了代替頻繁而且重複的人工操作，從而提升效率，實際應用中一般作爲迴歸測試的一個實現工具。
做web自動化之前的考量：
這裏依舊要重申一下，做UI自動化需要滿足的條件，我個人覺得要做這個對於項目以及人員的要求都蠻高的，所以這也是ui自動化經常失敗的原因，這裏我覺得在做自動化之前要考慮好項目本身以及項目組測試成員能否滿足自動化的需要。
1.項目要求：
需求相對穩定
重複任務較多
項目開發週期長
這裏有幾個大概的要求，自動化需要持續一段時間，所以需要在一段充足的時間內來進行，而繁瑣重複的測試操作，也是自動化實現的意義。
至於需求相對穩定，指的是我們要進行自動化的功能模塊，不會經常改動主要流程，例如我要把電商網站的購買流程自動化，那麼如果今天增加流程分支，明天更改下單規則，自動化是做不起來的，而且這種情況下做自動化，腳本維護的工作量遠超流程穩定後的腳本工作量。
2.人員要求以及工作量安排
代碼能力
人員充足與否
工作量任務安排
這裏代碼能力其實要求並不太高，因爲ui自動化說起來也是一個非常有規律的東西，沒有學過代碼的測試在經過培訓熟悉後，也可以完成ui自動化的編寫，這裏的代碼能力更多的是指項目組中至少有一個人，不僅負責框架搭建，也要針對不同情況的疑難雜症進行解答，屬於自動化項目的核心。
對於人員和工作量，這裏主要是考慮我們項目是否是測試工作飽和的狀態，人員太少，工作量大的情況下，普通的點點點都很忙了，是沒有時間進行開發初期的UI自動化的，因爲初期的自動化工作量還是蠻大的，會佔用比較長的工作時間；但是當自動化用例完成後，項目需求變動不大的情況下，自動化維護的工作量會比較少。
所以可以根據項目的節奏，在日常工作任務比較輕鬆的時候完成自動化，而在項目緊張的時候就可以分出精力用來維護腳本了。
3.測試項目組要求：
項目測試評估：
當前項目的測試覆蓋率、測試質量以及測試工作投入
加入自動化後的測試覆蓋率、測試質量以及測試工作投入
自動化的發起人、負責人以及目的
自動化測試的推進：
目前的測試用例、以及需要做自動化的用例，需要討論分析，那些用例需要做自動化，做了自動化後的工作量和測試安排、對測試進度和項目進度的影響。
1.確定測試用例
在評估確定好要做自動化後，第一步是確定我們的自動化用例，需要測試的項目組一起把當前項目用例拿出來，評估哪些用例需要做自動化，自動化用例的選擇標準是什麼。第二步就是確定自動化的實現方式，使用哪兒種框架來實現自動化。
2.工作量安排以及項目協調
確定好用例以及實現方式後，需要安排測試小組進行自動化編寫。一般來說需要一個核心測試開發，來主要負責框架的搭建以及相關功能的補充，其他人員主要負責case、page具體用例的實現。
在制定自動化計劃時，也要考慮到項目當前的測試工作量和測試效果，在滿足基礎手工測試的基礎上進行自動化的工作安排。
3.定期迴歸用例
在第一批用例編寫完成後，接下來就是定期維護和檢查用例，比如頁面元素的調整、需求功能的更改，都會需要再次調整用例。這個時期如果要考慮增加用例，需要謹慎一些，因爲如果自動化用例增加太多，也會導致維護成本的增加，可能大部分時間用來維護甚至重寫用例，反而會本末倒置。
二、自動化框架
基礎的自動化框架，實際上都是分爲了兩部分：第一部分是結構框架selenium+unittest，另一部分是設計框架driver+Page+case(或者叫POM).也不是一定是這些技術，但是肯定是同等功能的技術。
第一部分：結構框架
這裏我認爲是組成自動化的源碼結構，必須要有selenium這樣的驅動和unittest這樣的單元測試框架，這兩部分組成了我們自動化的結構框架。根據這個概念引申出來，例如使用selenium+robotframework，使用selenium+pytest等等，結構框架也是我們所要使用的技術框架。
關於selenium的部署以及webdriver的方法介紹：
web自動化測試第1步：UI自動化了解以及python環境配置
web自動化測試第2步：定位元素
web自動化測試第3步：元素的基礎操作和瀏覽器基礎操作
web自動化測試第4步：頁面元素信息（屬性）的獲取
web自動化測試第5步：瀏覽器/頁面信息的獲取
web自動化測試第6步：模擬鼠標操作（ActionChains）
web自動化測試第7步：模擬鍵盤事件（Keys）
web自動化測試第8步：瀏覽器不同頁籤之間的切換(handle)
web自動化測試第9步：切換頁面frame
web自動化測試第10步：獲取瀏覽器彈窗alert、自定義彈窗以及其操作
web自動化測試第11步：switch_to包詳解：切換handle、frame、alert
web自動化測試第12步：selenium中下拉框的解決方法（Select）
web自動化測試第13步：元素定位（2）（webdriver的所有定位方式詳解）
web自動化測試第14步：對於cookie的操作
web自動化測試第15步：使用js語句
web自動化測試第16步：WebDriverWait元素等待和全局設置
web自動化測試第17步：元素定位終極法寶，最全面的xpath定位詳解
關於unittest單元測試框架的介紹
web自動化測試第18步：單元測試框架unittest
web自動化測試第19步：使用unittest運行多個測試用例集
第二部分：設計框架
這裏的設計框架，指的是我們根據選擇的結構框架，來實現自動化用例運行的具體邏輯步驟。例如一個測試用例的實現，在selenium+unittest中，我使用的是driver+page+case的步驟來實現的，如果使用的是selenium+robotframework，那就是通過關鍵字封裝驅動來實現的。
本質都是將功能分門別類，高內聚低耦合的設計思路。
關於具體的結構設計
web自動化測試第21步：UI自動化框架結構以及思路
web自動化測試第22步：POM設計模式的實現
web自動化測試第23步：數據分離
關於一些補充的方法
web自動化測試第24步：使用測試報告模板
web自動化測試第25步：加入log日誌
web自動化測試第26步：郵件發送測試報告
web自動化測試第27步：連接數據庫
web自動化測試第20步：測試用例斷言
三、元素定位
元素定位我認爲是UI自動化的核心所在，因爲任何一個UI自動化框架，不論是什麼結構驅動，都需要針對某一個元素來操作，定位準確簡潔就是非常重要的。在經過總結後，我對於xpath的定位總結了很多方法和規範，包括路徑、屬性、位置、xpath軸、運算符等方面，詳細瞭解這些xpath的知識後，對於元素定位來說應該是沒問題的了。
關於xpath的定位方法
web自動化測試第17步：元素定位終極法寶，最全面的xpath定位詳解
關於webdriver中的的定位方法
web自動化測試第2步：定位元素
web自動化測試第13步：元素定位（2）（webdriver的所有定位方式詳解）