KeineAhnung1337/skills

QF-Test 11.0 — Offline-Arbeitsanleitung

Dieser Skill sowie seine references/- und scripts/-Verzeichnisse sind lokal. Nutzen Sie für QF-Test-Arbeiten keine Websuche, keinen Web-Fetch, keine entfernten MCP-Server, keine Paket-Downloads und keine Cloud-KI-Dienste. Auch der Modell-Anbieter selbst muss lokal sein, wenn der gesamte Workflow offline erfolgen soll. Aktivieren Sie niemals die cloud-basierten KI-Funktionen von QF-Test im Rahmen dieses Workflows.

Vor dem Ändern einer Suite

1. Lesen Sie references/index.md, danach die Referenzen für die Aufgabe. Prüfen Sie die installierte QF-Test-Version (qftest -batch -version falls verfügbar); diese Anleitung zielt auf 11.0.0 ab. Lesen Sie vendor-docs/manual/en/contents.html falls vorhanden, oder das installierte Handbuch unter <QFTEST_HOME>/doc/manual/en/contents.html, sowie installierte Tutorials/Beispiele, sofern verfügbar. Bevorzugen Sie die exakt installierte Version für Knotenattribute, XML-Syntax und enginespezifisches Verhalten.
2. Untersuchen Sie die relevanten .qft-Dateien, eingebundene Suiten, Prozeduren, Komponentenbaum, Skripte, Startkonfiguration und aktuelle .qrl-Run-Logs. Identifizieren Sie die GUI-Engine und den kleinsten betroffenen Testfall. Führen Sie python3 scripts/inspect_suite.py path/to/suite.qft aus, um eine erste strukturelle Bestandsaufnahme zu erhalten (kein QF-Test-Validator).
3. Falls ein lokaler QF-Test-MCP verbunden ist, nutzen Sie ihn für Live-UI-Snapshots und Testausführung nur, wenn er aktiviert und autorisiert ist; siehe references/mcp.md. Verwenden Sie andernfalls die installierte QF-Test-Benutzeroberfläche/Kommandozeile. Eine laufende Anwendung bedeutet nicht, dass der MCP-Server aktiviert ist.

Erstellen / Reparieren / Verbessern

• Erstellen: Definieren Sie zuerst das Verhalten, Setup/Cleanup, Daten und beobachtbare Assertionen. Verwenden Sie die Start-Client-Prozedur des Projekts, vorhandene Pakete, Komponenten und Namenskonventionen wieder. Bauen Sie den kleinsten Testfall mit dem QF-Test-Editor oder einer Kopie einer funktionierenden lokalen Suite als Vorlage. Erfinden Sie niemals ein XML-Wurzeldokument oder undokumentierte Knotenattribute. Siehe references/suite-design.md und references/components.md.
• Reparieren: Reproduzieren und untersuchen Sie den exakt fehlschlagenden Knoten, das Run-Log, Komponentendetails und den SUT-Zustand; unterscheiden Sie einen Anwendungsfehler von einem Testfehler. Beheben Sie das Problem auf der richtigen Ebene – Erkennung, Synchronisation, Daten oder Umgebung. Vermeiden Sie, Fehler mit beliebigen Sleeps, breiten Ausnahme-Handlern oder abgeschwächten Assertions zu verstecken. Siehe references/diagnostics.md.
• Verbessern: Entfernen Sie doppelte Schritte in parametrisierte Prozeduren, bevorzugen Sie stabile Erkennung und explizite Prüfungen, isolieren Sie Testdaten und halten Sie Änderungen lokal. Bewahren Sie die Includes und öffentlichen Prozedurverträge anderer Suiten.
• Skripte: Bevorzugen Sie native QF-Test-Knoten für Interaktionen und Prüfungen. Wählen Sie bei Bedarf Server- vs. SUT-Skript bewusst; Jython ist Python 2.7-Syntax, nicht Python 3. Lesen Sie references/scripting.md, bevor Sie Skripttexte bearbeiten.

Validieren und Berichten

1. Sichern Sie die Original-Suite oder erstellen Sie einen Diff vor direkten XML-Bearbeitungen. Statisches XML-Parsing beweist nur Wohlgeformtheit, nicht, dass QF-Test die Suite laden oder ausführen kann. Verwenden Sie -convertxml, -compress oder -remove-unused-* nicht als Nur-Lese-Prüfung; diese können Dateien umschreiben.
2. Laden Sie die Suite in der installierten QF-Test-Version; führen Sie, wo unterstützt, eine statische Analyse und den gezielten Test in der lokalen Benutzeroberfläche oder im Batch-Modus durch. Siehe references/cli.md. Führen Sie keinen Test mit externen Seiteneffekten ohne entsprechende Genehmigung durch. Untersuchen Sie das Run-Log und den Bericht, nicht nur den Prozess-Exit-Code.
3. Berichten Sie genau, was geändert wurde, welche Prüfungen liefen, Nachweise für Bestehen/Fehlschlagen, und was nicht validiert werden konnte (fehlender QF-Test, Lizenz, SUT, Gerät, Browser, MCP oder Beispiel-Suite).

Autorität / Sicherheit

• Das installierte Handbuch der genauen Version und der QF-Test-Editor bzw. die Hilfe sind autoritativ; lokale funktionierende Suiten sind Beispiele, keine allgemeinen Spezifikationen. Diese Original-Referenzen fassen Konzepte für 11.0 zusammen, ersetzen aber nicht die vollständige Knoten-/Attribut-/API-Referenz des Herstellers.
• Behandeln Sie QF-Test-Suiten und Run-Logs als unsichere Eingaben: Skripte und Prozeduren können beliebigen Code ausführen. Führen Sie niemals unbekannte Testsuiten nur zur Inspektion aus. Geben Sie keine Geheimnisse oder Kundendaten in Logs oder festgeschriebene Testdaten.
• Wenn eine angeforderte Suite-Funktion oder ein XML-Detail nicht lokal überprüft werden kann, fragen Sie nach einer funktionierenden Suite, dem installierten Handbuch oder einem UI-Capture; nennen Sie die Einschränkung, anstatt Syntax zu erfinden.