Android 4.0.3 CTS 測試，android4.0.3

Android 4.0.3 CTS 測試，android4.0.3

Android-CTS 4.0.3測試基本配置

1. Download CTS

CTS的擷取方式有兩種：

1.1.由Google提供

1.1.1．開啟瀏覽器輸入串連: http://source.android.com/compatibility/downloads.html

1.1.2．下載所需檔案

選擇對應Android版本的CDD文檔（介紹CTS測試），CTS測試包下載（測試包會不斷更新），android-cts-verifier-4.0.3_r1-linux_x86-arm.zip，android-cts-media-1.0.zip

1.1.3．基本檔案結構

將下載的CTS測試包解壓到相應檔案夾裡面：android-cts檔案夾裡麵包含Docs、Repository、Tools三個檔案夾。

1.1.4．下載android SDK

1.2.通過4.0.3的源碼編譯得來

在Google提供的Android源碼中是包含CTS測試的，源碼下可以看到有一個CTS檔案夾，裡面就是CTS的測試源碼。

在Android項目源碼下使用命令：

(切換分支，並保證自己的項目源碼最新)

./source build/envsetup.sh

choosecombo 1 18 1(僅針對公司自己的手機,我們這兒選擇Variant choices :user模式)

make cts

來得到，產生的android-cts包在~/<源碼目錄>/out/host/linux-x86/cts中。

2．RUN CTS 前期準備工作

2.1．先確定Linux 系統的adb path是否設定正確（我是在虛擬機器Ubuntu下類比的）

Shell 命令：（配置環境變數）

shz@ubuntu:$ cd ~

shz@ubuntu:$ gedit .bashrc

在.bashrc檔案中添加

PATH=$PATH:/home/shz/java/jdk1.6.0_35/bin:

PATH=$PATH:/home/shz/sdk/android-sdk-4.0.3/platform-tools:

PATH=$PATH:/home/shz/sdk/android-sdk-4.0.3/tools:

（根據你自己的實際的檔案路徑來配置）

2.2．確保你所配置的環境變數都正確

shz@ubuntu:$ java

shz@ubuntu:$ adb

查看資訊是否正確，如果沒有配置好，會有提示

（例如adb: command not found）

2.3．確保手機已正確串連上

shz@ubuntu:$ adb devices 

有的時候會出現這種情況

解決辦法：許可權問題，給予root許可權並在root許可權下重啟adb server即可。

具體步驟：

shz@ubuntu:$ cd sdk/android-sdk-4.0.3/platform-tools

shz@ubuntu:~/sdk/android-sdk-4.0.3/platform-tools$ sudo su

[sudo]password for shz: (輸入密碼，斷行符號，root許可權)

 

退出root模式：

 

Look，一切OK。

3．調整系統狀態

3.1．執行系統重設，恢複為出廠狀態

3.2．測試前需要安裝apk：adb install android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk

然後在設定裡面的協助工具功能中會多一個Delegating Accessibility Service選項，將這個選項開啟

3.3．測試前需要安裝apk：adb install android-cts/repository/testcases/CtsDeviceadmin.apk

3.4．測試前需要安裝apk：adb install CtsVerifier.apk

（之前下載下來的android-cts-verifier-4.0.3_r1-linux_x86-arm.zip解壓有）

然後在設定安全->選擇裝置管理員對多出三個選項，將這三個選項勾選並啟用

3.5．測試Media相關項目需要用到官方提供的一個media包，有三種方式：

a）.在SD卡中建目錄test, 將android-cts-media-1.0.zip解壓到test目錄中，將SD卡插入裝置中。確定SD卡為可讀可寫狀態。

b）.在Ubuntu環境下，可以再android-cts-media-1.0.zip解壓出來的文檔中放在一個建立的test檔案夾匯中，直接運行檔案夾下的

./copy_media.sh

即可。

 

它會自動把這些media檔案拷貝到你的sd卡中。

c）.當知道自己的裝置適應的視頻解析度，使用

. copy_media.sh 1280x720

將該解析度及以下的解析度的視頻複製到手機的SD卡中進行測試。

Google一共提供了五種解析度的視頻檔案，176x144、480x360、720x480、1280x720、1920x1080。根據自己裝置的具體情況添加，公司手機最大支援1080p的視頻，但是超過720p之後的視頻播放都會很卡，所以我暫訂為選擇720p的視頻來測試。

3.6．在 android裝置設定中：安全->螢幕安全保護->自動鎖定設為“無”

3.7. 在 android裝置設定中：顯示->休眠->休眠時間調節到最長

3.8．在 android裝置設定中：開發人員選項->保持喚醒狀態，允許類比地址兩項勾選（當然了，USB調試也是需要開啟的）

3.9．將 android裝置的語言設定為英文。

3.10．需要有一張有話費的可正常使用的SIM卡。 

3.11．將WIFI開啟，串連一個可用AP（我所在公司的手機為雙卡，需要設定好手機的語音、資料、短訊息的預設卡）設定->雙卡設定

3.12．設定->輸入語言設為android 

3.13．手機螢幕停留在主介面上

4．RUN CTS

4.1．開啟終端，進入android-cts/tools目錄

執行命令：

shz@ubuntu:$ cd android-cts/tools

4.2．進入CTS，執行cts-tradefed指令碼

執行命令：

shz@ubuntu:~/android-cts/tools$: ./cts-tradefed

 

當手機串連好的時候，執行該命令，會顯示出Android裝置的ID， 如果沒有這句話，說明手機沒有和PC連通。調整手機和PC的串連，串連好了之後，就重複第二步裡面的內容並給與手機許可權：

之後再重複之前的步驟就可以看見Android裝置的ID了。

註：有時候進入CTS測試狀態後無法出現cts-tf >，此時電腦按一個斷行符號鍵就可以了。這算是CTS的一個小bug。

4.3開始整個CTS測試

4.3.1．首先我們先使用help命令來看一下cts-tf >裡面的資訊：

 

在這個裡面會顯示出CTS測試包的版本：

CTS-tradefed host version 4.0.3_r3

我們可以看一下都有哪些測試plan：

 

測試packages：

 

後面還有許多就不都貼出來了。

4.3.2．開始執行命令

a) 執行一個plan：run cts --plan <plan名稱>

全部測試一遍命令：

run cts --plan CTS

b) 僅測試一個包：run cts -p <測試包名稱>

例如：run cts -p android.acceleration

c) 因為是基於JUnit測試，屬於白盒測試，所有基本上我們都知道它的內部是如何啟動並執行，所以我們也可以根據某個測試包中某一個具體的類或者方法進行測試：

run cts –p <packages name> –c <class name> [-m  <method name>]

d) 多台Android裝置同時測試:

run cts –s 裝置名稱 -plan <plan名稱>

註：

 (1)、這兒有一個很重要的命令

我們在進行CTS測試的時候總會有一些因為各種原因引起的不成功的測試項，但是，要完全進行一次全部的CTS測試又是一項很費時的操作，這個時候這個命令就派上用場了，它可以讓我們之前測試的結果的基礎上，建立一個根據測試結果為fail/not Executed /time out的集合組建出一個新的plan，之後測試這個plan，就可以只需要測試那些之前測試沒有通過的項目，而不用再把已經通過的項目再測一遍，就節約了很多時間。

 (2)、在Google的官網上有這麼提到過，當我們在測試一個整的包的時候，成功率比單獨測一個類和方法要高。

所以，我們再重測一些失敗項的時候，根據情況選擇測試一個包的模式也是一個不錯的選擇。

5．測試結果

測試結果在android-cts/repository/results目錄下；

測試日誌在android-cts/repository/logs目錄下。

6. 失敗項目重測及xml文檔整合

我們在測試一些項目的時候，完全跑一遍CTS測試，很多項都會失敗fail，但是我們在對這些失敗項單獨測得時候，這些項目pass，這時，我們不可能再去重新完全跑一次CTS，這樣既耗時，也不能確保該項一定會pass，這樣，我們就可以用下面的方法來對失敗項操作，做到失敗項的pass結果整合。

原理：

將fail項修改成not Executed項，使用該命令進行重測。

6.1. 定位

找到那些測試fail的項，對它們進行源碼的修改、調試，之後進行單獨測試，直到它不再fail。使用文本編譯器開啟result的xml檔案，找到該項

 

6.2. 修改

找到項目之後，將[result=”fail”]改成[result=”not  Executed”],記得在xml檔案的開頭將fail總數和not Executed的總數根據你修改的數目進行修改

修改之後：

 

6.3. 測試

session_ID是之前查看result前面的ID。

運行，測試完成，結果就被整合到了原來的result集中，pass項將會把原來的fail的log在result的xml檔案中也一併刪除。

注意事項：CTS測試中不能對終端做任何操作。