功能测试

1. 功能测试-QA的定义

• 核心内容：
  • 误区纠正：初级/中级甚至资浅高级测试常把游戏测试等同于"找bug"，这是不对的；QA是游戏/软件的质量监管者，而非单纯找bug的人。
  • QA职责定位：在整个游戏研发生命周期中，与其他研发部门紧密协作合作，发现所有可能影响游戏线上质量的问题；问题不只是功能问题，还包括流程问题。
  • 流程问题典型：①策划需求文档写不清，导致前后端实现逻辑不完善，测试时暴露大量界面/接口之间无调用关系或调用错误；②研发改动不走需求单、不提测，直接把代码/资源上传进游戏工程，质量无法保证；③赶工期时上游临期突增需求（如一周只够测2个功能，周五/六突然要求两天测5个），只能糊弄跑流程、抠不清细节。
  • QA是最后关卡/收尾者，必须把最后流程卡住；研发上游写代码、配策划表、传美术资源等环节的不规范，最终都由QA兜底；每个bug背后是公司几万、几十万甚至几百万损失，QA要管控、监督、反馈所有可能影响线上质量的流程与问题。
• 工具：无
• 经验/坑：
  • 提出远超正常量的大量bug会打乱测试计划、挤占研发本周本可完成的功能产出，两边耽误。
  • 测试不能只糊弄跑一遍流程，细节必须抠清，否则上线后隐藏逻辑问题会被玩家逐一发现。

2.功能测试-研发流程

• 核心内容：
  • 0到1研发主流程：制作人（游戏大脑）先有想法（做FPS/MMO/三消/跑酷等）并定题材风格（东方玄幻/欧美/通用卡通）；游戏分多个版本多阶段（半年/1年/2年周期），每版本拆成几周/几个月，先定本版本内容（如5英雄、5关卡、5怪物、5地图、20道具）。
  • 主策划+PM据制作人需求目标，把几十项内容拆成几百上千个需求单/功能单/提测单（项目管理软件），再做版本计划：何时脑暴、何时写策划案、前后端研发、联调、QA测试、真机验证、打真机包、上线。
  • 功能评审会：策划据个人经验写策划案，不100%确定与其他功能贴合、风格一致、前后端可实现，故拉前端、后端、美术、测试、运营、组长、主策划一起查缺补漏；QA用QA思维发现策划按自身需求设计、想不到玩家"反人类/反游戏"操作导致的前后端调用问题或误拉起其他功能。
  • 研发阶段：策划新增/修改配表，前端写前端代码、后端写后端代码、美术定风格与UI/UE；前后端联调期间QA编写测试用例（此时QA无别的可做），并提前搭建测试环境。
  • 测试环境必要性：研发各自在主干分支开发，QA测试一定会影响他人——例：公会创建/解散/退会入会冷却1天、英雄大招冷却5分钟，QA若在主干把配表1天改1分钟、5分钟改5秒会影响所有人；故需独立QA分支/QA服务器，前后端代码、配表、美术资源由QA自行维护、每日多次更新保证最新；执行QA可向主管/leader申请独立测试环境。
  • 提测前确认研发自检自查：各部门分开做（英雄模型、例会、技能配表/数值文字、特效）后联调成整体再提测，提测前与功能负责人确认是否自检。原因：未自检会出现错别字、技能数值错误、点击无效果、二三级页面错误、几百上千报错甚至底层C++错误；QA无法识别美术资源是否最新/正式版（外包换几十版、交付时间不确定）；程序/美术不玩游戏，对"西域风格美女"等文字理解偏差QA也难发现，只能策划自检。
  • 不自检强行测试：一个正常只产30-50bug的功能会产出500-上千bug，原本半天提50bug变成提三天，测试计划延期、研发修复也延期，双方不讨好。
  • 执行测试：按测试用例（500/1000/2000条）逐条执行，通过打勾、不通过打叉并写bug单号；未执行也要写明原因（与策划案不一致/高优先级严重bug阻塞后续）。
  • bug优先级分级：致命（一点击功能就崩溃、无法测试，最高优先级立即提）；高级（功能不好使但其他功能好使，即功能缺失）；普通（如1升2、2升3正常，3升4不好使的逻辑问题）；轻微（升级成功但未显示成功、按钮字体前两大后两小）；建议（如升级按钮字体应为游戏统一红色，现为黄色、风格不一致）。
  • bug跟踪：按优先级跟研发确认高级/普通修复时间并按时追；修不了/没思路的向上级反馈引入外力；不修的须让研发用其项目管理账号在bug单备注原因，QA回归验证确实修复后关单；延期/下版本bug按工作室流程备注并移入下版本后关单。
  • 测试报告：写清提测时间、用例编写时间、用例经内/外评审后新增/修改/删除条数、执行时长、产出bug总数及高级/普通/轻微/建议各多少；分类统计功能逻辑bug、策划配表bug、美术资源bug，指出哪些是显而易见未自检/疏忽导致；写明哪些测试方法/工具能提效、产高质量bug，发给leader汇报。
  • 封包/真机（风暴）测试：前述都在引擎内验收，手游最终须在手机验证，区分验证真机独有问题（不同手机品牌、安卓/苹果/鸿蒙版本、CPU/GPU/内存/运行内存、刘海屏、分辨率；地铁/卫生间/地下车库，4G/5G/WiFi/热点、国内外网络导致的前后端响应校验问题）；研发角度做真机联调体验（新手引导、5级背包、10级公会等此前单个体验，现串联看手感与玩家感受），重点关注真机/不同网络/硬件下前后端响应、交互、调起是否及时、按策划与用例正确反馈。
  • 项目总结/复盘：周期内各功能何时接入测试、何时完整验收、各环节执行与产出、问题及解决、用例与真机包覆盖率、遗漏点是否补进用例查缺补漏、可复用到下版本的流程/技术项、对接流程问题及预防、本版不足与下版改进；各公司流程基调不同但核心一致。
• 工具：独立QA分支/QA测试服务器、GM配表修改（缩短冷却时间）、项目管理软件流转bug
• 经验/坑：
  • 提测前必须确认研发自检自查，否则bug量暴涨拖垮双方计划。
  • bug不能提完不管，要按优先级跟踪修复时间、回归验证后关单。

3.功能测试-脑爆 需求评审会

• 核心内容：
  • 脑暴会：功能想法初期，策划（如系统策划小组）内部思想碰撞；依据市场同类玩法流行趋势、目标用户/玩家群体需求分析，产出一级/二级/三级功能想法（功能放在哪个界面、多少级开启、自动弹出还是点击进入、静态还是动态效果图、UI/UE布局、有几个二级功能、单人地图还是他人可进入公会领地等）。
  • QA应主动参加脑暴会的三点理由：①设计初期QA无多余工作（无策划案、写不了用例、无需提前搭环境），参会可提前知道功能目的/出处/想法，实时跟进策划想要的样子；②QA本身须是该类游戏资深玩家或有同类项目经验，能从资深玩家/老测试角度给策划正向反馈；③提前了解设计意图与后续可能新增的功能入口/接口/调用点，可在测试用例里提前写到、提高覆盖率，待下一版本更新时再执行。
  • 团队作用：参会提高QA认可度，QA除提bug外还能提建议；不参会容易把"非bug的建议"自我压下不提。
  • 需求评审会：脑暴后策划把想法落成策划案文档（篇幅看策划功底，三五篇到二三十篇不等）；因策划个人有技能短板（只理解/想到80%、缺20%），且每个功能都与其他功能交互（如公会升级材料跳转副本、招人请求跳转聊天系统），必须开评审会补齐想不到的点。
  • 评审会参会人：主设计策划+辅助策划、数值策划、UI/UE策划、前后端同学、美术（建模/动作/UI/地编）、QA、运营，从各职能角度评估可行性与技术壁垒；QA提前在策划案里发现问题，避免以后提bug，大家省事。
  • 参会收益：脑暴过一遍、评审再过一遍，后续写测试用例非常顺畅；提前认识开发人员，知道提bug找谁、在群里at谁、了解研发习惯（不同公司bug提给开发个人，还是提给策划负责人再分发）；评审时汇总各人研发天数得出大致研发周期，可初步制定测试计划。
  • 评审会上要及时提出GM工具需求：如调/跳时间命令（创建/加入/解散需一天）、批量加人（上限100人，用GM命令直接加到99再补两个号测101人）、强制解散公会、把公会从A地图挪到B地图等。
  • 新功能评审、老功能评审、中后期调优评审QA都要100%参加；公司中期调优若只找前后端不叫QA，必须向负责人沟通。
• 工具：GM工具（调时间、批量加人、强制解散、跨地图挪动等测试辅助命令）
• 经验/坑：
  • 功能联调/开始测试后才提GM工具需求，既耽误研发做后续功能，也耽误自己测试（等工具两三天，研发还不一定愿意做）。
  • 私下调优不通知QA、不开需求单/测试单，未经测试进入主干分支或线上会带来极大风险、产生大量bug与损失，须据理力争要求纳入评审。

4.功能测试-BUG标题

• 核心内容：
  • 提bug占游戏测试工作约90%；优秀清晰的标题让研发不点开详情就能快速精准定位bug表现（研发每天接几十上百bug，不想逐条点开看操作步骤）。
  • 标题必须展示：一级功能、二级功能、简单操作、具体bug表现。
  • 错误标题反例：①"爆破鬼才点击一技能技能按钮没有了"——没清晰定位二级功能，需研发熟悉游戏读完整句才懂；②"打开英雄功能空白一片"——没说一级/二级功能、哪个界面、哪个位置空白；③"英雄无法升级"——太简洁，没写一二级功能、哪个英雄、何因（全部无法/升级失败/材料不足）。
  • 标准格式：一级功能（英雄功能）+二级功能（升级）+简单操作（爆破鬼才一级升二级时点击英雄升级按钮）+具体bug表现（按钮点击后消失不见）。
  • 为何要写细：QA对游戏最熟（比策划还熟），可凭简单描述理解；但多数程序/美术/策划不玩自家游戏甚至不玩游戏，清晰标题是基本功；正确标题让研发凭标题直接定位到对应代码行，省掉来回追问（哪个英雄、哪个二级功能、UI/UE/特效/美术、换别的英雄是否复现）。
• 工具：项目管理软件（bug流转载体）
• 经验/坑：
  • 不要为省事简单写；标题不清会引发反复追问、增加沟通成本、降低测试效率。
  • 每条标题都详细体现基本功，内部调查/复盘时会被认可、沟通无障碍。

5.功能测试-BUG内容

• 核心内容：
  • 标题字数有限制（项目管理软件超长省略号），故标题简洁、bug内容描述要远比标题详细；标准是模拟玩家/从玩家口中了解的操作步骤与表现，让不玩游戏的研发也能看懂。
  • 操作步骤不能省、不能简陋（不能与描述重复、不能留空白），把研发当没接触游戏的小白逐步写清：进入哪个地图/界面（主城/副本/爬塔/跨服战场，不同地图会屏蔽部分功能）→用GM获得英雄和升级材料（研发新号没有该英雄）→点主城下方英雄按钮（写清位置，避免研发在无此功能的地图找不到）→左侧英雄列表→点一级爆破鬼才（明确一级升二级，避免老号满级英雄混淆）→弹出英雄详情界面→点详情界面下方升级按钮（便于临时接手、没做过该功能的B同学定位）。
  • 预计效果（正确效果，以策划案为准，不清楚可查策划案）与实际效果（bug表现，如点升级按钮后按钮丢失）。
  • 复现概率：每次都出现即100%；出现一次又不出现即偶现。
  • 版本：研发引擎从资料库拉取策划/前端/后端/美术资源，QA测试前需把SVN/Git前端资源和QA服务器后端资源都拉到最新；bug单要写清SVN/Git版本号（否则研发没更新资源会说"没有这个功能/没有这个bug"）；真机测试要写清系统版本/资源版本（登录界面角落可见，资源版本对应美术/策划/程序资源），用于从上百个真机包/底包/热更包中定位。
  • 分支与服务器：研发在master主干，QA前端也基于主干但用独立QA服务器，数据可能不同（如服务器资源1.0 vs 2.0、英雄满级上限10级 vs 调到20级）；须写清分支与服务器，否则研发随意调过资源会导致bug不复现。
  • 角色名字/ID、账号：便于研发直接复制角色数据或直接用测试账号，省去建号/搭环境（搭环境可能二三十分钟）；外网玩家反馈复现不了时，可凭角色ID查正式服务器操作日志定位（例：屠龙刀99强化100显示成功但装备消失）。
  • 平台：写清在引擎编辑器还是真机出现；真机bug必须写手机型号、内存、系统版本、网络（4G/5G/WiFi/热点、运营商、国内/国外、所处场景）。
  • 截图/视频：截图是出bug之后的表现图（非出bug前）；视频从无bug第一步按步骤录到bug出现，研发不用看文字即可看懂。
  • log日志：日常bug可不提供；偶现/难复现（如10%概率）bug需附log；两种方式——研发打点（断言，操作时输出定位所需因素）、游戏内自带log收集按钮取近两三分钟操作；建议GM平台一开始就加log收取按钮。
• 工具：GM命令、SVN/Git资源版本、log日志/打点、项目管理软件
• 经验/坑：
  • 策划案不确定是否最新要先和策划确认并打字留痕，按过期文档写出的用例无效、浪费测试时间。
  • bug内容比标题详细，操作步骤把研发当小白逐步写。

6.功能测试-BUG严重等级

• 核心内容：
  • bug按严重程度分四类（部分公司分5-6级，具体标准按公司/工作室要求）：轻度、普通、严重、致命。
  • 轻度bug：UI表现（颜色、文字、简单系统提示），对功能逻辑无影响，只影响感受体验。例：系统邮件标题未按策划案标红（内容可读、道具可领，仅难与玩家邮件区分）；标题错别字"系统油件"（可读清，仅影响阅读体验）。处理：研发/线上阶段在测试计划时间内修完即关；研发想延到下热更/大里程碑修，须在bug单备注原因。
  • 普通bug（约占90%，提1000个约900个）：功能实现不完善、对整体功能影响较大、影响体验；用例与策划案不一致、功能逻辑多了或少了都算。例：点一次英雄升级连续升两级（材料只够一次）；系统邮件标题内容正常但道具无法领取。处理：研发阶段立即沟通核对修复时间排期、修完复测（不主动问会被搁置）；线上发现立即向测试主管/leader汇报排期。
  • 严重bug：功能实现与策划完全不符，严重影响正常功能逻辑、功能效益与游戏平衡。例：英雄升级按钮丢失（功能失效、所有玩家无法升级）。处理：研发阶段立即沟通，说明已严重阻塞后续测试计划、要求立即修复以便继续；线上立即向leader汇报，leader第一时间联系制作人/主策/PM/主程序/运营，定修复复现成本、走哪个热更/里程碑、停服还是不停服修复。
  • 致命bug（最高优先级，部分公司称阻碍bug）：核心功能无法使用、游戏无法正常运行、或阻碍后续测试；带致命bug不能公测，必须修完才上线。例：充值类（充1元得2元宝箱、充1元得20钻石即翻倍，每充1元公司损失1元；充值类bug基本都是严重或致命，直接影响公司收益）；点英雄功能瞬间游戏崩溃闪退（无法运行）。处理：研发阶段立即让研发放下手头所有工作优先修，修完立即测试，不能拖不能延后；线上第一时间（无论是否在公司，用任何社交手段）报leader，由leader联系制作人/主策/PM/主程序/主运营立即修复。
• 工具：GM工具（发送系统邮件做测试）
• 经验/坑：
  • 上线通常可带3-5个普通、7-8个轻微、0-1个严重，但绝不能带致命bug。
  • 线上严重/致命bug每耽误一分钟公司损失几千到几十万，绝不能因怕领导骂而隐瞒不报。

7.功能测试-BUG定位分类

• 核心内容：
  • 一个英雄（以孙悟空为例）横跨所有部门：
    • 立绘/皮肤/技能特效=美术资源；身高宽、技能数、技能描述、伤害计算、升级/进阶/强化消耗材料及数量、每级经验=策划定；
    • 技能图标样式/位置/点击反馈、升级经验条增长=前端；
    • 伤害计算、受击反馈、距离范围计算（前端看不到）=后端。
  • 提bug不能都提给一个人：有功能/英雄负责人（设计策划）的公司，bug都提给他由他分发给前端/后端/美术/TA/运营；无此概念的公司需QA自己把bug逐个分给对应策划/前端/后端/美术，故须先搞清功能涉及哪几个策划/前端/后端/美术及各自负责模块（英雄列表、例会、皮肤、技能各负责人不同），让负责人列表或自己整理成表。
    • 策划配表问题：例①升级材料每次应+10经验却+11（非整数、与之前不同，配表手打错/多空格）；②技能三段伤害各100，第三段打出1000（配表多打一个0）或只打1点（漏打）、第三段无伤害显示乱码（误删内容只留空格，系统识别不出报错）。
    • 前端问题（眼睛能看到的表现）：例①点升级按钮后按钮丢失（前端图标/资源丢失，非配表非后端非美术——最初按钮在说明美术资源没问题，是操作后代码逻辑导致消失）；②升到100级后按钮应变"满级"却仍显示"升级"，前端没做达到100级切换文字的条件判断。
    • 后端问题（看不到的属性计算/校验）：例①充值点确认，前端扣了钻石但后端没收到请求、礼包未到账；②弱网地铁点10次确认卡住，信号恢复后10次请求一起发后端，后端若不校验身上钻石余额、只认前端请求，会发10个礼包（花10钻白嫖100钻礼包），属后端校验缺失。
    • 美术问题：该显示图片/图标处显示粉图/白图，人物/场景/植被马赛克、锯齿严重，地图副本分割线生硬黑粗线，灯光/太阳下光影光晕过大等美术资源/特效/子物体/地编问题。
• 工具：无
• 经验/坑：
  • 刚入公司先理清各功能对应负责人清单，避免bug错分/漏分。
  • 区分口径：前端=可见表现、后端=不可见属性计算与校验、策划=配表数值、美术=资源显示。

8.功能测试-测试用例（含义）

• 核心内容：
  • 为什么写用例：无论1/5/10年经验，没人敢说不借助用例、仅凭经验和脑内认知就能覆盖功能所有测试点；人的思维有误区缺陷，且无法保证每时每刻状态饱和，故需用用例辅助覆盖全面。
  • 定义：测试用例是一套有计划、有规律、有明确目的的数据集；通过拆解策划案，按功能逻辑（一/二/三级功能）、策划配表、前后端代码、美术资源，有计划拆解所有需测试内容/测试点，汇总成数据集（一般是Excel列表，按模块分组多条）；每个功能写500-2000甚至三四千条。
  • 作用：验证功能模块是否符合策划案预期，QA据此记录测试进度、覆盖度和后续维护；用例经内部评审、外部评审后第一次执行，执行后需维护（通过/未通过/未通过原因/下次执行时间），后续还有回归测试（bug修完再测一遍）与交叉测试（A测完B再测，弥补个人测试思维局限与状态疏漏）。
  • 用例一般字段：用例编号（与Excel序号并排，统计总条数）；一/二/三级功能模块（三级即可，写清本条操作位置，如公会功能→公会成员/列表/创建/解散）；前置条件（如必须具备英雄及升级材料数量，否则无法执行）；测试操作（点英雄→点升级按钮→1级升2级）；预期结果（符合策划案，升级成功）；实际结果（如一级直升十级=错误未通过）；备注（未通过写bug单号/链接，无法测试写原因；可加测试类型、测试时间，暂不执行的用例红色标注）；测试员（多人维护，记录新增/修改/删除）。
  • 编写前提：必须先熟悉功能需求；脑暴会后策划宣讲、前后端开始编译时开始写用例，宣讲前后提前找研发要策划案预读；不知道明确需求不能写用例；不可按过往游戏经验/常理认知盲写（每个游戏甚至相同功能表现都不同），一切以功能策划案为准。
  • 写用例前必须向研发索要最新功能需求文档并确认是否最新（功能改动常在内部群口头交流、未更新文档）；非最新会产出无效用例浪费测试时间；研发推诿让"看群"属偷懒，应反馈给测试leader或其上级。
  • 编写要多从QA角度思考分析发散，而非单纯把策划案逐条拆成脑图/用例；应先拆完策划前后端逻辑点/设计点（如500条），再用QA思维补测试点（补1000-2000条），结合才是完整用例。
  • 写法无统一标准，符合自身方法、部门流程、满足测试计划与标准即可；
    • 两种思路：
      • 由点到面（主城公会功能这个点→公会界面这个面→各二级功能点→权限委任/邀请/踢出等面）
      • 由面到点（英雄功能整体这个面→左列表/右礼盒/下技能/上升级各点）。
  • 正式详细全覆盖用例高标准：拿给任何部门任何人（前后端美术策划TA运营客服）从头执行，也能覆盖该功能全部测试点；中后期时间紧可只写主要前后端逻辑交互测试点。
• 工具：Excel用例表、内部/外部评审
• 经验/坑：
  • 不可凭旧游戏经验盲写用例，一切以最新策划案为准。
  • 用例不能只拆策划案，必须加QA发散测试点。

9.功能测试-测试用例（不同写法）

• 核心内容：
  • 无论用何种方法/格式写用例，只要写了就能提升测试覆盖度、保证测试数量，鼓励积极编写、不嫌麻烦。
  • 两种写法对比：
    • ①详细严谨型：优点严谨有规则，缺点耗时长、繁琐，适用于项目前中期（测试执行不多、有大量时间写初期全部功能用例）；
    • ②简单易懂型：优点简单，缺点信息不完善，对执行人要求高（需熟悉功能，能凭简单步骤判断是否bug），适用于版本中期/中后期时间紧、对功能已很熟悉时节省时间提效。
  • 详细型用例字段：
    • 用例ID（自编，不用Excel系统序列号，因前面有功能模块）；
    • 一/二/三级模块（日常虽有四五级模块但不写，避免前置条件过多、繁琐，只写前三级）；
      • 一级模块每条都重复写出而不合并（避免500条合并居中后要拉很久才看到模块名，方便查看）；
      • 二级模块写清名字（如英雄功能下英雄列表/例会/技能/品阶/升级/强化各20条）；
      • 三级模块区分正常操作与异常操作检查；
    • 优先级（按功能逻辑风险与QA发散测试点严重程度分高/中/低，按优先级高低执行，时间不足时低优先级可容忍漏测，高优先级系统逻辑问题必须先测，否则漏测会出严重/致命阻碍bug）；
    • 前置准备条件（搭测试环境，如GM获得英雄与材料数量，与提bug前置对应）；
    • 操作步骤（可细分1/2/3也可合并）；
    • 预期结果（与策划案一致）；
    • 实际结果（通过√/未通过×/未测试/无法测试，未通过写bug单号，无法测试注明原因）；
    • 测试结果/测试版本（写清SVN/Git版本号、资源号、系统号，bug贴单号）。
  • 简单型用例：只有一级功能→操作步骤→预期结果→实际结果，连测试环境准备都不写，供熟悉功能者快速测试。
  • 不同研发阶段/工作室/测试流程要求不同；任何阶段任何项目哪怕老QA也要写用例。
• 工具：Excel用例表
• 经验/坑：
  • 线上出bug追责时，有详细用例与执行记录/单号可证明已测、责任转移到研发；无凭脑测说不清楚自己测没测。

10.功能测试-测试用例（正确写法）

• 核心内容：
  • 不同公司/工作室要求不同，无绝对正确，认真读策划案、按自己理解写出即可提升覆盖度。
  • 两种拆解思路：
    • ①由面及点：先测整个模块全部页面功能，从一级入口进入先检查所有界面UI/字体等资源（英雄界面：左侧列表是否按等级/颜色等阶/强化进阶等级/属性排序，图标/属性/等级UI是否正确；右侧技能图标是否全显示、排序逻辑（普通技能→连体技→绝招→觉醒）、颜色/等级/文字描述大小与全面；海外多语言翻译文字长短是否超框/换行/排布；例会/时装显示与顺序颜色；不同分辨率/性能/效果设置下美术资源）；每个界面可正常跳下级界面，层层深入到最底层（技能三级界面：一二三级属性/描述、升级进阶材料、满级效果、形象变换）。
    • ②由点到面：从入口先只检查某个功能所有资源（如只看左侧英雄列表：无英雄显示、白/绿/紫英雄显示与排序、筛选按钮各筛选逻辑、删两个英雄、多个同名一级白英雄默认排序），测完再测右侧例会、技能，直到相关功能完成再测其他。
  • 推荐格式：一/二/三级模块可合并（只要清晰易懂一眼看出模块位置即可，不必每条重复）；列含操作、预期结果、实际结果、备注、游戏版本号、是否有bug单，时间充裕按此即可满足初中级要求。
  • 进阶加列：
    • 加"所属测试范围"列（策划/前端/后端/美术），便于测试时直接定位责任方；
    • 区分正常功能测试点与异常/特殊测试点（2G/3G/4G/5G/WiFi/热点、电梯/地下车库、国内外/不同运营商网络、工具模拟网络波动/断网重连、顶号、覆盖安装、突然来电话等特殊场景下正常功能点的表现）。
  • 写正式用例前先把所有测试模块列出，先按策划案拆一级模块、再二级、三级，测试范围即罗列清楚；再写前置测试条件（回顾功能设计思路时心中已有全部测试点，避免遗漏）。
• 工具：Excel用例表
• 经验/坑：先拆模块层级再写用例，前置条件撰写过程即回顾设计思路、防遗漏。

11.功能测试-测试用例（前置后置）

• 核心内容：
  • 用例不只一人使用，后续有多轮回归测试与交叉测试，故需在用例第一页做前置条件设计。
  • 前置页签（首页）记录：
    • QA负责人、编写时间（如5/20提测、5/21写完1000条，编写人张三）；
    • 评审统计（未评审条数、已评审条数，内外部评审通过并获认可）；
    • 首次执行结果统计（测试通过80条、未通过10条有bug、无法测试条数及原因）；
    • 无法测试原因（策划没想到该操作需求需补充，或程序理解错误致实现与策划案不一致）；
    • 记录执行时所处主干/分支/版本号环境，供后续测试同学了解此前环境与情况。
  • 用例维护记录：功能上线前会随市场需求/QA/主策制作人体验频繁修改，策划案实时改、用例随之维护，谁负责测试谁维护；
    • 记录每轮（回归/交叉）执行条数、新增/修改/删除条数、产出bug单号、测试环境。例：5/22李四执行110条（新增10条，因策划改功能点QA需补10-20条）；5/23王五执行110条（修改10条，因策划改原有逻辑、老用例需同步改）；5/24赵六执行90条（删除20条，因玩家不喜欢某功能、策划删除该功能、旧用例废弃）。
    • 新增/修改/删除须在备注写明涉及哪些条（只写用例ID/序号即可，不必贴整条用例），并写清本轮测试环境。
  • 后置条件（每条用例行内）：评审结果（未评审/已评审及原因）；执行结果（通过不写；未通过贴bug单号；未测试写原因——策划逻辑不一致程序未实现/程序未理解策划；无法测试写原因——阻碍bug/需求修改/缺测试环境）；测试版本（前端/后端/系统/美术资源版本）；也可直接在此写对应bug单号。
  • 设计一个测试用例应有两个页签：第一页签放前置条件（谁创建、后续谁维护/新增/修改/删除及条例，便于跟踪）；行内放后置条件。
• 工具：Excel用例表（双页签）
• 经验/坑：谁负责测试谁维护用例；删除用例对应功能被策划删除、旧用例废弃。

12.功能测试-测试用例（分类）

• 核心内容：
  • 测试用例分四类（各类专项另写专项用例，与功能用例持平）：单个功能测试用例、全游戏冒烟测试用例、预发布测试、线上测试。
  • 单个功能测试用例：依所负责功能与版本计划/周期、自定测试计划时间编写；需配GM命令辅助（获取10个满级英雄、强化进阶材料及各消耗数量）；几百到两三千条；高标准是交给任意无经验研发也能覆盖全部测试点；前中期时间多时由点到面/由面到点按策划/前后端/美术/UI/UE逻辑拆解；写清分支（主干/Beta/线上）、服务器、资源版本号。
  • 专项测试用例：性能/适配/弱网/反外挂/自动化/SDK/冗余/报错等各写专用用例，不按功能逻辑而按专项易出问题点写（例兼容测试兼顾海外前100/500手机品牌、安卓/鸿蒙/苹果系统版本、二三十种分辨率、刘海屏、内存/CPU/GPU，使几百到几千元手机都能流畅）。
  • 全游戏冒烟测试用例：所有功能单测/回归/交叉/真机都做完后、上线前最后一轮；不可能一天跑完50个功能×1000条，故冒烟用例控制在1-2小时内，覆盖所有核心功能、各渠道登录、新手流程、强弱引导、核心功能流程跑通，以及运营活动（30日/7日签到、领礼包）、各类充值正常、战斗/资源副本获取消耗正常；按安装后首次进入、功能开启时间与核心流程顺序编写，以正常玩家思路串联跑通，不抠细节（细节此前已抠完）；可GM辅助提前开关卡/条件。
  • 预发布测试：主干研发A版后基于主干切出预发布分支（只含A已测功能，主干含A+新研发的B）；为防分支切换时美术资源丢失/显示不全、代码合并问题；可编辑器可真机，研发阶段30分钟-2小时、上线热更只给15-30分钟；测核心功能流程（登录、新手流程、核心功能、运营充值模拟、战斗副本、资源消耗获取）；预发布阶段仍可开GM平台（不会直接从预发布打真机包给玩家，避免玩家带GM后台）。
  • 线上测试：公测后，手游最少一周一版，常在周三/周五凌晨3-5点更新；留给线上测试仅30分钟（要算打包、热更、发布、固定开服时间）；线上用例无GM，完全按正常玩家角度，新号测各渠道登录、各区服、新手流程、首充；老号测各渠道登录、核心功能流程；必须真钱充值（公测前所有充值档位各买一次，之后每次热更只充最小金额如6元首充/最小礼包，公司报销）；线上分支/线上服写清。
• 工具：GM平台（单功能/冒烟/预发布用，线上无GM）
• 经验/坑：
  • 线上测试必须用真机、新号+老号、覆盖全部渠道，只用老号或单渠道100%出问题。
  • 四种用例针对不同研发阶段，缺一不可。

13.功能测试-提建议

• 核心内容：
  • QA不只找功能bug，是游戏最后质量监管，所有可能影响线上质量的都要监管；测试中发现功能逻辑设计不符流行趋势/违背游戏常见逻辑，可向游戏策划提建议（不是向研发）。
  • 提建议载体因公司而异：项目管理软件建建议单（Team/鸡爪等）、或bug单选"建议"选项、或建整个功能的建议收集文档（写清哪个QA针对哪个功能、当前表现、建议表现、依据逻辑、策划接受与否/是否建需求单/不接受理由）。
  • 提建议前提：胜任岗位需对该游戏类型有深刻理解/经验或同类项目经验，才知道游戏应该是什么样。
  • 角度：不要以QA主观角度（我觉得红/白），要以标准玩家角度，从新手、老手两个角度，分功能项与体验项提合理化建议（魂类游戏对新手不友好但老手舒爽，需兼顾）；功能项考虑功能间关联；体验项考虑PC/真机/Pad不同设备、不同姿势/环境下是否友好。
  • 格式：写清当前功能/玩法（工会、家园、大地图、精英副本、英雄、个人信息、翅膀、团队、帝王争霸赛等）；当前表现（例SLG王城争霸战晚9-10点，部分人已睡）；优化建议（按中国玩家作息改7-8点黄金档）；附参考链接（竞品同类活动开启时间，官网可查）、截图、视频，做到有依据、有表现、有参考。
  • 沟通技巧：态度不强硬也不太软，QA是质量监管只提供反馈建议，虚心提出、合理合情有理有据，不说"你必须按我说的改"；尽量提供参考链接/视频，不能光嘴说；记录沟通结果（接受与否、改成什么样）。
  • 特殊情况：100%确定某设定严重影响体验、拿全依据策划仍不改，不要当面冲突，向测试部门leader/主管汇报，由其找对方主策划沟通。
  • 建议来源：①自身过往游戏经历/对设计的理解；②过往同类项目经验；③竞品/友商参考（最好列3-5个竞品的设定）；④公测前线上测试/删档/黑盒/留存测试中玩家在论坛、贴吧、QQ群等渠道的反馈。
• 工具：项目管理软件/建议收集文档、竞品官网链接、截图视频
• 经验/坑：
  • QA只有提建议权利，策划改不改/怎么改/何时改由策划决定，不要battle/较真争论；不要因策划态度凶就不敢提。

14.功能测试-偶现BUG定义

• 核心内容：
  • 日常bug两类：必现（约占90%）与偶现（约10%）。
  • 偶现定义：按首次出现的操作步骤再次操作未出现，换不同分支/服务器/人账号/电脑多次尝试仍未出，仅偶发1次（第5/10/20次又出1次）统称偶现。
  • 前提：偶现bug本质也是必现，只是复现条件环境苛刻、我们没找到必现规律。
  • 概率判断：首次出现后复现9次都没出≈10%（1/10、1/20写概率）；若复现概率>50%（70/80/90%）其实就是必现，只是触发条件/步骤与首次不同，应换电脑/账号/重搭测试环境再试；低于50%才在bug单标注出现概率（1/10=10%、1/20=20%）。大于50%建议不要写成偶现（显得水平低），应反推首次前后操作步骤找关键触发因素。
  • 偶现可能原因：
    • 编辑器原因（只在编辑器有、真机无）；
    • 游戏终端原因（手机独有/模拟器无、PC端独有，研发阶段会在引擎与PC端都测）；
    • 分支资源不同（master主干有、beta预发布无，前后端资源问题）；
    • 服务器不同（主干服有、QA服无，需同步最新资源）；新账号/老账号问题。
  • 提交偶现bug要写清：
    • ①前置测试环境（改过的配表、前后端美术资源修改、GM命令调试账号等所有配置）；
    • ②非常详细操作步骤（必现bug写三四行即可，偶现要把出现前半分钟甚至前一分钟步骤全写）；
    • ③bug出现后的表现（重开关游戏能否复现、退账号、回主城/副本、切换功能再切回bug是否还在）；
    • ④账号信息（用过的账号、角色ID，方便研发按所在分支/服务器、账号直接复制角色复现调试，避免重搭环境难复制）；
    • ⑤截图/录屏（偶现一定要有，录出现前一分钟操作+出现后半分钟/一分钟表现，不只写文字）；
    • ⑥log/报错信息（有条件时通过GM命令/按钮/文件导出系统log、报错信息粘贴；Unity/U3D编辑器把黄色预警、红色报错全屏逐条截图贴上）。
• 工具：GM命令导出log、Unity/U3D编辑器报错截图、录屏
• 经验/坑：
  • 概率>50%别标成偶现；偶现必须附账号角色ID、完整前后步骤录屏和log，否则研发难复现定位。

15.功能测试-偶现BUG处理方式

• 核心内容：
  • 自己发现偶现bug处理：
    • ①按常规bug标题格式在项目管理软件提交，标题前后备注"偶现"，让研发第一眼看到；哪怕100次只出1次、不确定是不是bug、没截图视频也要提（概率极小可提给leader并挂研发、工作群@说明，后续保留现场再叫人），因为研发可据表现从前后端代码逻辑梳理、屏蔽/提前避免，QA不必须复现才能修；别因怕研发反复问、怕显得没能力就不提，那是给线上埋坑。
    • ②再次复现偶现现场时，第一时间停手、保留现场、离开座位人肉去叫对应前端/后端/策划到真机现场排查（别只在聊天软件喊，对方可能离开十几二十分钟，期间服务器重启/掉线现场就没了），高手可在本机直接定位改代码再试。
  • 研发反馈偶现bug处理：
    • 公司一般规定只有QA能提bug、研发提需求，研发通过聊天软件/截图反馈给负责测试；QA据其信息先把bug提交项目管理软件、标题备注偶现，无操作步骤就写大概表现并贴与研发的聊天截图；
    • 第一时间问还有没有现场，有就立刻人肉叫相关前后端到现场；
    • 没现场就让对方回忆出现前半分钟/一分钟操作与出现后表现，从策划/前后端/美术角度收集信息，QA写下步骤、贴文字/截图/视频提交，并备注"QA正在尝试，复现第一时间叫研发到现场排查"。
  • 复现四步：
    • ①不动当前分支/账号/服务器/GM环境，手离开键鼠，回忆出现前进行了哪些功能/界面的无意识点击，先按回忆步骤试复现；
    • ②仍无法复现则开录屏软件（自己网上找开源截图/录屏软件，不找公司要），按回忆步骤多次尝试，概率上必会再偶遇，录下出现前步骤+表现+出现后逻辑，拿到步骤后贴截图视频到bug单；
    • ③严重且手动无法复现时，借助自动化工具/按键精灵录制回忆出的操作，在曾出现bug的测试环境反复执行脚本大量次，筛出出现视频；
    • ④手动+几十上百次自动化仍无法复现的严重问题，反馈研发从可视化代码逻辑/代码层级梳理定位，无法定位则从代码逻辑屏蔽/避免bug表现；研发不听可找测试leader与对方主程序leader沟通。
  • 废弃条件（偶现bug也分轻度/一般/严重/致命/阻碍）：
    • ①功能重要程度：功能太轻、bug极轻不注意看不到可废弃；废弃须让研发在bug单下备注原因（本版本不修/放下版本），单子流转给QA由QA废弃或挪版本，千万不要让研发直接废弃（QA每天几十上百条不一定看全系统提示，直接废弃会不知道修没修）。
    • ②严重程度：如"背包无法打开"功能已失效（英雄招不出、培养到100星不打架同属严重）必须修，按四步复现，研发说不修/下版本不行；"跨服战场队长名字不显示"影响小（不影响进服、开活动、PK、奖励资源消耗），有排期就修、没时间备注原因放下版本或直接废。
    • ③复现概率：一个版本只有自己或单个美术出现、GM反常规调试（主城招1万精英boss导致卡/掉线崩溃）导致的不算bug；多版本/多研发/交叉测试多人反馈但复现不了，登记到团队偶现bug记录表，标注概率极低无明确步骤，每版本末期集中回归（时间充裕可每周/每半周），3/5/10次都试不出可关闭，仍取决于功能重要程度（支线文字偶现无伤大雅，背包打不开不行）。
    • ④存在时间：A版出现一次，B/C/D版（每版3-4个月，共约1年）都复现不了，可废弃/删除/置灰并备注每版多次尝试、与前后端沟通后推测已随版本迭代消失，QA内部偶现表留记录、项目管理软件暂关闭，后续再出现重开或新提单跟踪。
• 工具：开源截图/录屏软件、自动化工具/按键精灵、团队偶现bug记录表格、项目管理软件
• 经验/坑：
  • 别让研发直接废弃bug单；GM反常规操作造成的卡顿崩溃不算bug；长期多版本不复现的轻bug可关闭但留内部记录。

16.功能测试-特殊测试内容

• 核心内容：功能bug之外四类特殊重要测试：
  • ①卸载安装测试：SDK授权/登录/充值一旦出问题都是严重/阻碍/致命（微信QQ授权失败登不进；充值1元发1万元宝或充100只发1元）。卸载安装极重要：研发成本几千万到几亿，最贵是宣发买量成本（海外SLG单用户150-170、MMO110-120、三消70-90），玩家下载/安装出问题进不去，几亿买量白花，属重大线上事故。每版本封包前必测，是游戏第一步、与更新同等重要。
    • 测试点：
      • 卸载后重装（APP卸载后残留缓存文件删不干净，新旧文件冲突/重复/版本低，前后端如何校验处理）；
      • 正在运行时安装/卸载（切后台直接卸载能否卸掉，重装后是否仍在运行、战场副本环境是否一致；
      • 用旧安装包覆盖正在运行的游戏是否出问题、能否正常覆盖安装）；
      • 其他应用（抖音/快手/微信/微博等热门软件）运行时安装/卸载游戏，看APP间冲突；
      • 存储空间不足时（100G用99.5G剩500MB，底包1G分段下载到500MB时无空间，是否给空间不足/清理缓存提示）；
      • 安装卸载意外情况（死机/重启/断电/来电话，更新资源包中途断网，重启后续传还是重下、已下500MB是否保留；卸载2-4秒倒计时过程中打断是成功还是失败）；
      • 不同渠道商/不同渠道版本包体能否正常运行（某渠道底包有问题会影响其几千几万用户）；
      • 安装后检查版本号与安装时是否一致（更新/登录页左下角右下角显示前端版本号+资源版本号，不对会资源更新失败/拉取失败）；
      • 卸载后是否影响其他应用（不同引擎冲突、相互授权/定位/登录权限，导致其他软件打不开/点击崩溃）。
  • ②热门软件兼容测试：对手机而言游戏只是一个APP，手机里几十个上百个APP开发商/引擎/语言/工具不同必产生冲突（比喻多国不同信仰习惯的人同住一屋）。问题表现：点击打开第一秒黑屏第二秒闪退（曾因与某APP冲突，调优后解决）。测试：用测试手机应用商店热门APP排行榜（非游戏榜）下载前20个，每个点开切后台即可（不需登录授权），再运行本游戏能正常打开运行即通过；只测前20（前5/10覆盖不够，前30/50排名实时波动不稳、有买量刷榜）。
  • ③中断性测试：以手机为载体，模拟干扰手机运行环境的因素，看前后端有无对应逻辑处理/系统提示。
    • 场景：
      • 来电话（默认杀应用/切后台，挂断后网络重拉成功或失败；拒接电话也是瞬间切APP再切回，需测）；
      • 短信/诈骗推送/商城促销弹窗（调起第三方应用）；
      • 误按锁屏键置灰（断网/关APP/切后台，前后端数据是否还连接）；
      • 物理按键机型（按物理返回键游戏能否识别该机型）；
      • 连接有线/无线耳机、无线音响（弹授权、切换）；
      • 调出关机/重启二级三级界面；
      • 低电量（5%/10%手机自动切省电模式禁用部分功能，游戏有无特殊反馈，重点关注）；
      • 过图loading资源加载过程中杀进程/打断，重进资源加载成功与否及表现。前后端反馈规则需与策划沟通、由策划制定，QA按规则测。
  • ④友商竞品bug测试：任何游戏类型市场上都有同类竞品（MOBA曙光英雄对王者、SLG乱世王者/三国志）。最怕闭门造车、闭环只盯自己；
    • 竞品研发测试团队几百上千人、流程完善，每次热更仍修bug，说明此类bug不易出现/识别，我们小团队也可能遇到；
    • 友商用真金白银在线上趟过路，去其官网看每次热更修复了哪些bug，回自己项目核对对应功能测试点/用例有没有测到、有无遗漏，避免重复踩坑。
    • 信息来源：竞品官网、贴吧、论坛、QQ群；
    • 看日常更新板块与紧急更新修复的bug类型（官方只列1-3条代表性修复，看这几条即可）。
• 工具：应用商店热门APP排行榜、竞品官网/贴吧/论坛/QQ群
• 经验/坑：安装环节绝对不能出问题，否则几千万几亿推广无效甚至赔钱；兼容只测前20热门APP即可。

17.功能测试-自检自查流程

• 核心内容：
  • 为什么要研发自检自查：功能联调完流转QA前，研发先自查功能完整性/可流通性/能否按策划案上下游跑通。很多研发不玩自家游戏，若不自查直接流转，功能质量差（二级三四级功能调不起、配表乱配数值错如满级10级配成1000级、升级按钮无效、点击崩溃、疯狂刷配表/底层C++报错），正常一功能500-2000用例产30-50bug，质量差会产几百上千bug，原计划测1天变3-5天，打断/阻碍测试计划；研发也要延期修bug，双方都浪费。
  • 策划自检：
    • ①按策划文档把一二三四级所有功能前后端逻辑全流程跑通、功能正常打开；
    • ②在主干环境测（最后从主干切Beta/Online分支）；
    • ③无明显资源丢失（美术/程序/策划资源，如升级材料图标不显示、缺道具数量因未配表）；
    • ④无明显各类报错（不能点击功能狂报几百上千条，偶1-2条可接受）；
    • ⑤真机真实体验（编辑器只验逻辑，真机才能验设计的体验感/流程感/手感）。
  • 程序自检：
    • ①按策划案从头到尾把流程跑通（不需细跑，各功能能正常点击、符合前后端反应即可，不能凭多年经验不看文档自己编，不同游戏MMO/FPS/SLG/三消公会功能都不同）；
    • ②在主干分支测（测试在QA分支/QA服务器测，不会去程序研发分支）；
    • ③无明显资源丢失（代码逻辑/策划配表/美术资源，模块缺失会致代码冲突报错崩溃）；
    • ④无明显各类报错（点击功能产生的代码/配表/美术/底层C++报错当场处理掉，不能攒到版本最后几天统一修；50-100个功能每条攒100报错就是几千条，最后密集改尤其改底层代码100%引出新问题、需全方位重测、延误发行周期，QA不能妥协，要求当天/当前阶段修复）。
  • 美术自检：
    • ①按策划文档整体流程跑通（美术定UI/UE/地编/特效显示位置/大小/光亮，跑通时才知道该不该有此图标特效、位置大小光亮对不对，QA看不出）；
    • ②在主干环境/主干服务器验收，不要在自己单独的美术工程/美术分支验收（美术资源体量比整个研发工程还大，通常与程序策划资源分两个文件夹、单独美术工程）；
    • ③无明显资源丢失（白块/粉块/黑块/绿块/蓝块及时更新贴补补全）；
    • ④无明显美术资源报错（几十万上百万文件由几十个美术分别命名，联调/调用时命名不兼容致报错）；
    • ⑤真机手感（编辑器分辨率/光学感受正常，真机CPU/GPU/分辨率/硬件不同会冲突致体验误差，只跑资源显示是否正常合适、不跑逻辑）；
    • ⑥最关键：确保所有美术资源是最新版（QA只能验收有没有资源、不知是否最新；资源会换3-7版，还有外包美术团队交付时间不定，只有美术能确认是否最新及何时替换）；
    • ⑦冗余资源检查（换7版后前6版废弃资源须从研发分支删除，几十上百万文件删除100%有遗漏；不删会增大包体、玩家加载大量无用资源耗流量、延长更新时间致流失，版本末期美术详细检查）。
  • 无自检自查的后果：QA单功能产大量bug→测试计划延期、二轮回归；研发计划延期耽误后续开发；每功能都提大量bug→版本从2-3个月拖到4-5个月甚至半年，最后质量不稳定。
  • 公司无流程/未严格执行的做法：让测试leader找制作人/PM沟通，把流程加进研发流程；不能只口头，要在项目管理软件标注各部门检查内容、逐条标注通过/未通过，可见功能状态/问题/处理进度；未严格执行时由leader把"无流程致QA工作量暴增、双方延期、版本延期"问题写清，再把"节省各自测试/修复时间、保证周期"好处写出，与各部门leader拉会沟通。
• 工具：项目管理软件（标注各部门自查检查项）、主干分支环境、真机
• 经验/坑：程序报错禁止攒到版本末尾统一修、尤其底层代码；美术必须自查资源是否最新与冗余，QA验不出。

18.功能测试-查策划配表

• 核心内容：
  • 查策划配表是高效测试方法，用于功能前后端逻辑之外的大量重复性/冗余量测试，替代老式手动逐一点击，提高效率。
  • 适用场景：
    • ①英雄1级升100级：手动要点100次、遇bug暂停提bug再继续；直接查Excel英雄升级列表配表，看等级设置是否连续正确（如1-10后空格直接跳12，10升11必出逻辑bug），手动1-2分钟的事查表10秒，时间成本降到1/10。
    • ②技能1级升100级每级消耗3个不同道具、数量不同，10级后加白色材料变4种、20级后再加变5种；查表先看材料ID是否正确，再看每级每材料消耗数量、等阶提升增减材料类别，手动1-2小时查表5分钟。
    • ③20个英雄各测1-100级材料类别数量，手动20小时约3天，查表半天。
    • ④怪物（100割草怪/200精英怪/50小BOSS/20大BOSS）所有技能伤害，二三百个手动成本极大。
    • ⑤装备强化/升级/进阶：20英雄×七八件装备×每件升100次，数量巨大。
    • ⑥充值/运营礼包几十档位。
    • ⑦背包全部道具（成功线上游戏几千到上万个）：查有无废弃道具、展示效果/文字超行/种类显示、能否使用/展示/分享，手动三四天到一周，查表一天。
  • 查表检查点：配置错误、数量错误、空格、多/少符号、多/少代码、数量填多填少；只要配表无这些错误，基本升级逻辑就是对的。
  • 反面：初级/中级测试闷头用傻瓜式手动，单英雄升级进阶强化测一两周，20-200个英雄每3天/每周版本更新根本测不完，时间成本成倍翻、测试计划延期；领导分给活闷头干不思考提效，别人半天自己一周，能力不被认可。
  • 配合方式：先查配表测一遍、提完配表bug，仍需在游戏里操作一遍，但执行时不必再核对真实消耗数量（配表已查），只按1升2、10升20等把操作走一遍看前后端逻辑对不对（因可能有前端/后端逻辑问题致无法升级/升级失败）；后续每次更新回归冗余量大的工作都用查表方式提效。
• 工具：策划Excel配表（英雄升级列表、材料消耗表、怪物技能伤害表、道具表）
• 经验/坑：查表不能完全替代游戏内操作，配表对了还要走一遍前后端逻辑；不要闷头手动重复，要主动找高效方法。

19.功能测试-反复修改新增内容测试

• 核心内容：
  • 为什么反复修改/新增：研发中市场新功能点、玩家喜欢/需要的功能会影响已做好功能；功能做完只是初版demo，非最终版，会据内部/市场/黑盒/封档/删档/留存测试玩家反馈反复大量修改甚至推翻；策划推翻修改后之前测试结果也作废，需反复重测。
  • 典型例子：
    • ①新手引导（玩家进游戏第一个接触内容，买量推广几千万几亿，引导体验差/严重bug直接致玩家流失、财政损失；系统策划自体验→策划组长→主策→制作人→测试/前后端/美术/运营各部门反复提优化意见，故反复修改调优；后续付费/留存测试必有引导，体验差玩家直接退出删游戏）。
    • ②副本（日常/精英/活动副本几百上千个，测试点多：入口位置NPC、副本列表/文字显示、材料/体力消耗、怪物布置、场景、机制；版本末期主策/主策划改一个底层机制会影响全部上百上千副本，人力/时间不可能全覆盖）。
  • 解决方法：
    • 前期可预料新手引导/副本/英雄底层技能逻辑中后期必被主策制作人修改，第一次测此类功能时就直接用自动化测试工具/脚本编写模拟玩家操作、配特殊用例，反复点击；
    • 模拟通关新手引导手动要3-8小时，脚本15分钟-半小时跑完；
    • 脚本模拟进副本-打-通关-下一关循环，上千副本脚本跑一天，跑时QA可测其他功能，跑完看输出报告（哪个副本某机制报错，附截图/视频）。
  • 脚本复用：功能修改/新增后旧脚本不废，只针对新增/修改内容改脚本即可（前期底层逻辑操作已写完，改新增内容只需10-20分钟，不从零写）。
  • 不能只测修改点：100条逻辑点策划只改10条，研发不敢保证其余90条不改出bug（改功能必调用其他代码逻辑/界面/配表，会把其他内容改出问题）；只测修改内容是不负责任、会漏bug；但每次从0到1全测时间成本又太高，故需自动化辅助。
  • 联调性测试：版本中后期各功能做完，主策制作人新建账号连续玩3-5小时甚至一两天做成长性联调体验，反复提修改意见；改战斗底层逻辑会涉及几十英雄、几百上千怪测试，只剩最后几天不可能从零全测完。
  • 其他用途：
    • ①版本末期对自己负责的最核心功能（如战斗底层）不放心，用脚本24小时反复跑测，会遇到正常测试碰不到的问题（如英雄跑动坐标第二次略偏，蝴蝶效应致站位/技能释放/战斗结果不同），次日看报告；
    • ②严重偶现bug只遇1次、99次未复现，编写该操作步骤脚本在真机24小时反复尝试，按概率学几千次必出现，bug出现致脚本后续步骤执行不了即暂停。
• 工具：自动化测试工具/脚本（脚本编辑器）、24小时跑测报告
• 经验/坑：不要闷头沿用老方法闭环，多向其他测试同学学习高效技术/提效工具；不要只测修改点也不要每次从零全测。

20.功能测试-工业化测试流程

• 核心内容：
  • 为什么需要工业化流程：不同公司/工作室研发流程不同→测试流程不同；测试同学既往经验/认知不同，仅靠个人经验认知梳理测试点必有遗漏（同组6人经验认知不同，看同一英雄A看到80测试点B看到90，如看人审美不同）。
  • 三类风险：①经验/认知差异致覆盖不全遗漏；②负责功能的人临时请假/生病，leader或接手同事不熟悉，时间紧迫下测试面/力度达不到水平，上线出问题；③状态不佳（生活琐事/身体不适但未达请假标准，带病/家里大事坚持上班），认知思维下降，无法保证当日工作质量产出。人不可能始终饱满、从不请假。
  • 工业化流程定义：研发初期就制定各阶段QA该做什么及标准处理流程：脑暴/功能设计QA如何参与输出跟进；策划案阶段QA要做什么、如何要最新策划案/策划案未更新如何处理；联调阶段是否提GM命令/需求、用例内外部评审流程、如何引导研发测试积极发言反馈、如何记录并把修改后用例反馈；提测后按何周期测试、未按期提测怎么处理、提测质量差怎么处理；测试中bug集中在配表/前端/美术/后端占比分析；研发说"先不用测/还没做/内部调试"如何应对；版本中后期性能/兼容/适配/弱网/反外挂/自动化/SDK等专项何时筹备。
  • 作用：覆盖研发早中后期，从功能测试项、专项测试项、测试计划、测试效率、职能划分都有详细标准，无论谁来、状态如何都能按既定流程做完测试，避免个人/团队原因疏漏。
  • 落地：
    • ①部门流程文档（个人/部门流程，应对请假生病状态差致产出低）；
    • ②QA部门按能力分中高低、设不同职能测试小组；
    • 每版本功能轮换，确保每个功能至少2人熟悉全部测试点/特殊点；
    • 流程问题查内部资料（leader开会不知怎么办时查文档按标准执行）。
  • 通用用例模板：几十个英雄/上千怪物/上千副本不必每个从0写；如孙悟空100条用例，其中80条通用（例会、技能描写、属性伤害、升级/进阶/强化消耗、列表排序筛选等），写猪八戒时删掉20条孙悟空独属内容、补20条猪八戒独属即可；怪物按割草怪/精英怪/小BOSS/大BOSS各写通用80条，补20条差异化。
  • 沉淀内部资料：流程规范、通用用例以文字存入内部知识库/SVN资料夹/共享文档，遇到问题/流程卡点直接查阅，保证不疏漏。
• 工具：内部知识库/SVN资料夹/共享文档、职能测试小组、通用用例模板
• 经验/坑：不要只靠个人经验测；功能轮换保证双人熟悉；通用模板+独属补充提高用例效率。

21.功能测试-游戏测试计划

• 核心内容：
  • 为什么要有测试计划：有计划才知道整个研发周期、自己负责哪些功能、各功能关键时间节点；计划依托版本计划镶嵌其中并严格执行，就不会测不完/延期。
  • 错误被动工作方式：
    • ①来需求才测、等leader分活，不跟进负责功能状态与提测时间，导致功能都堆到最后半个月一起提测，第一轮都测不完，更没有回归/交叉/正式数值/真机/专项时间；
    • ②不跟进自己提的bug修复时间，研发不及时修都堆到版本末期，修完还要验收+重跑其他功能+二轮测试，时间不够；
    • ③不按部门测试计划排交叉/回归/专项时间（专项周期比功能测试长、专项bug修复时间远大于普通前后端逻辑bug；线上阶段还要主干/Beta预发布/Online分支测+真机包回归）；
    • ④不计算自己测试周期/bug修复周期/二轮回归周期，导致版本中后期省略测试阶段；
    • ⑤遇到流程卡住（没沟通好测试分支/服务器致去自己分支找不到功能；宣讲时没提GM需求又不好意思后提；研发没自检自查满屏报错/崩溃；阻碍bug研发答应修却不修）不沟通不汇报，闷头干。
  • 测试工具/环境应在研发联调阶段就提前搭（切测试分支、测试服务器、更新前后端美术资源、准备GM命令工具），不要等测试单到了才现搭；先通读自己用例，把需要的GM命令及作用列出，提交leader/GM排期，并记住教训。
  • 制定测试计划方法（以负责背包/邮件/头像/设置/新手引导5个功能、3个月周期为例）：
    • ①识别功能重要程度：新手引导最重要（买量几千万几亿，玩家第一个接触，判断质量、影响留存，出问题当场卸载），头像最不重要（只影响体验不影响功能逻辑）；按重要程度排测试流程与时间，评估所需时间不超版本周期。
    • ②跟进提测时间：新手引导约2月末提测、留最后1个月走完测试流程；到2月末未提测先找研发沟通（已做完忘流转/在测明天提/未做完延后），若延后到2.5-2.8月导致后续回归/交叉/数值/真机/专项都做不了，立即向测试leader汇报；其余四功能应在第一个月内提测，避免堆到最后一个月与新手引导撞车，与研发沟通要求提前提测，未按既定时间提测也要向leader反馈预计提测时间。
    • ③跟进bug修复周期与优先级：5功能各100bug共500个，研发若先修不重要的四功能而不修新手引导，要按功能优先级要求优先修新手引导；修不完由双方leader沟通增/调人手；最坏情况优先保新手引导，背包/邮件/头像/设置带bug上线影响面小（玩家过引导进游戏后按等级才开启），可下次更新修复；挪下版本/热更修须研发在bug单备注原因，QA操作挪单并同步测试case。
    • ④熟悉负责功能研发周期：通过研发拉的测试/沟通/提测群聊天或直接沟通，实时掌握功能所处阶段（脑暴/写策划案/联调/提测）；发现延期提前预警（如脑暴应1号结束，10号还在谈即延期9天，测试流程走不完，提前向leader汇报）；发现研发间争吵/沟通问题会影响配合，提前介入；提前告知策划你的测试周期（一轮功能项测试含写用例/脑暴会/交叉/多轮回归/正式数值/真机需几天到半月），让策划倒排提测时间。
    • ⑤计划要计入测试环境搭建时间（分支/服务器/GM命令）与协作人手（20人副本需20人/机器人、多机型多系统多设备一人操作不过来，提前找leader调配辅助人手半小时到2小时）；规划每个功能各测试阶段时间，某阶段延期会顺延后续阶段，任何阶段（回归/正式数值）都不能舍弃。
  • 不同bug跟进：按严重等级修复顺序——先阻碍/致命，再高优/严重，再一般，再轻度；单功能致命/阻碍/高优修完即可保证功能逻辑基本没问题，普通bug影响不大。
  • 应急预案：策划案几十页、用例几千条导致核心功能没时间测，提前介入提前要策划案筛有用内容；5000条用例只有两天执行不完，主动向leader汇报工作量，协调外包/外部公司/其他项目组测试分工（各跑2500条），不是工作没做好而是工作量大。
• 工具：研发测试/提测群、GM命令排期、leader协调人手、测试计划
• 经验/坑：主动跟进提测与bug修复，不被动等待；功能重要程度决定修复优先级；任何测试阶段不可舍弃；预案要提前做。