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