Gradle 관리 기기는 사용할 기기 (예: 'API 27의 Pixel 2 에뮬레이터')를 정의하는 데 사용할 수 있으며 기기 프로비저닝을 처리합니다.
대부분의 CI 시스템에는 Android Emulator를 처리하기 위한 서드 파티 플러그인('작업', '통합' 또는 '단계'라고도 함)이 함께 제공됩니다.
Firebase Test Lab과 같은 기기 팜에 계측 테스트를 위임합니다.
기기 팜은 높은 안정성을 위해 사용되며 에뮬레이터 또는 실제 기기에서 실행할 수 있습니다.
성능 회귀 테스트
앱 성능을 모니터링하려면 벤치마크 라이브러리를 사용하는 것이 좋습니다.
개발 중에 성능 테스트를 자동화하려면 일관되고 현실적인 테스트 결과를 보장하는 실제 기기가 필요합니다.
벤치마크를 실행하는 데 시간이 오래 걸릴 수 있으며, 특히 벤치마킹하는 코드 및 사용자 여정의 범위가 많은 경우 시간이 오래 걸릴 수 있습니다. 병합된 기능 또는 커밋마다 모든 벤치마크를 실행하는 대신 야간 빌드와 같이 정기적으로 예약된 유지보수 빌드의 일부로 실행하는 것이 좋습니다.
성능 모니터링
걸음 맞춤을 사용하여 성능 회귀를 모니터링할 수 있습니다. 단계 맞춤은 현재 빌드와 비교할 이전 빌드 결과의 롤링 기간을 정의합니다. 이 접근 방식은 여러 벤치마크 결과를 하나의 회귀별 측정항목으로 결합합니다. 회귀 테스트 중에 걸음 수 피팅을 적용하여 노이즈를 줄일 수 있습니다.
이렇게 하면 단일 빌드의 벤치마크 시간이 느려졌다가 다시 정규화될 때 발생할 수 있는 거짓양성 발생을 줄일 수 있습니다.
테스트 범위 회귀 검사
테스트 적용 범위는 사용자 및 사용자의 팀이 테스트에 변경사항을 충분히 포함하는지 판단하는 데 도움이 되는 측정항목입니다. 그러나 이것이 유일한 지표가 되어서는 안 됩니다. 일반적으로 커버리지가 기본 브랜치를 기준으로 하향 조정될 때 실패하거나 경고를 표시하는 회귀 검사를 설정하는 것이 일반적입니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(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-07-27(UTC)"],[],[],null,["# Types of CI automation\n\nThe following are some typical forms of automation that you might like to use in\nyour CI system.\n\nBasic jobs\n----------\n\n- **Build:** By building a project from scratch, you make sure that the new\n changes compile correctly and that all libraries and tools are compatible with\n each other.\n\n- **Lint or style checks:** This is an optional but recommended step. When you\n enforce style rules and perform [static analysis](/studio/write/lint), code reviews can be more\n concise and focused.\n\n- **[Local, or host-side tests](/training/testing/local-tests):** They run on the local machine that\n performs the build. On Android this is usually the JVM, so they're fast and\n reliable. They include Robolectric tests as well.\n\nInstrumented tests\n------------------\n\n[Tests that run on emulators or physical devices](/training/testing/instrumented-tests) require some provisioning,\nwaiting for devices to boot or be connected and other operations that add\ncomplexity.\n\nThere are multiple options to run instrumented tests on CI:\n\n- [Gradle Managed Devices](/studio/test/gradle-managed-devices) can be used to define the devices to use (for example \"Pixel 2 emulator on API 27\") and it handles device provisioning.\n- Most CI systems come with a third-party plugin (also called \"action\", \"integration\" or \"step\") to handle Android emulators.\n- Delegate instrumented tests to a device farm such as [Firebase Test Lab](https://firebase.google.com/docs/test-lab). Device farms are used for their high reliability and they can run on emulators or physical devices.\n\nPerformance regression tests\n----------------------------\n\nTo monitor app performance we recommend using the [benchmark libraries](/topic/performance/benchmarking/benchmarking-overview).\nAutomation of performance tests during development requires physical devices to\nensure consistent and realistic test results.\n\nRunning benchmarks can take a long time, especially when you have high coverage\nof code and user journeys that you are benchmarking. Instead of running all\nbenchmarks for every merged feature or commit, consider executing them as part\nof a regularly scheduled maintenance build, such as a nightly build.\n\n### Monitoring performance\n\nYou can monitor performance regressions using [step fitting](https://medium.com/androiddevelopers/fighting-regressions-with-benchmarks-in-ci-6ea9a14b5c71). Step\nfitting defines a rolling window of previous build results which you compare\nagainst the current build. This approach combines several benchmark results into\none regression-specific metric. You can apply step fitting to reduce noise\nduring regression testing.\n\nThis reduces the occurrence of false positives which can occur when benchmark\ntimes are slow for a single build and then normalize again.\n\nTest coverage regression checks\n-------------------------------\n\n[Test coverage](/studio/test/test-in-android-studio#view_test_coverage) is a metric that can help you and your team decide if tests\nsufficiently cover a change. However, it shouldn't be the only indicator. It is\ncommon practice to set up a regression check that fails or shows a warning when\nthe coverage goes down relative to the base branch.\n| **Note:** The coverage generated by an instrumentation test is different from that of a unit test as bigger tests typically make fewer assertions per line of tested code and their goal is different. Consider keeping two separate coverage metrics."]]
