背景
測試是完善的研發體系中不可或缺的一環。前端同樣需要測試，你的css改動可能導致頁面錯位、js改動可能導致功能不正常。由於前端偏向GUI軟體的特殊性，儘管測試領域工具層出不窮，在前端的自動化測試上面卻實施並不廣泛，很多人依舊以手工測試為主。本文試圖探討前端自動化測試領域的工具和實踐。
為什麼需要自動化測試
一個專案最終會經過快速迭代走向以維護為主的狀態，在合理的時機以合理的方式引入自動化測試能有效減少人工維護成本。自動化測試的收益可以簡單總結為：
可測試方向
首先本文不會探討單元測試方向，因為單測已經有完善的工具體系。但前端開發中，除了一些框架和庫，願意去寫單測的少之又少。另外單測維護成本較高，而且也沒法滿足前端測試的所有需求。
前端自動化測試可以在幾個方向進行嘗試：
• 介面迴歸測試 測試介面是否正常，這是前端測試最基礎的環節
• 功能測試 測試功能操作是否正常，由於涉及互動，這部分測試比介面測試會更復雜
• 效能測試 頁面效能越來越受到關注，並且效能需要在開發過程中持續關注，否則很容易隨著業務迭代而下降。
• 頁面特徵檢測 有些動態區域無法通過介面對比進行測試、也沒有功能上的異常，但可能不符合需求。例如效能測試中移動端大圖素材檢測就是一種特徵檢測，另外常見的還有頁面區塊靜態資源是否符合預期等等。
業界開源工具
工欲善其事，必先利其器。業界在自動化測試領域已經有不少優秀的框架和庫，善於利用能事半功倍。
介面迴歸測試
介面迴歸測試常見的做法有畫素對比和dom結構對比兩個方向。
畫素對比
畫素對比基本的思想認為，如果網站沒有因為你的改動而介面錯亂，那麼在截圖上測試頁面應當跟正常頁面保持一致。可以跟線上正常頁面對比或者頁面歷史記錄對比。畫素對比能直觀的顯示影像上的差異，如果達到一定閾值則頁面可能不正常。
PhantomCSS
畫素對比比較出名的工具是PhantomCSS。 PhantomCSS結合了Casperjs截圖和ResembleJs影像對比分析。單純從易用性和對比效果來說還是不錯的。
由於PhantomJS 2.0暫時禁用了檔案上傳，PhantomCSS預設不支援PhantomJS 2.0 。如果還是想使用可以修改原始碼中獲取圖片檔案的方式，改為通過ajax獲取同域名下檔案的方式，具體可以參考ResembleJs官網示例。
如何測試多瀏覽器
如果想測試多瀏覽器下的相容性情況，只需要拿到多個瀏覽器下的截圖即可。多瀏覽器測試最出名的當屬selenium , selenium可以自動化的獲取多個瀏覽器下的截圖，前端工程師來說還可以藉助Node的webdriver 來輕鬆開發測試指令碼。
但selenium的安裝和上手成本要稍大些，而且對於多瀏覽器來說，各個瀏覽器之間的相容性對比容易出錯。不同瀏覽器截圖可能一畫素的偏差就導致截圖對比失敗，多瀏覽器可能更適用迴歸性測試。
響應式頁面測試
國外有人將畫素對比應用到了響應式頁面上，如果您針對PC和移動裝置使用同一個網頁，響應式測試可以很快的迴歸你的頁面在不同尺寸上的頁面是否正常。與單純針對移動端開發的響應式不同，同時支援PC移動的頁面更容易發生錯亂。
例如BackstopJS 專案，便是通過PhantomJS、capserJS等工具在不同尺寸下截圖然後根據resemberJS進行畫素比對判斷是否正常:
畫素對比需要注意的問題
• 不建議對網站所有頁面進行測試 這隻會導致很容易出現告警，但不一定是錯誤。針對重複使用的元件和樣式、容易出問題的區域測試更加有效
• 推薦測試區域而不是整個頁面 整個頁面的測試導致任何一點文字、影像等動態的改變都可能導致不通過，而且真正的錯誤可能由於影像太大而被閾值忽略。影像越大對比也越容易超時。
• 隱藏動態區域 在選擇器對應的區域如果有動態元素，可以同樣通過選擇器來隱藏
• 介面對比只是一個環節，需與其他測試相結合 沒有銀彈，合理結合才是關鍵dom結構對比
畫素對比雖然直觀，但動態元素居多且無法保證測試頁面與線上頁面同步時有所侷限。@雲龍大牛針對這個問題提供了新的解決方案page-monitor，根據dom結構與樣式的對比來對比整個頁面的變動部分。 使用效果示例：
畫素對比和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可以輕鬆實現貼吧的自動發帖功能：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
casper.test.begin('測試發帖功能',functionsuite(test) { //登入百度 casper.loginBaidu();//實現略，可以通過cookie或者表單登入實現 casper.thenOpen('http://tieba.baidu.com/p/3817915520',function() { vartext ="樓主好人"; //等待發帖框出現 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能監聽測試和頁面的各個狀態進行截圖等操作，如果針對測試執行結果稍作優化，便可以形成一個視覺化操作流：
不想維護case?
除非有足夠的QA同學來幫你完成測試工作，否則通過人工來回歸肯定會消耗更多的精力。在專案功能基本穩定期，維護case會簡單的多，而且同樣建議針對網站核心功能而不是所有功能來新增case。
瀏覽器相容測試
當然selenium同樣支援操作測試，類似的工具還有dalekjs等，如果想專門針對IE測試，可以考慮[triflejs]http://triflejs.org/,它提供了與PhantomJS基本類似的API。
PhantomFlow操作對比測試
有沒有像影像對比一樣直觀，又能比較簡單的寫case的工具呢？可以考慮PhantomFlow, PhantomFlow假定如果頁面正常，那麼在相同的操作下，測試頁面與正常頁面的展現應該是一樣的。 基於這點，使用者只需要定義一系列操作流程和決策分支，然後利用PhantomCSS進行截圖和影像對比。最後在一個很讚的視覺化報表中展現出來。可以看下作者所在公司進行的測試視覺化圖表：
完整內容點此檢視
測試是完善的研發體系中不可或缺的一環。前端同樣需要測試，你的css改動可能導致頁面錯位、js改動可能導致功能不正常。由於前端偏向GUI軟體的特殊性，儘管測試領域工具層出不窮，在前端的自動化測試上面卻實施並不廣泛，很多人依舊以手工測試為主。本文試圖探討前端自動化測試領域的工具和實踐。
為什麼需要自動化測試
一個專案最終會經過快速迭代走向以維護為主的狀態，在合理的時機以合理的方式引入自動化測試能有效減少人工維護成本。自動化測試的收益可以簡單總結為：
自動化的收益 = 迭代次數 * 全手動執行成本 - 首次自動化成本 - 維護次數 * 維護成本
對於自動化測試來說，相對於發現未知的問題，更傾向於避免可能的問題。可測試方向
首先本文不會探討單元測試方向，因為單測已經有完善的工具體系。但前端開發中，除了一些框架和庫，願意去寫單測的少之又少。另外單測維護成本較高，而且也沒法滿足前端測試的所有需求。
前端自動化測試可以在幾個方向進行嘗試：
• 介面迴歸測試 測試介面是否正常，這是前端測試最基礎的環節
• 功能測試 測試功能操作是否正常，由於涉及互動，這部分測試比介面測試會更復雜
• 效能測試 頁面效能越來越受到關注，並且效能需要在開發過程中持續關注，否則很容易隨著業務迭代而下降。
• 頁面特徵檢測 有些動態區域無法通過介面對比進行測試、也沒有功能上的異常，但可能不符合需求。例如效能測試中移動端大圖素材檢測就是一種特徵檢測，另外常見的還有頁面區塊靜態資源是否符合預期等等。
業界開源工具
工欲善其事，必先利其器。業界在自動化測試領域已經有不少優秀的框架和庫，善於利用能事半功倍。
介面迴歸測試
介面迴歸測試常見的做法有畫素對比和dom結構對比兩個方向。
畫素對比
畫素對比基本的思想認為，如果網站沒有因為你的改動而介面錯亂，那麼在截圖上測試頁面應當跟正常頁面保持一致。可以跟線上正常頁面對比或者頁面歷史記錄對比。畫素對比能直觀的顯示影像上的差異，如果達到一定閾值則頁面可能不正常。
PhantomCSS
畫素對比比較出名的工具是PhantomCSS。 PhantomCSS結合了Casperjs截圖和ResembleJs影像對比分析。單純從易用性和對比效果來說還是不錯的。
由於PhantomJS 2.0暫時禁用了檔案上傳，PhantomCSS預設不支援PhantomJS 2.0 。如果還是想使用可以修改原始碼中獲取圖片檔案的方式，改為通過ajax獲取同域名下檔案的方式，具體可以參考ResembleJs官網示例。
如何測試多瀏覽器
如果想測試多瀏覽器下的相容性情況，只需要拿到多個瀏覽器下的截圖即可。多瀏覽器測試最出名的當屬selenium , selenium可以自動化的獲取多個瀏覽器下的截圖，前端工程師來說還可以藉助Node的webdriver 來輕鬆開發測試指令碼。
但selenium的安裝和上手成本要稍大些，而且對於多瀏覽器來說，各個瀏覽器之間的相容性對比容易出錯。不同瀏覽器截圖可能一畫素的偏差就導致截圖對比失敗，多瀏覽器可能更適用迴歸性測試。
響應式頁面測試
國外有人將畫素對比應用到了響應式頁面上，如果您針對PC和移動裝置使用同一個網頁，響應式測試可以很快的迴歸你的頁面在不同尺寸上的頁面是否正常。與單純針對移動端開發的響應式不同，同時支援PC移動的頁面更容易發生錯亂。
例如BackstopJS 專案，便是通過PhantomJS、capserJS等工具在不同尺寸下截圖然後根據resemberJS進行畫素比對判斷是否正常:
畫素對比需要注意的問題
• 不建議對網站所有頁面進行測試 這隻會導致很容易出現告警，但不一定是錯誤。針對重複使用的元件和樣式、容易出問題的區域測試更加有效
• 推薦測試區域而不是整個頁面 整個頁面的測試導致任何一點文字、影像等動態的改變都可能導致不通過，而且真正的錯誤可能由於影像太大而被閾值忽略。影像越大對比也越容易超時。
• 隱藏動態區域 在選擇器對應的區域如果有動態元素，可以同樣通過選擇器來隱藏
• 介面對比只是一個環節，需與其他測試相結合 沒有銀彈，合理結合才是關鍵dom結構對比
畫素對比雖然直觀，但動態元素居多且無法保證測試頁面與線上頁面同步時有所侷限。@雲龍大牛針對這個問題提供了新的解決方案page-monitor，根據dom結構與樣式的對比來對比整個頁面的變動部分。 使用效果示例：
畫素對比和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可以輕鬆實現貼吧的自動發帖功能：
?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
casper.test.begin('測試發帖功能',functionsuite(test) { //登入百度 casper.loginBaidu();//實現略，可以通過cookie或者表單登入實現 casper.thenOpen('http://tieba.baidu.com/p/3817915520',function() { vartext ="樓主好人"; //等待發帖框出現 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能監聽測試和頁面的各個狀態進行截圖等操作，如果針對測試執行結果稍作優化，便可以形成一個視覺化操作流：
不想維護case?
除非有足夠的QA同學來幫你完成測試工作，否則通過人工來回歸肯定會消耗更多的精力。在專案功能基本穩定期，維護case會簡單的多，而且同樣建議針對網站核心功能而不是所有功能來新增case。
瀏覽器相容測試
當然selenium同樣支援操作測試，類似的工具還有dalekjs等，如果想專門針對IE測試，可以考慮[triflejs]http://triflejs.org/,它提供了與PhantomJS基本類似的API。
PhantomFlow操作對比測試
有沒有像影像對比一樣直觀，又能比較簡單的寫case的工具呢？可以考慮PhantomFlow, PhantomFlow假定如果頁面正常，那麼在相同的操作下，測試頁面與正常頁面的展現應該是一樣的。 基於這點，使用者只需要定義一系列操作流程和決策分支，然後利用PhantomCSS進行截圖和影像對比。最後在一個很讚的視覺化報表中展現出來。可以看下作者所在公司進行的測試視覺化圖表：
完整內容點此檢視