Lorsque le corpus de test est volumineux ou que le temps d'exécution devient long, nous vous offrons la possibilité de répartir les tests sur plusieurs appareils : le partitionnement.
Le partitionnement nécessite que l'exécuteur de test le prenne en charge.
La majorité des principaux exécuteurs de test prennent déjà en charge le partitionnement. Aucun travail supplémentaire n'est donc requis. Les éléments suivants prennent déjà en charge le partitionnement : les tests d'instrumentation, les tests pilotés côté hôte et GTest.
Il existe deux types de partitionnement compatibles avec Tradefed : local et distribué. Ils partagent certaines similitudes. Cette page décrit donc les propriétés communes, puis les spécificités de chacun.
Propriétés communes
Les deux formes de partitionnement supposent les mêmes propriétés de la part des exécuteurs de test : les partitions doivent être indépendantes et déterministes. La première étape des deux partitionnements consiste à créer la liste ordonnée complète des tests, puis à les diviser en différents groupes/partitions.
La principale différence entre les formes de partitionnement réside dans la manière dont elles exécutent les tests. Pour en savoir plus, consultez les sections ci-dessous.
Partitionnement local
Le partitionnement local signifie que tous les appareils impliqués dans l'exécution de l'appel partitionné sont connectés au même hôte physique.
Exécution
Le partitionnement local tire parti du fait que tous les appareils sont connectés au même hôte en créant un pool de tests à exécuter et en demandant à chaque appareil d'interroger les tests lorsqu'il est libre (c'est-à-dire lorsqu'il a terminé le test précédent). Cela permet d'optimiser l'utilisation des appareils. On parle également de partitionnement dynamique.
Options
--shard-count XX
Partitionnement distribué
Le partitionnement distribué signifie que tous les appareils impliqués dans l'exécution de l'appel partitionné peuvent se trouver n'importe où et être connectés à différents hôtes physiques.
Exécution
Le partitionnement distribué a lieu lors de la création de la liste des tests, et le contenu de chaque partition n'exécute que la partition actuellement demandée. Ainsi, toutes les partitions distribuées créent d'abord la même liste, puis exécutent un sous-ensemble mutuellement exclusif de celle-ci, ce qui permet d'exécuter tous les tests.
La principale propriété de cette forme est que les partitions sont complètement indépendantes les unes des autres et peuvent échouer indépendamment.
Le principal inconvénient est que la longueur des partitions n'est pas nécessairement équilibrée, car nous ne pouvons pas prédire à l'avance la durée d'exécution de chaque test dans chaque partition. La distribution est effectuée de manière à ce que chaque partition contienne approximativement le même nombre de cas de test.
Options
--shard-count XX --shard-index XX
Partitionnement par jeton
Le partitionnement par jeton ne peut être utilisé qu'avec le partitionnement local. L'indicateur est inopérant dans les cas d'utilisation de partitionnement non local. Parfois, l'un des appareils impliqués dans le partitionnement contient des ressources spéciales que d'autres n'ont pas, comme une carte SIM. Certains tests ne peuvent fonctionner que lorsque cette ressource spéciale est disponible et échouent dans le cas contraire.
Le partitionnement par jeton est notre solution pour ces cas d'utilisation. Les modules de test peuvent déclarer la ressource spéciale dont ils ont besoin dans leur fichier AndroidTest.xml, et Tradefed achemine les tests vers un appareil disposant de la ressource.
Configuration XML
<option name="config-descriptor:metadata" key="token" value="SIM_CARD" />
Le value du jeton correspond à la Tradefed's
TokenProperty
et est associée à un gestionnaire dans
TokenProviderHelper.
Cela permet d'exécuter des modules de test sur des appareils capables d'exécuter correctement les tests.
Que se passe-t-il si aucun appareil ne peut exécuter le test ?
Si aucun appareil disponible ne dispose de la ressource correspondant au module de test, le module de test échoue et est ignoré, car il ne peut pas s'exécuter correctement.
Par exemple, si un module de test demande une carte SIM pour s'exécuter, mais qu'aucun appareil n'en possède, le module de test échoue.
Implémentation
Transmettez ce flag de fonctionnalité à la ligne de commande Tradefed principale :
--enable-token-sharding