Android 호환성 테스트 모음(CTS)은 수백만 개의 개별 테스트를 제공합니다.
CTS는 소프트웨어 개발 단계에서 자주 실행해야 하며 이러한 테스트를 실행하는 데 필요한 시간을 줄일 수 있습니다.
이 페이지에서는 테스트 실행 시간을 줄이는 데 사용할 수 있는 방법과 하드웨어 리소스를 프로세스에 최적화하는 방법을 설명합니다.
기기 샤딩
주기 시간을 줄이려면 여러 기기에서 CTS를 실행하는 것이 좋습니다(샤딩).
샤딩 사용 방법을 보려면 CTS 테스트 실행을 참고하세요.
Android 테스트 스테이션
Android 테스트 스테이션(ATS)을 사용하여 표준 Android 테스트 모음을 실행할 사용자 인터페이스를 채택합니다. 이 도구는 Trade Federation(TF)의 웹 인터페이스 역할을 합니다. 이를 통해 일련의 테스트 기기에서 최소한의 설정으로 CTS를 실행하고 연속적인 테스트 실행을 위한 일정을 수립할 수 있습니다.
Android 테스트 스테이션은 멀티 호스트 모드를 지원하므로 이를 사용하면 여러 ATS worker 호스트에서 기기와 테스트를 관리하는 데 단일 ATS 컨트롤러 호스트를 사용할 수 있습니다.
에뮬레이터 연속 실행
개발 단계에서 CTS를 연속적으로 실행하려면 Android Virtual Device(AVD)를 하드웨어 대신 사용할 수 있습니다. 테스트 실패 회귀를 조기에 식별할 수 있으므로 근본 원인을 분류하고 분석하는 데 필요한 시간이 많이 단축됩니다. 에뮬레이터의 여러 인스턴스는 샤딩에 사용할 수 있으며 Android 테스트 스테이션에서 연속 실행되도록 예약할 수 있습니다.
drawElements 품질 프로그램(dEQP)
drawElements 품질 프로그램(dEQP)은 Android CTS에 포함되어 있습니다. CtsDepqTestCases라는 이 프로그램은 Android 그래픽의 테스트 적용 범위에 중점을 둡니다. 이 모듈은 Android CTS에 포함된 모든 테스트 사례의 약 80%를 차지하며 총 실행 시간의 6%를 차지합니다.
Android 그래픽 드라이버는 Android 펌웨어(BSP)에 포함되고 개발 과정에서 크게 변경되지 않으므로 이 모듈은 전략적으로 실행할 수 있습니다. 예를 들어 소프트웨어를 개발하면서 2주마다(또는 그 미만으로) CTS를 실행하는 경우 펌웨어 업데이트 일정에 따라 이 모듈을 여러 주기 동안 제외할 수 있습니다.
한 가지 방법은 일련의 기기에서 CtsDeqpTestCases를 별도로 실행한 후 CTS 보고서를 제출하는 것입니다. 예를 들어 두 개의 다른 호스트에서 실행합니다.
멀티미디어 프레임워크와 그 드라이버(디코더, 인코더)는 Android 펌웨어(BSP)의 일부입니다. 이 모듈을 전략적으로 실행하고 펌웨어 업데이트 일정에 따라 여러 주기 동안 이러한 모듈을 제외할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-05-09(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-05-09(UTC)"],[],[],null,["# Optimize the CTS\n\nThe Android Compatibility Test Suite (CTS) provides millions of individual tests.\nWhile necessary to run CTS frequently during the software development phase,\nit's possible to shorten the time needed to run these tests.\n| **Important:** To approve a software build for final production, a full run of the CTS test suite is mandatory. The final production build can't contain modules that are either untested or that have failed testing. Partners are responsible for discovering failures early in development. All failures must be addressed before the final build.\n\nThis page describes methods you can use to reduce test execution time and how\nto optimize hardware resources into the process.\n\nSharding devices\n----------------\n\nTo reduce cycle time, consider running the CTS on multiple devices (sharding).\nTo see how sharding can be used, review\n[Run CTS tests](/docs/compatibility/cts/run).\n| **Tip:** For maximum efficiency, we recommend you connect at least six devices. Doing so can shorten total CTS execution time to less than 24 hours.\n\nAndroid test station\n--------------------\n\nUse the\n[Android Test Station (ATS)](/docs/core/tests/development/android-test-station/ats-user-guide)\nto employ a user interface to run standard Android test suites. This tool\nserves as a web interface for\n[Trade Federation (TF)](/docs/core/tests/tradefed),\nallowing you to run the CTS with minimal setup on a set of test devices as well\nas to establish a schedule to continuously run tests.\n\nThe Android test station supports\n[Multi-host mode](/docs/core/tests/development/android-test-station/ats-user-guide#multi-host-mode),\nwith which a single ATS controller host can be used to manage devices and tests\non multiple ATS worker hosts.\n| **Tip:** To run Android Test Station on an emulator, include the parameter `--use_host_adb`.\n\nEmulator continuous run\n-----------------------\n\nTo run the CTS continuously during the development phase,\n[Android Virtual Devices (AVD)](/docs/devices/automotive/start/avd/android_virtual_device)\ncan be used as a substitute for hardware. Regressions of test failures can be\nidentified early, saving much of the time needed to triage and analyze root\ncauses. Multiple instances of the emulator can be used for sharding and can be\nscheduled to run continuously with the Android test station.\n| **Important:** The emulator implementation may not be identical to the hardware and tests may not run or the results may be unreliable. Be sure to analyze which test modules produce different results compared to hardware before setting up the Emulator for continuous run.\n\ndrawElements Quality Program (dEQP)\n-----------------------------------\n\nThe\n[`drawElements` Quality Program (dEQP)](/docs/core/graphics/deqp-testing)\nis included in the Android CTS. Called `CtsDepqTestCases`, this program focuses\non test coverage of Android graphics. This module accounts for almost 80% of all\ntest cases in Android CTS and represents 6% of total execution time.\n\nSince the Android graphics drivers are part of Android firmware (BSP) and do not\nchange much over the course of development, you can run this module\nstrategically. For example, if you run CTS every two weeks (or less) during\nsoftware development, based on the firmware update schedule you can exclude this\nmodule for several cycles.\n| **Important:** To avoid discovering last minute issues during final certification, we highly recommend you run the module multiple times during development and to not skip this module completely.\n\nOne option is to run `CtsDeqpTestCases` separately on a set of devices, and to\nthen submit the CTS reports. For example, on two different hosts.\n\nHost 1:\n\n`cts-tf \u003e run cts --max-log-size 100 --shard-count 6 -o -m CtsDeqpTestCases`\n\nHost 2:\n\n`cts-tf \u003e run cts --max-log-size 100 --shard-count 6 -o --exclude-filter CtsDeqpTestCases`\n\nMedia test cases\n----------------\n\nMedia test cases verify multimedia services such as audio, video, and the\nmultimedia drivers. These multimedia test modules contribute the most to CTS\nexecution time. Delays can occur when:\n\n- Downloading media files or repeatedly playing media files during tests.\n- Retrying failed test cases.\n\nThe Android CTS contains these test modules:\n\n- `CtsMediaStressTestCases`\n- `CtsMediaPlayerTestCases`\n- `CtsMediaAudioTestCases`\n- `CtsVideoTestCases`\n- `CtsMediaDecoderTestCases`\n- `CtsMediaCodecTestCases`\n- `CtsMediaV2TestCases`\n\nConsider running some media tests locally or on a local server. For details, see\n[Run CTS media tests locally](/docs/compatibility/cts/run-locally).\n\nThe multimedia framework and its drivers (decoders and encoders) are part\nof the Android firmware (BSP). You can run this module strategically and exclude\nthese modules for several cycles, based on the firmware update schedule.\n| **Important:** To avoid discovering last minute issues during final certification, we highly recommend you run the multimedia modules multiple times during development and to not skip these modules completely."]]
