Cette page explique comment générer des rapports sur les métriques et 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 de manière très naturelle dans les tests, ce qui permet aux rédacteurs de tests d'ajouter facilement de l'instrumentation.
DeviceTestCase : style JUnit3
Si votre test étend DeviceTestCase dans un type de test de style JUnit3, vous pouvez appeler la méthode addTestMetric(String key, String value) à partir de n'importe quel scénario de test pour générer un rapport sur 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 consigner un fichier pour qu'il soit disponible dans le result_reporters, vous pouvez appeler la méthode addTestLog(String dataName, LogDataType dataType, InputStreamSource dataStream) depuis n'importe quel scénario de test pour signaler un fichier à consigner.
Exemple :
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
Scénario de test : test JUnit3 standard
Si vous souhaitez créer des rapports sur les métriques dans Tradefed à partir d'une classe TestCase JUnit3 standard, vous devez 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 consigner 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");
}
}
Vous pouvez utiliser la règle TestLogData pour signaler des fichiers.
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 exécuteur de test Tradefed, vous implémenterez IRemoteTest et obtiendrez un ITestInvocationListener via la méthode run(). Cet écouteur peut être utilisé pour consigner 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 des métriques en parallèle des tests.
Côté hôte
Vous pouvez mettre en œuvre BaseDeviceMetricCollector pour collecter des métriques côté hôte et les enregistrer dans le cadre de l'appel de test. Un certain nombre de collecteurs génériques sont déjà disponibles pour différents cas d'utilisation, mais toutes les nouvelles contributions sont les bienvenues.
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 régulièrement pendant le test * AtraceCollector qui collecte à l'aide d'un fichier "atrace" pour chaque scénario de test.
Côté appareil
Lorsque vous exécutez des tests côté appareil (instrumentations, tests UIAutomator, etc.), il n'est pas toujours idéal d'avoir un collecteur côté hôte collectant de manière asynchrone. Par exemple, une capture d'écran effectuée de manière asynchrone passera probablement à côté de 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 générer automatiquement des rapports sur les métriques collectées de manière entièrement compatible avec le pipeline de création de rapports Tradefed.
Si vous utilisez le lanceur 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 probablement les inclure de manière statique en ajoutant ce qui suit à votre fichier de compilation:
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 telles que 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). Cette opération est en réalité interdite.
Pour vous assurer que la collecte de métriques est appliquée de manière égale à chaque module, seule la configuration de niveau supérieur (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 appareil à partir d'un module
Une configuration est disponible pour qu'un test côté appareil signale que certains fichiers doivent être collectés.
AndroidTest.xml peut spécifier un collecteur qui recherche des fichiers sur l'appareil et les extrait.
<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 de récupérer 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 à consigner. Cela se fait de la même manière que côté hôte (décrit ci-dessus).
- Ajoutez le
collector-device-libà votre APK de test dans les fichiers de compilation:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Utilisez la règle @rule que nous fournissons pour créer des fichiers journaux:
@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);
}
}
Le nom KEY dans l'exemple ci-dessus est le nom 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ù puis-je trouver les métriques ?
Cela dépend de l'result_reporter spécifié dans votre configuration XML.