自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
TF 测试生命周期
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
使用 Trade Federation 执行的测试,其生命周期包括四个独立阶段,并且围绕正式定义的接口而设计。
定义的接口
- build 提供程序:提供一个要测试的 build,必要时可下载适当的文件。
- 目标准备器:准备测试环境,其中可能包括软件安装和设备配置。
- 测试:执行测试并收集测试结果。虽然我们的 IRemoteTest 接口专为在 Trade Federation 环境中实现出色性能而设计,但这里执行的测试可以是任何 JUnit 测试。
- 测试调用监听器(结果报告):监听测试结果,通常用于将测试结果转发到存储库或将其显示给测试运行程序。
TF 中的基本测试实体是一项配置 (config)。config 是一个 XML 文件,用于声明测试的生命周期组件。
对测试生命周期进行独立分段的目的是方便重复使用。使用该设计,开发者可以创建一次测试,然后集成者可以创建不同的配置,以便在不同环境中运行该测试。例如,他们可以创建一项配置,该配置可以在本地计算机上运行测试并将测试结果转储到 stdout。然后,他们可以创建执行相同测试的第二个配置,但使用不同的测试调用监听器将测试结果存储在数据库中。他们还可能设计第三个配置,用于从某处的测试实验室进行连续测试。
这里顺便说明一下,一个配置加上相关命令行参数(由测试运行程序提供)一起称为命令。当 TF 将某个命令与 ITestDevice
配对并执行该命令时,后续对象称为调用。简而言之,调用包含贯穿整个生命周期的完整 TF 测试执行过程。
其他配置组件
阶段输出和错误
调用的每个阶段都会依序执行,且具有特定目标。本部分介绍每个阶段的正常输出和错误。
build 提供程序
此阶段会创建并输出 IBuildInfo
对象,该对象包含设置和运行测试所需的所有文件引用。
此阶段最常见的错误是无法下载或找不到请求的文件。
此阶段出现的错误会导致直接报告错误,并且不会运行任何测试。
目标准备
此阶段会为被测目标设置必要状态。此阶段可根据需要为给定的测试调用更改设备或主机设置。
此阶段的常见错误通常包括设备无法设置为给定状态(例如无法刷写),以及找不到设置必需的文件。
此阶段出现的错误会导致运行目标清理、报告错误,并且不会运行任何测试。
测试
此阶段会对先前准备的目标运行请求的测试,并报告所有测试执行结果。
此阶段的常见错误通常包括被测目标不可用,或某些错误导致测试部分执行。这些错误是会影响测试执行本身的基础架构问题,而不是单个测试用例失败。
此阶段出现的错误会导致停止执行测试、运行目标清理、报告错误并获得部分结果。
结果报告
此阶段会向配置的服务(例如服务器和本地文件)报告结果和错误。
虽然单个结果报告程序可能会出错,但它们彼此独立(一个报告程序不会看到另一个报告程序的错误)。这些错误只会影响单个报告程序自身的结果报告。可在日志中查看这些错误。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-07-27。"],[],[],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."]]