AI가 Roblox Studio에서 Playtest를 실행하고, 클라이언트 UI와 입력 결과, 서버 상태를 한 테스트 기록으로 검증합니다.
개요
일반적인 플레이테스트 검증에는 manage_studio의 구조화된 Test Session을 사용합니다. AI는 JSON-compatible scenario를 순서대로 실행하고, 각 단계의 대상과 기대값, 관찰값, 소요 시간, 오류를 기록합니다. 테스트 코드를 Script로 주입하지 않습니다.
Dashboard의 Playtest 페이지는 Test Values와 Automated Test Results로 나뉩니다. Automated Test Results는 저장된 결과를 읽는 viewer이며, 진행 중인 테스트를 제어하거나 결과를 다시 판정하지 않습니다.
테스트값 관찰과 변경
Test Values 탭에서는 테스트 프로필별로 실제 Studio 값을 등록하고, Play 또는 Run 중 현재값을 관찰하거나 입력값을 적용할 수 있습니다.
Add value에서 Explorer의 현재 선택 항목을 읽는 Studio selection을 사용하면 테스트 코드를 추가하지 않고 Attribute, Value, 지원 property를 등록할 수 있습니다. 직접 선택할 수 없는 내부 상태는 프로젝트에 등록된 Test Adapter로 연결합니다.
Play 또는 Run을 시작하면 Observed values에 읽기 전용 현재값이 표시됩니다. Change values에서는 입력값을 수동으로 적용하거나, 입력을 확정할 때 자동으로 적용할 수 있습니다. 입력값과 저장 기본값은 서로 분리되며, Apply saved defaults when Play starts를 켜면 다음 Play 시작 시 프로필의 저장 기본값을 적용합니다.
기본 검증 방식
구조화된 Test Session은 다음 원칙으로 실행됩니다.
- 모드를 지정하지 않으면 Play 모드(F5)로 시작합니다.
- v1은 client 한 명과 순차 step을 지원합니다.
- UI, 입력,
LocalScript,PlayerGui,LocalPlayer가 포함된 검증에는 Play 모드를 사용합니다. - Run 모드(F8)는 client 관찰이 필요 없는 server, world, physics 검증에만 사용합니다.
- 같은 session 안에서 client UI와 interaction, server 결과를 각각 검증할 수 있습니다.
예를 들어 다음처럼 요청할 수 있습니다.
"Play 모드에서 상점 UI가 나타나는지 확인하고,
구매 버튼을 실제 입력으로 누른 뒤 서버의 구매 결과까지 검증해줘"AI는 test_session_start로 session을 시작하고, test_session_status로 진행 상황과 step evidence를 확인합니다. 실행 중인 session을 취소할 때는 test_session_stop을 사용합니다.
UI와 입력 검증
Client Test Agent는 실행 중인 게임의 PlayerGui를 기준으로 UI를 확인합니다.
wait_for_gui로 대상 UI가 준비될 때까지 기다립니다.snapshot_gui로 이름, class, 표시 상태, 위치, 크기, ZIndex, text 요약을 수집합니다.input_click으로 화면 안의 버튼에 VirtualInput을 전달합니다.- 입력 전달과
GuiButton.Activated관찰을 서로 다른 evidence로 기록합니다. - 필요한 경우 별도 server step에서 실제 게임 상태 변경을 확인합니다.
Play 모드의 viewport pixel screenshot은 구조화된 session v1에서 지원하지 않습니다. UI 확인에는 semantic snapshot과 interaction evidence를 사용합니다. manage_camera.screenshot은 Edit 모드 전용입니다.
Dashboard에서 결과 읽기
Test History에는 구조화된 session과 기존 Raw Luau 기록이 함께 표시됩니다.
| 항목 | 설명 |
|---|---|
| 실행 종류 | Structured 또는 Raw Luau |
| Status | passed, failed, timed_out, cancelled, insufficient_evidence |
| Mode | Play 또는 Run |
| Duration | 전체 테스트 소요 시간 |
| Evidence 요약 | server/client agent 수와 주요 실패 또는 제한 |
구조화된 report를 선택하면 다음 내용을 확인할 수 있습니다.
- 전체 판정과 판정 이유
- Server, Client UI, Interaction, Visual dimension과 required 여부
- step별 target, action, expected, observed, evidence, error, duration
- Server/Client Agent와 semantic UI, VirtualInput capability
- structured result, Markdown report, raw log 등 저장 artifact
필수 evidence가 모두 통과해야 전체 결과가 passed가 됩니다. Server 결과가 성공해도 필수 client UI 또는 interaction evidence가 없으면 insufficient_evidence로 기록됩니다. 선택적인 observation 실패는 기록에 남지만 필수 검증이 성공한 결과를 실패로 바꾸지 않습니다.
수동 Playtest 제어
자동 검증 없이 Play/Run 상태만 제어할 때는 다음 액션을 사용합니다.
| 액션 | 설명 |
|---|---|
play_start | Play(F5) 또는 Run(F8) 모드 시작 |
play_stop | 현재 Playtest 중지 |
play_pause | 실행 중인 Playtest 일시정지 |
play_resume | 일시정지된 Playtest 재개 |
play_status | 현재 edit, running, paused 상태와 가능한 액션 확인 |
"Play 모드로 게임을 시작해줘"
"현재 Playtest 상태를 확인하고 종료해줘"구조화된 Session 액션
| 액션 | 설명 | 주요 파라미터 |
|---|---|---|
test_session_start | scenario 검증 후 background session 시작 | scenario, idempotencyKey, Studio selector |
test_session_status | 상태와 bounded step evidence 조회 | sessionId, stepCursor, stepLimit |
test_session_stop | session 취소와 teardown 요청 | sessionId |
test_session_status는 기본 20개, 최대 50개의 step evidence를 한 번에 반환합니다. 다음 페이지는 응답의 opaque stepCursor를 사용합니다.
Raw Luau 진단
run_test는 제거되지 않았지만 일반 검증의 기본 경로가 아닙니다. 프로젝트 전용 Luau assertion처럼 raw script 실행이 꼭 필요한 고급 진단에서 명시적으로 사용합니다.
"Raw Luau 방식으로 ServerScriptService 상태를 검사하고 로그를 남겨줘"run_test는 전달받은 script를 ServerScriptService.__MCP_TestRunner에 주입하고, 로그 signal을 수집한 뒤 Playtest와 임시 script를 정리합니다.
저장되는 결과
결과는 선택한 Place의 {projectRoot}/weppy-project-sync/place_XXXXX/tests/YYYYMMDD-HHmmss/ 아래에 저장됩니다.
구조화된 session:
test-result.json # 전체 판정과 step evidence의 정본
test-report.md # 사람이 읽는 요약
test-log.txt # server/client origin이 포함된 로그
test-context.json # 실행 context와 replay metadata기존 Raw Luau 기록은 기존 Markdown report와 log 형식으로 계속 읽을 수 있으며 자동으로 변환되지 않습니다.
Multi-Place 검증
여러 Place를 수정했다면 Dashboard의 Connection 페이지에서 Studio ID와 Place 이름을 확인한 뒤 대상별로 요청합니다.
"studio-1 Lobby에서 포털 버튼 표시와 클릭 결과를 Play 모드로 확인하고,
studio-2 Game에서는 도착 지점의 서버 상태를 Run 모드로 검증해줘"구조화된 session은 시작할 때 선택한 Studio target을 고정합니다. 실행 중 active Studio가 바뀌어도 다른 Place로 이동하지 않습니다.
실패 원인 확인
Dashboard에서 실패한 report를 선택하고 전체 판정 이유와 failed step을 먼저 확인합니다. expected, observed, error, evidence dimension을 함께 보면 UI 미표시, 입력 미전달, server assertion 실패, timeout, 지원되지 않는 capability를 구분할 수 있습니다.