前端自動化測試探索

背景

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

爲何須要自動化測試

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

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

對於自動化測試來講，相對於發現未知的問題，更傾向於避免可能的問題。

可測試方向

首先本文不會探討單元測試方向，由於單測已經有完善的工具體系。但前端開發中，除了一些框架和庫，願意去寫單測的少之又少。另外單測維護成本較高，並且也無法知足前端測試的全部需求。

前端自動化測試能夠在幾個方向進行嘗試：

• 界面迴歸測試 測試界面是否正常，這是前端測試最基礎的環節

• 功能測試 測試功能操做是否正常，因爲涉及交互，這部分測試比界面測試會更復雜

• 性能測試 頁面性能愈來愈受到關注，而且性能須要在開發過程當中持續關注，不然很容易隨着業務迭代而降低。

• 頁面特徵檢測 有些動態區域沒法經過界面對比進行測試、也沒有功能上的異常，但可能不符合需求。例如性能測試中移動端大圖素材檢測就是一種特徵檢測，另外常見的還有頁面區塊靜態資源是否符合預期等等。

業界開源工具

工欲善其事，必先利其器。業界在自動化測試領域已經有很多優秀的框架和庫，善於利用能事半功倍。

界面迴歸測試

界面迴歸測試常見的作法有像素對比和dom結構對比兩個方向。

像素對比

像素對比基本的思想認爲，若是網站沒有由於你的改動而界面錯亂，那麼在截圖上測試頁面應當跟正常頁面保持一致。能夠跟線上正常頁面對比或者頁面歷史記錄對比。像素對比能直觀的顯示圖像上的差別，若是達到必定閾值則頁面可能不正常。

PhantomCSS

像素對比比較出名的工具是PhantomCSS。 PhantomCSS結合了 Casperjs截圖和ResembleJs 圖像對比分析。單純從易用性和對比效果來講仍是不錯的。

不支持PhantomJS 2.0的問題

因爲PhantomJS 2.0暫時禁用了文件上傳，PhantomCSS默認不支持PhantomJS 2.0 。若是仍是想使用能夠修改源碼中獲取圖片文件的方式，改成經過ajax獲取同域名下文件的方式，具體能夠參考ResembleJs官網示例。

如何測試多瀏覽器

若是想測試多瀏覽器下的兼容性狀況，只須要拿到多個瀏覽器下的截圖便可。多瀏覽器測試最出名的當屬selenium , selenium能夠自動化的獲取多個瀏覽器下的截圖，前端工程師來講還能夠藉助Node的webdriver 來輕鬆開發測試腳本。

但selenium的安裝和上手成本要稍大些，並且對於多瀏覽器來講，各個瀏覽器之間的兼容性對比容易出錯。不一樣瀏覽器截圖可能一像素的誤差就致使截屏對比失敗，多瀏覽器可能更適用迴歸性測試。

響應式頁面測試

國外有人將像素對比應用到了響應式頁面上，若是您針對PC和移動設備使用同一個網頁，響應式測試能夠很快的迴歸你的頁面在不一樣尺寸上的頁面是否正常。與單純針對移動端開發的響應式不一樣，同時支持PC移動的頁面更容易發生錯亂。

例如BackstopJS 項目，即是經過PhantomJS、capserJS等工具在不一樣尺寸下截圖而後根據resemberJS進行像素比對判斷是否正常:

像素對比須要注意的問題

• 不建議對網站全部頁面進行測試 這隻會致使很容易出現告警，但不必定是錯誤。針對重複使用的組件和樣式、容易出問題的區域測試更加有效

• 推薦測試區域而不是整個頁面 整個頁面的測試致使任何一點文字、圖像等動態的改變均可能致使不經過，並且真正的錯誤可能因爲圖像太大而被閾值忽略。圖像越大對比也越容易超時。

• 隱藏動態區域 在選擇器對應的區域若是有動態元素，能夠一樣經過選擇器來隱藏

• 界面對比只是一個環節，需與其餘測試相結合 沒有銀彈，合理結合纔是關鍵

dom結構對比

像素對比雖然直觀，但動態元素居多且沒法保證測試頁面與線上頁面同步時有所侷限。@雲龍大牛針對這個問題提供了新的解決方案page-monitor，根據dom結構與樣式的對比來對比整個頁面的變更部分。 使用效果示例：

經過page-monitor你能夠很快的搭建一個監控系統，監控頁面的文字、樣式等變更狀況。

像素對比和dom結構對比各有優點，但也沒法解決所有問題。何不綜合利用呢？FEX部門QA同事就結合了兩種方式提供了pagediff平臺，正在對外公測中！有興趣能夠體驗一把吧~ http://pagediff.baidu.com

QA同窗開發的平臺都這麼炫，做爲前端怎麼能不瞭解一點測試知識呢？

用戶操做測試

上面提到界面迴歸測試沒法取代功能測試。即使是界面正常，功能正常也是必須關注的部分。最直接的功能測試就是模擬用戶操做，經過模擬正常的操做流程來判斷頁面展示是否符合預期。

Phantomjs、CasperJS

大名鼎鼎的PhantomJS固然要隆重介紹啦！前面界面對比測試基本都是基於PhantomJS開發的， Phantom JS是一個服務器端的 JavaScript API 的 WebKit。其支持各類Web標準： DOM 處理, CSS 選擇器, JSON, Canvas, 和 SVG。對於web測試、界面、網絡捕獲、頁面自動化訪問等等方面能夠說是信手拈來。

casperjs是對PhantomJS的封裝，提供了更加易用的API, 加強了測試等方面的支持。例如經過CasperJS能夠輕鬆實現貼吧的自動發帖功能：

casper.test.begin('測試發帖功能', function suite(test) { //登陸百度 casper.loginBaidu();//實現略，能夠經過cookie或者表單登陸實現 casper.thenOpen('http://tieba.baidu.com/p/3817915520', function () { var text = "樓主好人"; //等待發帖框出現 this.waitForSelector( '#ueditor_replace', function() { //開始發帖 this.echo("開始發帖。發帖內容: " + text,"INFO"); //執行js this.page.evaluate(function(text) { $("#ueditor_replace").text(text); $("a.poster_submit").click();//點擊提交 },text); },function(){ test.fail("找不到發帖框#ueditor_replace"); } ); }) .run(function () { test.done(); }); }); 

經過前端最熟悉的語言，短短几十行代碼即可輕鬆實現自動發帖的功能，還能夠在其中添加一些測試邏輯來完善case。

相對於單測來講，casperjs能用簡單的API、從真實用戶操做的角度來快速測試網站的功能是否正常，而且能夠保留每一步測試的截圖最終實現操做流可視化。例以下面這個GitHub項目便使用Casperjs測試一個電子商務網站的登陸、下單等重要流程是否正常。case完善以後一條命令即可測試整個網站。

casperjs能監聽測試和頁面的各個狀態進行截圖等操做，若是針對測試運行結果稍做優化，即可以造成一個可視化操做流：

經過這個能直觀的看到各個操做的狀況以及錯誤的步驟(若有錯誤圖片將飄紅)，下面則能夠看到casper 測試的詳細日誌輸出。

不想維護case?

除非有足夠的QA同窗來幫你完成測試工做，不然經過人工來回歸確定會消耗更多的精力。在項目功能基本穩按期，維護case會簡單的多，並且一樣建議針對網站核心功能而不是全部功能來添加case。

瀏覽器兼容測試

固然selenium一樣支持操做測試，相似的工具還有dalekjs等，若是想專門針對IE測試，能夠考慮[triflejs]http://triflejs.org/,它提供了與PhantomJS基本相似的API。

PhantomFlow操做對比測試

有沒有像圖像對比同樣直觀，又能比較簡單的寫case的工具呢？能夠考慮PhantomFlow, PhantomFlow假定若是頁面正常，那麼在相同的操做下，測試頁面與正常頁面的展示應該是同樣的。 基於這點，用戶只須要定義一系列操做流程和決策分支，而後利用PhantomCSS進行截圖和圖像對比。最後在一個很讚的可視化報表中展示出來。能夠看下做者所在公司進行的測試可視化圖表：

圖片中表明不一樣的操做，每一個操做有決策分支，每一個綠色的點表明圖像對比正常，若是是紅色則表明異常。點擊進去能夠查看操做的詳情：

不得不說這是一個不錯的構思，它將操做測試的case濃縮成決策樹，用戶只須要定義進行何種操做並對關鍵部分進行截圖便可。若是網站偏向靜態或者能保證沙盒地址數據一致性，那麼用這個測試工具能有效提升實施自動化測試的效率。

性能測試

網站展示性能也愈來愈成爲人們關注的點，尤爲是移動端性能始終是一個影響體驗的重要因素。通常開發者都會利用自動化工具對資源進行合併壓縮等優化，不少大公司也都搭建本身的性能監控系統指導優化工做。性能監控能夠參考個人另外一篇文章七天打造前端性能監控系統。

須要注意的是性能並非一個目標，而是開發、測試過程當中須要持續關注的問題。咱們有自動化的工具和框架在開發時進行優化，一樣能夠藉助工具在測試時進行性能測試。

這裏推薦一個一樣是基於PhantomJS的工具Phantomas,它能運行測試頁面獲取不少性能指標，加載時間、頁面請求數、資源大小、是否開啓緩存和Gzip、選擇器性能、dom結構等等諸多指標都能一次性獲得，而且有相應的grunt插件。你也能夠對檢測指標進行二次開發，例如移動端定義一個最大圖片大小的規則，在開發的時候若是使用了超過限制的大圖則進行告警。不過若是把加載過程當中的時間點做爲常規的測試監控，則最好模擬移動端網絡環境。

頁面特徵檢測與實踐

前面講到性能測試中測試資源大小其實就屬於一種資源特徵，諸如此類咱們還能夠開發一些通用的測試規則，以測試頁面是否正常。這種測試主要適用於在界面和操做上沒法直接進行判斷的元素。例如頁面中廣告部署是否正常。

廣告部署檢測實踐

第三方部署廣告以及物料配置的時候容易出現問題，例如代碼腳本升級出錯、部署錯誤、物料尺寸格式不對、廣告容器未適配多種屏幕大小、廣告是否可見、時效廣告是否展示等。已知的問題就有不少，若是出現問題時由廣告系統的人員挨個檢測是一個很耗費人力的過程。而這些特徵都是跟實際運行環境相關的，大部分均可以經過casperjs之類的工具來進行檢測。

另外與廣告相關的還有屏蔽檢測等，檢測頁面div廣告區塊(非iframe廣告)是否被攔截插件所攔截。因爲攔截插件使用的基本相同的攔截規則，並且對於div廣告採用的是選擇器屏蔽，檢測過程當中只須要根據相關的檢測規則判斷選擇器是否存在頁面中便可。這在casperjs中一個api便可搞定:

if(casper.exist(selector)){ casper.captureSelector(filename,selector); } 

這樣便能直接截圖被攔截的區域了。

與自動化測試的結合

回到剛纔的需求，如何經過casperjs實現這些檢測需求呢。casperjs支持執行JS來獲取返回結果：

this.page.evaluate(function(text) { $("#ueditor_replace").text(text); $("a.poster_submit").click();//點擊提交 },text); 

並且能夠主動注入jquery或者zepto等框架，這樣你就能夠以很是簡單的方式來操做分析dom元素了。例如根據html結構特徵獲取部署類型、自動掃描廣告檢測容器寬度、獲取廣告的選擇器來進行截屏等。若是頁面有報錯能夠經過casper的api進行監聽：

casper.on("page.error", function(msg, trace) { this.echo(msg,'WARNING'); //詳細錯誤信息 if(trace){ this.echo("Error: " + msg, "ERROR"); this.echo("file: " + trace[0].file, "WARNING"); this.echo("line: " + trace[0].line, "WARNING"); this.echo("function: " + trace[0]["function"], "WARNING"); } }); 

還能捕獲網絡請求分析死鏈或者廣告請求：

//記錄全部請求 casper.on('resource.requested', function(req,networkRequest) { //do something }); 

更加讚的是你還能夠進入到跨域的iframe裏面去進行操做！

casper.withFrame(id/name,function(){ //now you are inside iframe }) 

注意: iframe操做時推薦用name，id有時候會發生錯位。

檢測示例：

能夠說有這麼讚的工具你能輕鬆實現不少意想不到的需求！

配置化減少成本

在開發了檢測工具以後，固然要想辦法減少使用成本，如上面例子中，只需將廣告檢測的一些規則和檢測頁面進行配置化，用戶使用的時候只須要關注須要測試哪些頁面而已。工具會根據用戶提交配置自動運行並將結果返還給用戶。

與CI的結合

講到這裏，上面這些步驟很像ci系統啦！若是能經過ci實現一系列的自動化部署測試等工做，使用上就更加順暢了。

談起ci確定要介紹jenkins,穩定可靠，是不少大公司ci的首選。只是在前端的眼中它看起來會感受。。醜了點和難用了點。。若是能像travis-ci那樣小清新和直觀易用該多好哈哈。

固然若是你要本身實現一套相似ci的流程也不復雜，由於對於上面提到的自動化測試來講只須要一個隊列系統處理批量提交的測試任務而後將運行結果反饋給用戶便可。固然前端測試可能對於自定義的報表輸出要求更高點。若是你想實現一套，使用laravel和beanstalkd能快速搭建一套完善的隊列系統，laravel已經提供不少內置支持。各個服務的運行結果輸出成html報表，就能實現一套輕量級且支持自定義展示的ci系統了。這方面有不少教程，能夠自行搜索。

國外作的比較好的輕量級ci系統有:

• http://wercker.com/
• https://semaphoreci.com/
• https://codeship.com
• https://circleci.com/
• …

良好的用戶體驗讓人使用的心情愉悅沒有障礙，若是想定製能夠做爲參考。

實踐經驗

前端自動化測試能夠說仍是一個在不斷探索的領域，實施過程當中也不免遇到問題。有些須要注意的點能夠做爲經驗參考。

減少使用和維護成本

自動化測試爲人詬病的地方無外乎使用效果和使用成本，使用效果能夠對症下藥選擇合適的工具，而使用成本則能夠經過一系列措施來減少到合理程度：

• 與構建工具結合

  grunt、FIS，將自動化測試與構建工具結合能更早的發現問題，也能減少使用和維護成本

• 與持續基礎結合

  與CI系統的結合能更大範圍更有效的發揮自動化測試的做用

• 與工做流結合

  與平常工做流結合一樣是爲了減小使用成本，如將結果經過自定義的方式反饋給用戶等。

• 測試配置化

  測試配置化能讓用戶使用和維護更加簡單、大部分狀況下只須要維護配置腳本便可

注重細節提升問題定位能力

每一個產品都有自身的特色，若是隻是粗略的使用這些開源工具，可能達不到想要的效果，須要根據自身的狀況選擇合理的工具並進行必定的調優。只有不斷提升自動化測試的問題定位能力，才能真正發揮自動化的價值。

利用開源力量、合理搭配使用

1. 若是遇到問題，請尋找解決思路
2. 根據思路尋找開源支持
3. 若是找不到請參照第一條

開源世界已經有不少優秀的資源，不建議從頭開開始造輪子，除非你能很好的維護下去。基於現有的優秀工具、庫、平臺，針對自身產品的特色進行優化和二次開發更有利於工具自己的發展。

總結

測試是研發重要環節，前端自動化測試雖然還在不斷探索但已經有不少優秀的工具和庫。

合理利用工具、針對性選擇、減少使用和維護成本。

參考資料：

• http://rupl.github.io/frontend-testing/#/6/2
• http://www.phase2technology.com/blog/css-testing-with-phantomcss-phantomjs-casperjs-and-grunt/
• http://blog.nodejitsu.com/npmawesome-page-metrics-with-phantomas/
• http://fideloper.com/ubuntu-beanstalkd-and-laravel4
• http://www.yegor256.com/2014/10/05/ten-hosted-continuous-integration-services.html
• http://www.zhihu.com/question/19786019
• http://www.zhihu.com/question/29922082