自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
Tradefed 中的选项处理
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
选项处理是 Trade Federation 模块化方法的核心。具体而言,选项是一种机制,让开发者、集成者和测试运行者通过该机制可以共同协作,而不会重复相互的工作。简单地说,实现选项处理后,开发者可将 Java 类成员标记为可配置,届时该成员的值可被集成者增强或覆盖,并且随后可被测试运行者增强或覆盖。该机制适用于所有 Java 固有类型,以及固有类型的任何 Map
或 Collection
实例。
注意:选项处理机制仅适用于实现测试生命周期中包含的某个接口的类,并且仅当该类由生命周期系统实例化后才适用。
开发者
首先,开发者需要使用 @Option
注解来标记成员。
这些对象至少需要指定 name
和 description
值,前者指定与该选项关联的参数名称,后者指定使用 --help
或 --help-all
运行命令时会在 TF 控制台上显示的说明。
举例来说,假设我们要构建一个功能完善的电话测试,我们会在测试中拨打各种电话号码,并预期在每个号码连接后收到一系列 DTMF 音。
public class PhoneCallFuncTest extends IRemoteTest {
@Option(name = "timeout", description = "How long to wait for connection, in millis")
private long mWaitTime = 30 * 1000; // 30 seconds
@Option(name = "call", description = "Key: Phone number to attempt. " +
"Value: DTMF to expect. May be repeated.")
private Map<String, String> mCalls = new HashMap<String, String>;
public PhoneCallFuncTest() {
mCalls.add("123-456-7890", "01134"); // default
}
以上就是开发者为该测试设置两个配置点的所有要求。开发者随后可以正常离开并使用 mWaitTime
和 mCalls
,而无需特别关注它们可配置的事实。由于 @Option
字段是在类实例化之后、run
方法调用之前设置的,因此实现者可以轻松为 Map
和 Collection
字段设置默认值或执行某类过滤操作,除此之外只能附加这些字段。
集成商
集成者的工作重心是编写 XML 格式的配置。配置格式允许集成者为任何 @Option
字段设置(或附加)值。例如,假设集成者想要定义拨打默认号码的低延迟测试,以及会拨打各种号码的运行时间较长的测试。集成者可以创建一对配置,可能如下所示:
<?xml version="1.0" encoding="utf-8"?>
<configuration description="low-latency default test; low-latency.xml">
<test class="com.example.PhoneCallFuncTest">
<option name="timeout" value="5000" />
</test>
</configuration>
<?xml version="1.0" encoding="utf-8"?>
<configuration description="call a bunch of numbers; many-numbers.xml">
<test class="com.example.PhoneCallFuncTest">
<option name="call" key="111-111-1111" value="#*#*TEST1*#*#" />
<option name="call" key="222-222-2222" value="#*#*TEST2*#*#" />
<!-- ... -->
</test>
</configuration>
测试运行程序
测试运行者也可以通过 Trade Federation 控制台访问这些配置点。首先也是最重要的,它们将使用 run command <name>
指令(或简称 run <name>
)运行命令(即配置及其所有参数)。除此之外,他们可以指定任何参数列表作为命令的一部分,这可能替换或附加到各个配置内的生命周期对象指定的字段。
如需使用 many-numbers
电话号码运行低延迟测试,测试运行者可以执行:
tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#
或者,要从相反方向获得类似的效果,测试运行者可以减少 many-numbers
测试的等待时间:
tf> run many-numbers.xml --timeout 5000
选项排序
您可能会注意到 call
选项的底层实现是 Map
,因此在命令行上重复了 --call
时,它们都将存储起来。
选项 timeout
(其底层实现为 long
)只能存储一个值。因此,系统只会存储指定的最后一个值。--timeout 5 --timeout 10
会生成包含 10 的 timeout
。
如果将 List
或 Collection
用作底层实现,则系统会按照命令行中指定的顺序存储所有值。
布尔值选项
布尔值基础类型的选项可以通过直接传递选项名称(例如 --[option-name]
)设置为 true
,也可以利用语法 --no-[option-name]
设置为 false
。
另请参阅
将选项传递给套件和模块
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-26。
[[["易于理解","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-03-26。"],[],[],null,["# Option handling in Tradefed\n\nOption handling lies at the heart of Trade Federation's modular approach. In particular, options\nare the mechanism by which the developer, Integrator, and Test Runner can work together without\nhaving to duplicate each-other's work. Put simply, our implementation of option handling allows the\ndeveloper to mark a Java class member as being configurable, at which point the value of that member\ncan be augmented or overridden by the Integrator, and can be subsequently augmented or overridden by\nthe Test Runner. This mechanism works for all Java intrinsic types, as well as for any\n`Map` or `Collection` instances of intrinsic types.\n\n**Note:** The option-handling mechanism only works for classes\nimplementing one of the\ninterfaces included in the [Test Lifecycle](/docs/core/tests/tradefed/fundamentals/lifecycle), and only when that class is\n*instantiated* by the lifecycle machinery.\n\nDeveloper\n---------\n\nTo start off, the developer marks a member with the\n[@Option](https://android.googlesource.com/platform/tools/tradefederation/+/android16-release/common_util/com/android/tradefed/config/Option.java) annotation.\nThey specify (at a minimum) the `name` and `description` values, which\nspecify the argument name associated with that Option, and the description that is displayed on\nthe TF console when the command is run with `--help` or `--help-all`.\n\nAs an example, let's say we want to build a functional phone test that dials a variety of\nphone numbers, and expects to receive a sequence of DTMF tones from each number after it\nconnects. \n\n```gdscript\npublic class PhoneCallFuncTest extends IRemoteTest {\n @Option(name = \"timeout\", description = \"How long to wait for connection, in millis\")\n private long mWaitTime = 30 * 1000; // 30 seconds\n\n @Option(name = \"call\", description = \"Key: Phone number to attempt. \" +\n \"Value: DTMF to expect. May be repeated.\")\n private Map\u003cString, String\u003e mCalls = new HashMap\u003cString, String\u003e;\n\n public PhoneCallFuncTest() {\n mCalls.add(\"123-456-7890\", \"01134\"); // default\n }\n```\n\nThat's all that's required for the developer to set up two points of configuration for that\ntest. They could then go off and use `mWaitTime` and `mCalls` as normal,\nwithout paying much attention to the fact that they're configurable. Because the\n`@Option` fields are set after the class is instantiated, but before the\n`run` method is called, that provides an easy way for implementors to set up defaults for\nor perform some kind of filtering on `Map` and `Collection` fields, which are\notherwise append-only.\n\nIntegrator\n----------\n\nThe Integrator works in the world of configurations, which are written in XML. The config format\nallows the Integrator to set (or append) a value for any `@Option` field. For instance,\nsuppose the Integrator wanted to define a lower-latency test that calls the default number, as well\nas a long-running test that calls a variety of numbers. They could create a pair of configurations\nthat might look like the following: \n\n```world-of-warcraft-toc\n\u003c?xml version=\"1.0\" encoding=\"utf-8\"?\u003e\n\u003cconfiguration description=\"low-latency default test; low-latency.xml\"\u003e\n \u003ctest class=\"com.example.PhoneCallFuncTest\"\u003e\n \u003coption name=\"timeout\" value=\"5000\" /\u003e\n \u003c/test\u003e\n\u003c/configuration\u003e\n``` \n\n```world-of-warcraft-toc\n\u003c?xml version=\"1.0\" encoding=\"utf-8\"?\u003e\n\u003cconfiguration description=\"call a bunch of numbers; many-numbers.xml\"\u003e\n \u003ctest class=\"com.example.PhoneCallFuncTest\"\u003e\n \u003coption name=\"call\" key=\"111-111-1111\" value=\"#*#*TEST1*#*#\" /\u003e\n \u003coption name=\"call\" key=\"222-222-2222\" value=\"#*#*TEST2*#*#\" /\u003e\n \u003c!-- ... --\u003e\n \u003c/test\u003e\n\u003c/configuration\u003e\n```\n\nTest Runner\n-----------\n\nThe Test Runner also has access to these configuration points through the Trade Federation console.\nFirst and foremost, they run a command (that is, a config and all of its arguments) with the\n`run command \u003cname\u003e` instruction (or `run \u003cname\u003e` for short).\nBeyond that, they can specify any list of arguments are part of the command, which can replace or\nappend to fields specified by lifecycle objects within each config.\n\nTo run the low-latency test with the `many-numbers` phone numbers, the Test Runner\ncould execute: \n\n```\ntf\u003e run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#\n```\n\nOr, to get a similar effect from the opposite direction, the Test Runner could reduce the wait\ntime for the `many-numbers` test: \n\n```\ntf\u003e run many-numbers.xml --timeout 5000\n```\n\nOption ordering\n---------------\n\nYou might notice that the `call` option underlying implementation is a `Map`\nso upon repeated `--call` on the command line, they're all stored.\n\nThe option `timeout`, which has an underlying implementation of `long`,\ncan only store one value. So only the last value specified is stored.\n`--timeout 5 --timeout 10` results in `timeout` containing 10.\n\nIn case of a `List` or `Collection` as the underlying implementation,\nall the values are stored, in the order specified on the command line.\n\nBoolean options\n---------------\n\nOptions of boolean underlying type can be set to `true` by directly passing the\noption name, for example, `--[option-name]` and can be set to `false` using\nthe syntax `--no-[option-name]`.\n\nSee also\n--------\n\n[Pass options to suite and\nmodules](/docs/core/tests/tradefed/testing/through-suite/option-passing)"]]