AOSP包含用於測試模塊的測試模板,這些模板不是VTS運行程序的BaseTest的主機端Python子類。
開發人員可以使用這些模板來最大程度地減少集成此類測試的工作量。本節介紹如何配置和使用測試模板(位於VTS testcases / template目錄中),並提供常用模板的示例。
BinaryTest模板
使用BinaryTest模板來集成在VTS中在目標設備上執行的測試。目標端測試包括:
- 基於C ++的測試已編譯並推送到設備
- 目標端Python測試已編譯為二進製文件
- 設備上可執行的Shell腳本
無論有沒有BinaryTest模板,這些測試都可以集成到VTS中。
將目標端測試與BinaryTest模板集成
BinaryTest模板旨在幫助開發人員輕鬆集成目標端測試。在大多數情況下,您可以在AndroidTest.xml
添加一些簡單的配置行。 VtsDeviceTreeEarlyMountTest的示例配置:
<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest."> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/> <option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" /> <option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" /> <option name="test-timeout" value="5m"/> </test> </configuration>
在此配置中:
-
binary-test-source
和binary-test-type
是特定於模板的。 - 指定測試二進制源的相對主機路徑可使模板處理準備,文件推送,測試執行,結果解析和清理。
- 該模板包含與測試用例創建相關的方法,以供子類覆蓋。
- 該模板在每個測試二進制模塊中假設一個測試用例,並且默認情況下將二進制源文件名用作測試用例名稱。
配置選項
BinaryTest模板支持以下配置選項:
選項名稱 | 值類型 | 描述 |
---|---|---|
二進制測試源 | 弦 | 相對於主機上的vts測試用例目錄的二進制測試源路徑。 示例: DATA/nativetest/test |
二進制測試工作目錄 | 弦 | 工作目錄(設備端路徑)。 示例: /data/local/tmp/testing/ |
二進制測試環境 | 弦 | 二進制的環境變量。 示例: PATH=/new:$PATH |
二進制測試參數 | 弦 | 測試參數或標誌。 示例:-- --gtest_filter=test1 |
二進制測試ld庫路徑 | 弦 | LD_LIBRARY_PATH 環境變量。示例: /data/local/tmp/lib |
二進制測試禁用框架 | 布爾值 | 測試前,請運行adb stop 關閉Android Framework。示例: true |
二進制測試停止本機服務器 | 布爾值 | 在測試過程中,停止所有正確配置的本機服務器。示例: true |
二進制測試類型 | 串 | 模板類型。其他模板類型也從該模板擴展而來,但是您不必為此模板指定此選項,因為您已經指定了binary-test-source 。 |
對於具有值類型strings
選項,您可以通過重複配置中的選項來添加多個值。例如,設置兩次binary-test-source
(如VtsDeviceTreeEarlyMountTest
示例中所示)。
測試標籤
您可以通過以下方式添加測試標籤:將測試標籤添加到帶有strings
值的選項之前,並使用::
作為分隔符。當包含名稱相同但位數不同或父目錄不同的二進制源時,測試標籤特別有用。例如,為避免具有相同名稱但來自不同源目錄的源的文件推送或結果名稱衝突,可以為這些源指定不同的標記。
如具有兩個dt_early_mount_test
源的VtsDeviceTreeEarlyMountTest
示例所示,測試標記是binary-test-source
上的_32bit::
和_64bit::
前綴。以32bit
或64bit
結尾的標籤會自動將測試標記為可用於一位ABI位。即,標記_32bit
測試不會在64位ABI上執行。不指定標籤等於使用帶有空字符串的標籤。
具有相同標籤的選項被分組並與其他標籤隔離。例如,帶有_32bit
標記的binary-test-args
僅適用於具有相同標記的binary-test-source
,並在具有相同標記的binary-test-working-directory
執行。 binary-test-working-directory
選項對於二進制測試是可選的,允許您為標籤指定單個工作目錄。如果未指定binary-test-working-directory
選項,則每個標籤都使用默認目錄。
標記名稱直接附加到結果報告中的測試用例名稱。例如,測試案例testcase1
與標籤_32bit
顯示為testcase1_32bit
在結果報告。
在沒有BinaryTest模板的情況下集成目標端測試
在VTS中,默認測試格式是從VTS運行程序中的BaseTest擴展的主機端Python測試。要集成目標端測試,您必須首先將測試文件推送到設備,使用shell命令執行測試,然後使用主機端Python腳本解析結果。
推送測試二進製文件
我們建議使用VtsFilePusher
目標準備器推送文件。例:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher"> <option name="push" value="DATA/test->/data/local/tmp/test"/> </target_preparer>
VtsFilePusher
執行以下操作:
- 檢查設備連接。
- 確定絕對源文件路徑。
- 使用
adb push
命令adb push
文件。 - 測試完成後刪除文件。
或者,您可以使用遵循類似過程的主機端Python測試腳本來手動推送文件。
運行測試
將文件推送到設備後,在主機端Python測試腳本中使用shell命令運行測試。例:
device = self.android_devices[0] res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"]) asserts.AssertFalse(any(res[return_codes]))
GtestBinaryTest模板
GtestBinaryTest模板託管GTest測試二進製文件,每個二進製文件通常包含多個測試用例。該模板通過覆蓋設置,測試用例創建和結果解析方法來擴展BinaryTest模板,因此所有BinaryTest配置都是繼承的。
GtestBinaryTest添加了選項gtest-batch-mode
:
選項名稱 | 值類型 | 描述 |
---|---|---|
二進制測試類型 | 串 | 模板類型。使用值gtest 。 |
gtest-batch-mode | 布爾值 | 以批處理模式運行Gtest二進製文件。示例: true |
通常,將gtest-batch-mode
設置為true
提高性能,同時會稍微降低可靠性。在VTS一致性測試中,許多模塊使用批處理模式來提高性能。但是,出於可靠性考慮,如果未指定模式,則默認為非批處理。
非批量模式
非批處理模式針對每個測試用例分別調用GTest二進製文件。例如,如果GTest二進製文件包含10個測試用例(通過主機端配置過濾後),則每次使用不同的測試過濾器在設備外殼上調用二進製文件10次。對於每個測試用例,模板都會生成並解析一個唯一的GTest結果輸出XML。
使用非批處理模式的優點包括:
- 測試用例隔離。一個測試用例中的崩潰或掛起不會影響其他測試用例。
- 粒度。更容易獲得每個測試用例的性能分析/覆蓋率度量,systrace,bugreport,logcat等。在每個測試用例完成後立即檢索測試結果和日誌。
使用非批處理模式的缺點包括:
- 冗餘加載。每次調用GTest二進製文件時,它將加載相關的庫並執行初始類設置。
- 通信開銷。測試完成後,主機和目標設備進行通信以進行結果解析和下一個命令(可能會進行未來的優化)。
批處理模式
在GTest批處理模式下,僅使用包含由主機端配置過濾的所有測試用例的長測試過濾器值調用一次測試二進製文件(這避免了非批處理模式下的冗餘加載問題)。您可以使用output.xml或使用終端輸出來解析GTest的測試結果。
使用output.xml時(默認):
與非批處理模式一樣,測試結果通過GTest輸出xml文件進行解析。但是,由於輸出xml是在所有測試完成之後生成的,因此,如果測試用例崩潰了二進製文件或設備,則不會生成結果xml文件。
使用終端輸出時:
GTest運行時,它將以框架可以解析的格式打印測試日誌並向終端顯示進度,以獲取測試狀態,結果和日誌。
使用批處理模式的優點包括:
- 測試用例隔離。如果框架在崩潰後使用減少的測試過濾器(不包括已完成和崩潰的測試用例)重新啟動二進製文件/設備,則提供與非批處理模式相同的測試用例隔離級別。
- 粒度。提供與非批處理模式相同的測試用例粒度。
使用批處理模式的缺點包括:
- 維修費用。如果GTest日誌記錄格式更改,則所有測試都將中斷。
- 混亂。測試用例可以打印類似於GTest進度格式的內容,這會混淆格式。
由於這些缺點,我們暫時刪除了使用命令行輸出的選項。將來,我們將重新考慮該選項,以提高此功能的可靠性。
HostBinaryTest模板
HostBinaryTest模板包含其他目錄或Python腳本中不存在的主機端可執行文件。這些測試包括:
- 在主機上可執行的已編譯測試二進製文件
- Shell,Python或其他語言的可執行腳本
VTS Security SELinux策略主機端測試就是一個例子:
<configuration description="Config for VTS Security SELinux policy host-side test cases"> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/> <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" /> <option name="binary-test-type" value="host_binary_test"/> </test> </configuration>
HostBinaryTest不會擴展BinaryTest模板,但會使用類似的測試配置。在上面的示例中, binary-test-source
選項指定測試可執行文件的主機端相對路徑, binary-test-type
為host_binary_test
。與BinaryTest模板類似,默認情況下,二進製文件名用作測試用例名稱。
擴展現有模板
您可以直接在測試配置中使用模板以包含非Python測試,也可以在子類中擴展模板以處理特定的測試需求。 VTS存儲庫中的模板具有以下擴展:
鼓勵開發人員針對任何特定的測試要求擴展任何現有模板。擴展模板的常見原因包括:
- 特殊的測試設置過程,例如使用特殊命令準備設備。
- 生成不同的測試用例和測試名稱。
- 通過讀取命令輸出或使用其他條件來解析結果。
為了使擴展現有模板更加容易,模板包含專門用於每種功能的方法。如果您對現有模板進行了改進的設計,我們建議您為VTS代碼庫做出貢獻。