企业🤖AI Agent构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
上一篇文章我们已经知道testcases目录中xml配置文件读取出来后的形式,继续往下看: ![](https://box.kancloud.cn/2016-01-09_56911dd452703.jpg) 然后把xml对应的TestPackageDef保存到Map中,所以我们可以这样说,TestPackageDef就代表了一个testcases目录下的xml文件。所以有多少个xml文件就有多少个TestPackageDef对象,然后将这些对象保存到map中。key值为xml的appPackageName属性值。当所有的xml文件都配置完成后,我们就回到了buildTestsToRun方法中: ![](https://box.kancloud.cn/2016-01-09_56911dd5df798.jpg) 这个时候调用了getTestPackagesToRun,这个方法是从刚才得到的testRepo对象中筛选出本次任务需要跑的ITestPackageDef列表。再根据该列表组装List 对象testPkgList并返回。 ![](https://box.kancloud.cn/2016-01-09_56911dd6580ab.jpg) 然乎根据参数来添加发生错误时的操作: 保存bugreport信息 保存截图 保存logcat system的信息 然后找到要安装的apk和执行完任务后要卸载的包名: ![](https://box.kancloud.cn/2016-01-09_56911dd6a7631.jpg) 这是根据xml中targetBinaryName属性对应的值找到apk名和targetNameSpace属性找到要卸载的包名。然后安装这些apk,并获取手机设备信息。实际上是通过安装TestDeviceSetup.apk,然后运行Instrumentation的case来获取信息的。获取完信息以后,会判断是否需要重启,只有当要执行的case包大于1且mDisableReboot为false时才重启设备。然后是循环执行测试任务,以包为单位执行,执行的核心为test.run(filter); ![](https://box.kancloud.cn/2016-01-09_56911dd738a4e.jpg) ![](https://box.kancloud.cn/2016-01-09_56911dd7a4c85.jpg) 先将包含测试的apk安装到设备中,然后运行case,最后删除case包。我们来看看删除的case包到底是什么。 ![](https://box.kancloud.cn/2016-01-09_56911dd7d118d.jpg) 原来apk安装后,android系统是通过其包名来定位apk的,所以卸载的时候肯定要用包名。先来再来回头看super.run(listener); ![](https://box.kancloud.cn/2016-01-09_56911dd80a0c5.jpg) 先通过DDM的RemoteAndroidTestRunner来创建测试的runner,然后设置一些基本参数,就可以调用doTestRun方法来进行实际的测试。 ![](https://box.kancloud.cn/2016-01-09_56911dd88abb2.jpg) 先获得要测试的case信息。经过一系列跳来跳去跳来跳去,最后到了TestDevice中: ![](https://box.kancloud.cn/2016-01-09_56911dd8e4177.jpg) 最后到执行case,执行完以后会判断是否成功发送了命令,如果没有就要重连设备。最后讲一下performDeviceAction这个方法: ~~~ private boolean performDeviceAction(String actionDescription, final DeviceAction action, int retryAttempts) throws DeviceNotAvailableException { // 如果成功直接返回,如果失败就要重试 for (int i = 0; i < retryAttempts + 1; i++) { try { return action.run(); } catch (TimeoutException e) { logDeviceActionException(actionDescription, e); } catch (IOException e) { logDeviceActionException(actionDescription, e); } catch (InstallException e) { logDeviceActionException(actionDescription, e); } catch (SyncException e) { logDeviceActionException(actionDescription, e); // a SyncException is not necessarily a device communication // problem // do additional diagnosis if (!e.getErrorCode().equals(SyncError.BUFFER_OVERRUN) && !e.getErrorCode().equals(SyncError.TRANSFER_PROTOCOL_ERROR)) { // this is a logic problem, doesn't need recovery or to be // retried return false; } } catch (AdbCommandRejectedException e) { logDeviceActionException(actionDescription, e); } catch (ShellCommandUnresponsiveException e) { CLog.w("Device %s stopped responding when attempting %s", getSerialNumber(), actionDescription); } // TODO: currently treat all exceptions the same. In future consider // different recovery // mechanisms for time out's vs IOExceptions recoverDevice(); } if (retryAttempts > 0) { throw new DeviceUnresponsiveException(String.format("Attempted %s multiple times " + "on device %s without communication success. Aborting.", actionDescription, getSerialNumber())); } return false; ~~~ 上面的写法会在case执行过程中出现异常的话,会有重试机制。但前提是retryAttempts这个变量的值要大于0。