Отчет о показателях или данных теста Tradefed

На этой странице описывается, как сообщать показатели вместе с результатами тестирования при написании теста в 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-тест

Если вы пишете свой собственный класс или runner Tradefed Test, вы реализуете 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>

Некоторые существующие в настоящее время коллекторы: * TemperatureCollector , который периодически собирает температуру во время тестового прогона. * AtraceCollector , который собирает данные с использованием «atrace» для каждого тестового случая.

На стороне устройства

При запуске тестов на стороне устройства (тесты Instrumentations, 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>

Указав эти шаблоны и ключ, сборщик, если он обнаружит ключ, попытается извлечь и зарегистрировать связанный файл.

Для того, чтобы эти ключи были сгенерированы, тест на стороне устройства (инструментация) должен указать файл, который должен быть зарегистрирован. Это делается аналогично тому, как это делается на стороне хоста (описано выше).

  1. Добавьте collector-device-lib в ваш тестовый APK в файлах make: 
  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
  1. Используйте @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-конфигурации.