개발자 기반 CTS

이 페이지에서는 개발자 기반 CTS(CTS-D) 사용 가이드라인을 대략적으로 설명합니다.

테스트 커버리지

CTS 및 CTS 인증 도구처럼 CTS-D는 다음 항목만 적용할 수 있습니다.

  • 특정 API 수준의 개발자 SDK(developer.android.com)에 설명된 모든 공개 API
  • 특정 API 수준의 Android 호환성 정의 문서(CDD)에 포함된 모든 MUST 요구사항

STRONGLY RECOMMENDED, SHOULD, MAY와 같은 MUST 이외의 요구사항은 선택사항이며 CTS를 사용하여 테스트할 수 없습니다.

모든 API와 CDD 요구사항은 특정 API 수준과 연결되어 있으므로 모든 CTS 테스트(CTS, CTS-D, CTS 인증 도구)는 연결된 API 또는 요구사항과 동일한 API 수준에 연결됩니다. 특정 API가 지원 중단되거나 변경되면 이에 상응하는 테스트도 지원 중단하거나 업데이트해야 합니다.

CTS 테스트 생성 규칙

  • 테스트는 동일한 객관적 결과를 일관되게 생성해야 합니다.
  • 테스트는 기기를 즉시 한 번 테스트하여 기기의 통과 또는 실패 여부를 판단해야 합니다.
  • 테스트 생성자는 테스트 결과에 영향을 미칠 수 있는 가능한 모든 요인을 삭제해야 합니다.
  • 기기에 특정 하드웨어 조건/환경/설정이 필요한 경우 이러한 설정은 커밋 메시지에 명확하게 정의해야 합니다. 설정 예 안내는 CTS 설정을 참고하세요.
  • 테스트는 한 번에 6시간 넘게 실행해서는 안 됩니다. 더 오래 실행해야 하는 경우 Google에서 검토할 수 있도록 테스트 제안서에 이유를 포함해 주세요.

다음은 앱 제한을 테스트하기 위한 테스트 조건 모음의 예입니다.

  • Wi-Fi가 안정적입니다(Wi-Fi를 사용하는 테스트의 경우).
  • 기기가 테스트 중 고정된 상태로 유지됩니다(테스트에 따라 다름).
  • 기기가 전원에서 분리되어 있고 배터리 잔량은 X퍼센트입니다.
  • CTS를 제외하고 실행 중인 앱이나 포그라운드 서비스, 백그라운드 서비스가 없습니다.
  • CTS를 실행하는 동안 화면이 꺼져 있습니다.
  • 기기가 isLowRamDevice가 아닙니다.
  • 절전/앱 제한이 맨 처음 상태에서 변경되지 않았습니다.

테스트 자격요건

Google에서는 기존 CTS나 CTS 인증 도구, CTS-D 테스트에서 테스트되지 않는 동작을 적용하는 새로운 테스트를 허용합니다. 테스트 커버리지 범위 밖 동작을 확인하는 모든 테스트는 거부됩니다.

CTS 제출 프로세스

  1. 테스트 제안서 작성: 앱 개발자는 Google Issue Tracker를 사용하여, 식별된 문제를 설명하고 확인을 위한 테스트를 제안하는 테스트 제안서를 제출합니다. 제안서에는 연결된 CDD 요구사항 ID가 포함되어야 합니다. Android팀에서 제안서를 검토합니다.
  2. CTS 테스트 개발: 제안서가 승인되면 제출자는 기본(AOSP/main) 브랜치에서 AOSP에 관한 CTS 테스트를 만듭니다. Android팀에서 코드를 검토합니다.
  3. 테스트 게시: AOSP/main에 CL을 제출한 후 최신 androidx-tests-dev 브랜치로 선택합니다. 이제 테스트가 공개적으로 제공됩니다.

CTS-D 테스트 작성 가이드라인

  • Java 코드 스타일 가이드를 따릅니다.
  • CTS 개발에 설명된 모든 단계를 따릅니다.
  • 적절한 테스트 계획에 테스트를 추가합니다.
    • include-filters를 사용하여 새 테스트를 CTS-D 테스트 계획(platform/cts/tools/cts-tradefed/res/config/cts-developer.xml)에 추가합니다.
    • exclude-filters를 사용하여 기본 CTS 테스트 계획(platform/cts/tools/cts-tradefed/res/config/cts-developer-exclude.xml)에서 새 테스트를 제외합니다.
  • build_error.log의 모든 errorprone 경고와 제안을 처리합니다.
  • 변경사항을 head로 리베이스합니다. 여기에는 cts-developer.xml 및 cts-developer-exclude.xml 테스트 계획이 포함됩니다.
  • Google 엔지니어링 담당자에게 문의하여 테스트 사례가 기존 CTS 모듈에 포함될 수 있는지 확인합니다. 포함될 수 없으면 새 모듈을 만드는 데 도움을 받을 수 있습니다.
  • 새 테스트 모듈이 만들어질 때마다 새 테스트 모듈 디렉터리에 OWNERS 파일을 만듭니다.
    • OWNERS 파일에는 협력하는 Google 테스트 소유자로부터 얻은 다음 정보가 포함되어야 합니다.
    • # Bug component: xxx
    • Google 테스트 소유자 LDAP
  • AndroidTest.xml에서 다음 매개변수를 지정합니다. 예는 샘플 파일(1, 2)을 참고하세요.
    • Instant_app 또는 not_instant_app
    • secondary_user 또는 not_secondary_user
    • all_foldable_states 또는 no_foldable_states
  • 올바른 minSDK를 지정하려면 <uses-sdk> 문서를 참고하세요.
  • 새로운 테스트 메서드나 클래스, 모듈을 확인할 때 새 테스트와 같은 방식으로 이를 CTS-D 테스트 계획에 추가하고 기본 CTS 테스트 계획에서 제외합니다.

CTS-D 테스트 실행

run cts --plan cts-developer를 사용하여 명령줄에서 CTS-D 테스트 계획을 실행합니다.

특정 테스트 사례를 실행하려면 run cts --include-filter "test_module_name test_name"을 사용합니다.

전체 CTS 실행에 관한 자세한 내용은 CTS 테스트 실행을 참고하세요.

수락 및 출시

테스트 요청이 제출되면 내부 팀에서 이를 검토하여 CDD 요구사항이나 문서화된 API 동작을 테스트하는지 확인합니다. 테스트에서 유효한 요구사항이나 동작을 확인하는 것으로 판단되면 팀에서는 이 테스트 사례를 Google 엔지니어에게 전달하여 추가 검토를 받습니다. 그러면 Google 엔지니어가 개발자에게 연락하여 CTS로 수락되기 위해 테스트를 개선할 수 있는 방법에 관한 의견을 제공합니다.

CTS 출시 일정에 관한 자세한 내용은 출시 일정 및 브랜치 정보를 참고하세요.