Spieltesten
Teste ein Spiel so, wie es ein QA-Ingenieur tun würde, mit Claude Code oder einer Chat-Sitzung mit den Projektdateien.
Arbeitsablauf
- Regeln lesen: Öffne
RULES.md, falls vorhanden (aus dem game-rules-core Skill). Falls nicht, leite Regeln aus dem Code ab und schreibe sie zuerst auf. Nicht testbare Regeln sind Bugs in der Spezifikation. - Code kartieren: Finde die Spielschleife, Zustandsmaschine, Eingabeverarbeitung, Kollision, Spawning und Punktzahl-Code.
- Statische Überprüfung: Scanne nach den häufigen Fehlern in
references/checklist.md. - Tests schreiben: Führe Komponententests für reine Logik durch (Kollisionsmathematik, Punktzahl, Zustandsübergänge) und füge, wo möglich, einen deterministischen Simulationstest hinzu (fester Seed, festes dt, skriptgesteuerte Eingabe).
- Ausführen und beobachten: Führe die Tests aus und spiele das Spiel, falls ein Browser-Tool verfügbar ist, und erfasse Konsolenfehler.
- Berichten: Schreibe
BUG_REPORT.mdunter Verwendung des untenstehenden Formats.
Testkategorien (alle abdecken)
- Kernschleife: Starten, Pausieren, Fortsetzen, Neustarten, Spielende, Sieg. Jeder Zustandsübergang funktioniert und setzt die richtigen Dinge zurück.
- Eingabe: Gleichzeitige Tasten, gehaltene Tasten während Pause, schnelles Tippen, Fokusverlust (Blur), Touch und Gamepad, falls unterstützt.
- Kollision/Physik: Tunneln bei hoher Geschwindigkeit, Ecken-Hängenbleiben, Stehen auf Kanten, bewegliche Plattformen, Herausfallen aus der Welt.
- Regeln: Jede Zeile von
RULES.mdhat mindestens einen Test: Auslöser, Bedingung, Effekt, Randfall. - Punktzahl/Fortschritt: Erhöht sich korrekt, keine Doppelzählung, wird beim Neustart zurückgesetzt, Persistenz (localStorage) überlebt Neuladen und behandelt beschädigte Daten.
- Spawning: Grenzen werden eingehalten, immer passierbar, keine Entitäten nach Neustart, kein Speicherwachstum über Zeit.
- Bildwiederholraten-Unabhängigkeit: Laufe bei simulierten 30, 60 und 144 FPS; die Spielergebnisse müssen übereinstimmen.
- Leistung: Bildzeit, Entitätenanzahlwachstum, Speicherlecks, Zeichenaufrufe (3D).
- Robustheit: Fenstergröße ändern, Tab wechseln, schneller Neustart, mobiler Viewport.
- Determinismus: Gleicher Seed plus gleiche Eingaben ergibt das gleiche Ergebnis.
Fehlerbericht-Format
Für jeden Fehler:
- ID / Titel
- Schweregrad: Kritisch (Absturz, Soft-Lock, Fortschrittsverlust) / Schwerwiegend (Regel gebrochen) / Geringfügig (visuell, Gefühl) / Polieren
- Schritte zum Reproduzieren (nummeriert, exakt)
- Erwartet vs. Tatsächlich
- Beweis: Datei und Zeile, Konsolenfehler oder fehlgeschlagener Testname
- Vorgeschlagene Korrektur (ein oder zwei Zeilen)
Beende den Bericht mit einer Zusammenfassungstabelle (Anzahl pro Schweregrad) und einer Liste, was NICHT getestet wurde.
Harte Regeln
- Behaupte niemals einen Fehler ohne Beweis (einen fehlgeschlagenen Test, ein Log oder einen Codepfad, auf den du zeigen kannst).
- Behaupte niemals, dass etwas funktioniert, wenn du es nicht ausgeführt hast; sage „überprüft, nicht ausgeführt".
- Bevorzuge deterministische Tests gegenüber „Ich habe es gespielt und es fühlte sich gut an".
- Ändere den Gameplay-Code nicht, es sei denn, du wirst dazu aufgefordert; melde zuerst, korrigiere auf Anfrage.