Cette page explique comment générer des rapports sur les métriques et les résultats des tests lors de la rédaction 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. L'enregistrement des métriques peut s'effectuer de manière très naturelle dans les tests, ce qui permet aux rédacteurs de tests d'ajouter facilement et l'instrumentation.
DeviceTestCase – style JUnit3
Si votre test étend DeviceTestCase
Dans un type de test de type JUnit3, vous pouvez appeler la méthode
addTestMetric(String key, String value) à partir de n'importe quel scénario de test à 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 consigner un fichier pour qu'il soit disponible dans 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 générer des rapports sur les métriques dans Tradefed à partir d'un scénario de test JUnit3 standard
, elle doit être convertie 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 aussi enregistrer les métriques dans un scénario de test (dans @Test)
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 échangées
Tradefed fournit un objet metrics_collector dédié pour collecter des métriques
en parallèle des tests.
Côté hôte
BaseDeviceMetricCollector peuvent être implémentés pour collecter des métriques côté hôte et les signaler lors 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 "atrace" pour chaque scénario de test.
Sur l'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 prise de manière asynchrone ne capturera probablement pas 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, l'APK d'instrumentation devra probablement les inclure de manière statique en ajoutant à votre fichier makefile, comme suit:
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Toute contribution aux collecteurs côté appareil est également la bienvenue.
Considérations particulières pour les suites
Pour les suites comme CTS avec une configuration de niveau supérieur exécutant un module
il n'est pas nécessaire de spécifier metrics_collector dans chaque module.
(AndroidTest.xml). C'est en fait interdit.
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 s'exécuteront
pour chaque module de la suite.
Collecter les fichiers journaux de l'appareil à partir d'un module
Une configuration est disponible pour qu'un test côté appareil puisse vous avertir que certains fichiers doivent être collectées.
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 comme du 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 que nous fournissons pour les 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 automatiquement
le nettoie de l'appareil.
Où se trouvent les métriques ?
Cela dépend de l'result_reporter spécifié dans votre configuration XML.