[Google GTS][7.0R2]GtsSettingsTestCases(顺道以该case为例介绍GTS BL机制)

[DESCRIPTION]

首先，该case是GTS 7.0R2新增case，具体报错信息如下

com.google.android.settings.gts.MADAComplianceTest#testMADACompliance

fail

java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.test.uiautomator.UiDevice.unfreezeRotation()' on a null object reference at com.google.android.settings.gts.MADAComplianceTest.tearDown(MADAComplianceTest.java:96) at java.lang.reflect.Method.invoke(Native Method)

[ANALYSIS]

首先，该fail只在EEA版本上报出，非EEA版本该case pass，单是这种现象就可以怀疑BL了

什么是BL呢，所谓BL即Bussiness Logic缩写，是Google针对合作商及合作商产品投放地区的不同而特别订制的测试，换言之就是虽然case名都是一样的，但针对不同的厂商或者不同的产品投放地区(欧盟，非欧，俄罗斯)，这个case测试的内容可以是不一样的

再看BL是怎么工作的：

执行测试套之前需要配置一个环境变量APE_API_KEY，指向保存在本地的从Google得到的json文件

执行case的时候，先是通过这个key去GCP拿到token，再向GTS Cloud请求对应的将要执行的BL，GTS Cloud会根据你的身份信息判断当前的DUT将要执行什么样的BL，并将生成的bl文件返回给本地(保存在DUT的/sdcard/路径下，在测试完成后自动删除)

回到失败项，了解bl后就可以捕获下EEA和非EEA的bl结合device log做下对比

先看非EEA pass的情况：

bl相关内容：

      "testName": "com.google.android.settings.gts.MADAComplianceTest#testMADACompliance",
      "businessLogicRules": [
        {
          "ruleConditions": [
            {
              "methodName": "com.android.compatibility.common.util.ApiLevelUtil.isAtLeast",
              "methodArgs": [
                "27"
              ]
            },
            {
              "methodName": "!com.google.android.settings.gts.MADAComplianceTest.verifyGPP"
            }
          ],
          "ruleActions": [
            {
              "methodName": "com.google.android.settings.gts.MADAComplianceTest.failTest",

相关log内容：

08-26 22:44:35.825  7773  7787 I BusinessLogicTestCase: Finding business logic for test case: com.google.android.settings.gts.MADAComplianceTest#testMADACompliance
08-26 22:44:35.826  7773  7787 D BusinessLogicExecutor: Executing condition: com.android.compatibility.common.util.ApiLevelUtil.isAtLeast(27)
08-26 22:44:35.828  7773  7787 D BusinessLogicExecutor: Executing condition: com.google.android.settings.gts.MADAComplianceTest.verifyGPP()

而EEA上fail的情况，bl中没未查到testMADACompliance

log中内容：

08-26 22:50:18.251 20522 20536 E TestRunner: failed: testMADACompliance(com.google.android.settings.gts.MADAComplianceTest)
08-26 22:50:18.251 20522 20536 E TestRunner: ----- begin exception -----
08-26 22:50:18.252  1558  1558 I ADB_SERVICES: g_pending_list length=1
08-26 22:50:18.252 20522 20536 E TestRunner: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.test.uiautomator.UiDevice.unfreezeRotation()' on a null object reference
08-26 22:50:18.252 20522 20536 E TestRunner: 	at com.google.android.settings.gts.MADAComplianceTest.tearDown(MADAComplianceTest.java:96)

只有报错，并不存在BussinessLogicExecutor的日志，说明该case执行并没有跑相关的BL

结果异常发生的地方是在tearDown里面

反编译测试套对应的apk代码(GTS测试套是闭源的，查看代码逻辑需要反编译对应的测试apk)

异常正好指向调用unfreezeRotation()时空指针引用，而mDevice是在setup的阶段初始化的，

猜测可能是针对EEA的BL执行过程中对mDevice做了操作被置为了空

陈述上述分析过程给Google申请waive， 目前已经获得approval

[SUMMARY]

BL模式是GTS的一个趋势，按Google自己的说法，这么做可以更加高效的针对不同的业务逻辑做测试适配

对于问题定位而言，首先捕获bl文件(测试过程中从DUT的/sdcard/路径下获得)，结果device log就可以知道

当前case的执行逻辑