Android 테스트 스테이션은 Android 개발자와 테스트 엔지니어가 Android CTS(호환성 테스트 도구 모음 )와 같은 표준 Android 테스트 도구 모음을 실행하기 위한 사용자 인터페이스를 사용하는 데 사용할 수 있는 테스트 도구입니다. 이 도구는 TF(Trade Federation) 의 웹 인터페이스 역할을 하여 최소한의 설정으로 테스트 장치 세트에서 CTS를 쉽게 실행할 수 있을 뿐만 아니라 테스트를 지속적으로 실행하기 위한 일정을 설정할 수 있습니다.
Android 테스트 스테이션 설정
이 섹션에서는 Android 테스트 스테이션을 설치하고 설정하는 방법을 설명합니다.
Android 테스트 스테이션은 다음 위치의 소스 코드를 사용합니다.
- Android 테스트 스테이션 소스 코드
- TradeFed 클러스터 소스 코드
Android 테스트 스테이션 설치
실행하려는 테스트 제품군에 대한 하드웨어 및 소프트웨어 요구 사항을 따르십시오.
CTS에 대한 요구 사항은 source.android.com 에서 찾을 수 있습니다.
추가 하드웨어 요구 사항은 없지만 100GB의 여유 하드 드라이브 공간과 8GB 메모리가 있는 시스템을 사용하는 것이 좋습니다. 이는 테스트 제품군의 여러 실행에서 출력 파일을 저장하기에 충분합니다.
Android 테스트 스테이션을 설치하는 방법에는 두 가지가 있습니다.
- 설치 프로그램 을 실행합니다.
- 여러 프로그램과 리소스를 설치해야 하는 수동으로 설치 합니다.
설치 프로그램으로 설치
Ubuntu 18.04+에서 설치 프로그램은 Android 테스트 스테이션을 실행하는 데 필요한 모든 프로그램과 리소스를 설치하고 구성합니다.
설치 프로그램을 사용하려면:
설치 프로그램을 실행합니다.
curl https://storage.googleapis.com/android-mtt.appspot.com/prod/install.sh | bash
mtt version을 실행하여 설치된 Android Test Station CLI 버전을 확인합니다.
수동 설치
도커 설치
Linux 머신에 Docker Community Edition(CE)을 설치하기 위한 지침을 따르십시오.
권한 변경 사항을 적용하려면 터미널 창을 다시 시작하거나 로그아웃했다가 다시 로그인해야 할 수 있습니다.
파이썬 3.7 설치
Android 테스트 스테이션 CLI에는 Python 3.7이 필요합니다.
Ubuntu 16.04 또는 이전 버전의 경우 다음 중 하나를 수행하여 먼저 Python 3.7용 리포지토리를 추가해야 합니다.
다음 명령을 실행합니다.
sudo add-apt-repository ppa:deadsnakes/ppa
또는 소스에서 저장소를 빌드하고 설치하십시오.
Python 3.7을 설치하려면 다음 명령을 실행하십시오.
sudo apt-get updatesudo apt install python3.7 python3.7-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 테스트 스테이션을 처음 설치하고 실행하면 설정 마법사가 환경에 맞게 도구를 사용자 지정하는 데 도움이 되는 몇 가지 단계를 안내합니다. 여기에서 변경한 사항은 나중에 설정 페이지를 통해 재구성할 수 있습니다.
구성 백업 복원
다른 Android 테스트 스테이션 호스트에서 백업한 구성 파일 이 있는 경우 파일 업로드 버튼을 클릭하여 해당 호스트에서 수정된 구성을 복사하도록 파일을 업로드할 수 있습니다.
그림 1. 구성 백업 복원
기본 서비스 계정 설정
리소스(예: Google Cloud Storage, Google Drive)에 액세스할 때 Android 테스트 스테이션이 기본적으로 사용하는 서비스 계정 을 설정할 수 있습니다. 서비스 계정을 인증하려면 서비스 계정 키 업로드 를 클릭하고 서비스 계정의 JSON 키 파일을 선택하십시오.
그림 2. 서비스 계정 설정
서비스 계정이 성공적으로 인증되면 페이지 오른쪽 상단에 계정 이메일 주소가 나타납니다. 서비스 계정을 변경하려면 계정 이름을 클릭하고 현재 기본 계정을 제거하고 새 서비스 계정 키를 업로드합니다.
그림 3. 서비스 계정 변경
구성 세트 가져오기
구성 세트는 관련 기기 작업, 빌드 채널 등을 포함하여 테스트 스위트를 실행하기 위한 구성 번들입니다. 구성 세트는 특정 Google Cloud Storage(GCS) 버킷에서 호스팅됩니다. Google 계정으로 GCS 빌드 채널을 인증하면 사용 가능한 모든 구성 세트 목록이 표시됩니다.
테스트 스테이션 호스트에 추가하려는 구성 세트를 선택하고 선택 항목 가져오기 를 클릭합니다.
그림 4. 구성 세트 가져오기
Wi-Fi 설정 포함
일부 CTS 테스트에서는 기기가 Wi-Fi 핫스팟에 연결되어야 합니다. Wi-Fi 네트워크를 선택하려면 WiFi SSID 와 WiFi PSK (옵션)를 입력하십시오.
그림 5. Wi-Fi 핫스팟 설정
설정 마법사를 완료하면 새 설정이 적용된 페이지가 다시 로드됩니다.
장치 연결
테스트에 장치를 사용하려면 USB 디버깅을 활성화해야 합니다. 디버깅을 활성화하려면:
개발자 옵션 및 디버깅 활성화 의 지침을 따릅니다.
사용자 지정 ADB 키가 미리 로드된 테스트 Android 빌드를 사용하려는 경우 사용자 지정
.adb_key파일을~/.android/디렉터리에 넣습니다.파일은 자동으로 로드되고 ADB에 전달되어 해당 빌드를 실행하는 장치에 대해 장치가 플래시된 후 USB 디버깅을 자동으로 활성화합니다.
USB를 사용하여 장치를 호스트 시스템에 연결합니다.
장치는 웹 인터페이스를 새로 고친 후 1분 이내에 Android 테스트 스테이션 장치 탭에 나타납니다. 이 탭에서 장치의 상태를 볼 수도 있습니다.
그림 6. 장치 연결
다양한 장치 상태는 다음과 같습니다.
- 사용 가능 - 장치가 연결되어 테스트를 실행할 준비가 되었습니다.
- 할당됨 - 장치가 연결되어 있으며 현재 테스트를 실행 중입니다. 각 장치는 한 번에 하나의 테스트만 실행할 수 있으므로 장치는 새 테스트를 실행하기 전에 현재 테스트를 완료해야 합니다.
테스트 실행
테스트 선택
Android 테스트 스테이션은 사전 번들 CTS 구성 세트와 함께 제공됩니다. 이러한 테스트 중 하나를 실행하려면 테스트 스위트 탭으로 이동하여 원하는 테스트에 대해 테스트 실행 을 클릭하십시오.
그림 7. 테스트 선택
새 테스트를 편집하거나 추가하려면 테스트 추가 를 참조하십시오.
테스트 실행 구성
이 특정 테스트 실행에 사용할 매개변수를 편집하십시오. 대부분의 매개변수는 선택한 테스트 구성에 정의된 값으로 미리 채워져 있습니다.
이 단계는 기본값을 사용하여 완료할 수 있지만 Max Retry 및 Command 와 같은 매개변수를 필요에 맞게 변경할 수 있습니다.
그림 8. 테스트 실행 구성
테스트 실행 매개변수는 다음과 같습니다.
- 이름 - 실행하려는 테스트 스위트의 이름입니다.
- 실행 횟수 - 예약 시 이 테스트 실행을 실행해야 하는 횟수입니다. 테스트 실행은 Trade Federation 을 사용하여 예약되며 용량이 있는 경우 최대 20개의 테스트 실행을 병렬로 실행합니다.
- 최대 재시 도 - 하나 이상의 테스트가 실패한 경우 테스트 실행을 재시도하는 최대 횟수입니다. 이는 일반적으로 비정상적 테스트를 처리하기 위해 전체 CTS 실행에 대해 4~6회 재시도로 설정됩니다.
- 대기열 시간 초과 - 테스트 실행이 너무 오랫동안 대기 상태로 유지되면 자동으로 취소됩니다. 여기에서 취소하기 전에 대기할 시간을 지정합니다. 기본값은 24시간입니다.
명령 - 테스트 스위트를 실행하는 명령입니다. 여기에 추가 명령줄 인수를 입력할 수 있습니다. 예를 들어 다음을 사용하여 CTS 8.1에서 특정 모듈을 실행합니다.
cts-suite -m ShortModuleName재시도 명령 - 테스트 스위트를 재시도하는 명령입니다. 여기에 명령줄 인수를 추가할 수 있습니다. 예를 들어 CTS 8.1에서 특정 모듈만 재시도하려면 다음을 사용합니다.
cts --retry 0 -m ShortModuleName재시도 인수는 초기 명령에서 사용할 수 있는 인수와 다를 수 있으므로 선택한 테스트 스위트의 공식 사이트에서 지원되는 매개변수를 확인하십시오.
이전 테스트 실행 - 이전 테스트 실행을 다시 실행하려면:
로컬 - 현재 호스트에서 실행이 시작된 경우 테스트 실행의 세부 정보를 볼 때 표시되는 테스트 실행 ID를 입력합니다.
그림 9. 로컬 이전 테스트 실행
원격 - 실행이 다른 호스트에서 시작된 경우 원격 을 선택하고 테스트 결과 파일 업로드 를 클릭하고 로컬 저장소에서 파일을 선택하여 테스트 결과 파일을 업로드합니다.
그림 10. 원격 이전 테스트 실행
장치 선택
체크박스를 클릭하여 테스트 스위트를 실행하기 위해 할당할 장치를 선택합니다. 샤드 수는 선택한 장치 수와 일치하도록 자동으로 변경되어야 합니다.
그림 11. 장치 선택
장치 일련 번호가 아닌 다른 속성으로 장치를 선택하려면 "장치 사양"을 수동으로 입력할 수 있습니다. 예를 들어, 제품 이름이 "bramble"인 3개의 장치를 선택하려면 다음을 입력하십시오.
product:bramble;product:bramble;product:bramble
지원되는 속성은 다음과 같습니다.
- build_id
- device_serial
- 기기 종류
- 호스트 이름
- 제품
- product_variant
- sim_state
테스트 실행을 실행하려면 선택한 모든 장치가 사용 가능 상태여야 하며 테스트 실행이 실행되면 모두 할당됨 상태로 전환됩니다. 테스트 실행은 장치가 사용 가능해질 때까지 기다리는 동안 대기 상태입니다.
장치 작업 추가
장치 작업은 각 테스트 실행 전에 실행할 수 있는 스크립트입니다. 깜박임 및 재부팅과 같은 일부 장치 작업은 이미 구성되어 있습니다. 새 장치 작업을 만들려면 새 장치 작업 만들기 를 참조하십시오.
그림 12. 장치 작업
테스트 실행에 장치 작업을 추가하려면 새 작업 추가 를 클릭하고 추가할 작업의 확인란을 선택한 다음 작업 추가 를 클릭 합니다 . 장치 작업은 순차적으로 수행됩니다. 드래그하여 작업을 재정렬할 수 있습니다.
그림 13. 작업 재정렬
테스트 리소스 설정
테스트 리소스는 테스트 실행을 실행하는 데 필요한 파일입니다. 예를 들어 CTS를 실행하려면 android-cts*.zip 파일이 필요하고 기기를 플래싱하려면 빌드 이미지를 제공해야 합니다.
테스트 제품군 zip 파일의 다운로드 URL은 파트너에게 제공된 Google 드라이브 링크로 기본 설정되어야 합니다. 찾아보기 를 클릭하여 다른 파일을 선택할 수 있습니다. 팝업 창에서 파일 다운로드 링크를 입력하거나, 인증된 빌드 채널의 파일을 사용하거나, 로컬 저장소에서 사용할 파일을 업로드할 수 있습니다.
그림 14. 테스트 리소스
아래는 웹 URL로 테스트 리소스를 선택하는 팝업창입니다. 다운로드 URL 링크를 입력하고 선택 버튼을 클릭하여 선택을 확인하면 됩니다.
그림 15. 테스트 리소스 선택기 - 웹 URL
Google Grive, Google Cloud Storage(GCS) 또는 기타 채널에 리소스를 업로드한 경우 특정 채널의 탭으로 이동하여 리소스를 선택할 수도 있습니다. 다음은 Google 드라이브에서 리소스를 선택하는 예입니다.
그림 16. 테스트 리소스 선택기 - Google 드라이브
파일을 선택하는 것 외에도 파일 이름 필드에서 와일드카드 문자도 지원됩니다. 문서는 여기 에서 찾을 수 있습니다.
그림 17. 테스트 리소스 선택기 - 와일드카드 패턴 지원
Android 테스트 스테이션의 로컬 파일 저장소에서 파일을 선택할 수도 있습니다. 이 저장소에 파일을 업로드하거나 로컬 파일 및 디렉터리를 직접 사용할 수 있습니다 .
그림 18. 테스트 리소스 선택기 - 로컬 파일 저장소
재실행 구성 추가
기본 실행이 완료된 후 시작되는 재실행을 예약하고 결과를 로드할 수 있지만 다른 장치, 작업 또는 리소스를 사용할 수 있습니다.
그림 19. 재실행 구성 추가
테스트 실행 시작
테스트 실행에 필요한 정보를 입력한 후 테스트 실행 시작 을 클릭합니다. 모든 정보가 유효하면 테스트 실행이 시작되고 테스트 실행의 세부 정보와 진행 상황을 볼 수 있는 페이지로 리디렉션됩니다.
그림 20. 테스트 실행 시작
테스트 계획 만들기
테스트 계획은 정기적인 일정에 따라 테스트 실행을 생성하는 데 사용됩니다. 예를 들어 매일 오후 5시에 CTS 9.0을 실행합니다. 새 테스트 계획을 작성하려면 새 테스트 계획 작성 을 클릭하십시오.
그림 21. 테스트 계획 작성
테스트 계획 구성
테스트 계획의 이름과 추가하려는 레이블을 입력합니다. 그런 다음 사용할 일정을 선택합니다.
- 수동 - 테스트 계획은 사용자가 테스트 계획 목록 페이지에서 테스트 계획 실행 을 클릭할 때만 테스트 실행을 생성합니다.
- 주기적 - 테스트 계획은 선택한 주기적 일정에 따라 테스트 실행을 자동으로 예약합니다. 예를 들어 매일 오후 5시에 테스트 실행을 예약합니다.
- 사용자 지정 - 테스트 계획은 입력한 cron 표현식 을 기반으로 테스트 실행을 자동으로 예약합니다. 예를 들어 매일 오후 5시에 테스트 실행을 예약하려면 cron 표현식은
0 17 * * *입니다.
그림 22. 테스트 계획 구성
테스트 스위트 추가
+ 테스트 실행 구성 추가 를 클릭하여 테스트 계획에 따라 예약하려는 테스트 스위트를 추가합니다. 이름 드롭다운에서 테스트 스위트를 선택하고 다음 단계 를 클릭합니다. 그런 다음 테스트를 실행할 장치를 선택하고 구성 추가 를 클릭합니다. 각 테스트 계획에 대해 여러 구성을 추가할 수 있습니다.
그림 23. 테스트 실행 구성
장치 작업 추가
각 테스트 실행 전에 실행할 장치 작업을 추가합니다. 자세한 내용은 장치 작업 추가 를 참조하십시오.
그림 24. 장치 작업 추가
테스트 리소스 설정
테스트 계획에 테스트 리소스를 추가하는 것은 개별 테스트 실행에 추가하는 것과 같습니다. 자세한 내용은 테스트 리소스 설정 을 참조하세요.
그림 25. 테스트 리소스 설정
테스트 실행 보기
테스트 실행 목록
테스트 실행 페이지에서 예약된 테스트 실행 목록을 봅니다. 테스트 실행에 대한 자세한 내용을 보려면 보기 를 클릭하십시오.
필터 표시줄에 문자열을 입력하고 Enter 키를 눌러 목록을 필터링할 수도 있습니다. 여러 필터를 쉼표로 구분하여 사용할 수 있습니다. 필터는 Status 및 Created 를 제외하고 모든 열에서 정확한 텍스트(하위 문자열 일치 없음)를 포함하는 모든 행을 반환합니다.
빈 필터는 모든 행을 반환합니다. 현재 값이 비어 있는 행을 필터링할 수 있는 방법은 없습니다.
그림 26. 테스트 실행 목록
테스트 실행 세부 정보
여기에서 상태, 로그 및 결과와 같은 테스트 실행의 세부 정보를 볼 수 있습니다.
그림 27. 테스트 실행 세부 정보
테스트 실행 상태
테스트 실행의 진행 상황은 상태 섹션에 표시됩니다. 다운로드 진행, 취소 사유, 오류 메시지 등 관련 메시지가 있는 경우 여기에도 표시됩니다.
그림 28. 테스트 실행 상태
테스트 실행 상태는 다음과 같습니다.
- 보류 중 - 필수 리소스를 다운로드 중입니다.
- 대기 중 - 장치를 사용할 수 있게 되면 테스트를 실행할 준비가 된 것입니다.
- 실행 중 - 테스트가 할당된 장치에서 실행 중입니다.
- 완료됨 - 테스트가 완료되어 결과를 보고했습니다.
- 취소됨 - 사용자가 테스트를 취소했거나 사용 가능한 장치를 찾는 동안 시간이 초과되었습니다.
- 오류 - 테스트 실행을 방해하는 오류가 발생했습니다.
테스트 실행 취소
테스트 실행이 완료되지 않은 경우 취소를 클릭한 다음 확인 대화 상자에서 예 를 클릭하여 취소 할 수 있습니다. 테스트 실행은 queue_timeout_seconds 필드보다 오래 대기 상태로 유지되는 경우에도 자동으로 취소됩니다. 실행 중 상태에서 테스트 실행을 취소하면 적용되는 데 몇 분 정도 걸릴 수 있습니다.
그림 29. 테스트 실행 취소
테스트 실행 결과
테스트 실행이 완료되면 결과가 수집되고 표시됩니다. 각 실행에 대한 화살표를 클릭하면 추가 세부 정보를 볼 수 있습니다. 출력 파일 보기 를 클릭하여 test_result.xml 및 test_result_failures.html 과 같이 수집된 테스트 아티팩트를 확인하십시오.
그림 30. 테스트 실행 결과
로그 탭에서 라이브 호스트 및 Tradefed 로그를 볼 수 있습니다.
그림 31. 로그 탭
개별 모듈에 대한 결과는 테스트 결과 탭에 있습니다.
그림 32. 테스트 결과 탭
테스트 리소스 탭에서 열기 를 클릭하면 테스트 리소스로 사용되는 파일을 다운로드할 수 있습니다.
그림 33. 테스트 리소스 탭
create_time 과 같은 테스트 실행의 세부 정보를 보려면 구성 탭으로 이동하십시오.
그림 34. 구성 탭
고급 기능
구성 파일 관리
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 테스트 스테이션 인스턴스를 설정할 때 구성을 파일로 내보내 다른 사용자와 구성을 공유할 수 있습니다. 이렇게 하려면 설정 페이지로 이동하여 오른쪽 상단에서 내보내기 를 클릭합니다.
그림 35. 구성 파일 관리
구성 파일을 다운로드한 후 다른 사용자와 파일을 공유하십시오. 가져오기 를 클릭하고 구성 파일을 선택하여 구성 파일을 Android 테스트 스테이션 인스턴스에 추가할 수 있습니다.
새 장치 작업 만들기
장치 작업은 장치 설정 프로세스를 자동화하는 데 사용됩니다. 작업은 재시도 전을 포함하여 각 테스트 실행 전에 테스트가 실행 중인 각 장치에서 실행되는 스크립트입니다. 사용 가능한 장치 작업 목록을 보려면 설정 페이지로 이동하여 장치 작업 탭을 클릭하십시오. 재부팅 및 깜박임과 같은 여러 장치 작업이 이미 구성되어 있습니다.
그림 36. 장치 작업 탭
새 장치 작업 추가
새 장치 작업 을 클릭합니다.
그림 37. 새 장치 작업 버튼
이름과 설명을 입력합니다.
그림 38. 장치 작업 이름
대상 준비자 추가 를 클릭합니다.
Trade Federation Target Preparer 전체 클래스 이름을 입력하십시오(예:
com.android.tradefed.targetprep.RunHostCommandTargetPreparer).
그림 39. 대상 준비자 추가
사용 가능한 대상 준비자 목록은 com.android.tradefed.targetprep 참조에서 찾을 수 있습니다.
그림 40. 대상 준비자 목록
대상 준비자와 함께 사용할 옵션을 추가합니다. 사용 가능한 옵션을 보려면 AOSP의 각 대상 준비자에 대한 소스 코드의 targetprep 을 확인하세요.
그림 41. 작업 옵션 예
옵션을 추가하려면 대상 준비자 옵션 추가 를 클릭하고 필요한 값을 입력합니다.
그림 42. 작업 명령 예
플래시를 위한 빌드 이미지와 같은 장치 작업을 실행하는 데 필요한 테스트 리소스를 정의합니다. 리소스 정의를 추가하려면 테스트 리소스 추가 를 클릭하고 필수 필드를 채우십시오. 파일의 위치를 알고 있는 경우 찾아보기 를 클릭하여 기본 다운로드 URL을 제공할 수 있습니다. 대상 준비자가 디렉터리를 테스트 리소스로 수락하는 경우 압축 해제 를 선택합니다. 그런 다음 임시 작업 디렉터리 아래에 상대 대상 디렉터리와 압축을 풀 파일 이름 을 지정합니다. 파일 이름을 지정하지 않으면 모든 파일이 테스트 리소스에서 압축 해제됩니다.
그림 43. 작업 테스트 리소스
업데이트 를 클릭합니다.
그림 44. 작업 저장 변경 사항
테스트 관리
테스트 편집
저장된 테스트를 편집하려면 테스트 페이지로 이동하여 수정하려는 테스트 행에서 편집 을 클릭합니다. 테스트 구성을 변경한 후 업데이트 를 클릭합니다.
그림 45. 테스트 편집
새 테스트 추가
새 테스트를 추가하려면 테스트 페이지로 이동하여 새 테스트 만들기 를 클릭합니다. 적절한 정보를 입력하고 만들기 를 클릭합니다.
그림 46. 테스트 만들기
그림 47. 테스트 복사
호스트 구성 내보내기
호스트를 구성한 후 호스트의 구성을 파일로 내보낼 수 있습니다. 이 파일을 다른 호스트에 업로드하여 저장된 구성을 복사할 수 있습니다.
호스트 구성을 내보내려면 설정 페이지로 이동하여 오른쪽 상단에서 내보내기 를 클릭합니다.
그림 48. 호스트 구성 내보내기
호스트 구성 파일을 가져오려면 설정 페이지로 이동하여 오른쪽 상단에서 가져오기 를 클릭합니다.
그림 49. 호스트 구성 가져오기
로컬 파일 및 디렉토리 사용
버전 R11부터 $HOME/.ats_storage 디렉토리의 파일은 Android 테스트 스테이션에서 자동으로 액세스할 수 있습니다. 파일을 해당 디렉토리로 복사하거나 이동한 다음 테스트 실행을 예약할 때 로컬 파일 탭에서 파일을 선택할 수 있습니다.
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:8000에서 컨트롤러에 액세스할 수 있는지 확인하십시오.
작업자를 시작하려면 다음 명령을 사용하십시오.
mtt start --control_server_url=http://controller.com:8000 --operation_mode=ON_PREMISE
네트워크에서 호스트가 서로 통신하는 것을 허용하지 않는 경우 ATS 작업자에 대한 아래의 고급 설정 지침을 따라야 합니다.
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=${DOCKER_GATEWAY_IP_ADDRESS}:ATS_PORT \ --control_file_server_url=${DOCKER_GATEWAY_IP_ADDRESS}:FS_PORT \ --operation_mode=ON_PREMISE
지원하다
버그 보고
Android Test Station에 대한 귀하의 기여는 도구 개발을 개선하는 데 도움이 되며 귀하의 의견을 기다립니다! 최신 릴리스에 대한 자세한 내용은 ATS 릴리스 정보 를 참조하십시오. 버그를 보고하거나 제안을 하려면 버그 보고서 를 제출하세요. 파트너는 파트너 채널을 통해 버그 또는 제안 사항을 보고해야 합니다.