Auf dieser Seite wird beschrieben, wie Sie beim Schreiben eines Tests in Tradefed Metriken zusammen mit Testergebnissen melden.
Der Vorteil der Protokollierung über die Tradefed-Pipeline besteht darin, dass Sie Ihre Kennzahlen neben Ihren Funktionsergebnissen finden. Die Protokollierung von Metriken kann innerhalb von Tests ganz natürlich erfolgen, sodass Testautoren bequem weitere Instrumente hinzufügen können.
DeviceTestCase – JUnit3-Stil
Wenn Ihr Test DeviceTestCase in einem Test im JUnit3-Stil erweitert, können Sie die Methode addTestMetric(String key, String value) aus beliebigen Testfällen heraus aufrufen, um eine Metrik zu melden. Dies kann mehrfach 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, damit sie im result_reporters verfügbar ist, können Sie die Methode addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) aus beliebigen Testfällen heraus aufrufen, um eine zu protokollierende Datei zu melden.
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 Metriken in Tradefed aus einer regulären JUnit3-TestCase-Klasse melden möchten, muss diese stattdessen in einen MetricTestCase konvertiert werden, der genau dieselbe Klasse mit einer zusätzlichen Methode ist: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner – JUnit4-Stil
Wenn Ihr Test im JUnit4-Stil mit DeviceJUnit4ClassRunner ausgeführt wird, können Sie auch Metriken innerhalb eines Testfalls (innerhalb von @Test) protokollieren, um sie von Tradefed zu melden. Sie müssen TestMetrics Regeln verwenden, um Ihre Metriken zu melden.
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");
}
}
Um Dateien zu melden, verwenden Sie die TestLogData Regel, um sie zu melden.
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 Ihre eigene Tradefed-Testklasse oder Ihren eigenen Tradefed-Testläufer schreiben, implementieren Sie IRemoteTest und erhalten einen ITestInvocationListener über die run() Methode. Mit diesem Listener können Metriken wie folgt protokolliert werden:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Tradefed-Metriksammler
Tradefed stellt ein dediziertes metrics_collector Objekt zur Verfügung, um parallel zu den Tests Metriken zu sammeln.
Auf der Gastgeberseite
BaseDeviceMetricCollector kann implementiert werden, um beliebige Metriken von der Hostseite zu sammeln und sie als Teil des Testaufrufs zu melden. Für verschiedene Anwendungsfälle sind bereits eine Reihe generischer Kollektoren verfügbar, wir freuen uns jedoch jederzeit über neue Beiträge.
Um den Collector anzugeben, der in Ihrem Tradefed-Aufruf verwendet werden soll, müssen Sie lediglich das Objekt zu Ihrer Tradefed-XML-Konfiguration hinzufügen:
Beispiel:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Einige derzeit vorhandene Kollektoren: * TemperatureCollector , der während des Testlaufs periodisch die Temperatur sammelt. * AtraceCollector , der für jeden Testfall mithilfe von „atrace“ Daten sammelt.
Auf der Geräteseite
Beim Ausführen von geräteseitigen Tests (Instrumentierungen, UIAutomator-Tests usw.) ist es möglicherweise nicht ideal, einen Collector auf der Hostseite zu haben, der asynchron sammelt. Beispielsweise wird ein asynchron aufgenommener Screenshot höchstwahrscheinlich den gewünschten Bildschirm verfehlen und unbrauchbar sein.
Um diese Anwendungsfälle zu erfüllen, gibt es eine geräteseitige Version unserer Kollektoren, die in jeder „AndroidJUnitRunner“-Instrumentierung verwendet werden kann. BaseMetricListener kann implementiert werden, um automatisch erfasste Metriken zu melden, die vollständig kompatibel mit der Tradefed-Reporting-Pipeline sind.
Wenn Sie den Runner „ AndroidJUnitTest “ von Tradefed verwenden, können Sie einfach die folgende Befehlszeilenoption angeben, damit Ihr Collector mit Ihren Tests ausgeführt wird:
--device-listeners android.device.collectors.ScreenshotListener
ACHTUNG: Damit die Collector-Klassen zur Laufzeit aufgelöst werden können, muss Ihr Instrumentierungs-APK sie höchstwahrscheinlich statisch einschließen, indem Sie Folgendes zu Ihrem Makefile hinzufügen:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Auch Beiträge an geräteseitige Sammler sind willkommen.
Besondere Berücksichtigung für Suiten
Für Suiten wie CTS, die über eine Top-Level-Konfiguration verfügen, auf der einige Modulkonfigurationen ausgeführt werden, ist es nicht erforderlich, metrics_collector in jeder Modulkonfiguration ( AndroidTest.xml ) anzugeben. Eigentlich ist es verboten.
Um sicherzustellen, dass die Metriksammlung gleichermaßen auf jedes Modul angewendet wird, kann nur die Konfiguration der obersten Ebene (z. B. cts.xml ) metrics_collector wie oben erläutert angeben. Diese Kollektoren werden auf jedes Modul der Suite angewendet und ausgeführt.
Sammeln Sie Geräteprotokolldateien von einem Modul
Für einen geräteseitigen Test ist ein Setup verfügbar, um zu benachrichtigen, dass einige Dateien erfasst werden sollten.
AndroidTest.xml kann einen Collector angeben, der nach Dateien auf dem Gerät sucht und diese 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 Schlüssel versucht der Collector, wenn er den Schlüssel erkennt, die zugehörige Datei abzurufen und zu protokollieren.
Damit diese Schlüssel generiert werden können, sollte ein geräteseitiger Test (Instrumentierung) die Datei angeben, die protokolliert werden soll. Dies erfolgt auf ähnliche Weise wie auf der Hostseite (oben beschrieben).
- Fügen Sie die
collector-device-libzu Ihrem Test-APK in den Make-Dateien 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 KEY Name im obigen Beispiel ist der Name, unter dem die Datei gemeldet wird. Dies ist der Name, den Sie im FilePullerDeviceMetricCollector abgleichen sollten, damit er automatisch abgerufen wird. es sollte ein eindeutiger Name sein.
HINWEIS: Sobald die Datei abgerufen wurde, bereinigt FilePullerDeviceMetricCollector sie automatisch vom Gerät.
Wo finde ich die Kennzahlen?
Dies hängt vom result_reporter ab, der in Ihrer XML-Konfiguration angegeben ist.