Z tej strony dowiesz się, jak raportować dane wraz z wynikami testów podczas pisania testu w Tradefed.
Zaletą rejestrowania w potoku Tradefed jest to, że dane można znaleźć obok wyników funkcjonalnych. Rejestrowanie danych może odbywać się w sposób naturalny w ramach testów, co ułatwia autorom testów dodawanie większej liczby instrumentacji.
DeviceTestCase – styl JUnit3
Jeśli test rozszerza DeviceTestCase
w stylu JUnit3, możesz wywołać metodę
addTestMetric(String key, String value) z dowolnego przypadku testowego, aby zgłosić
dane. Można ją 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, który ma 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 zgłaszać dane w Tradefed z klasy TestCase JUnit3, musisz ją przekonwertować na MetricTestCase, czyli 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 zgłaszane
przez Tradefed. Do zgłaszania danych 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 – czysty test Tradefed
Jeśli piszesz własną klasę testową lub narzędzie uruchamiające Tradefed, zaimplementujesz
IRemoteTest
i uzyskasz ITestInvocationListener za pomocą metody run(). Tego odbiornika można 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, który zbiera dane równolegle z testami.
Po stronie hosta
BaseDeviceMetricCollector można zaimplementować, aby zbierać dowolne dane po stronie hosta i zgłaszać je w ramach wywołania testu. Dostępnych jest już kilka ogólnych kolektorów do różnych przypadków użycia, ale zawsze przyjmujemy nowe propozycje.
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 dostępne kolektory: * TemperatureCollector który okresowo zbiera temperaturę podczas wykonywania testu. * AtraceCollector który zbiera dane za pomocą „atrace” dla każdego przypadku testowego.
Po stronie urządzenia
W przypadku testów po stronie urządzenia (instrumentacje, testy UIAutomator itp.) kolektor po stronie hosta, który zbiera dane asynchronicznie, może nie być idealnym rozwiązaniem. 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 kolektorów po stronie urządzenia, której można używać w dowolnej instrumentacji „AndroidJUnitRunner”. BaseMetricListener można zaimplementować, aby automatycznie zgłaszać dane 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 kolektor działał razem z testami:
--device-listeners android.device.collectors.ScreenshotListener
UWAGA: aby klasy kolektorów były rozpoznawane w czasie działania, plik APK instrumentacji będzie najprawdopodobniej musiał je statycznie zawierać. W tym celu dodaj do pliku makefile ten wiersz:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Propozycje dotyczące kolektorów po stronie urządzenia są również mile widziane.
Szczególne uwagi dotyczące pakietów
W przypadku pakietów takich jak CTS, które mają konfigurację najwyższego poziomu uruchamiającą 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 równomiernie do każdego modułu, tylko konfiguracja najwyższego poziomu (np. cts.xml) może określać metrics_collector zgodnie z opisem powyżej. Te kolektory 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 powiadomienie o tym, że należy zebrać niektóre pliki.
AndroidTest.xml może określać kolektor, 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 określisz te wzorce i klucz, kolektor, gdy zobaczy klucz, spróbuje pobrać i zarejestrować powiązany plik.
Aby te klucze były generowane, test po stronie urządzenia (instrumentacja) powinien określać plik, który ma być zarejestrowany. Odbywa się to w podobny sposób jak po stronie hosta (opisany powyżej).
- Dodaj
collector-device-libdo pliku APK testu w plikach makefile:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Aby rejestrować pliki, użyj reguły @rule, którą udostępniamy:
@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 zgłaszany. Jest to nazwa, która powinna pasować do nazwy w FilePullerDeviceMetricCollector, aby plik był automatycznie pobierany. Powinna to być unikalna nazwa.
UWAGA: po pobraniu pliku FilePullerDeviceMetricCollector automatycznie usuwa go z urządzenia.
Gdzie znajdę dane?
Zależy to od result_reporter określonego w konfiguracji XML.