На этой странице описывается, как сообщать метрики вместе с результатами теста при написании теста в Tradefed.
Преимущество регистрации через конвейер Tradefed заключается в том, что вы можете найти свои показатели наряду с функциональными результатами. Регистрация метрик может выполняться в тестах очень естественно, что позволяет авторам тестов добавлять дополнительные инструменты.
DeviceTestCase — стиль JUnit3
Если ваш тест расширяет DeviceTestCase в виде теста в стиле JUnit3, вы можете вызвать метод addTestMetric(String key, String value) из любых тестовых примеров, чтобы сообщить о метрике. Это можно вызывать несколько раз, если ключ уникален.
Пример:
public static class TestMetricTestCase extends DeviceTestCase {
public void testPass() {
addTestMetric("key1", "metric1");
}
public void testPass2() {
addTestMetric("key2", "metric2");
}
}
Если вы хотите зарегистрировать файл, который будет доступен в result_reporters , вы можете вызвать метод addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) из любых тестовых примеров, чтобы сообщить о файле для регистрации.
Пример:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase — обычный тест JUnit3
Если вы хотите сообщать метрики внутри Tradefed из обычного класса JUnit3 TestCase, вместо этого его необходимо преобразовать в MetricTestCase , который представляет собой тот же класс с дополнительным методом: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner — стиль JUnit4
Если ваш тест стиля JUnit4 выполняется с помощью DeviceJUnit4ClassRunner , вы также можете регистрировать метрики внутри тестового примера (внутри @Test), которые будут сообщаться Tradefed. Вам нужно будет использовать правила TestMetrics для отчета о своих показателях.
Пример:
@RunWith(DeviceJUnit4ClassRunner.class)
public static class Junit4TestClass {
@Rule
public TestMetrics metrics = new TestMetrics();
@Test
public void testPass5() {
// test log through the rule.
metrics.addTestMetric("key", "value");
}
@Test
public void testPass6() {
metrics.addTestMetric("key2", "value2");
}
}
Чтобы сообщить о файлах, вы будете использовать правило TestLogData .
Пример:
@RunWith(DeviceJUnit4ClassRunner.class)
public static class Junit4TestClass {
@Rule
public TestLogData logs = new TestLogData();
@Test
public void testPass5() {
// test log through the rule.
try (InputStreamSource source = getDevice().getScreenshot()) {
logs.addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
IRemoteTest — чистый тест Tradefed
Если вы пишете свой собственный класс или средство выполнения теста Tradefed, вы реализуете IRemoteTest и получаете прослушиватель ITestInvocationListener с помощью метода run() . Этот прослушиватель можно использовать для регистрации метрик следующим образом:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Сборщики метрик Tradefed
Tradefed предоставляет специальный объект metrics_collector для сбора метрик параллельно с тестами.
На стороне принимающей стороны
BaseDeviceMetricCollector можно реализовать для сбора любых показателей со стороны хоста и сообщения о них в рамках вызова теста. Уже доступен ряд универсальных сборщиков для разных случаев использования, но мы всегда приветствуем новые предложения.
Чтобы указать сборщик, который будет использоваться при вызове Tradefed, вам просто нужно добавить объект в вашу XML-конфигурацию Tradefed:
Пример:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Некоторые существующие на данный момент коллекторы: * ТемператураКоллектор , который периодически собирает температуру во время тестового запуска. * AtraceCollector , который собирает данные с помощью atrace для каждого тестового примера.
Со стороны устройства
При запуске тестов на стороне устройства (инструменты, тесты UIAutomator и т. д.) наличие сборщика на стороне хоста, собирающего данные в асинхронном режиме, может быть не идеальным решением. Например, снимок экрана, сделанный асинхронно, скорее всего, не будет соответствовать нужному экрану и окажется бесполезным.
Для удовлетворения этих случаев использования существует версия наших сборщиков на стороне устройства, которую можно использовать в любом инструменте AndroidJUnitRunner. BaseMetricListener может быть реализован для автоматического составления отчетов о метриках, которые собираются способом, полностью совместимым с конвейером отчетов Tradefed.
Если вы используете программу AndroidJUnitTest от Tradefed, вы можете просто указать следующую опцию командной строки, чтобы ваш сборщик работал с вашими тестами:
--device-listeners android.device.collectors.ScreenshotListener
ВНИМАНИЕ. Чтобы классы-сборщики разрешались во время выполнения, ваш APK-файл инструментов, скорее всего, должен будет статически включить их, добавив в ваш make-файл следующее:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Вклад в сборщиков устройств также приветствуется.
Особое внимание к люксам
Для таких пакетов, как CTS, в конфигурации верхнего уровня которых выполняются некоторые конфигурации модулей, нет необходимости указывать metrics_collector в каждой конфигурации модуля ( AndroidTest.xml ). На самом деле это запрещено.
Чтобы гарантировать, что сбор метрик одинаково применяется к каждому модулю, только конфигурация верхнего уровня (например, cts.xml ) может указывать metrics_collector как описано выше. Эти сборщики будут применены и запущены для каждого модуля пакета.
Сбор файлов журналов устройства из модуля.
Доступна настройка, позволяющая при тестировании на стороне устройства уведомлять о необходимости сбора некоторых файлов.
AndroidTest.xml можно указать сборщика, который будет искать файлы на устройстве и извлекать их.
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<!-- repeatable: Pattern of key of a FILE we listen on that should be pulled -->
<option name = "pull-pattern-keys" value = "ScreenshotListener_.*" />
<!-- repeatable: The key of the DIRECTORY to pull -->
<option name = "directory-keys" value = "<example-key: /sdcard/atrace_logs>" />
</metrics_collector>
Указав эти шаблоны и ключ, сборщик, если он увидит ключ, попытается извлечь и зарегистрировать связанный файл.
Чтобы эти ключи были сгенерированы, тест на стороне устройства (инструментарий) должен указать файл, который должен быть зарегистрирован. Это делается аналогично тому, как это делается на стороне хоста (описано выше).
- Добавьте
collector-device-libв тестовый APK в файлах make:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Используйте @rule, которое мы предоставляем для журналирования файлов:
@RunWith(AndroidJUnit4.class)
public static class Junit4TestClass {
@Rule
public TestLogData logs = new TestLogData();
@Test
public void testPass5() {
// test log through the rule.
File logFile = new File("whatever");
logs.addTestLog("KEY", logFile);
}
}
Имя KEY в приведенном выше примере — это имя, под которым будет сообщаться о файле. Это имя, которое вы должны сопоставить в FilePullerDeviceMetricCollector , чтобы оно автоматически извлекалось. это должно быть уникальное имя.
ПРИМЕЧАНИЕ. После извлечения файла FilePullerDeviceMetricCollector автоматически удаляет его с устройства.
Где найти метрики?
Это зависит от result_reporter , указанного в вашей конфигурации XML.