Cycle de vie du test TF,Cycle de vie du test TF

Le cycle de vie d'un test exécuté à l'aide de Trade Federation est composé de quatre étapes distinctes, conçues autour d'interfaces formellement définies.

Interfaces définies

  • Fournisseur de build : Fournit un build à tester, en téléchargeant les fichiers appropriés si nécessaire.
  • Préparateur cible : prépare l'environnement de test, y compris éventuellement l'installation du logiciel et la configuration de l'appareil.
  • Test : Exécute le(s) test(s) et rassemble les résultats des tests. Il peut s'agir de n'importe quel test JUnit, bien que notre interface IRemoteTest soit spécifiquement conçue pour bien fonctionner dans l'environnement de la fédération commerciale.
  • Test Invocation Listener (reporting des résultats) : écoute les résultats des tests, généralement dans le but de transmettre les résultats des tests à un référentiel ou de les afficher au Test Runner.

L'entité de test fondamentale dans TF est une configuration (config). Une configuration est un fichier XML qui déclare les composants du cycle de vie d'un test.

Cette séparation du cycle de vie du test est destinée à permettre sa réutilisation. Grâce à cette conception, le développeur peut créer un test une seule fois, puis l'intégrateur peut créer différentes configurations pour exécuter ce test dans différents environnements. Par exemple, ils peuvent créer une configuration qui exécutera un test sur une machine locale et videra le résultat sur stdout. Ils pourraient ensuite créer une deuxième configuration qui exécuterait le même test, mais utiliserait un écouteur d'invocation de test différent pour stocker les résultats du test dans une base de données. Une troisième configuration pourrait être conçue pour exécuter ce test en continu à partir d'un laboratoire de test quelque part.

Il est pratique de noter ici qu'une Configuration avec ses arguments de ligne de commande (tels que fournis par le Test Runner) est connue sous le nom de Command . Lorsque TF associe une commande à un ITestDevice et l'exécute, l'objet suivant est appelé Invocation . En bref, une invocation englobe une exécution complète du test TF, tout au long de son cycle de vie.

Composants de configuration supplémentaires

  • Device Recovery : mécanisme permettant de récupérer la communication de l'appareil en cas de perte.
  • Logger : collecte les données de journalisation tradefed.

Sortie d'étage et erreurs

Chaque étape d'une invocation s'exécute de manière séquentielle et a un objectif spécifique. Cette section décrit les sorties et les erreurs habituelles de chaque étape.

Fournisseur de build

Cette étape crée et génère un objet IBuildInfo qui contient toutes les références de fichiers requises pour configurer et exécuter les tests.

L'erreur la plus courante à ce stade est l'échec du téléchargement ou de la recherche des fichiers demandés.

Une erreur à ce stade entraîne le signalement direct de l'erreur et l'exécution d'aucun test.

Préparation cible

Cette étape met en place les états nécessaires pour la cible testée. Cette étape peut modifier la configuration de l'appareil ou de l'hôte selon les besoins pour l'appel de test donné.

Les erreurs courantes à ce stade impliquent généralement l'échec de la configuration de l'appareil dans un état donné (par exemple, l'échec du clignotement) et l'échec de la recherche des fichiers requis pour la configuration.

Une erreur à ce stade entraîne l'exécution du nettoyage de la cible, le signalement de l'erreur et l'exécution d'aucun test.

Essais

Cette étape exécute les tests demandés sur la cible préalablement préparée et rapporte tous les résultats d'exécution des tests.

Les erreurs courantes à ce stade impliquent généralement que la cible testée est indisponible ou une erreur provoquant une exécution partielle des tests. Ces erreurs sont des problèmes d'infrastructure qui affectent l'exécution du test lui-même, par opposition à l'échec d'un seul cas de test.

Une erreur à ce stade entraîne l'arrêt de l'exécution du test, l'exécution du nettoyage de la cible, le signalement de l'erreur et l'obtention de résultats partiels.

Communication des résultats

Cette étape signale les résultats et les erreurs aux services configurés (par exemple, les serveurs et les fichiers locaux).

Bien que les rapporteurs de résultats individuels puissent avoir des erreurs, ils sont isolés les uns des autres (un rapporteur ne voit pas les erreurs d'un autre). Ces erreurs n'affectent que les rapports de résultats d'un rapporteur individuel et les erreurs peuvent être visualisées dans les journaux.

,

Le cycle de vie d'un test exécuté à l'aide de Trade Federation est composé de quatre étapes distinctes, conçues autour d'interfaces formellement définies.

Interfaces définies

  • Fournisseur de build : Fournit un build à tester, en téléchargeant les fichiers appropriés si nécessaire.
  • Préparateur cible : prépare l'environnement de test, y compris éventuellement l'installation du logiciel et la configuration de l'appareil.
  • Test : Exécute le(s) test(s) et rassemble les résultats des tests. Il peut s'agir de n'importe quel test JUnit, bien que notre interface IRemoteTest soit spécifiquement conçue pour bien fonctionner dans l'environnement de la fédération commerciale.
  • Test Invocation Listener (reporting des résultats) : écoute les résultats des tests, généralement dans le but de transmettre les résultats des tests à un référentiel ou de les afficher au Test Runner.

L'entité de test fondamentale dans TF est une configuration (config). Une configuration est un fichier XML qui déclare les composants du cycle de vie d'un test.

Cette séparation du cycle de vie du test est destinée à permettre sa réutilisation. Grâce à cette conception, le développeur peut créer un test une seule fois, puis l'intégrateur peut créer différentes configurations pour exécuter ce test dans différents environnements. Par exemple, ils peuvent créer une configuration qui exécutera un test sur une machine locale et videra le résultat sur stdout. Ils pourraient ensuite créer une deuxième configuration qui exécuterait le même test, mais utiliserait un écouteur d'invocation de test différent pour stocker les résultats du test dans une base de données. Une troisième configuration pourrait être conçue pour exécuter ce test en continu à partir d'un laboratoire de test quelque part.

Il est pratique de noter ici qu'une Configuration avec ses arguments de ligne de commande (tels que fournis par le Test Runner) est connue sous le nom de Command . Lorsque TF associe une commande à un ITestDevice et l'exécute, l'objet suivant est appelé Invocation . En bref, une invocation englobe une exécution complète du test TF, tout au long de son cycle de vie.

Composants de configuration supplémentaires

  • Device Recovery : mécanisme permettant de récupérer la communication de l'appareil en cas de perte.
  • Logger : collecte les données de journalisation tradefed.

Sortie d'étage et erreurs

Chaque étape d'une invocation s'exécute de manière séquentielle et a un objectif spécifique. Cette section décrit les sorties et les erreurs habituelles de chaque étape.

Fournisseur de build

Cette étape crée et génère un objet IBuildInfo qui contient toutes les références de fichiers requises pour configurer et exécuter les tests.

L'erreur la plus courante à ce stade est l'échec du téléchargement ou de la recherche des fichiers demandés.

Une erreur à ce stade entraîne le signalement direct de l'erreur et l'exécution d'aucun test.

Préparation cible

Cette étape met en place les états nécessaires pour la cible testée. Cette étape peut modifier la configuration de l'appareil ou de l'hôte selon les besoins pour l'appel de test donné.

Les erreurs courantes à ce stade impliquent généralement l'échec de la configuration de l'appareil dans un état donné (par exemple, l'échec du clignotement) et l'échec de la recherche des fichiers requis pour la configuration.

Une erreur à ce stade entraîne l'exécution du nettoyage de la cible, le signalement de l'erreur et l'exécution d'aucun test.

Essais

Cette étape exécute les tests demandés sur la cible préalablement préparée et rapporte tous les résultats d'exécution des tests.

Les erreurs courantes à ce stade impliquent généralement que la cible testée est indisponible ou une erreur provoquant une exécution partielle des tests. Ces erreurs sont des problèmes d'infrastructure qui affectent l'exécution du test lui-même, par opposition à l'échec d'un seul cas de test.

Une erreur à ce stade entraîne l'arrêt de l'exécution du test, l'exécution du nettoyage de la cible, le signalement de l'erreur et l'obtention de résultats partiels.

Communication des résultats

Cette étape signale les résultats et les erreurs aux services configurés (par exemple, les serveurs et les fichiers locaux).

Bien que les rapporteurs de résultats individuels puissent avoir des erreurs, ils sont isolés les uns des autres (un rapporteur ne voit pas les erreurs d'un autre). Ces erreurs n'affectent que les rapports de résultats d'un rapporteur individuel et les erreurs peuvent être visualisées dans les journaux.