unity-game-qa-performance

Unity testing and performance

Evidence takes precedence over subjective conclusions. When device tiers, frame rate, memory, GC, Draw Call, loading, or build size limits have not been approved by the user, only report measured data and decision gaps.

Input and decisions

Read the Work Item, acceptance criteria, related implementation, tests, project configuration, GDD/TDD, current candidate build, and created numeric, asset, audio, and release documents. When there are substantive trade-offs regarding performance budgets, acceptance thresholds, severity, risk exemptions, or release, hand them to $unity-game-grilling; when thresholds are undefined, only report measured results and do not define PASS on your own.

Execution and handoff

Use for tests, builds, Editor/Player logs, and Profiler entry points unity:unity-cli; route Web, audio, TMP, and specific rendering issues respectively to unity:optimize-web、unity:optimize-audio、unity:optimize-text-mesh-pro and the applicable URP specialized Skill. This role is responsible for the test matrix, evidence authenticity, budget determination, and independent release, and does not duplicate specialized tuning tutorials.

1. In the QA plan, predefine EditMode, PlayMode, scene main paths, module boundaries, and user-approved target platforms. Device cases and tiers can only be planned in advance; before G2 PASS it is prohibited to install or launch any Standalone/Player, real device, or equivalent device, and it is also prohibited to collect device visual, input, lifecycle, performance, or stability results.
2. Run tests according to unity:unity-cli current rules and wait for the task's terminal state; record version, number of cases, failure details, and raw logs.
3. Before G2, only perform Editor Profiler trends, static budgets, asset statistics, and build log checks, and do not produce target device performance PASS。G2 PASS afterward, at G3, collect frame time, CPU/GPU, memory, GC, Draw Call, textures, loading, and build size according to the approved platform toolchain and candidate artifacts.
4. Defect records include version, scene, device, reproduction steps, expected/actual, evidence, P0-P3, owner, and regression status.
5. The 2D/UI small loop only covers representative aspect ratios within the approved orientation: landscape does not need to verify portrait, and portrait does not need to verify landscape; dual-orientation projects cover both orientations separately and verify switching. Single-orientation covers the reference, narrower, and wider aspect ratios for that orientation, representative safe areas, and continuous resize trajectories, and does not require cross-orientation rotation; desktop widescreen is covered only within the approved scope. For each case, actually measure Screen/Game View/backbuffer or RenderTexture, Camera pixelRect/projection, CanvasScaler or PanelSettings,Screen.safeArea, input hit testing, key UI rectangles, state, language, stable frames, and screenshots; the mere existence of components, a successful build, a single screenshot, or static configuration cannot prove responsive passing. When real measurements are missing, mark NOT_RUN or unverified。
6. For $unity-game-3d-modeling deliverables, independently check source version, topology/normals/tangents, scale axes, material slots, LOD, skinning/bones/BlendShape, Collider, attachment points, Prefab references, and architecture budget; the model production agent's self-check cannot replace QA.
7. For $unity-game-3d-texturing deliverables, independently check UV density/overlap/Padding, bake rays and seams, PBR channels/color space/normal direction, URP Shader/Importer/Material mapping, Mip/Streaming, texture memory, and authorization evidence.
8. During R&D, 3D acceptance uses the Unity Editor to cover neutral lighting, grazing light, front and back sides, near and far views, LOD switching, animation deformation, and target scene lighting; platform on-device turntable, device performance, and stability are approved only in G3 after G2 PASS .
9. Procedural text is verified for real glyphs, font fallback, baseline, en、zh-CN、ja、ru、es strategy, and container adaptation separately forsingle-line/wrap , and no language may be truncated. Scene evidence covers only its own resident HUD; modal, popup, drawer, and toast must use independent DISPLAY_LAYER candidates with an open → interact → close → restore trajectory, and host scene screenshots cannot substitute for this.
10. G2 generates a unique modules.acceptance-complete PASS report for each approved module and a unique platforms.adaptation-complete PASS report for each approved platform. Only when that G2 result is valid may G3 freeze a candidate primary artifact for each platform and execute the Cartesian product of "platform device tier × all approved scenarios"; each test case is bound to the artifact hash of its platform. When there is no complete module, platform, device matrix, or real-device evidence, use NOT_RUN or BLOCKED, and must not report a pass.

Developer self-testing may serve as input but cannot replace independent QA approval.