Automated Script Generation System for Game Testing

The author’s automation testing team faced a heavy workload in script writing and therefore designed an automatic script generation system that enables functional QA members, even those without coding experience, to contribute to script development.

The system works by manually executing a test case once, recording all mouse and keyboard operations, and automatically generating a script that can replay those actions while verifying that the game’s internal states match those recorded during the manual run.

Compared with existing record‑and‑playback tools, the new system solves two major problems: fixed‑interval execution and lack of result verification. It does so by using a state‑machine and client‑state detection mechanism to ensure actions only proceed when the required UI or game conditions are satisfied.

System Architecture

The framework consists of two parts: script recording and script playback. During recording, the system captures user input events, GM commands, and the client’s UI state (including mouse/keyboard events, UI visibility, player coordinates, level, money, etc.). During playback, the recorded events are replayed while continuously checking the client state until it matches the recorded values.

For each input event, the system registers a tick loop that repeatedly calls a generated function f (or c after patching) to compare the current client state with the previously recorded state, advancing to the next step only when the comparison succeeds.

Input Event Recording

Mouse scroll and keyboard input events are merged to improve efficiency: consecutive scrolls are combined into a single scroll with an accumulated offset, and consecutive keyboard inputs are merged, with the final UI element values (e.g., scroll bar percentage or text box content) recorded as the success criteria.

GM Command Recording

GM commands, which are sent to the server, are captured by wrapping them in functions on the server side, recording the player‑id substitution, and then replaying them on the client by sending the function name back, executing it via loadstring , and verifying the resulting client state.

Defects and Improvement Directions

The current system has several limitations: it only records a single client, requires high consistency between recording and execution environments, struggles with non‑deterministic actions, and generates scripts that are hard to read. Potential improvements include multi‑client support, manual script post‑processing, IDE integration for visualizing state changes, and leveraging AI‑driven testing to handle highly random scenarios.

Conclusion

The prototype demonstrates clear benefits for deterministic test cases (e.g., skill upgrades, UI value checks) while acknowledging that it cannot fully replace traditional scripting for complex, randomised gameplay.