개발자 기반 CTS

이 페이지에서는 개발자 기반 CTS(CTS-D)에 대한 사용 지침을 간략하게 설명합니다.

테스트 커버리지

CTS 및 CTS Verifier와 같은 CTS-D는 다음만 시행할 수 있습니다.

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

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

모든 API 및 CDD 요구 사항은 특정 API 수준에 연결되어 있으므로 모든 CTS 테스트(CTS, CTS-D 및 CTS 검증 도구)는 연결된 API 또는 요구 사항과 동일한 API 수준에 연결됩니다. 특정 API가 더 이상 사용되지 않거나 변경된 경우 해당 테스트는 더 이상 사용되지 않거나 업데이트되어야 합니다.

CTS 테스트 생성 규칙

  • 테스트는 일관되게 동일한 객관적인 결과를 생성해야 합니다.
  • 테스트는 장치를 즉시 한 번 테스트하여 장치의 통과 또는 실패 여부를 결정해야 합니다.
  • 테스트 작성자는 테스트 결과에 영향을 줄 수 있는 모든 가능한 요소를 제거해야 합니다.
  • 장치에 특정 하드웨어 조건/환경/설정이 필요한 경우 해당 설정은 커밋 메시지에 명확하게 정의되어야 합니다. 설정 지침의 예는 CTS 설정 을 참조하십시오.
  • 테스트는 한 번에 6시간 이상 실행하면 안 됩니다. 더 오래 실행해야 하는 경우 테스트 제안에 이유를 포함하여 검토할 수 있도록 하십시오.

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

  • Wi-Fi가 안정적입니다(Wi-Fi에 의존하는 테스트의 경우).
  • 장치는 테스트 중에 고정된 상태로 유지됩니다(테스트에 따라 다름).
  • 배터리 잔량이 X퍼센트인 모든 전원에서 장치의 플러그가 뽑혀 있습니다.
  • CTS를 제외하고 실행 중인 앱, 포그라운드 서비스 또는 백그라운드 서비스가 없습니다.
  • CTS를 실행하는 동안 화면이 꺼집니다.
  • 장치는 isLowRamDevice 가 아닙니다.
  • 배터리 세이버/앱 제한은 "즉시 사용 가능한" 상태에서 변경되지 않았습니다.

시험 자격

기존 CTS, CTS 인증 도구 또는 CTS-D 테스트에서 테스트되지 않은 동작을 시행하는 새로운 테스트를 허용합니다. 테스트 범위를 벗어난 동작을 확인하는 모든 테스트는 거부됩니다.

CTS 제출 프로세스

  1. 테스트 제안서 작성: 앱 개발자는 Google Issue Tracker 를 사용하여 식별된 문제를 설명하고 이를 확인하기 위한 테스트를 제안하는 테스트 제안서를 제출합니다. 제안서에는 관련 CDD 요구 사항 ID 가 포함되어야 합니다. Android 팀이 제안을 검토합니다.
  2. CTS 테스트 개발: 제안서가 승인된 후 제출자는 기본(AOSP/마스터) 분기의 AOSP에 대한 CTS 테스트를 만듭니다. Android 팀이 코드를 검토합니다.
  3. 테스트 게시: AOSP/master 에 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 .
  • errorprone 에서 오류가 발생하기 쉬운 모든 경고 및 제안을 build_error.log 합니다.
  • 변경 사항을 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 출시 일정에 대한 자세한 내용은 출시 일정 및 분기 정보 를 참조하세요.