KI-Agenten können einen Playtest in Roblox Studio ausführen und Client-UI, Interaktionen und Serverstatus in einem Testdatensatz prüfen.

Playtest — Status und Testverlauf

Überblick

Verwenden Sie für normale Laufzeitprüfungen eine strukturierte Test Session über manage_studio. Die KI führt ein JSON-kompatibles scenario der Reihe nach aus und speichert target, erwartete und beobachtete Werte, Dauer und Fehler jedes steps. Testcode wird nicht als Script injiziert.

Die Playtest-Seite im Dashboard trennt die Bereiche Test Values und Automated Test Results. Automated Test Results zeigt gespeicherte Ergebnisse; der Bereich steuert keinen aktiven Test und berechnet dessen Ergebnis nicht neu.

Testwerte beobachten und ändern

Im Tab Test Values können Sie echte Studio-Werte in wiederverwendbaren Testprofilen registrieren, aktuelle Werte beobachten und Eingaben anwenden, während Play oder Run aktiv ist.

Playtest Test Values — aktive Studio-Werte beobachten und ändern

Wählen Sie unter Add value die Option Studio selection, um die aktuelle Explorer-Auswahl zu lesen und deren Attributes, Value oder unterstützte properties ohne zusätzlichen Testcode zu registrieren. Verwenden Sie einen registrierten Test Adapter für internen Zustand, der nicht direkt ausgewählt werden kann.

Nach dem Start von Play oder Run zeigt Observed values schreibgeschützte aktuelle Werte. Unter Change values können Sie eine Eingabe manuell oder automatisch beim Bestätigen anwenden. Eingaben bleiben von gespeicherten Standardwerten getrennt. Aktivieren Sie Apply saved defaults when Play starts, um die gespeicherten Standardwerte des Profils beim Start der nächsten Play-Session anzuwenden.

Standard-Prüfmethode

Ohne expliziten mode startet die session im Play-Modus (F5).
v1 unterstützt einen client und sequenzielle steps.
Verwenden Sie Play für UI, Eingaben, LocalScript, PlayerGui, LocalPlayer oder Spielerverhalten.
Verwenden Sie Run (F8) nur für server-, world- oder physics-Prüfungen ohne client-Beobachtung.
Eine session kann client UI, interaction und server-Ergebnisse getrennt prüfen.

"Prüfe im Play-Modus, ob die Shop-UI erscheint, klicke den Kauf-Button
mit einer echten Eingabe und prüfe danach das Kaufergebnis auf dem Server."

Die KI startet die session mit test_session_start und liest Fortschritt sowie step evidence mit test_session_status. Mit test_session_stop wird eine laufende session abgebrochen.

UI und Eingaben prüfen

wait_for_gui wartet auf die Ziel-UI.
snapshot_gui speichert Namen, classes, Sichtbarkeit, Position, Größe, ZIndex und Textzusammenfassungen.
input_click sendet VirtualInput an einen Button innerhalb des viewports.
Eingabeübertragung und die Beobachtung von GuiButton.Activated werden getrennt gespeichert.
Ein separater server step kann die resultierende Änderung des Spielstatus prüfen.

Pixel-Screenshots des viewports im Play-Modus werden in der strukturierten session v1 nicht unterstützt. Verwenden Sie semantic UI snapshots und interaction evidence. manage_camera.screenshot funktioniert nur im Edit-Modus.

Ergebnisse im Dashboard lesen

Test History zeigt strukturierte sessions und vorhandene Raw-Luau-Datensätze.

Feld	Beschreibung
Ausführungsart	`Structured` oder `Raw Luau`
Status	`passed`, `failed`, `timed_out`, `cancelled` oder `insufficient_evidence`
Mode	Play oder Run
Duration	Gesamtdauer des Tests
Evidence-Zusammenfassung	Anzahl der server/client agents und wichtigster Fehler oder Einschränkung

Der strukturierte report zeigt Gesamtergebnis, Server-, Client-UI-, Interaction- und Visual-dimensions, expected/observed/evidence/error pro step, Agent-capabilities und gespeicherte artifacts.

Das Gesamtergebnis ist nur passed, wenn alle erforderlichen Nachweise erfolgreich sind. Ein erfolgreiches Serverergebnis mit fehlender erforderlicher Client-UI oder Interaction wird als insufficient_evidence gespeichert. Eine fehlgeschlagene optionale Beobachtung bleibt sichtbar, macht erfolgreiche Pflichtprüfungen aber nicht zu einem Fehler.

Playtest manuell steuern

Action	Beschreibung
`play_start`	Startet Play (F5) oder Run (F8)
`play_stop`	Beendet den aktuellen Playtest
`play_pause`	Pausiert einen laufenden Playtest
`play_resume`	Setzt einen pausierten Playtest fort
`play_status`	Liest `edit`, `running` oder `paused` und die zulässigen actions

Actions für strukturierte Sessions

Action	Beschreibung	Wichtige Parameter
`test_session_start`	Validiert das scenario und startet eine background session	`scenario`, `idempotencyKey`, Studio selector
`test_session_status`	Liest Status und eine begrenzte Seite step evidence	`sessionId`, `stepCursor`, `stepLimit`
`test_session_stop`	Fordert Abbruch und teardown an	`sessionId`

test_session_status liefert standardmäßig 20 und höchstens 50 steps. Verwenden Sie den opaque stepCursor aus der Antwort für die nächste Seite.

Raw-Luau-Diagnose

run_test bleibt verfügbar, ist aber nicht die Standardwahl für normale Prüfungen. Wählen Sie es ausdrücklich für erweiterte Diagnosen mit raw script, etwa eine projektspezifische Luau assertion.

run_test injiziert das script in ServerScriptService.__MCP_TestRunner, sammelt log signals und bereinigt Playtest und temporäres script.

Gespeicherte Ergebnisse

Ergebnisse werden für den gewählten Place unter {projectRoot}/weppy-project-sync/place_XXXXX/tests/YYYYMMDD-HHmmss/ gespeichert.

test-result.json   # Kanonisches Gesamtergebnis und step evidence
test-report.md     # Lesbare Zusammenfassung
test-log.txt       # Logs mit server/client origin
test-context.json  # Ausführungskontext und replay metadata

Vorhandene Raw-Luau-Datensätze bleiben im Markdown- und Log-Format lesbar und werden nicht automatisch konvertiert.

Multi-Place-Prüfung

Prüfen Sie bei mehreren Places zuerst Studio ID und Place-Name auf der Connection-Seite. Die session fixiert das Studio target beim Start und wechselt während der Ausführung nicht zu einem anderen Place.

Fehler untersuchen

Wählen Sie den fehlgeschlagenen report und prüfen Sie zuerst Gesamtgrund und failed step. Vergleichen Sie expected, observed, error und evidence dimension, um fehlende UI, nicht übertragene Eingaben, server assertion, timeout oder nicht verfügbare capability zu unterscheiden.