目录

原理简介：

Cts测试原理：

CTS报告与日志目录

CTS报告目录如下​编辑

log查看

举例

---

原理简介：

Cts环境搭建和测试方法，大家可以自行查询网上资料。

Cts测试原理：

输入命令后，会安装一系列的测试apk到盒子中，apk中会有很多断言，若这些断言失败就会报错。

如：

CTS报告与日志目录

CTS报告目录如下

test_result_failures_suite.html 中会记录所有的fail项。

我们只用关注failed项即可，Assumption Failure 不管。

往下翻，会看到相对详细点的错误。

log查看

跑cts时，同时会有个log文件，里面的目录如下：

一般log要在host_log_******.txt.gz 中找

此时你需要向测试要其使用的测试套件（主要那些apk与jar等，一般测试类和测试套件中的apk或jar同名，如果是apk需要先把apk反编译成jar）

如果你是在window下，可以用git 命令窗口去搜索：

接着用jd-gui.jar 去打开这个jar，上面说136行出错，可以看到是assertTrue(0 < b.getEstimatedBatteryCapacityMah()); 失败。如下

接着就得去查看getEstimatedBatteryCapacityMah是啥了。我用dumpsys battery查看这个结果是1000，不知道为何这里会失败。就让测试再去测试了。

假如你觉得这样分析jar不方便，可以查源码cts目录下的代码或在AOSPXRef 上搜索，不过其与测试套件里面真正的代码可能会有些许区别。

到这就是cts问题分析的一个大致流程了。

举例

接下来我们看一个GTS的经典例子：

看到上面的错误行，我最开始以为应该去查看runTest里面的内容。

但实际上应该根据UsageStatsHostTest.testInstantApp 方法里面的runTest内容，去查UsageStatsTest 的testInstantApp方法才对。

而在log的上面几行已经有相关提示：