如何进行前端自动化测试？

[fouber]

此文章转自我在 知乎 上的同名问答

前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。

首先，还是要强调一点：

前端是一种特殊的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的展现问题已经是不小的进步了。

=====[ 补充 ]=====
经评论中 @貘吃馍香 大大的提醒，这里强调一下：

页面差异监控的目的是方便的通知人肉回归范围，这并非测试方案，而是一种辅助测试的手段。

[kuitos]

spa系统及交互中间页面(如弹出框)是否能够diff？

[fouber]

@kuitos 可以

[whatthecole]

fis-java-jsp 貌似很久没更新了 还适用fis3吗

[codering]

@whatthecole https://github.com/fex-team/fis3-jello

[whatthecole]

@codering 这个方案一定要jsp+velocity吗

[codering]

@whatthecole 可以只用jsp 或只用velocity 或两者混合也行。如果要用其他后端模版，就得自己去按jello 的思路写一套。

[Cuiyansong]

@fouber 我还以为标题讲的内容是前端自动化测试/BDD测试，这部分内容是否会加入，期待～

[huanggm]

@fouber
不知道这个问题在这里提问是否合适。。。
问题是关于后端模版怎样做mock假数据测试？

如果是前端模版，直接使用ajax拉取假数据，然后用js渲染模版就行了。
但如果是后端模版，这个流程好像就行不通了，不知道有什么解决方案？

谢啦！

[holyzfy]

@huanggm 在前端搭一个web服务器（静态资源服务+渲染vm），约定vm同目录下同名的js文件作为假数据，例如 https://github.com/holyzfy/velocityServer

[nimoc]

@huanggm
提供一个已成型方案，有文档有示例。已在我所在团队实践一年多。

文档：http://fmsjs.org/

前端基于 FMS 可以独立完成Web数据模拟(AJAX、后端模板引擎渲染页面)。

示例项目：http://demo.fmsjs.org/
示例项目代码: https://github.com/nimojs/fms-demo

[abell123456]

这个太赞了！👍🏻

发自我的 iPhone

在 2016年1月7日，下午4:52，倉優小子 notifications@github.com 写道：

@huanggm 在前端搭一个web服务器（静态资源服务+渲染vm），约定vm同目录下同名的js文件作为假数据，例如 https://github.com/holyzfy/velocityServer

—
Reply to this email directly or view it on GitHub.

[zhangqiusheng]

这个很赞

[JennyHui]

只支持web? Android ios 还不支持是乎?

[wujunze]

👍

[mygaochunming]

@fouber 大神，请教个问题。

在开发项目的时候，页面的优化、bug一般会通过“gitlab/issue”管理。所以测试人员会根据issue一个一个测试并关闭问题。用你的话就是“屎”吃的有条不紊。我觉得在页面的测试方面不会有什么问题。

反而业务逻辑的变化是个不确定的因素，容易产生非预期的效果。请教下，有什么工具能将业务逻辑编写成脚本，然后进行自动化测试？

另，你上面的工具是否已开源？

[kuse95]

@mygaochunming karma + jasmine 还有淘宝有个神器叫f2etest你可以看看

[mygaochunming]

@1483799920 谢谢！

[aleen42]

对于浏览器之间的差异性比较，是否有更好的办法？计算 Virtual DOM 貌似不是一个好的选择

[Yan2603]

@nimojs 你的链接被劫持了

[xcyn]

@huanggm
提供一个已成型方案，有文档有示例。已在我所在团队实践一年多。

文档：http://fmsjs.org/

前端基于 FMS 可以独立完成Web数据模拟(AJAX、后端模板引擎渲染页面)。

示例项目：http://demo.fmsjs.org/
示例项目代码: https://github.com/nimojs/fms-demo

看不了