『壹』 web前端的自動化測試工具都有哪些啊
工具太多了，推薦幾個
Selenium
HP QuickTest Professional
WATIR
WATIN
還有其他的供選
Rational robot
SilkTest
TestComplete
TestPartner
『貳』 最好的web前端自動化測試框架是哪個為什麼
測試框架大同小異，主體思路大致都是「控制項-頁面-測試用例」三個層面。
當前主流的「控制項-頁面-測試用例」框架。
『叄』 前端自動化工具有哪些
隨著前端開發技術的不斷發展，前端開發工作也變得越來越復雜，如果能合理地採用一些自動化的工具，生活要容易得多。
LiveReload
我目前的開發主力機是一台較早的 13寸 Macbook Pro，外加一台戴爾的顯示器。相信做前端開發的都知道，這多出來的一台顯示器對工作效率的提升有多大。
LiveReload 技術+兩塊顯示屏可以幫你省去重復刷新瀏覽器這一枯燥的工作。目前實現 LiveReload 的方式很多，如果你傾向於圖形化的桌面應用，可以嘗試一下 LiveReload.app, 地址是：https://github.com/livereload/LiveReload， 這款應用同時有 Mac 版和 Windows 版，使用起來也很簡單，通過圖形界面設置好需要監聽文件所在的文件夾，然後將一段腳本插入到 HTML 頁面即可。
現在做前端開發，通常還會涉及到預處理器，雖然技術的多樣化給我們帶來了更多選擇，但要這些技術產生的代碼在瀏覽器中獲得一致的表現，還得將其轉化為瀏覽器支持的類型。
Webpack 是一款模塊載入兼打包工具，豐富的插件讓這款工具非常實用。雖然現在 Grunt 和 Gulp 作為兩款前端自動化工具非常流行，但其實 Webpack結合Npm腳本在大多數場合就已經足夠了。
django-webpack-loader
如果你在使用 Django ，django-webpack-loader是一款你不可錯過的 Webpack 插件。
我們都知道瀏覽器緩存對頁面載入速度的重要性， 同時我們也希望當資源文件發生變化時，頁面能立刻向用戶呈現變化。
通常的做法是將資源文件的 hash 值作為資源地址的一部分，比如main-cf4b5fab6e00a404e0c7.js， Webpack雖然支持這種命名方式，在配置文件中按如下方式設置即可。
其他推薦
WeFlow
CodeKit
『肆』 為什麼要構建前端自動化工作流
為了避免開發過程中有大量重復性工作
『伍』 前端自動化一般用什麼工具
前端工作其實有很多零零星星的小地方都是可以通過工具協助進行開發的。
基本文件伺服器和代理
可共用化代碼片段
源文件修改，網頁自動刷新
css，js部署前的合並和壓縮
圖片的合並和壓縮
自動化部署（FTP、SCP等）
js、css代碼質量檢測
單元測試
less、sass動態編譯
ES6 2 ES5動態編譯等等。
『陸』 Canvas開發的前端頁面自動化實現求助
現在的前端開發已經不再僅僅只是靜態網頁的開發了，日新月異的前端技術已經讓前端代碼的邏輯和交互效果越來越復雜，更加的不易於管理，模塊化開發和預處理框架把項目分成若干個小模塊，增加了最後發布的困難，沒有一個統一的標准，讓前端的項目結構千奇百怪。前端自動化構建在整個項目開發中越來越重要。
我們首先來回想一下之前我們是如何來開始做一個項目的。
① 首先要確定這個項目要使用什麼樣的技術來實現，然後開始規劃我們的項目目錄，接著就要往項目增加第三方庫依賴，比如：
拷貝 CSS庫（Yui Reset | bootstrap）JS庫（Requiet.js | Seajs | jQuery | jQuery插件 ） 進相應目錄（拷貝 N個文件，花費N分鍾）
② 然後，進行編碼
編輯器編碼 => 切換到瀏覽器F5 => 編輯器編碼 => 切換到瀏覽器F5 => 編輯器編碼 => 切換到瀏覽器F5 => 編輯器編碼 => 切換到瀏覽器F5 …………
③ 編碼完成，進行語法檢查，文件合並和壓縮
HTML去掉注析、換行符 - HtmlMin
CSS文件壓縮合並 – CssMinify
JS代碼風格檢查 – JsHint
JS代碼壓縮 – Uglyfy
image壓縮 - imagemin
整個過程都在重復無用繁瑣的工具...
漸漸的，一些自動化構建工具出現了，人們開始使用例如Bower、Gulp、Grunt、node、yeoman等等工具來構建一個本地的開發環境。自動化構建已經成了前端開發的趨勢，所以學好自動化構建也就是為自己的開發打下了良好的基礎。
『柒』 前端自動化構建工具 對於工程有什麼好處
簡化優化，方便管理擴展，移植。
『捌』 如何構建自動化的前端開發流程
自動當然是相對於手動而言的。
手動：
自己放置並引用JS庫和CSS框架
自己處理各個模塊的添加/刪除/依賴關系
自己壓縮合並JS和CSS
自己構建測試環境
自己FTP傳到網站上部署
自己備份各個版本的差異
總之就是什麼都自己來
自動：幾條命令電腦做。
如果沒有手動開發一個完整前端項目的經歷，請先至少手動來一遍。其一是體驗下有多麻煩，其二是不熟悉操作背後的本質，也用不好自動化工具。然後再學開發流程自動化就明白了。
『玖』 對於前端自動化構建工具有了解嗎
gulpjs是一個前端構建工具，與gruntjs相比，gulpjs無需寫一大堆繁雜的配置參數，API也非常簡單，學習起來很容易，而且gulpjs使用的是nodejs中stream來讀取和操作數據，其速度更快。如果你還沒有使用過前端構建工具，或者覺得gruntjs太難用的話，那就嘗試一下gulp吧。
『拾』 如何進行前端自動化測試
沒人邀請，路過回答。
前端測試是前端工程方面的重要分支，有過一些探索，這里簡單分享一下。
首先，還是要強調一點：
前端是一種特殊的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演算法示意圖）
（react的dom樹diff演算法示意圖）（react的dom樹diff演算法示意圖）
DOM樹diff我們可以分辨出元素樣式修改/內容修改/新增元素/刪除元素四種不同的頁面差異，我們可以配置選擇器來忽略元素。四種頁面差異的效果圖：
新增元素（綠色區域標記部分，「i am new here」）新增元素（綠色區域標記部分，「i am new here」）
刪除元素（灰色區域標記部分，「你好」）刪除元素（灰色區域標記部分，「你好」）
內容修改（黃色區域標記部分，「百-度」，「新-浪」）內容修改（黃色區域標記部分，「百-度」，「新-浪」）
樣式修改（紅色區域標記的部分）樣式修改（紅色區域標記的部分）
基於這樣的頁面差異對比監控，我們可以建立一個任務系統，把應用的所有頁面url監控起來，這樣每次版本迭代提交代碼後，系統就能自動告訴我們，哪些頁面的元素展現發生了改變，用於確定回歸范圍。
用監控的方式確定測試回歸范圍，是一種「少吃屎」的手段，符合工程化要求，能比較大范圍的應用，雖然不能完美解決GUI中的交互問題，但能保證GUI的展現問題已經是不小的進步了。