# Test Web > Ciclo completo de testes E2E do TOTVS Protheus via MCP Playwright com evidências e documentação. Cobre roteiro → aprovação → execução com screenshots → validação → error handling → persistência na base de conhecimento → geração de MIT010. Substitui TIR. Use quando precisar testar rotinas Protheus, validar regras de negócio, coletar evidências ou gerar documentação de testes. - Skill: `tbc-servicos/test-web` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add tbc-servicos/test-web` - Raw SKILL.md: https://api.skillmd.com/api/skills/tbc-servicos/test-web/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tbc-servicos (https://skillmd.com/u/tbc-servicos) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tbc-servicos/test-web --- # Protheus Test Web — Testes E2E com Evidências e Documentação Ciclo completo de testes E2E do TOTVS Protheus webapp usando MCP Playwright. Substitui o TIR (TOTVS Interface Robot) por uma abordagem interativa com visão real da tela. ## Pré-requisitos - Plugin MCP Playwright instalado (`/plugin` → instalar `playwright`) - URL do Protheus webapp (porta 7600 tipicamente) - Credenciais de acesso (usuário/senha) - Ambiente, módulo e filial do teste - Roteiro de teste (arquivo markdown, documento ou instruções do usuário) - Fonte `assets/fsttst.tlpp` compilado no RPO do ambiente de teste — runner universal `dev.tools.U_Run_Aplica`, usado para abrir a rotina direto pelo campo "Programa Inicial" (sem navegar o menu). Se não estiver compilado, compilar via `/protheus:compile` antes de iniciar (fallback: navegação por menu) ## Ciclo Completo: Roteiro → Aprovação → Execução → Evidências → Documentação ### Etapa 1 — Elaboração do Roteiro de Testes Antes de executar qualquer teste, elaborar um roteiro completo e apresentar ao team leader (desenvolvedor humano) para aprovação. #### Fontes de conhecimento para o roteiro Consultar a base de conhecimento Protheus via MCP antes de elaborar: ``` searchFunction({ name: "", limit: 5 }) searchKnowledge({ skill: "protheus-test", keyword: "" }) listTests({ platform: "protheus", module: "", limit: 5 }) ``` Usar o conhecimento da Knowledge Base para entender: - Campos obrigatórios da rotina - Validações e Pontos de Entrada ativos - Regras de negócio implementadas - Fluxo esperado da rotina (inclusão, alteração, exclusão) #### Formato do roteiro Apresentar ao team leader: ```markdown # Roteiro de Teste: **Rotina:** (ex: MATA103 — Documento de Entrada) **Módulo:** (ex: SIGACOM) **Ambiente:** **Filial:** **Data:** ## Objetivo ## Pré-condições ## Cenários de Teste ### TC01 — - **Ação:** - **Dados:** - **Resultado esperado:** - **Critério VERIFICÁVEL:** ### TC02 — ... ## Cleanup ``` **REGRA:** Só prosseguir para a execução após aprovação explícita do team leader. ### Etapa 2 — Preparação de Evidências Criar diretório de evidências: ``` evidencias/ └── YYYY-MM-DD__/ ├── 01_parametros_iniciais.png ├── 02_login.png ├── ... └── relatorio.md ``` ### Etapa 3 — Execução do Teste (QA) Cada passo DEVE ser acompanhado de screenshot via `browser_take_screenshot`. Nomear sequencialmente com descrição clara. #### Fases 1-3 — Acesso à rotina via Run_Aplica (PADRÃO) Usar o runner `dev.tools.U_Run_Aplica` (fonte `assets/fsttst.tlpp`) como Programa Inicial — abre a rotina direto, sem login pelo menu: 1. `browser_navigate` → URL do webapp 2. `browser_wait_for` (5-10s) — repetir se timeout 3. `browser_snapshot` → identificar campos dos Parâmetros Iniciais 4. No campo **"Programa Inicial"**, informar `dev.tools.u_run_aplica` 5. `browser_select_option` → selecionar ambiente, clicar "Ok" 6. **Screenshot:** `01_parametros_iniciais.png` 7. Aguardar a tela **"Executa funcao"** (8-12s) 8. Preencher Empresa, Filial, Usuário e Senha do teste e clicar **"Ambiente"** (monta o ambiente via RpcSetEnv — aguardar o MsgRun terminar) 9. **Screenshot:** `02_ambiente_montado.png` 10. No campo **"Funcao:"**, digitar a função da rotina (ex.: `MATA103`) e clicar **"Executar"** 11. Aguardar a rotina abrir (10s), tratar dialogs (Moedas → Confirmar, Filiais → duplo clique + Ok) 12. **Screenshot:** `04_browse_rotina.png` > A tela também localiza funções no RPO por máscara ("Mascara Funcao" + > "Buscar", aceita `*`) — útil para confirmar que o fonte em teste está > compilado antes de executar. Erros na execução aparecem na área > "Resultado" quando "Protecao de erro" está marcada. #### Fases 1-3 (fallback) — Login e navegação por menu Somente se o `fsttst.tlpp` não puder ser compilado no ambiente: 1. `browser_navigate` → URL, aguardar, selecionar ambiente, "Ok" — **Screenshot:** `01_parametros_iniciais.png` 2. Preencher usuário/senha, "Entrar", aguardar (8-12s) — **Screenshot:** `02_login.png` 3. Alterar Ambiente se necessário (botão pesquisa → tabela → Confirmar), fechar popup "base de Desenvolvimento" se aparecer, aguardar menu (15s) — **Screenshot:** `03_menu_principal.png` 4. Clicar no grupo de menu → rotina, aguardar (10s), tratar dialogs — **Screenshot:** `04_browse_rotina.png` #### Fase 4 — Ação do Teste 1. Executar a ação (Incluir, Classificar, etc.) 2. Preencher campos conforme roteiro 3. **Screenshot a cada preenchimento relevante:** - `05_cabecalho_preenchido.png` - `06_pedido_importado.png` - `07_grid_editada.png` 4. Salvar/Confirmar #### Fase 5 — Validação 1. **Screenshot do resultado:** `08_resultado.png` 2. Se bloqueio esperado: **Screenshot:** `09_bloqueio_regra.png` 3. Se sucesso: **Screenshot:** `10_documento_gravado.png` 4. Registrar resultado: PASSOU / FALHOU / BLOQUEADO (esperado ou não) #### Fase 6 — Cleanup 1. Excluir registro criado (se necessário) 2. **Screenshot:** `11_registro_excluido.png` 3. Confirmar que dados voltaram ao estado original ### Etapa 4 — Tratamento de Erros (error.log) Se ocorrer erro SMARTCLIENT (THREAD ERROR) durante a execução: 1. **Screenshot imediato:** `XX_erro_smartclient.png` 2. Clicar em "Detalhes" no dialog de erro 3. **Screenshot dos detalhes:** `XX_erro_detalhes.png` 4. Copiar o conteúdo completo do textbox de erro (stack trace) 5. Analisar o erro: - Identificar a rotina/linha que causou (ex: `MATA103.PRW line: 3669`) - Classificar: erro de ambiente (config), erro de código (dev), erro de dados 6. **Devolver para o desenvolvedor** com: - Stack trace completo - Screenshot do erro - Análise da causa provável - Sugestão de correção (se possível) 7. **NÃO prosseguir** com o teste até o erro ser resolvido 8. Registrar a lição aprendida via `/protheus:feedback` Erros comuns que devem ser devolvidos ao dev: - `CheckSpecialKey` não configurada → problema de ambiente - `type mismatch` → campo com tipo incorreto no código - `array out of bounds` → lógica de array incorreta - `variable does not exist` → variável não declarada - Qualquer `THREAD ERROR` com stack trace apontando para `.PRW` customizado ### Etapa 5 — Review das Evidências Apresentar ao team leader: 1. Lista de screenshots com descrição de cada passo 2. Resultado de cada cenário (PASSOU/FALHOU) 3. Erros encontrados com stack trace (se houver) 4. Perguntar se o teste precisa ser reexecutado ou ajustado ### Etapa 6 — Persistência na Base de Conhecimento #### Teste bem-sucedido → Salvar via MCP Após aprovação do team leader, salvar o teste: ``` saveTest({ platform: "protheus", module: "", title: "", scenario: "", script: "", tags: "", submitted_by: "" }) ``` #### Teste com falha ou lição aprendida → /protheus:feedback Para erros encontrados, comportamentos inesperados ou lições aprendidas: Invocar `/protheus:feedback` com: - O que aconteceu (erro, comportamento inesperado) - Causa raiz identificada - Como foi resolvido (ou como deveria ser resolvido) - Contexto (rotina, ambiente, dados) ### Etapa 7 — Geração de Documentação MIT010 Após aprovação das evidências, gerar documento MIT010 (Análise de Negócio): 1. **Cabeçalho:** nome do teste, data, ambiente, responsável 2. **Objetivo:** o que foi testado e por quê 3. **Pré-condições:** dados necessários, configurações do ambiente 4. **Roteiro passo a passo:** cada ação com screenshot inline 5. **Resultado esperado vs obtido:** comparação por cenário 6. **Evidências:** todos os screenshots organizados sequencialmente 7. **Erros encontrados:** stack traces, análise, resolução 8. **Conclusão:** APROVADO / REPROVADO / PENDENTE 9. **Lições aprendidas:** o que foi registrado via feedback Para gerar o MIT010, usar a skill `/mit-docs:mit010` (plugin mit-docs) se disponível, ou gerar em Markdown/DOCX com referências às imagens. Formato de saída: perguntar ao usuário (Markdown, DOCX). ## Regras Críticas ### Formatação de Números - Separador de MILHAR = ponto (.) - Separador DECIMAL = vírgula (,) - Ao digitar valores, usar APENAS vírgula como decimal, SEM pontos - Correto: `3,676500` — ERRADO: `3676,500000` ### Checkboxes em Tabelas - Clique simples = seleciona a linha (NÃO marca o checkbox) - **Duplo clique** = marca/desmarca o checkbox ### Snapshots Grandes - Protheus gera snapshots >100K chars — salvar em arquivo com `filename` - Buscar refs via grep/python no arquivo salvo - Sempre tirar `browser_take_screenshot` para validação visual ### Tempos de Espera - Nunca prosseguir sem aguardar carregamento - Se snapshot retorna vazio, aguardar mais tempo - Ver tempos em `references/protheus-webapp-patterns.md` ### Evidências (Screenshots) - OBRIGATÓRIO em cada passo — sem evidência não há teste válido - Nomes sequenciais e descritivos - Diretório dedicado por execução ### Aprovação do Roteiro - OBRIGATÓRIO antes de executar — apresentar roteiro ao team leader - Baseado no conhecimento da Knowledge Base via MCP - Só prosseguir com aprovação explícita ### Dialogs Modais - Sempre verificar se há dialog antes de interagir com a tela - Buscar botões: "Fechar", "Ok", "Confirmar", "Sim", "Cancelar" ## Referências Consultar `references/protheus-webapp-patterns.md` para padrões de interface, formatação, módulos e tempos de espera.