Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Veja a seguir algumas formas típicas de automação que podem ser usadas no
seu sistema de CI.
Jobs básicos
Criar:ao criar um projeto do zero, você garante que as novas
mudanças sejam compilados corretamente e que todas as bibliotecas e ferramentas sejam compatíveis
entre si.
Verificações de lint ou estilo:esta é uma etapa opcional, mas recomendada. Quando você
aplica regras de estilo e realiza análise estática, as revisões de código podem ser
mais concisas e focadas.
Testes locais ou no lado do host:eles são executados na máquina local que
executa o build. No Android, geralmente é a JVM, então, elas são rápidas e
confiáveis. Eles também incluem testes Robolectric.
Há várias opções para executar testes de instrumentação na CI:
Os dispositivos gerenciados pelo Gradle podem ser usados para definir os dispositivos a serem usados (por
exemplo, "Emulador do Pixel 2 na API 27") e processam o provisionamento de dispositivos.
A maioria dos sistemas de CI vem com um plug-in de terceiros (também chamado de "ação",
"integração" ou "etapa") para processar emuladores do Android.
Delegar testes de instrumentação a um farm de dispositivos, como o Firebase Test Lab.
Os farms de dispositivos são usados pela alta confiabilidade e podem ser executados em emuladores
ou dispositivos físicos.
Testes de regressão de desempenho
Para monitorar o desempenho do app, recomendamos o uso das bibliotecas de comparação.
A automação de testes de desempenho durante o desenvolvimento requer dispositivos físicos para
garantir resultados de teste consistentes e realistas.
A execução de comparações pode levar muito tempo, especialmente quando você tem uma alta cobertura
de jornadas de código e usuário para comparar. Em vez de executar todas
as comparações para cada recurso ou confirmação mesclado, considere executá-las como parte
de um build de manutenção programado regularmente, como um build noturno.
Como monitorar o desempenho
É possível monitorar regressões de desempenho usando o ajuste de etapas. O ajuste
de etapa define uma janela contínua de resultados do build anterior, que você compara
com o build atual. Essa abordagem combina vários resultados de comparação em
uma métrica específica da regressão. É possível aplicar o ajuste de passos para reduzir o ruído
durante o teste de regressão.
Isso reduz a ocorrência de falsos positivos que podem ocorrer quando os tempos
de comparação são lentos para um único build e depois normalizam novamente.
Testar verificações de regressão de cobertura
A cobertura de testes é uma métrica que pode ajudar você e sua equipe a decidir se os testes
cobrem uma mudança de maneira suficiente. No entanto, ele não deve ser o único indicador. É uma
prática comum configurar uma verificação de regressão que falhe ou mostre um aviso quando
a cobertura diminui em relação à ramificação de base.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]
