Zgłaszanie danych lub danych pochodzących z testu Tradefed

Na tej stronie opisujemy, jak raportować dane wraz z wynikami testu podczas pisania testu w 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łać 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);
            }
        }
    }

TestCase – zwykły test JUnit3

Jeśli chcesz raportować dane w Tradefed z klasy zwykłego testu JUnit3, 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 w stylu JUnit4 jest uruchamiany za pomocą DeviceJUnit4ClassRunner, możesz też rejestrować dane w przypadku testowym (w ramach @Test), aby były raportowane przez Tradefed. 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 – testowanie w czystej formie Tradefed

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

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

Kolektory danych Tradefed

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

Po stronie hosta

BaseDeviceMetricCollector można zaimplementować w celu zbierania dowolnych danych po stronie hosta i zgłaszania ich w ramach wywołania testu. W przypadku różnych zastosowań dostępnych jest już kilka uniwersalnych kolekcjonerów, ale zawsze chętnie przyjmujemy nowe.

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 przypadku testowego.

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 prawdopodobnie nie będzie zawierał żądanego ekranu i będzie bezużyteczny.

Aby spełnić te wymagania, udostępniamy wersję naszych kolektorów po stronie urządzenia, którą można używać w dowolnym narzędziu do pomiarów „AndroidJUnitRunner”. Interfejs BaseMetricListener można zaimplementować w celu automatycznego raportowania danych, które są zbierane w sposób w pełni zgodny z systemem raportowania Tradefed.

Jeśli używasz skryptu AndroidJUnitTest z Tradefed, możesz po prostu użyć tej opcji wiersza poleceń, aby uruchomić kolektor z testami:

  --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 danych 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 podawać wartości metrics_collector w każdej konfiguracji modułu (AndroidTest.xml). Jest to w ogóle zabronione.

Aby zapewnić równe stosowanie zbierania danych do każdego modułu, tylko konfiguracja najwyższego poziomu (np. cts.xml) może określać ustawienie metrics_collector, jak opisano powyżej. Te kolektory zostaną zastosowane i wykonane w przypadku każdego modułu pakietu.

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

Konfiguracja jest dostępna, aby poinformować o tym, że test na urządzeniu powinien zebrać niektóre pliki.

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

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

Po określeniu tych wzorców i klucza, jeśli zbieracz zobaczy klucz, spróbuje pobrać i zapisać powiązany plik.

Aby te klucze mogły zostać wygenerowane, test po stronie urządzenia (instrumentacja) powinien określić plik, który ma być zapisany w dzienniku. Jest to realizowane w sposób podobny do tego, który ma miejsce po stronie hosta (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 mogę znaleźć dane?

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