WebKit自动化回归测试之LayoutTest实践 (超时问题的处理)

灰太狼 2022-06-10 04:37 140阅读 0赞

转载请注明出处:http://blog.csdn.net/horkychen

![1340981617_3580.jpg][]

WebKit的回归测试是由一组脚本构成的Layout Tests，测试内容是测试的网页和标准结果(Baseline)。其测试脚本执行的基本方式示意如下:

![1340981639_5907.png][]

* \*脚本会启动http服务器以支持网页加载,在此不做描述。*

而每个网页里面都含有测试用的JavaScript脚本, 主要因为有一些DOM对象被动态注入了供JavaScript脚本使用。*(关于如何添加这个DOM对象，可以参考[这篇文章][Link 1]的第二种情况。代码在WebCoreTestSupport.cpp::injectInternalsObject())* 。这些对象中就是testRunner、eventSender、GCController、textInputController、internals。它们的功能是和DumpRenderTree交互。可以交互的内容列在这里了:

[ Write Layout Tests for DumpRenderTree][Write Layout Tests for DumpRenderTree]

测试脚本其实就是JavaScript脚本加上这些新对象。需要注意在使用这些对象前最好检查一下，保持一个兼容性，如官网给的例子:

if (window.testRunner)

testRunner.dumpAsText(true);

……

使用WebKit提供的脚本就可以开始测试了: (以下是在WebKit目录下执行)

Tools/Scripts/run-webkit-tests --verbose --debug \[目标目录\]

*\**更多选项，使用*Tools/Scripts/run-webkit-tests --help*可以看到。

下面讲一个实作，中间要解决一个关于时间控制的问题。

先架环境，下载了Webkit后，还需要从Webkit的代码库中导出LayoutTest。在WebKit目录执行:

*svn export **http://svn.webkit.org/repository/webkit/trunk/LayoutTests/ LayoutTests*

等吧！有1.5G之大，我可是下了两天。

说明一下测试目标。测试一下JS Engine对时间控制的准确性。写了一段JS脚本，会每隔两秒输出当前时间及与上次的时间差。所以Document加载完成后，脚本还需要运行一段时间。好在testRunner提供waitUntilDone和notifyDone可以使用。waitUntilDone表示测试程序要等待脚本发送notifyDone才表示测试用例执行结束，然后才能收集结果。否则DumpRenderTree当网页加载完成后，就后直接Dump，然后走人，而这个时候，这个测试脚本还什么都没发生呢。

测试的网页如下:

<html>
    <head>
    
    </head>
    
    <body>
    
        <div id="dd"></div>
    
    
        <script>
        if (window.testRunner)
        {
        testRunner.dumpAsText(true);
        }
        
    totalCount = 20;
            text = "";
            nOld= -1;
            var handle;
    
            function repaint()
            {
                var now = new Date();
                
                 str = "<b>" + now + "</b>####" ;
                
                if(-1==nOld)
                {
                nOld=now.getTime();
                str+= "  <span style=\"color:#0000FF;\"]] > Begin</span><div />"
                }
                else
                {
                nDiff = now.getTime()-nOld;
                if(  Math.abs(nDiff-2000) >=5 )
                {
                str+= "<span style=\"color:#FF0000;\"]]
    >
    NG ("+nDiff+")</span><div />"
                }
                else
                {
                  str+= "<span style=\"color:#0000FF;\"]] > OK</span><div />"
                }
                nOld=now.getTime();
                }
                
                text = str + text;
                document.getElementById('dd').innerHTML = text;
                
                totalCount--;
                
                if( 0 == totalCount )
                {
                	clearInterval(handle);
                	if (window.testRunner) 
                	{
        			testRunner.notifyDone();
        	     	}
                }
            }   
    
            handle = setInterval(repaint, 2000);
            
            if (window.testRunner)
            {
            testRunner.waitUntilDone(); //Ask testRunner to wait the script done.
            }
    
        </script>
    
    </body>
    
    </html>

然后把脚本放到LayoutTests目录下:

![1340981710_9301.png][]

执行Tools/Scripts/run-webkit-tests脚本，指定运行脚本的目录就可以了。不幸的是出错了。

![1340981731_4743.png][]

看到是Time-Out的问题(脚本执行时加上*--verbose*可以看到更多的细节),前面的测试脚本会运行至少20\*2s, 也就是至少需要40秒的时间。而*run-webkit-tests*默认的时间为35s (执行时脚本也有输出)，所以超时了。喜欢探究一下的，可以看看*Scripts/webkitpy/layout\_tests/controllers/manager.py*。

run-webkit-tests提供了一个参数可以指定自己的TimeOut设定。

*--time-out-ms=TIME\_OUT\_MS*  (针对所有测试用例)

将Time-Out时间设为70秒再试一次：

*Tools/Scripts/run-webkit-tests --verbose --debug --no-build --no-retry --time-out-ms=70000 xxxxx*

结果仍然出错了。真正的问题来了。

![1340981754_9467.png][]

这里关于分析过程省略500字……

最终发现, DumpRenderTree还有一个对于*waitUntilDone/notifyDone*的限定。默认在收到*waitUntilDone*后，超过30秒没有接到*notifyDone*，就算超时。相关代码都在DumpRenderTree工程中：

Mac OS        LayoutTestControllerMac.mm  ->waitToDumpWatchdogInterval赋值

Windows       TestShell.cpp -> 建构函数

所以这里有两个Time-Out时间，一个是控制每个测试用例的运行时间，另一个是*waitUntilDone*等多久的时间。示意如下:

![1340981779_1982.png][]

两个一组合，这个测试还是没过。而且后者在Mac OS的实现(Windows有入口可以改掉)是Hard Code没办法通过参数设置。我们只能强行改掉它了，关于这个问题我正在联系WebKit确认准备提交个Bug。

注意，改完后，要使用Tools/Scripts/build-dumprendertree来重新编译。在run-webkit-tests加*--build*帮不上你的。

然后再执行一次上面的脚本，就可以看到正常的结果了。测试的结果会被存储在与DumpRenderTree同级目录下:

![1340981896_8119.png][]

> *\*xxx-actual.txt -> 为实际dump出来的结果*
> 
> *\*xxx-diff.txt ->差异比对结果*
> 
> *\*xxx-expected.txt -> 标准输出*
> 
> *\*xxx-stderr.txt -> 运行过程中的错误信息输出*  
>

另一种方案，修改layouttest脚本给DumpRenderTree加个\--no-timeout使得每个Case几乎不用考虑超时的问题。这样做，风险就太高了，很可能卡死在某个测试用例。

补一张测试执行的示意图 (英文比较直接一点):  
 ![1341361292_8044.png][]

Reference:

[http://www.webkit.org/blog/1456/layout-tests-practice/][http_www.webkit.org_blog_1456_layout-tests-practice]

[http://trac.webkit.org/wiki/Writing%20Reftests][http_trac.webkit.org_wiki_Writing_20Reftests]

[1340981617_3580.jpg]: https://img-my.csdn.net/uploads/201206/29/1340981617_3580.jpg
[1340981639_5907.png]: https://img-my.csdn.net/uploads/201206/29/1340981639_5907.png
[Link 1]: http://blog.csdn.net/horkychen/article/details/7640052
[Write Layout Tests for DumpRenderTree]: http://trac.webkit.org/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree#window.testRunner
[1340981710_9301.png]: https://img-my.csdn.net/uploads/201206/29/1340981710_9301.png
[1340981731_4743.png]: https://img-my.csdn.net/uploads/201206/29/1340981731_4743.png
[1340981754_9467.png]: https://img-my.csdn.net/uploads/201206/29/1340981754_9467.png
[1340981779_1982.png]: https://img-my.csdn.net/uploads/201206/29/1340981779_1982.png
[1340981896_8119.png]: https://img-my.csdn.net/uploads/201206/29/1340981896_8119.png
[1341361292_8044.png]: https://img-my.csdn.net/uploads/201207/04/1341361292_8044.png
[http_www.webkit.org_blog_1456_layout-tests-practice]: http://www.webkit.org/blog/1456/layout-tests-practice/
[http_trac.webkit.org_wiki_Writing_20Reftests]: http://trac.webkit.org/wiki/Writing%20Reftests