Ce document décrit les AVD pour Test Lab, y compris les avantages et les limites connues. Nous fournissons également des recommandations comment tester votre application tout au long du cycle de développement. Test Lab DMV sont similaire aux AVD pour Android Studio, mais ils sont optimisés pour les performances avec les tests dans le cloud. Il existe donc peu de différences entre les deux.
Test Lab Les AVD avec un suffixe .arm ou (Arm) sont avancés qui offrent les avantages suivants:
Exécution plus rapide des tests
Tailles et densités d'écran alignées sur les AVD d'Android Studio pour plus de cohérence
Processeurs graphiques accélérés compatibles avec les GPU
Le tableau suivant décrit les avantages de l'utilisation d'appareils virtuels :
| Avantage | Description | Cas d'utilisation |
| Haute disponibilité | Vous pouvez exécuter des tests et obtenir des résultats plus rapidement lorsque vous utilisez des appareils virtuels. Les appareils virtuels étant créés à la demande, vos les tests démarrent presque immédiatement, ce qui permet une validation rapide de votre application. | Testez de petites mises à jour de votre application ou des tests de régression. |
| Des tests plus longs | Les appareils virtuels acceptent une durée de test maximale de 60 minutes. Les tests sur des appareils physiques sont limités à une durée de test sur 45 minutes sur chaque appareil. | Exécution de tests plus longs |
| Réduction des coûts | Les appareils virtuels sont facturés au prix de 1 $de l'heure pour chaque appareil virtuel utilisé. pour tester votre application. | Tests quotidiens à l'aide de systèmes d'intégration continue, ou avant vérification dans le code. Pour en savoir plus, consultez Niveaux d'utilisation, quotas et tarifs pour Test Lab. |
Tester votre application avec des appareils virtuels
Vous pouvez tester votre application avec des appareils virtuels de la même manière que vous le faites avec des appareils physiques. Vous pouvez sélectionner des appareils virtuels pour vos tests lorsque vous configurer une matrice de test. Pour en savoir plus sur l'exécution de tests avec Test Lab, consultez Premiers pas avec les tests Android Firebase Test Lab
Afficher les modèles et les API compatibles
Pour afficher les modèles AVD et les API compatibles avec Test Lab, exécutez la commande suivante:
gcloud firebase test android models list --filter=virtual
Bonnes pratiques pour tester votre application
Les appareils virtuels augmentent votre gamme d'options lorsque vous testez votre application avec Test Lab Nous vous recommandons de suivre les bonnes pratiques suivantes pour tester votre tout au long du cycle de développement de l'application:
Utilisez l'émulateur Android Studio ou un appareil physique connecté.
Lorsque vous développez votre application, utilisez l'émulateur Android Studio ou un fichier un appareil physique pour examiner chaque build en vue d'une validation initiale. Si vous avez des tests d'instrumentation, vous pouvez aussi les exécuter à partir d'Android Studio sur appareils physiques ou virtuels fournis par Test Lab.
Utilisez des systèmes CI pour chaque modification de code lorsque vous travaillez sur des projets partagés
Si vous travaillez sur un projet de grande envergure ou si vous contribuez à des projets partagés à l'aide de GitHub ou d'un site similaire, nous vous recommandons d'utiliser des systèmes d'intégration continue (CI). Testez vos applications sur des appareils virtuels chaque fois que le système CI ou avant chaque demande d'extraction. Pour en savoir plus sur l'utilisation de Test Lab avec l'intégration continue (CI) consultez la section Utiliser Test Lab pour Android avec l'intégration continue Systèmes
Testez votre appli sur des appareils physiques avec Test Lab avant de publier des mises à jour importantes
Avant de publier des mises à jour d'application comportant des modifications importantes de l'interface utilisateur et des fonctionnalités, nous vous recommandons d'utiliser Test Lab pour tester votre application sur des appareils physiques. Cela vous aidera à vous assurer que votre application est stable et performants sur une large gamme d'appareils physiques populaires. Effectuer des tests sur des permet également d'assurer la couverture des tests pour toutes les fonctionnalités de l'application qui reposent sur des fonctionnalités d'appareils physiques qui ne sont pas simulées par des appareils virtuels. Pour apprendre Pour en savoir plus sur ces fonctionnalités, consultez la section Limites connues.
Mises à jour des appareils virtuels
Régulièrement, l'équipe Android ajoute de nouvelles images d'appareils virtuels, abandonne les anciennes et met à jour les existantes. Nous appliquons ces mises à jour à notre appareil virtuel pour vous assurer d'effectuer les tests par rapport à la version la plus récente qui reflètent l'expérience utilisateur expériences.
Dans de rares cas, ces mises à jour peuvent entraîner l'échec inattendu des tests. Lorsqu’il y a une mise à jour potentiellement destructive connue, Test Lab inclura des informations dans notes de version. Nous vous recommandons d'utiliser des frameworks de test (par exemple, Espresso qui résistent à ces changements dans la mesure du possible. Lorsque cela n'est pas possible, nous vous recommandons de cibler les appareils virtuels ARM, qui vous pouvez vous attendre à les mettre à jour moins fréquemment.
Limitations connues
Certaines fonctionnalités des appareils physiques ne sont actuellement pas simulées par des appareils virtuels, ou sont simulées avec certaines limites. Le tableau suivant récapitule les fonctionnalités actuellement indisponibles sur les appareils virtuels ou avec certaines limites:
| Fonctionnalité | Détails |
| Interfaces binaires d'application (ABI) | Tous les appareils ne sont pas compatibles avec toutes les ABI. Si vous
développez avec le NDK Android, assurez-vous de générer du code pour
ABI compatibles avec les appareils que vous ciblez (voir la section
appareils dans
Test Lab). Pour en savoir plus sur la gestion des ABI, consultez Android
ABI.
Remarque:Si un test de votre matrice de test est marqué comme non valide, cette peut survenir car votre application est dépendante d'un code natif non compatible avec le ABI de l'appareil. |
| Performances graphiques | Les appareils virtuels Nexus et Pixel utilisent le rendu graphique logiciel. Les applications nécessitant une utilisation intensive des ressources graphiques enregistrent des performances inférieures. Si votre application est gourmande en graphiques, envisagez plutôt d'utiliser SmallPhone.arm, MediumPhone.arm ou des appareils physiques. |
| API graphiques | OpenGL ES 3.x n'est pas compatible avec les appareils avec un niveau d'API inférieur à 29. Les appareils récents ne sont pas entièrement compatibles avec avec les API OpenGL/Vulkan, vous remarquerez peut-être de légères différences au niveau des graphismes. |
| Application Google Play Store | L'application Google Play Store n'est pas compatible avec les appareils virtuels ARM. |
| Fonctionnalité de réalité augmentée (RA) | Le test de la fonctionnalité de réalité augmentée (RA) n'est pas compatible avec les appareils virtuels. |
| Niveaux d'API plus anciens | Test Lab Les appareils virtuels ARM ne sont pas compatibles avec les niveaux d'API inférieurs à 26. |