CTS问题指南

1.简介

CTS为google为了android手机可以表现良好而推出的兼容性测试包。针对每个不同的系统版本，都有不止一个的CTS包以供测试。
具体的CTS代码可以通过下载下来的android代码目录里的./cts目录进行查看，必要时需要切换具体tag进行查看不同版本.

本文档主要会介绍CTS的几种fail场景，并且结合之前问题进行分析以及提供可用方法。

2.CTS错误形式

1. assert fail

这个问题现象就很简单了，junit的assert所指示的变量失败，从而查看该变量或者方法是如何所得的即可。
有偶现与必现两种：

1.必现情况：

必现情况比较好解决。由于一直可以复现，添加log和跟踪代码即可。一般来说必现CTS fail较少，因为android对应相对版本的CTS都在google内部测试很多次，所以必现问题一般与展讯自身或者android版本之类的有关。

2.偶现情况：

偶现情况就比较复杂了。由于CTS的每一个方法都非常独立，一般偶现情况会由网络情况，前一个case影响，以及本case的代码执行时序问题所导致。
这一系列的问题都没有什么好的参照，也比较难以分析。可能是最难的CTS问题。

勉强举一个例子：

android.webkit.cts.WebViewSslTest -- testClearSslPreferences -- failed

1224901 01-01 18:47:46.019 5420 6160 I TestRunner: 1224902 01-01 18:47:46.019 5420 6160 I TestRunner: 1224903 01-01 18:47:46.019 5420 6160 I TestRunner: 1224904 01-01 18:47:46.019 5420 6160 I TestRunner: 1224905 01-01 18:47:46.019 5420 6160 I TestRunner: 1224906 01-01 18:47:46.019 5420 6160 I TestRunner: 1224907 01-01 18:47:46.019 5420 6160 I TestRunner: 1224908 01-01 18:47:46.019 5420 6160 I TestRunner: 1224909 01-01 18:47:46.019 5420 6160 I TestRunner: 1224910 01-01 18:47:46.019 5420 6160 I TestRunner: 1224911 01-01 18:47:46.019 5420 6160 I TestRunner: 1224912 01-01 18:47:46.019 5420 6160 I TestRunner: 1224913 01-01 18:47:46.019 5420 6160 I TestRunner: 1224914 01-01 18:47:46.019 5420 6160 I TestRunner: 1224915 01-01 18:47:46.019 5420 6160 I TestRunner: 1224916 01-01 18:47:46.019 5420 6160 I TestRunner: 1224917 01-01 18:47:46.019 5420 6160 I TestRunner: 1224918 01-01 18:47:46.019 5420 6160 I TestRunner: 1224919 01-01 18:47:46.019 5420 6160 I TestRunner: 1224920 01-01 18:47:46.019 5420 6160 I TestRunner: failed: testClearSslPreferences(android.webkit.cts.WebViewSslTest)
----- begin exception -----
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:48)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at android.webkit.cts.WebViewSslTest.testClearSslPreferences(WebViewSslTest.java:567 )
at java.lang.reflect.Method.invoke(Native Method)
at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:214)
at android.test.InstrumentationTestCase.-wrap0(InstrumentationTestCase.java)
at android.test.InstrumentationTestCase$2.run(InstrumentationTestCase.java:189)
at android.app.Instrumentation$SyncRunnable.run(Instrumentation.java:1897)
at android.os.Handler.handleCallback(Handler.java:739)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5435)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:762)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:652)
----- end exception -----

error的result已经明确指明错误点为android.webkit.cts.WebViewSslTest.testClearSslPreferences(WebViewSslTest.java:567)
这行的assert fail

从cts case代码看到

547    @UiThreadTest
548    public void testClearSslPreferences() throws Throwable {
549        if (!NullWebViewUtils.isWebViewAvailable()) {
550            return;
551        }
552        // Load the first page. We expect a call to
553        // WebViewClient.onReceivedSslError().
554        final SslErrorWebViewClient webViewClient = new SslErrorWebViewClient(mOnUiThread);
555        startWebServer(true);
556        final String url = mWebServer.getAssetUrl(TestHtmlConstants.HELLO_WORLD_URL);
557        mOnUiThread.setWebViewClient(webViewClient);
558        mOnUiThread.clearSslPreferences();
559        mOnUiThread.loadUrlAndWaitForCompletion(url);
560        assertTrue(webViewClient.wasOnReceivedSslErrorCalled());
561
562        // Load the page again. We expect another call to
563        // WebViewClient.onReceivedSslError() since we cleared sslpreferences.
564        mOnUiThread.clearSslPreferences();
565        webViewClient.resetWasOnReceivedSslErrorCalled();
566        mOnUiThread.loadUrlAndWaitForCompletion(url);
567        assertTrue(webViewClient.wasOnReceivedSslErrorCalled());
568        assertEquals(TestHtmlConstants.HELLO_WORLD_TITLE, mOnUiThread.getTitle());
569
570        // Load the page once again, without clearing the sslpreferences.
571        // Make sure we do not get the callback.
572        webViewClient.resetWasOnReceivedSslErrorCalled();
573        mOnUiThread.loadUrlAndWaitForCompletion(url);
574        assertFalse(webViewClient.wasOnReceivedSslErrorCalled());
575        assertEquals(TestHtmlConstants.HELLO_WORLD_TITLE, mOnUiThread.getTitle());

567行为

567        assertTrue(webViewClient.wasOnReceivedSslErrorCalled());

我们明确两个情况，
第一，该问题偶现，故可以认为实际代码逻辑其实并没有问题，可能有其他因素干扰所致。
第二，查看case发现Line 556-560与Line 566-568其实做的是同一件事情，除去中间Line 564-565是在做清理工作外，其他都没有任何区别。

结合第二点和偶现问题发生时，总是在567行出错，之前Line 560的assert从未fail过，所以我们可以怀疑两点
第一，Line 564-565两个清理工作方法存在偶现问题，有时候会清楚不了ssl相关信息。
第二，第一次的访问影响到了第二次的访问，导致情况不一致。

这个问题如果可以查看到具体的cap log，可能就不需要自顶向下阅读代码，但是由于该服务器架设在手机内部，不知道为何cap log中并没有相关ssl 握手信息。只好从ssl错误回调开始看，一直阅读一直复现。

阅读代码没什么可说的，可以发现怀疑点一不是问题的根本，清除工作做得很正常。
最终发现由于连接访问过程中loadUrlAndWaitForCompletion只是等待到了主资源加载完毕，而子资源（favicon.ico）依然还在连接。导致下一个请求访问开始时，sslconfig并没有清空。由于ssl证书与host关联，故第二次请求主资源的时候虽然出现了问题，但是认为是已知的证书问题，忽略该错误直接发送请求。

目前认为该问题无法修改机制，只能提交TR。

2. 显示5min或者10min超时

一般超时问题都相对可以追溯，与assert fail不同，一般超时是指setup阶段，teardown阶段，以及测试方法本身出现deadlock，从而一直超时。
其实考虑到webview本身是一个独立的app组件，一般情况下死锁是能够在浏览器使用的时候就发现的，所以setup和teardown阶段是最有可能出现死锁的。
例：

android.webkit.cts.WebViewSslTest –
testSslErrorProceedResponseNotReusedForDifferentHost - failed

android.webkit.cts.WebViewSslTest –
testSslErrorProceedResponseNotReusedForSameHost - failed

Test failed to run to completion. Reason: 'Failed to receive adb shell test output within 600000 ms. Test may have timed out, or adb connection to device became unresponsive'. Check device logcat for details

result输出可能有多样，但是基本的情况就是slog所打印出的log从该case start开始大约有5-10min没有任何CTS测试相关的log输出。包括最后的finish也没有。

这种情况可以通过在CTS的测试代码中添加log进行检查到底是哪里出现deadlock。

比如这个问题，实际上是出在CTS的teardown方法中:

457    @Override
458    protected void tearDown() throws Exception {
459        if (mOnUiThread != null) {
460            mOnUiThread.cleanUp();
461        }
462        if (mWebServer != null) {
463            stopWebServer();
464        }
465        super.tearDown();
466    }

在每一行都添加log后通过复现可以发现死锁卡在stopWebServer这行。从而导致test无法执行完毕。

相类似的情况可能在setup函数或者是case本身

3. 解决思路及方案

目前已知的解决办法就两种
1.提交TR说明问题原因以及现象。具体模板可以直接问CTS接口人索取。
一般需要确认原因并且最好有android或者chromium的官方issue辅证为佳。
2.直接修改代码以符合测试要求。这一类比较大胆，可以通过activityManager查询当前process name来分别到底是cts测试还是实际的app使用了webview组件，再根据死板的cts测试流程给予正确的回复。

CTS 问题指南