测试页面样式时遇到的问题
在我们测试Web页面的时候，往往需要面对如下几个问题
手工测试多个浏览器
跨浏览器测试，测试页面在多个浏览器中的表现，浏览器可能包括Chrome，Firefox，Safari，IE和Opera。除了测试基本功能是否健全以外，还需要测试外观样式，因为当前的CSS技术在各个浏览器里的表现不完全一致。比如会看看IE和其他现代浏览器的差距有多大，从而判定之间的差别是否能被接受。
除了测试多个浏览器之外，很可能需要进行多版本的测试，现在浏览器的更新速度是非常快的，这样就导致了用户群在浏览器版本之间的跨度变大，为了保证质量，多个版本的测试也是必要的。比如IE6到IE10的测试。
其次，随着Mobile Webapp的发展，响应式设计的广泛应用，页面的测试还需要照顾到移动设备和多尺寸屏幕。
可以看出，页面样式的测试情况是十分复杂的，更甚的是，我们现在都是用手工在测试，耽误很多时间。
可复用的样式代码容易影响现有样式
复用的影响？
我们推荐在开发样式的时候使用SASS或LESS的CSS预编译语言，这样可以更好的管理CSS代码，但是也会导致一个问题，一个可复用的样式的修改可能会影响很多个页面，比如一个颜色变量的改变。而我们往往是让页面引入所有样式，很难判断哪些页面会有影响。可能一个能力很强的QA能预见到一些并做了测试，可能有些影响到了回归测试的时候才发现，也可能到了生产环境上也没有发现。
现有CSS测试的问题
样式不是不可以“测试”的，项目中可能会使用
expect($('#my-target')).toHaveCss({margin: '10px'}); expect($('#my-target')).toHaveClass('box'); |
的方式去测试某个元素是否含有某种特定的属性并断言值是多少，但是每个元素在页面上的样式是由它的Computed Style决定的，这些属性是非常多的，几乎做不到通过这些属性值来表达某个元素是否显示得正确，而且这样代码维护成本是非常大的，频繁的UI修改你同时需要修改测试。同样地，如果你断言某个元素是否拥有某种样式，最终的页面显示难以预见。
依赖感觉的测试是不严谨的
无论是谁来做页面样式的测试，都是基于看和感觉的，这种测试不能有效的发现细节问题，不能得出严谨的结果，每个测试者都会有自己的答案。虽然说眼见为实，但有时候看到了也不可信赖。例子中的两个对比图片，肉测很难发现细小的差异。
