Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous trouverez ci-dessous quelques formes d'automatisation classiques que vous pouvez utiliser dans votre système CI.
Jobs de base
Compiler:en compilant un projet à partir de zéro, vous vous assurez que les nouvelles modifications sont compilées correctement, et que tous les outils et bibliothèques sont compatibles les uns avec les autres.
Vérifications lint ou de style:il s'agit d'une étape facultative, mais recommandée. Lorsque vous appliquez des règles de style et effectuez une analyse statique, les revues de code peuvent être plus concises et plus ciblées.
Tests locaux ou côté hôte:ils s'exécutent sur l'ordinateur local qui effectue la compilation. Sur Android, il s'agit généralement de la JVM, qui est donc rapide et fiable. Ils comprennent également des tests Robolectric.
Il existe plusieurs options pour exécuter des tests d'instrumentation dans la CI:
Gradle Managed Devices (Appareils gérés par Gradle) permet de définir les appareils à utiliser (par exemple, "émulateur Pixel 2 sur l'API 27") et gère le provisionnement des appareils.
La plupart des systèmes CI sont fournis avec un plug-in tiers (également appelé "action", "intégration" ou "étape") pour gérer les émulateurs Android.
Déléguez les tests d'instrumentation à une batterie d'appareils telle que Firebase Test Lab.
Les fermes d'appareils sont utilisées pour leur haute fiabilité et peuvent s'exécuter sur des émulateurs ou des appareils physiques.
Tests de régression des performances
Pour surveiller les performances de l'application, nous vous recommandons d'utiliser les bibliothèques d'analyse comparative.
L'automatisation des tests de performances pendant le développement nécessite des appareils physiques pour garantir des résultats cohérents et réalistes.
L'exécution d'analyses comparatives peut prendre beaucoup de temps, en particulier lorsque vous avez une couverture élevée du code et des parcours utilisateur que vous comparez. Au lieu d'exécuter tous les benchmarks pour chaque fonctionnalité ou commit fusionné, envisagez de les exécuter dans le cadre d'une compilation de maintenance programmée de façon régulière, telle qu'une compilation nocturne.
Contrôle des performances
Vous pouvez surveiller les régressions de performances à l'aide de l'ajustement du pas. L'ajustement de pas définit une fenêtre glissante des résultats de la compilation précédente, que vous comparez à la compilation actuelle. Cette approche combine plusieurs résultats de benchmark dans une métrique spécifique à la régression. Vous pouvez appliquer l'ajustement de pas pour réduire le bruit lors des tests de régression.
Cela réduit l'occurrence de faux positifs qui peuvent se produire lorsque les temps de référence sont lents pour un seul build, puis sont à nouveau normalisés.
Tester les vérifications de régression de la couverture
La couverture des tests est une métrique qui peut vous aider, vous et votre équipe, à déterminer si les tests couvrent suffisamment une modification. Cependant, il ne devrait pas être le seul indicateur. Il est courant de configurer une vérification de régression qui échoue ou affiche un avertissement lorsque la couverture diminue par rapport à la branche de base.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Types of CI automation\n\nThe following are some typical forms of automation that you might like to use in\nyour CI system.\n\nBasic jobs\n----------\n\n- **Build:** By building a project from scratch, you make sure that the new\n changes compile correctly and that all libraries and tools are compatible with\n each other.\n\n- **Lint or style checks:** This is an optional but recommended step. When you\n enforce style rules and perform [static analysis](/studio/write/lint), code reviews can be more\n concise and focused.\n\n- **[Local, or host-side tests](/training/testing/local-tests):** They run on the local machine that\n performs the build. On Android this is usually the JVM, so they're fast and\n reliable. They include Robolectric tests as well.\n\nInstrumented tests\n------------------\n\n[Tests that run on emulators or physical devices](/training/testing/instrumented-tests) require some provisioning,\nwaiting for devices to boot or be connected and other operations that add\ncomplexity.\n\nThere are multiple options to run instrumented tests on CI:\n\n- [Gradle Managed Devices](/studio/test/gradle-managed-devices) can be used to define the devices to use (for example \"Pixel 2 emulator on API 27\") and it handles device provisioning.\n- Most CI systems come with a third-party plugin (also called \"action\", \"integration\" or \"step\") to handle Android emulators.\n- Delegate instrumented tests to a device farm such as [Firebase Test Lab](https://firebase.google.com/docs/test-lab). Device farms are used for their high reliability and they can run on emulators or physical devices.\n\nPerformance regression tests\n----------------------------\n\nTo monitor app performance we recommend using the [benchmark libraries](/topic/performance/benchmarking/benchmarking-overview).\nAutomation of performance tests during development requires physical devices to\nensure consistent and realistic test results.\n\nRunning benchmarks can take a long time, especially when you have high coverage\nof code and user journeys that you are benchmarking. Instead of running all\nbenchmarks for every merged feature or commit, consider executing them as part\nof a regularly scheduled maintenance build, such as a nightly build.\n\n### Monitoring performance\n\nYou can monitor performance regressions using [step fitting](https://medium.com/androiddevelopers/fighting-regressions-with-benchmarks-in-ci-6ea9a14b5c71). Step\nfitting defines a rolling window of previous build results which you compare\nagainst the current build. This approach combines several benchmark results into\none regression-specific metric. You can apply step fitting to reduce noise\nduring regression testing.\n\nThis reduces the occurrence of false positives which can occur when benchmark\ntimes are slow for a single build and then normalize again.\n\nTest coverage regression checks\n-------------------------------\n\n[Test coverage](/studio/test/test-in-android-studio#view_test_coverage) is a metric that can help you and your team decide if tests\nsufficiently cover a change. However, it shouldn't be the only indicator. It is\ncommon practice to set up a regression check that fails or shows a warning when\nthe coverage goes down relative to the base branch.\n| **Note:** The coverage generated by an instrumentation test is different from that of a unit test as bigger tests typically make fewer assertions per line of tested code and their goal is different. Consider keeping two separate coverage metrics."]]
