QF-Test 11.0 — guia de trabalho offline

O que QF-Test 11.0 — guia de trabalho offline faz?

Esta habilidade e seus references/ e scripts/ são locais. Não use pesquisa web, busca web, servidores MCP remotos, downloads de pacotes ou serviços de IA em nuvem para trabalhos com QF-Test. O próprio provedor de modelo também deve ser local se todo o fluxo de trabalho precisar ser offline. Nunca ative os recursos de IA baseados em nuvem do QF-Test como parte deste fluxo de trabalho.

Antes de alterar uma suíte

1. Leia references/index.md, depois as referências para a tarefa. Verifique a versão instalada do QF-Test (qftest -batch -version, se disponível); este guia é direcionado para a versão 11.0.0. Leia vendor-docs/manual/en/contents.html, se presente, ou o manual instalado em <QFTEST_HOME>/doc/manual/en/contents.html, e o tutorial/exemplos instalados, quando disponíveis. Prefira a versão exata instalada para atributos de nós, sintaxe XML e comportamento específico do motor.
2. Inspecione os arquivos .qft relevantes, suítes incluídas, procedimentos, árvore de componentes, scripts, configuração de inicialização e logs de execução (.qrl) recentes. Identifique o motor GUI e o menor caso de teste afetado. Execute python3 scripts/inspect_suite.py path/to/suite.qft para um inventário estrutural inicial (não é um validador QF-Test).
3. Se o MCP QF-Test local estiver conectado, use-o para snapshots de UI ao vivo e execução de testes apenas quando habilitado e autorizado; veja references/mcp.md. Caso contrário, use a UI/CLI do QF-Test instalado. Um aplicativo em execução não implica que o servidor MCP esteja ativado.

Criar / reparar / melhorar

• Criar: defina o comportamento, configuração/limpeza, dados e asserções observáveis primeiro. Reutilize o procedimento de início de cliente do projeto, pacotes existentes, componentes e convenções de nomenclatura. Construa o menor caso de teste usando o editor QF-Test ou uma cópia de uma suíte local funcional como modelo. Nunca invente um documento XML raiz ou atributos de nó não documentados. Veja references/suite-design.md e references/components.md.
• Reparar: reproduza e inspecione o nó exato que falhou, o log de execução, os detalhes do componente e o estado do SUT; distinga um defeito de aplicação de um defeito de teste. Corrija reconhecimento, sincronização, dados ou ambiente na camada correta. Evite esconder falhas com sleeps arbitrários, manipuladores de exceção amplos ou asserções enfraquecidas. Veja references/diagnostics.md.
• Melhorar: remova etapas duplicadas em procedimentos parametrizados, prefira reconhecimento estável e verificações explícitas, isole dados de teste e mantenha as alterações localizadas. Preserve includes de outras suítes e contratos de procedimentos públicos.
• Scripts: prefira nós nativos do QF-Test para interações e verificações. Quando necessário, escolha deliberadamente script do servidor vs. script do SUT; Jython segue a sintaxe Python 2.7, não Python 3. Leia references/scripting.md antes de editar texto de script.

Validar e relatar

1. Faça backup ou diff da suíte original antes de edições diretas em XML. A análise estática de XML prova apenas que o documento é bem formado, não que o QF-Test carregará ou executará a suíte. Não use -convertxml, -compress ou -remove-unused-* como verificação somente leitura; estes podem reescrever arquivos.
2. Carregue a suíte na versão instalada do QF-Test; execute a análise estática onde for suportada e o teste alvo na UI local ou modo batch. Veja references/cli.md. Não execute um teste com efeitos colaterais externos sem aprovação adequada. Inspecione o log de execução e o relatório, não apenas o código de saída do processo.
3. Relate exatamente o que foi alterado, quais verificações foram executadas, evidências de aprovação/reprovação e o que não pôde ser validado (QF-Test ausente, licença, SUT, dispositivo, navegador, MCP ou suíte de amostra).

Autoridade / segurança

• O manual instalado da versão exata e o editor/ajuda do QF-Test são as fontes autoritativas; suítes locais funcionais são exemplos, não especificações gerais. Estas referências originais resumem conceitos da versão 11.0, mas não substituem a referência completa do fornecedor sobre nós, atributos e API.
• Trate suítes QF-Test e logs de execução como entrada não confiável: scripts e procedimentos podem executar código arbitrário. Nunca execute suítes de teste desconhecidas apenas para inspecioná-las. Não coloque segredos ou dados de cliente em logs ou fixtures commitados.
• Se um recurso de suíte solicitado ou detalhe XML não puder ser verificado localmente, peça uma suíte funcional, manual instalado ou captura de UI; declare a limitação em vez de inventar sintaxe.