WebTestPilot

Pesquisa sobre oráculos metamórficos para teste E2E — como um teste ponta-a-ponta decide que passou, quando não existe valor esperado contra o qual comparar — e a especificação da stack que vai implementar isso em AWS.

Quatro documentos, um por camada, escritos para públicos diferentes: quem chega, quem vai escrever relações, quem vai escolher ferramenta, quem vai implementar.

---

Onde ler

Site (GitHub Pages): https://apethor.github.io/metamorphic-e2e-oracles/ — as cinco páginas com navegação cruzada, geradas de estudo/.

	Camada	O que tem
🧭	Índice	O que mudou entre versões, por onde começar
🪨	C1 · Introdução	O problema do oráculo, seis famílias de oráculo, vocabulário, como ler o resto — dez minutos
📐	C2 · Teoria	O que a academia sabe; catálogo de 24 relações metamórficas prontas para tela; por que o navegador é hostil; onde está a brecha
🔩	C3 · Mercado	Que ferramentas existem, camada a camada; comparativo verificado em 27/08/2026; quem está vivo, quem morreu, quem cobra o quê
🏗️	C4 · Stack	A especificação implementável: 16 decisões de arquitetura, AWS com custo por par, formato de uma relação em código, a função que extrai o que se compara na tela, aplicação de referência, três pilotos

Entregáveis (release v2.2): relatório executivo em PDF (10 páginas, linguagem de negócio), deck de apresentação em PPTX (15 slides, com notas) e o site em .zip. Fontes em entregas/.

Para regenerar: editar o .md em estudo/, rodar python paginas/build.py (páginas com links absolutos) ou python paginas/build.py --site docs (site do Pages, links relativos).

Por onde começar

• Chegou agora: C1, dez minutos.
• Vai escrever relações metamórficas: C2 § 4 (catálogo e "quem escreve") e C4 § 4–5 (formato e projeção). Duas relações executadas contra a app de referência, com código, em pesquisa/revisoes/v2/R6-qa-lead.md § 5.
• Vai escolher ferramenta: C3 § 5 (matriz) e § 7–8 (sinais de mercado, risco).
• Vai implementar: C4 inteiro; comece pelo § 10.2 (MVP de uma semana e o que medir primeiro) e § 12 (experimentos abertos).
• Vai revisar: pesquisa/protocolo.md § 4 (asserções falsificáveis) e § 5 (personas e rubrica).

O que o estudo concluiu, em cinco linhas

1. Nenhum produto comercial faz teste metamórfico E2E. O mais próximo é o Bombadil (Antithesis), que já verifica propriedades sobre uma sessão de navegador e é o concorrente direto da segunda fase do plano.
2. "O veredito é código" é consenso, não diferencial. O que distingue o oráculo metamórfico é de onde vem o predicado — de uma relação entre duas execuções, não de uma especificação inferida por um modelo. Essa origem ainda precisa de evidência empírica.
3. O oráculo que não pode falhar é o que ajusta a relação depois de ver o resultado. A resposta não é ferramenta nova: é fixar a relação antes e prová-la com um defeito plantado (mutante) que ela tem de detectar.
4. Por cenário, uma relação custa cerca de duas vezes uma asserção comum; por família de tela, amortiza. O inimigo prático é o estado ainda não assentado depois de uma ação — sem um passo de espera explícito, 4 de 4 execuções deram falso positivo.
5. Em AWS, o custo escondido é a rede, não o navegador. Um NAT custaria de 4 a 9 vezes o compute; a aplicação sob teste roda dentro da mesma task; o gargalo é estado e cota de vCPU.

Estrutura

WebTestPilot/
├── README.md
├── estudo/                     FONTE DE VERDADE — um documento por camada
│   ├── C1-introducao.md        problema do oráculo · seis famílias · vocabulário · enunciados e divergências
│   ├── C2-teoria-mr.md         estado da arte · catálogo MR-A1..A8, B1..B6, C1..C10 · hostilidades · a brecha
│   ├── C3-mercado.md           camadas · matriz 27/08 · agentes e transporte · vizinhança · sinais · busca
│   └── C4-stack-spec.md        princípios · ADR-01..16 · laço · defineMR · R(·) · AWS · custo · Vendure · pilotos
├── paginas/
│   ├── build.py                estudo/*.md → paginas/*.html (e --site docs/)
│   └── 0*-*.html               gerados
├── docs/                       site do GitHub Pages (gerado)
├── entregas/                   roteiro do deck · build_deck.py · deck .pptx · relatório executivo .html/.pdf
└── pesquisa/                   material bruto e registro
    ├── protocolo.md            enunciados E1–E12 · metodologia · asserções A01–A32 · ciclo · changelog
    ├── plano-v2.md             estratégia da v2 (ondas, premissas)
    ├── achados.md              os 13 achados
    ├── bibliografia.md         ~85 fontes com DOI e nível de evidência
    ├── catalogo-mrs.md         nota de reuso: mudanças, classes de custo, priorização
    ├── ferramentas.md          scripts de reverificação (gh api, npm, DNS) + divergências N4
    ├── exploracao/             X1 literatura · X2 MST-wi/metamorph · X3 mercado · X4 AWS · X5 app/R(·) · X6 tese de Zahid
    └── revisoes/
        ├── _template.md
        ├── R1..R5-*.md         rodada 1 (v1)
        └── v2/                 rodada 2: R1 acadêmico · R2 red team · R3 AWS · R6 QA lead (executou)
                                fechamento: R7 par leitor · R8 auditoria de consistência

Versões

• v1 (tag v1) — corte 26/08/2026, rodada 1 de revisão aplicada.
• v2 (tag v2) — corte 27/08/2026: reestruturação em quatro camadas, onda de exploração, onda adversarial, execução da app de referência.
• v2.1 (tag v2.1) — 28/08: pendências fechadas (tese de Zahid lida, merge de carrinho, Hegel, adoção do Bombadil, DOIs COMPSAC/AITest).
• v2.2 (tag v2.2) — 28/08: revisão editorial (par leitor R7) e auditoria de consistência (R8) aplicadas: nomes sem colisão, histórico de versão fora do texto, enunciados e divergências definidos no C1, ADRs completas.

Histórico detalhado, pendências e próxima rodada (o MVP): pesquisa/protocolo.md § 6–7.