Ce contenu est destiné aux développeurs de plateformes Android. Avant de comprendre comment les tests sont effectués sur la plateforme Android, veuillez vous référer à l' architecture de la plateforme Android pour un aperçu.
Plongez ensuite dans les technologies précises à votre disposition dans cette section, telles que la Vendor Test Suite (VTS) et sa myriade de didacticiels vidéo et d'atelier de programmation .
Notez également les mécanismes de test spécifiques à la sécurité disponibles pour détecter et renforcer vos appareils contre les vulnérabilités.
Pour tester des applications, commencez par les principes fondamentaux des tests et effectuez l' atelier de programmation de tests Android à l'aide des exemples fournis.
Enfin, notez que des tests de base avant la soumission sont disponibles via Repo Hooks qui peuvent exécuter des linters, vérifier le formatage et déclencher des tests unitaires avant de continuer, comme le téléchargement d'un commit. Notez que ces hooks sont désactivés par défaut. Voir l'introduction des Repo Hooks pour plus de détails.
Quoi et comment tester
Un test de plate-forme interagit généralement avec un ou plusieurs services du système Android, ou couches HAL (Hardware Abstraction Layer), exerce les fonctionnalités du sujet testé et affirme l'exactitude du résultat du test.
Ainsi, un test de plateforme peut :
- exercer les API du cadre via le cadre d'application ; Les API spécifiques utilisées peuvent inclure :
- API publiques destinées aux applications tierces
- les API cachées destinées aux applications privilégiées, à savoir les API système
- API privées (@masquer ou protégé, package privé)
- invoquer directement les services du système Android via des proxys de classeur brut/IPC
- interagir directement avec les HAL via des API de bas niveau ou des interfaces IPC
Les types 1 et 2 sont généralement écrits sous forme de tests d'instrumentation , tandis que les types 3 sont généralement écrits sous forme de GTests .
Pour en savoir plus, consultez nos exemples de bout en bout :
Familiarisez-vous avec ces outils, car ils sont intrinsèques aux tests sous Android.
Suite de tests de compatibilité (CTS)
Android Compatibility Test Suite est une suite de différents types de tests, utilisés pour garantir la compatibilité des implémentations du framework Android entre les partenaires OEM et entre les versions de plate-forme. La suite comprend également des tests d'instrumentation et le framework GTest.
Les tests CTS et plateforme ne s’excluent pas mutuellement, et voici quelques directives générales :
- si un test affirme l'exactitude des fonctions/comportements de l'API du framework et qu'il doit être appliqué aux partenaires OEM, il doit l'être dans CTS
- si un test est destiné à détecter les régressions pendant le cycle de développement de la plate-forme et peut nécessiter une autorisation privilégiée pour être exécuté et peut dépendre des détails d'implémentation (tels que publiés dans AOSP), il ne doit s'agir que de tests de plate-forme
Suite de tests des fournisseurs (VTS)
La Vendor Test Suite (VTS) automatise les tests du noyau HAL et OS. Pour utiliser VTS afin de tester l'implémentation d'un système Android intégré, configurez un environnement de test, puis testez un correctif à l'aide d'un plan VTS.
Infrastructure de test de la Fédération du commerce
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. TF peut exécuter des tests fonctionnels localement, à votre bureau, au sein de votre plateforme de paiement. Il existe deux fichiers requis pour exécuter un test dans TF, une source de test Java et une configuration XML. Voir RebootTest.java et reboot.xml pour des exemples.
Débogage
La section Débogage résume les outils utiles et les commandes associées pour le débogage, le traçage et le profilage du code de plate-forme Android intégré lors du développement de fonctionnalités au niveau de la plate-forme.