Raportuj metryki lub dane z testu Tradefed

Na tej stronie opisano, jak raportować metryki wraz z wynikami testów podczas pisania testu w Tradefed.

Zaletą logowania się za pośrednictwem Tradefed Pipeline jest możliwość znalezienia metryk wraz z wynikami funkcjonalnymi. Rejestrowanie metryk można przeprowadzić w testach w bardzo naturalny sposób, co ułatwia autorom testów dodanie większej liczby instrumentów.

DeviceTestCase — styl JUnit3

Jeśli Twój test rozszerza DeviceTestCase w typie testu w stylu JUnit3, możesz wywołać metodę addTestMetric(String key, String value) z dowolnego przypadku testowego, aby zgłosić metrykę. Można to wywołać wiele razy, 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 zarejestrować plik, aby był dostępny w result_reporters , możesz wywołać metodę addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) z dowolnego przypadku testowego, aby zgłosić plik do zarejestrowania.

Przykład:

    public static class TestLogTestCase extends DeviceTestCase {

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

TestCase - zwykły test JUnit3

Jeśli chcesz raportować metryki w Tradefed ze zwykłej klasy JUnit3 TestCase, zamiast tego należy je przekonwertować na MetricTestCase , która jest dokładnie tą samą klasą za pomocą dodatkowej metody: addTestMetric(String key, String value)

DeviceJUnit4ClassRunner — styl JUnit4

Jeśli Twój test w stylu JUnit4 działa z DeviceJUnit4ClassRunner , możesz także rejestrować metryki w ramach przypadku testowego (wewnątrz @Test), które mają być raportowane przez Tradefed. Aby zgłosić swoje metryki, będziesz musiał 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żyjesz reguły TestLogData , aby to zgłosić.

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 — czysty test Tradefed

Jeśli piszesz własną klasę lub moduł uruchamiający test Tradefed, zaimplementujesz IRemoteTest i uzyskasz obiekt ITestInvocationListener za pomocą metody run() . Tego odbiornika można używać do rejestrowania metryk w następujący sposób:

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

Kolekcjonerzy metryk handlowych

Tradefed udostępnia dedykowany obiekt metrics_collector do zbierania metryk równolegle z testami.

Po stronie gospodarzy

BaseDeviceMetricCollector można zaimplementować w celu zbierania dowolnych metryk po stronie hosta i raportowania ich w ramach wywołania testu. Dostępnych jest już wiele ogólnych modułów zbierających do różnych zastosowań, ale zawsze jesteśmy otwarci na nowe rozwiązania.

Aby określić moduł zbierający, który będzie używany w wywołaniu Tradefed, wystarczy dodać 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: * Kolektor temperaturowy , który okresowo zbiera temperaturę podczas pracy testowej. * AtraceCollector , który zbiera przy użyciu „atrace” dla każdego przypadku testowego.

Po stronie urządzenia

Podczas uruchamiania testów po stronie urządzenia (Instrumentacje, testy UIAutomator itp.) posiadanie modułu zbierającego po stronie hosta zbierającego asynchronicznie może nie być idealne. Na przykład zrzut ekranu wykonany asynchronicznie najprawdopodobniej nie będzie zawierał żądanego ekranu i będzie bezużyteczny.

Aby sprostać tym przypadkom użycia, istnieje wersja naszych modułów zbierających po stronie urządzenia, której można używać w dowolnym oprzyrządowaniu „AndroidJUnitRunner”. BaseMetricListener można wdrożyć w celu automatycznego raportowania metryk zebranych w sposób w pełni kompatybilny z potokiem raportowania Tradefed.

Jeśli używasz modułu uruchamiającego „ AndroidJUnitTest ” firmy Tradefed, możesz po prostu określić następującą opcję wiersza poleceń, aby moduł zbierający działał z testami:

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

PRZESTROGA: Aby klasy modułu zbierającego mogły zostać rozwiązane w czasie wykonywania, plik APK instrumentacji najprawdopodobniej będzie musiał je statycznie uwzględnić, dodając do pliku makefile następujące elementy:

  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib

Mile widziane są również datki na rzecz kolekcjonerów po stronie urządzenia.

Specjalne uwagi dla apartamentów

W przypadku pakietów takich jak CTS, które mają konfigurację najwyższego poziomu z niektórymi konfiguracjami modułów, nie ma potrzeby określania metrics_collector w każdej konfiguracji modułu ( AndroidTest.xml ). Właściwie jest to zabronione.

Aby mieć pewność, że kolekcja metryk zostanie zastosowana jednakowo do każdego modułu, tylko konfiguracja najwyższego poziomu (na przykład cts.xml ) może określić metrics_collector , jak wyjaśniono powyżej. Kolektory te zostaną zastosowane i będą działać w odniesieniu do każdego modułu pakietu.

Zbierz pliki dziennika urządzenia z modułu

Dostępna jest konfiguracja umożliwiająca test po stronie urządzenia powiadamiający o konieczności pobrania niektórych plików.

AndroidTest.xml może określić moduł zbierający, który będzie szukać plików 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>

Określając te wzorce i klucz, moduł zbierający, jeśli zobaczy klucz, spróbuje pobrać i zarejestrować powiązany plik.

Aby te klucze zostały wygenerowane, test po stronie urządzenia (oprzyrządowanie) powinien określić plik, który powinien zostać zarejestrowany. Odbywa się to w podobny sposób jak po stronie hosta (opisane powyżej).

  1. Dodaj collector-device-lib do testowego pliku APK w plikach make:
  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
  1. Użyj udostępnionej przez nas reguły @rule do rejestrowania plików:
    @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 powyższym przykładzie jest nazwą pod którą plik będzie raportowany. To jest nazwa, którą powinieneś dopasować w FilePullerDeviceMetricCollector , aby została automatycznie pobrana. powinna to być unikalna nazwa.

UWAGA: Po pobraniu pliku FilePullerDeviceMetricCollector automatycznie czyści go z urządzenia.

Gdzie znaleźć metryki?

Zależy to od result_reporter określonego w konfiguracji XML.