Auf dieser Seite wird beschrieben, wie Sie beim Schreiben von Messwerten und Testergebnissen Berichte erstellen. einen Test in Tradefed.
Der Vorteil des Loggings über die Tradefed-Pipeline besteht darin, dass Sie Ihre Messwerte die funktionellen Ergebnisse. Das Logging von Messwerten kann ganz einfach innerhalb von Tests erfolgen, was es für Testautoren bequem macht, weitere Instrumentierung hinzuzufügen.
DeviceTestCase – JUnit3-Stil
Wenn Ihr Test DeviceTestCase in einem JUnit3-Test erweitert, können Sie die Methode addTestMetric(String key, String value)
innerhalb von Testfällen aufrufen, um einen Messwert zu erfassen. Dieser kann mehrmals aufgerufen werden, solange der Schlüssel eindeutig ist.
Beispiel:
public static class TestMetricTestCase extends DeviceTestCase {
public void testPass() {
addTestMetric("key1", "metric1");
}
public void testPass2() {
addTestMetric("key2", "metric2");
}
}
Wenn Sie eine Datei protokollieren möchten, die im result_reporters
verfügbar sein soll, können Sie die Methode addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream)
innerhalb von Testfällen aufrufen, um eine Datei zu melden, die protokolliert werden soll.
Beispiel:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase – regulärer JUnit3-Test
Wenn Sie Messwerte in Tradef aus einem normalen JUnit3-Testfall melden möchten
Klasse, muss sie in MetricTestCase
konvertiert werden. Dies ist die
exakt dieselbe Klasse mit einer zusätzlichen Methode: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner – JUnit4-Stil
Wenn Ihr JUnit4-Stiltest mit
DeviceJUnit4ClassRunner
können Sie Messwerte auch innerhalb eines Testlaufs (in @Test) für die Berichterstellung
von Tradefed. Sie müssen TestMetrics
Regeln verwenden, um Berichte zu Ihren Messwerten zu erstellen.
Beispiel:
@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");
}
}
Wenn Sie Dateien melden möchten, verwenden Sie die Regel TestLogData
.
Beispiel:
@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 – reiner Tradefed-Test
Wenn Sie Ihren eigenen Tradefed-Testkurs oder Runner schreiben, werden Sie ihn implementieren.
IRemoteTest
und rufen Sie über die Methode run()
ein ITestInvocationListener
ab. Dieser Listener
können verwendet werden, um Messwerte wie folgt zu protokollieren:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Erfasser von Tradefed-Messwerten
Tradefed bietet ein spezielles metrics_collector
-Objekt, mit dem Messwerte parallel zu den Tests erfasst werden können.
Auf der Hostseite
BaseDeviceMetricCollector können implementiert werden, um beliebige Messwerte von der Hostseite zu erfassen und in Berichte aufzunehmen. als Teil des Testaufrufs. Eine Reihe generischer Collectors für verschiedene Anwendungsfälle. Wir freuen uns aber immer über neue Beiträge.
Wenn Sie den in Ihrer Tradefed-Aufrufmethode zu verwendenden Collector angeben möchten, fügen Sie das Objekt einfach Ihrer Tradefed-XML-Konfiguration hinzu:
Beispiel:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Einige derzeit vorhandene Collectors: * TemperatureCollector die die Temperatur regelmäßig während des Testlaufs erfasst. * AtraceCollector, der für jeden Testfall mit „atrace“ erfasst.
Auf der Geräteseite
Bei der Durchführung von geräteseitigen Tests (Instrumentierungen, UIAutomator-Tests usw.) Wenn ein Collector auf der Hostseite asynchron Daten erfasst, Ideal ist. Bei einem asynchron aufgenommenen Screenshot wird z. B. höchstwahrscheinlich der Fehler und nutzlos sein.
Für diese Anwendungsfälle gibt es eine geräteseitige Version unserer Collectors, die in jeder AndroidJUnitRunner-Instrumentierung verwendet werden kann. BaseMetricListener kann implementiert werden, um automatisch Berichte zu erfassten Messwerten zu erstellen. und vollständig kompatibel mit der Tradefed-Berichts-Pipeline sein.
Bei Verwendung von AndroidJUnitTest Runner von Tradefed haben, können Sie einfach die folgende Befehlszeilenoption angeben damit der Collector mit den Tests ausgeführt wird:
--device-listeners android.device.collectors.ScreenshotListener
ACHTUNG: Damit die Collector-Klassen zur Laufzeit aufgelöst werden, Instrumentierungs-APK höchstwahrscheinlich statisch einfügen müssen, indem sie in Ihr Makefile:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Beiträge zu geräteseitigen Collectors sind ebenfalls willkommen.
Besondere Hinweise für Suiten
Für Suiten wie CTS, die eine Top-Level-Konfiguration haben, auf der ein Modul ausgeführt wird
Konfigurationen vorhanden sind, muss metrics_collector
nicht in jedem Modul angegeben werden.
Konfiguration (AndroidTest.xml
). Es ist in Wirklichkeit verboten.
Damit die Messwerterhebung auf alle Module gleichermaßen angewendet wird, kann metrics_collector
wie oben beschrieben nur in der Konfigurationsebene auf oberster Ebene (z. B. cts.xml
) angegeben werden. Diese Collectors werden angewendet und ausgeführt
für jedes Modul der Suite.
Geräteprotokolldateien aus einem Modul erfassen
Es ist eine Konfiguration verfügbar, mit der bei einem geräteseitigen Test benachrichtigt werden kann, dass einige Dateien sollte erfasst werden.
AndroidTest.xml
kann einen Aggregator angeben, der nach Dateien auf dem Gerät sucht und sie abruft.
<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>
Durch Angabe dieser Muster und des Schlüssels kann der Collector den Schlüssel erkennen, versuchen, die zugehörige Datei abzurufen und zu protokollieren.
Damit diese Schlüssel generiert werden, muss ein geräteseitiger Test (Instrumentierung) sollte die zu protokollierende Datei angeben. Es erfolgt in einer ähnlichen wie auf der Hostseite (oben beschrieben).
- Fügen Sie das
collector-device-lib
in den Make-Dateien Ihrem Test-APK hinzu:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Verwenden Sie die von uns bereitgestellte @rule, um Dateien zu protokollieren:
@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);
}
}
Der Name KEY
im obigen Beispiel ist der Name, unter dem die Datei gespeichert wird.
gemeldet. Dies ist der Name, mit dem im Feld
FilePullerDeviceMetricCollector
, um sie automatisch abzurufen. sollte es sein
eindeutigen Namen.
HINWEIS: Sobald die Datei abgerufen ist, wird automatisch FilePullerDeviceMetricCollector
vom Gerät entfernt.
Wo finde ich die Messwerte?
Das hängt von result_reporter
ab, das in Ihrer XML-Konfiguration angegeben ist.