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 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, à condition que la clé soit 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 pure Tradefed
Si vous écrivez votre propre classe ou exécuteur de test Tradefed, vous allez l'implémenter
IRemoteTest
et d'obtenir un ITestInvocationListener via la méthode run(). Cet écouteur
peut servir à enregistrer 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 disponibles pour différents cas d'utilisation, mais les nouvelles contributions sont toujours les bienvenues.
Pour spécifier le collecteur à utiliser dans votre appel Tradefed, vous 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 les données à l'aide de la méthode "atrace" pour chaque scénario de test.
Côté appareil
Lorsque vous exécutez des tests côté appareil (instrumentations, tests UIAutomator, etc.), la présence d'un collecteur côté hôte peut ne pas être idéal. Par exemple, si vous faites une capture d'écran de manière asynchrone, l’écran voulu et qu’elle ne sert à rien.
Pour répondre à ces cas d'utilisation, il existe une version de nos collecteurs côté appareil. et peut être utilisé dans n'importe quel "AndroidJUnitRunner" et l'instrumentation. BaseMetricListener peuvent être mises en œuvre 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 AndroidJUnitTest depuis Tradefed, il vous suffit de spécifier l'option de ligne de commande suivante : pour exécuter votre collecteur 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.
Attention particulière aux 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 que la collecte de métriques soit appliquée de manière égale à chaque module,
seule la configuration de premier niveau (par exemple, cts.xml) peut le 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 d'un 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 recherchera le fichier sur le
l'appareil et les extraire.
<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>
Si vous spécifiez ces modèles et ces clés, le collecteur s'il voit la clé tenter d'extraire et de consigner le fichier associé.
Pour générer ces clés, un test côté appareil (instrumentation) doit spécifier le fichier à enregistrer. Cela se fait de la même manière comme du 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 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);
}
}
Dans l'exemple ci-dessus, le nom KEY est le nom sous lequel le fichier sera
signalées. Il s'agit du nom à utiliser dans le
FilePullerDeviceMetricCollector pour qu'elle soit extraite automatiquement. elle devrait être
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 des result_reporter spécifiés dans votre configuration XML.