CTS问题分析14 | weiinter105

由于测试手法不规范造成的cts-on-gsi无法retry的问题

问题初探

测试命令: run cts-on-gsi-retry –retry 6 -s 8981083
报错堆栈(host log中):

 

从堆栈上看是正常的,需要再深入看一下

问题分析

首先从关键的一句log入手

No module that needed to run in retry were found. nothing to do.

 

很明显是loadingStrategy返回的LinkedHashMap为空导致的问题,那么需要看一下为什么返回值是空

看BaseTestSuite中的loadingStrategy,这里返回null

 

这个函数是为了加载我们给测试项提供的额外的配置文件,一般在google/vts/vts9.0_r5/android-vts/testcases的文件下,如BionicUnitTestsStatic.config等等,从中读取配置文件;retry时其调用栈为:

 

继续沿着栈查看

 

可见有两种可能 1. listConfigFiles为空 2. 循环loadOneConfig一直没有加载config

若第一种情况,那么只能是测试环境有问题,配置文件完全被删了,看了下排除该情况;那么只能是第二种情况

查看SuiteModuleLoader中的相应逻辑

 

 

我们注意到在loadOneConfig中有个过滤条件,shouldRunModule;那么在retry时这里的逻辑是过滤出要被执行的module的相应的配置属性

那么为什么这个值一直是false呢,mIncludeFilters本身不是null(host log中打印出来了),那么只能getFilterList(this.mIncludeFilters, moduleId)得到null;

moduleId为abi和module name的组合,到这里,我们就怀疑是abi造成的问题了;再回头看host log;发现果然:

 

由于abi的不匹配造成的问题,retry时查询要执行的module的config时,由于abi不匹配造成测试框架误判断shouldRunModule = false;

问题总结

1.测试手法的问题,cts-og-gsi默认只测64位,但是如果后面加上-a armeabi-v7a的话,也能进行32位的测试;测试第一次测试时加了-a armeabi-v7a;但是后面进行retry时没有加,导致框架默认abi为arm64-v8a;导致后续retry流程module因为abi的关系无法匹配;读取要retry的报告为v7a,加载config时默认v8a导致的问题, 请测试同学注意下;测cts-on-gsi时后面就不用加-a了,避免该问题重复发生

2.框架有轻微的问题,但本质来说是测试手法问题,google不会认的

微信扫码打赏

作者: RESSRC

个人资源站

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据