테스트 모음
테스트가 VTS의 일부가 되려면 Android.bp에 다음 설정이 있어야 합니다.
test_suites: ["vts"],
또한 테스트를 general-tests 모음에 추가하면 사전 제출 검사에 사용되는 테스트 매핑 모음에 테스트가 포함될 수 있습니다.
테스트 구성
대부분의 경우 Trade Federation에서 VTS 테스트를 실행하기 위해 사용하는 XML 파일인 테스트 구성은 빌드 중에 자동으로 생성됩니다. 그러나 테스트 구성을 맞춤설정할 수 있습니다.
맞춤 테스트 구성 파일 만들기
새 테스트 XML 파일을 처음부터 만드는 것은 복잡할 수 있습니다. 테스트 하네스 작동 방식과 각 테스트 실행기 간의 차이를 파악해야 하기 때문입니다. 자동 생성된 테스트 구성 파일은 이 프로세스를 더 쉽게 하도록 설계되었습니다.
테스트 XML 파일을 맞춤설정해야 한다면 자동 생성된 파일로 시작할 수 있습니다.
자동 생성된 테스트 구성 파일을 찾으려면 먼저 make 명령어를 실행하여 다음과 같이 구성을 빌드합니다.
$ m VtsHalUsbV1_1TargetTest
빌드 디렉터리에서 다음과 같이 모듈 이름에 따라 구성 파일을 검색할 수 있습니다.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
여러 파일 사본이 있을 수 있으며 그중 아무거나 사용할 수 있습니다.
.config 파일을 Android.bp 파일이 있는 디렉터리로 복사합니다.
Android.bp 파일에 테스트 모듈이 하나만 있다면 XML 파일의 이름을 AndroidTest.xml로 바꿀 수 있으므로 빌드 시스템에서 자동으로 테스트 모듈의 구성 파일로 사용합니다. 그 외의 경우에는 다음 예와 같이 test_config 속성을 모듈에 추가합니다.
test_config: "VtsHalUsbV1_1TargetTest.xml",
이제 작업하고 맞춤설정을 구현할 테스트 구성 파일이 생겼습니다.
adb 루트로 테스트 강제 실행
대부분의 VTS 테스트는 실행하는 데 루트 권한이 필요하지 않습니다. 테스트 구성 파일이 자동 생성된 경우 다음 속성을 Android.bp에 추가할 수 있습니다.
require_root: true,
테스트 구성 파일이 맞춤설정된 경우 다음을 테스트 XML 파일에 추가합니다.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
테스트 중에 프레임워크 중지
많은 VTS 테스트에서는 Android 프레임워크를 실행할 필요가 없으며 프레임워크가 중지된 상태에서 테스트를 실행하면 기기 플레이크의 영향을 받지 않고 안정적으로 테스트를 실행할 수 있습니다. 테스트 구성 파일이 자동 생성된 경우 다음 속성을 Android.bp에 추가할 수 있습니다.
disable_framework: true,
테스트 구성 파일이 맞춤설정된 경우 다음을 테스트 XML 파일에 추가합니다.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
테스트 인수 추가
일부 gtest 테스트는 실행하는 데 더 많은 시간이 필요할 수 있습니다. 이 경우 테스트 실행기 옵션을 XML 파일에 추가하면 됩니다.
예를 들어 다음 항목의 native-test-timeout 설정을 사용하면 기본값 1분 대신 3분 제한 시간으로 테스트를 실행할 수 있습니다.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
최소 API 수준 요구
일부 VTS 테스트는 최소 API 수준이 있는 기기에서만 실행할 수 있습니다. 테스트 구성 파일이 자동 생성되었다면 다음 속성을 Android.bp에 추가할 수 있습니다.
test_min_api_level: 29,
테스트 구성 파일이 맞춤설정되었다면 다음 명령어를 테스트 XML 파일에 추가합니다.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12에서는 이러한 기기에 공급업체 이미지의 API 수준을 표시하기 위하여 ro.board.first_api_level 및 ro.board.api_level 속성을 정의합니다. 이 속성을 ro.product.first_api_level과 함께 사용하면 테스트 모음에서 기기에 적절한 테스트 사례를 선택합니다.
Android 13에서는 ro.product.first_api_level, ro.board.first_api_level, ro.board.api_level 속성을 사용하여 필요한 공급업체 API 수준을 계산함으로써 자동으로 설정되는 ro.vendor.api_level을 정의합니다.
ro.board.first_api_level
ro.board.first_api_level 속성은 SoC의 공급업체 이미지가 이 속성과 함께 처음 출시될 때의 API 수준입니다. 이는 기기의 출시 API 수준에 종속되지 않으며, 이 값을 정의하는 SoC의 첫 번째 API 수준에만 종속됩니다. 이 값은 SoC의 전체 기간 동안 영구적으로 적용됩니다.
기기 제조업체는 다음 예에서와 같이 device.mk 파일에 BOARD_SHIPPING_API_LEVEL을 정의하여 ro.board.first_api_level을 설정할 수 있습니다.
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
이렇게 하면 기기에서 ro.board.first_api_level 속성이 자동으로 vendor/build.prop으로 정의됩니다. 속성은 공급업체 init 프로세스에 의해 설정됩니다.
ro.board.api_level
ro.board.api_level 속성은 SoC에 대한 공급업체 이미지의 현재 API 수준입니다. ro.board.first_api_level이 있는 공급업체 이미지의 API 수준이 업데이트되면 SoC를 사용하는 기기는 ro.board.first_api_level을 업데이트하는 대신 공급업체 이미지의 현재 API 수준으로 ro.board.api_level 속성을 정의해야 합니다. 이 속성을 설정하지 않으면 ro.board.first_api_level이 기본적으로 사용됩니다.
ro.board.api_level을 설정하려면 device.mk 파일에서 원하는 값으로 BOARD_API_LEVEL을 정의하세요.
ro.vendor.api_level
Android 13에서는 공급업체 이미지에서 지원해야 하는 API 수준을 보여주기 위해 ro.vendor.api_level 속성이 도입되었습니다. 이 속성은 최소 ro.board.api_level(ro.board.api_level이 정의되지 않은 경우 ro.board.first_api_level) 및 ro.product.first_api_level로 자동 설정됩니다. 공급업체 이미지 업그레이드가 필요한 공급업체 구현 테스트에서는 이 속성을 참조하여 SoC에 대한 공급업체 요구사항을 면제받을 수 있습니다.
VTS를 사용한 샤딩 프로세스
Android 버전 10 이상에서는 아래 안내에 따라 VTS 및 CTS-on-GSI 계획을 모두 사용하여 테스트하면서 샤딩 프로세스를 여러 기기에서 실행할 수 있습니다.
run vts --shard-count <number of devices> -s <device serial> ...
이 명령어는 VTS 계획을 샤드로 분할하여 여러 기기에서 실행합니다.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
이 명령어는 CTS-on-GSI 계획을 샤드로 분할하여 여러 기기에서 실행합니다.