测试页面样式时遇到的问题
  在我们测试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修改你同时需要修改测试。同样地,如果你断言某个元素是否拥有某种样式,终的页面显示难以预见。
  依赖感觉的测试是不严谨的
  无论是谁来做页面样式的测试,都是基于看和感觉的,这种测试不能有效的发现细节问题,不能得出严谨的结果,每个测试者都会有自己的答案。虽然说眼见为实,但有时候看到了也不可信赖。例子中的两个对比图片,肉测很难发现细小的差异。