Esta página describe cómo informar las métricas junto con los resultados de las pruebas al escribir una prueba en Tradefed.
El beneficio de iniciar sesión a través de la canalización de Tradefed es encontrar sus métricas junto con sus resultados funcionales. El registro de métricas se puede realizar de forma muy natural dentro de las pruebas, lo que facilita que los redactores de pruebas agreguen más instrumentación.
DeviceTestCase - estilo JUnit3
Si su prueba extiende DeviceTestCase en un tipo de prueba de estilo JUnit3, puede llamar al método addTestMetric(String key, String value) desde dentro de cualquier caso de prueba para informar una métrica. Esto se puede llamar 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 desea registrar un archivo para que esté disponible en result_reporters , puede llamar al método addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) desde dentro de cualquier caso de prueba para informar un archivo para registrar.
Ejemplo:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase - prueba regular JUnit3
Si desea informar métricas dentro de Tradefed desde una clase JUnit3 TestCase regular, deberá convertirse a MetricTestCase que es exactamente la misma clase con un método adicional: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner - estilo JUnit4
Si su prueba de estilo JUnit4 se ejecuta con DeviceJUnit4ClassRunner , también puede registrar métricas dentro de un caso de prueba (dentro de @Test) para que Tradefed las informe. Deberá usar las reglas de TestMetrics 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 informar archivos, utilizará la regla TestLogData para informarlo.
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 está escribiendo su propia clase o corredor de prueba de Tradefed, implementará IRemoteTest y obtendrá un ITestInvocationListener a través del método run() . Este oyente se puede utilizar para registrar métricas de la siguiente manera:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Recolectores de métricas Tradefed
Tradefed proporciona un objeto metrics_collector dedicado para recopilar métricas en paralelo a las pruebas.
En el lado del anfitrión
BaseDeviceMetricCollector se puede implementar para recopilar métricas del lado del host e informarlas como parte de la invocación de prueba. Ya hay disponibles varios recopiladores genéricos para diferentes casos de uso, pero siempre damos la bienvenida a nuevas contribuciones.
Para especificar el recopilador que se usará en su invocación de Tradefed, simplemente necesita agregar el objeto a su configuración XML de Tradefed:
Ejemplo:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Algunos colectores existentes actualmente: * TemperatureCollector que recoge la temperatura periódicamente durante la ejecución de la prueba. * AtraceCollector que recopila usando 'atrace' para cada caso de prueba.
En el lado del dispositivo
Cuando se ejecutan pruebas del lado del dispositivo (instrumentación, pruebas de UIAutomator, etc.), tener un recopilador en el lado del host que recopile de forma asincrónica podría no ser lo ideal. Por ejemplo, una captura de pantalla tomada de forma asíncrona probablemente perderá la pantalla deseada y será inútil.
Para cumplir con estos casos de uso, existe una versión del lado del dispositivo de nuestros recopiladores y se puede usar en cualquier instrumentación 'AndroidJUnitRunner'. BaseMetricListener se puede implementar para informar automáticamente las métricas que se recopilan de una manera totalmente compatible con la canalización de informes de Tradefed.
Si está utilizando el corredor ' AndroidJUnitTest ' de Tradefed, simplemente puede especificar la siguiente opción de línea de comando para que su recopilador se ejecute con sus pruebas:
--device-listeners android.device.collectors.ScreenshotListener
PRECAUCIÓN: Para que las clases de recopiladores se resuelvan en tiempo de ejecución, lo más probable es que su APK de instrumentación deba incluirlas estáticamente agregando a su archivo MAKE lo siguiente:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Las contribuciones a los recopiladores del lado del dispositivo también son bienvenidas.
Consideración especial para suites
Para conjuntos como CTS que tienen una configuración de nivel superior que ejecuta algunas configuraciones de módulos, no es necesario especificar metrics_collector en cada configuración de módulo ( AndroidTest.xml ). En realidad está prohibido.
Para garantizar que la recopilación de métricas se aplique por igual 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 ejecutarán en cada módulo de la suite.
¿Cómo recopilar archivos de registro de dispositivos de un módulo?
Hay una configuración disponible para que una prueba del lado del dispositivo notifique que se deben recopilar algunos archivos.
AndroidTest.xml puede especificar un recopilador que buscará archivos en el dispositivo y los extraerá.
<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>
Al especificar estos patrones y clave, el recopilador, si ve la clave, intentará extraer y registrar el archivo asociado.
Para que se generen estas claves, una prueba del lado del dispositivo (instrumentación) debe especificar el archivo que debe registrarse. Se realiza de manera similar al lado del host (descrito anteriormente).
- Agregue el
collector-device-liba su APK de prueba en los archivos de creación:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Utilice la @regla que proporcionamos para registrar archivos:
@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 en el ejemplo anterior es el nombre bajo el cual se informará el archivo. Este es el nombre que debe hacer coincidir en FilePullerDeviceMetricCollector para que se extraiga automáticamente. debe ser un nombre único.
NOTA: Una vez que se extrae el archivo, FilePullerDeviceMetricCollector lo limpia automáticamente del dispositivo.
¿Dónde encontrar las métricas?
Depende del result_reporter especificado en su configuración XML.