C2 · Teoria — o oráculo metamórfico aplicado a E2E de navegador

Camada C2 do estudo WebTestPilot · v2.2 · corte 27 ago 2026 Público: quem vai desenhar ou revisar MRs. Critério de qualidade: cada afirmação rastreável a pesquisa/bibliografia.md, com nível de evidência. Pressupõe o vocabulário do C1.

1 · Escopo e formalização

Teste metamórfico (MT) troca a pergunta. Em vez de "qual é a saída correta para esta entrada?" — que ninguém responde para uma página inteira — pergunta-se "que relação deve valer entre a saída desta entrada e a de uma entrada derivada dela?". A técnica nasce em Chen, Cheung & Yiu (1998) — o survey de referência é Chen, Kuo, Liu, Poon, Towey, Tse & Zhou (CSUR 2018) — e tem três peças: caso-fonte, transformação que produz seguidores, e a relação metamórfica que serve de oráculo. Violação indica defeito em algum lugar do conjunto; conformidade não conclui nada.

Barr et al. (TSE 2015) colocam MT entre os oráculos derivados, com a ressalva de que "poderiam ser considerados mecanismo de oráculo especificado, porque MRs são propriedades da verdade de base" — e a formalização que importa aqui: uma MR é "a constraint on the values of stimulating the single SUT f at least twice, observing the responses, and imposing a constraint on how they interrelate" (N1). Mesmo sistema, ao menos duas execuções, entradas relacionadas. É esse trio que distingue MT do teste diferencial (dois sistemas, mesma entrada) e do de regressão (duas versões, mesma entrada).

1.1 Os três moldes

Para E2E, o lado da entrada é o problema difícil: "que perturbação do fluxo gravado ainda é um fluxo válido?" é uma pergunta de MRIP, e Zhou et al. já oferecem dois MRIPs aplicáveis a fluxos: change direction (ordenação) e change sequence in time — "the change of time sequence of some input events (such as in the context of testing an interactive system)". O catálogo do § 4 traz a coluna MRIP por isso: um gerador, humano ou LLM, consome primeiro a transformação do fluxo, depois a relação sobre R(·).

1.2 As árvores de MRPs

Ying, Towey, Bellotti, Chua & Zhou (STVR 2025, N1) organizam os MRPs publicados em duas árvores de família, com raízes Symmetry ("diferentes pontos de vista dos quais o sistema parece o mesmo") e Sets ("entradas e saídas representáveis como conjuntos, relacionadas por operações de conjunto"). Para sistemas de consulta, os sete MRPs de Segura et al. (MET 2019) — Input Equivalence, Shuffling, Conjunctive Conditions, Disjunctive Conditions, Disjoint Partitions, Complete Partitions, Partition Difference — são nós da árvore Sets.

O que as árvores mostram sobre o catálogo deste estudo (§ 4): o grupo A tem nó publicado para cada MR; o grupo B (estado e navegação) só cabe sob a raiz abstrata Symmetry, sem nó; o grupo C (derivado do MST-wi, apresentado no § 3) não tem nó nenhum. A originalidade do catálogo está nos grupos B e C — e tem fonte que a delimita, não só afirmação nossa. (Detalhe das árvores lido na tese aberta de Ying, 2024; a equivalência com o artigo STVR, fechado, é inferência nossa.)

2 · O achado central

Existe um corpo maduro de MT para a web, e ele é quase inteiramente API-level. Web services são o domínio de aplicação mais popular no survey de Segura et al. (TSE 2016): 16% dos 58 estudos de aplicação, cerca de nove trabalhos, numa categoria que o survey chama de "web services and applications", com corte em novembro de 2015 (N1). O corpo cresceu desde então — RESTest, AGORA, ARMeta — e continua presumindo requisição isolada, sem estado de UI.

O oráculo metamórfico sobre fluxo E2E em navegador real tem uma linha do tempo curta e três artefatos, todos de tese:

Morfify define a similaridade na tese (§ 3.5; StringSimilarity.java). O metamorph é lido em detalhe no § 5 e no § 6.4.

Zahid, em detalhe (tese lida, N1; código, N4). Oito MRs sobre o Spring PetClinic, instanciadas por 18 testes; 18 MRs escritas sobre um WebShop Django/React próprio, quatro mostradas. A avaliação em E2E é por injeção manual de falhas — 6 + 4, uma por MR: o Stryker gerou 551 mutantes no WebShop e foi abandonado por tempo; mutação automática só no terceiro caso, uma API REST sem UI (185 mutantes: MR 77,3 % contra 62,5 % do teste funcional). Resultado E2E: MR 10/10, baseline 1/10 — com viés de seleção declarado pelo próprio autor (§ 5.1, § 6.1: "we needed to modify MT test cases after injecting the fault"). No código, textContent('body'), count() de classe CSS e waitForTimeout fixo; a relação é descrita como "equal, subset, superset"; banco reiniciado antes de cada teste. Dos 16 testes rotulados "MR" no WebShop, 15 são asserções com valor literal e 1 é relação genuína entre duas execuções (contagem sob variação de caixa). É o único ponto de dados de MR validada em E2E web, e é fraco: as faltas foram escolhidas por MR e as relações ajustadas depois; não há taxa de falso positivo.

Nenhum dos três define a projeção como decisão registrada: Morfify e MST-wi usam similaridade sobre HTML inteiro (o MST-wi: "We rely on edit distance to determine if Web pages are equal", colapsando estados abaixo de 5% do comprimento — N1); o metamorph escolhe os observáveis depois de ver a fonte; Zahid escreve valores literais em código — a priori, mas asserção especificada, não projeção tipada. O que existe de projeção pensada a priori está em outra literatura: a de abstração de estado de GUI para inferência de modelo — Genie (OOPSLA 2021) define "a GUI state (abstracted from a set of structurally equivalent GUI runtime layouts)" com critério por tipo de widget; Odin (FSE 2022) usa pool de regras de abstração; Yandrapally, Stocco & Mesbah (ICSE 2020) estudam quais diferenças de DOM são near-duplicates; Liu et al. (2026) comparam seis abstrações. É dela que R(·) deve herdar (C4 § 5) — e é, com a linha X-PERT (§ 7.2), a evidência N1 para a escolha de projeção por locator tipado. [protocolo · A18]

Vizinhos que não são o alvo mas que um revisor cobra: ASSURE (2025, N2) faz MT no navegador, sobre a saída de extensões com LLM, não sobre o fluxo da aplicação; Tu & Lee (JISE 2025; arXiv jul/2026) instanciam os sete MRPs de Segura sobre uma app web real (busca de cursos da NCKU) com execução e comparação automáticas — crawler, PICT, fuzz — sem LLM e sem ground truth. O espaço não está vazio: está despovoado, e povoado só por teses e estudos de caso.

A ação ficou barata; o julgamento não. A onda de 2026 em teste E2E — agentes LLM dirigindo o navegador — resolveu a ação e não o julgamento. O WebTestBench (Kong et al., 2026, N2) mede isso: sem o checklist ground-truth, nenhum dos dez modelos de fronteira chega a um terço de F1; com ele, o mesmo modelo quase dobra (números no C1 § 1). Três ressalvas sobre esse número: o corpus é de aplicações geradas por IA (Lovable.dev) e curado por densidade de defeito; a tarefa medida é "gerar checklist aberto + dirigir o browser em horizonte longo + detectar defeito", não "avaliar uma relação entre duas execuções"; e metade do erro sobrevive ao oráculo perfeito. Daí a divergência D1 (gerar o critério é o gargalo — ou a execução ainda é?), mantida: gerar o critério é um gargalo, o maior isolado medido — não o único. O roadmap de Molina, Gorla & d'Amorim (TOSEM 2025) aponta na mesma direção. O oráculo metamórfico é a técnica mais adequada ao E2E e a menos automatizada.

O WebTestPilot de Teoh et al. (FSE 2026) é homônimo deste estudo e sem relação com ele (C1 § 3); é a linha rival, descrita no § 7.4.

3 · Mapa do campo

Maturidade: ● consolidado, ferramenta usável, validação em campo · ◐ replicado, ferramenta de pesquisa · ○ emergente · ◌ ocupado só nominalmente.

A linhagem de GUI móvel, trabalho a trabalho:

• Genie (OOPSLA 2021): "leverage the commonly-held independent view property … to manufacture property-preserving mutant tests" — 34 bugs em 12 apps, TP 40,9%, abstração de estado por tipo de widget.
• SetDroid (ISSTA 2021): setting-wise metamorphic fuzzing, 42 defeitos em 26 apps.
• Odin (FSE 2022): bugs como comportamento desviante em estados profundos.
• MVTE (JSS 2025): 5 MRs de autenticação, 159 vulnerabilidades.
• Xiong et al. (2026): LLM gera propriedades por exploração, executa e refina por feedback.

4 · Catálogo de MRs para fluxo E2E

Os exemplos numéricos vêm da aplicação de referência do C4 § 9 — uma loja Vendure com seed de 54 produtos.

Convenções. R(x) é a projeção observável da tela após executar o fluxo x — conjunto de itens com chave estável, um total, o estado de um formulário. Nunca o DOM inteiro, nunca um screenshot. Cada cartão traz: molde (MRIP → MROP, nó na árvore de Ying quando existe), fonte/seguidor/relação, o que pega, pré-condições, e classe de custo: K0 (sem estado — roda contra produção desde que R(·) exclua ranking, personalização e promoção), K1 (par com estado, contexto próprio), K2 (fan-out n+1).

Quatro regras que valem para o catálogo inteiro:

1. Enumeração completa. As MRs de conjunto (MR-A1, MR-A2, MR-A4, MR-A6, MR-A7, MR-A8) exigem que R(·) enumere o resultado até a última página, com condição de parada por locator (o link "próxima" deixa de existir), não por contagem estimada. Onde a enumeração for cara, degradar para cardinalidade |R(seg)| ≤ |R(fonte)| — foi o que Zhou et al. usaram em motores de busca. Contador declarado ≠ itens enumerados é erro de setup do oráculo, não violação.
2. A relação é fixada antes de executar, e falsificada por mutante. Numa MR os dois operandos vêm do sistema por definição — o que precisa estar fixado fora dele é a relação: operador, direção, lista de observáveis, guardas e exclusões, registrados em arquivo (anchoredOn) antes da primeira execução, e alterados depois só com revisionNotes. Uma MR é propriedade necessária, não suficiente (Chen 1998): a falha que a preserva passa. A resposta clássica é análise de mutação — falsifiedBy é isso, com ferramenta (Stryker, PIT) onde há código. Onde não há (SaaS de terceiro, K0 em produção) a MR é admitida com anchoredOn: observed e peso menor — como Zhou et al. (TSE 2016) fizeram em motores de busca sem especificação, e acharam falhas reais. Os erros de especificação da relação que o metamorph documenta (§ 6.4) são todos pegáveis por um mutante; o argumento está no § 6.5.
3. Requisito declarado, não suposição. MR-B2 (idempotência) e MR-C4 (one-shot) são mutuamente exclusivas por ação; MR-A5 (normalização) e MR-C8 (validação) só são MR se a regra for requisito. A escolha é dado da MR, não descoberta da execução.
4. Fallback de consulta alargada. Sites que, ao zerar o resultado, mostram "similares" violam ⊆ corretamente. MR-A1 precisa de guarda: seguidor com resultado vazio e aviso de alargamento não é violação.

Grupo A — consulta e coleção

Fonte: sistemas baseados em consulta. Toda tela com busca, filtro, faceta ou ordenação.

MR-A1 · Refinar filtro só pode encolher · MRIP add condition → MROP Subset · nó Conjunctive Conditions · K0

fonte     busca(q) + filtro A
seguidor  busca(q) + filtro A ∧ B
relação   R(seg) ⊆ R(fonte)

Pega faceta que aplica OR onde deveria AND, e contador dessincronizado da lista. Pré-condições: a semântica ∧ está declarada (código do filtro ou schema); guarda de alargamento (regra 4); B ⊄ A no seed — com B ⊂ A (Electronics ∧ Computers) a instância é vácua: A ∨ B = A, e o mutante OR real não viola (20 ⊆ 20, medido na app de referência, C4 § 9.2); Computers ∧ Photo viola (11 → 20).

MR-A2 · Alargar filtro só pode crescer · MRIP relax condition → MROP Superset · nó Disjunctive Conditions · K0

fonte     busca(q) + filtro A
seguidor  busca(q) + filtro A ∨ B
relação   R(seg) ⊇ R(fonte)

Ressalva de UI: storefronts headless de 2026 costumam ANDar facetas do mesmo grupo — a instância canônica não existe na tela. Instância substituta legítima: hierarquia de coleções (Electronics ⊇ Computers), ancorada no seed. Exercita a camada de dados, não a de filtro; declarar qual.

MR-A3 · Ordem de aplicação é irrelevante (comutatividade de ações) · MRIP change sequence in time → MROP Equality · extensão nossa (N5), sem nó · K0

fonte     aplica A, depois B, depois ordena
seguidor  ordena, depois B, depois A
relação   R(seg) = R(fonte)   (como lista, se a ordenação faz parte do estado)

Não confundir com o Shuffling de Segura, que é sobre critério de ordenação (→ MR-A7); MR-A3 é comutatividade da composição de filtros — propriedade diferente e mais interessante para SPA com estado acumulado. Pré-condições: A e B independentes e co-disponíveis nas duas ordens; nenhum é aba, rádio ou faceta mutuamente exclusiva — o metamorph tem o caso literal ("'Playas' and 'Ciudades' are mutually exclusive tabs … reversing their order should produce different states. The MR is therefore semantically invalid"). E o estado tem de ser acumulado na UI: num storefront onde o estado é a URL (?facets=1&facets=2), a ordem é irrelevante por construção do URLSearchParams e MR-A3 é tautologia (medido na app de referência, C4 § 9.2). Vale em SPA com estado em memória.

MR-A4 · As partes somam o todo · MRIP partition attribute → MROP Complete · nó Complete Partitions · K2 (n+1)

fonte     lista sem filtro de categoria
seguidor  lista filtrada por cada categoria cᵢ
relação   ⋃ᵢ R(segᵢ) = R(fonte)   ∧   Σᵢ |R(segᵢ)| = |R(fonte)|

Detecta item órfão, categoria fantasma e paginação que descarta a última página. Pré-condições: a partição é provada no seed, não observada na tela (no Vendure: 54 = 20 + 20 + 14, nenhum órfão; marca não particiona — 25 sem marca). Amostragem sob orçamento: para qualquer S ⊆ {cᵢ}, valem ⋃ᵢ∈S R(segᵢ) ⊆ R(fonte) e Σᵢ∈S |R(segᵢ)| ≤ |R(fonte)| — perde-se só a completude. k+1 execuções por noite com S rotativo recuperam a completude ao longo de dias sem tornar a relação incorreta. O custo real é em page loads, não em execuções: MR-A4 no Vendure são 4 navegações e 11 loads.

MR-A5 · Entradas equivalentes, saída idêntica · MRIP Query-Meaning → MROP Equality · nó Input Equivalence · K0

fonte     busca("cadeira")
seguidor  busca("  CADEIRA  ")
relação   R(seg) = R(fonte)

Pré-condições: normalização é requisito declarado do componente (plugin de busca + banco), não "da app" — no Vendure a caixa é insensível nos dois deploys, mas o trim diverge entre a demo pública (0 resultados) e a instância local (1) — medido na app de referência (C4 § 9.2). Atenção à tautologia: se o cliente faz trim() antes de navegar, a variante com espaços via UI não testa nada — testar via URL.

MR-A6 · Apresentação não altera conteúdo · MRIP change view → MROP Equivalence (Segura 2018, escopo REST; sem nó próprio na subárvore de QBS) · K0

fonte     lista em grade, 20/página
seguidor  mesma lista em tabela, 50/página
relação   R(seg) = R(fonte)   (como conjunto)

Isola bug de virtualização e paginação. Ressalva de UI: grade/tabela e itens por página são raros em 2026; substitutos legítimos — viewport, moeda, locale — isolam bugs diferentes (responsividade, filtro por moeda). Declarar qual.

MR-A7 · Critério de ordenação não altera o conjunto · MRIP change direction → MROP Equivalence · nó Shuffling · K0

fonte     lista ordenada por preço
seguidor  mesma lista ordenada por relevância / nome / inverso
relação   R(seg) = R(fonte)   (como conjunto)

O Shuffling de Segura, agora no lugar certo. A mais barata do catálogo: dois page loads, sem estado. Zhou et al. (TSE 2020) validaram em 65 sites comerciais: "sorting the results in ascending and descending orders should return the same set of results in reverse order" — a variante forte, como lista invertida, também vale quando a chave de ordenação é única.

MR-A8 · Diferença de partição · MRIP partition attribute → MROP Difference · nó Partition Difference · K2 (n+1; 3 se houver faceta negada)

∀ k ∈ 1..n−1 :  R(fonte) − ⋃ᵢ≤k R(segᵢ)  =  ⋃ⱼ>k R(segⱼ)

Segura et al. (MET 2019, § III-G): "the outputs of the follow-up test cases are pairwise disjoint and their union contains the same items as the source output". Detecta o mesmo bug de partição que MR-A4, mas localiza qual categoria vazou. Pela fórmula literal o custo é n+1, igual ao de MR-A4 — só cai para 3 execuções quando a UI oferece filtro negado ("todas menos v₁"), instância condicional que muitas facetas exclude permitem. O "not exploited" de Segura já foi datado por Tu & Lee (JISE 2025).

Grupo B — estado e navegação

O espaço em branco da literatura, com fonte que o delimita: nenhum nó nas árvores de Ying (2025); só a raiz Symmetry. Todas exigem a camada de isolamento de estado, exceto MR-B3.

MR-B1 · Ida e volta retorna ao início · MRIP inverse action → Equality · K1

fonte     estado S
seguidor  S → adiciona(i) → remove(i)
relação   R(seg) = R(fonte)

Carrinho, favoritos, seleção múltipla, follow/unfollow. Vaza estado residual — contador que não decrementa, badge que não some, total com frete fantasma. Pré-condição: i ∉ S — se o item já estiver no estado, "adicionar" soma quantidade e "remover" apaga a linha inteira, e a relação falha sem bug. Ancoragem: "vazio" é definido pelo requisito (lines.length === 0 no código), não pela tela. Existência de um pedido interno com zero linhas é estado legítimo e sai de R.

MR-B2 · Repetir não acumula · MRIP duplicate action → Equality · K1

fonte     aplica ação idempotente a uma vez
seguidor  aplica a duas vezes
relação   R(seg) = R(fonte)

Duplo-clique em submit, F5 sobre POST, cupom já aplicado, marcar como lido. Pré-condição obrigatória: a ação é declaradamente idempotente — adicionar o mesmo item ao carrinho duas vezes deve somar quantidade e não serve. No Vendure o cupom é idempotente por código (order.service.ts:1086). fc.scheduledModelRun do fast-check aplica-se diretamente aqui para corrida de duplo-submit. Dual: ação de uso único → MR-C4.

MR-B3 · Rotas diferentes, mesmo destino · MRIP path independence → Equality · K0

fonte     home → categoria → produto p
seguidor  URL direta de p  |  busca → p
relação   R(seg) = R(fonte)

Encontra tela que só monta corretamente quando herdou estado da navegação anterior. Ancoragem: breadcrumb que reflete o caminho é legitimamente diferente e sai de R; breadcrumb que reflete a coleção canônica entra. Decidir pelo código, não pelo resultado. Dual: pular passo obrigatório → MR-C3; a relação inverte.

MR-B4 · Grandeza acumulada não regride · MRIP add element → Order (≥) · K1

fonte     carrinho: n itens, subtotal T
seguidor  mesmo carrinho + item de preço p > 0
relação   subtotal(seg) ≥ T   ∧   n+1 itens

Relação de ordem, não de igualdade. Desconto progressivo quebra a MR sobre o total — acrescentar item pode destravar faixa e baixar. Projetar o subtotal antes de desconto (subTotalWithTax), com pré-condição "nenhuma promoção ativa no canal". Pré-condições adicionais: p ∉ carrinho (senão a quantidade incrementa e o número de linhas não muda) e estoque(p) ≥ 1 — ou projetar a quantidade total em vez do número de linhas.

MR-B5 · Sessão reconstruída é a mesma · MRIP session cycle → Equality · K1

fonte     logado, em estado S
seguidor  logout → login → navega até S
relação   R(seg) = R(fonte)

Pré-condições: R exclui o que é legitimamente por-sessão (tokens, timestamps, "visto por último"); ordenar pedidos por código, não por updatedAt; guestOrder = ∅ — a app de referência faz merge de carrinho no login (regra em C4 § 9.2); sem a pré-condição a relação vira R(seg).cart = merge(guest, R(fonte).cart). Reforço: logout invalida o estado antigo → MR-C6.

MR-B6 · Mesma ação, outro usuário · MRIP change subject → Inequality ∨ Error · MST-wi CWE_266_…_OTG_AUTHZ_002 · K1

fonte     usuário A executa ação autorizada
seguidor  usuário B (sem permissão, não supervisor de A) replica
relação   isError(R(seg))  ∨  R(seg) ≠ R(fonte)        ← disjunção, como no paper
pré       !isSupervisorOf(B, A) · cannotReachThroughGUI(B, url) · afterLogin
          · notTried(B, url) · !isError(R(fonte))

!isError(fonte) existe porque "it is impossible with these inputs to characterize the output that should be observed for User(2)"; cannotReachThroughGUI exige dados de navegação dos dois usuários — sem crawler, é declaração manual. Implementa-se com dois storageState e o mesmo fluxo; desde o Playwright 1.61, BrowserContext.credentials cobre passkey. No MST-wi, 8 das 76 MRs têm essa forma. Guarda de tempo: o Vendure expõe pedido anônimo por 2 h após criação (shop.api.graphql); page.clock resolve.

Grupo C — derivadas do MST-wi

Mineração das 76 MRs (sobre o Catalog of MRs.pdf do Zenodo 7702754): 22 têm gêmea funcional direta (29%), 39 colapsam em três MRs de robustez (51%), 15 são só segurança — canal, certificado, CSRF, path traversal (20%). A classificação é editorial (N5) sobre lista completa verificada (N1/N4). Todas exigem isolamento de estado, exceto MR-C7 e MR-C10.

MR-C1 · Mesmo papel, mesmo resultado (isolamento de tenant) · troca de sujeito, forma de igualdade · K1

fonte     usuário A (papel P) executa fluxo f
seguidor  usuário B (mesmo papel P) executa f com seus próprios dados
relação   R(seg) = R(fonte)   módulo campos por-usuário

Gêmea da MR-B6. Pega dado de A que aparece para B, feature flag presa a usuário, permissão herdada. Pré: mesmo papel declarado; nenhum é supervisor do outro; R exclui os campos por-usuário antes de executar.

MR-C2 · Identificador de outro usuário (IDOR) · mutação de parâmetro com valor de outro sujeito · CWE_15_639_OTG_AUTHZ_004 · K1

fonte     A navega até seu recurso r_A → URL /pedidos/{id_A}         (sessão de A)
seguidor  B abre a mesma URL /pedidos/{id_A}                        (sessão de B)
relação   R(seg) ∈ { erro/404 , conteúdo que B já viu pela GUI }   ∧   R(seg) ≠ R(fonte)

Pré: inventário de ids por usuário coletado nas execuções de A; relação disjuntiva — igualdade estrita com "tela de erro" gera falso positivo quando a app redireciona.

MR-C3 · Guarda de workflow: pular passo obrigatório é recusado · remoção de passo · CWE_841, OTG_SESS_008 · K1

fonte     s1 → s2 (obrigatório) → s3 → estado S
seguidor  s1 → s3, em contexto novo
relação   R(seg) ≠ R(fonte)  ∧  R(seg) mostra bloqueio  ∧  backend inalterado

Checkout sem endereço, wizard que aceita ?step=3, ação sem login. Pré: a precedência é requisito documentado — senão é MR-B3 (atalho legítimo) e a relação inverte.

MR-C4 · Ação de uso único recusa repetição · ação duplicada · OTG_BUSLOGIC_005 · K1

fonte     aplica ação one-shot a  (cupom único, voto, token de reset)
seguidor  aplica a duas vezes
relação   R(seg) ≠ R(fonte)  ∧  segunda tentativa exibe recusa  ∧  saldo = o da fonte

Dual exato de MR-B2. Pré: a ação é declarada one-shot — no MST-wi o sinal é urlOfActionChangesOverMultipleExecutions (URL com nonce). Sem a declaração, MR-B2 e MR-C4 são contraditórias e uma delas é falso positivo garantido.

MR-C5 · Expiração por relógio · Wait(Δt) inserido · CWE_262_…, OTG_SESS_007 · K1

fonte     estado S com prazo T → ação a
seguidor  page.clock avança Δt > T → ação a
relação   R(seg) ≠ R(fonte)  ∧  R(seg) mostra expiração
dual      Δt < T  ⇒  R(seg) = R(fonte)

Sessão eterna, reserva de estoque sem fim, oferta relâmpago que não acaba. Pré: T declarado; o relógio do backend também precisa ser controlável, ou a MR só testa o cliente — o MST-wi muda a data do sistema.

MR-C6 · Logout invalida o estado antigo · replay de credencial antiga · CWE_613_OTG_SESS_006 · K1

fonte     login → captura storageState₁ → navega até S
seguidor  logout → novo contexto com storageState₁ → tenta S
relação   R(seg) ≠ R(fonte)  ∧  R(seg) é tela pública/login

Logout só de cliente, cookie que sobrevive, id de sessão que não roda.

MR-C7 · Redundância não altera o resultado · parâmetro duplicado · OTG_INPVAL_004 · K0

fonte     busca(q) + filtro A
seguidor  busca(q) + filtro A + filtro A   (?cat=x&cat=x)
relação   R(seg) = R(fonte)

Extensão de MR-A5. Filtro acumulativo que soma em vez de idempotir; parser de querystring que pega o último valor.

MR-C8 · Entrada fora do domínio é recusada e o estado não muda · mutação de campo · CWE_521, CWE_434, CWE_611 · K1

fonte     submete formulário F válido → sucesso, estado S'
seguidor  mesmo F com um campo fora da regra
relação   R(seg) ≠ R(fonte)  ∧  erro junto ao campo  ∧  estado = S

Validação só no cliente, upload que aceita qualquer extensão. Pré: regra de validação documentada; uma mutação por seguidor.

MR-C9 · Entrada hostil degrada graciosamente · string de ataque, "igual ou erro controlado" · 35 MRs colapsadas (CWE_79*, CWE_89*, CWE_792_* …) · K0/K1

fonte     busca(q) / formulário com valor v
seguidor  mesmo fluxo com v' = v + caractere especial | string longa | marcação
relação   R(seg) ∈ { R(fonte), erro controlado }  ∧  sem 5xx, stack trace, console error, alert

É MR + oráculo implícito: sozinha é frouxa; com a família E anexada, pega busca que quebra com aspas e campo que ecoa HTML. Não substitui DAST.

MR-C10 · Canonicalização de URL · codificação alternativa · CWE_289*, CWE_647 · K0

fonte     abre /produto/123
seguidor  abre /produto/123/ , /produto/%31%32%33 , /PRODUTO/123
relação   R(seg) = R(fonte)   ∨   R(seg) = 404        (nunca um terceiro recurso)

Pré: política de canonicalização declarada.

Resumo, priorização — e quem escreve

Esta tabela é a lista de referência das fases para C3 e C4. MR-C9 fica na Fase 1 porque é oráculo implícito com MR anexada; MR-A3 e MR-C7 são condicionais porque, em UI cujo estado é a URL, são tautologia (cartão MR-A3).

Quem escreve — leitura de um QA lead que executou MR-A1 e MR-B1 na app de referência (relato em pesquisa/revisoes/v2/R6-qa-lead.md). De 24, um time de QA escreveria 9: MR-A1 (com B ⊄ A), MR-A4 amostrada, MR-A7, MR-B1, MR-B3, MR-B6/MR-C2, MR-C3, MR-C6 e MR-A5 só para caixa. Sete se explicam em cinco minutos: MR-A1, MR-A7, MR-B1, MR-B3, MR-B6, MR-C3, MR-C6. Cortaria: MR-A2 (não existe na UI), MR-A3 e MR-C7 (tautologia em UI de URL pura), MR-A6 (sem grade/moeda no seed), MR-A8 (fórmula que ninguém lê; MR-A4 amostrada localiza igual), MR-B4, a disjunção de MR-B6, MR-C2 com inventário, MR-C4 e MR-C8 (asserção com valor esperado é mais curta e mais forte), MR-B5 sem a pré-condição guestOrder = ∅ (o merge substitui, não soma), MR-C1 (o excludes fica maior que R), MR-C5 (não move o relógio do backend), MR-C9 (é oráculo implícito), MR-C10 (é do framework). Onde a MR é genuinamente melhor: enumeração completa embutida (página 2 perdida, item órfão — bugs que ninguém caça à mão), amortização por projeção, ausência de valor esperado que envelhece com o seed. Onde é só mais complicada: tudo com valor esperado barato. A MR soma à suíte; não a substitui.

Na aplicação de referência (Vendure + starter Next.js), 12 das 12 MRs avaliadas na instanciação são instanciáveis, três com ressalva de UI (MR-A2, MR-A5, MR-A6); R(·) de todas foi escrita a partir de código, schema, seed ou HTML estático, nenhuma a partir de execução (N4). O formato de arquivo que carrega tudo isso — owner, costClass, anchoredOn, excludes, falsifiedBy, setupErrors, revisionNotes — está no C4.

5 · Geração de MRs — onde o LLM entra e onde não

Escrever a MR à mão exige conhecimento de domínio, e é esse custo que impede adoção. Li et al. (TOSEM 2025, N1) classificam 81 estudos de geração; as contagens da tabela abaixo são do artigo. (Atenção: o preprint arXiv 2406.05397 tem outro título e não contém as contagens.)

Os vizinhos diretos — trabalhos que fazem uma das peças do que este estudo propõe:

Mais distantes, em uma linha cada: MR-Scout minera pares fonte/seguidor implícitos em suítes unitárias; MR-Coupler usa análise estática de dependências; MeMo (JSS 2021) faz NLP sobre Javadoc, só equivalência, 91% P / 69% R — reconhece MR em texto, não inventa; Shin et al. (QUATIC 2024) geram EMRs na DSL do MST-wi por few-shot, 78,6% dos statements corretos por anotação manual, sem executar; Bose et al. (2026, N2) fazem prompt aberto sobre classe/método, 141 validadas de 14.916 — grounding em código, não em GUI.

Formulações mais fortes da lacuna — "ninguém instancia MRP por LLM sobre tela concreta"; "ninguém instancia sobre tela, executa em navegador e valida contra baseline antes de julgar" — não se sustentam: Pei et al. instanciam taxonomia predefinida sobre componente, o metamorph instancia molde travado sobre tela, Zahid faz o ciclo completo à mão, e "validar no original" é o protocolo-padrão de toda avaliação por mutação, não uma lacuna. O que sobrevive é menor e mais honesto:

A brecha. Não há trabalho publicado que descreva um pipeline automatizado em que um LLM instancia MRPs sobre tela de aplicação, o harness executa fonte e seguidor em navegador, e a MR só é promovida após passar no baseline e ser falsificada por mutante. Cada peça existe separada (MRG instancia sem LLM; metamorph instancia com LLM e não valida; Zahid valida por falhas manuais e instancia à mão; Xiong executa e refina, em móvel e sem MR). A contribuição possível é a automação do filtro, não o filtro — engenharia, não lacuna de literatura. [protocolo · A15]

A evidência que reordena a prioridade é a do metamorph: MR gerada por LLM e não validada, com nenhuma violação confirmada como bug do site (números e triagem no § 6.4). É suficiente para o C4: validação contra baseline e relação fixada a priori são pré-requisito de existência (decisão fechada no C4 § 2, ADR-13), não recomendação.

A assimetria que torna a camada construível continua verdadeira, mas com número e com o risco à vista: errar na proposta custa uma execução de validação (≈ US$ 0,05 e 10 min de parede por MR com modelo barato, no metamorph); errar no julgamento entra no relatório. MetaFOE mostra que metade das instâncias cai mesmo com verificação por execução (compilação + fuzzing) — o que torna a validação indispensável e é, ao mesmo tempo, o risco direto de E9a (que fração das MRs instanciadas por LLM sobrevive à validação?): se metade cai, o custo de descoberta dobra.

6 · Por que o navegador é hostil — cinco frentes

MT presume, na formulação original, que fonte e seguidor são execuções independentes de uma função. Um fluxo E2E viola isso em quatro frentes ao mesmo tempo; há uma quinta que não vem do navegador, mas da forma do oráculo.

6.1 Estado compartilhado. Fonte e seguidor tocam o mesmo backend. Adicionar ao carrinho na fonte contamina o seguidor. Ou se isola o estado por execução — a decisão de arquitetura mais cara do C4 — ou as MRs precisam ser robustas a interferência, o que reduz o catálogo utilizável ao grupo A com K0.

6.2 Não-determinismo. Timestamps, IDs gerados, ranking personalizado, A/B, anúncios, ordem de resolução de requisições, animação. R(·) precisa excluir tudo isso explicitamente — e a exclusão é registrada com motivo, senão vira ancoragem por outro caminho ("excluir o que deu diferente"). Número (metamorph, N2): sem page.clock, HAR ou storageState, 35 MRs em replay duplo deram 45,7% estáveis, 20% de drift de observação, 34,3% de falha de execução — em sites de produção maduros.

6.3 Custo de execução. Mínimo 2 execuções por MR; n+1 para partição. A literatura de priorização de MRs existe — Srinivasan & Kanewala (STVR 2022): critérios de falta, cobertura e diversidade de dados; redução no tempo até a primeira falta de 23–61% (BBMap) e 10–40% (LingPipe) — mas os sujeitos custam milissegundos por execução, e dois dos três critérios exigem cobertura de código ou histórico de faltas, que um oráculo E2E caixa-preta não tem. Em MT de sistema web pelo navegador há um trabalho de seleção sob orçamento: AIM (Bayati Chaleshtari, Marquer, Pastore & Briand, TSE 2024) minimiza o conjunto de entradas do MST-wi por clustering e algoritmo genético — 84% (Jenkins) e 82% (Joomla) de redução de tempo mantendo a detecção. É sobre entradas, não sobre MRs, e é o ponto de partida. Seleção sob orçamento é condição de existência, e as classes K0/K1/K2 do catálogo são a primeira resposta.

6.4 Violação ≠ bug. Bug or not Bug? (SANER 2023) propõe distinção binária por ARM num toy example — não há taxonomia de causas. A linha de constraints de MR (MetaTrimmer, 2310.00338) e as classes de veredito de 2606.17529 (pass / fail / skip / out-of-relation-domain / inconclusive) são as pistas. A taxa de violação→bug depende do processo de autoria, não do domínio — e há pontos suficientes para dizê-lo: com MR gerada por LLM e não validada, 0 confirmados em 26 (metamorph, N2, um batch — detalhe abaixo); com MR humana de ordenação e projeção de contagem sobre 65 grandes sites comerciais, 60 dos 65 violaram ao menos uma vez, com inconsistências reproduzíveis 10× em dias diferentes (Zhou et al., TSE 2020, N1 — Amazon devolvendo 160 resultados por preço crescente e 851.077 por decrescente); com propriedade de vista independente em GUI Android, TP 40,9% (Genie, N1); em MT de NLP, ~60% de TP em 937 violações analisadas à mão (Cho, Ruberto & Terragni, ICSME 2025). Em E2E web com MR validada há um ponto, fraco: Zahid detecta 10/10 faltas manuais contra 1/10 do baseline, com faltas escolhidas por MR e relações ajustadas depois, sem taxa de falso positivo (§ 2). E9c (com MR validada em E2E web, que fração das violações é bug?) continua aberto e exige app própria com defeitos semeados antes de escrever as MRs. Sem triagem, o falso positivo inviabiliza CI; e a triagem, em 2026, virou produto (Momentic, Datadog, Checkly, mabl — ver C3).

O batch do metamorph, em detalhe: de 100 tentativas, 63 compilam; de 48 pares executados, 26 violam; das 26 violações, nenhuma foi confirmada como bug do site — 17 eram oráculo mal especificado, 7 harness (autocomplete, passo perdido, corrida), 1 MR inválida, e 2 ficaram sem resolução (Amazon, filtro dependente de ordem; GitHub, repositório ausente na primeira página). A reclassificação é nossa (N5) sobre a prosa do autor em analysis.md — a coluna triage do CSV bruto está vazia. Um batch, um modelo barato, um locale, 48 h. O autor conclui, sobre este oráculo: "strict failures are triage triggers". Há ainda 2 falsos negativos e ≥ 7 passes vácuos. Os quatro modos de falha que o batch mostra — direção do operador invertida, not_equal frouxo, igualdade vácua sobre lista vazia, observável auxiliar frágil — são erros de especificação da relação, todos pegáveis por um mutante (§ 6.5). O que o dado mostra é a qualidade de MR gerada e não validada; não é taxa-base de nada.

6.5 O oráculo que não pode falhar. Uma MR é propriedade necessária da função correta, não suficiente (Chen, Cheung & Yiu, 1998): defeito que preserva a relação passa. Se o motor de filtro estiver quebrado de modo independente de ordem, MR-A3 obtém o mesmo resultado errado duas vezes e conclui que está tudo bem. É a falha mais silenciosa das cinco — o painel fica verde.

Canedo (2026, N2, autor único, um sistema) dá vocabulário recente ao problema — specification-anchored (expectativa fixada fora do código sob mutação) versus state-anchored (flui dele) — e inclui MRs entre duas execuções nas suítes que analisa, tratando-as como legítimas; o que ele não faz é estudar a ancoragem de MRs em separado, e a condição de escopo é explícita: "State anchoring cancels only when the source of the observed state lies inside the mutate target." A transposição para o catálogo é nossa, e tem uma armadilha: um "teste" que reprovasse toda projeção lida de page.* reprovaria toda MR, inclusive as que este estudo chama de spec-anchored. Numa MR os dois operandos vêm do sistema por definição; o que precisa estar fixado fora dele é a relação — regra 2 do catálogo. A tese de Zahid é o caso documentado da hostilidade em fonte primária: "we needed to modify MT test cases after injecting the fault", e a MR de controle de acesso foi recodificada em 0/1 depois de a igualdade valer sob a falta.

A resposta não é ferramenta nova: é análise de mutação, que Zahid faz à mão e que falsifiedBy operacionaliza; mais dois testes baratos — observável obrigatório não vazio (rejeitar [] como pass) e direção do operador vinda do molde, não do modelo. Os quatro modos de falha do metamorph (§ 6.4) são erros de especificação da relação, e todos cairiam num mutante.

7 · A vizinhança não-metamórfica

7.1 Propriedade temporal sobre um trace — e a fronteira porosa com MR. Quickstrom (O'Connor & Wickström, PLDI 2022) — LTL sobre traço de navegador; parado desde ago/2024. Sucedido pelo Bombadil (Antithesis, MIT, jan/2026, 1.451 ★, 197 arquivos em 24 repos consumidores): "I consider Bombadil the successor of Quickstrom" (Wickström); Rust + CDP, spec em TypeScript, roda em CI e dentro do Antithesis. É propriedade temporal sobre um trace de sessão única — o que o C1 registra como família P, fora da tabela de seis porque não julga por comparação de execuções. A fronteira com MR, porém, é porosa: next(x) com closure sobre o estado atual expressa "estado após ação = f(estado antes)", e o playground do próprio autor contém filterFromAllShowsFewerItems / filterToAllShowsMoreItems / filterChangeDoesNotCreateItems — MR-A1, MR-A2 e MR-A6 como propriedades sobre trace; um consumidor de código aberto (LibreChat) usa next(now(…)).implies(…) em E2E de produto. Toda MR cujo seguidor é a próxima ação da mesma sessão (MR-A1/-A2 por refinamento, MR-A6, -A7, -B1, -B2, -C7, -C10 — entre elas as K0 da Fase 2) é expressável no Bombadil hoje, com custo de autoria menor (uma propriedade, um gerador de ações, sem par). O que ele não faz: par em contextos separados (MR-A4/-A8 n+1, MR-B5, -B6, MR-C1–C6), validação contra baseline, falsificação. Classificado como P ∩ D: concorrente direto da Fase 2 e candidato a motor de relação da camada 3 (arquitetura do C3 § 2) para MRs de sessão única (C3 § 3.3; experimento em C4 § 12).

7.2 Diferencial. A família C tem literatura própria em web, e ela é evidência N1 para a escolha de projeção por locator tipado (C4 § 5): WebDiff (ICSM 2010) começou com DOM + histograma de screenshot e registrou falso positivo por "small shifts"; CrossCheck (ICST 2012) separou visual, DOM e trace; X-PERT (ICSE 2013 / ISSTA 2014) abandonou imagem como detector primário — "use of image-comparison techniques for detecting structure and content XBIs had a high false positive rate" — e migrou para posição relativa + conteúdo textual, com 76% de precisão e 95% de recall. A projeção R(·) deste estudo (locator tipado, ARIA snapshot) é herdeira direta disso. No mercado: Meticulous (base × head, respostas gravadas, US$ 15M em jul/2026), Diffy (primary/secondary/candidate — o protocolo de calibrar o ruído rodando a mesma versão duas vezes é a arte prévia exata do falso positivo de MR; licença CC BY-NC-ND, só ler), Keploy e GoReplay (replay de tráfego, família B/C). Todos compartilham "mesma entrada, dois lados"; MT é "entradas relacionadas, um sistema". [protocolo · A18]

Comparação cabeça a cabeça: replay diferencial só acha regressão entre versões; MT acha bug que já estava lá, em versão única — Zhou et al. (TSE 2020) o fizeram em 60 de 65 sites. É o argumento de venda mais forte do estudo e, em E2E com MR validada, ainda uma promessa com um único ponto fraco (E9c; § 6.4): o comprador de Meticulous paga custo de autoria ≈ 0 e aceita não ver o bug antigo; o estudo ainda precisa mostrar qual bug antigo D acha que C (Meticulous) e P (Bombadil) não acham, e quanto vale — é o enunciado E12.

7.3 Juízes LLM de GUI — e a regra "o veredito é código". Três trabalhos de 2025–26 (N2) mostram o que um juiz LLM faz e não faz:

A regra: o veredito é código. O C1 § 3 a enuncia; os números acima dizem por que é regra e não preferência. Não porque juiz LLM "não funcione" — em sucesso-de-tarefa passa de 90% só com screenshots; em detecção de bug (Trident) fica em 50–72% de precisão, que é o número que decide, porque nenhum CI o aceita como oráculo primário. O SLR de Mughal & Bilal (2026) mostra o padrão do campo: "just over half of the corpus reaches a verdict with no specification at all". O agente descobre o caso-fonte e propõe; o LLM tria depois. O que distingue a família D é a origem do predicado (relação entre execuções, não especificação inferida), e é essa origem que precisa de evidência (E9c): a linha rival já mostra 96/96 com spec inferida, e os dados E2E de relação são 0/26 (metamorph, MR não validada) e 10/10 (Zahid, faltas manuais escolhidas por MR). O verde silencioso existe dos dois lados: surface UI match no juiz, pass vácuo e not_equal frouxo na MR (§ 6.4). [protocolo · A20]

7.4 Agentes que inferem oráculo de spec. WebTestPilot (FSE 2026): pré/pós-condições sobre elementos simbolizados; 96/96; 4 apps com 100 bugs injetados. Temac (2025) e HxAgent (2026) atacam planejamento multiagente sem tratar do oráculo. Todos são a linha rival: melhor experiência de autoria, oráculo especificado por trás.

8 · Problemas abertos

Ordenados pelo quanto bloqueiam um sistema real, com o que já se sabe sobre cada um.

1. MRIPs para fluxo gravado. Que perturbação de um fluxo E2E produz um seguidor válido? Publicados: change direction, change sequence in time (Zhou 2020) e independent view — inserir eventos independentes no fluxo (Genie, OOPSLA 2021, validado em 12 apps). O catálogo usa mais nove sem nome publicado (inverse action, duplicate, path independence, change subject, remove step, wait, encode…). Nomear e validar esses MRIPs em web é contribuição possível deste projeto.
2. Projeção R(·) como decisão registrada. Os três artefatos de MT E2E não a definem como decisão; a literatura de abstração de estado de GUI (Genie, Odin, Yandrapally 2020, Liu 2026) o faz para inferência de modelo, com seis abstrações comparadas. O que falta é transpor isso para oráculo metamórfico com registro (anchoredOn/excludes). Há doze instâncias na app de referência e sete regras (C4 § 5) — começo de resposta ao E10 (como se define R(·) numa app real, e quanto custa?). Custo estimado: ~35–40% do esforço de um piloto.
3. Seleção sob orçamento onde a execução custa minutos. Priorização de MRs só em domínios de milissegundos; em MT web pelo navegador só AIM (TSE 2024), e sobre entradas. Classes K0/K1/K2 e amostragem de MR-A4/MR-A8 são a primeira resposta; diversidade de dados é o critério transplantável.
4. Taxa de violação→bug e triagem. Pontos existentes: 0/26 (MR gerada, não validada), 60/65 sites (MR humana, Zhou 2020), 40,9% TP (Genie), ~60% (MT de NLP), 10/10 vs 1/10 (Zahid, faltas manuais escolhidas por MR — fraco). Nenhum com mutantes semeados antes das MRs. Não existe taxonomia de causas; existem constraints e classes de veredito. A resposta exige app própria com defeitos semeados — E9c.
5. Isolamento de estado a custo aceitável. Entre mockar tudo (perde integração) e resetar backend a cada par (caro), a resposta do C4 é sidecar por execução; o teto de paralelismo e o custo são as perguntas do E11 (implantação em AWS e escalabilidade?).
6. Métricas de qualidade de MR em E2E. Mutation score e cobertura são herança de teste unitário. Candidatos: poder de detecção sobre mutantes semeados × estabilidade sob não-determinismo × custo em page loads.
7. Instabilidade de MRs geradas por LLM. ARMeta e metamorph relatam: equivalência semântica inconsistente entre sessões, not_equal frouxo, passes vácuos. Mitigação conhecida: molde travado, saída tipada, validação por execução.

Fontes desta camada em pesquisa/bibliografia.md. Protocolo de busca das asserções de ausência (36 consultas em 5 bases + 6 em chinês) em pesquisa/exploracao/X1-literatura.md § 4–5; mineração do MST-wi e leitura do metamorph em X2-mstwi-metamorph.md; instanciação de R(·) em X5-app-referencia-projecao.md.

Registro das revisões e explorações que produziram esta camada: pesquisa/protocolo.md § 6; nota de leitura da tese de Zahid: pesquisa/exploracao/X6-tese-zahid.md.