Répondez à notre enquête sur la convivialité pour améliorer ce site.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Présentation de la fédération commerciale

Trade Federation (Tradefed ou TF en abrégé) est un cadre de test continu conçu pour exécuter des tests sur des appareils Android. Par exemple, Tradefed est utilisé pour exécuter la suite de tests de compatibilité (CTS) et la suite de tests du fournisseur (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) sur 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 voulez vous lancer directement 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 , native / 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

Voir Test via TF pour obtenir les informations les plus récentes sur la manière d'exécuter vos tests existants, tels que l' instrumentation .

Cas d'utilisation

La modularité de Trade Federation permet de s'intégrer facilement 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 où le commerce pourrait permettre des pratiques de test efficaces et évolutives.

Premièrement, il est utile de considérer le paysage des cas d'utilisation potentiels en fonction de la question "quelles parties sont modifiables et quelles parties sont statiques?" Par exemple, un équipementier OEM peut modifier la structure, le système et le matériel, mais n'a que peu ou pas d'influence sur les applications existantes. Un développeur d'application, 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 aura différentes options dans le cas d'un ensemble d'échecs de test. Malgré ces différences, Trade Federation peut aider à rendre chacun de leurs processus de test efficace, flexible et évolutif.

OEM de l'appareil

Un équipementier OEM construit du matériel et modifie souvent le système et les cadres Android pour qu'ils fonctionnent correctement sur ce matériel. L'OEM peut 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 peut implémenter un module de clignotement de périphérique qui s'exécutera pendant la phase de configuration 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 de forcer potentiellement le périphérique dans le chargeur de démarrage, de clignoter, 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 modifie le micrologiciel au niveau du système et les cadres au niveau de Java.

Une fois l'appareil complètement démarré, l'OEM serait en mesure d'exploiter les tests existants basés sur JUnit, 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 test 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 bien fonctionner 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 incorporé 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 des apks téléchargés à partir d'un service de compilation . Il est important de noter que cette dernière version continuerait à fonctionner correctement avec arbitrairement de nombreuses instances TF s'exécutant sur la même machine hôte.

En raison de la capacité de TF à traiter plusieurs appareils, il serait simple de classer chaque résultat de test par le type d'appareil utilisé pour ce test. Ainsi, TF pourrait potentiellement générer une matrice de compatibilité bidimensionnelle (ou multidimensionnelle) pour chaque construction de l'application.

Service de test

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 puissance pour déterminer la consommation d'énergie de l'application. Cela diffère des deux cas d'utilisation précédents en ce que le générateur de services ne contrôle pas les périphériques ou les applications en cours d'exécution.

Étant donné que Trade Federation peut exécuter n'importe quelle classe Java qui implémente la simple interface IRemoteTest , il est trivial d'écrire des pilotes capables de coordonner un matériel externe avec le IRemoteTest test exécuté sur l'appareil. 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 , signifie qu'il est également simple de représenter des résultats de test arbitraires (y compris, par exemple, des mesures de puissance numériques) dans le pipeline de rapport de résultats standard.