Teste de chatbot mente quando mede uma coisa parecida com a resposta em vez da resposta. Duas regras seguram quase tudo: leia a mensagem do assistente, não a tela inteira, e compare literalmente só o que o modelo não decide, deixando o texto livre de fora. Os números abaixo vêm de um assistente de chat que testei em setembro de 2026, num sistema interno.
O que a documentação diz
A Anthropic, no guia de testes para aplicações com modelos de linguagem (LLM, sigla em inglês para o tipo de modelo por trás desses chats), recomenda automatizar a correção sempre que der, e dá como exemplo a igualdade exata para respostas de categoria fechada. O guia também manda montar casos de teste que reflitam o uso real, incluindo casos de borda, como entrada vazia, longa demais ou ambígua. Não há ali uma receita para chatbot de interface, só o princípio.
A Playwright, ferramenta que controla o navegador nos testes, documenta que antes de clicar ela espera o elemento ficar visível, estável e habilitado, e que as asserções (as verificações do tipo "esse texto apareceu") repetem até a condição ser verdadeira. Isso resolve a espera do botão. Não resolve a espera da resposta do modelo, que é um texto que cresce aos poucos.
Primeiro engano: o teste lê o rodapé
Em 2 de setembro de 2026, meu teste dizia: "depois da pergunta, existe um texto com mais de 15 caracteres". Passou verde sem o assistente ter respondido nada. O motivo era o rodapé fixo da tela ("Enter envia…"), que vem depois da pergunta e tem mais de 15 caracteres. O teste media a presença de texto, não a resposta.
A correção foi medir a bolha: o último elemento da área de mensagens que não seja do usuário. E esperar o indicador de "escrevendo" sumir antes de ler, porque ler antes disso é ler uma resposta que ainda não existe.
Segundo engano: pedir ao assistente algo que o escopo proíbe
Para ter uma resposta curta e fácil de conferir, eu pedia "responda só ok". O assistente tinha escopo travado e recusava, com razão. A pergunta de prova precisa ser de dentro do escopo, com resposta que dê para checar: um dado que existe no relatório de teste, não uma instrução de formato.
Terceiro engano: comparar o texto inteiro
Em 8 de setembro de 2026 eu precisava saber se uma mudança no sistema tinha alterado o comportamento. Comparei pares de respostas. A recusa que o prompt manda dar fora do escopo foi idêntica em 21 de 21 pares. Já a resposta inteira variou até 86% entre uma execução e outra, quase tudo por causa de uma oferta em texto livre no fim ("posso ajudar com mais alguma coisa?" e variações). Um limiar frouxo de similaridade reprovava sem haver defeito.
O que resolveu foi separar as duas partes:
- A parte determinística, que o prompt fixa (a frase de recusa, o formato), compara com igualdade literal.
- A parte livre não entra na igualdade. Se importa, vira uma verificação própria, como "citou um número que existe nos dados?".
Tudo isso é medida do meu caso, num assistente só.
O que fazer
- Meça a mensagem do assistente, não a página. Identifique o elemento da resposta e espere o fim do "escrevendo".
- Faça perguntas de prova de dentro do escopo, com resposta conferível.
- Separe o que é fixo do que é livre. Igualdade literal no fixo. No livre, uma regra específica (número presente, fonte citada), não um percentual de semelhança.
- Inclua o caso que deve falhar: pergunta fora do escopo, entrada vazia, tentativa de injeção. Um teste que só vê o caminho feliz passa em qualquer sistema.
- Quando o teste ficar verde, quebre algo de propósito. Troque a resposta por texto vazio e veja se ele reprova. Se não reprova, ele não mede a resposta.
Se o seu chat já está no ar e ninguém sabe se as respostas melhoram ou pioram a cada mudança, é o tipo de trabalho que faço em agentes de IA em produção.