Automated Test Case Script Writing and Framework Applications in Game Development

Automated testing simulates manual test steps by executing scripts written in a programming language, covering unit, functional, load, and performance tests. After introducing the automation framework, the article discusses what makes a test case "good" (stable results, clear structure) versus "bad" (unstable, unreliable outcomes).

When choosing a scripting language for the framework, the team prefers Lua because it is a lightweight scripting language that can be updated dynamically, has a lower learning curve than C#, and minimizes intrusion into the product code. Other languages such as C#, Java, Objective‑C, and C++ are mentioned but are less suitable for test scripts.

The article presents a state‑machine approach to model test steps, defining states (Start, Status1, Status2, End) and transitions based on conditions like the presence of a bag button or whether the bag panel is open. A Lua example illustrates this logic:

local ProcessStatus = {
  Start = 0,
  Status1 = 1,
  Status2 = 2,
  End = 3,
}
local Status = ProcessStatus.Start
if Status == ProcessStatus.Start then
  if condition1 then -- bag button exists
    DoAction1()      -- click bag
    Status = ProcessStatus.Status1
  else               -- bag button missing
    DoAction2()      -- report error
    Status = ProcessStatus.End
  end
  return
end
if Status == ProcessStatus.Status1 then
  if condition3 then -- bag panel opened
    DoAction3()      -- check contents
    Status = ProcessStatus.Status2
  else
    Status = ProcessStatus.Start
  end
  return
end
if Status == ProcessStatus.Status2 then
  if condition5 then -- item present
    DoAction5()      -- output true
    Status = ProcessStatus.End
  else
    DoAction6()      -- output false
    Status = ProcessStatus.End
  end
  return
end

The article notes that the return statements prevent further code execution within the same call, and discusses strategies such as periodic timer‑driven re‑invocation to achieve repeated execution without blocking the game’s main thread.

Timer functions provided by the engine (e.g., RegisterTickWithDuration and RegisterTick) allow the script to run at fixed intervals (minimum 10 ms). An example shows a loop that attempts the test up to 20 times, unregistering the timer on success or timeout:

local Status = ProcessStatus.Start
local tick
local trytimes = 0
function run()
  trytimes = trytimes + 1
  if trytimes < 20 then
    if Status == ProcessStatus.Start then
      if condition1 then
        DoAction1()
        Status = ProcessStatus.Status1
      else
        DoAction2()
        Status = ProcessStatus.End
      end
      return
    end
    -- other state handling omitted for brevity
    if Status == ProcessStatus.End then
      UnRegisterTick(tick)
      tick = nil
    end
  else
    UnRegisterTick(tick)
    tick = nil
  end
end
tick = RegisterTick(run, 1000)

Beyond traditional script‑based tests, the article explores AI‑driven testing using reinforcement learning. Test cases can send the client’s state (UI, nearby NPCs, tasks) to an AI server, which returns the next action. Two communication models are described: server‑mediated (game server forwards state to AI) and direct client‑AI connection. AI‑generated scripts are especially useful for repetitive task‑type tests such as main‑line quests.

Additional applications of the automation framework include version‑checking (verifying that configuration tables match in‑memory data), performance testing (measuring server latency for skill execution across thousands of simulated players), and other custom checks like image‑based validation or rapid UI interactions.

In summary, automated testing improves efficiency and product quality, but full automation requires careful script design, state verification, and ongoing maintenance to keep pace with evolving game features.