上一篇文章我們已經知道testcases目錄中xml配置文件讀取出來后的形式,繼續往下看:

然后把xml對應的TestPackageDef保存到Map中,所以我們可以這樣說,TestPackageDef就代表了一個testcases目錄下的xml文件。所以有多少個xml文件就有多少個TestPackageDef對象,然后將這些對象保存到map中。key值為xml的appPackageName屬性值。當所有的xml文件都配置完成后,我們就回到了buildTestsToRun方法中:

這個時候調用了getTestPackagesToRun,這個方法是從剛才得到的testRepo對象中篩選出本次任務需要跑的ITestPackageDef列表。再根據該列表組裝List
對象testPkgList并返回。

然乎根據參數來添加發生錯誤時的操作:
保存bugreport信息
保存截圖
保存logcat system的信息
然后找到要安裝的apk和執行完任務后要卸載的包名:

這是根據xml中targetBinaryName屬性對應的值找到apk名和targetNameSpace屬性找到要卸載的包名。然后安裝這些apk,并獲取手機設備信息。實際上是通過安裝TestDeviceSetup.apk,然后運行Instrumentation的case來獲取信息的。獲取完信息以后,會判斷是否需要重啟,只有當要執行的case包大于1且mDisableReboot為false時才重啟設備。然后是循環執行測試任務,以包為單位執行,執行的核心為test.run(filter);


先將包含測試的apk安裝到設備中,然后運行case,最后刪除case包。我們來看看刪除的case包到底是什么。

原來apk安裝后,android系統是通過其包名來定位apk的,所以卸載的時候肯定要用包名。先來再來回頭看super.run(listener);

先通過DDM的RemoteAndroidTestRunner來創建測試的runner,然后設置一些基本參數,就可以調用doTestRun方法來進行實際的測試。

先獲得要測試的case信息。經過一系列跳來跳去跳來跳去,最后到了TestDevice中:

最后到執行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。
- 前言
- (1)-windows下cts配置
- (2)-cts調試環境的搭建
- (3)-基礎庫tradefederation配置
- (4)-任務的添加
- (5)-9大組件配置
- (6)-任務的執行
- (7)-任務執行的調度室
- (8)-IBuildProvider
- (9)-IDeviceRecovery
- (10)-TestDeviceOptions
- (11)-ICommandOptions
- (12)-ITargetPreparer
- (13)-任務執行過程
- (14)-任務執行過程
- (15)-任務執行完
- (16)-logcat信息收集系統
- (17)-fastboot狀態監聽器
- (18)-設備恢復
- (19)-設備狀態的分類以及恢復模式的分類
- (20)-cts自身log系統
- (21)-測試結果收集系統
- (22)-自動檢測設備
- (23)-設備分類
- (24)-case的組織