Trade Federation (Tradefed ou TF en abrégé) est un cadre de test continu conçu pour exécuter des tests sur les appareils Android. Par exemple, Tradefed est utilisé pour exécuter la suite de tests de compatibilité (CTS) et la suite de tests des fournisseurs (VTS) .
Trade Federation est une application Java qui s'exécute sur un ordinateur hôte et communique avec un ou plusieurs appareils Android à l'aide de ddmlib (la bibliothèque derrière DDMS) via adb.
Nous avons répertorié ci-dessous certaines des principales fonctionnalités de TF, ainsi que quelques exemples de cas d'utilisation. Cela dit, si vous souhaitez vous lancer et commencer, vous pouvez vous diriger directement vers la page Commencer ici .
Caractéristiques
- conception modulaire, flexible et évolutive
- a intégré la prise en charge de l'exécution de nombreux types de tests Android : instrumentation , uiautomator , natif/gtest, JUnit basé sur l'hôte, etc.
- fournit des mécanismes de fiabilité et de récupération en plus d'adb
- prend en charge la planification et l'exécution de tests sur plusieurs appareils en parallèle
Consultez Tests via TF pour obtenir les informations les plus récentes sur la façon d’exécuter vos tests existants, tels que Instrumentation .
Cas d'utilisation
La modularité de Trade Federation facilite son intégration dans des environnements dotés d'infrastructures de construction, de test et de reporting existantes. Nous énumérons ci-dessous quelques cas d'utilisation démonstratifs dans lesquels tradefed pourrait permettre des pratiques de test efficaces et évolutives.
Tout d'abord, il est utile de considérer l'ensemble des cas d'utilisation potentiels en fonction de la question « quelles parties sont modifiables et quelles parties sont statiques ? » Par exemple, un OEM d’appareil peut modifier la structure, le système et le matériel, mais a peu ou pas d’influence sur les applications existantes. Un développeur d’applications, en revanche, peut modifier l’application, mais a peu de contrôle sur la plupart des aspects du système ou du framework.
En conséquence, une entité dans chaque cas d’utilisation aura des objectifs de test différents et disposera de différentes options en cas d’échec de test. Malgré ces différences, Trade Federation peut contribuer à rendre chacun de ses processus de test efficaces, flexibles et évolutifs.
Fabricant de l'appareil
Un OEM d’appareil construit du matériel et modifie souvent le système et les frameworks Android pour qu’ils fonctionnent correctement sur ce matériel. L'OEM pourrait s'efforcer d'atteindre ces objectifs tout en conservant la stabilité et les performances au niveau du matériel et du système, et en s'assurant que les modifications apportées au cadre ne rompent pas la compatibilité avec les applications existantes.
L'OEM pourrait implémenter un module de flashage de périphérique qui s'exécutera pendant la phase de configuration de la cible du cycle de vie . Ce module aurait un contrôle complet sur le périphérique pendant sa période d'exécution, ce qui lui permettrait potentiellement de forcer le périphérique à entrer dans le chargeur de démarrage, à flasher, puis de forcer le périphérique à redémarrer en mode espace utilisateur. Combiné avec un module à relier à un système de construction continue, cela permettrait à l'OEM d'exécuter des tests sur son appareil à mesure qu'il apporte des modifications au micrologiciel au niveau du système et aux frameworks au niveau Java.
Une fois l'appareil entièrement démarré, l'OEM serait en mesure d'exploiter les tests JUnit existants, ou d'en écrire de nouveaux, pour vérifier la fonctionnalité qui l'intéresse. Enfin, ils pourraient écrire un ou plusieurs modules de rapport de résultats à relier aux référentiels de résultats de tests existants, ou pour rapporter les résultats directement (par exemple, par e-mail ).
Développeur d'applications
Un développeur d'applications crée une application qui doit fonctionner correctement sur une variété de versions de plate-forme et une variété d'appareils. Si un problème survient sur une version de plate-forme et/ou un appareil particulier, le seul remède consiste à ajouter une solution de contournement et à passer à autre chose. Pour les grands développeurs, le processus de test peut être intégré dans une séquence de construction continue. Pour les petits développeurs, il peut être lancé périodiquement ou manuellement.
La plupart des développeurs d'applications utiliseraient les modules d'installation de test apk qui existent déjà dans TF. Il existe une version qui s'installe à partir du système de fichiers local , ainsi qu'une version qui peut installer les apk téléchargés à partir d'un service de build . Il est important de noter que cette dernière version continuerait à fonctionner correctement avec un nombre arbitraire d’instances TF exécutées sur la même machine hôte.
En raison de la capacité de TF à gérer plusieurs appareils, il serait simple de classer chaque résultat de test en fonction du type d'appareil utilisé pour ce test. Ainsi, TF pourrait potentiellement générer une matrice de compatibilité bidimensionnelle (ou multidimensionnelle) pour chaque build de l'application.
Service de tests
Un service de test peut, par exemple, permettre aux développeurs d'applications de soumettre des applications et d'exécuter des tests sur des appareils équipés d'outils de mesure de l'énergie afin de déterminer la consommation d'énergie de l'application. Cela diffère des deux cas d'utilisation précédents dans la mesure où le créateur de services ne contrôle pas les appareils ou les applications en cours d'exécution.
Étant donné que Trade Federation peut exécuter n'importe quelle classe Java implémentant l'interface simple IRemoteTest , il est trivial d'écrire des pilotes capables de coordonner un élément matériel externe avec le scénario de test exécuté sur le périphérique. Le pilote lui-même peut générer des threads, envoyer des requêtes à d'autres serveurs ou faire tout ce dont il pourrait avoir besoin. De plus, la simplicité et la polyvalence de l'interface de rapport de résultats, ITestInvocationListener , signifient qu'il est également simple de représenter des résultats de tests arbitraires (y compris, par exemple, des mesures de puissance numériques) dans le pipeline de rapport de résultats standard.