Um fluxo de trabalho Android seguro não continua tocando até que algo aconteça. Ele identifica a tela atual, limita os tentativas de reinício, verifica o próximo estado e para com evidências quando o resultado é incerto.
A resposta curta: pare quando a próxima ação não for mais justificada.
Uma condição de parada de automação do Android é uma regra que impede que o fluxo de trabalho continue quando a tela atual, o resultado ou o tempo não suportam mais a próxima ação. Pode encerrar a execução, retornar um resultado controlado, coletar evidências ou enviar o caso para uma pessoa. O ponto não é parar em cada surpresa. O ponto é evitar transformar a incerteza em outro toque.
Trabalhos de fluxo confiáveis respondem a quatro perguntas antes de cada ação importante: Em que estado o telefone deve estar? Qual observação prova esse estado? Quantos tentativas de recuperação são aceitáveis? Que evidências devem ser preservadas se o estado nunca aparecer? O Android UI Automator inclui esperas condicionais e verificações de estabilidade, enquanto o WorkManager documenta a cancelamento e o tratamento de trabalho parado. A lição de design comum é simples: esperar, tentar novamente e parar precisam de limites explícitos.
- Continue apenas quando o estado esperado for positivamente identificado.
- Tente novamente apenas quando o falha for temporário e a tentativa de retry tiver um limite claro.
- Pare ou solicite revisão quando a tela for desconhecida, uma ação for sensível ou o pós-condicionamento falhar.
Continuar, esperar, tentar novamente, parar ou revisar?
| decisão | Use-o quando | Limite requerido | Evidência para manter |
|---|---|---|---|
| continuar | O estado atual e a próxima ação são ambos esperados | Uma transição revisada | Estado observado e pós-condição |
| esperar | O aplicativo ainda está carregando ou se ajustando | Tempo limite ou condição de pronto nomeada | Tempo decorrido e última tela |
| tentar novamente | Uma condição temporária pode ser resolvida sem alterar o significado comercial. | Tentativas máximas mais intervalo | Contagem de tentativas e resultado de cada observação |
| parar | O estado é desconhecido, inválido, inseguro ou fora do caminho aprovado | Terminação imediata | Parar razão, captura de tela, resultado estruturado |
| Revisão humana | O fluxo de trabalho não pode decidir com segurança ou a próxima ação tem consequências materiais | Prazo claro para transferência de posse e proprietário | Pacote completo de evidências e próximo passo proposto |
Essas escolhas não são intercambiáveis. Uma espera dá ao mesmo estado tempo para se estabilizar. Uma tentativa de reprovação repete uma observação ou ação de recuperação limitada. Uma ramificação seleciona entre resultados conhecidos. Uma parada encerra o caminho revisado. A revisão humana é apropriada quando a automação não tem evidências suficientes para escolher com segurança.
Passo 1: nomeie os estados antes de escolher as ações
No final deste passo, cada tela importante tem um nome e um pequeno conjunto de fatos observáveis. Comece com um fluxo de trabalho restrito, como abrir uma compilação de teste, navegar para uma página de configurações, alterar uma opção não sensível e confirmar o novo estado. Não comece com uma longa sequência de coordenadas.
- Escreva o estado inicial, o próximo estado esperado e os estados alternativos aceitáveis.
- Para cada estado, escolha o sinal útil mais estreito: propriedade da interface do usuário, texto visível, imagem conhecida, objeto detectado ou captura de tela focada.
- Marque qualquer tela que nunca deve receber uma ação automática, como uma conta inesperada, permissão, compra, exclusão ou tela de dados de produção.
A verificação é simples: outro revisor deve ser capaz de analisar a definição do estado e explicar por que a próxima ação é permitida. oGuia de clique automático de reconhecimento de imagensmostra por que encontrar um alvo visual não é suficiente. O fluxo de trabalho ainda precisa de uma pré-condição antes do toque e uma pós-condição depois.
Passo 2: escolha uma observação que prove cada estado
No final deste passo, cada estado tem uma observação primária e uma fonte de evidência de backup. Use a estrutura da interface do usuário para fatos semânticos, como uma etiqueta, estado selecionado, controle habilitado ou contagem de itens. Use OCR quando o texto visível é importante, mas a árvore da interface do usuário não o expõe de forma confiável. Use correspondência de modelos para um alvo visual conhecido e detecção de objetos para uma classe validada cuja posição ou tamanho varia.
Evite empilhar vários sinais fracos e chamar a certeza da combinação. Uma captura de tela ampla, um modelo não validado e um resultado OCR parcial não fazem automaticamente uma decisão confiável. Em vez disso, defina uma observação portante e registre os outros sinais como evidências de apoio. oComparação de testes visuais do AndroidExplica onde o estado da interface do usuário, OCR, capturas de tela, modelos e detecção se encaixam.
A verificação significa testar amostras positivas e negativas. A condição deve passar na tela pretendida e falhar em uma tela visualmente semelhante, mas incorreta. Se não conseguir distinguir esses estados, restrinja a região, altere o sinal ou pare o fluxo de trabalho antes da ação.
Passo 3: coloque um orçamento em torno de cada espera e tentativa de reinício.
No final deste passo, nenhum loop pode rodar para sempre. Cada espera precisa de um tempo limite ou de uma condição de prontidão nomeada. Cada tentativa de reprovação precisa de um número máximo de tentativas, um intervalo razoável e uma razão pela qual tentar novamente poderia ter sucesso sem piorar a situação.
| Padrão de falha | Por que outra tentativa pode ajudar | Limite seguro | Pare razão |
|---|---|---|---|
| A tela ainda está carregando | O mesmo estado pode se tornar pronto | Espere até ficar estável ou o tempo de espera expirar | Condição pronta não alcançada |
| Elemento está temporariamente ausente | O conteúdo pode chegar com um pequeno atraso. | Observe novamente por um número fixo de tentativas | Elemento esperado nunca apareceu |
| Toque não produziu transição | A entrada pode ter sido perdida uma vez | Um repetiu após verificar a tela | Condição pós-venda ainda ausente |
| Dialog ou conta desconhecido aparece | Outra tentativa não reduz a incerteza | Sem tentar novamente | Estado inesperado requer revisão |
| Ação pode excluir, comprar, enviar ou publicar | A repetição cega pode duplicar consequências | Sem tentativa automática de reinício, a menos que a idempotência seja comprovada. | O resultado da ação sensível é incerto |
As perguntas da comunidade sobre automação do Android muitas vezes descrevem ciclos que esperam para sempre ou tarefas que parecem presas. Uma regra de tentativas máximas é útil, mas o contador deve seguir a operação. Uma verificação somente de leitura pode tolerar mais tentativas do que uma ação que altera o estado. O número correto é o menor orçamento revisado que cobre a latência normal.
Passo 4: verifique a pós-condição antes de declarar o sucesso
No final deste passo, um toque entregue não é mais tratado como uma tarefa concluída. Após cada ação de mudança de estado, espere que a interface se estabilize e observe o resultado esperado. Se a pós-condição estiver faltando, o fluxo de trabalho não deve continuar silenciosamente para a próxima ação.
- Registre o estado que autorizou a ação.
- Execute a única ação aprovada.
- Aguarde um pós-condição nomeado ou um tempo limite limitado.
- Sucesso na rota para o próximo estado e falha na captura de evidências, recuperação revisada ou parada.
Isso protege contra sobreposições, navegação atrasada, entradas perdidas, coordenadas desatualizadas e telas semelhantes. Também produz um relatório de falhas melhor: o revisor vê o que foi esperado, qual ação ocorreu e qual estado seguinte não apareceu.
Passo 5: preserve evidências suficientes para que uma pessoa possa decidir
No final deste passo, cada parada produz um pacote de evidências compacto em vez de uma vaga etiqueta de falha. Capture evidências antes que a recuperação altere a tela. Mantenha apenas o que é necessário para o diagnóstico e processe capturas de tela ou logs de acordo com a política de dados para o aplicativo que está sendo testado.
- Fluxo de trabalho e nome do passo, construção do aplicativo, dispositivo, versão do Android, localização e orientação.
- Estado esperado, estado observado, resultado da condição, contagem de tentativas e tempo decorrido.
- Uma captura de tela ou recorte focado, além de texto OCR, pontuação de correspondência, propriedades da interface do usuário ou resultado de detecção quando relevante.
- O último estado bem-sucedido, ação tentada, pós-condição ausente e razão explícita de parada.
- Uma escolha sugerida do revisor: tentar novamente após uma correção conhecida, atualizar o estado aceito ou investigar o produto.
Uma transferência útil permite que alguém tome a próxima decisão sem reproduzir toda a execução primeiro. oGuia de teste de fumaça de QA de automação AndroidDá um exemplo mais amplo de manter as verificações de dispositivos reais estreitas e reprodutíveis.
ComoLaiCai FlowModelos de limites seguros
LaiCai FlowÉ um recurso de automação dentroLaiCai Screen Mirroring. Um Fluxo pode observar a estrutura da interface do usuário ou o estado visual, se ramificar entre resultados conhecidos, esperar visivelmente, repetir um número limitado de vezes, chamar um Fluxo filho até o sucesso ou um limite e terminar através de retorno explícito ou comportamento de parada. Esses blocos de construção tornam a decisão de segurança visível para um revisor.
Em um padrão típico, uma IU, OCR, modelo ou nó de detecção observa o telefone uma vez. Uma ramificação roteia um sucesso ou falha conhecido. Uma espera representa um atraso real no negócio. Um loop limitado lida com uma condição temporária. Uma observação falhada sem margem de recuperação pode encerrar o Fluxo atual em vez de alimentar a mesma ação para sempre.
LaiCai Flow InsidePode executar um Perfil compatível através deLaiCai Android AgentNo telefone após o implantação. A compatibilidade ainda depende de cada nó, ativo, modelo e dependência de rede usado pelo perfil. Executar no dispositivo não remove a necessidade de limites, evidências ou revisão.
Uma lista de verificação de revisão prática antes do implantação
- Toda ação tem uma pré-condição nomeada e uma pós-condição verificável.
- Cada espera tem um tempo limite ou condição de pronto, e cada tentativa de reprovação tem um número máximo de tentativas.
- Estados desconhecidos param ou vão para um caminho de recuperação revisado.
- Ações sensíveis nunca são repetidas cegamente quando seu resultado é incerto.
- A evidência de falha é capturada antes que a tela mude novamente.
- Casos de tela positivas, negativas, lentos, interrompidos e inesperados foram testados em dispositivos autorizados.
Se uma dessas afirmações for falsa, o fluxo de trabalho não está pronto para operação sem supervisão. Ainda pode ser útil no modo supervisionado através deAutomação de IA Android, onde uma pessoa pode observar o dispositivo, refinar as condições de estado e revisar as evidências de falha.
Perguntas frequentes sobre a condição de parada da automação do Android
Um atraso fixo é uma condição de parada?
Não. Um atraso fixo apenas pausa o fluxo de trabalho. Isso não prova que o aplicativo atingiu o estado esperado. Associe qualquer atraso a uma observação de estado e um tempo limite.
Todos os falhas deveriam parar todo o fluxo de trabalho?
Não. Um falha temporária conhecida pode seguir um caminho de recuperação revisado e limitado. Um estado desconhecido, condição pós-recoveria ausente ou ação sensível incerta normalmente deve parar ou solicitar revisão.
Quantos tentativas de reinício são seguros?
Não existe um número universal. Use o limite mais pequeno que cobre a latência normal medida e reduza o limite para ações que alteram o estado. Se repetir a ação puder duplicar uma consequência, verifique a idempotência ou não tente novamente automaticamente.
A IA remove a necessidade de regras de parada?
Não. A IA pode ajudar a interpretar uma tela ou propor um fluxo de trabalho, mas a execução ainda precisa de estados, orçamentos, pós-condições e limites de revisão explicitamente permitidos. A incerteza é uma razão para coletar evidências, não permissão para continuar.
Torne a incerteza visível em vez de automatizá-la através dela
Um fluxo de trabalho Android confiável não é aquele que dura mais tempo. É aquele que pode explicar por que cada ação foi permitida, qual resultado ela esperava e por que parou quando as evidências mudaram.
Nomeie os estados, escolha uma observação portadora de carga, vincule cada espera e tentativa de reprovação, verifique cada pós-condição e preserve uma transferência útil. Esse design transforma as condições de parada de código defensivo na política de operação do fluxo de trabalho.
- Desenvolvedores do Android: Automatizador de Interface de Usuário
- Desenvolvedores do Android: espera do legado do UI Automator
- Desenvolvedores do Android: Gerencie o trabalho do WorkManager
- Desenvolvedores do Android: Trabalho persistente e restrições
- Appium: Capabilidades de sessão
- Discussão do Tasker: tentativas de espera limitadas