Ce contenu est destiné aux développeurs de plateformes Android. Avant de comprendre comment les tests sont effectués sur la plate-forme Android, veuillez vous référer à l' architecture de la plate-forme 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 de codelab .
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 les tests d'applications, commencez par les principes de base des tests et effectuez l'atelier de programmation des tests Android à l'aide des exemples fournis.
Enfin, notez que les tests de pré-soumission de base sont disponibles via Repo Hooks qui peuvent exécuter des linters, vérifier la mise en forme et déclencher des tests unitaires avant de continuer, comme le téléchargement d'un commit. Notez que ces crochets sont désactivés par défaut. Voir l'introduction Repo Hooks pour plus de détails.
Quoi et comment tester
Un test de plate-forme interagit généralement avec un ou plusieurs des services du système Android ou des 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 :
- API de framework d'exercice via le framework d'application ; les API spécifiques en cours d'exercice 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 (@hide, ou protected, package private)
- invoquez directement les services du système Android via des proxies raw binder/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ée pour garantir la compatibilité des implémentations du framework Android entre les partenaires OEM et entre les versions de la plate-forme. La suite comprend également des tests d'instrumentation et le framework GTest.
CTS et les tests de plate-forme 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é à tous les partenaires OEM, il doit ê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 de mise en œuvre (tels que publiés dans AOSP), il ne doit s'agir que de tests de plate-forme
Suite de tests du fournisseur (VTS)
La Vendor Test Suite (VTS) automatise les tests du noyau HAL et OS. Pour utiliser VTS pour tester une implémentation de système Android intégrée, configurez un environnement de test, puis testez un correctif à l'aide d'un plan VTS.
Infrastructure de test 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. TF peut exécuter des tests fonctionnels localement, à votre bureau, au sein de votre plate-forme de paiement. Il y a 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.