Esta página descreve como informar métricas com resultados de testes ao escrever um teste no Tradefed.
O benefício de fazer o registro em um pipeline do Tradefed é encontrar suas métricas junto com os resultados funcionais. O registro de métricas pode ser feito de forma muito natural em testes, o que facilita a adição de mais instrumentação pelos criadores de testes.
DeviceTestCase: estilo JUnit3
Se o teste estender DeviceTestCase
em um teste no estilo JUnit3, você poderá chamar o método
addTestMetric(String key, String value)
de dentro de qualquer caso de teste para informar
uma métrica. Ele pode ser chamado várias vezes, desde que a chave seja exclusiva.
Exemplo:
public static class TestMetricTestCase extends DeviceTestCase {
public void testPass() {
addTestMetric("key1", "metric1");
}
public void testPass2() {
addTestMetric("key2", "metric2");
}
}
Se você quiser registrar um arquivo para que ele fique disponível no result_reporters
, chame o método addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream)
de dentro de qualquer caso de teste para informar um arquivo a ser registrado.
Exemplo:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase: teste JUnit3 comum
Se você quiser gerar relatórios de métricas no Tradefed usando uma classe JUnit3 TestCase
regular, ela precisará ser convertida em um MetricTestCase
, que é a
mesma classe com um método extra: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner: estilo JUnit4
Se o teste no estilo JUnit4 estiver sendo executado com
DeviceJUnit4ClassRunner,
também é possível registrar métricas em um caso de teste (dentro de @Test) para serem informadas
pelo Tradefed. Você precisa usar regras TestMetrics
para gerar relatórios das suas métricas.
Exemplo:
@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 arquivos, use a regra TestLogData
.
Exemplo:
@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: teste puro do Tradefed
Se você estiver escrevendo sua própria classe ou executor de teste do Tradefed, implemente
IRemoteTest
e receba um ITestInvocationListener
pelo método run()
. Esse listener
pode ser usado para registrar métricas da seguinte maneira:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Coletores de métricas do Tradefed
O Tradefed fornece um objeto metrics_collector
dedicado para coletar métricas em
paralelo aos testes.
Do lado do host
BaseDeviceMetricCollector pode ser implementado para coletar qualquer métrica do lado do host e informá-las como parte da invocação do teste. Vários coletores genéricos já estão disponíveis para diferentes casos de uso, mas sempre aceitamos novas contribuições.
Para especificar o coletor a ser usado na sua invocação do Tradefed, basta adicionar o objeto à configuração XML do Tradefed:
Exemplo:
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Alguns coletores atuais: * TemperatureCollector que coleta a temperatura periodicamente durante a execução do teste. * AtraceCollector que coleta usando "atrace" para cada caso de teste.
No lado do dispositivo
Ao executar testes do lado do dispositivo (instrumentações, testes do UIAutomator etc.), ter um coletor do lado do host coletando de forma assíncrona pode não ser ideal. Por exemplo, uma captura de tela feita de forma assíncrona provavelmente não vai mostrar a tela desejada e será inútil.
Para atender a esses casos de uso, existe uma versão dos nossos coletores no dispositivo que pode ser usada em qualquer instrumentação "AndroidJUnitRunner". O BaseMetricListener pode ser implementado para gerar relatórios automáticos de métricas coletadas de maneira totalmente compatível com o pipeline de relatórios do Tradefed.
Se você estiver usando o executor AndroidJUnitTest do Tradefed, basta especificar a seguinte opção de linha de comando para que o coletor seja executado com seus testes:
--device-listeners android.device.collectors.ScreenshotListener
ATENÇÃO: para que as classes de coleta sejam resolvidas durante a execução, o APK de instrumentação provavelmente precisará incluí-las de forma estática adicionando ao makefile o seguinte:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Contribuições para coletores do lado do dispositivo também são bem-vindas.
Consideração especial para suítes
Para suítes como o CTS, que têm uma configuração de nível superior executando algumas configurações de módulo, não é necessário especificar metrics_collector
em cada configuração de módulo (AndroidTest.xml
). Na verdade, isso é proibido.
Para garantir que a coleta de métricas seja aplicada igualmente a cada módulo, apenas a configuração de nível superior (por exemplo, cts.xml
) pode especificar metrics_collector
, conforme explicado acima. Esses coletores serão aplicados e executados em cada módulo do pacote.
Coletar arquivos de registros do dispositivo de um módulo
Uma configuração está disponível para que um teste do lado do dispositivo notifique que alguns arquivos precisam ser coletados.
AndroidTest.xml
pode especificar um coletor que vai procurar e extrair arquivos do dispositivo.
<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>
Ao especificar esses padrões e a chave, o coletor, se encontrar a chave, vai tentar extrair e registrar o arquivo associado.
Para que essas chaves sejam geradas, um teste do lado do dispositivo (instrumentação) precisa especificar o arquivo que será registrado. Ele é feito de maneira semelhante ao lado do host (descrito acima).
- Adicione o
collector-device-lib
ao APK de teste nos arquivos make:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Use a @regra que fornecemos para arquivos 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);
}
}
O nome KEY
no exemplo acima é o nome em que o arquivo será
informado. Esse é o nome que você precisa corresponder no
FilePullerDeviceMetricCollector
para que ele seja extraído automaticamente. Ele precisa ser
exclusivo.
OBSERVAÇÃO: depois que o arquivo é extraído, o FilePullerDeviceMetricCollector
o limpa automaticamente do dispositivo.
Onde encontro as métricas?
Isso depende do result_reporter
especificado na sua configuração XML.