Teste de interrupção em aplicativos móveis

⚡ Resumo Inteligente

O teste de interrupção verifica como um aplicativo móvel se comporta quando uma chamada, alarme, notificação ou queda de rede o interrompe, e se o aplicativo retorna ao seu estado exato anterior assim que a interrupção termina.

🔘 Escopo: A técnica pertence ao teste de aplicativos móveis, mas também se aplica à web e a softwares independentes.
☑️ Fontes de interrupção: Chamadas recebidas, SMS, alarmes, bateria fraca, eventos de carregamento, atualizações de aplicativos e alterações de rede abrangem a maioria dos cenários reais.
✅ Quatro resultados esperados: Executar em segundo plano, exibir um alerta, uma chamada para ação ou não ter impacto — cada aplicativo define qual opção se aplica.
🧪 Projeto de teste: O teste de interrupção é um subconjunto do teste funcional, portanto, as mesmas estruturas, casos de teste e processo de execução se aplicam.
🛠️ Simulação: Os controles estendidos do emulador, as configurações do dispositivo e as nuvens de dispositivos reais reproduzem chamadas, alertas e perda de conectividade sob demanda.
📊 Não é um teste de recuperação: Os testes de recuperação validam a restauração após uma falha, enquanto uma interrupção é apenas uma descontinuidade.tracção, não uma falha.

Saiba Mais

O que é teste de interrupção?

Teste de interrupção É um ramo do teste de aplicativos móveis que lida com a forma como um aplicativo reage a uma interrupção e retorna ao seu estado anterior. A interrupção vem de fora do aplicativo — do sistema operacional, do hardware ou de outro aplicativo — e o teste verifica se nenhum dado, estado da tela ou transação em andamento é perdido quando o controle é restaurado.

O teste de interrupção se aplica a qualquer tipo de aplicação — web, mobile, independente, etc. A variedade de dispositivos, redes e configurações torna-o ainda mais relevante para móvel aplicações do que para as outras.

Por que você precisa do teste de interrupção?

O que quase sempre acontece quando você está em uma reunião? Você é interrompido, certo? Quando isso acontece, algumas pessoas nem piscam, outras precisam de um minuto para se recuperar e outras perdem completamente o fio da meada. Em outras palavras, o Teste de Interrupção tenta descobrir qual comportamento seu aplicativo apresenta.

Deixando de lado as formalidades por um instante, vamos analisar outra situação do mundo real. Imagine que você tem uma lanterna e a liga. A bateria acaba, o que interrompe seu funcionamento. Troque as baterias e ligue-a novamente. A lanterna deve voltar a funcionar normalmente. Este é o caso de uso. Uma disciplina de teste que se concentra em verificar se isso acontece ou não é o Teste de Interrupção.

A justificativa comercial é simples. Uma interrupção ocorre no pior momento possível — no meio de um pagamento, no meio de um upload, no meio de um formulário — e um usuário que perde esse trabalho raramente tenta novamente. Travamentos ao retomar o processo, telas em branco, transações duplicadas e perda de dados inseridos em formulários são todos defeitos que apenas uma interrupção expõe, e é por isso que eles sobrevivem a uma versão funcional que nunca interrompe nada.

Tipo de interrupções em aplicativos móveis

As interrupções se enquadram em alguns grupos familiares, resumidos na ilustração abaixo.

Todos nós estamos familiarizados com as interrupções comuns que normalmente ocorrem. Aqui estão algumas delas:

Bateria fraca
Bateria totalmente carregada — durante o carregamento
Chamada recebida
SMS de entrada
Alerta recebido de outro aplicativo móvel
Conectado para carregar
Desconectado do carregamento
Dispositivo desligado
Lembretes de atualização do aplicativo
Alarme
Perda de conexão de rede
Restauração da conexão de rede

Esta lista não é exaustiva, mas inclui os cenários mais comuns. Uma forma prática de organizá-la é por origem: eventos dependentes do dispositivo, como bateria e carregamento; eventos iniciados pelo usuário, como atender uma chamada ou alternar entre aplicativos; e eventos externos, como perder o sinal em um elevador ou túnel.

Resolução em caso de interrupção

O comportamento esperado em caso dessas interrupções é um dos quatro seguintes:

Executado em segundo plano: A interrupção toma conta do aplicativo enquanto este fica em segundo plano. Ele retoma o controle após o término da interrupção. Por exemplo, uma chamada telefônica ou uma chamada do FaceTime que você atende enquanto lê um livro digital no iBooks (ou aplicativo similar). Quando o usuário atende o telefone, o iBooks aguarda até que a chamada termine e, em seguida, retoma a leitura quando ela for encerrada.
Exibir alerta: O alerta desaparece e você trabalha normalmente. Uma mensagem de "SMS recebido" aparece no cabeçalho. O usuário não se preocupa com isso e continua usando o aplicativo normalmente. Outros alertas de aplicativos móveis, como uma nova solicitação de amizade no Facebook ou uma mensagem do WhatsApp, também se enquadram nessa categoria. Mas se o usuário decidir ler a mensagem, o comportamento descrito no ponto 1 será seguido. Se o alerta for ignorado, o estado do aplicativo permanece inalterado.
Apelo à ação: Os alarmes precisam ser desligados ou adiados antes de você continuar trabalhando. O mesmo se aplica às mensagens de atualização de aplicativos. Você precisa cancelar ou aceitar as alterações antes de prosseguir. Outro exemplo é o alerta de bateria fraca — você pode optar por continuar normalmente ou entrar no modo de economia de energia, se o dispositivo permitir.
Sem impacto: Um exemplo disso é quando uma conexão de rede fica disponível e seu dispositivo se conecta a ela. Da mesma forma, quando você conecta seu dispositivo para carregar, nenhum alerta ou ação específica é necessária. Provavelmente, ele funcionará normalmente enquanto você continua usando o aplicativo.

Portanto, dependendo da interrupção que você está testando, entenda o comportamento e veja se seu aplicativo o atende. Além disso, o comportamento descrito acima pode não ser o mesmo para todos os aplicativos e dispositivos. Certifique-se de descobrir os detalhes específicos do seu aplicativo móvel.

Testes de interrupção de casos de teste com resultados esperados

Uma vez acordada a resolução esperada, cada interrupção torna-se um caso de teste comum com um gatilho, uma ação e um resultado verificável. A tabela abaixo mostra como as quatro resoluções acima se traduzem em cenários concretos.

Interrupção	Cenário de teste	Resultado esperado
Chamada recebida	Inicie uma chamada enquanto um formulário estiver parcialmente preenchido, atenda-a e, em seguida, encerre a chamada.	O aplicativo é minimizado e retomado na mesma tela com os dados inseridos intactos.
SMS ou notificação push recebida	Envie uma mensagem enquanto um vídeo ou upload estiver em andamento e ignore o banner.	O banner aparece e desaparece; o estado da aplicação permanece inalterado.
Alarme	Permitir que um alarme programado seja acionado durante uma sessão ativa e desativá-lo.	O alarme exige primeiro uma chamada à ação; em seguida, o aplicativo retoma de onde parou.
Aviso de bateria fraca	Durante uma transação, descarregue o dispositivo até ao limite de aviso.	É exibido um aviso, a transação não é cancelada e o modo de baixo consumo de energia não causa problemas na tela.
Perda de conexão de rede	Desative a conectividade durante a solicitação e, em seguida, restaure-a.	Uma mensagem clara é exibida, nenhum travamento ocorre e a solicitação é concluída ou falha com segurança na restauração.
Carregando conectado ou desconectado	Conecte e desconecte o carregador durante uma sessão ativa.	Sem impacto — a aplicação continua sem alterações visíveis.
Lembrete de atualização do aplicativo	Exibir uma solicitação de atualização enquanto o aplicativo estiver em uso.	O usuário pode cancelar ou aceitar, e a tela subjacente permanece inalterada.

Mantenha uma linha por interrupção em cada tela crítica, em vez de uma linha por interrupção para toda a aplicação. A tela de pagamento, a tela de login e um formulário longo falham de maneiras diferentes, e um único caso genérico mascara isso.

Agora que entendemos o que é Teste de Interrupção e o que validar ao conduzi-lo, é hora de falar sobre como fazê-lo.

Como fazer testes de interrupção

Veja esta afirmação: o iBooks deve ser executado em segundo plano quando o usuário recebe uma chamada telefônica.

Você não consideraria isso um requisito funcional do aplicativo iBooks? Eu consideraria.

Portanto, o teste de interrupção é um subconjunto de Teste funcional Para um aplicativo móvel, os testes de interrupção seguem as mesmas estruturas e ferramentas de teste utilizadas. A habilidade dos testadores reside em conceber esses cenários. Uma vez feito isso, os casos de teste são elaborados e executados exatamente da mesma forma que qualquer outro teste.

Na prática, a sequência é curta e repetível:

Liste os principais fluxos de usuário — login, pagamento, upload, formulários longos, reprodução de mídia.
Mapeie cada possível interrupção da lista acima em cada trajeto.
Defina em conjunto com o responsável pelo produto a resolução esperada para cada caso, pois não existe uma solução padrão universal.
Execute a interrupção no instante de maior risco, não em um momento ocioso, e depois retome a operação.
Verificar o estado, os dados, a sessão e a memória após a retomada, e não apenas se o aplicativo ainda está aberto.

Para obter mais informações sobre a disciplina em geral, consulte o Teste de celular tutorial e casos de exemplo em Teste de aplicativo móvel.

Ferramentas e técnicas para simular interrupções

Os cenários acima precisam ser produzidos sob demanda, em vez de serem aguardados, e cada plataforma oferece uma maneira de fazer isso.

Android Controles estendidos do emulador: O painel lateral do emulador simula uma chamada recebida, um SMS, o nível da bateria e o estado do carregador, além da intensidade do sinal celular, permitindo que a maioria das interrupções seja atendida sem a necessidade de um segundo aparelho.
Simulador de iOS e Xcode: A conectividade e os estados do hardware podem ser variados a partir do simulador e das configurações do dispositivo, enquanto um dispositivo físico emparelhado abrange os cenários de chamada que um simulador não consegue gerar.
Um segundo dispositivo físico: Ligar ou enviar mensagens para o dispositivo em teste a partir de outro aparelho continua sendo a maneira mais fiel de reproduzir uma interrupção real, especialmente em casos em que o tempo é crucial.
Configurações do dispositivo: O modo avião, a ativação/desativação do Wi-Fi, o modo Não Perturbe, a economia de bateria e os alarmes programados resolvem problemas de conectividade e interrupções de energia em dispositivos reais.
Estruturas de automação: A mesma pilha de automação usada para o restante do seu conjunto de funcionalidades pode controlar o aplicativo antes e depois da interrupção, de modo que a verificação de retomada seja assegurada em vez de ser feita visualmente.
Nuvens de dispositivos reais: Um conjunto de dispositivos hospedados amplia a cobertura entre fabricantes e versões de sistemas operacionais, o que é importante porque o tratamento de interrupções é uma das áreas em que as personalizações dos fornecedores mais divergem.

Independentemente do mecanismo, registre o momento exato da interrupção no caso de teste. "Interrupção durante o upload" e "interrupção após o upload" são testes diferentes com modos de falha distintos.

Melhores Práticas para Testes de Interrupção

Alguns hábitos distinguem um conjunto útil de ferramentas de interrupção de um mero exercício de cumprimento de formalidades.

Interromper no pior momento: Target O instante em que uma transação é confirmada ou um arquivo está sendo gravado, pois é nesse momento que o estado é mais frágil.
Teste o currículo, não a interrupção: O defeito quase sempre aparece após o retorno do controle, portanto as asserções devem ser feitas na tela restaurada.
Abrange ambas as direções de uma mudança de rede: Perder a conexão e recuperá-la são casos distintos, sendo que o segundo é omitido com mais frequência.
Variar a duração: Um alerta de dois segundos e uma chamada de dez minutos fazem com que o aplicativo passe por diferentes caminhos do ciclo de vida, incluindo a remoção da memória.
O problema está presente em diversas versões de sistemas operacionais e hardware de baixo custo: A remoção de processos em segundo plano é muito mais agressiva em dispositivos com recursos limitados, o que expõe defeitos que um aparelho topo de linha esconde.
Automatize as tarefas repetitivas: A conectividade e as interrupções de bateria são automatizadas de forma eficiente, liberando o trabalho manual para cenários de chamadas e alarmes.
Monitore o uso de recursos, bem como o estado: Uma interrupção que causa vazamento de memória ou consome bateria ao retomar a operação é um defeito, mesmo quando a tela parece correta, o que relaciona este trabalho a teste de desempenho de aplicativos móveis.

O teste de interrupção não é o mesmo que o teste de recuperação?

Não, não pode. Teste de Recuperação Valida a restauração após uma falha. Uma interrupção não é necessariamente uma falha — é apenas uma descontinuidade.tracção.

É como a diferença entre uma vírgula e um ponto em inglês. A distinção é apenas técnica, mas a ideia geral é clara. O teste de recuperação verifica se o aplicativo consegue voltar a funcionar após uma falha; o teste de interrupção verifica se algo para de funcionar quando outro programa assume o primeiro plano.

Isso é o que você precisa saber para começar a trabalhar com Testes de Interrupção — um ramo importante e intuitivo dos Testes de Aplicativos Móveis.

Perguntas Frequentes

Os cenários são os mesmos, mas os resultados não. As duas plataformas gerenciam aplicativos em segundo plano e a liberação de memória de maneiras diferentes, e Android As interfaces personalizadas dos fornecedores adicionam suas próprias regras de bateria, portanto, o mesmo teste pode ser aprovado em uma família de dispositivos e reprovado em outra.

Os modelos de IA leem histórias de usuários e relatórios de falhas e sugerem combinações de interrupções que um testador pode não ter listado — por exemplo, uma chamada que chega exatamente durante a atualização do token. O aprendizado de máquina também agrupa registros de falhas de produção para mostrar quais interrupções realmente afetam os usuários reais primeiro.

O Copilot elabora bem o código padrão — colocando o aplicativo em segundo plano, alternando a conectividade, aguardando e, em seguida, verificando a tela restaurada. A decisão sobre quando interromper e qual estado deve ser mantido fica a cargo do testador, portanto, considere os scripts gerados como um rascunho inicial para revisão.

Sim. Os dois nomes descrevem a mesma atividade e são usados indistintamente por diferentes equipes e ferramentas. Escolha uma grafia para o seu plano de testes e use-a de forma consistente, pois a mistura de terminologias dificulta a busca por conjuntos de testes e facilita a criação de casos duplicados.

Use ambos. Emuladores são ideais para conectividade rápida e repetível e para casos de uso intenso da bateria em um pipeline. Dispositivos reais são necessários para chamadas genuínas, gerenciadores de bateria do fornecedor e remoção de memória insuficiente, que são justamente as condições que expõem os defeitos de retomada mais críticos.

Travamentos ao retomar a sessão, telas em branco ou incorretas após retornar, perda de dados inseridos em formulários, pagamentos duplicados em uma nova tentativa, sessões interrompidas que exigem um novo login, reprodução de mídia travada e vazamentos de memória ou bateria que só aparecem após o aplicativo ser minimizado repetidamente.

Sim, ambas as coisas. Interrupções de rede, bateria e troca de aplicativos são roteadas de forma confiável e devem ser incluídas na execução de regressão. Chamadas recebidas, alarmes e avisos de energia específicos do fabricante geralmente são mais rápidos de serem testados manualmente em um aparelho real, então a maioria das equipes mantém um pequeno conjunto de testes manuais à mão.

Comece assim que uma jornada crítica estiver completa em termos de funcionalidades, em vez de durante a semana final de testes de estabilidade. Defeitos de retomada geralmente exigem alterações no ciclo de vida ou no gerenciamento de estado, e essas alterações são caras para serem corrigidas depois que a versão candidata a lançamento já estiver finalizada.