Aplicações de AI
Testes de aplicações de AI: o que quebra e como testar.
Um app com LLM falha de maneiras que um app web comum não falha. O modelo devolve algo diferente a cada vez, então você não faz asserção sobre a resposta — faz sobre tudo em volta dela: que uma resposta chega, faz streaming, termina, falha de forma visível, respeita um limite e nunca devolve dados que a pessoa não pode ver.
Última atualização em 24 de agosto de 2026
Em que testar uma aplicação de AI é diferente?
A interface é a mesma. O contrato não é. A automação de testes tradicional se apoia em uma asserção que vale duas vezes — clique aqui, veja isto. Um modelo quebra essa suposição na primeira execução, e é por isso que as equipes muitas vezes concluem que seus recursos de AI não podem ser testados por regressão e acabam lançando-os sem testes.
Podem, sim. O truque é tirar a asserção do texto e levá-la para as partes determinísticas: a resposta chegou dentro de um orçamento, foi interpretada com o esquema que você pediu, citou um documento que este usuário pode ler, uma recusa foi exibida como recusa, uma nova tentativa não cobrou duas vezes. Tudo isso é automação comum. Julgar se a resposta é boa é um problema de avaliação, exige a sua própria verdade de referência e pertence a um ambiente ao lado dos seus prompts, e não a uma suíte de regressão.
O que realmente quebra em um app com LLM
São comportamentos, não opiniões sobre a qualidade da saída, e é isso que os torna testáveis. Cada um chega aos usuários como um bug do produto, e não como uma resposta ruim.
| Falha | Como chega a um usuário | O teste |
|---|---|---|
| A resposta começa a chegar e para no meio | Uma conexão perdida no meio do streaming deixa uma resposta pela metade na tela, sem erro e sem nova tentativa. Os usuários leem aquilo como a resposta. | Corte a resposta no meio do streaming e verifique que a UI mostra um estado de falha, e não uma resposta truncada. |
| O modelo é lento e a UI não tem resposta para isso | Um p95 de quarenta segundos enquanto a interface não mostra progresso, nem cancelamento, nem timeout. As pessoas clicam de novo, e agora duas requisições estão sendo cobradas. | Mantenha a resposta aberta além do timeout e verifique que há um estado visível, um caminho para cancelar e nenhuma requisição duplicada em um segundo clique. |
| O provedor retorna 429 ou 503 | Limites de taxa e quedas do provedor são rotina, não exceção. Apps que os tratam como impossíveis mostram um erro cru ou um spinner infinito. | Retorne 429 e 503 do provedor e verifique que o app degrada para uma mensagem em que o usuário possa agir. |
| Respostas vazias, recusadas e barradas por filtros de segurança | O modelo recusa, ou o filtro de segurança dispara, e a interface exibe um balão vazio porque só trata o caminho feliz. | Force uma recusa e uma resposta vazia; verifique que nenhuma gera uma mensagem em branco ou um layout quebrado. |
| A conversa perde o contexto | O histórico é cortado para caber na janela e o assistente esquece em silêncio o que lhe disseram três mensagens atrás. Parece que o produto é burro. | Leve uma conversa além do limite de contexto e verifique que o app diz o que descartou, em vez de descartar em silêncio. |
| Chamadas de ferramenta disparam mais de uma vez | Um agente repete uma etapa cuja ferramenta já foi executada. O que quer que a ferramenta tenha feito — um e-mail, uma cobrança, uma gravação — acontece duas vezes. | Faça uma chamada de ferramenta expirar depois de ter dado certo e verifique que a nova tentativa não repete o efeito colateral. |
| A busca retorna o documento de outro tenant | O banco vetorial é filtrado no prompt e não na consulta; assim, uma busca que ignora a instrução devolve dados que o usuário não pode ler. | Consulte como um tenant um documento que pertence a outro e verifique que ele está ausente do conjunto recuperado, e não apenas não mencionado na resposta. |
| O custo dispara sem um teto | Sem limite por usuário, um loop ou uma conta automatizada vira uma fatura que ninguém percebe até a cobrança chegar. | Acione o mesmo endpoint repetidamente e verifique que existe um limite — por usuário, por chave, por minuto. |
Segurança
Testes de segurança de LLM: a superfície que vale verificar
Um recurso de AI costuma chegar ligado a duas coisas que um recurso comum não tem: um endpoint pago e um componente que segue instruções encontradas em tudo o que lê. Ambos ampliam a superfície de ataque de formas para as quais uma revisão de segurança de aplicações padrão não foi escrita.
Ordenado abaixo pela frequência com que realmente é encontrado — que não é a ordem em que esses itens costumam ser descritos.
- 01
Chaves do provedor no bundle do cliente
Uma chave de provedor de modelo enviada no JavaScript do front-end, ou acessível por uma rota de proxy sem autenticação na frente.
Qualquer pessoa com as ferramentas de desenvolvedor pode gastar sua cota. É a verificação mais barata desta lista e a mais cara de deixar passar.
- 02
Prompt injection por meio de conteúdo
Instruções escondidas em algo que o modelo lê — um documento enviado, uma página coletada, um ticket de suporte, o corpo de um e-mail — e que o modelo então segue.
O atacante nunca toca no seu campo de entrada. Tudo o que o seu sistema ingere é uma entrada, quer você a tenha projetado assim ou não.
- 03
Injeção que chega a uma ferramenta
Instruções injetadas que fazem um agente chamar uma ferramenta: enviar uma mensagem, gravar um registro, fazer uma requisição a um endereço interno.
É aqui que a injeção deixa de ser um constrangimento e vira um incidente. O raio de impacto é tudo o que o agente tem permissão de fazer.
- 04
Vazamento do prompt de sistema e de segredos
Fazer o modelo repetir suas próprias instruções, as definições de suas ferramentas ou trechos de configuração que recebeu.
O prompt de sistema costuma conter regras de negócio, endpoints internos e, às vezes, credenciais que ninguém queria deixar ali.
- 05
Recuperação entre tenants
Uma recuperação delimitada pedindo educadamente ao modelo, e não filtrando a consulta.
Um prompt não é controle de acesso. Se o filtro mora nas instruções, uma instrução ignorada é um vazamento de dados.
- 06
Saída renderizada como marcação ou código
Saída do modelo colocada na página como HTML, ou em um shell, uma consulta ou um eval.
Injeção clássica com uma nova origem. O modelo agora é uma entrada não confiável, e que um atacante pode influenciar.
- 07
Gasto ilimitado como negação de serviço
Um endpoint que chama um modelo pago sem limite de taxa, sem teto por conta e sem limite de tamanho do que aceita.
O ataque não é derrubar você. É inflar uma conta até que você mesmo se derrube.
- 08
O que os logs guardam
Prompts e respostas gravados em logs e ferramentas de análise — incluindo tudo o que um usuário colou neles.
As pessoas colam credenciais de produção e dados de clientes em caixas de chat. A retenção dos seus logs agora é uma questão de proteção de dados.
O que o QA Spider automatiza, e o que não automatiza
Dito de forma estreita o bastante para que você possa nos cobrar.
Automatizamos isto
- Conduz seu produto em um navegador real, de modo que os casos de streaming, timeout, nova tentativa, estado vazio e estado de erro acima viram testes de UI comuns — executados em um agendamento e a cada deploy.
- Verifica a API por baixo da interface, incluindo as rotas que seu front-end chama para chegar a um modelo.
- Registra o que falha como ticket no Jira, Azure DevOps, ClickUp, GitHub ou Linear, com os passos para reproduzir e uma captura de tela.
- Faz uma verificação de segurança de superfície no site público: transporte e cabeçalhos de segurança, flags de cookies, conteúdo misto, exposição de formulários, DNS e proteção contra falsificação de e-mail.
Não fazemos isto
- No momento, não oferecemos uma suíte automatizada de prompt injection ou jailbreak. Se alguém disser que o rastreador dele faz isso de fábrica, peça que mostre as asserções.
- Não avaliamos se uma resposta está correta. Isso é um problema de eval, exige a sua verdade de referência e é uma disciplina diferente do teste de regressão.
Perguntas que as pessoas fazem sobre testar apps de AI
- Como testar uma aplicação de AI é diferente de testar um app web comum?
- A interface é a mesma; a saída não. Um app comum devolve a mesma resposta duas vezes, então dá para fazer asserções sobre ela. Um modelo devolve algo diferente a cada vez, então as asserções passam para a forma e o comportamento em torno da resposta — que ela chega, faz streaming, termina, falha de forma visível e custa o que deveria.
- Como escrever uma asserção quando a saída muda toda vez?
- Faça asserção sobre o contrato, não sobre o texto. Que uma resposta chegou dentro do orçamento, que foi interpretada com o esquema que você pediu, que citou um documento que o usuário pode ver, que uma recusa é exibida como recusa. Julgar a redação é um eval, executado à parte da suíte de regressão.
- O que é prompt injection e como testá-lo?
- Instruções escondidas em conteúdo que o seu sistema lê — um documento, uma página web, um ticket — e que o modelo então obedece. Você testa plantando instruções em todos os canais que chegam ao modelo e verificando que o efeito nunca se concretiza: nenhuma ferramenta chamada, nenhum dado devolvido, nenhum prompt de sistema repetido.
- Qual é o problema de segurança mais comum em produtos de AI?
- Os sem glamour. Uma chave de provedor acessível pelo navegador, um endpoint de modelo sem limite de taxa e uma recuperação delimitada por uma instrução no prompt em vez de um filtro na consulta. Os três são mais baratos de encontrar do que um jailbreak engenhoso e mais prováveis de existir.
- O QA Spider consegue testar meu produto de AI?
- O comportamento em volta do modelo, sim: streaming, timeouts, novas tentativas, recusas, estados de erro, limites de taxa e a API por baixo da interface, testados em um navegador real a cada deploy. Suítes automatizadas de prompt injection não são algo que oferecemos hoje, e preferimos dizer isso a deixar você descobrir depois.
- Vocês verificam se o modelo dá respostas corretas?
- Não. A correção exige a sua verdade de referência e pertence a um ambiente de avaliação que você mantém e versiona junto com seus prompts. O teste de regressão responde a outra pergunta: o que funcionava ontem continua funcionando depois do deploy de hoje.
Aponte-o para o seu produto de AI.
O comportamento em volta do modelo — streaming, timeouts, novas tentativas, recusas, limites de taxa e a API por baixo da interface — testado em um navegador real, a cada deploy.