根據我自己的工作經驗，自動化測試一般用於迴歸測試和相容性測試。現在移動端測試，要涵蓋的機型很多，蘋果還好，安卓的機子簡直數不過來，手工去相容的話，一個人最多看3-4個，再多就顧不過來了，耽誤進度了。寫一個自動化指令碼，可以執行在所有你要相容的機型上面，就會節省很多人力和時間。東軟的一款產品我們使用過叫UTF在自動化測試這做的很好。歡迎瞭解東軟平臺產品https://platform.neusoft.com/

1、需要確認使用的技術棧，java、python還是javascript；

2、前端一些框架：appium、webdriver都比較成熟了；

3、如果組內整體開發技能不高，則需要寫一套框架了，其他人使用關鍵詞驅動去執行。

首先來說，前端自動化測試在實際應用中還是較少的！為什麼這樣講呢？我們得先了解自動化測試是為了解決什麼問題的，以及自動化測試的侷限性。

自動化測試的目的很簡單，就是解放人力，將一些重複性核驗工作交給程式自動去檢測。但問題來了，對於一般後端功能來說，自動化測試是比較容易實施的。但對於前端來說，自動化的應用場景還是較少的。

我們知道，如果是測試人員對前端頁面進行測試，主要測試點有：

介面排版佈局是否和效果圖一致；

在不同瀏覽器下的相容性；

互動效果是否達到預期；

頁面效能分析等。

從上面來看，介面佈局和相容性人工測試都比較難，自動化實施起來複雜度也很高。從另外一方面來看，前端頁面改動的可能性較大，所以UED方面的確不適合實施自動化測試，成本太高！

那是不是說前端領域就真的沒法實施自動化測試了呢？其實也不是，比如我們將一些偏底層性的核驗交給程式來自動化測試。比如用程式來實現：

監測前端頁面是否存在死鏈；

監測前端頁面圖片尺寸是否過大，需要裁剪；

監測前端頁面是否丟擲了JS錯誤等 ...

前端自動化需要了解 Selenium ，同時你需要掌握一種程式語言，如Java、Python等。利用Selenium可以實現以下功能：

可以對頁面DOM進行操作；

可以執行JS；

如果有興趣，可以去GitHub上搜索一下：checkConsoleError 、check404 ，這兩個小工具是我用Selenium寫的前端自動化測試小工具。

當然了，一般前端人員還是很難駕馭Selenium的，因為要一定的程式設計能力才能寫出測試指令碼。對於一般前端人員我們建議使用類似的IETester來測試頁面相容性即可。

在回答這個問題前，先大概介紹以下內容，以便理解。若認為贅餘，可直接閱讀最後一章節。

結合測試分層自動化測試思想

Unit-單元測試

一般由開發人員開展測試，寫單元測試用例也是開發人員對自己的程式碼進行檢查的一個過程。

Service-服務介面自動化測試

通常指的是介面自動化測試，在分層自動化測試的應用中，介面自動化是最常用的自動化解決方案。

結合資料驅動測試框架、關鍵字驅動測試框架可以滿足大部分測試場景，包含含有複雜業務邏輯的功能的覆蓋（B介面依賴A介面返回）。特別是在前後端分離的產品架構設計中，可以對功能點進行有效的覆蓋，至於頁面顯示、頁面元素佈局、展示的驗證可以透過手工測試或者其他工具覆蓋。

UI-頁面自動化測試

UI層是與使用者進行互動的，測試工作大多集中在這一層。根據個人實踐經驗，大部分場景下不推薦UI自動化，難以做到高效的維護，關於UI自動化的兩點建議:

能在底層做自動化覆蓋，就儘量不在UI層做自動化覆蓋 只做最核心的功能的自動化覆蓋，指令碼可維護性儘可能提高自動化測試開展的必要條件

首先，是否開展自動化，通常需要同時滿足以下條件：

軟體需求變動不頻繁(超過10%的變動是頻繁變動，同時10%並不是一個固定值，根據其維護、擴充套件成本適當調整閾值)專案週期足夠長 自動化測試用例可重複使用

同時，自動化測試的是否易於擴充套件、易於維護對其可持續性而言非常重要。

自動化測試的侷限性

一方面，自動化測試的侷限性體現在上述其開展的必要條件，如果在不滿足其必要條件的背景下，開展自動化會發現自動化並不會提高測試效率，甚至可能加大了測試成本。

另一方面，UI自動化與介面自動化本身的侷限性，UI自動化較介面自動化而言其具備覆蓋率高的優勢（介面測試無法覆蓋頁面元素、格式、資料），介面自動化較UI自動化而言具備高擴充套件、易維護、問題修復成本低的優勢。

自動化測試的目的

自動化測試的直接目的是圍繞產品質量提高測試效率，其根本目的（效率轉化）無外乎以下幾點：

真正的實現專案人力投入的縮減

做更多更有意義的測試，比如更深入的需求分析、測試設計或者對測試左移、右移的投入；

適應開發模式的轉變，比如類敏捷、devops、testops模式下的頻繁迭代、持續部署、質量運營等。

如何進行前端自動化測試

前面鋪墊了很多，終於可以回答這個問題了。。。感謝讀者能夠耐心讀到此處。。

我們知道UI自動化其開展的前提更強調系統的穩定性，不穩定的系統會導致頻繁的自動化用例維護，這種維護成本是巨大的，甚至會出現原本兩個人測試的專案，引入UI自動化現在需要三個人測試的情況。那麼系統穩定性高，改動的可能性較小的情況下如何進行UI自動化？——建議使用Robot Framework + Selenium2Library，同時自動化測試設計時考慮資料與程式碼分離，以便減低維護成本，提高其可擴充套件性。

如果系統的穩定性一般，存在需求改動、頁面最佳化的可能性，如何開展高覆蓋的自動化測試？——建議使用Robot Framework + RequestsLibrary +Python requests(自定義關鍵字型檔開發)實現介面自動化，也需要考慮資料與程式碼分離的設計策略，同時RobotFramework支援資料驅動，用例編寫效率會得到很大的提升。基於此再使用UI Recorder(阿里開源的一款零成本UI自動化錄製工具)進行整體頁面的自動化測試。

最後，充分考慮易維護性、易擴充套件性的自動化測試策略設計，是可以實現自動化測試前移的，並非只能用於系統穩定或者回歸測試的場景中。