Esta página descreve como relatar métricas junto com os resultados do teste ao gravar um teste no Tradefed.
A vantagem da geração de registros pelo pipeline do Tradefed é encontrar as métricas junto lado seus resultados funcionais. O registro de métricas pode ser feito de modo muito natural nos testes. Assim, os criadores de testes podem adicionar mais e instrumentalização.
DeviceTestCase: estilo JUnit3
Se o teste estender DeviceTestCase
em um tipo de teste no estilo JUnit3, você pode chamar o método
addTestMetric(String key, String value)
de dentro dos casos de teste a serem informados
uma métrica. Pode ser chamado várias vezes, desde que a chave seja única.
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 esteja disponível no result_reporters
, faça o seguinte:
chame o método addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream)
.
de dentro dos casos de teste para relatar 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 normal
Se você quiser relatar métricas dentro do Tradefed de um TestCase JUnit3 normal,
classe, ele precisará ser convertido em um MetricTestCase
, que é o
exatamente a mesma classe com um método extra: addTestMetric(String key, String value)
DeviceJUnit4ClassRunner: estilo JUnit4
Se o teste de estilo JUnit4 estiver sendo executado com
DeviceJUnit4ClassRunner,
você também pode registrar métricas em um caso de teste (em @Test) para serem relatadas
pela Tradefed. Você vai precisar usar TestMetrics
regras para gerar relatórios sobre as 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, você usará 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 de troca
Se estiver criando sua própria classe ou executor de testes do Tradefed, você implementará
IRemoteTest (link em inglês)
e receber um ITestInvocationListener
com o método run()
. Este listener
pode ser usado para registrar métricas da seguinte forma:
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Coletores de métricas da Tradefed
A Tradefed fornece um objeto metrics_collector
dedicado para coletar métricas em
paralelo dos testes.
No lado do organizador
BaseDeviceMetricCollector (em inglês) pode ser implementado para coletar métricas do host e relatá-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 invocação do Tradefed, basta adicionar o objeto à sua 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: * TemperaturaCollector que coleta a temperatura periodicamente durante o teste. * AtraceCollector (link em inglês) que coleta usando "atrace" para cada caso de teste.
No lado do dispositivo
Ao executar testes no lado do dispositivo (Instrumentações, testes do UIAutomator etc.), ter um coletor no 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 terá a tela desejada e ser inútil.
Para atender a esses casos de uso, existe uma versão do dispositivo dos nossos coletores e pode ser usado em qualquer "AndroidJUnitRunner" e instrumentalização. BaseMetricListener podem ser implementadas para relatar automaticamente as métricas coletadas de maneira totalmente compatível com o pipeline de relatórios do Tradefed.
Se você estiver usando o AndroidJUnitTest, runner do Tradefed, basta especificar a seguinte opção de linha de comando para executar o coletor com os testes:
--device-listeners android.device.collectors.ScreenshotListener
CUIDADO: para que as classes do coletor sejam resolvidas no tempo de execução, seus e o APK de instrumentação provavelmente precisará incluí-los estaticamente 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.
Atenção especial para suítes
Para pacotes como o CTS, que têm uma configuração de nível superior executando algum módulo
configurações diferentes, não é necessário especificar metrics_collector
em cada módulo
(AndroidTest.xml
). Na verdade, isso é proibido.
Para garantir que a coleta de métricas
seja aplicada igualmente a cada módulo,
somente 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 no lado do dispositivo notifique que alguns arquivos devem ser coletados.
AndroidTest.xml
pode especificar um coletor que procurará o arquivo na
dispositivo e extraia-os.
<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 perceber a chave, tente extrair e registrar o arquivo associado.
Para que essas chaves sejam geradas, um teste do lado do dispositivo (instrumentação) especificar o arquivo que será registrado. Isso é feito de maneira semelhante do host (descrito acima).
- Adicione o
collector-device-lib
ao APK de teste nos arquivos de criação:
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 sob o qual o arquivo será
relatadas. Esse é o nome que você deve corresponder
FilePullerDeviceMetricCollector
para extraí-lo automaticamente. ele deveria ser
um nome exclusivo.
OBSERVAÇÃO: depois que o arquivo for extraído, FilePullerDeviceMetricCollector
automaticamente
o limpa do dispositivo.
Onde encontro as métricas?
Depende do result_reporter
especificado na configuração XML.