C1 · Introdução — o problema do oráculo em teste E2E

Camada C1 do estudo WebTestPilot · v2.2 · corte 27 ago 2026 Público: quem chega. Critério de qualidade: situar em dez minutos, sem simplificar errado. A escala de evidência e as convenções de código que o resto do estudo usa estão no § 5.

1 · Todo teste tem duas metades

Um teste é um caso — o que fazer — e um oráculo — como saber se o resultado está certo. Em teste unitário o oráculo é uma linha: expect(soma(2, 2)).toBe(4). O valor esperado é conhecido, pequeno e estável.

Em teste ponta-a-ponta (E2E) o "resultado" não é um valor. É uma página renderizada, com DOM, requisições em voo, animação, estado de sessão e estado de backend. Não existe predicado exato para "esta tela está correta". É possível escrever o caso para cada fluxo; o que custa caro — e quebra a cada redesign — é escrever o oráculo de cada um.

Isso tem nome e idade: é o oracle problem (Barr, Harman, McMinn, Shahbaz & Yoo, TSE 2015). E a assimetria que ele descreve piorou em vez de melhorar. Gerar ação ficou barato: crawler, fuzzer, agente LLM clicando na tela. Julgar o que apareceu continua sendo trabalho humano. Hoje dá para explorar um site inteiro automaticamente; decidir se o que apareceu é bug ou comportamento esperado é o que trava.

O dado que mede isso: o WebTestBench (mar/2026) avaliou dez modelos de fronteira dirigindo o navegador em 100 aplicações e 1.750 casos. Nenhum passou de 30% de F1 — o melhor, GPT-5.1, ficou em 26,4%. Quando os autores entregam o checklist do que verificar, o mesmo modelo vai a 46,8%, e o melhor da tabela (Claude Sonnet 4.5) a 49,2%. Gerar o critério de julgamento é um gargalo — o maior isolado que se mediu, ainda que não o único; há uma leitura alternativa desse dado, registrada como divergência D1 (§ 5).

2 · As seis famílias de oráculo

A literatura canônica (Barr et al., 2015) reconhece quatro gêneros: oráculo especificado (317 trabalhos), derivado (245), implícito (76), e "no test oracle" (56) — como lidar com a ausência de oráculo automatizável, o que na prática é o humano. Este estudo refina os quatro em seis famílias, porque em E2E de navegador o gênero "derivado" abriga três coisas com custo e comportamento muito diferentes — e é numa delas que o estudo se concentra. A equivalência "no oracle = humano/LLM" é editorial e está declarada como tal.

Três notas sobre a tabela:

• Não é uma partição. Um produto real pode cair em mais de uma família: o Meticulous, produto de replay comparado no C3 § 5, é derivado no eixo do baseline (B) e pseudo-oráculo no eixo da versão (C). Use a tabela para escolher técnica, não como taxonomia formal.
• A família F corta em outro eixo. As cinco primeiras dizem de onde vem o valor esperado; a F diz quem decide. É por isso que ela pode aparecer em qualquer ponto de um pipeline — como oráculo primário (onde falha) ou como triador de uma violação já detectada (onde tem lugar).
• Uma sétima letra aparece adiante. O C2 § 7 e o C3 chamam de família P a propriedade temporal sobre um trace de sessão única (Quickstrom, Bombadil): "sempre que o usuário refina o filtro, a lista não cresce", verificada ao longo de uma só sessão. Não entra na tabela porque não compara duas execuções — julga um trace contra uma fórmula —, mas fica na fronteira da D, e por isso ganha letra.

3 · Como se combinam na prática

As famílias não competem. A arquitetura mais rendosa que este estudo encontrou empilha:

E  implícito      varredura em toda execução — custa nada, pega o lixo óbvio
D  metamórfico    relações determinísticas — pega lógica sem valor esperado
F  humano/LLM     só como triador da violação já detectada, nunca como juiz primário
A  especificado   os poucos fluxos críticos que merecem asserção à mão
B  derivado       regressão visual, em camada separada

A regra que organiza tudo, e que o C4 transforma em arquitetura: o modelo pode propor e pode triar; o veredito é código. Isso não é diferencial deste estudo — em 2026 é consenso operacional. Diz o mesmo um trabalho homônimo, o WebTestPilot de Teoh et al. (FSE 2026), agente de teste web de outro grupo e sem relação com este estudo, que avalia seus predicados por código; e disse o mesmo a Octomind, ferramenta de geração de testes por IA que encerrou o produto em 2026 (C3 § 7): "AI should not be used during runtime. It's slow. It's brittle. It's costly." O que distingue a família D é de onde vem o predicado: de uma relação entre execuções, não de uma especificação inferida. É essa origem, e não a regra, que precisa de evidência — e o C4 diz como obtê-la.

4 · Vocabulário mínimo de teste metamórfico

O resto do estudo usa estes termos sem reapresentá-los.

Dois termos merecem uma frase a mais.

Mutante é um defeito plantado de propósito no sistema — uma linha comentada, um operador trocado — que a relação tem de detectar. É a resposta à ancoragem: fixar a relação antes de executar e provar que ela falha quando o sistema está errado. Sem isso, uma MR é só uma propriedade necessária — a limitação fundacional do método, conhecida desde 1998: a relação valer não prova que o sistema está certo; ela não valer é que prova que algo está errado.

Projeção é a palavra que carrega o problema. A MR é a parte fácil — "encolher só pode encolher" cabe numa linha. Definir o que comparar, excluindo timestamp, ranking personalizado, animação e tudo que é legitimamente diferente entre duas execuções, é onde mora o trabalho de engenharia. O C4 dedica uma seção a isso.

5 · Como ler o resto do estudo

Níveis de evidência. Toda afirmação nos quatro documentos carrega um nível: N1 resultado revisado por pares · N2 preprint ou relato dos autores · N3 capacidade declarada por fornecedor · N4 verificação direta nossa, datada · N5 julgamento editorial. Os N4 envelhecem e são reverificados a cada rodada. Os N5 são as afirmações mais importantes e as menos apoiadas — por isso o alvo prioritário de revisão. PISTA marca um indício não confirmado: algo visto de passagem que ainda precisa ser aberto antes de virar afirmação.

Códigos que aparecem nas páginas. As MRs do catálogo são MR-A1…MR-C10 (C2 § 4); as classes de custo de uma MR são K0 (sem estado), K1 (par com estado) e K2 (fan-out); as decisões de arquitetura são ADR-01…ADR-16 (C4). Uma marca como [protocolo · A15] ao fim de um parágrafo aponta para a asserção falsificável correspondente em pesquisa/protocolo.md § 4 — é rastreabilidade para quem revisa, não leitura obrigatória. Os enunciados E e as divergências D são estes:

O que este estudo não é. É uma revisão narrativa estruturada, não uma revisão sistemática: sem string de busca pré-registrada, sem dupla extração. Afirmações de exaustividade ("nenhum produto faz X") vêm acompanhadas do protocolo de busca que as sustenta, e valem só para o que foi buscado. Nenhum produto comercial foi executado — a capacidade de produto é sempre N3; o Playwright e a aplicação de referência (Vendure) foram executados num laptop para escrever e rodar duas MRs com mutantes (C4 § 9–10); nada foi executado na AWS; nenhum resultado publicado foi replicado. A metodologia completa, as asserções e o registro das rodadas de revisão estão em pesquisa/protocolo.md.

Fontes desta camada: Barr et al. (TSE 2015) · Chen, Cheung & Yiu (1998) · Zhou, Sun, Chen & Towey (TSE 2020) · Segura et al. (TSE 2016; MET 2019) · Kong et al., WebTestBench (2026) · Teoh et al., WebTestPilot (FSE 2026) · Canedo, Oracles That Cannot Fail (2026). Referências completas em pesquisa/bibliografia.md.