Optimiser la CTS

La suite de tests de compatibilité Android (CTS) fournit des millions de tests individuels. Bien qu'il soit nécessaire d'exécuter fréquemment CTS pendant la phase de développement logiciel, il est possible de réduire le temps nécessaire à l'exécution de ces tests.

Important :Pour approuver un build logiciel pour la production finale, une exécution complète de la suite de tests CTS est obligatoire. Le build de production final ne peut pas contenir de modules qui n'ont pas été testés ou qui ont échoué aux tests. Les partenaires sont chargés de détecter les défaillances dès le début du développement. Tous les échecs doivent être résolus avant le build final.

Cette page décrit les méthodes que vous pouvez utiliser pour réduire le temps d'exécution des tests et comment optimiser les ressources matérielles dans le processus.

Appareils partagés

Pour réduire le temps de cycle, envisagez d'exécuter le CTS sur plusieurs appareils (fractionnement). Pour découvrir comment utiliser le sharding, consultez la section Exécuter des tests CTS.

Conseil :Pour une efficacité maximale, nous vous recommandons de connecter au moins six appareils. Cela peut réduire la durée totale d'exécution de CTS à moins de 24 heures.

Station de test Android

Utilisez la station de test Android (ATS) pour exécuter des suites de test Android standards à l'aide d'une interface utilisateur. Cet outil sert d'interface Web pour la Trade Federation (TF), ce qui vous permet d'exécuter la CTS avec une configuration minimale sur un ensemble d'appareils de test, ainsi que d'établir un calendrier pour exécuter des tests en continu.

La station de test Android est compatible avec le mode multi-hôte, qui permet d'utiliser un seul hôte de contrôleur ATS pour gérer les appareils et les tests sur plusieurs hôtes de travail ATS.

Conseil :Pour exécuter Android Test Station sur un émulateur, incluez le paramètre --use_host_adb.

Exécution continue de l'émulateur

Pour exécuter le CTS en continu pendant la phase de développement, vous pouvez utiliser des appareils virtuels Android (AVD) à la place du matériel. Les régressions des échecs de test peuvent être identifiées rapidement, ce qui permet de gagner beaucoup de temps nécessaire pour trier et analyser les causes profondes. Plusieurs instances de l'émulateur peuvent être utilisées pour la segmentation et peuvent être programmées pour s'exécuter en continu avec la station de test Android.

Important :L'implémentation de l'émulateur peut ne pas être identique au matériel, et les tests peuvent ne pas s'exécuter ou les résultats peuvent être peu fiables. Veillez à analyser les modules de test qui produisent des résultats différents de ceux du matériel avant de configurer l'émulateur pour une exécution continue.

Programme de qualité drawElements (dEQP)

Le programme de qualité drawElements (dEQP) est inclus dans le CTS Android. Appelé CtsDepqTestCases, ce programme se concentre sur la couverture des tests des graphiques Android. Ce module représente près de 80% de tous les cas de test dans Android CTS et 6% du temps d'exécution total.

Étant donné que les pilotes graphiques Android font partie du micrologiciel Android (BSP) et ne changent pas beaucoup au cours du développement, vous pouvez exécuter ce module de manière stratégique. Par exemple, si vous exécutez CTS toutes les deux semaines (ou moins) pendant le développement logiciel, en fonction du calendrier de mise à jour du micrologiciel, vous pouvez exclure ce module pendant plusieurs cycles.

Important :Pour éviter de découvrir des problèmes de dernière minute lors de la certification finale, nous vous recommandons vivement d'exécuter le module plusieurs fois pendant le développement et de ne pas l'ignorer complètement.

Une option consiste à exécuter CtsDeqpTestCases séparément sur un ensemble d'appareils, puis à envoyer les rapports CTS. Par exemple, sur deux hôtes différents.

Hôte 1:

cts-tf > run cts --max-log-size 100 --shard-count 6 -o -m CtsDeqpTestCases

Hôte 2:

cts-tf > run cts --max-log-size 100 --shard-count 6 -o --exclude-filter CtsDeqpTestCases

Scénarios de test des contenus multimédias

Les scénarios de test multimédias vérifient les services multimédias tels que l'audio, la vidéo et les pilotes multimédias. Ces modules de test multimédias contribuent le plus au temps d'exécution du CTS. Des retards peuvent se produire dans les cas suivants:

• Téléchargement de fichiers multimédias ou lecture répétée de fichiers multimédias pendant les tests
• Réessayer les scénarios de test ayant échoué.

Android CTS contient les modules de test suivants:

• CtsMediaStressTestCases
• CtsMediaPlayerTestCases
• CtsMediaAudioTestCases
• CtsVideoTestCases
• CtsMediaDecoderTestCases
• CtsMediaCodecTestCases
• CtsMediaV2TestCases

Envisagez d'exécuter des tests multimédias localement ou sur un serveur local. Pour en savoir plus, consultez Exécuter des tests multimédias CTS en local.

Le framework multimédia et ses pilotes (décodeurs et encodeurs) font partie du micrologiciel Android (BSP). Vous pouvez exécuter ce module de manière stratégique et l'exclure pendant plusieurs cycles, en fonction du calendrier de mise à jour du micrologiciel.

Important :Pour éviter de découvrir des problèmes de dernière minute lors de la certification finale, nous vous recommandons vivement d'exécuter les modules multimédias plusieurs fois pendant le développement et de ne pas les ignorer complètement.