Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Di seguito sono riportate alcune forme tipiche di automazione che potresti voler utilizzare nel tuo sistema CI.
Job di base
Creazione: creando un progetto da zero, ti assicuri che le nuove modifiche vengano compilate correttamente e che tutti gli strumenti e le librerie siano compatibili tra loro.
Controllo lint o stile: questo passaggio è facoltativo, ma consigliato. Quando applichi regole di stile ed esegui analisi statiche, le revisioni del codice possono essere più concise e mirate.
Test locali o lato host: vengono eseguiti sulla macchina locale
che esegue la build. Su Android di solito si tratta della JVM, perciò sono veloci e affidabili. Includono anche test Robolectric.
Sono disponibili diverse opzioni per eseguire test strumentati su CI:
Puoi utilizzare Gradle Managed Devices per definire i dispositivi da utilizzare (ad esempio "emulatore Pixel 2 sull'API 27") e gestire il provisioning dei dispositivi.
La maggior parte dei sistemi CI è dotata di un plug-in di terze parti (chiamato anche "azione", "integrazione" o "passaggio") per gestire gli emulatori Android.
Delega i test strumentati a una device farm come Firebase Test Lab.
Le device farm vengono utilizzate per la loro elevata affidabilità e possono essere eseguite su emulatori o dispositivi fisici.
Test di regressione delle prestazioni
Per monitorare le prestazioni dell'app, consigliamo di utilizzare le librerie di benchmark.
L'automazione dei test delle prestazioni durante lo sviluppo richiede dispositivi fisici per garantire risultati dei test coerenti e realistici.
L'esecuzione dei benchmark può richiedere molto tempo, soprattutto in presenza di un'elevata copertura
del codice e dei percorsi degli utenti di cui stai effettuando il benchmarking. Anziché eseguire tutti i benchmark per ogni funzionalità o commit unito, valuta la possibilità di eseguirli come parte di una build di manutenzione pianificata regolarmente, ad esempio una build notturna.
Monitoraggio del rendimento
Puoi monitorare le regressioni del rendimento utilizzando la funzionalità di adattamento. Stepfitting definisce una finestra temporale continuata dei risultati della build precedente confrontati con la build attuale. Questo approccio combina diversi risultati di benchmark
in un'unica metrica specifica per la regressione. Puoi applicare l'adattamento dei passaggi per ridurre
il rumore durante i test di regressione.
Questo riduce il numero di falsi positivi che possono verificarsi quando i tempi del benchmark sono lenti per una singola build e poi si normalizzano di nuovo.
Testa i controlli di regressione della copertura
La copertura dei test è una metrica che può aiutare te e il tuo team a decidere se i test coprono sufficientemente una variazione. Tuttavia, non dovrebbe essere l'unico indicatore. È
pratica comune configurare un controllo di regressione che non va a buon fine o mostra un avviso quando
la copertura diminuisce rispetto al ramo di base.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
