Teste de regressão no desenvolvimento móvel — o que é, tipos e como é realizado

O que é teste de regressão?

O teste de regressão é um tipo de teste destinado a confirmar que as alterações no código não quebraram a funcionalidade existente. O termo “regressão” significa um retorno a um estado pior — quando uma função que funcionava na versão anterior para de funcionar na nova. Os testes de regressão são executados repetidamente em cada ciclo de desenvolvimento, o que os diferencia dos testes de novos recursos, que são escritos uma vez.

A necessidade do teste de regressão decorre do efeito de alterações em cascata: corrigir um bug em um módulo pode resolver o problema, mas quebrar a funcionalidade adjacente que dependia dele. Por exemplo, alterar uma consulta SQL no repositório de usuários pode acelerar a autenticação, mas quebrar a exportação de dados que usava a mesma consulta. Um teste de regressão na exportação de dados detectará essa violação antes do lançamento.

De acordo com o relatório CISQ 2023, o custo de corrigir um defeito de regressão encontrado em produção é 15 vezes maior do que no estágio de execução automatizada de regressão. As empresas que investem em teste de regressão automatizado reduzem a parcela de defeitos de regressão nos lançamentos de 25% para 5% dentro de um ano após a implementação, de acordo com o Capgemini World Quality Report.

Tipos de teste de regressão

Existem várias abordagens para o teste de regressão que diferem em escopo e critérios de seleção de testes. A escolha da abordagem depende do tamanho do projeto, da frequência das alterações e do tempo disponível no pipeline de CI. Abaixo estão os principais tipos de teste de regressão com suas características.

Teste de regressão completo

A execução de regressão completa executa todos os testes automatizados do projeto sem exceção. Essa abordagem oferece máxima confiança, mas requer recursos computacionais e tempo significativos. Uma execução completa é realizada antes de lançamentos importantes — a cada 2–4 semanas. Para um aplicativo com 5000 testes, uma execução completa leva de 2 a 6 horas, dependendo da infraestrutura.

Teste de regressão seletivo

A abordagem seletiva executa apenas os testes relacionados aos módulos alterados. Para determinar a relação, é utilizada uma análise de dependência em nível de código: se a classe UserRepository for alterada, os testes que dependem do UserRepository direta ou transitivamente são executados. Ferramentas como Jacoco, Android Test Coverage e Xcode Code Coverage fornecem mapas de cobertura para seleção precisa. Uma execução seletiva é realizada em cada pull request e leva de 5 a 15 minutos.

Regressão baseada em riscos

A regressão baseada em riscos classifica os testes por criticidade da funcionalidade e probabilidade de quebra. Funções críticas — pagamentos, autenticação, sincronização — são testadas a cada alteração de código. Funções auxiliares — tela Sobre, animações — são testadas apenas antes do lançamento. A classificação é revisada trimestralmente com base em dados de incidentes de produção.

Diferença entre teste de regressão e reteste

Os conceitos de teste de regressão e reteste são frequentemente confundidos, embora sejam processos diferentes. O reteste é uma reexecução de um teste específico que falhou anteriormente, após a correção do defeito. O objetivo do reteste é confirmar que a correção funciona: o bug não se reproduz mais. O reteste é realizado uma vez, imediatamente após a correção e a confirmação da correção pelo desenvolvedor.

O teste de regressão é a execução de testes na funcionalidade existente que NÃO foi alterada. O objetivo é garantir que a correção de um defeito não criou um novo defeito em outro lugar. Os testes de regressão são executados repetidamente em cada ciclo de desenvolvimento, independentemente de quais bugs específicos foram corrigidos. A principal diferença: o reteste verifica a própria correção, a regressão verifica as consequências da correção.

Em um pipeline de CI/CD, ambos os processos são executados sequencialmente. Após mesclar um pull request, um reteste do bug específico é executado, seguido por uma execução de regressão completa ou seletiva. De acordo com a SmartBear (2022), separar esses processos reduz o tempo de diagnóstico de execuções de CI com falha em 30%, pois a equipe vê imediatamente quais defeitos estão relacionados à regressão e quais a correções que não funcionam.

Automação de teste de regressão

A automação do teste de regressão é um fator crítico de sucesso para projetos móveis modernos. O teste de regressão manual não escala: com um conjunto de 200 testes, uma execução requer de 2 a 3 dias úteis de um engenheiro de QA, tornando as execuções diárias impossíveis. Os testes de regressão automatizados são executados em 10 a 60 minutos sem intervenção humana, permitindo que sejam executados em cada commit ou pull request.

• Testes unitários — a base do conjunto de regressão (70%). São executados em segundos, não requerem emulador e fornecem identificação precisa da classe quebrada.
• Testes de integração — o segundo nível (20%). Verificam a camada de rede, banco de dados e serviços do sistema com dependências controladas.
• Testes de UI e E2E — o topo da pirâmide (10%). Cobrem cenários críticos do usuário: registro, pagamento, sincronização.

Para manter o conjunto de regressão atualizado, utiliza-se analítica de testes: ferramentas como Allure, ReportPortal e Xray rastreiam as taxas de aprovação, duração e estabilidade de cada teste. Testes cuja estabilidade cai abaixo de 90% (frequentemente quebram devido a mudanças nos requisitos) são marcados como legados e atribuídos ao proprietário para revisão.

Exemplo de configuração de um teste de regressão

Vamos analisar a configuração de um teste de regressão automatizado no Android usando a biblioteca JUnit 5 e Espresso. O exemplo demonstra a regressão seletiva — o teste verifica se, após a refatoração do repositório de usuários, a tela de perfil não foi quebrada. Para iOS, o XCTest é usado com lógica semelhante — um teste repetido em um cenário chave.

Android: teste de regressão de perfil

O teste usa MockWebServer para emular o servidor e verifica o caminho completo: carregamento dos dados do usuário, exibição na tela de perfil e tratamento de erro quando o servidor está indisponível. Esses testes são incluídos no conjunto de regressão e executados a cada alteração no módulo de perfil.

@RunWith(AndroidJUnit4::class)
class ProfileRegressionTest {

    @get:Rule
    val composeRule = createComposeRule()

    @Test
    fun profileScreen_rendersCorrectly() {
        val user = User(id = 1, name = "Alice", email = "alice@test.com")
        composeRule.setContent {
            ProfileScreen(user)
        }
        composeRule.onNodeWithText("Alice").assertIsDisplayed()
        composeRule.onNodeWithText("alice@test.com").assertIsDisplayed()
    }

    @Test
    fun profileScreen_handlesNetworkError() {
        setNetworkError()
        composeRule.onNodeWithText("Erro de carregamento").assertIsDisplayed()
    }
}

iOS: teste de regressão com XCTest

Para iOS, o teste de regressão usa XCTestExpectation para verificação assíncrona da atualização da interface do usuário após receber dados da API. O teste emula uma resposta de rede e verifica se os elementos da interface foram atualizados corretamente.

class ProfileRegressionTests: XCTestCase {
    func testProfileScreen_rendersCorrectly() {
        let viewModel = ProfileViewModel(userId: 1)
        let view = ProfileView(viewModel: viewModel)
        viewModel.loadProfile()

        let expectation = expectation(description: "profile loaded")
        viewModel.onProfileLoaded = {
            XCTAssertEqual(viewModel.userName, "Alice")
            XCTAssertEqual(viewModel.userEmail, "alice@test.com")
            expectation.fulfill()
        }
        waitForExpectations(timeout: 3.0)
    }
}

Estratégia para construir um conjunto de regressão

Construir um conjunto de regressão eficaz é um processo iterativo baseado em dados de defeitos e alterações de código. A estratégia inicial é incluir todos os testes existentes no conjunto de regressão e executar uma passagem completa antes de cada lançamento. À medida que a base de testes cresce (mais de 2000 testes), uma execução completa se torna muito longa e uma abordagem seletiva é necessária.

A segunda fase — implementação de ferramentas de análise de dependência: Jacoco para Android, Xcode Test Plan para iOS. Essas ferramentas constroem um mapa “teste — classe — método” e permitem determinar quais testes são afetados por uma alteração específica. Uma execução seletiva baseada em análise de cobertura reduz o tempo de execução em 60–80% enquanto mantém 95% de eficácia na detecção de regressões, de acordo com a Spotify Engineering (2022).

A terceira fase — monitoramento contínuo e otimização. Testes que não falharam em 6 meses são movidos para um conjunto de baixa prioridade. Testes que falham mais de uma vez por mês são candidatos a revisão: ou eles capturam problemas reais (precisam de correção) ou são muito frágeis (requerem estabilização). Uma revisão trimestral do conjunto de regressão é uma prática padrão para manter sua eficácia e velocidade de execução.