【工具链】自动化冒烟回归：登录到结算的脚本化全流程测试

实战应用：用在哪里

每次热更后靠人工点一遍主流程（登录、进场景、打怪、结算、退出），耗时且容易漏。自动化冒烟回归用脚本模拟完整玩家流程，一次编写、每次版本自动执行。适用于：热更前的主流程验证、新服开区前的全功能巡检、引擎升级后的兼容性确认。

冒烟脚本的骨架

冒烟不是测所有功能，只测"坏了会出大事"的主干：登录 → 进场景 → 移动与攻击 → 背包增删 → 传送 → 结算退出。每步产出可断言的结果：

local steps = {
    { name = "登录",     fn = function() return login("test01", "pwd") end },
    { name = "进场景",   fn = function() return enterMap(3) and getPos().map == 3 end },
    { name = "攻击结算", fn = function()
        attackNearest()
        wait(2)
        return killCount() > 0 end },
    { name = "背包写入", fn = function()
        addItem(1001, 1)
        return hasItem(1001) end },
}

for _, s in ipairs(steps) do
    local ok, res = pcall(s.fn)
    print(s.name, ok and res ~= false and "PASS" or "FAIL")
end

失败即停止并输出失败步骤名，接入 CI 后每次提交自动执行，热更引入的破坏在发布前暴露。

稳定性三原则

假环境隔离：冒烟连测试服，账号专用且数据可重置，每次运行前重置到已知状态。断言带容差：数值类断言用区间（掉落在 8~12 之间）而非精确相等，减少无效失败。失败必留证据：失败时保存当前变量快照与最近 50 行日志，人工复查不必重新复现。

实测收益

某 996 项目把 12 步冒烟接入流水线后，前三个月拦截了 7 次会破坏主流程的提交，其中 3 次是开发者自认为"只是改了个文案"的变更。冒烟套件的编写成本约两天，之后每次版本发布前的人工回归时间从 2 小时缩到 15 分钟——只验证自动化覆盖之外的部分。冒烟回归是热更体系（版本管理篇）的安全下限，两者配套才算完整的发布保障。

冒烟用例的维护节奏：每季度淘汰一次过时用例（对应功能已下线），新增主干功能时同步补用例。用例总量控制在 30 到 50 个之间，少于 20 个覆盖不足，多于 80 个则运行时间开始侵蚀开发体验。失败用例的修复优先级高于新功能开发，这是团队要达成的共识。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。