2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
TF 테스트 수명 주기
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Trade Federation을 사용하여 실행된 테스트의 수명 주기는 이전에 정의된 인터페이스를 중심으로 설계된 4가지 개별 단계로 구성됩니다.
정의된 인터페이스
- 빌드 제공업체: 테스트에 빌드를 제공하고 필요한 경우 적절한 파일을 다운로드합니다.
- 타겟 준비자: 테스트 환경을 준비하며, 소프트웨어 설치 및 기기 설정을 포함할 수 있습니다.
- 테스트: 테스트를 실행하고 테스트 결과를 수집합니다. 이는 JUnit 테스트일 수 있지만 IRemoteTest 인터페이스는 Trade Federation 환경에서 원활히 작동하도록 구체적으로 설계되었습니다.
- 테스트 호출 리스너(결과 보고): 테스트 결과를 수신 대기합니다. 보통 테스트 결과를 저장소로 전달하거나 테스트 실행기에 표시하는 데 목적이 있습니다.
TF의 근본적인 테스트 항목은 구성(config)입니다. config는 테스트의 수명 주기 구성 요소를 선언하는 XML 파일입니다.
이러한 테스트 수명 주기의 구분은 재사용이 가능하도록 하는 데 의도가 있습니다. 개발자는 이 설계를 사용하여 테스트를 1회 생성할 수 있으며 이어서 통합자는 여러 구성을 생성하여 이 테스트를 여러 환경에서 실행할 수 있습니다. 예를 들면 로컬 머신에서 테스트를 실행하고 결과를 stdout에 덤프하는 구성을 생성할 수 있습니다. 그런 다음에는 같은 테스트를 실행하지만 다른 테스트 호출 리스너를 사용하여 테스트 결과를 데이터베이스에 저장하는 두 번째 구성을 생성할 수 있습니다. 세 번째 구성은 어딘가의 테스트 실험실에서 이 테스트를 지속적으로 실행하도록 설계될 수 있습니다.
구성과 테스트 실행기에 의해 제공된 명령줄 인수가 명령어로 알려져 있다는 사실을 기억하면 편리합니다. TF가 명령어를 ITestDevice와 페어링하고 실행하면 후속 객체는 호출이 됩니다.
간단히 말해 호출은 전체 수명 주기를 아우르는 온전한 TF 테스트 실행을 포괄합니다.
추가 구성 요소
- 기기 복구: 손실된 기기 통신 복구를 위한 메커니즘입니다.
- 로거: tradefed 로깅 데이터를 수집합니다.
단계별 출력 및 오류
호출의 각 단계는 순차적으로 실행되고 특정 목표가 있습니다. 이 섹션에서는 각 단계의 일반적인 출력과 오류를 설명합니다.
빌드 제공업체
이 단계에서는 테스트를 설정하고 실행하는 데 필요한 모든 파일 참조가 포함된 IBuildInfo 객체를 만들고 출력합니다.
이 단계에서 가장 일반적인 오류는 요청한 파일을 다운로드하거나 찾을 수 없는 것입니다.
여기에서 오류가 발생하면 오류가 직접 보고되고 테스트가 실행되지 않습니다.
타겟 준비
테스트 중인 타겟에 필요한 상태를 설정하는 단계입니다. 이 단계에서는 지정된 테스트 호출에 필요한 기기 또는 호스트 설정을 변경할 수 있습니다.
보통 이 단계의 일반적인 오류는 기기를 특정 상태(예: 플래싱 실패)로 설정할 수 없거나 설정에 필요한 파일을 찾을 수 없는 것입니다.
여기에서 오류가 발생하면 타겟 정리가 실행되고 오류가 보고되며 테스트가 실행되지 않습니다.
테스트
이전에 준비된 타겟에서 요청된 테스트를 실행하고 테스트 실행 결과를 모두 보고하는 단계입니다.
보통 이 단계의 일반적인 오류는 테스트 중인 타겟을 사용할 수 없거나 일부 오류로 인해 테스트가 부분적으로 실행되는 것입니다. 이러한 오류는 단일 테스트 사례의 실패와 달리 테스트 실행 자체에 영향을 미치는 인프라 문제입니다.
여기에서 오류가 발생하면 테스트 실행이 중지되고 타겟 정리가 실행되며 오류가 보고되고 부분적 결과를 얻습니다.
결과 보고
구성된 서비스(예: 서버 및 로컬 파일)에 결과와 오류를 보고하는 단계입니다.
개별 결과 보고자에는 오류가 있을 수 있지만 보고자는 서로 격리되어 있습니다(한 보고자가 다른 보고자의 오류를 보지 못함). 이러한 오류는 개별 보고자의 자체 결과 보고에만 영향을 미치며 로그에서 오류를 확인할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# TF test lifecycle\n\nThe lifecycle of a test executed using Trade Federation is composed of four separate stages,\ndesigned around formally defined interfaces.\n\nDefined interfaces\n------------------\n\n- [Build Provider](/reference/tradefed/com/android/tradefed/build/IBuildProvider): Provides a build to test, downloading appropriate files if necessary.\n- [Target Preparer](/reference/tradefed/com/android/tradefed/targetprep/ITargetPreparer): Prepares the test environment, possibly including software installation and device configuration.\n- [Test](/reference/tradefed/com/android/tradefed/testtype/IRemoteTest): Executes test(s) and gathers test results. This may be any JUnit Test, although our [IRemoteTest](/reference/tradefed/com/android/tradefed/testtype/IRemoteTest) interface is specifically designed to work well in the Trade Federation environment.\n- [Test Invocation Listener (results reporting)](/reference/tradefed/com/android/tradefed/result/ITestInvocationListener): Listens for test results, usually for the purpose of forwarding the test results to a repository or displaying them to the Test Runner.\n\nThe fundamental testing entity in TF is a **Configuration** (config). A config is an XML file\nthat declares the lifecycle components of a test.\n\nThis separation of the test's lifecycle is intended to allow for reuse. Using this design, the\nDeveloper can create a Test once, and then the Integrator can create different Configurations to\nrun that Test in different environments. For example,\nthey could create a Configuration that will run a test on a local machine and dump the result to\nstdout. They could then create a second Configuration that would execute that same test, but use a\ndifferent Test Invocation Listener to store the test results in a database. A third Configuration\nmight be designed run that test continuously from a test lab somewhere.\n\nIt's convenient to note here that a Configuration along with its command-line arguments (as\nprovided by the Test Runner) is known as a **Command** . When TF pairs a Command with an\n`ITestDevice` and executes it, the subsequent object is known as an **Invocation**.\nIn short, an Invocation encompasses a complete TF test execution, across its entire lifecycle.\n\nAdditional configuration components\n-----------------------------------\n\n- [Device Recovery](/reference/tradefed/com/android/tradefed/device/IDeviceRecovery): mechanism to recover device communication if lost.\n- [Logger](/reference/tradefed/com/android/tradefed/log/package-summary): collects tradefed logging data.\n\nStage output and errors\n-----------------------\n\nEach stage of an invocation executes sequentially and has a specific goal. This section describes\nthe usual outputs and errors of each stage.\n\n### Build provider\n\nThis stage creates and outputs an\n[`IBuildInfo`](/reference/tradefed/com/android/tradefed/build/IBuildInfo) object that contains all the required files references to set up and run the tests.\n\nThe most common error at this stage is a failure to download or find the requested files.\n\nAn error at this stage results in directly reporting the error, and no tests being run.\n\n### Target preparation\n\nThis stage sets up the necessary states for the target under tests. This stage can alter the\ndevice or the host setup as needed for the given test invocation.\n\nCommon errors at this stage usually involve failure to setup the device into a given state\n(for example, failed flashing) and failure to find the required files for the setup.\n\nAn error at this stage results in target clean up running, reporting of the error, and no tests\nbeing run.\n\n### Tests\n\nThis stage runs the requested tests on the previously prepared target, and reports all the\ntest execution results.\n\nCommon errors at this stage usually involve the target under test being unavailable or some\nerror causing partial execution of the tests. These errors are infrastructure issues that affect\nthe test execution itself as opposed to a failure of a single test case.\n\nAn error at this stage results in the test execution stopping, the target clean up running,\nreporting the error, and getting partial results.\n\n### Results reporting\n\nThis stage reports the results and errors to the configured services (for example, servers and\nlocal files).\n\nAlthough individual results reporters can have errors, they're isolated from each other\n(one reporter doesn't see errors from another one). These errors affect only an individual\nreporter's own results reporting and the errors can be viewed in the logs."]]
