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

Na tej stronie dowiesz się, jak zgłaszać dane wraz z wynikami testów podczas pisania testu w Tradefed.

Zaletą rejestrowania za pomocą potoku Tradefed jest możliwość znalezienia danych obok wyników funkcjonalnych. Rejestrowanie danych może odbywać się w testach w sposób bardzo naturalny, co ułatwia twórcom testów dodawanie większej liczby instrumentów.

DeviceTestCase – styl JUnit3

Jeśli test rozszerza klasę DeviceTestCase w stylu JUnit3, możesz wywołać metodę addTestMetric(String key, String value) w dowolnym przypadku testowym, aby zgłosić dane. Można go wywoływać wielokrotnie, o ile klucz jest niepowtarzalny.

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) w dowolnym przypadku testowym, 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ć dane w Tradefed z zwykłej klasy JUnit3 TestCase, musisz ją przekonwertować na MetricTestCase, czyli 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 (wewnątrz @Test), aby były raportowane przez Tradefed. Aby raportować dane, musisz używać 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 - pure Tradefed Test

Jeśli piszesz własną klasę testową lub moduł uruchamiający Tradefed, zaimplementujesz interfejs IRemoteTest i uzyskasz ITestInvocationListener za pomocą metody run(). Ten odbiorca może służyć do rejestrowania danych 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 wskaźników równolegle z testami.

Po stronie hosta

BaseDeviceMetricCollector można wdrożyć, aby zbierać dowolne dane na hoście i przesyłać je w ramach wywołania testu. W przypadku różnych zastosowań dostępnych jest już wiele ogólnych kolektorów, ale zawsze chętnie przyjmujemy nowe.

Aby określić kolektor, który ma być 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 z obecnie dostępnych kolektorów:TemperatureCollector, który okresowo zbiera dane o temperaturze podczas testu. * AtraceCollector który zbiera dane za pomocą narzędzia „atrace” w przypadku każdego testu.

Po stronie urządzenia

Podczas przeprowadzania testów po stronie urządzenia (testów Instrumentations, UIAutomator itp.) zbieranie danych po stronie hosta w sposób asynchroniczny może nie być idealne. Na przykład zrzut ekranu zrobiony asynchronicznie najprawdopodobniej nie będzie zawierać pożądanego ekranu i będzie bezużyteczny.

Aby zaspokoić te potrzeby, istnieje wersja naszych modułów zbierających dane po stronie urządzenia, której można używać w dowolnym narzędziu „AndroidJUnitRunner”. BaseMetricListener można wdrożyć, aby automatycznie raportować dane, które są zbierane w sposób w pełni zgodny z potokiem raportowania Tradefed.

Jeśli używasz narzędzia uruchamiającego „AndroidJUnitTest” z Tradefed, możesz po prostu określić tę opcję wiersza poleceń, aby uruchomić moduł zbierający razem z testami:

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

UWAGA: aby klasy zbierające mogły zostać rozpoznane w czasie działania, plik APK instrumentacji najprawdopodobniej będzie musiał zawierać je statycznie. W tym celu dodaj do pliku makefile ten kod:

  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib

Zachęcamy też do przesyłania informacji do kolektorów po stronie urządzenia.

Specjalne uwagi dotyczące apartamentów

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

Aby zapewnić, że zbieranie danych będzie stosowane w równym stopniu do każdego modułu, tylko konfiguracja najwyższego poziomu (np. cts.xml) może określać metrics_collector w sposób opisany powyżej. Te moduły zbierające będą stosowane i uruchamiane w przypadku każdego modułu pakietu.

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

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

AndroidTest.xml może określić kolekcjonera, 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>

Jeśli zbieracz danych wykryje klucz, spróbuje pobrać i zarejestrować powiązany z nim plik.

Aby wygenerować te klucze, test po stronie urządzenia (instrumentacja) powinien określać plik, który ma być rejestrowany. Odbywa się to w podobny sposób jak w przypadku hosta (opisany powyżej).

  1. Dodaj collector-device-lib do testowego pliku APK w plikach kompilacji:
  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 powyższym przykładzie to nazwa, pod którą plik będzie raportowany. Jest to nazwa, która powinna pasować do nazwy w FilePullerDeviceMetricCollector, aby była automatycznie pobierana. Powinna to być unikalna nazwa.

UWAGA: po pobraniu pliku FilePullerDeviceMetricCollector automatycznie usuwa go z urządzenia.

Gdzie znajdę te dane?

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