Automação web para iniciantes: quatro etapas e três armadilhas comuns

A automação web costuma ser entendida como fazer um programa clicar em botões por você. Na prática, porém, descobre-se que uma ação tem quatro etapas e que, se qualquer uma delas estiver errada, pode parecer que nada aconteceu.

Primeiro, vale separar dois conceitos que são facilmente confundidos. Automação web é o termo mais amplo: inclui usar um programa para fazer o que uma pessoa normalmente faria em uma página web, inclusive obter dados diretamente por meio de requests. Automação de navegador é uma vertente mais específica: o programa controla um navegador real para abrir páginas, executar JavaScript e simular cliques e digitação. Em cenários com muito conteúdo dinâmico ou interações complexas, normalmente é necessário seguir esse segundo caminho.

As quatro etapas de uma ação

• Localizar o elemento: Identifique o alvo com id, name, class, seletor CSS ou XPath. Dê prioridade a atributos semânticos e só recorra à estrutura ou ao índice quando não houver opção melhor.
• Esperar até ficar interativo: Um elemento estar no DOM não significa que já possa ser clicado. Espere até que esteja visível ou clicável, ou até que uma request específica retorne. O que se espera é uma condição, não uma quantidade de segundos.
• Executar a ação: Clicar, digitar ou rolar. Componentes personalizados muitas vezes exigem reproduzir a ordem de uma pessoa: abrir primeiro, esperar a lista renderizar e então selecionar pelo texto.
• Verificar o resultado: Depois da ação, confirme se o resultado está correto. Veja se o link mudou, se o texto da página mudou ou o que a API retornou. Sem essa etapa, uma falha pode ser tratada como sucesso e os retries e alertas posteriores ficam sem uma base confiável.

Entre as quatro etapas, a segunda e a quarta costumam consumir mais tempo de depuração. Não porque sejam difíceis, mas porque frequentemente não geram erro e apenas produzem silenciosamente um resultado incorreto.

A estabilidade do seletor determina quanto tempo o script dura

Quando a página muda, um locator fixo pode deixar de funcionar. Localizar por texto, posição ou índice é a opção menos resistente a mudanças: adicionar um botão ou alterar uma mensagem pode desalinhar tudo.

Sempre que possível, prefira atributos id, name ou data. Se precisar de locators estruturais, concentre-os em um único lugar para que uma alteração seja feita apenas ali, e não em dezenas de linhas. Também não espere escrever o script e nunca mais mexer nele; sites mudam com frequência e boa parte do custo de manutenção fica justamente nesse ponto.

Carregamento dinâmico: o que esperar importa mais do que quanto esperar

Hoje são raras as páginas em que tudo está pronto assim que o carregamento inicial termina. Os dados são renderizados por requests assíncronas, então os elementos aparecem mais tarde do que você imagina.

Esperas fixas são comuns e também muito sujeitas a falhas: dormir por 3 segundos pode ser insuficiente em uma máquina lenta e apenas desperdiçar tempo em uma rápida. O correto é esperar uma condição ser satisfeita e agir somente quando o elemento estiver realmente clicável.

Se o elemento não for encontrado, verifique primeiro iframe e shadow DOM

Quando o elemento está claramente na página, mas o script não consegue encontrá-lo, muitas vezes o problema não é o seletor, e sim o escopo.

Um iframe é um documento independente. É preciso entrar no frame correspondente antes de procurar o elemento e sair dele depois da operação; caso contrário, as buscas seguintes ocorrerão no contexto errado. Os nós dentro de um shadow DOM não são encontrados diretamente por seletores CSS externos. Primeiro obtenha o shadow root e depois faça a busca dentro dele. Esses dois casos costumam ser confundidos com uma mudança de layout da página e acabam consumindo tempo de depuração sem necessidade.

Há mais duas coisas fáceis de esquecer

A primeira é a sessão. Em tarefas que exigem login, é preciso pensar em como salvar e reutilizar o estado autenticado. Caso contrário, será necessário entrar novamente a cada execução, com o risco de travar em uma etapa de verificação.

A segunda é o ambiente. Se todas as tarefas compartilham o mesmo ambiente de navegador, sessões e caches podem contaminar umas às outras. Tarefas que funcionam bem separadas podem começar a interferir quando executadas juntas. Quando se passa de uma tarefa para várias, separar a isolação de ambientes em uma camada própria economiza muitos problemas. Ferramentas como PurpleMark fornecem fingerprint e proxy independentes para cada ambiente, enquanto o framework de automação fica responsável apenas por executar as ações.

Confirme um limite antes de começar

A automação pode substituir operações repetitivas, mas não etapas que exigem a participação de uma pessoa real. Se o fluxo alvo incluir verificação facial em tempo real ou análise manual, esse fluxo não poderá ser 100% automatizado.

Por isso, primeiro valide da forma mais simples: percorra manualmente todo o fluxo, anote cada etapa e confirme se existe algum ponto que não pode ser ultrapassado. Só então decida quanto esforço de desenvolvimento vale investir. Viabilidade técnica e o que as regras permitem também são questões diferentes, portanto verifique com antecedência os termos de serviço da plataforma alvo.