En esta página, se describe cómo informar métricas junto con resultados de pruebas al escribir una prueba en Tradefed.
El beneficio del registro a través de la canalización de Tradefed es que permite encontrar tus métricas tus resultados funcionales. El registro de métricas se puede realizar de forma muy natural dentro de las pruebas, lo que facilita que los escritores de pruebas agreguen más y la instrumentación.
DeviceTestCase: estilo JUnit3
Si la prueba extiende DeviceTestCase
En una prueba de estilo JUnit3, puedes llamar al método
addTestMetric(String key, String value) desde cualquier caso de prueba para informar
una métrica. Se puede llamar a este método varias veces, siempre que la clave sea única.
Ejemplo:
public static class TestMetricTestCase extends DeviceTestCase {
public void testPass() {
addTestMetric("key1", "metric1");
}
public void testPass2() {
addTestMetric("key2", "metric2");
}
}
Si quieres registrar que un archivo esté disponible en result_reporters, puedes
llama al método addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream)
desde el interior de cualquier caso de prueba
para informar un archivo que se registrará.
Ejemplo:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase: prueba JUnit3 normal
Si quieres informar métricas dentro de Tradefed desde un TestCase JUnit3 normal
, deberá convertirse en MetricTestCase, que es la
exactamente la misma clase con un método adicional: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner: estilo JUnit4
Si tu prueba de estilo JUnit4 se ejecuta con
DeviceJUnit4ClassRunner.
También puedes registrar métricas dentro de un caso de prueba (dentro de @Test) que se informarán
Tradefed. Deberá utilizar TestMetrics reglas para informar sus métricas.
Ejemplo:
@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");
}
}
Para denunciar archivos, usarás la regla TestLogData.
Ejemplo:
@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: Prueba pura de Tradefed
Si escribes tu propia clase o ejecutor de prueba de Tradefed, implementarás
IRemoteTest;
y obtén una ITestInvocationListener a través del método run(). Este objeto de escucha
se puede usar para registrar métricas de la siguiente manera:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Recopiladores de métricas de Tradefed
Tradefed proporciona un objeto metrics_collector dedicado para recopilar métricas en
paralela de las pruebas.
Del lado del host
BaseDeviceMetricCollector que se pueden implementar para recopilar métricas del host y, luego, informarlas como parte de la invocación de prueba. Varios recopiladores genéricos ya están disponibles para diferentes casos de uso, pero siempre aceptamos nuevas contribuciones.
Para especificar el recopilador que se usará en la invocación de Tradefed, solo debes agregar el objeto a tu configuración XML de Tradefed:
Ejemplo:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Estos son algunos de los recopiladores existentes en la actualidad: * TemperatureCollector (Recolector de temperatura) que recopila la temperatura periódicamente durante la ejecución de prueba. * AtraceCollector que recopila mediante “atrace” para cada caso de prueba.
Del lado del dispositivo
Cuando se ejecutan pruebas del dispositivo (instrumentaciones, pruebas de UIAutomator, etc.), es posible que no sea conveniente tener un recopilador en el host que recopile de forma asíncrona ideal. Por ejemplo, una captura de pantalla que se toma de forma asincrónica probablemente no tenga en cuenta que quería la pantalla y fueran inútiles.
Para cumplir con estos casos de uso, existe una versión del dispositivo de nuestros recopiladores y puede usarse en cualquier instancia de "AndroidJUnitRunner" y la instrumentación. BaseMetricListener Se pueden implementar para informar automáticamente las métricas recopiladas y completamente compatible con la canalización de informes de Tradefed.
Si usas "AndroidJUnitTest" de Tradefed, puedes especificar la siguiente opción de línea de comandos para que tu colector se ejecute con tus pruebas:
--device-listeners android.device.collectors.ScreenshotListener
PRECAUCIÓN: Para que las clases de colector se resuelvan en el entorno de ejecución, tu lo más probable es que el APK de instrumentación deba incluirlos de forma estática agregando al archivo makefile:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Las contribuciones a los recopiladores del dispositivo también son bienvenidas.
Consideración especial para suites
Para paquetes como CTS que tienen una configuración de nivel superior que ejecuta algún módulo
no es necesario especificar metrics_collector en cada módulo
configuración (AndroidTest.xml). En realidad, está prohibido.
Para garantizar que la recopilación de métricas se aplique de forma equitativa a cada módulo,
solo la configuración de nivel superior (por ejemplo, cts.xml) puede especificar
metrics_collector, como se explicó anteriormente. Estos recopiladores se aplicarán y se ejecutarán
en cada módulo del paquete.
Cómo recopilar archivos de registro del dispositivo de un módulo
Hay una configuración disponible para que una prueba lateral del dispositivo notifique que algunos archivos que se deben recopilar.
AndroidTest.xml puede especificar un recopilador que buscará un archivo en el
el dispositivo y extraerlos.
<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>
Cuando se especifican estos patrones y esta clave, el recopilador, si ve la clave, intenta extraer y registrar el archivo asociado.
Para que se generen estas claves, se debe realizar una prueba del lado del dispositivo (instrumentación) debe especificar el archivo que se debe registrar. Se hace de manera similar que en el lado del host (descrita anteriormente).
- Agrega el
collector-device-libal APK de prueba en los archivos Make:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Usa la @rule que proporcionamos para los archivos de registro:
@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);
}
}
El nombre KEY del ejemplo anterior es el nombre con el que se incluirá el archivo
informes. Este es el nombre que debes hacer coincidir en la
FilePullerDeviceMetricCollector para que se extraiga automáticamente. debería ser
con un nombre único.
NOTA: Una vez que se extrae el archivo, FilePullerDeviceMetricCollector automáticamente.
lo limpia del dispositivo.
¿Dónde puedo encontrar las métricas?
Depende del result_reporter especificado en tu configuración XML.