• 博客园logo
  • 会员
  • 众包
  • 新闻
  • 博问
  • 闪存
  • 赞助商
  • HarmonyOS
  • Chat2DB
    • 搜索
      所有博客
    • 搜索
      当前博客
  • 写随笔 我的博客 短消息 简洁模式
    用户头像
    我的博客 我的园子 账号设置 会员中心 简洁模式 ... 退出登录
    注册 登录
yuzaipiaofei
博客园    首页    新随笔    联系   管理    订阅  订阅

Android cts all pass 全攻略

Android cts all pass 全攻略
 

✿为什么要进行cts测试Android兼容性测试(CTS)和连带的兼容性定义文档(CDD),是一个确保终端设备与特定版本Android兼容的自管理程序。C...

 

✿为什么要进行cts测试

        Android兼容性测试(CTS)和连带的兼容性定义文档(CDD),是一个确保终端设备与特定版本Android兼容的自管理程序。CTS测试集包含大约24,000个在Android设备上运行的测试用例,这些用例分别针对电话、图形、相机、GPS、触摸屏、无线网等功能。Google针对每个主要Android版本公布了CDD文档,其中指出了对CTS中每类测试的具体要求。通过CTS测试是访问Android软件市场的必要条件之一。通过CTS测试之后便允许在设备上使用Android商标,它标志着该设备能够良好兼容软件市场中的数十万应用程序。

      ✿常见问题和解决方案

      我在这里不写怎么执行CTS,-p 是什么意思 -t是什么意思,我总结的是在执行  cts_host > start --plan CTS 之后,想all pass 的那些有营养的东西。

      ❀ testcase timeout

         测试某个testcase的时候一直出现 “........”,迟迟没有pass或者fail,等良久出现一个血淋淋的timeout,很让人伤心。有不少人笑嘻嘻的以为timeout 挺好,至少它不是fail。在我看来timeout 比 fail 还恐怖,因为它连进行测试到底是pass还是fail的权利都没有。想不被硬件设备厂商笑话,必须0 timeout ,然后再争取0 fail 。

        timeout多数都是由于这个错误造成的:

        Exception in thread "Thread-XX" com.android.ddmlib.ShellCommandUnresponsiveException

                           at com.android.ddmlib.AdbHelper.executeRemoteCommand(AdbHelper.java:408)

                           at com.android.ddmlib.Device.executeShellCommand(Device.java:276)

                           at com.android.cts.TestDevice$1.run(TestDevice.java:1718)

        解决方案:

            这个错误是由于CTS和SDK版本不匹配造成的。倘若用android2.2 SDK 和 android2.2 cts -r6 还是出现了这个问题,那么编译自己工程的sdk (在整体m后,再make sdk),配套官方的cts一起,就可以百分百解决这个问题了。

           必须要注意的是,不要用自己的工程代码编译出来的cts(make cts),因为可能编译出来的不是最新的(通常是r1版本)。而google提供的才是最新的,而硬件设备厂商都会信赖最新版本的cts的测试结果。

      ❀Restarting device ...Restarting ADB...

         板子执行几个测试项就停下,让人很郁闷

         CTS_INFO >>> Max ADB operations reached. Restarting ADB...

         CTS_INFO >>> Restarting device ...
         Device(xxxxxxxxxxxxxxxxxxxxxx) disconnected
         Test stopped.
         Device(xxxxxxxxxxxxxxxxxxxxxx) connected
  
解决方案:

         其实重启adb和板子是正常现象,如果不重启会影响他们的正常工作。但是这样频繁的重启,很影响工作效率。

         我们可以控制测试中重启的频率:

         修改android-cts/repository/host_config.xml中的 reboots value:     

          <!-- Number of tests executed between reboots. A value <= 0 disables reboots. -->
          <IntValue name="maxTestCount" value="200" />
        

         5000是我测试比较合理的数字,如果不跑全部的cts项23700个test的话,数量不多可以修改为-1,禁止重启。

         如果数量过多,则还是重启的好,否则中途adb会卡死停止test。自动化测试,你不会一直盯着它的对吧?

   ❀java.io.IOException: sad result from adb: closed

          倘若中途出现:

          java.io.IOException: sad result from adb: closed
         00:47 E/ddms: ADB rejected shell command (am instrument -w -e bundle true android.tests.devicesetup/android.tests.getinfo.DeviceInfoInstrument): closed

         CTS_ERROR >>> Failed to execute shell command am instrument -w -e bundle true android.tests.devicesetup/android.tests.getinfo.DeviceInfoInstrument on device 0xxxxxxxxxxxx         

         java.io.IOException: sad result from adb: closed

  解决方案:

          别担心,重启一下板子就好了。

✿其他fail

         因为各个项目差异,所以fail项不同,抛开硬件差异所决定的fail,还有系统工程师为了掩饰别的bug而新增的cts fail bug,我们还需要注意的是:

         1.Net相关的testcase ,记得开wifi \ 3G,保持网络联通

         2.SMS相关的testcase,记得插SIM卡

         3.当I2C上某个设备的testcase没有过,试试禁掉I2C上其他的sensor服务,单一测试,也许会有意外收获


posted @ 2011-08-22 16:14  yuzaipiaofei  阅读(252)  评论(0)    收藏  举报
刷新页面返回顶部
博客园  ©  2004-2025
浙公网安备 33010602011771号 浙ICP备2021040463号-3