Ta strona opisuje, jak raportować metryki wraz z wynikami testów podczas pisania testu w Tradefed.
Zaletą logowania za pośrednictwem potoku Tradefed jest znajdowanie metryk obok wyników funkcjonalnych. Rejestrowanie metryk można wykonać bardzo naturalnie w ramach testów, co ułatwia autorom testów dodanie większej ilości oprzyrządowania.
DeviceTestCase - styl JUnit3
Jeśli Twój test rozszerza DeviceTestCase w rodzaju testu typu JUnit3, możesz wywołać metodę addTestMetric(String key, String value) z wnętrza dowolnych przypadków testowych, aby zgłosić metrykę. Można to wywoływać 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 wnętrza dowolnych przypadków testowych, 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ć metryki wewnątrz Tradefed ze zwykłej klasy JUnit3 TestCase, należy je przekonwertować na MetricTestCase , która jest dokładnie tą samą klasą z dodatkową metodą: addTestMetric(String key, String value)
UrządzenieJUnit4ClassRunner - styl JUnit4
Jeśli Twój test w stylu JUnit4 działa z DeviceJUnit4ClassRunner , możesz również rejestrować metryki w przypadku testowym (wewnątrz @Test), które mają być zgłaszane przez Tradefed. Będziesz musiał użyć reguł TestMetrics , aby zgłosić swoje metryki.
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 program uruchamiający Tradefed Test, zaimplementujesz IRemoteTest i uzyskasz ITestInvocationListener za pomocą metody run() . Ten detektor może służyć do rejestrowania metryk w następujący sposób:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Kolekcjonerzy metryk będących przedmiotem handlu
Tradefed udostępnia dedykowany obiekt metrics_collector do zbierania metryk równolegle z testami.
Po stronie gospodarza
BaseDeviceMetricCollector można zaimplementować w celu zbierania dowolnych metryk po stronie hosta i zgłaszania ich w ramach wywołania testowego. Dostępnych jest już wiele generycznych kolekcjonerów dla różnych przypadków użycia, ale zawsze chętnie przyjmujemy nowe wkłady.
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 obecnie istniejące kolektory: * TemperatureCollector , który okresowo zbiera temperaturę podczas przebiegu testowego. * 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 (instrumenty, testy UIAutomator itp.) posiadanie kolektora po stronie hosta zbierającego asynchronicznie może nie być idealne. Na przykład zrzut ekranu zrobiony asynchronicznie najprawdopodobniej przegapi żądany ekran i będzie bezużyteczny.
Aby sprostać tym przypadkom użycia, istnieje wersja naszych kolektorów po stronie urządzenia i może być używana w dowolnym oprzyrządowaniu „AndroidJUnitRunner”. BaseMetricListener można zaimplementować w celu automatycznego raportowania metryk, które są zbierane w sposób w pełni zgodny z potoku raportowania Tradefed.
Jeśli używasz programu uruchamiającego ' AndroidJUnitTest ' firmy Tradefed, możesz po prostu określić następującą opcję wiersza polecenia, aby kolektor działał z testami:
--device-listeners android.device.collectors.ScreenshotListener
UWAGA: Aby klasy zbierające mogły zostać rozwiązane w czasie wykonywania, plik APK instrumentacji najprawdopodobniej będzie musiał statycznie je uwzględnić, dodając do pliku makefile następujące elementy:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Mile widziane są również wpłaty na rzecz kolekcjonerów po stronie urządzeń.
Szczególna uwaga na apartamenty
W przypadku pakietów, takich jak CTS, które mają konfigurację najwyższego poziomu, w której działają niektóre konfiguracje modułów, nie ma potrzeby określania metrics_collector w każdej konfiguracji modułu ( AndroidTest.xml ). Właściwie jest to zabronione.
Aby upewnić się, że kolekcja metryk jest stosowana jednakowo do każdego modułu, tylko konfiguracja najwyższego poziomu (na przykład cts.xml ) może określać metrics_collector , jak wyjaśniono powyżej. Kolektory te zostaną zastosowane i uruchomione w każdym module pakietu.
Jak zbierać pliki dziennika urządzenia z modułu?
Dostępna jest konfiguracja, aby test po stronie urządzenia powiadomił, że niektóre pliki powinny zostać zebrane.
AndroidTest.xml może określić kolektor, który będzie szukał plików na urządzeniu i ściągał 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>
Określając te wzorce i klucz, kolektor, jeśli zobaczy klucz, spróbuje pobrać i zarejestrować skojarzony plik.
Aby te klucze zostały wygenerowane, test po stronie urządzenia (oprzyrządowanie) powinien określić plik, który ma być rejestrowany. Odbywa się to w podobny sposób jak po stronie hosta (opisane powyżej).
- Dodaj
collector-device-libdo testowego pakietu APK w plikach make:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Użyj dostarczonej przez nas reguły @, aby rejestrować pliki:
@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órą należy dopasować w FilePullerDeviceMetricCollector , aby została automatycznie pobrana. powinna to być unikatowa nazwa.
UWAGA: Po ściągnięciu pliku FilePullerDeviceMetricCollector automatycznie czyści go z urządzenia.
Gdzie znaleźć metryki?
Zależy to od parametru result_reporter określonego w konfiguracji XML.