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

Na tej stronie dowiesz się, jak podczas pisania tworzyć raporty dotyczące danych i wyników testów test w The Tradefed.

Zaletą logowania za pomocą potoku Tradefed jest znajdowanie wskaźników z perspektywy funkcjonalnych wyników. Logowanie wskaźników jest możliwe w sposób bardzo naturalny w ramach testów, dzięki czemu twórcy testów mogą dodawać więcej z narzędzi pomiarowych.

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

TestCase – zwykły test JUnit3

Jeśli chcesz raportować wskaźniki wewnątrz Tradefed ze zwykłego przypadku testowego JUnit3 klasa, trzeba ją przekonwertować na klasę MetricTestCase, która jest dokładnie ta sama klasa z dodatkową metodą: addTestMetric(String key, String value)

DeviceJUnit4ClassRunner – styl JUnit4

Jeśli test stylu JUnit4 jest uruchomiony z DeviceJUnit4ClassRunner, możesz też rejestrować wskaźniki w przypadku testowania (wewnątrz @Test), które mają być raportowane z The 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, należy użyć 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(). Ten detektor może służyć do rejestrowania wskaźników w następujący 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 gospodarza

BaseDeviceMetricCollector może być implementowany w celu zbierania dowolnych danych po stronie hosta i ich raportowania 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 używający słowa „atrace” dla każdego przypadku testowego.

Po stronie urządzenia

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 uwzględnia chciał mieć ekran i był bezużyteczny.

Aby sprostać tym przypadkom użycia, istnieje wersja kolektorów po stronie urządzenia i można go użyć w dowolnym AndroidJUnitRunner z narzędzi pomiarowych. BaseMetricListener. można wdrożyć w celu automatycznego raportowania zbieranych danych w sposób w pełni zgodny z procesem 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

UWAGA: aby klasy kolektora były przetwarzane w czasie działania, plik APK z narzędziami będą najprawdopodobniej wymagał statycznego umieszczenia ich przez dodanie w pliku Makefile:

  LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib

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

Specjalna uwaga w przypadku 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 stosowanie gromadzenia 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 uruchomione w poszczególnych modułach pakietu.

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

Dostępna jest konfiguracja, która umożliwia testowanie po stronie urządzenia powiadomień o niektórych plikach powinny być zbierane.

AndroidTest.xml może określić kolektor, który będzie szukać pliku w urządzenia i ją wyciągnąć.

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

Do wygenerowania tych kluczy służy test po stronie urządzenia (instrumentacja) powinien określać plik, który należy zapisać. Odbywa się to w podobny sposób po stronie hosta (zgodnie z opisem 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, aby zapisać pliki 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);
        }
    }

W powyższym przykładzie KEY to nazwa, pod którą zostanie przestawiony plik zostało zgłoszone. 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: po pobraniu pliku FilePullerDeviceMetricCollector automatycznie usuwa go z urządzenia.

Gdzie znajdę dane?

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