標籤：

如何進行前端自動化測試？

01-01

前端自動化測試都包括什麼呢？要怎麼開始進行呢？看了phantomjs還是不知道怎麼應用於前端自動化測試

沒人邀請，路過回答。

前端測試是前端工程方面的重要分支，有過一些探索，這裡簡單分享一下。

首先，還是要強調一點：

前端是一種特殊的GUI軟體

看過我最近一年內做前端工程方面相關分享的人可能有印象，我總是在強調這一點。前端測試也跟這個理論基礎有所關聯。

在這裡，我還想吐槽一下：

API測試方法論在測試GUI時並不能解決所有問題。

與很多前端工程師討論過前端測試，大家更多的還是盯著API測試方法論。誠然，前端有那麼一小部分代碼是可以用API測試保證質量的，但前端項目中的絕大多數代碼是GUI界面，前端測試應該向傳統GUI測試方法論需求解決方案：GUI軟體測試_百度百科 ，這個百科詞條介紹的很不錯，大家可以感受一下GUI測試相關概念和方法。它的測試用例、覆蓋率統計、測試方法等等都與API測試有著很大的不同。

統一了這個認知之後，我們來討論一下前端GUI測試的特殊性。根據百科詞條上的那些介紹，相信大家都能感覺到GUI測試的成本非常高，而前端這種特殊的GUI軟體，具有天生的快速迭代特徵，這使得case維護成本也變得非常高，經常跟不上迭代速度。

一個標準的互聯網應用產品的前端部分，我粗略估計大概有20%的業務基礎代碼比較穩定，比如通用組件、通用演算法和數據模塊等，可以針對這些建立複雜一些的API和GUI測試用例來保證質量。剩下80%的部分不是很穩定，每天都在迭代，針對他們維護case的成本非常高。目前業界中號稱做了自動化測試的項目，也大多是在做那穩定的20%。

關於穩定部分的單元測試方法我這裡就不贅述了， @貘吃饃香 的答案給出了很多關鍵字，有興趣的去搜索就好了。我想討論的是針對剩下80%不穩定部分的工程化測試方案。據我了解，前端測試面對這些問題還是很無力的，業內大部分團隊還是靠堆人解決。

面對這種現狀，我其實也沒想到過什麼好的方法，基本原則就是：以最低的成本建立和維護自動化測試用例。到目前為止，就想到過兩個方案（都不是測試方案，只是回歸測試輔助）：

1. 不太靠譜的「超級工位」大法。

這個方案可以說根本不是什麼技術方案，而是一個辦公設施，就是我們準備一個工位，擺上所有我們需要測試的主流設備，然後設備通過某種方式與一台電腦相連接，測試人員坐在工位上，在電腦中輸入某個url，就能同步到所有設備中，然後開始逐個的人肉測試。

超級工位大法示意圖（應該很多設備的，這裡就是隨便展示一下而已。。。）

相比現在的前端GUI測試，超級工位已經算是從0到1的飛躍了，雖然沒解決什麼技術問題，但為測試前的準備工作做好了鋪墊。如果把前端測試比作吃屎，超級工位就是為這餐準備了一個好一點的餐桌。。。

2. 靠譜一些的「頁面差異監控」

12年的時候還在百度，當時有同事去美國參加velocity，twitter分享了一下他們的開發流程，其中有一個環節就是頁面對比監控，利用了一個叫pdiff的工具，每次提交代碼，會自動對比頁面之間的差異然後提醒測試人員注意回歸。這也是一個典型的GUI測試零成本維護用例的案例。不過pdiff這個工具是基於像素對比的，誤報率比較高，所以去年我做了一個這個項目：fouber/page-monitor · GitHub 基於DOM樹的diff，這樣就能很大程度上自主控制要監控的元素，可以設置監控樣式、文本的變化，比起像素diff智能了一些。

其工作原理就是利用phantom或其他headless瀏覽器訪問頁面，然後截圖，然後執行一段js，遍歷整個dom樹，獲取元素計算樣式和元素內文本內容，構造出一個JSON結構，然後每次diff這個json來判斷頁面差異，並標記在截圖上展示。dom樹的diff過程有點類似react的虛擬dom樹diff。

（react的dom樹diff演算法示意圖）

（react的dom樹diff演算法示意圖）

DOM樹diff我們可以分辨出元素樣式修改/內容修改/新增元素/刪除元素四種不同的頁面差異，我們可以配置選擇器來忽略元素。四種頁面差異的效果圖：

新增元素（綠色區域標記部分，「i am new here」）

刪除元素（灰色區域標記部分，「你好」）

內容修改（黃色區域標記部分，「百-度」，「新-浪」）

樣式修改（紅色區域標記的部分）

基於這樣的頁面差異對比監控，我們可以建立一個任務系統，把應用的所有頁面url監控起來，這樣每次版本迭代提交代碼後，系統就能自動告訴我們，哪些頁面的元素展現發生了改變，用於確定回歸範圍。

（目前我還只是把這個系統用於競品或者自家產品的運營監控）

（百度 @FEX 團隊開發的基於像素diff的組件監控平台）

用監控的方式確定測試回歸範圍，是一種「少吃屎」的手段，符合工程化要求，能比較大範圍的應用，雖然不能完美解決GUI中的交互問題，但能保證GUI的展現問題已經是不小的進步了。

=====[ 補充 ]=====

經評論中 @貘吃饃香 大大的提醒，這裡強調一下，頁面差異監控的目的是方便的通知人肉回歸範圍，這並非測試方案，而是一種輔助測試的手段。

瀉藥

還有 Selenium 神馬的吧

當然 berserkJS 興許也能湊合乾乾這事兒（類似phantomjs ）

個人認為一般前端自動化測試大致包括

  • 類庫單元測試自動化

  • 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++開發
  • 無法覆蓋到所有瀏覽器
  • 常用內核覆蓋更新勞心勞力

UI組件測試自動化

這是個大坑

因為 UI 涉及可視化內容

需要實現不同 testcase 的自動化界面操作

常見的如，單雙擊、拖拽、自動表單內容填寫等

一般用 Selenium 來錄操作後執行

或者使用 phantomjs 等工具寫模擬操作腳本來實現

這類東西一般就不太指望能跨全平台了，一個瀏覽器能跑通就不錯了。

======

針對這個稍微補充

比如 @張雲龍 說的方法，也只能針對 phantom 之類 qtwebkit 核來作簡單頁面 diff 展示情況對比。

它不能解決實際複雜情況：

  • 針對不同瀏覽（或不同網路情況）中斷吐出內容不一致（想像wap，雖然過時了）

  • 個人登錄後吐出內容不一致（社交網路）
  • 根據地域不同吐出內容不一致（百度搜索框計算什麼的）
  • 其他等等

大致問題了解下就好了

====

主要是 UI 的 testcase 寫起來太煩

而且 UI 還是最善變的

一般公司不去做這種費力不討好的自動化測試

基於 phantomjs 的自動化測試

它主要靠js腳本來模擬操作

一般流程是寫代碼寫代碼寫代碼

  1. open 某個 url
  2. 監聽 onload 事件
  3. 事件完成後調用 sendEvent 之類的 api 去點擊某個 DOM 元素所在 point
  4. 觸發交互
  5. 根據 UI 交互情況 延時 setTimeout （規避惰載入組件點不到的情況）繼續 sendEvent 之類的交互
  6. 最後調用截圖 api 發送操作結果到遠端用於人工（或機器）審核 UI 結果是否正常。

簡單說幾個方面，我自己嘗試過的。

1，nodejs端的有phantomjs, java的selenium都可以做固定流程的功能測試，比如全站的登陸，比如設置流程，比如網站功能的主流程，都可以測到，錄成腳本，後端直接跑。

2，瀏覽器插件部分，記得油猴么，還有chrome應該也可以寫定製的頁面額外腳本，管理好了，自己跑一跑當前頁面的ui測試也是可以的。一般用作回歸，這個對js的對外api有要求，腳本要能調用的到。

3，單測mocha，jasmine等等，不一一列舉，這個很多人熟悉啦。

4，截屏監控與頁面質量監控，這個一般成熟點的公司都有，比如上線後發現頁面大量dom有變化，會發出警報（簡訊郵件），設置一個闕值就ok了。

5，找台測試機寫腳本批量調用瀏覽器進程實測頁面，收集一些埋點，內嵌一些js跑功能，類似berserkJS。

6，最後的問題，測什麼，怎麼寫，回答：同學寫過爬蟲么，就是假裝自己是個用戶，去做操作，然後設置延遲，等待結果（跳轉，ajax 返回做dom修改等），再判斷此功能是否執行成功，ps，注意如果有flash的頁面，phantomjs配置起來略麻煩，那個可以再開個問題提問了。

其他答案基本把方案都說了，只能分享點我們團隊的經驗，主要是我們團隊沒那麼多人，沒有精力進行繁瑣的監控和人肉測試。

準備工作：

1. 我們為了能夠同時測試所有瀏覽器，選用 selenium，js 框架用 jasmine

2. 後端因為是 PHP，選用 facebook/php-webdriver · GitHub 來調用 selenium

3. 需要某種方法對頁面注入 jasmine 框架，我們因為是 Web App 圖方便直接用 ?test=1 的方式打開前端測試

4. 一個 staging 環境

測試/發布流程：

1. 腳本自動 deploy 到 staging，staging 先啟動 unit test，測試所有後端代碼一切正常

2. unit test 的最後，啟動前端測試，發送請求到裝有各種瀏覽器的一台機子，各種瀏覽器一一測試，webdriver 等待 jasmine 告知測試結果，看有沒有 errors

3. 一旦有 errors，deploy 工作暫停，修復bug，再來一遍

4. 如果 jasmine 告知 all tests passed，deploy 繼續，staging 環境啟動腳本，把代碼推送到production，執行 migration，本次發布結束。

（staging 就是和 production 相同環境相同機子，但使用不同域名和資料庫的測試站點）

另外：

其實我們試過用 CasperJS + PhantomJS + SlimerJS 寫測試，但這個方案不能覆蓋 IE，雖然我們只支持IE9+，但還是經常碰到一些莫名其妙的問題，最後放棄了。

（其實 webdriver 那段測試已經被我注釋了，因為前端測試經常無法通過，我們趕時間發版本，實在來不及修復）

轉自專欄：

[從入門到不放棄]多瀏覽器的自動化測試(1)-本地測試 - 知乎專欄

[從入門到不放棄]多瀏覽器的自動化測試(2)-雲服務測試

前端之殤

要是你碰到前端工程師朋友，那聊聊瀏覽器的兼容性準是沒錯，這和碰到英國朋友就談天氣是一個道理。大部分程序員朋友們一定會捶胸頓足，連連訴苦，不過如果對方一時語塞，或者欲言又止，請拍拍他/她肩膀說：「沒事，過兩年出了新瀏覽器又是一條好漢。」

在前端界，瀏覽器兼容性是讓工程師們頭疼的問題，對於經驗豐富的人來說，很清楚瀏覽器有哪些坑，但是對於大部分程序員，最可怕的是代碼明明在這個瀏覽器運行得很好，但是到了另一個瀏覽器中就不能正常運行了。對於這部分的程序員，保障代碼能正常運行的方法便是能儘早發現問題，然後將其解決。

通常情況下，發現兼容性問題的方法莫過於將程序在各個瀏覽器中執行一遍，但這是極其浪費人力和時間的，最省力的方法也需要在每次版本的更迭時重複一遍測試工作。對於不同的兼容性要求，測試需要的時間各不相同，若是只支持最新版本的瀏覽器，那麼便測試3、4個瀏覽器即可，但是對於兼容性要求高的程序，有可能要測試10個瀏覽器以上。對於中小型公司來說，如果沒有專職的測試人員，這樣的測試耗時是致命的。若進行嚴格測試，則會拖慢項目進度，倘若敷衍了事，那程序的質量便沒法保證。

本文將作為多瀏覽器自動化測試的第一篇文章，將以項目A作為例子，給讀者從頭介紹如何進行本地多瀏覽的自動化測試工作，包括測試的原理、測試框架的選取、測試工程的搭建和實現等。在下一篇文章中將介紹如何使用雲服務實現更多瀏覽器的測試工作。另外「從入門到不放棄」系列將給讀者們帶來更多從零開始的前端實踐案例，諸如前端組件庫設計與實施、項目自動化構建等案例，歡迎大家關注本系列的其他文章。

小窺測試

測試是一個龐大的主題，包括各種分類的測試，諸如黑盒測試/白盒測試、單元測試/集成測試/端到端測試等。通常程序員在測試自己的代碼的時候用得最多的便是單元測試，但是因為測試也是需要代價，很多人是不喜歡寫測試的，甚至是一點都不寫。當然今天我們不是要討伐諸位，而是希望讀者能從文中受益，從一個測試小白可以自己動手搭建自己的測試工程。

在多瀏覽器的自動化測試，我們多半是進行端到端的測試工作，一小部分是大粒度的單元測試。端到端測試測試模擬用戶的行為。在 Web 應用程序中，他們會啟動伺服器，打開瀏覽器，模擬用戶的行為進行點擊、輸入、提交等動作，斷言瀏覽器中發生了特定的事情或者是得到了期待的結果，從而讓我們相信功能可以正常的運行。而單元測試根據代碼單元的公共 API 運行它們。這些測試需要創建一個類的實例，使用特定的輸入調用它的方法，斷言被調用的方法達到了預期的效果。在下文中我們會看到這兩種測試的實踐，當然有時候區分度並不大，可能無法明顯地區分哪些是端對端測試哪些是單元測試，有時候他們是混合起來的，不過只要記住我們的目標是保證功能可以正常運行救足夠了。

在瀏覽器的測試中，Selenium 可謂是最重要的工具之一。簡單來說Selenium的作用是 "Automate Browsers"——讓瀏覽器可以自動化起來的工具。它提供了統一的介面，讓用戶可以使用不同的編程語言，調用其介面來模擬用戶的操作，例如點擊，移動等操作。基本上一切人工操作的行為都可以通過 Selenium 的 API 進行觸發操作。我們將 Selenium 看作是人手的代理，幫程序員完成一切用手乾的活。

測試的技術方案選擇

在進行項目實踐前，很重要的一項工作是選擇合適的技術棧。好比在前端開發時應該選擇 React，Vue 還是 Angular 作為框架一樣，前端的測試工作也需要選擇一套技術棧。很多時候大家在制定技術棧時容易走偏，在選擇技術框架時不是選擇最合適的框架，而是選擇最熱門的框架。當然一定程度上熱門的框架能反應其受歡迎程度，可能是因為其出眾的優點，如較高的開發效率、高效的渲染特性或者是活躍的社區。在前端開發中，很容易有這樣的感受，就是只要半個月沒有關注業界的最新動態，就感覺恍若隔世，新的解決方案層出不窮，讓人喘不過氣。就作者本人經驗來說，已經過了慌亂的年紀，再也不會盲目地追尋新技術，而轉向關注技術背後解決的痛點，就好像2C創業者們嘴上老說的用戶痛點一樣。

在介紹本文涉及項目的技術棧之前，需要提醒諸位，此處的技術選擇並不一定完全適用於諸位的項目，請各位三思而測。目前市場上有眾多的測試框架，測試斷言庫甚至是全套的測試解決方案。Karma、Jasmine 和 Mocha 是大家熟知的測試框架，而 chai, should.js 是流行的斷言庫，另外在不同的技術社區還有自成一套的測試技術，比如 React 社區中的 Jest 和 Enzyme 都是受開發者喜愛的測試框架和庫，最近一些新的並行測試解決方案也日漸流行，如AVA、Intern。本文中的實踐來自於項目A，在項目測試前期我們分析了測試需求，我們希望整個測試方案能滿足一下要求：

  • 支持端到端測試

  • 對接雲測試服務方便

  • 本地測試和雲測試切換方便

  • 提供封裝的瀏覽器操作介面

  • 測試用例可以快速遷移到其他框架下執行

考量了以上的需求，我們認為 NightWatch.js 是一款非常合適的測試解決方案。當然其他的測試框架也基本能滿足需求，但是從方便易用性上考慮，我們最後採用了 NightWatch.js，該方案不僅提供簡易封裝的瀏覽器代理操作 API， 還給我們提供了方便便捷的雲測試配置(下一篇文章將著重介紹此內容)，就憑這兩點就已經非常吸引我們了。對於前端測試新手，強烈推薦試用此框架，讓你可以迅速完成曾經畏而卻步的測試工作。

項目實踐

項目A的本地測試實踐是需要分別在兩台電腦上的多瀏覽器中執行測試，兩台電腦分別是 Windows 系統和 Mac 系統，包括了 IE 、Firefox(windows/mac)、Chrome(windows/mac)、Safari 等最新的主流瀏覽器。兩台機子的測試是分別執行的，我們通過 Jenkins 分別定期執行機子上的測試任務，將測試結果通過郵件的方式反饋給開發人員。 Jenkins 是一個持續集成的平台，關於如果使用 Jenkins 請各位自己 Google..

在接下來的文章中，我們將只介紹在一台機子上的工程實踐，對於多個機子的測試需要將如下的工程部署到不同的機子，再使用諸如 Jenkins 之類的工具進行定期執行就可以。

開始工作前，我們需要將技術關係瞭然於心。我們在 Nightwatch 框架下使用 Selenium 中的 driver對瀏覽器進行操作。不同的瀏覽器有不同的 Driver，整個技術棧圖如圖1所示：

圖1

在圖中 Test Runner 即為 Nightwatch，我們使用 Nightwatch 提供封裝過的 API 進行 Test Case 的書寫。下面我們將從零開始手把手教你如何使用 Nightwatch 啟動你的第一個 Test case。

1. 安裝測試所需包

在自己的前端項目中安裝 Nightwatch.js，並將其保存在 package.json的 devDependencies 中。

npm install nightwatch --save-dev

2. 增加 npm script 入口

在 npm scripts 中加入 test 指令入口，該條指令的具體工作是使用 test.conf.js 的配置，執行名為"A"、"B"、"C"的配置項(若為了直觀查看測試的內容，可根據項目的測試瀏覽器和版本將名字設為 chrome52.0, safari9.0 這樣的名字，此處設為 A,B,C 是避免大家誤認為是指令是自動根據名字去尋找匹配的瀏覽器）。更多命令的詳解請參照 Nightwatch 文檔。

"scripts": {
...
"test": "./node_modules/.bin/nightwatch -c conf/test.conf.js -e A,B"
...
}

3. 配置 Nightwatch

完成指令入口的配置工作，接下來需要完成 test.conf.js 的配置工作。在本地測試中，我們使用 Selenium 對瀏覽器進行代理操作。配置使用本地 Selenium 操作本機瀏覽器 Nightwatch 有三個重點：

  • Selenium 的配置：配置好 Selenium jar 包的路徑，該包從 Selenium 的官網上下載，host 和 port 按照下文配置書寫。
  • driver 的配置：cli_args 是 Selenium 參數，在這我們指定了 chromedriver 和 geckodriver 的路徑，chromedriver 是用來操作 chrome，geckodriver 用來操作 safari 和 firefox（顧名思義，geckodriver 支持基於 gecko 的瀏覽器），都可以從網上進行下載。在項目A中，我們將其下載到前端下面的 bin 目錄下。
  • 測試目標瀏覽器的配置：也就是A和B，每一個 Object 都是一個配置項，A是測試Chrome瀏覽器，B是測試 Safari 瀏覽器，如果沒有指定版本，就使用本地最新版，更多的配置可以參考 Nightwatch 文檔，可以指定系統、版本，並可以啟動、禁用瀏覽器的某些特性，如 Cookie。

selenium : {
"start_process" : true,
"server_path":"./bin/selenium-server-standalone-3.4.0.jar",
"host" : "127.0.0.1",
"port" : 4444,
"cli_args": {
"webdriver.chrome.driver": "bin/chromedriver",
"webdriver.gecko.driver" : "bin/geckodriver"
}
},
...

test_settings: {
A: {
desiredCapabilities: {
"browserName": "chrome"
}
},
B: {
desiredCapabilities: {
"browserName": "safari"
}
}
}
...

諸位需要根據自己機子的實際情況進行配置，如果是Windows系統，那麼將沒有safari瀏覽器，而使用 IE 瀏覽器，這樣則會需要 IE 瀏覽器對應的 driver。

4. 書寫測試用例

在各項準備工作完畢後，就只差測試用例了，下面是項目A的一個測試用例的片段，用於檢測頁面上 id 為 testid 的 DOM 中的內容字元，我們期待字元的長度為 32， 如果該字元為 32 個字元，那麼測試通過，否則測試失敗。需要注意的是因為此 DOM 是動態插入的，所以在判斷其字元前，我們使用 waitForElementVisible 來檢查瀏覽器中 testid 的 DOM 是否已經顯示，若在5秒內顯示則進行下面的工作，如果沒有顯示，那麼測試也會失敗。

module.exports = {
"@tags": ["unit"],
"unit testing" : function (browser) {
browser.url(`http://localhost:3010/test`)
.waitForElementVisible("#testid", 5000)
.getText("#testid",function(result){
this.assert.equal(result.value.length,32);
});
browser.end();
}
};

5. 運行測試

到此為止，我們簡單的測試工程已經搭建完畢。現在我們回過頭去，執行我們最開始配置的 test 指令，啟動測試任務。你需要在命令中執行：

npm test

如果順利的話，此時你會看到瀏覽器自動地打開關閉，很快就能從終端上看到如下的測試結果,圖2 展示的是多個測試用例成功的結果，圖3展示的是測試失敗的結果（如遇到無法測試或者其它異常情況請 Google。：D)。

圖2

圖3

從測試結果中可以查看測試用例的測試結果，包括測試的瀏覽器、未通過測試的信息詳情等。至此，一個從零開始的本地測試實踐教程結束。

本地測試與雲測試

因為本地瀏覽器的類型有限，一般我們更多地使用本地的多瀏覽器測試來完成功能驗證的工作，對於要求更嚴的兼容性測試，我們將採用雲測試的方式。雲測試即雲服務提供商將向我們提供更多的雲主機，每台主機上運行著不同版本的瀏覽器。通過使用雲測試服務，我們就能將測試覆蓋到更多類型、版本的瀏覽器。

在下一篇文章中，我們仍以項目A為例子，使用 Nightwatch 框架，在此文章的基礎上介紹雲測試和雲測試工程的搭建。

轉自：[從入門到不放棄]多瀏覽器的自動化測試(2)-雲服務測試 - 知乎專欄

在上一篇文章中，擼主已手把手教大家如何從零開始構建一個本地自動化測試工程。如果你沒有看過上一篇文章，請先逐字閱讀。本文將在上一篇文章的基礎上主要為大家介紹兩個內容：一是如何免費地搭建多機的自動化測試環境，二是如何使用雲測試服務進行360度無死角的自動化測試。信息量大，請各位閱後勿焚，動手牢記。

本地測試鞭長莫及

由於一台計算機支持的瀏覽器種類有限，如一台 mac 上可以安裝 safari, chrome, firefox, opera 等，而且通常只能安裝一個版本的產品，所以本地測試多用於檢驗功能邏輯是否正確，或者是檢驗特定瀏覽器的特定功能。對於未知的兼容性測試，單憑本地測試是沒法進行的。下文中介紹的方法將提供給測試者一種全新的測試體驗，通過遠程測試的方式對自己的代碼進行測試。 遠程測試需要搞清楚兩個概念，一是客戶端 (Client)，一是服務端 (Server)，Client 是用於運行 test cases 代碼的地方，Server 則是瀏覽器所在地。通過 Server 上的一些 servlet 來連接 Client 和 Server 上的瀏覽器，實現將 test 中的用例行為在遠程端的瀏覽器上執行。 通過瀏覽器和 test 執行宿主機的分離，使得test能在更多的瀏覽器上執行，並且更易於擴展測試瀏覽器的數量。在下文的實踐當中，讀者會對 Client 和 Server 有更清楚的了解，在此不再贅述。

自己的雲測試環境

既然測試代碼要和瀏覽器環境分割開來，那麼我們需要在前文的基礎上將瀏覽器安裝到其他的環境中，而不是將瀏覽器和測試的 Node 測試環境放在同一台機子。安裝完成之後需要使用服務端的 Servlet 也就是 Selenium 提供的 webdriver server 將測試環境和瀏覽器連接起來。具體的步驟如下： 1. 尋找到一台可用的主機： 無論是實體機還是虛擬機都是可以的，不過需要主機可以接入到測試運行主機的網路。

2. 在主機上安裝瀏覽器： 具體安裝的瀏覽器類型和版本根據操作系統和測試需求而定， 例如可以在 windows 操作系統上安裝 IE， firefox等瀏覽器，在 Linux 系統安裝 chrome, firefox等瀏覽器， 在 Mac系統上安裝 safari, chrome 等瀏覽器。

3. 下載對應瀏覽器的 driver 到Server主機上。因為 selenium 需要使用不同的 driver 來啟動不同的瀏覽器，如同上一篇文章提到的bin目錄下的 driver 可執行文件，此時要將需要測試瀏覽器對應的 driver 下載到 server 上，然後再通過測試工程的配置告訴 selenium-server-standalone 這些 driver 在哪，從而執行它們來操作瀏覽器。

  • chromedriver (用於 chrome)下載地址: https://sites.google.com/a/chromium.org/chromedriver
  • geckodriver (可用於 firefox, safari)下載地址:https://github.com/mozilla/geckodriver/releases

4. 在主機上下載並啟動 Selenium Server: 該 Server 實際上是一個 Java 小程序，用於 client 和 server 之間的通信（有關 selenium 原理的文章請關注《搞不懂不甘心》系列）。首先在 Selenium 的官網上下載 selenium-server-standalone-{VERSION}.jar， 然後啟動該 Jar 包。

java -jar selenium-server-standalone-{VERSION}.jar

如果主機沒有安裝 JRE, 則需要再安裝 java 的運行環境或者是直接安裝 jdk 。

5. 修改測試項目的配置文件：還記得啟動測試時需要指定的配置文件嗎？這個配置文件 test.conf.js 非常重要，用於配置 selenium 以及測試的瀏覽器，當我們改變使用遠程server的瀏覽器作為測試目標時，當然需要修改配置文件。我們需要將配置文件中的 selenium 項修改為如下形式：

selenium : {
"start_process" : true,

//server的ip地址
"host" : "192.168.10.1",

"port" : 4444,

"cli_args": {

//chromedriver 在server主機上的文件路徑
"webdriver.chrome.driver": "/home/bin/chromedriver",

//geckodriver 在server主機上的文件路徑
"webdriver.gecko.driver" : "/home/bin/geckodriver"
}
}

對於test_settings的設置請參照上文，然後按照自己安裝的瀏覽器版本進行修改。

6. 啟動測試：一切準備好了之後，在client主機上，也就是測試代碼運行的機子上便可啟動測試。

"scripts": {
...
"test": "./node_modules/.bin/nightwatch -c conf/test.conf.js -e A,B"
...
}

自己搭建測試雲環境的過程其實並不複雜，只需要在將 selenium server 和瀏覽器安裝到其他主機即可，對於 client 上的代碼不需要改動，只需要改動配置中的 selenium 配置。但是很快測試者會發現，當我們需要測試更多的機子，用手工的方式去維護這些 server 是一件費時費力的事，也消耗了公司的計算資源。有沒有更好的辦法讓我們既可以全面的測試自己的代碼又可以不用費盡心思維護主機？答案是有，請繼續閱讀。

雲測試服務

對於繁瑣重複的工程任務，商家們總是能想到賺錢的辦法，這不對於上文我們碰到的麻煩就有商家提供了相應的產品。該產品為測試者們提供無數個測試瀏覽器，測試者不需要關心這些瀏覽器在何處運行，應該怎麼樣維護，只需要一個服務地址便可以將自己的測試頁面跑在這些瀏覽器上，其實這個服務地址和之前我們自己搭建的 Server ip 類似，只不過如果使用自己的測試雲，使用不同的測試主機時，需要手動更改host。而這些商家提供了一個類似分銷中心，用於流量分發，所以我們只需要用一個地址便可實現使用不同的主機進行測試。 目前提供此類服務的商家有很多，如 browserstack、saucelabs、crossbrowsertesting 等，大家可以根據自己手頭黃金和測試的需要選擇性價比高的服務。本文將使用 browserstack 作為例子為大家科普此類服務，不過它並不是擼主的金錢爸爸，請大家放下水文的猜疑。

根據我們自行搭建雲測試環境的經驗，我們將 browserstack 的測試後台架構猜想為下圖所示。我們不關心該架構是否是真實的實現，但是這是合理的理論猜想，希望此圖能讓我們對此服務有個大概的技術了解：

browserstack 為用戶提供了自動化測試、實時交互測試、截圖等服務，關於具體的服務細節請移步官網。本節將主要介紹如何使用其自動化測試服務，會稍微提及實時交互測試的功能。那接下來便開始我們的雲測試使用體驗： 首先在其[網站](https://www.browserstack.com)上註冊賬號，點擊最上方的導航欄中的 Automate，跳轉頁面後在新頁面左側最上方點擊 」Username and Access Keys」，便可看到用於使用雲測試服務的用戶名和key，我們將使用此auth來修改測試配置。 現在回到我們的測試項目，對 test.conf.js 的 selenium 項進行修改，並添加 common_capabilities 項，用於配置雲服務的信息。

selenium : {
"start_process" : false,
"host" : "hub-cloud.browserstack.com",
"port" : 80
},

common_capabilities: {
"build": "nightwatch-browserstack",
// Browserstack 的 username 對應配置項
"browserstack.user": process.env.BROWSERSTACK_USERNAME",
// Browserstack 的 key 對應配置項
"browserstack.key": process.env.BROWSERSTACK_ACCESS_KEY,
"browserstack.debug": true,
"browserstack.local": true
}

連接雲測試服務的配置工作完成後，我們需要指定測試的瀏覽器種類和版本。如果有不指定的欄位，雲服務會有預設值來填充，例如配置中沒有指定操作系統，雲服務則會自動選擇最快的一個測試機，而不管瀏覽器所在的操作系統。再例如當沒指定測試瀏覽器的版本時，雲服務則會測試最新版本的瀏覽器。官網上的文檔提供了所有可提供測試的瀏覽器種類和版本，為了說明方便，我們現在只指定瀏覽器種類，不規定版本。簡要的瀏覽器配置項如下：

...
safari: {
desiredCapabilities: {
browserName: "safari"
}
},
ie: {
desiredCapabilities: {
browserName: "ie"
}
},
...
ios: {
desiredCapabilities: {
browserName: "iPhone"
}
}
...
}

以上工作做完之後便可以啟動測試了，是不是so easy。除了命令行返回的測試結果之外，browsertack 自動化測試還為我們提供了測試回放等。如果發現測試出錯，可以通過商家提供的在線實時測試來進行調試，這也是一個非常方便的功能。

有的放矢地測試

閱讀完自動化測試的文章，相信大家已經迫不及待想體驗雲測試的便利。在各位動手之前，有一些溫馨提示需要告知大家。首先這些雲測試服務因為由國外服務商提供，所以網路延時有些時候會過高，測試可能會出現超時的情況，請選擇網路較好的主機來運行測試用例。其次是因為自動化測試會讓大家寫測試用例上癮，反正測試扔上去測就好，但是擼主認為測試人員還是要清楚地劃分測試的粒度，有些測試用例比如細粒度的單元測試和端對端的測試，有很多測試覆蓋的都是同樣的代碼，這樣的測試其實是浪費的，所以在明確目標之後，還需要精心設計測試用例。最後如有不懂請先 google，其他不能 google 的問題歡迎和擼主交流，文章若有錯請指教。

您好。我現在正在做js自動測試這塊。測試分為單元測試和ui測試。都是要用到測試框架的。測試框架可以用現成的也也可以自己寫

首先吐槽一下，UI自動化測試和API自動化測試還處於一個很劣勢的地位。大部分網頁設計之初並沒有按照先擬定測試用例再編寫代碼的模式，很多tag命名混亂，介面返回標準頻繁更改，如果自動化測試代碼耦合度強，版本一升級就等著填坑吧…

如果不是做研究或有極客癌的話，在頻繁迭代的情況下，怎樣設計框架才能保證測試效率跟的上節奏，才能把鍋及時的甩給開發或運維人，才是生存之道。

正題分割……………………………………………

至於用selenium還是phantomjs樓上的大神都說的比較明白了，我說一下設計框架的問題，個人認為最簡單暴力的方法就是selenium2(webdriver)+testng。手寫查錯重跑機制會有很多意想不到的坑比如瀏覽器崩潰，頁面測試邏輯錯亂等等，testng一站式囊括重跑，停止，輸出這些自己寫起來吃力不討好的功能，而且在開發過程中方便調試。

另外selenium功能齊全支持xpath，支持js，這就意味著你能夠在測試過程中實現任何js可以實現的功能。只要你代碼的耦合度夠弱，實現針對特定頁面的傻瓜式可配置測試也很容易，不過成本也算比較高了。

ps.其中的一個坑是效率問題，4g的機器，selenium並行跑在jvm上很容易內存溢出，二三十個網頁就臨近崩潰了，所以為了保證性能，寧願慢一點或是單網頁測試最穩妥。(網路差的時候放在夜裡跑7個小時測整個系統啊)

不同規模的公司，不同疊代速度的產品測試方式不一樣。

如果是更新頻率較低的產品，可以應用大家談到的基於截圖的測試，腳本測試等技術手段，但是對於大多數中小公司來說，然並卵，這樣乾的成本相當之高，你測試還沒出來產品設計又給丟給你一大波新的設計圖鳥。

因此，俺比較推薦的方式是對核心邏輯做基於數據層面的針對性測試，這樣做的性價比比較高，用來保證在上線時不出重大的 bug。

要使用這個方案需要前端配合使用 MVVM 的結構，不論是 App 還是 Web 端都可以用，只要保證 ViewModel 裡面的邏輯正確即可。

在 iOS 裡面使用 MVVM + ReactiveCocoa 那是灰常地爽 ~~~

測試是完善的研發體系中不可或缺的一環。前端同樣需要測試，你的css改動可能導致頁面錯位、js改動可能導致功能不正常。由於前端偏向GUI軟體的特殊性，儘管測試領域工具層出不窮，在前端的自動化測試上面卻實施並不廣泛，很多人依舊以手工測試為主。本文試圖探討前端自動化測試領域的工具和實踐。

為什麼需要自動化測試

一個項目最終會經過快速迭代走向以維護為主的狀態，在合理的時機以合理的方式引入自動化測試能有效減少人工維護成本。自動化測試的收益可以簡單總結為：

自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本

其實最好的方法是人工智慧的終極階段 - 雲三哥 ... 嗯你們懂得

傳統的介面測試往往是介面一個個運行，觀察返回數據是否顯示正確，然後再用這個介面的出參手動的填入下一個介面的入參，這樣的測試流程不僅很繁瑣，效率低下，遇到業務場景比較複雜的很容易發生錯誤。所以我們需要一個自動化測試的解決方案，可以用最少的代價做最有效率的事情。

可以看我的文章如何使用DOClever在前端對介面進行自動化測試！

pyswat框架是完全採用錄製的方式生成案例，做web端的UI自動化測試非常方便

剛剛開始用selenium2,覺得還不錯，只是對於界面的驗證，還需要後期人工手動對截圖進行比對

看了以上大神們的答案，對前端自動化測試工程師的前景堪憂，公司完全沒有必要去養這些專職的自動化測試工程師

有QTP，有selenium,尤其是selenium，結合Python的unittest，可以部署自己前端自動化測試方案了。先馬克，有空了再答。

推薦閱讀：

※把 css文件和 js文件放在 Github 里，可以在寫網頁的時候直接調用嗎？
※剛開始學編程，看別人的代碼感覺高山仰止，開始喪失信心怎麼辦？
※前端工程師懂設計對工作是否有用？
※web前端開發工程師，年過30，崗位最多升到前端經理。如何規劃前景?
※各位師兄師姐好，自學Web前端可以給點建議嗎？

TAG:前端開發 | 測試 |