A geração de casos de teste com IA é a parte do trabalho de qualidade assistido por IA com mais evidência publicada, o que torna invulgarmente possível separar o que está demonstrado do que é apenas afirmado. A evidência também é menos lisonjeira do que o marketing.
Gerar testes a partir do código e gerar testes a partir de requisitos são operações diferentes, com modos de falha diferentes. A geração a partir do código produz testes que descrevem o que o software faz. A geração a partir de requisitos produz testes que descrevem o que deveria fazer. A diferença é o problema do oráculo: um teste gerado a partir do código herda os bugs desse código como comportamento esperado.
Qual é a diferença entre gerar a partir do código e a partir de requisitos?
Respondem a perguntas diferentes. Confundi-las é o erro com mais consequências na geração de casos de teste com IA.
| Gerado a partir de | O que os testes descrevem | Na prática |
|---|---|---|
| Código | Descreve o que o código faz | Apanha regressões face ao comportamento atual. Não apanha nenhum bug que já exista, porque esse bug passa a ser o resultado esperado. Serve para sistemas legados sem testes e para aumentar a cobertura depressa. |
| Requisitos | Descreve o que deveria fazer | Apanha comportamento que nunca foi implementado corretamente. Não apanha nada que o requisito tenha deixado de dizer. Serve para funcionalidades novas, trabalho regulado e rastreabilidade. |
O que mede realmente a investigação sobre geração de casos de teste com IA?
Há três conclusões sobre geração de casos de teste com IA que vale a pena conhecer antes de qualquer compra. A primeira é que cobertura não é deteção de falhas. Um trabalho sobre geração de testes guiada por mutação mediu um prompt normal a um modelo de linguagem com 53 por cento de mutation score, que não melhorou ao longo de quatro iterações sem feedback de mutação. Com feedback de mutação, a abordagem chegou aos 89,5 por cento. O mesmo conjunto de trabalhos refere que, em quase 24.000 testes que falharam em código mutado, mais de 99 por cento passaram no programa original, e conclui que os modelos não têm precisão suficiente para raciocinar de forma fiável sobre alterações semânticas ao código.
A leitura prática: um conjunto de testes gerado pode apresentar uma cobertura alta e não detetar metade das falhas introduzidas de propósito no código que cobre. A cobertura mede execução. O mutation score mede se o teste daria conta de uma mudança de comportamento.
A segunda é que os testes gerados são diferentes dos escritos por pessoas. Um estudo empírico de 2.232 commits relacionados com testes concluiu que os agentes de IA escreveram 16,4 por cento dos commits que acrescentam testes, com testes mais longos, maior densidade de asserções e menor complexidade ciclomática do que os equivalentes escritos por pessoas. Os ganhos de cobertura foram comparáveis, mas o âmbito dos testes tendeu a ser mais localizado em contribuições complexas. Mais asserções não é automaticamente melhor: um trabalho sobre test smells encontrou uma forte correlação negativa entre o tamanho do modelo e a frequência de smells, sendo a assertion roulette, em que um teste que falha não consegue dizer que asserção falhou, a mais afetada.
A terceira é que nenhuma abordagem atual está completa. Uma revisão sistemática de 2026 sobre geração de testes com IA a partir de requisitos em linguagem natural analisou 21 estudos primários face a seis dimensões de qualidade: automação, tratamento da ambiguidade, aplicabilidade ao domínio, rastreabilidade, rigor da avaliação e controlo de alucinações. Não encontrou nenhuma abordagem que cumprisse as seis ao mesmo tempo. É a frase mais útil da literatura para quem compra, porque saber de quais destas seis precisa realmente transforma uma comparação impossível numa comparação exequível.
O que funciona bem hoje na geração de casos de teste com IA?
Na geração de casos de teste com IA, quatro coisas funcionam com razoável confiança. Traduzir critérios de aceitação claros em cenários estruturados é rápido e quase sempre correto quando o requisito está bem escrito, e é o caso mais forte da categoria. Expandir combinações de valores limite, classes de equivalência e permutações de entradas é onde os conjuntos gerados encontram de facto cenários que uma pessoa com prazos apertados teria saltado. Aumentar a cobertura de código sem testes é rápido e útil, com a ressalva acima sobre o que essa cobertura prova. E rascunhar em vez de decidir é o fluxo de trabalho realista: a geração produz um rascunho que um engenheiro revê, corta e corrige. As equipas que tratam o resultado como final ficam com o problema do mutation score. As que o tratam como primeiro rascunho ficam com a maior parte da velocidade e nenhuma da falsa confiança.
Um valor publicado sobre velocidade: uma fonte do setor indica que a geração de casos de teste acelera 60 por cento, reduzindo o tempo médio por caso de cerca de uma hora para dezanove minutos. Vem de um fornecedor da categoria e não de um estudo independente, e mede tempo de escrita e não qualidade dos testes.
O que ainda não funciona?
Porque é que a manutenção decide se isto compensa
A criação é a parte barata. Um conjunto de testes escreve-se uma vez e mantém-se durante anos. As referências públicas colocam a manutenção anual de software em 15 a 20 por cento do custo de construção, e os conjuntos de testes seguem o mesmo padrão: o custo recorrente ultrapassa o inicial em qualquer sistema com uma vida útil normal. Uma ferramenta que reduz para metade o tempo de escrita e deixa a manutenção igual mexeu num número pequeno.
É aqui que gerar a partir de requisitos se distingue de gerar a partir do código, e é o argumento mais forte a favor do primeiro. Quando um requisito muda, os testes derivados desse requisito são identificáveis, e só esses precisam de ser gerados de novo. A regeneração seletiva guiada por alterações aos requisitos é o que a literatura de investigação aponta como caminho para reduzir o esforço de manutenção, em vez de reescrever um conjunto de testes sempre que a aplicação muda. Os testes gerados a partir do código não têm essa ligação: estão presos a uma implementação que muda constantemente, e nada lhe diz quais deixaram de fazer sentido quando um módulo foi refatorado.
Sobre os nossos próprios números: a página de produto do Qualiagentic indica que a manutenção representa 60 a 70 por cento do esforço de QA. Esse número descreve o problema, não um resultado que prometemos. Não publicamos uma percentagem de redução, pelas razões que este artigo explica. Um valor credível teria de vir acompanhado da base de comparação, do tipo de aplicação e do período de medição. Enquanto não pudermos publicar os três, preferimos mostrar o resultado no seu próprio conjunto de testes, durante um piloto.
Como avaliar uma ferramenta de geração de casos de teste com IA?
-
1Pergunte a partir de quê gera. Código, requisitos ou ambos. Isto determina o que os testes podem dizer-lhe, antes de qualquer comparação de funcionalidades.
-
2Corra mutation testing sobre o resultado. A cobertura é o número que lhe vão mostrar. O mutation score é o número que responde à pergunta.
-
3Verifique a rastreabilidade. Consegue seguir um teste gerado até ao requisito de onde veio e até um resultado associado a uma versão da aplicação? Em trabalho regulado, isto não é opcional.
-
4Dê-lhe um requisito verdadeiramente ambíguo. Veja se a ferramenta assinala a ambiguidade ou a resolve em silêncio. O segundo comportamento vai custar-lhe mais tarde.
-
5Pergunte pela regeneração seletiva. Quando um requisito muda, a ferramenta identifica e gera de novo apenas os testes afetados, ou produz um conjunto novo para ser o cliente a reconciliar?


