Cette page explique comment signaler des métriques avec les résultats des tests lorsque vous écrivez un test dans Tradefed.
L'avantage de la journalisation via le pipeline Tradefed est de trouver vos métriques à côté de vos résultats fonctionnels. La journalisation des métriques peut être effectuée très naturellement dans les tests, ce qui permet aux rédacteurs de tests d'ajouter plus d'instrumentation.
DeviceTestCase : style JUnit3
Si votre test étend DeviceTestCase dans un type de test JUnit3, vous pouvez appeler la méthode addTestMetric(String key, String value) depuis n'importe quel scénario de test pour signaler une métrique. Cette méthode peut être appelée plusieurs fois tant que la clé est unique.
Exemple :
public static class TestMetricTestCase extends DeviceTestCase {
public void testPass() {
addTestMetric("key1", "metric1");
}
public void testPass2() {
addTestMetric("key2", "metric2");
}
}
Si vous souhaitez enregistrer un fichier pour qu'il soit disponible dans result_reporters, vous pouvez appeler la méthode addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) à partir de n'importe quel scénario de test pour signaler un fichier à enregistrer.
Exemple :
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase : test JUnit3 standard
Si vous souhaitez générer des rapports sur les métriques dans Tradefed à partir d'une classe TestCase JUnit3 standard, vous devrez la convertir en MetricTestCase, qui est exactement la même classe avec une méthode supplémentaire : addTestMetric(String key, String value).
DeviceJUnit4ClassRunner – style JUnit4
Si votre test de style JUnit4 s'exécute avec DeviceJUnit4ClassRunner, vous pouvez également enregistrer des métriques dans un scénario de test (dans @Test) pour qu'elles soient signalées par Tradefed. Vous devrez utiliser des règles TestMetrics pour générer des rapports sur vos métriques.
Exemple :
@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");
}
}
Pour signaler des fichiers, vous devez utiliser la règle TestLogData.
Exemple :
@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 : test Tradefed pur
Si vous écrivez votre propre classe ou runner de test Tradefed, vous implémenterez IRemoteTest et obtiendrez un ITestInvocationListener via la méthode run(). Ce listener peut être utilisé pour enregistrer les métriques comme suit :
listener.testLog(String dataName, LogDataType type of data, InputStreamSource data);
Collecteurs de métriques Tradefed
Tradefed fournit un objet metrics_collector dédié pour collecter les métriques en parallèle des tests.
Côté hôte
BaseDeviceMetricCollector peut être implémenté pour collecter des métriques côté hôte et les signaler dans l'invocation de test. Un certain nombre de collecteurs génériques sont déjà disponibles pour différents cas d'utilisation, mais nous accueillons toujours de nouvelles contributions.
Pour spécifier le collecteur à utiliser dans votre appel Tradefed, il vous suffit d'ajouter l'objet à votre configuration XML Tradefed :
Exemple :
<metrics_collector class="com.android.tradefed.device.metric.AtraceCollector">
<option name="categories" value="freq"/>
</metrics_collector>
Voici quelques collecteurs existants : * TemperatureCollector, qui collecte la température périodiquement pendant l'exécution du test. * AtraceCollector qui collecte les données à l 'aide d'atrace pour chaque scénario de test.
Sur l'appareil
Lors de l'exécution de tests côté appareil (instrumentations, tests UIAutomator, etc.), il n'est peut-être pas idéal d'avoir un collecteur côté hôte qui collecte les données de manière asynchrone. Par exemple, une capture d'écran effectuée de manière asynchrone manquera très probablement l'écran souhaité et sera inutile.
Pour répondre à ces cas d'utilisation, une version côté appareil de nos collecteurs existe et peut être utilisée dans n'importe quelle instrumentation "AndroidJUnitRunner". BaseMetricListener peut être implémenté pour signaler automatiquement les métriques collectées de manière entièrement compatible avec le pipeline de reporting Tradefed.
Si vous utilisez le runner AndroidJUnitTest de Tradefed, vous pouvez simplement spécifier l 'option de ligne de commande suivante pour que votre collecteur s'exécute avec vos tests :
--device-listeners android.device.collectors.ScreenshotListener
ATTENTION : Pour que les classes de collecteur soient résolues au moment de l'exécution, votre APK d'instrumentation devra très probablement les inclure de manière statique en ajoutant les éléments suivants à votre fichier makefile :
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Les contributions aux collecteurs côté appareil sont également les bienvenues.
Considérations particulières pour les suites
Pour les suites comme CTS qui ont une configuration de premier niveau exécutant certaines configurations de module, il n'est pas nécessaire de spécifier metrics_collector dans chaque configuration de module (AndroidTest.xml). C'est même interdit.
Pour que la collecte de métriques s'applique de manière égale à chaque module, seule la configuration de premier niveau (par exemple, cts.xml) peut spécifier metrics_collector, comme expliqué ci-dessus. Ces collecteurs seront appliqués et exécutés sur chaque module de la suite.
Collecter les fichiers journaux d'un module
Une configuration est disponible pour qu'un test côté appareil indique que certains fichiers doivent être collectés.
AndroidTest.xml peut spécifier un collecteur qui recherchera les fichiers sur l'appareil et les extraira.
<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>
En spécifiant ces modèles et cette clé, le collecteur tentera d'extraire et de consigner le fichier associé s'il voit la clé.
Pour que ces clés soient générées, un test côté appareil (instrumentation) doit spécifier le fichier à enregistrer. Elle s'effectue de la même manière que côté hôte (décrit ci-dessus).
- Ajoutez
collector-device-libà votre APK de test dans les fichiers make :
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Utilisez la règle @que nous fournissons pour consigner les fichiers :
@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);
}
}
Dans l'exemple ci-dessus, le nom KEY est celui sous lequel le fichier sera signalé. Il s'agit du nom que vous devez faire correspondre dans FilePullerDeviceMetricCollector pour qu'il soit extrait automatiquement. Il doit s'agir d'un nom unique.
REMARQUE : Une fois le fichier extrait, FilePullerDeviceMetricCollector le supprime automatiquement de l'appareil.
Où trouver les métriques ?
Cela dépend de la result_reporter spécifiée dans votre configuration XML.