Android 테스트 스테이션은 Android 개발자와 테스트 엔지니어가 표준 Android 테스트 모음(예: Android 호환성 테스트 모음(CTS)) 실행을 위한 사용자 인터페이스를 채택하는 데 사용할 수 있는 테스트 도구입니다. 이 도구는 Trade Federation(TF)의 웹 인터페이스로 작동하므로 이를 사용하면 최소한의 설정으로 테스트 기기 집합에서 CTS를 간편하게 실행하고 연속적인 테스트 실행을 위한 일정을 수립할 수 있습니다.
Android 테스트 스테이션 설정
이 섹션에서는 Android 테스트 스테이션을 설치하고 설정하는 방법을 설명합니다.
Android 테스트 스테이션은 다음 위치에 있는 소스 코드를 사용합니다.
- Android 테스트 스테이션 소스 코드
- TradeFed Cluster 소스 코드
Android 테스트 스테이션 설치
실행하는 테스트 모음의 하드웨어 및 소프트웨어 요구사항을 준수합니다.
CTS 요구사항은 source.android.com에서 확인할 수 있습니다.
ATS에는 추가 하드웨어 요구사항이 없지만 CTS 호스트 요구사항을 시작점으로 사용하는 것이 좋습니다.
Android 테스트 스테이션을 설치하는 방법은 두 가지가 있습니다.
설치 프로그램으로 설치
Ubuntu 20.04 이후 버전의 경우 설치 프로그램에서 Android 테스트 스테이션을 실행하는 데 필요한 모든 프로그램과 리소스를 설치하고 구성합니다.
설치 프로그램을 사용하려면 다음 단계를 따르세요.
설치 프로그램을 실행합니다.
curl https://storage.googleapis.com/android-mtt.appspot.com/prod/install.sh | bash
mtt version을 실행하여 Android 테스트 스테이션 CLI의 설치 버전을 확인합니다.
수동 설치
Docker 설치
Linux 시스템의 Docker Community Edition(CE) 설치 안내를 따릅니다.
권한 변경사항을 적용하려면 터미널 창을 다시 시작하거나 로그아웃 후 다시 로그인해야 할 수 있습니다.
Python 3 설치
Android 테스트 스테이션 CLI는 Python 버전 3.7~3.10에 대해 인증됩니다.
Ubuntu 16.04 이하에서는 먼저 다음 중 하나를 실행하여 Python 3용 저장소를 추가합니다.
다음 명령어를 실행합니다.
sudo add-apt-repository ppa:deadsnakes/ppa
소스에서 저장소를 빌드하고 설치합니다.
Python 3을 설치하려면 다음 명령어를 실행합니다.
sudo apt-get updatesudo apt install python3 python3-distutils
특정 Python 3 버전(예: 3.10)을 설치하려면 대신 다음 명령어를 실행하세요.
sudo apt-get updatesudo apt install python3.10 python3.10-distutils
Android 테스트 스테이션 CLI 가져오기
명령줄 인터페이스(CLI) 패키지를 여기에서 다운로드하세요.
Android 테스트 스테이션 시작
다음 명령어를 사용하여 Android 테스트 스테이션을 시작합니다.
mtt start
UI를 처음 시작하면 표시되기까지 몇 분 정도 걸릴 수 있습니다. CLI는 브라우저에서 UI에 액세스할 수 있는 웹 URL을 표시합니다. 기본적으로 웹 URL은 localhost:8000입니다. 필요한 경우 시작 시 --port 플래그를 사용하여 기본 포트를 변경할 수 있습니다.
사용할 수 있는 최신 버전이 있다면 현재 버전으로 업데이트할 수 있습니다. 출시 노트에서 최신 버전을 확인해 보세요.
현재 버전으로 업데이트하려면 다음을 실행합니다.
mtt start --force_update
앱을 중지하려면 다음을 실행합니다.
mtt stop
다른 명령어 목록을 보려면 다음을 사용합니다.
mtt --help
데이터베이스 백업 및 복원
ATS 데이터베이스를 백업하려면 앱을 중지하고 다음 명령어를 실행합니다. 이 명령어는 현재 데이터베이스를 홈 디렉터리에 mtt-backup.tar라는 TAR 파일로 백업합니다.
docker run --rm --mount source=mtt-data,target=/data -v ~:/out ubuntu bash -c "cd /data && tar cvf /out/mtt-backup.tar ."
복원하려면 앱을 시작하기 전에 다음 명령어를 실행합니다.
docker run --rm --mount source=mtt-data,target=/data -v ~:/out ubuntu bash -c "cd /data && tar xvf /out/mtt-backup.tar"
설정 마법사
처음 Android 테스트 스테이션을 설치하고 실행한 후 설정 마법사의 몇 가지 단계를 통해 사용자 환경에 맞도록 도구를 맞춤설정할 수 있습니다. 여기에서 변경한 사항은 나중에 Settings 페이지에서 다시 구성할 수 있습니다.
구성 백업 복원
다른 Android 테스트 스테이션 호스트에서 백업한 구성 파일이 있다면 Upload File 버튼을 클릭하여 파일을 업로드한 후 다른 호스트에서 수정한 구성 항목을 복사할 수 있습니다.
그림 1. 구성 백업 복원
기본 서비스 계정 설정
Android 테스트 스테이션에서 리소스에 액세스할 때 기본으로 사용하는 서비스 계정을 설정할 수 있습니다(예: Google Cloud Storage, Google Drive). 서비스 계정을 인증하려면 Upload Service Account Key를 클릭하고 서비스 계정의 JSON 키 파일을 선택합니다.
그림 2. 서비스 계정 설정
서비스 계정이 성공적으로 인증되면 페이지 오른쪽 상단에 계정 이메일 주소가 표시됩니다. 서비스 계정을 변경하려면 계정 이름을 클릭하고 현재의 기본 계정을 삭제한 후 새 서비스 계정 키를 업로드합니다.
그림 3. 서비스 계정 변경
구성 세트 가져오기
구성 세트는 관련 기기 작업, 빌드 채널을 포함하여 테스트 모음을 실행하기 위한 구성 번들입니다. 구성 세트는 특정 Google Cloud Storage(GCS) 버킷에서 호스팅됩니다 Google 계정으로 GCS 빌드 채널을 인증하면 사용할 수 있는 모든 구성 세트 목록이 표시됩니다.
테스트 스테이션 호스트에 추가할 구성 세트를 선택하고 Import Selected를 클릭합니다.
그림 4. 구성 세트 가져오기
Wi-Fi 설정 포함
일부 CTS 테스트는 기기를 Wi-Fi 핫스팟에 연결해야 합니다. Wi-Fi 네트워크를 선택하려면 Wi-Fi SSID 및 Wi-Fi PSK(선택사항)를 입력합니다.
그림 5. Wi-Fi 핫스팟 설정
설정 마법사를 완료하면 페이지가 새로고침되며 새로운 설정이 적용됩니다.
기기 연결
기기를 테스트에 사용하려면 USB 디버깅을 사용 설정해야 합니다. 디버깅을 사용 설정하려면 다음 단계를 따르세요.
개발자 옵션 및 디버깅 사용 설정 안내를 따릅니다.
맞춤 ADB 키로 미리 로드된 테스트 Android 빌드를 사용하려면 맞춤
.adb_key파일을~/.android/디렉터리에 넣습니다.이러한 빌드를 실행하는 기기가 플래시된 후에는 파일이 자동 로드되고 ADB로 전달되어 USB 디버깅을 자동으로 사용 설정합니다.
USB를 사용하여 기기를 호스트 시스템에 연결합니다.
웹 인터페이스를 새로고침하면 1분 이내에 기기가 Android 테스트 스테이션 Devices 탭에 표시됩니다. 이 탭에서 기기의 상태도 확인할 수 있습니다.
그림 6. 기기 연결
가능한 기기 상태는 다음과 같습니다.
- Available - 기기가 연결되었고 테스트를 실행할 준비가 되었습니다.
- Allocated - 기기가 연결되었고 현재 테스트를 실행 중입니다. 각 기기는 한 번에 하나의 테스트만 실행할 수 있으므로 기기에서 새 테스트를 실행하기 전에 현재 테스트를 완료해야 합니다.
테스트 실행
테스트 선택
Android 테스트 스테이션에는 미리 번들로 묶은 CTS 구성 세트가 함께 제공됩니다. 이러한 테스트 중 하나를 실행하려면 Test Suites 탭으로 이동하여 원하는 테스트의 Run test를 클릭합니다.
그림 7. 테스트 선택
새 테스트를 수정하거나 추가하려면 테스트 추가를 참고하세요.
테스트 실행 구성
이 특정 테스트를 실행하는 데 사용할 매개변수를 수정합니다. 대부분 매개변수는 선택된 테스트 구성에 정의된 값으로 미리 설정되어 있습니다.
이 단계는 기본값을 사용하여 완료할 수 있지만, 필요에 따라 Max Retry 및 Command와 같은 매개변수를 변경할 수 있습니다.
그림 8. 테스트 실행 구성
테스트 실행 매개변수는 다음과 같습니다.
- Name - 실행하려는 테스트 모음의 이름입니다.
- Run Count - 테스트 일정이 예약된 경우 이 테스트 실행이 실시되어야 하는 횟수입니다. 테스트 실행은 Trade Federation을 사용하여 예약하며, 여유 용량이 있다면 최대 20개의 테스트 실행이 동시에 실행됩니다.
- Max Retry - 하나 이상의 테스트가 실패했을 때 테스트 실행을 다시 시도할 최대 횟수입니다. 전체 CTS 실행의 경우 주로 4~6회 다시 시도하도록 이 값을 설정하여 실패가 자주 발생하는 테스트를 처리합니다.
- Queue Timeout - 테스트 실행이 Queued 상태로 너무 오래 남아 있으면 자동으로 취소됩니다. 여기에서 취소 전 대기하는 시간을 지정합니다. 기본값은 24시간입니다.
Command - 테스트 모음을 실행할 명령어입니다. 여기에 명령줄 인수를 추가로 입력할 수 있습니다. 예를 들어, 다음과 같이 하여 CTS 8.1의 특정 모듈을 실행합니다.
cts-suite -m ShortModuleNameRetry Command - 테스트 모음을 다시 시도하는 명령어입니다. 여기에서 명령줄 인수를 더 추가할 수 있습니다. 예를 들어, CTS 8.1의 특정 모듈만 다시 시도하려면 다음을 사용하면 됩니다.
cts --retry 0 -m ShortModuleName테스트를 다시 시도할 때 사용하는 인수는 초기 명령어에서 사용할 수 있는 인수와 다를 수 있으므로 공식 사이트에서 선택한 테스트 모음에 지원되는 매개변수를 확인하세요.
Previous Test Run - 이전 테스트 실행을 다시 실행하는 방법은 다음과 같습니다.
로컬 - 현재 호스트에서 실행을 시작했다면 테스트 실행 세부정보를 확인할 때 표시된 테스트 실행 ID를 입력합니다.
그림 9. 로컬에서 이전 테스트 실행
원격 - 다른 호스트에서 실행을 시작했다면 Remote를 선택하고 Upload Test Results File을 클릭한 후 로컬 저장소에서 파일을 선택하여 테스트 결과 파일을 업로드합니다.
그림 10. 원격으로 이전 테스트 실행
기기 선택
체크박스를 클릭하여 테스트 모음을 실행하는 데 할당할 기기를 선택합니다. 샤드 수는 선택한 기기 수와 일치하도록 자동으로 변경됩니다.
그림 11. 기기 선택
기기 일련번호가 아닌 속성별로 기기를 선택하려면 '기기 사양'을 수동으로 입력하면 됩니다. 예를 들어 제품 이름이 'bramble'인 기기를 3개 선택하려면 다음을 입력합니다.
product:bramble;product:bramble;product:bramble
지원되는 속성은 다음과 같습니다.
- build_id
- device_serial
- device_type
- hostname
- product
- product_variant
- sim_state
테스트 실행을 시작하려면 선택된 모든 기기가 Available 상태여야 하며 테스트 실행이 시작될 때 모두 Allocated 상태로 전환됩니다. 기기를 사용할 수 있을 때까지 기다리는 동안 테스트 실행은 Queued 상태입니다.
기기 작업 추가
기기 작업은 각 테스트 실행 전에 실행할 수 있는 스크립트입니다. 플래시 및 재부팅과 같은 일부 기기 작업이 이미 구성되어 있습니다. 새 기기 작업을 만들려면 새 기기 작업 만들기를 참고하세요.
그림 12. 기기 작업
테스트 실행에 기기 작업을 추가하려면 Add new action을 클릭하고 추가할 작업의 체크박스를 선택한 후 Add Action(s)을 클릭합니다. 기기 작업은 순차적으로 실행됩니다. 작업을 드래그하여 순서를 변경할 수 있습니다.
그림 13. 작업 재정렬
테스트 리소스 설정
테스트 리소스는 테스트 실행을 하는 데 필요한 파일입니다. 예를 들어, CTS를 실행하려면 android-cts*.zip 파일이 필요하며, 기기를 플래시하려면 빌드 이미지를 제공해야 합니다.
테스트 모음 ZIP 파일의 다운로드 URL은 기본적으로 파트너에게 제공되는 Google 드라이브 링크로 지정됩니다. browse를 클릭하여 다른 파일을 선택할 수 있습니다. 팝업 창에서 파일 다운로드 링크를 입력하거나, 인증된 빌드 채널의 파일을 사용하거나, 로컬 저장소에서 사용할 파일을 업로드할 수 있습니다.
그림 14. 테스트 리소스
아래는 웹 URL로 테스트 리소스를 선택할 수 있는 팝업 창입니다. 다운로드 URL 링크를 입력하고 Select 버튼을 클릭하여 선택을 확인하면 됩니다.
그림 15. 테스트 리소스 선택기 - 웹 URL
Google Drive, Google Cloud Storage(GCS) 또는 기타 채널에 리소스를 업로드했다면 특정 채널의 탭으로 이동하여 리소스를 선택할 수도 있습니다. 다음은 Google 드라이브에서 리소스를 선택하는 예입니다.
그림 16. 테스트 리소스 선택기 - Google Drive
Filename 입력란은 파일 선택뿐만 아니라 와일드 카드 문자도 지원됩니다. 관련 문서는 여기에서 확인할 수 있습니다.
그림 17. 테스트 리소스 선택기 - 와일드 카드 패턴 지원
Android 테스트 스테이션의 로컬 파일 저장소에서 파일을 선택할 수도 있습니다. 이 저장소에 파일을 업로드하거나 로컬 파일과 디렉터리를 직접 사용하면 됩니다.
그림 18. 테스트 리소스 선택기 - 로컬 파일 저장소
재실행 구성 추가
기본 실행이 완료되고 결과를 로드한 후 시작되는 재실행을 예약할 수 있지만 다른 기기나 작업, 리소스를 사용할 수 있습니다.
그림 19. 재실행 구성 추가
테스트 실행 시작
테스트 실행에 필요한 정보를 입력한 후 Start Test Run을 클릭합니다. 모든 정보가 유효하면 테스트 실행이 시작되고, 테스트 실행의 세부정보 및 진행 상황을 볼 수 있는 페이지로 리디렉션됩니다.
그림 20. 테스트 실행 시작
테스트 계획 만들기
테스트 계획은 테스트 실행을 주기적인 일정으로 만드는 데 사용됩니다. 예를 들어, 매일 오후 5시에 CTS 9.0을 실행합니다. 새 테스트 계획을 만들려면 Create a new test plan을 클릭합니다.
그림 21. 테스트 계획 만들기
테스트 계획 구성
테스트 계획의 이름을 입력하고 추가하려는 라벨을 지정합니다. 그런 다음 사용할 일정을 선택합니다.
- Manual - 사용자가 테스트 계획 목록 페이지에서 Run test plan을 클릭할 때만 테스트 계획에서 테스트 실행을 만듭니다.
- Periodic - 선택된 일정 주기에 따라 테스트 계획에서 자동으로 테스트 실행을 예약합니다. 예를 들어, 매일 오후 5시에 테스트가 실행되도록 예약할 수 있습니다.
- Custom - 테스트 계획은 입력된 크론 표현식에 따라 자동으로 테스트 실행을 예약합니다. 예를 들어 매일 오후 5시에 테스트 실행을 예약하려면 크론 표현식은
0 17 * * *가 됩니다.
그림 22. 테스트 계획 구성
테스트 모음 추가
테스트 계획에서 예약하고 싶은 테스트 모음을 추가하려면 + Add test run configuration을 클릭합니다. Name 드롭다운에서 테스트 모음을 선택하고 Next step을 클릭합니다. 그런 다음, 테스트를 실행할 기기를 선택하고 Add Configuration을 클릭합니다. 테스트 계획마다 여러 구성을 추가할 수 있습니다.
그림 23. 테스트 실행 구성
기기 작업 추가
각 테스트 실행 전에 실행할 기기 작업을 추가합니다. 자세한 내용은 기기 작업 추가를 참고하세요.
그림 24. 기기 작업 추가
테스트 리소스 설정
테스트 계획에 테스트 리소스를 추가하는 것은 개별 테스트 실행에 추가하는 것과 같습니다. 자세한 내용은 테스트 리소스 설정을 참고하세요.
그림 25. 테스트 리소스 설정
테스트 실행 보기
테스트 실행 목록
Test Runs 페이지에서 예약된 테스트 실행 목록을 확인합니다. View를 클릭하여 테스트 실행의 세부정보를 확인합니다.
필터 표시줄에 문자열을 입력하고 Enter 키를 눌러 목록을 필터링할 수도 있습니다. 필터를 여러 개 사용하려면 쉼표로 구분하면 됩니다. 필터는 Status와 Created 열을 제외하고 모든 열에 정확한 텍스트(하위 문자열 일치 없음)가 포함된 모든 행을 반환합니다.
필터가 비어있으면 모든 행을 반환합니다. 현재 값이 비어 있는 행은 필터링할 수 없습니다.
그림 26. 테스트 실행 목록
테스트 실행 세부정보
여기에서 테스트 실행의 세부정보(예: 상태, 로그, 결과)를 볼 수 있습니다.
그림 27. 테스트 실행 세부정보
테스트 실행 상태
Status 섹션에 테스트 실행의 진행 상황이 표시됩니다. 다운로드 진행률, 취소 이유 또는 오류 메시지와 같은 관련 메시지가 있다면 마찬가지로 여기에 표시됩니다.
그림 28. 테스트 실행 상태
테스트 실행 상태는 다음과 같습니다.
- Pending - 필요한 리소스를 다운로드하는 중입니다.
- Queued - 기기가 사용 가능 상태가 되면 테스트를 실행할 준비가 됩니다.
- Running - 할당된 기기에서 테스트가 실행 중입니다.
- Completed - 테스트가 완료되어 결과를 보고했습니다.
- Canceled - 사용자가 테스트를 취소했거나 사용 가능한 기기를 찾는 중에 타임아웃이 발생했습니다.
- Error - 오류가 발생하여 테스트를 실행할 수 없습니다.
테스트 실행 취소
테스트 실행이 완료되지 않았다면 Cancel을 클릭한 후 확인 대화상자에서 Yes를 클릭하여 취소할 수 있습니다. 또한, queue_timeout_seconds 입력란에 지정된 시간보다 오랫동안 Queued 상태가 지속되면 테스트 실행이 자동으로 취소됩니다. Running 상태에서 테스트 실행을 취소하면 변경사항이 적용되는 데 몇 분 정도 걸릴 수 있습니다.
그림 29. 테스트 실행 취소
테스트 실행 결과
테스트 실행이 완료되면 결과가 수집되어 표시됩니다. 각 실행의 화살표를 클릭하여 추가 세부정보를 볼 수 있습니다. View Output Files를 클릭하여 수집된 테스트 아티팩트(예: test_result.xml 및 test_result_failures.html)를 확인합니다.
그림 30. 테스트 실행 결과
Logs 탭에서 실시간 호스트 및 Tradefed 로그를 볼 수 있습니다.
그림 31. Logs 탭
개별 모듈의 결과는 Test Results 탭에 있습니다.
그림 32. Test Results 탭
Test Resources 탭에서 Open을 클릭하여 테스트 리소스로 사용된 파일을 다운로드할 수 있습니다.
그림 33. Test Resources 탭
create_time과 같은 테스트 실행 세부정보를 보려면 Config 탭으로 이동합니다.
그림 34. Config 탭
고급 기능
구성 파일 관리
Android 테스트 스테이션은 YAML로 작성된 구성 파일을 사용하여 테스트, 빌드 채널, 기기 작업과 같은 사전 정의된 옵션을 로드합니다. 아래는 일부 옵션의 구성 파일 예입니다.
// example_file.yaml
tests:
- id : android.cts.9_0.arm
name: CTS 9.0 (ARM)
test_resource_defs:
- name: android-cts.zip
default_download_url: https://dl.google.com/dl/android/cts/android-cts-9.0_r7-linux_x86-arm.zip
test_resource_type: TEST_PACKAGE
command: cts
env_vars:
- name: TF_PATH
value: ${TF_WORK_DIR}/android-cts/tools:${TF_WORK_DIR}/android-cts/testcases
- name: LD_LIBRARY_PATH
value: ${TF_WORK_DIR}/android-cts/lib:${TF_WORK_DIR}/android-cts/lib64
setup_scripts:
output_file_patterns:
- android-cts/logs/latest/.*
- android-cts/results/latest/.*\.html
- android-cts/results/latest/compatibility_result\..*
- android-cts/results/latest/logo.png
- android-cts/results/latest/test_result.xml
result_file: test_result.xml
java_properties:
- name: CTS_ROOT
value: ${TF_WORK_DIR}
context_file_dir: android-cts/results/
context_file_pattern: '[\d_\.]+\.zip'
retry_command_line: retry --retry 0
runner_sharding_args: --shard-count ${TF_SHARD_COUNT}
build_channels:
- id: google_drive
name: Google Drive
provider_name: Google Drive
device_actions:
- id: flash
name: Flash
test_resource_defs:
- name: bootloader.img
test_resource_type: DEVICE_IMAGE
- name: radio.img
test_resource_type: DEVICE_IMAGE
- name: img.zip
test_resource_type: DEVICE_IMAGE
tradefed_target_preparers:
- class_name: com.android.tradefed.targetprep.RunHostCommandTargetPreparer
option_values:
- name: work-dir
values:
- ${TF_WORK_DIR}
- name: host-setup-command
values:
- adb -s $SERIAL reboot-bootloader
- fastboot -s $SERIAL flash bootloader bootloader.img
- fastboot -s $SERIAL flash radio radio.img
- fastboot -s $SERIAL reboot-bootloader
- fastboot -s $SERIAL -w update img.zip
- adb -s $SERIAL wait-for-device
- name: host-cmd-timeout
values:
- 10m
Android 테스트 스테이션 인스턴스를 설정할 때 구성을 파일로 내보내기하여 다른 사람과 공유할 수 있습니다. 이렇게 하려면 Settings 페이지로 이동하여 오른쪽 상단의 Export를 클릭합니다.
그림 35. 구성 파일 관리
구성 파일이 다운로드되면 다른 사용자와 파일을 공유합니다. 파일을 공유한 사용자는 Import를 클릭하고 구성 파일을 선택하여 Android 테스트 스테이션 인스턴스에 구성 파일을 추가할 수 있습니다.
새 기기 작업 만들기
기기 작업은 기기 설정 절차를 자동화하는 데 사용됩니다. 작업은 각 테스트 실행 전에(재시도 포함) 테스트가 실행되는 각 기기에서 실행되는 스크립트입니다. 사용할 수 있는 기기 작업 목록을 보려면 Settings 페이지로 이동하여 Device Actions 탭을 클릭합니다. 재부팅 및 플래시와 같은 여러 기기 작업이 이미 구성되어 있습니다.
그림 36. Device Actions 탭
새 기기 작업 추가
New device action을 클릭합니다.
그림 37. New device action 버튼
이름과 설명을 입력합니다.
그림 38. 기기 작업 이름
Add Target Preparer를 클릭합니다.
Trade Federation 타겟 준비자 전체 이름(예:
com.android.tradefed.targetprep.RunHostCommandTargetPreparer)을 입력합니다.
그림 39. 타겟 준비자 추가
사용할 수 있는 타겟 준비자 목록은 com.android.tradefed.targetprep 참조에서 확인할 수 있습니다.
그림 40. 타겟 준비자 목록
타겟 준비자와 함께 사용할 수 있는 옵션을 추가합니다. 사용할 수 있는 옵션을 보려면 targetprep에서 AOSP의 각 타겟 준비자 소스 코드를 확인하세요.
그림 41. 작업 옵션 예
옵션을 추가하려면 Add Target Preparer Option을 클릭하고 필요한 값을 입력합니다.
그림 42. 작업 명령어 예
기기 작업을 실행하는 데 필요한 테스트 리소스를 정의합니다(예: 플래시용 빌드 이미지). 리소스 정의를 추가하려면 Add Test Resource를 클릭하고 필수 입력란을 작성합니다. 파일 위치를 알고 있다면 browse를 클릭하여 기본 다운로드 URL을 입력하면 됩니다. 타겟 준비자가 디렉터리를 테스트 리소스로 허용하면 Decompress를 선택합니다. 그런 다음 임시 작업 디렉터리 아래에 상대 Destination 디렉터리와 압축 해제할 File Names를 지정합니다. 파일 이름을 지정하지 않으면 테스트 리소스에서 모든 파일이 압축 해제됩니다.
그림 43. 작업 테스트 리소스
Update를 클릭합니다.
그림 44. 작업 변경사항 저장
테스트 관리
테스트 수정
저장된 테스트를 수정하려면 Tests 페이지로 이동하고 수정하려는 테스트 행에서 Edit을 클릭합니다. 테스트 구성을 변경한 후 Update를 클릭합니다.
그림 45. 테스트 수정
새 테스트 추가
새 테스트를 추가하려면 Tests 페이지로 이동하여 Create a New Test를 클릭합니다. 알맞은 정보를 입력하고 Create를 클릭합니다.
그림 46. 테스트 만들기
그림 47. 테스트 복사
호스트 구성 내보내기
호스트를 구성한 후 호스트 구성을 파일로 내보낼 수 있습니다. 이 파일을 다른 호스트에 업로드하여 저장된 구성을 복사할 수 있습니다.
호스트 구성을 내보내려면 Settings 페이지로 이동하여 오른쪽 상단 모서리에 있는 Export를 클릭합니다.
그림 48. 호스트 구성 내보내기
호스트 구성 파일을 가져오려면 Settings 페이지로 이동하여 오른쪽 상단에 있는 Import를 클릭합니다.
그림 49. 호스트 구성 가져오기
로컬 파일과 디렉터리 사용
버전 R11부터는 Android 테스트 스테이션에서 $HOME/.ats_storage 디렉터리의 파일에 자동으로 액세스할 수 있습니다. 파일을 디렉터리로 복사하거나 이동한 후 테스트 실행을 예약할 때 Local File 탭에서 선택할 수 있습니다.
cp /path/to/file $HOME/.ats_storage
그림 50. $HOME/.ats_storage 디렉터리에서 파일 선택
--mount_local_path 플래그를 사용하여 디렉터리를 추가로 로컬 파일 저장소에 마운트할 수 있습니다.
mtt start --mount_local_path=/path/to/dir1 --mount_local_path=/path/to/dir2:renamed_dir2
그림 51. 로컬 파일 저장소에 마운트된 추가 디렉터리
멀티 호스트 모드 사용 설정
멀티 호스트 모드에서는 사용자가 단일 ATS 컨트롤러 호스트를 사용하여 여러 ATS 작업자 호스트에서 기기와 테스트를 관리할 수 있습니다.
그림 52. 멀티 호스트 모드 아키텍처
ATS 컨트롤러를 시작하려면 다음 명령어를 사용합니다.
mtt start --operation_mode=ON_PREMISEhttp://${CONTROLLER_HOSTNAME}:8000에서 컨트롤러에 액세스할 수 있는지 확인합니다.worker를 시작하려면 다음 명령어를 사용합니다.
mtt start --control_server_url=http://CONTROLLER_HOSTNAME:8000 --operation_mode=ON_PREMISE
네트워크에서 호스트 간 통신을 허용하지 않으면 ATS worker에 대한 아래의 고급 설정 안내를 따라야 합니다.
SSH 터널을 사용하여 두 호스트를 연결합니다. 기본 서버 포트 및 파일 서버 포트를 위한 포트를 선택합니다(예: 9000, 9006).
ssh -L ATS_PORT:localhost:8000 -L FS_PORT:localhost:8006 CONTROLLER_HOSTNAMEATS를 구성하고 시작합니다.
DOCKER_GATEWAY_IP_ADDRESS=$(ip -4 addr show dev docker0 | grep -Eo 'inet [.0-9]+/' | grep -Eo '[.0-9]+')socat tcp-listen:ATS_PORT,bind="${DOCKER_GATEWAY_IP_ADDRESS}",reuseaddr,fork tcp-connect:127.0.0.1:ATS_PORT &socat tcp-listen:FS_PORT,bind="${DOCKER_GATEWAY_IP_ADDRESS}",reuseaddr,fork tcp-connect:127.0.0.1:FS_PORT &mtt start --control_server_url=http://${DOCKER_GATEWAY_IP_ADDRESS}:ATS_PORT \ --control_file_server_url=http://${DOCKER_GATEWAY_IP_ADDRESS}:FS_PORT \ --operation_mode=ON_PREMISE
파일 클리너
파일 클리너는 사용자 정의 구성을 토대로 파일을 정리하기 위해 매시간 실행되는 크론 작업입니다. ATS에는 테스트 실행 결과를 보관하고 임시 파일을 삭제하기 위한 두 가지 기본 구성이 있습니다. 이 가이드는 효율적으로 파일을 관리하기 위해 정책과 구성을 맞춤설정하는 방법을 설명합니다.
정책
정책은 파일 또는 디렉터리에서 실행되는 작업과 타겟 선택 기준을 정의합니다. 사용 가능한 작업은 표에 나와 있습니다.
| 작업 유형 | 매개변수 |
|---|---|
ARCHIVE | remove_file: true인 경우 보관처리 후 파일을 삭제합니다. |
DELETE |
기준은 파일 속성 및 시스템 정보를 토대로 합니다. 사용 가능한 기준은 표에 나와 있습니다.
| 기준 유형 | 설명 | 매개변수 |
|---|---|---|
LAST_MODIFIED_TIME | 마지막 수정 날짜 및 시간을 기준으로 파일을 필터링합니다. | ttl: 다양한 유형의 시간 표현이 지원됩니다(예: 10m, 2h, 7 days, 4w). 지원되는 형식은 pytimeparse를 참고하세요. |
LAST_ACCESS_TIME | 마지막 액세스 날짜 및 시간을 기준으로 파일을 필터링합니다. | LAST_MODIFIED_TIME과 동일합니다. |
NAME_MATCH | 정규 표현식을 사용하는 이름을 기준으로 파일을 필터링합니다. | pattern: 결과 zip 파일을 일치시키기 위한 정규식(예: [a-f0-9]{8}-([a-f0-9]{4}-){3}[a-f0-9]{12}\.zip)입니다. |
SYSTEM_AVAILABLE_SPACE | 시스템에서 사용 가능한 공간을 기준으로 작업을 트리거합니다. | threshold: 사용 가능한 공간이 기준점(예: 200(B), 200KB, 200MB, 200GB, 2TB.) 아래로 떨어지면 작업을 트리거합니다. |
그림 53. 새 파일 클리너 정책 추가
구성
구성은 하나 이상의 정책을 특정 디렉터리와 결합합니다. 특정 디렉터리 내 파일과 디렉터리는 정의된 정책에 따라 처리됩니다. 구성에 표시된 순서대로 정책이 적용됩니다.
모든 타겟 디렉터리는 /data 디렉터리 아래에 있어야 합니다. 구성에서 타겟 디렉터리를 logs로 지정하는 경우 /data/logs로 해석됩니다.
그림 54. 파일 클리너 구성 수정
초기화
Reset Settings를 클릭하면 파일 클리너 구성이 기본 상태로 복원됩니다. 이 작업을 실행하면 모든 맞춤 항목이 삭제됩니다.
그림 55. 파일 클리너 설정 초기화
지원
버그 신고
Android 테스트 스테이션에 참여해 주시면 도구 개발을 개선하는 데 도움이 됩니다. Google에서는 개발자 여러분의 의견을 기다리고 있습니다. 최신 버전에 관한 자세한 내용은 ATS 출시 노트를 참고하세요. 버그를 신고하거나 제안사항이 있다면 버그 신고를 제출하세요. 파트너는 파트너 채널을 통해 버그나 제안을 알려주시기 바랍니다.