개발자 기반 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 제출 프로세스

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

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

자바 코드 스타일 가이드를 따릅니다.
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 출시 일정에 관한 자세한 내용은 출시 일정 및 브랜치 정보를 참고하세요.