Android兼容性測試CTS --環境搭建、測試執行、結果分析

    爲了確保Android應用可以在全部兼容Android的設備上正確運行，而且保持類似的用戶體驗，在每一個版本發佈之時，Android提供了一套兼容性測試用例集合（Compatibility Test Suite, CTS）來認證運行Android系統的設備是否徹底兼容Android規範，並附帶有相關的兼容性標準文檔（Compatibility Definition Document, CDD）。

    首先從http://source.android.com/compatibility/downloads.html（網絡須要能進google）處下載最新的兼容性測試用例集合，並解壓。如圖1所示。

        

圖1 Android 官網中CTS測試環境下載等

大部分是基於Junit和儀表盤技術編寫的。還擴展了自動化測試過程，能夠自動執行用例，自動收集和彙總測試結果。CTS採用XML配置文件的方式將這些測試用例分組成多個測試計劃（plan）,第三方也能夠建立本身的plan。

CTS測試執以前要作的準備工做以下：

1. 下載兼容性測試用例包，並解壓，解壓後的文件名命名爲「android-cts」。在http://source.android.com/compatibility/downloads.html頁面的最下方，有一個名爲「Compitibility Test Suite(CTS) User Manual」的連接，是最新版本的Android兼容性測試用例的執行方法，建議在執行以前先通讀該文檔。

2. 刷機爲須要測試的版本。

3. 手機開機時，若是有google帳戶設置，取消便可：Start->Not now->Next->Next->Next->Finish。

4. 設置手機語言爲英語：Setting->Language&input->language->English(United States)。

5. 插入SIM卡和外置SD卡（SD卡須要格式化：Settings->Storage->Erase SD card->Erase SD card->Erase Everything）。

6. 插入USB,鏈接手機到電腦，能夠用adb devices檢查，是否正確鏈接。

7. 打開wifi, 並鏈接到可用wifi。

8. 打開藍牙，無須配對。

9. 保證手機無操做30分鐘後LCD off:Settings->Display->Sleep->30 minutes.

10. 去掉屏幕鎖：Settings->Security->Screen Lock 的值是「None」.

11. 打開Settings->Location services->「Google location services」, 」GPS satellites」, 」Location & Google search」.

12. 打開Settings->Accessibility->Developer options->USB debugging(USB 調試).

13. 打開Settings->Accessibility->Developer options->Stay Awake（保持喚醒）.

14. 打開Settings->Accessibility->Developer options->Allow mock location（容許模擬位置）.

15. 經過Settings->Speech synthesis->Install voice data安裝「Text To Speech」文件（com.svox.langpack.installer-1.apk）, 假如android-cts/repository/testcases/中沒有此文件，就省去這一步。

16. 若是須要執行可訪問性方面的兼容性測試，則安裝「CtsDelegatingAccessibilityService.apk」（adb install –r */android-cts/repository/testcases/ CtsDelegatingAccessibilityService.apk），並將Settings->Accessibility->Delegating Accessibility Service選項打開。假如m目錄中沒有此文件，就省去這一步，通常狀況下是沒有的。

17. 若是須要執行設備管理方面的兼容性測試，則安裝「CtsDeviceAdmin.apk」 (adb install –r */android-cts/repository/testcases/ CtsDeviceAdmin.apk)，並將Setting->Security->Devices Administrators->android.devicesadmin.cts.CtsDevicesAdmin等選項打開。目錄中必定會有這個文件的，請仔細查找，如圖2所示。

圖2 CtsDeviceAdmin.apk

18. 若是須要執行多媒體方面的兼容性測試，則須要執行:

1)從http://source.android.com/compatibility/downloads.html 下載android- cts-media-X.Y.zip並解壓。

2）進入解壓後的文件夾，並執行bash copy_media.sh, 把測試所需文件copy到手機內存中，假如copy失敗，多是手機路徑不對，請用gedit打開copy_media.sh文件，同時adb shell進入手機終端，查看手機內存目錄與copy_media.sh文件中的目錄是否一致。若是不一致，請更改copy_media.sh文件，必須保證copy到手機內存（copy完以後能夠打開gallery進行查看），不然會影響後邊android.media等與media相關測試包的執行，如圖3-一、圖3-2所示。

圖3-1 Copy Media

圖3-2 Copy Media

19. 保證手機處於home界面，即按下「Home」鍵。

CTS測試正式開始：

1． 進入到「*/android-cts/tools」目錄，執行bash cts-tradefed，先識別設備，以後出現cts_host >，則證實已進入CTS命令行交互界面，此時能夠輸入cts相關命令來執行cts測試了，如圖4所示。

圖4 CTS命令行交互界面

2． 測試默認CTS，其中包括全部的packages，能夠輸入以下命令 :

run cts --plan CTS（這兩次跑測試都用的這個，具體用哪一個，請諮詢相關人員）

或者 run cts –disable -reboot --plan CTS (跑測試過程當中，手機不會reboot，這樣能夠方便接adb logcat),跑起來時先根據日期和時間建立測試結果的文件夾，而後出現「start test run of xx packages, containing xx tests」說明測試已經開始跑了，此時儘可能再多觀察十分鐘，出現「Installing prerequisites」而且以後有顯示case pass，則確保cts確實開始run了，如圖5所示。

圖5 run cts

CTS測試結果分析：

測試結束後在*/android-cts/respository/results文件夾中，會看到以日期和時間命名的文件夾用於保存執行過的測試結果，如圖6-一、圖6-2所示。

圖6-1 results

圖6-2 results

並且還有一個同名的zip文件保存一樣的內容。測試過程當中的自動錄log，測試結束後log自動保存在*/android-cts/respository/logs裏邊以日期和時間命名的文件夾中，如圖7-一、圖7-2所示。

圖7-1 logs

圖7-2 logs

在測試結果文件夾中，全部的測試結果是以XML的形式保存的。一般測試結果網頁分紅「Device Information」、「Test Summary」、「Test Summary by Package」、「Test Failures(xx)」和「Detailed Test Report」等四個區域。其中 「Device Information」中列出了被測設備具體的軟硬件以及功能配置信息，如圖8所示。

圖8 Device Information

「Test Summary」列出了CTS 版本號，各狀態case個數等信息，如圖9所示。

圖9 Test Summary

而「Test Failures(xx)」會將斷言失敗時的輸出記錄在內，如圖10所示。

圖10 Test Failures

每次測試保證把CTS測試case所有跑完，用 「l r」查看，本次CTS測試是否所有run完，即not executed一列的數值是0，若是數值不爲0，則表示還剩下沒有run完的case,有多是手機凍結或者reset致使adb 識別不了設備，因此後邊的case都爲not executed狀態，如圖11-一、圖11-2所示。

圖11-1 Not executed

圖11-2 Devices offline

這時須要從新鏈接手機，後使用命令「run cts --continue-session session_id」 就能夠繼續上面not executed的case了，session_id用命令l r就能夠看見，如圖12-一、圖12-2所示。

圖12-1 查看Session ID

圖12-2 Continue not executed case

首先保證把整個case都run一遍，not executed數值爲0。以後把「失敗的測試用例」中的case run 三遍，排除手機系統穩定性尤爲是手機reset和freeze致使的case fail。目標是肯定case fail是因爲CTS case自己的問題，而不是任何別的因素。從新run fail的case時須要在上次所有run完的case上邊新建測試計劃，而後執行新建的測試計劃。新建測試測試使用命令「add derivedplan --plan plan_name -s sessionID -r [pass/fail/notExecuted]」 添加一個新的plan，再用命令「run cts --plan plan_name」運行便可測試沒測的項。如：

測試SessionID爲2的全部fail項，輸入命令應爲：

>add derivedplan --plan cts_fail_1 -s 2 -r fail

>run cts --plan cts_fail_1 // cts_fail_1即前面定義的，能夠本身隨意起名字。

以後若是fail的仍是不少，建議作第三遍，就在cts_fail_1測試計劃的基礎上，再次新建和執行測試計劃，假如用「l r」查看cts_fail_1測試計劃的sessionID爲3，則執行

>add derivedplan --plan cts_fail_2 -s 3 -r fail

>run cts --plan cts_fail_3

如圖13所示。

圖13 Add derivedplan

三次run完以後會在*/android-cts/respository/results文件夾中生成三個以日期和時間命名的結果文件夾，把三次都失敗的測試用例粘貼到excel表中進行彙總，並統計每一個測試包（package）中fail的case數量。

CTS測試部分經常使用命令,如圖14。

圖14 Help

與host相關的部分經常使用命令：

help: CTS命令一覽表

exit：退出cts終端

……

與run相關的部分經常使用命令：

run cts --plan test_plan_name: 執行一個測試計劃

run cts --package/-p: 單獨run cts測試中的一個包

run cts --class/-c [--method/-m]: run指定的類，或者具體到類中的方法

run cts --continue-session session_ID: 繼續run指定session上狀態爲not executed 的case

run cts [option] --serial/-s device_ID: 在指定device_ID上run cts [option]

……

與java包相關的部分經常使用命令：

l/list d/devices: 列出全部鏈接的設備和設備的狀態

l/list packages: 列出CTS全部的測試包

l/list p/plan: 列出CTS全部的測試計劃

……

與測試計劃相關的部分經常使用命令：

add derivedplan --plan plan_name --session/-s session_id –r [pass/fail/notExecuted/timeout]:從指定session id中根據case的各類狀態產生一個新的測試計劃

……

與option相關的命令：

run cts --disable-reboot [option]: 在測試過程當中不須要重啓手機

CTS常見問題總結

1．若是測試結果顯示android.media和android.mediastress兩個packages中fail的case較多，並且查看details時，出現如圖14所示的log，則是media沒有copy進指定目錄，此時也能夠adb shell進去手機終端，在fail log路徑下查看，是否有所需文件，我猜想必定是沒有的。

圖14 media fail log

以後須要從新將指定文件copy到fail log中指定的目錄，此時能夠參考*/android-cts-media-1.1/ copy_media.sh文件中的各個push文件路徑，如圖15所示，尤爲注意其中的internal_sd,這是是會根據手機版本有可能會變化的，若是變化，請根據變化更新腳本。

圖15 copy_media.sh

2．整輪測試跑完，若是須要rerun fail的case,在添加新的測試計劃時出現如圖16所示的狀態。

圖16 已有同名plan

根據提示也能看出是已有相同名字的plan存在，此時能夠換個name,或者去如圖17所示目錄中把相同名字的plan刪除。

圖17 plan文件夾

3.若是測試過程當中須要跑指定的幾個packages，而不是full CTS, 則可修改plan文件夾中的CTS.xml文件，如圖18所示。

 

圖18 修改plan

CTS測試執行流程也能夠參考如下博客：

http://blog.csdn.net/subsist/article/details/7209341/

 

想要了解更深層次的CTS，能夠參考如下博客：

http://blog.csdn.net/itfootball/article/category/2581865