随着互联网第二春的到来以及Web2.0的盛行，Web应用程序开发已经成为了当前软件开发的主力军。现在无论是企业级应用，社交应用还是移动应用，Web已经成为标准配置，而且很多企业正在逐步的将自己的企业级本地应用进行互联网Web化。但是Web 的界面布局测试，多浏览器测试，CSS/JavsScript的重构等都成为界面测试的痛中之痛，特别是大型Web应用的回归测试量太大，从而导致回归测试很多时候根本无法完成，所以很少会有团队能完成全方位的界面布局回归测试，特别是对于使用Agile流程开发的团队就更加困难。
而且现在大家对用户体验以及持续部署越来越重视，导致Web应用程序的界面开发和测试难上加难。
首先来看看Web 界面开发和测试为什么如此困难。
1，Web界面布局回归测试
对于Web网页界面布局测试一般都是由人工手动对比设计图和产品界面。而人工对比测试存在两个问题：a,速度慢；b,人的不确定性。对于拥有大量复杂界面的企业级Web应用，界面布局的回归测试的数量巨大，再加上这两个问题，导致这类应用的界面布局回归测试时间很长，成本很高，所以很多基于Agile项目基本不可能在迭代周期内高质量的完成其界面回归测试。对于每天做一次回归，那更是不可能完成的任务。
（下面有一个游戏“大家来找茬”，请读者用心找找有多少处不同，并记录一下用了多少时间。答案在附1图中）
图1，大家来找茬
2，CSS/JavaScript代码重构
现在Web前端越来越复杂，所以代码量也急速增加，导致前端开发像后端开发一样开始使用基于Library, Module和Pattern的开发方式。从而产生了一个问题：当有公共代码被修改和重构之后，如何快速发现界面的side effect？
由于CSS和控制界面的JavaScript代码被重构之后，只能通过人眼手动检测其正确性，导致开发和测试人员很难在有限的时间找到所有被修改的代码影响到的界面进行检查。最后很可能会有一些side effect在开发和测试阶段都不被发现而进入产品环境。
3，多浏览器
Web应用其最大的优势就是其可以跨平台跨浏览器，使用者可以在不同的操作系统中使用不同的浏览器访问并使用Web应用。但是这个优势也带来了很大的问题：需要做大量的浏览器兼容性测试。而被测浏览器的数量越多（现在的主流浏览器包括IE, Chrome, Firefox, Safari等，并且每种浏览器还有很多种版本），测试数量和时间也会成倍增长。这个痛也导致很多大型Web应用基本上很难在限定时间内完成大部分主流浏览器的兼容性测试。如果一定要做，那么也需要付出巨大的成本，比如添加更多的测试人员。