雖然UI自動化是比較高成本的方式锐峭，但是很多時候也是功能測試的唯一選擇尺借。
·UI自動化測試不只是腳本，也需要設計
·軟件測試腳本的開發(fā)也是軟件開發(fā)腔彰，腳本必須符合規(guī)范叫编，必須經(jīng)過設計編碼測試維護的全過程。
·測試腳本的設計：根據(jù)面向?qū)ο笤O計的原則霹抛，我們需要對變化頻繁的地方進行必要的封裝搓逾。在這里變化相對最頻繁的就是UI本身，而相對穩(wěn)定的是業(yè)務邏輯杯拐。所以我們可以針對UI進行封裝霞篡，然后再封裝一層業(yè)務邏輯層，所有的測試用例都通過業(yè)務邏輯接口進行操作端逼。比如我們要測試一個登錄窗口朗兵，那么UI層就包含用戶名，密碼顶滩，登錄按鈕的UI定義余掖，邏輯層包含接口類似login接口，測試用例里邊就調(diào)用login接口登錄并進行必要的驗證礁鲁。
·測試腳本的編碼：既然是軟件工程盐欺，那么腳本也必須遵循代碼規(guī)范，比如python的腳本需要遵循python的代碼規(guī)范仅醇。
·測試腳本的測試：腳本是用于測試程序的冗美，那么自身的質(zhì)量也是至關重要。建議有條件的team進行code review析二，當然這個很難做到…… 另外就是至少要人工觀察腳本的操作粉洼，來確定它做了正確的事情。而且需要在不同的系統(tǒng)和機器上測試通過甲抖。
·測試腳本的維護：UI相對來說比較容易變化漆改，這就導致測試用例的fail，那么我們需要去調(diào)試并確認是腳本問題准谚，確認之后如果設計良好挫剑，大部分情況下只需要更新UI層就可以了。另外我們需要考慮是否UI變化過于頻繁柱衔，現(xiàn)在自動化開始是不是正確樊破？
·UI自動化測試開始的時機
·從前邊測試腳本的維護可以看出，維護工作量的大小唆铐，跟UI變動是否頻繁直接相關哲戚。我們需要做的事情，就是確定什么時候UI已經(jīng)穩(wěn)定了艾岂，我們再開始UI自動化顺少，否則還是考慮先人工測試覆蓋。當然了，我們也沒必要等整個程序的UI穩(wěn)定脆炎，比如一個獨立的功能UI穩(wěn)定了之后梅猿，我們就可以先對那個功能進行自動化，然后等待其它功能的UI穩(wěn)定秒裕。
·而且一旦UI自動化開始袱蚓，后邊的維護工作也相應要開始
·所以我建議開發(fā)過程中，有一個milestone叫UI freeze几蜻，這個階段后就可以著手開始UI的自動化測試了喇潘。當然，非UI的自動化梭稚，比如Unit Test颖低，Integration test和API test應該很早就開始了
·另外一種情況，是針對上一個版本release的功能的回歸測試弧烤，這個是最適合UI自動化的方面枫甲。一般來說，這種情況UI變動基本上沒有扼褪，而且功能比較穩(wěn)定，測試寫好之后粱栖，可以有效減輕手工測試的壓力话浇，而且可以更專注于新功能的驗證。
·需要考慮UI自動化的投入產(chǎn)出比
·我們先說投入：與軟件的投入產(chǎn)出一樣闹究，一個設計良好的UI自動化框架幔崖，最大的投入應該是創(chuàng)建框架和實現(xiàn)測試自動化腳本，而盡量減少維護的工作量渣淤。一個壞的自動化框架赏寇，前期可能投入較少，后續(xù)的維護和更改的成本可能幾倍與前期价认，甚至到最后只能丟棄掉嗅定。
·說到產(chǎn)出，自動化測試跑的次數(shù)越多用踩，平臺覆蓋越廣渠退，產(chǎn)出就越多，減少手工測試的工作量也越多脐彩。一旦自動化測試寫好碎乃，那就應該讓他們持續(xù)的跑起來，比如根據(jù)情況設置每周惠奸，每日梅誓，甚至是每次提交自動部署到所有平臺運行并報告結(jié)果。這個配合Jenkins來實現(xiàn)會比較方便。
（UI測試必備嵌言，無需自己寫腳本，完全零編碼愧怜，易操作）
