Can LLMs Test Terminal User Interfaces?

Imagine que você é um desenvolvedor de videogames. Você construiu um mundo lindo e complexo com montanhas, cidades e personagens, mas esqueceu de testar se as portas realmente abrem ou se o jogador fica preso em uma parede. No mundo do software, isso é um pesadelo. Para evitar isso, programadores usam "testadores automatizados" — assistentes robóticos que clicam em botões, digitam comandos e tentam quebrar o software para encontrar bugs antes que os usuários reais o façam.

Por muito tempo, tivemos dois tipos principais de software para testar. Primeiro, existem as Interfaces Gráficas de Usuário (GUIs), como os aplicativos no seu telefone ou computador. Elas são como salas luxuosas e coloridas com portas, janelas e botões rotulados. Testadores podem facilmente perguntar ao computador: "Onde está o botão 'Iniciar'?" e clicar nele. Segundo, existem as Interfaces de Linha de Comando (CLIs), que são como telegrafos da velha guarda. Você digita um código secreto e o computador responde com texto. Elas são fáceis de testar porque são simples: digite isso, receba aquilo.

Mas existe um terceiro tipo de software, mais sorrateiro, chamado Interface de Usuário de Terminal (TUI). Pense nelas como aplicativos "retro-futuristas". Elas parecem os antigos telegrafos (apenas texto em uma tela preta), mas agem como as salas luxuosas. Elas têm cursores em movimento, menus pop-up e estados complexos que mudam conforme você digita. São populares entre hackers, administradores de sistema e até assistentes de codificação de IA. O problema? Não sabemos realmente como testá-las adequadamente. Elas são complexas demais para os testadores de telegrafos simples, mas carecem dos "botões rotulados" que os testadores de salas luxuosas precisam. Este artigo faz uma grande pergunta: os robôs de Inteligência Artificial (IA) modernos conseguem aprender a testar esses aplicativos de texto complicados, ou estão tão confusos quanto nós?

---

A Grande História de Detetive das TUIs

Os pesquisadores por trás deste artigo decidiram brincar de detetive. Eles reuniram uma coleção massiva de 197 aplicações TUI do mundo real — desde gerenciadores de arquivos até monitores de sistema — e as submeteram a um teste de estresse rigoroso. Mas primeiro, eles tiveram que resolver um mistério: Quão bem esses aplicativos estão sendo testados agora?

Eles espiaram dentro do código dessas 197 aplicações e encontraram um segredo chocante. Apenas cerca de 12% do código de teste realmente tentava interagir com a tela. Pior ainda, quase metade dos testes que realmente tocavam na tela nunca digitaram uma única tecla! Eles apenas verificavam se a tela parecia correta quando o aplicativo abria pela primeira vez, como verificar a pintura de um carro, mas sem nunca ligar o motor. Acontece que a maioria das TUIs está sendo testada de olhos fechados.

Então, a equipe construiu suas próprias ferramentas para ver o que aconteceria se deixassem a IA e o acaso à solta nessas aplicações. Eles criaram um laboratório "headless" (um computador sem tela, apenas um terminal virtual) e embalaram cada aplicação em um contêiner especial. Em seguida, organizaram uma corrida entre quatro estratégias diferentes:

1. O Macaco Aleatório: Um robô que apenas digita teclas aleatórias o mais rápido que pode.
2. O Guia de IA: Um Modelo de Linguagem Grande (LLM) inteligente que olha para a tela e decide o que digitar a seguir.
3. O Guia de IA com um Mapa: O mesmo robô inteligente, mas desta vez ele também descobriu os "códigos de inicialização" (argumentos) corretos para iniciar as aplicações adequadamente.
4. O Roteirista de IA: Um robô que lê o código-fonte e escreve um plano de teste antes de começar.

Eles rodaram essas estratégias contra as 197 aplicações, dando a cada uma exatamente 600 segundos (10 minutos) para encontrar bugs.

Os Resultados: Quem Vence?

Os resultados foram surpreendentes e um pouco contraintuitivos.

1. O Robô "Inteligente" não é o mais rápido.
Quando os pesquisadores observaram quantos bugs cada estratégia encontrou por execução, o Macaco Aleatório na verdade encontrou mais falhas (crashes). Por quê? Porque ele era incrivelmente rápido. Em 600 segundos, o robô aleatório conseguiu digitar centenas de teclas. Os robôs de IA, sendo pensativos e "inteligentes", passaram a maior parte do tempo pensando e esperando por suas respostas, então eles só conseguiram digitar cerca de uma dúzia de teclas no mesmo período de tempo.

2. Mas o Robô "Inteligente" é muito mais eficiente.
Aqui está a reviravolta: se você medir o quão bons eles são por tecla pressionada, os robôs de IA foram 13 vezes melhores que o macaco aleatório. O macaco aleatório estava apenas lançando dardos no escuro e acertando alguns por sorte. Os robôs de IA estavam mirando cuidadosamente. Eles foram unicamente capazes de encontrar bugs de "entrada bloqueada" (input-gated)—falhas que só acontecem se você digitar uma sequência específica de teclas para desbloquear um menu oculto. O macaco aleatório nunca descobriu o código, mas a IA sim.

3. O "Código de Inicialização" foi o verdadeiro herói.
A maior descoberta não foi a inteligência da IA; foi sua capacidade de descobrir como iniciar as aplicações. Muitas TUIs precisam de arquivos ou argumentos específicos para sequer abrir sua interface. Sem eles, elas simplesmente fecham. A estratégia que usou a IA para derivar automaticamente os inputs de inicialização encontrou o maior número de bugs e cobriu a maior parte do código. Acontece que você não pode testar um carro se não souber como girar a chave.

4. A Armadilha do "Crash".
Os pesquisadores também descobriram uma armadilha importante na forma como costumamos contar bugs. Eles descobriram que 82% dos "crashes" (programas parando inesperadamente) eram, na verdade, apenas os programas dizendo: "Ei, eu preciso de um arquivo!" ou "Eu fui instruído a parar!". Isso não são bugs reais; são apenas comportamentos normais. Se você apenas contar cada vez que um programa para, você terá alarmes falsos. A equipe teve que construir um "detector de crash" especial que observa o texto real na tela para ver se é um erro real ou apenas uma saída educada. Depois de filtrar o ruído, eles encontraram 179 bugs reais e válidos entre as 197 aplicações.

5. Mais Cobertura de Código $\neq$ Mais Bugs.
No teste de software, as pessoas geralmente acreditam que, se cobrirem mais linhas de código, encontrarão mais bugs. O artigo sugere que isso não é verdade para as TUIs. Eles descobriram que os testes que encontraram mais falhas frequentemente tinham menor cobertura de código. Por quê? Porque encontrar um crash interrompe o teste imediatamente! O teste é cortado, então ele nunca chega a cobrir o restante do código. Isso significa que, para as TUIs, contar quantas linhas de código foram tocadas é uma má maneira de medir o quão bom é um teste.

A Conclusão

O artigo conclui que o teste automatizado para essas interfaces baseadas em texto é possível, mas está longe de ser resolvido. Nenhum modelo de IA específico foi o vencedor claro; de fato, um simples testador aleatório foi competitivo porque era mais rápido. A verdadeira chave para o sucesso foi o uso de estratégias híbridas: usar a IA para descobrir como iniciar a aplicação e navegar até o estado correto, e então usar o teste aleatório de alta velocidade para estressar a interface.

Os autores também nos alertam que precisamos de ferramentas melhores. A forma atual de testar (apenas verificar se o programa para) está cheia de alarmes falsos. Eles lançaram suas próprias ferramentas, tuicov e tuibot, para ajudar outros a testar essas aplicações adequadamente. A mensagem é clara: as TUIs são uma parte enorme e crescente do nosso mundo de software, mas atualmente são o "Velho Oeste" do teste. Temos as ferramentas para começar a domá-las, mas precisamos parar de confiar em regras antigas e começar a projetar testes que entendam a natureza única e baseada em texto dessas interfaces.