KeineAhnung1337/skills

QF-Test 11.0 — guide de travail hors ligne

Ce skill et ses dossiers references/ et scripts/ sont locaux. N'utilisez pas de recherche web, de récupération web, de serveurs MCP distants, de téléchargements de paquets ou de services cloud AI pour le travail QF-Test. Le fournisseur de modèle lui-même doit également être local si l'ensemble du workflow doit être hors ligne. N'activez jamais les fonctionnalités AI basées sur le cloud de QF-Test dans le cadre de ce workflow.

Avant de modifier une suite

1. Lisez references/index.md, puis les références pour la tâche. Vérifiez la version installée de QF-Test (qftest -batch -version si disponible) ; ce guide cible la version 11.0.0. Lisez vendor-docs/manual/en/contents.html s'il est présent, ou le manuel installé sous <QFTEST_HOME>/doc/manual/en/contents.html, ainsi que le tutoriel/les exemples installés lorsqu'ils sont disponibles. Privilégiez la version exacte installée pour les attributs de nœuds, la syntaxe XML et le comportement spécifique au moteur.
2. Inspectez les fichiers .qft pertinents, les suites incluses, les procédures, l'arbre des composants, les scripts, la configuration de démarrage et les journaux d'exécution .qrl récents. Identifiez le moteur GUI et le plus petit cas de test affecté. Lancez python3 scripts/inspect_suite.py chemin/vers/suite.qft pour un inventaire structurel initial (pas un validateur QF-Test).
3. Si un MCP QF-Test local est connecté, utilisez-le pour les instantanés UI en direct et l'exécution de tests uniquement lorsqu'il est activé et autorisé ; voir references/mcp.md. Sinon, utilisez l'interface utilisateur/ligne de commande QF-Test installée. Une application en cours d'exécution n'implique pas que le serveur MCP est activé.

Créer / réparer / améliorer

• Créer : définissez d'abord le comportement, la configuration/nettoyage, les données et les assertions observables. Réutilisez la procédure de démarrage client du projet, les paquets existants, les composants et les conventions de nommage. Construisez le plus petit cas de test en utilisant l'éditeur QF-Test ou une copie d'une suite locale de travail comme modèle. Ne fabriquez jamais un document XML racine ou des attributs de nœud non documentés. Voir references/suite-design.md et references/components.md.
• Réparer : reproduisez et inspectez le nœud exact en échec, le journal d'exécution, les détails du composant et l'état du SUT ; distinguez un défaut d'application d'un défaut de test. Corrigez la reconnaissance, la synchronisation, les données ou l'environnement au bon niveau. Évitez de masquer les échecs avec des pauses arbitraires, des gestionnaires d'exceptions trop larges ou des assertions affaiblies. Voir references/diagnostics.md.
• Améliorer : supprimez les étapes dupliquées dans des procédures paramétrées, privilégiez une reconnaissance stable et des vérifications explicites, isolez les données de test et conservez les modifications localisées. Préservez les inclusions des autres suites et les contrats des procédures publiques.
• Scripts : privilégiez les nœuds QF-Test natifs pour les interactions et les vérifications. Lorsque c'est nécessaire, choisissez délibérément un script serveur ou SUT ; Jython utilise la syntaxe Python 2.7, pas Python 3. Lisez references/scripting.md avant de modifier le texte du script.

Valider et rapporter

1. Sauvegardez ou différez la suite originale avant les modifications XML directes. L'analyse statique XML prouve seulement la bonne formation, pas que QF-Test chargera ou exécutera la suite. N'utilisez pas -convertxml, -compress ou -remove-unused-* comme vérification en lecture seule ; ces commandes peuvent réécrire les fichiers.
2. Chargez la suite dans la version installée de QF-Test ; lancez l'analyse statique si elle est prise en charge et le test ciblé dans l'interface utilisateur locale ou en mode batch. Voir references/cli.md. N'exécutez pas un test avec des effets de bord externes sans approbation appropriée. Inspectez le journal d'exécution et le rapport, pas seulement le code de sortie du processus.
3. Rapportez exactement ce qui a été modifié, quels contrôles ont été exécutés, les preuves de réussite/échec et ce qui n'a pas pu être validé (QF-Test manquant, licence, SUT, appareil, navigateur, MCP ou suite exemple).

Autorité / sécurité

• Le manuel installé de la version exacte et l'éditeur/aide de QF-Test font autorité ; les suites locales de travail sont des exemples, pas des spécifications générales. Ces références originales résument les concepts de la version 11.0 mais ne remplacent pas la référence complète du fournisseur sur les nœuds/attributs/API.
• Considérez les suites QF-Test et les journaux d'exécution comme des entrées non fiables : les scripts et les procédures peuvent exécuter du code arbitraire. N'exécutez jamais des suites de tests inconnues simplement pour les inspecter. Ne placez pas de secrets ou de données client dans les journaux ou les fixtures validées.
• Si une fonctionnalité de suite demandée ou un détail XML ne peut pas être vérifié localement, demandez une suite de travail, un manuel installé ou une capture d'interface utilisateur ; indiquez la limitation au lieu d'inventer une syntaxe.