자동화된 테스트 인프라

Android 9에는 AOSP 일반 시스템 이미지(GSI)를 실행하는 파트너 기기에서 공급업체 테스트 모음(VTS), CTS 또는 기타 테스트를 자동으로 실행하기 위한 VTS 인프라가 포함되어 있습니다. 이전에는 이러한 테스트를 거의 수동으로 진행했지만, 새로운 VTS 테스트 인프라에서는 하루에 여러 번 여러 기기에서 실행할 수 있도록 자동화된 테스트를 지원합니다.

아키텍처

VTS의 자동화된 테스트 인프라에는 다음 아키텍처가 사용됩니다.

자동화된 테스트 아키텍처

그림 1. VTS의 자동화된 테스트 인프라 아키텍처

테스트가 시작되면 VTS의 자동화된 테스트 인프라에서 다음 작업을 실행합니다.

  1. 다른 위치에서 빌드 아티팩트와 테스트 리소스를 가져옵니다.
    • PAB(Partner Android Build). GSI, VTS 프레임워크 및 기타 빌드용입니다.
    • 로컬 파일 시스템, Google Cloud Storage 또는 기타 공급업체별 빌드 시스템. Google 클라우드에 빌드를 저장하지 않는 파트너용입니다.
  2. (기기의) 빌드 아티팩트와 (AOSP의) GSI를 연결된 기기로 플래시합니다.
  3. 로컬 TradeFed 또는 클라우드의 TradeFed를 사용하여 VTS 테스트를 실행합니다.
  4. 테스트 결과를 VTS 대시보드에 보고합니다.

이 프로세스는 테스트에 연결된 모든 기기의 동작을 전달하는 실험실 컴퓨터인 VTS HC(호스트 컨트롤러)에서 조정합니다. HC는 최신 빌드를 가져와서 기기에 플래시하고 로컬로 또는 커맨더를 통해 테스트를 호출합니다. 또한, 클라우드 스케줄러와 통신하고 HC에서 실행되는 TradeFed 인스턴스(또는 다른 하네스)와 스케줄러 간의 트래픽을 전달합니다. 호스트 컨트롤러에 관한 세부정보는 호스트 컨트롤러 아키텍처를 참고하세요.

리소스 제공자

자동화된 테스트에는 시스템 빌드, 테스트 파일 및 VTS 아티팩트와 같은 리소스가 필요합니다. 이러한 리소스를 소스에서 빌드할 수 있지만, 정기적으로 가장 최근 커밋에서 빌드한 다음 다운로드용 아티팩트를 게시하는 것이 더 쉽습니다.

파트너는 다음 위치에서 자동화 리소스에 액세스할 수 있습니다.

  • 파트너 Android 빌드. 프로그래매틱 액세스 권한이 계정별로 부여됩니다.
  • 로컬 파일 시스템(또는 이와 유사). Partner Android Build를 사용하지 않는 파트너용입니다.

리소스에는 이후에 기기를 플래시하는 데 사용할 수 있는 두 옵션의 빌드 제공자가 모두 포함되어 있습니다. 이러한 빌드 제공자는 로컬 임시 디렉터리에 빌드를 저장하는 단일 build_provider.py에서 확장된 것입니다.

파트너 Android 빌드

Android 8.1 이하 버전의 경우 Android 파트너는 Partner Android Build 웹사이트(https://partner.android.com/build)를 방문하여 계정으로 이동한 다음 사용자 인터페이스를 통해 최신 시스템 이미지를 가져와야 했습니다. 파트너가 이렇게 여러 작업이 필요한 느린 프로세스를 피할 수 있도록 Android 9에는 적절한 사용자 인증 정보를 제공하면 PAB에서 관련 리소스를 자동으로 다운로드하는 기능이 포함됩니다.

액세스 권한 설정

프로그래매틱 액세스에서는 Google API에서 OAuth2를 사용하여 필수 RPC에 액세스합니다. 표준 접근 방식을 사용하여 OAuth2 사용자 인증 정보를 생성할 경우 파트너는 Google에 클라이언트 ID/보안 비밀 쌍을 설정해야 합니다. 맨 처음 PartnerAndroidBuildClient에서 보안 비밀을 가리키게 되면 사용자가 Google 계정에 로그인할 수 있는 브라우저 창이 열리고 작업을 계속 진행하는 데 필요한 OAuth2 사용자 인증 정보가 생성됩니다. 사용자 인증 정보(액세스 토큰 및 갱신 토큰)는 로컬에 저장되기 때문에 파트너는 한 번만 로그인하면 됩니다.

URL 관련 POST 요청

PAB의 리소스 링크를 클릭하면 그 리소스에 필요한 데이터와 다음 항목이 포함된 POST 요청이 전송됩니다.

  • 빌드 ID, 빌드 타겟
  • 리소스 이름
  • 브랜치
  • 릴리스 후보 이름 및 그 후보가 내부 빌드인지 여부

POST 요청은 buildsvc RPC의 downloadBuildArtifact 메서드에서 수신하며 이 메서드는 리소스를 액세스할 수 있는 URL을 반환합니다.

  • Clockwork Companion APK 리소스의 URL은 PAB에서 호스팅되는 읽기 가능한 URL입니다(인증 보호된 상태로 적절한 OAuth2 사용자 인증 정보를 사용하여 액세스할 수 있음).
  • 다른 리소스의 URL은 내부 Android Build API에서 제공되는 비보호 상태의 긴 URL입니다(5분 후 만료됨).

URL 가져오기

교차 사이트 요청 위조를 방지하기 위해 buildsvc RPC는 다른 매개변수와 함께 POST되는 XSRF 토큰이 필요합니다. 이 토큰으로 프로세스의 보안이 강화되지만, 이제는 토큰(PAB 페이지의 자바스크립트에서만 사용할 수 있음)이 액세스에도 필요하므로 프로그래매틱 액세스가 훨씬 더 어려워집니다.

이 문제를 방지하기 위해 Android 9에서는 아티팩트 목록과 아티팩트 URL에 액세스할 때 예측 가능한 URL 이름을 사용하도록 APK뿐만 아니라 모든 파일의 URL 이름 지정 스키마를 재설계하였습니다. 이제 PAB는 파트너가 리소스를 다운로드할 수 있게 해주는 편리한 URL 형식을 사용합니다. URL 형식이 인식되기 때문에 HC 스크립트는 쉽게 APK를 다운로드할 수 있고, HC는 buildsvc RPC가 필요하지 않으므로 XSRF/쿠키 문제를 피할 수 있습니다.

로컬 파일 시스템

빌드 제공자는 아티팩트의 목록(또는 ZIP 파일)이 있는 디렉터리를 고려하여 디렉터리에 있는 항목에 따라 관련 이미지를 설정합니다. 개발자는 gsutil 도구를 사용하여 Google Cloud Storage에서 로컬 디렉터리로 파일을 복사할 수 있습니다.

빌드 플래시

최신 기기 이미지를 호스트로 다운로드한 후에는 이미지를 기기에 플래시해야 합니다. 이 작업은 빌드 제공자에서 저장한 임시 파일 경로에 따라 표준 adb 명령어와 fastboot 명령어, Python 하위 프로세스를 사용하여 진행됩니다.

지원되는 작업:

  • GSI만 플래시
  • 기본 시스템에서 개별 이미지를 플래시(예: fastboot flash boot boot.img)
  • 기본 시스템에서 모든 이미지를 플래시. 예:
    • fastboot flashall(내장 flashall 유틸리티 사용)
    • fastboot flash(한 번에 하나씩)

테스트 실행

Android 9에서 VTS의 자동화된 테스트 인프라는 TradeFed 테스트 하네스만 지원하지만, 향후 다른 하네스를 지원하도록 확장될 수 있습니다.

기기가 준비되면 다음 옵션 중 하나를 사용하여 테스트를 호출할 수 있습니다.

  • 로컬에서 TradeFed를 사용하는 경우 호스트 컨트롤러에서 test 명령어를 사용합니다. 그러면 VTS 테스트 계획의 이름(예: vts-selftest)을 가져와 테스트가 실행됩니다.
  • TradeFed Cluster(선택적으로 MTT에 연결됨)를 사용하는 경우 호스트 컨트롤러 콘솔에서 lease 명령어를 사용합니다. 그러면 이행되지 않은 테스트 실행이 검색됩니다.

TradeFedCluster를 사용하는 경우 TradeFed는 로컬에서 원격 관리자 형태로 실행됩니다. 그러지 않으면 테스트는 Python 하위 프로세스를 통해 호출됩니다.

결과 보고

테스트 결과는 VtsMultiDeviceTest에서 일부 VTS 대시보드 프로젝트로 자동 보고됩니다.