Cette page décrit comment rapporter les métriques ainsi que les résultats des tests lors de la rédaction d'un test dans Tradefed.
L'avantage de la connexion via le pipeline Tradefed est de trouver vos métriques ainsi que vos résultats fonctionnels. La journalisation des métriques peut être effectuée très naturellement au sein des tests, ce qui permet aux rédacteurs de tests d'ajouter plus d'instruments.
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)
depuis n'importe quel scénario de test pour signaler une métrique. Cela peut être appelé 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 qu'un fichier 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 à enregistrer.
Exemple:
public static class TestLogTestCase extends DeviceTestCase {
public void testPass() {
try (InputStreamSource source = getDevice().getScreenshot()) {
addTestLog("screenshot", LogDataType.PNG, source);
}
}
}
TestCase - test JUnit3 régulier
Si vous souhaitez rapporter des métriques dans Tradefed à partir d'une classe JUnit3 TestCase standard, elle devra plutôt ê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 également enregistrer les métriques dans un scénario de test (à l'intérieur de @Test) qui seront signalées par Tradefed. Vous devrez utiliser les règles TestMetrics
pour signaler 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");
}
}
Afin de signaler des fichiers, vous utiliserez la règle TestLogData
pour le signaler.
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 - pur test Tradefed
Si vous écrivez votre propre classe ou runner Tradefed Test, vous implémenterez IRemoteTest et obtiendrez un ITestInvocationListener
via la méthode run()
. Cet écouteur 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 des métriques en parallèle des tests.
Du côté de l'hôte
BaseDeviceMetricCollector peut être implémenté pour collecter toutes les métriques du côté hôte et les signaler dans le cadre de l'invocation du test. Un certain nombre de collecteurs génériques sont déjà disponibles pour différents cas d'utilisation, mais nous sommes toujours ouverts à de nouvelles contributions.
Afin de spécifier le collecteur à utiliser dans votre invocation 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>
Quelques collecteurs actuellement existants : * TemperatureCollector qui collecte périodiquement la température pendant le test. * AtraceCollector qui collecte à l'aide de « atrace » pour chaque cas de test.
Du côté de l'appareil
Lors de l'exécution de tests côté appareil (Instrumentations, tests UIAutomator, etc.), disposer d'un collecteur côté hôte collectant de manière asynchrone n'est peut-être pas idéal. Par exemple, une capture d’écran prise de manière asynchrone manquera probablement l’écran souhaité et sera inutile.
Afin de 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é afin de signaler automatiquement les métriques collectées d'une manière entièrement compatible avec le pipeline de reporting Tradefed.
Si vous utilisez le programme d'exécution ' 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 statiquement en ajoutant à votre makefile ce qui suit :
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
Les contributions aux collectionneurs côté appareil sont également les bienvenues.
Considération particulière pour les suites
Pour les suites comme CTS qui ont une configuration de niveau supérieur 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 effectivement interdit.
Pour garantir que la collection 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 de périphérique à partir 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, s'il voit la clé, tentera d'extraire et de consigner le fichier associé.
Pour que ces clés soient générées, un test côté appareil (instrumentation) doit spécifier le fichier qui doit être enregistré. Cela se fait de la même manière que du côté hôte (décrit ci-dessus).
- Ajoutez le
collector-device-lib
à votre APK de test dans les fichiers make :
LOCAL_STATIC_JAVA_LIBRARIES += collector-device-lib
- Utilisez la @rule que nous fournissons pour enregistrer 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);
}
}
Le nom KEY
dans l'exemple ci-dessus est le nom sous lequel le fichier sera signalé. C'est le nom que vous devez faire correspondre dans FilePullerDeviceMetricCollector
pour qu'il soit automatiquement extrait. ce devrait être un nom unique.
REMARQUE : Une fois le fichier extrait, FilePullerDeviceMetricCollector
le nettoie automatiquement de l'appareil.
Où puis-je trouver les métriques ?
Cela dépend du result_reporter
spécifié dans votre configuration XML.