Raportuj dane lub wskaźniki z testu Tradefed

Na tej stronie opisujemy, jak raportować dane wraz z wynikami testów podczas pisania testu w ramach Tradefed.

Zaletą logowania się przez kanał Tradefed jest możliwość znalezienia danych wraz z funkcjonalnymi wynikami. Rejestrowanie danych może odbywać się w naturalny sposób w ramach testów, co ułatwia autorom testów dodawanie kolejnych elementów instrumentacji.

DeviceTestCase – styl JUnit3

Jeśli test rozszerza klasę DeviceTestCase w ramach testu w stylu JUnit3, możesz wywoływać metodę addTestMetric(String key, String value) z dowolnych testów, aby zgłaszać dane. Funkcja może być wywoływana wielokrotnie, o ile klucz jest unikalny.

Przykład:

    public static class TestMetricTestCase extends DeviceTestCase {

        public void testPass() {
            addTestMetric("key1", "metric1");
        }

        public void testPass2() {
            addTestMetric("key2", "metric2");
        }
    }

Jeśli chcesz, aby plik był dostępny w result_reporters, możesz wywołać metodę addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) z poziomu dowolnych testów, aby zgłosić plik do dziennika.

Przykład:

    public static class TestLogTestCase extends DeviceTestCase {

        public void testPass() {
            try (InputStreamSource source = getDevice().getScreenshot()) {
                addTestLog("screenshot", LogDataType.PNG, source);
            }
        }
    }

Przypadek testowy – zwykły test JUnit3

Jeśli chcesz raportować dane w Tradefed z klasy JUnit3 TestCase, musisz ją przekształcić w klasę MetricTestCase, która jest dokładnie tą samą klasą z dodatkową metodą: addTestMetric(String key, String value)

DeviceJUnit4ClassRunner – styl JUnit4

Jeśli test stylu JUnit4 jest uruchomiony z wykorzystaniem DeviceJUnit4ClassRunner, możesz też rejestrować wskaźniki w przypadku testowego (wewnątrz @Test), które mają być raportowane przez TradeF. Aby raportować dane, musisz użyć reguł TestMetrics.

Przykład:

    @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");
        }
    }

Aby zgłosić pliki, użyj reguły TestLogData.

Przykład:

    @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 – test czysty Tradefed

Jeśli piszesz własną klasę lub funkcję testu Tradefed, zaimplementujesz interfejs IRemoteTest i uzyskasz obiekt ITestInvocationListener za pomocą metody run(). Z tego odbiornika możesz korzystać do rejestrowania danych w ten sposób:

    listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);

Kolektory danych handlowych

Tradefed udostępnia specjalny obiekt metrics_collector do zbierania danych równolegle z testami.

Po stronie gospodarza

BaseDeviceMetricCollector może być implementowany w celu zbierania dowolnych danych po stronie hosta i ich raportowania w ramach wywołania testu. Dostępnych jest już wiele ogólnych kolektorów do różnych zastosowań, ale zawsze chętnie też przekazujemy nowe osoby.

Aby określić kolektora, którego chcesz używać w wywołaniu Tradefed, po prostu dodaj obiekt do konfiguracji XML Tradefed:

Przykład:

  <metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
      <option name="categories" value="freq"/>
  </metrics_collector>

Niektóre obecnie istniejące kolektory: * TemperatureCollector, który okresowo rejestruje temperaturę podczas testu. * AtraceCollector, który zbiera dane za pomocą polecenia „atrace” w przypadku każdego testu.

Na urządzeniu

Podczas przeprowadzania testów na urządzeniu (testów Instrumentation, testów UIAutomator itp.) używanie kolektora po stronie hosta do zbierania danych asynchronicznie może nie być optymalnym rozwiązaniem. Na przykład zrzut ekranu zrobiony asynchronicznie najprawdopodobniej nie będzie zawierał żądanego ekranu i będzie bezużyteczny.

Aby sprostać tym zastosowaniom, udostępniamy wersję naszych kolektorów po stronie urządzenia, którą można używać w dowolnym narzędziu do pomiarów „AndroidJUnitRunner”. BaseMetricListener można zaimplementować, aby automatycznie raportować dane zbierane w sposób w pełni zgodny z systemem raportowania Tradefed.

Jeśli używasz uruchamiania „AndroidJUnitTest” z Tradefed, możesz po prostu podać w wierszu poleceń następującą opcję, aby uruchomić kolektor w ramach testów:

  --device-listeners android.device.collectors.ScreenshotListener

OSTRZEŻENIE: aby klasy kolektora były rozwiązywane w czasie wykonywania, plik APK z urządzeniem pomiarowym najprawdopodobniej będzie musiał zawierać je statycznie. Aby to zrobić, dodaj do pliku makefile następujące informacje:

  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib

Zapraszamy też do przesyłania informacji do zbieraczy po stronie urządzenia.

Specjalne uwagi dotyczące apartamentów

W przypadku pakietów takich jak CTS, które mają konfigurację najwyższego poziomu z niektórymi konfiguracjami modułów, nie trzeba określać wartości metrics_collector w każdej konfiguracji modułu (AndroidTest.xml). Jest to wręcz zabronione.

Aby zapewnić równe gromadzenie danych w każdym module, metrics_collector w sposób opisany powyżej można określić tylko w konfiguracji najwyższego poziomu (np. cts.xml). Te kolektory zostaną zastosowane i wykonane w przypadku każdego modułu pakietu.

Pobieranie plików dziennika urządzenia z modułu

Dostępna jest konfiguracja, która umożliwia test po stronie urządzenia powiadomienie o konieczności zebrania niektórych plików.

AndroidTest.xml może określić kolektor, który będzie szukać pliku na urządzeniu i je pobierać.

  <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>

Dzięki określeniu tych wzorców i klucza kolektor, jeśli wykryje klucz, spróbuje pobrać i zapisać powiązany plik.

Aby można było wygenerować te klucze, plik, który należy zapisać, powinien zostać określony w teście po stronie urządzenia (instrumentacja). Jest to realizowane w sposób podobny do tego, który został opisany powyżej.

  1. Dodaj collector-device-lib do testowego pliku APK w plikach make:
  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
  1. Użyj podanej przez nas reguły @rule w plikach dziennika:
    @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);
        }
    }

Nazwa KEY w przykładzie powyżej to nazwa, pod którą plik zostanie zgłoszony. To jest nazwa, która powinna być zgodna z nazwą w polu FilePullerDeviceMetricCollector, aby można było ją automatycznie pobrać. Nazwa powinna być niepowtarzalna.

UWAGA: gdy plik zostanie pobrany, FilePullerDeviceMetricCollector automatycznie usunie go z urządzenia.

Gdzie znajdę dane?

Zależy to od wartości result_reporter określonej w konfiguracji XML.