‘壹’ 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的展现问题已经是不小的进步了。