Webkit Layout Test理论部分1 + 深入分析部分2– Layout Test :

转载 2013年12月04日 11:03:09

原文 :

http://blog.csdn.net/yajun0601/article/details/8887332

  当我开始做 WebKit 开发的时候,令我好奇的一件事儿就是这玩艺儿怎么测试。作为一个 Web 开发者,我清楚浏览器渲染引擎有多少 bug (尽管现在情况好了很多),以及日益复杂的web 页面给浏览器引擎带来多大的挑战。伴随bug 一起工作多年自然是要极力避免的事情,所以强制对规范的遵从和避免倒退就显得很关键。


        WebKit 的解决方案就是 layout tests。 从最简单层面来说,layout tests 就是提交到 WebKit 源码库中的一堆简单的网页(越简单越好)和期望的渲染结果文件( golden files),有文本也有图片。测试脚本( run-webkit-tests)使用一个内嵌了 WebKit 的应用(DumpRenderTree)遍历测试用例(现在有30000多了),然后对比这些测试用例的渲染结果和期望结果(golden files),最后将失败、崩溃、超时以及其他和期望不一致的结果生成报告。WebKit 项目中有让 layout test 在已经移植的所有平台上持续运行的编译机,这样就可以容易得发现那些有问题的改动(一旦发现就回滚)。


        鼓励开发者在提交代码前先运行 layout tests。最简单的方式是使用 commit queue,它会自动完成测试的执行。如果不这样,在工作站上运行全部测试用例也是可行的,目前运行一遍大约耗时15分钟,如果使用Dirk Pranke 的 multi-process test runner 时间可以缩短至约 4 分钟或者更少。
通过合理的使用测试数据,layout tests 可以被用来验证很多东西,从 JavaScript 引擎规范一致性到重绘以及 WebSocket 协议的实现。对于类似后者需要访问网络的情况,测试脚本会启动一个本地服务器(Apache, lighthttpd, 或者 WebSocket),然后从服务器上运行测试。本地 HTTP 服务器对模拟网络边界情况也是有用的;让我我觉得很可笑的是,在过去六个月的WebKit 工作中,我被迫学习和使用更多的PHP,比我过去六年做Web开发使用的还要多。


        对于比较简单的测试,他们更多采用了单元测试的形式(比如使用断言),有一个辅助的框架可以让这样的测试很容易的搭建起来。对应的期望结果文件里只是一条条的 "success" 描述。


         考虑到 layout test 不仅仅测试了渲染、布局,同时也包含了 JavaScript bindings的单元测试,网络堆栈的交互测试,数量级性能测试等等,大家也会偶尔讨论到"layout test" 这个名字越来越不精确。也正是由于这样的灵活性,layout test 模型在引入第三方测试套件的时候也有很好的表现。作为 layout test 的一部分,我们还运行了 Sputnik JavaScript 一致性套件,Philip Taylor 的 canvas 套件,以及 HTML5 解析套件,和更多其他浏览器厂商的测试用例。


        通常情况下,layout test 的执行伴随着所有的代码提交,特别是 fix bug 的代码(保证这个问题不再复现)。这就意味着解决 bug 的第一步是把导致问题出现的网页最简化。如果你提交了一个带有 NeedsReduction 标签的 bug,恰巧你又是触发 bug 网页的作者,那么你就比 WebKit 的开发人员更加适合来创建这个最简化的网页。因为如果一个问题可以归结为重复加载一个页面后查看 alert 或者这个神奇的单词“PASS”,那么调查起来就变得更加容易了。同时如果你提供了一个很好的简化后的测试用例,也意味着你的贡献将永垂不朽,因为这个测试用例每一天都会被运行几百遍。
        

        接下来的一篇会讨论 layout test 系统一些实际的东西,如果要了解更多,请移步 the WebKit wiki.


=============================================================================================

深入分析WebKit之Layout Tests

来自内部一个分享PPT整理过程的知识点,没有特别组织。

 

Layout Test主流程:


运行的指令:

  run-webkit-tests [选项] 测试脚本文件或所在的目录
    主要的参数有:

        --verbose  显示详细的信息

        --no-build  不要尝试重新编译dumprendertree

        --debug  使用Debug版本进行测试

        --help  显示所有选项信息


0. 测试方法的归纳

  i. 静态测试  (测试结果是通过比对最终网页输出来决定的。)

四种检测方法: 

Render tree, Body Text, Pixel Data, Ref Test

  (Body Text没有格式信息,而Pixel Data没有文本信息,所以两者是配合使用,以Body Text为主。)

Ref Test是以HTML页面的形式比对。不匹配的结果以图片形式存储。


  ii. 动态测试 (测试结果在执行过程中动态决定。但仍输出到网页,通过静态测试的方式报告出来。)

    动态测试的判断方法和静态测试相同。差异在于比对的内容已经是测试的结果。就是JavaScript脚已经根测试条件和数据,判断出测试成功或失败。然后静态测试的机制输出结果。     


测试用例的构成:

   a.测试用HTML文件  (必须在LayoutTests目录下)

{testname}.html

  b.基准文件 (Baseline)

. {testname}-expected.txt  -> Body Text

. {testname}-expected.png  -> Pixel Test

. {testname}-expected.html -> Ref Test 

. {testname}-expected-mismatch.html -> Ref Test

   c.说明

. missmatch类型的测试只有Ref Test支持

. Ref Test具有排它性,如果当前CaseRef Test, 不会再对其它内容检测。

 *关于Audio的比对,脚本里相关内容,但没有再分析。

 *第一次跑测试时,没有比较标准,LayoutTest会自动生成xxx-expected.txt 或xxxx-expected.png。

 *所有测试的网页必须放到LayoutTests目录下。


1. 不要在网页中输出日期或时间。

   (动态变化的内容是不可以拿来比对的)


2. 整个Test Case运行时间不能超过30s。详见另一篇文章


3. js-test-re.js (配合js-test-post.js使用) 中定义了若干结果确认的函数,如shouldBeTrue.

  如:

   <script src="../fast/js/resources/js-test-pre.js"></script>

   …

   <script>

     totalCount = 5;

     shouldBeTrue("totalCount == 3");

   </script>

   …

   <script src="../fast/js/resources/js-test-post.js"></script>


运行的结果:

  FAIL totalCount == 3 should be true. Was false.


 其它函数有:shouldBe,shouldBeCloseTo,shouldNotBe,shouldBeFalse,sholdBeNaN,shouldBeNull,shouldBeZero,

shouldBeEqualToString,shouldBeEmptyString,shouldBeDefined,shouldBeUndefined,shouldThrow…

详细地内容可以查看js-test-pre.js脚本。



4. LayoutTests/canvas/tests/23.canvas.reference.html

  ...

  <canvas id="c" class="output" width="100" height="50"><p class="fallback">FAIL (fallback content)</p></canvas>


   <ul id="d"></ul>

   <script>

    _addTest(function(canvas, ctx) {

          _assertSame(ctx.canvas, canvas, "ctx.canvas", "canvas");

         });

  </script>


_assertSame定义在LayoutTests/canvas/test.js中. 


所有canvas 2D测试使用同相同的id以方便测试脚本执行。


工作方式 (test.js中的实现):



 测试成功就在网页输出一个Pass, 否则输出错误信息。这样达到比对结果的目的。


另一个函数:_assertPixel  (2d.clearRect.nonfinite.html)

   _assertPixel(canvas, 50,25, 0,255,0,255, "50,25", "0,255,0,255");


 函数定义:

   _assertPixel(canvas, x,y, r,g,b,a, pos, colour)  

      pos和colors是代表坐标和颜色的两个字串。函数内没有使用。

        pos : "x,y"

        color: "r,g,b,a"


函数列表:

  _assert

  _assertSame   (===)

  _assertDifferent  (!==)

  _assertEqual  (==)

  _assertMatch (match) 正则表达式匹配

  _assertPixel  

  _assertPixelApprox  <-可以允许颜色有一点偏差


  _requireManualCheck 因为一些原因取不到数据,可能需要人工检查确认。



5.对于pixel test,除了dumpAsText()参数设为true, 在运行run-webkit-tests也要指定--pixel参数。 Expected的图像以PNG存储。PNG文件会被保存到对应的platform目录下。

  a. 抓下的图像仅限于可视区域。

  b. 因为字体渲染的原因,尽量不要涉及文本内容。

  c. 因为原生控件(native control)是由系统绘制,不同系统间有差异性。

  参考WebKit的这篇文章

   


6.  overridePreference (key, value)

  用于在脚本中动态修改Preference的值。可用的Keys:

      WebKitEnableCaretBrowsing

      WebKitUsePreHTML5ParserQuirks

 *更多的定义在WebPreferencesPrivate.h


7. Windows下使用LayoutTest的字体问题

  参考:http://trac.webkit.org/wiki/BuildingOnWindows (Font-metric-related failures)

 

8. 完整的testController方法列表:

  对照代码LayoutTestController.cpp中LayoutTestController::staticFunctions()的定义

9. 默认的网页视图大小 (DumpRenderTree)

    W3C SVG测试: 480x360

    其它测试:800x600

  *定义在LayoutTestController.cpp:2563 lines, 在函数sizeWebViewForCurrentTest中使用。

  都是常量定义,没有参数可以修改。


10. 自带DOM测试用例。使用selfhtml.js 和 同html同名的js文件。

  selfhtml.js 提供测试入口函数startTest和9个assert operation供使用: assertSize, assertEqualsCollectionAutoCase

  xxxx.js则提供runTest的实现供startTest调用。

  startTest执行:

      a. waitUntilDone

      b. runTest

      c. notifyDone


11. 黄金法则:

  a. 对于Pixel Test, 尽量不要涉及文本。

  b. 测试内容不要涉及动态内容,如时间、日期等。




【笔记】JunitTest的@Test注解的两个参数

博客中的部分字句引自慕课网的《JUnit-Java单元测试必备工具》公开课程。 是本人通过看教程视频后整理出来记录到博客上为日后需要时随时查阅用。 如有侵权,请联系本人删除该博客。  @Test...
  • ChyoGenntoo
  • ChyoGenntoo
  • 2015年05月28日 18:45
  • 1384

将数据划分为训练数据及测试数据(div_train_val.py 解析)

将LFW数据划分为face,non-face两个图像数据文件,在此基础上,提取训练数据及测试数据。 训练数据,在face文件中提取一部分,在non-face文件中提取一部分。 测试数据,在face...
  • u011070171
  • u011070171
  • 2016年06月01日 10:17
  • 941

go test命令参数问题

go test命令参数问题在使用go test对go代码进行单元测试的时候,遇到关于命令参数的问题,google了一下,没有找到很好的说明,其实就是一些细节而已。问题是这样的,在进行单元测试的时候,我...
  • kangaroo835127729
  • kangaroo835127729
  • 2016年03月18日 15:04
  • 3024

<Test> XiMaLaYa 新奇部分的添加

---------------------------------------之前的一些知识点:----------------------------------------------------...
  • Rodulf
  • Rodulf
  • 2016年01月25日 11:47
  • 445

基于datagrid框架的查询

然后是CenterPage.html框架中的代码,也就是tabs框架中的代码: 复制代码代码如下: //因为layout框架指向href时,只取html页面body中间的部...
  • wf4878921
  • wf4878921
  • 2014年05月26日 10:21
  • 566

将一个Activity分割成两部分,每个部分显示一个自定义View

最近刚开始学习Android开发,在练习写一个自定义View时
  • fnfuqqq
  • fnfuqqq
  • 2014年05月04日 15:39
  • 327

迁移到Thymeleaf3.x,布局方言2.x

环境: springboot1.5.4 win10 intellij IDEA2017.1 迁移到Thymeleaf3如果你的spring boot应用继承spring-boot-starter-pa...
  • qq_33589510
  • qq_33589510
  • 2017年07月09日 17:39
  • 1173

x2检验(chi-square test)或称卡方检验

x2检验(chi-square test)或称卡方检验 x2检验(chi-square test)或称卡方检验,是一种用途较广的假设检验方法。可以分为成组比较(不配对资料)和个别比较(配对,或同一对...
  • diemeng1119
  • diemeng1119
  • 2013年10月12日 16:35
  • 3554

关于.Net MVC 中_Layout.cshtml页面新布局的几点看法

作为一个刚刚开始学习Mvc的新人来说,从之前的winform页面到现在MVC的转变,感觉这是华丽丽的转身啊,再没有拖拽控件,转而是一种规范的格式,用Model-View-Controller三者把一个...
  • speedwade
  • speedwade
  • 2014年01月15日 17:23
  • 4439

springboot Test 自动配置注解详单

以下表格是各种@…Test注解,能够使用来测试你的应用 和它们被导入时的自动配置 测试的模块 导入的 auto-configuration ...
  • pml18710973036
  • pml18710973036
  • 2017年03月14日 11:25
  • 2145
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Webkit Layout Test理论部分1 + 深入分析部分2– Layout Test :
举报原因:
原因补充:

(最多只允许输入30个字)