小康叔叔-

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

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

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

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

• 在不同瀏覽器下的兼容性；

• 交互效果是否達到預期；

• 頁面性能分析等。

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

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

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

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

• 監測前端頁面是否拋出了JS錯誤等 ...

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

• 操作瀏覽器，它可以按照腳本代碼對頁面做輸入、點擊、驗證提交等操作，和真實用戶操作流程一樣；
  

• 可以對頁面DOM進行操作；

• 可以執行JS；

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

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

以上就是我的看法，如果大家有其它看法，歡迎在下方評論區留言交流哈 ~

網絡圈

一般前端自動化測試大致包括類庫單元測試自動化UI組件測試自動化類庫單元測試自動化較好實現基本思路是讓不同的瀏覽器可以自動根據指令跑一些JS函數結果與預期比對後返回是否通過case測試標誌其中一般有兩種實現方式：其一：1.打開目標瀏覽器，運行測試框架站點2.測試框架站點通過ajax 輪詢、websocket 等方式，將待測 js 的 case 在瀏覽器內運行（通過eval 、createElement("script") 等方式）3.比對測試結果，將結果 post 到遠端4.遠端接受測試結果5.遠端等待所有瀏覽器返回結果完成6.marge 所有瀏覽器數據顯示最終通過與否結果。這種方式弊端：人工開啟一次所有瀏覽器需要排隊測試，瀏覽器只能一次運行完一組測試後才能再運行下一組如果中間某testcase導致瀏覽器異常，返回結果將缺失，需要人工去服務器上檢查下瀏覽器狀態好處：可以覆蓋所有想覆蓋到的瀏覽器另一種方式：1.將常用瀏覽器內核放進一個或多個相互有關聯的進程內2.用例通過系統消息發送到各個包裝的內核中3.每次開啟一個新內核進程運行JS用例4.用例結果發送給包裝進程5.包裝進程彙集所有用例結果後post到遠端保存6.包裝進程連帶內核進程一起退出優點：無序人工開啟一次瀏覽器獨立進程運行，無需排隊不怕內核異常，異常後包裝進程可以直接恢復內核或者通知測試失敗缺點：前端實現太困難，需要C++開發

web小學員

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

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

Unit-單元測試

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

Service-服務接口自動化測試

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

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自動化錄製工具)進行整體頁面的自動化測試。

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

軟件測試開發技術棧

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

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

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

測試領域專家

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

關鍵字: 自動化 科技 測試