米哈游秋招游戏测试笔试：题型结构与考查方向

《面试题目》

题型与考点

1. 这场笔试包含哪些题型，各多少题？
2. 网页与设备兼容性测试要覆盖哪些点？
3. 线上异常问题怎么定位？日志分析和事故处理的思路是什么？
4. 游戏里的奖励、签到、排行榜这类系统怎么做测试设计？
5. 测试计划和测试范围怎么确定？要覆盖哪些异常场景？
6. 连接池、循环队列、死锁这些基础知识考的是什么？
7. 战斗中的命中反馈和玩家引导这类体验，要验证什么？

问答题

8. 请为一个《原神》里的任务撰写测试用例。
9. 自选一款游戏，说明它的核心玩法与优缺点；如果由你来开发，你会怎么设计？

---

《参考解析》

题型结构：广度优先，不止考测试理论

整卷是「单选 10 题 + 多选 12 题 + 手撕编程 1 题 + 问答 2 题」。客观题量大，覆盖的是测试基础、计算机基础与游戏理解的混合体，这意味着复习不能只刷测试理论：数据结构与并发的基础（连接池、循环队列、死锁）要能算得清、说得明，游戏侧的战斗反馈、引导设计要能从一个玩家的视角讲出「哪里可能出错」。

兼容性测试要按矩阵梳理，而不是想到哪测到哪

网页与设备兼容性测试的常规拆法是几个正交维度：浏览器与内核版本（Chrome、Edge、Safari、Firefox，以及手机上的各家内置浏览器）、分辨率与屏幕比例（含全面屏刘海、折叠屏展开态、横竖屏切换）、操作系统与机型档位（高刷与低端机要测帧率与内存）、网络环境（弱网、丢包、切网、断网重连）。重点是把「同一份数据在多个端上的表现是否一致」当作判据——登录态互通、进度同步、充值到账这些跨端链路是最容易出问题的地方。

异常定位：先固定可复现路径，再顺着日志时间线走

线上问题第一步永远是固定现场：拿到玩家 ID、发生时间、操作路径、客户端版本与设备信息，尽量在测试环境复现。复现不了就靠日志——客户端日志看崩溃栈、网络请求与本地状态，服务端日志看同一时间窗内的错误码与调用链，两端用请求 ID 或时间戳对齐，才能判断是客户端逻辑、接口返回还是下游存储的问题。事故处理上，先止损（回滚、降级、开关关闭）再定位根因，并且要留证据（日志、快照、当时的配置），事后补上监控与告警；奖励类事故还要考虑对已受影响玩家的补发方案，补发脚本必须幂等。

奖励、签到、排行榜的测试点从「时间 + 并发 + 幂等」三处切

签到与活动奖励的核心是时间边界：跨天、跨周、活动开始与结束的那一秒、时区与服务器时间不一致、客户端改本地时间；再叠加断线重连、杀进程重进、多端同时登录这些状态异常，验证不会重复发放或漏发。奖励发放要有幂等设计，重复请求只生效一次。排行榜要测同分并列的名次规则、榜单刷新延迟与缓存、数据量很大时的分页与截断、作弊与异常数据的过滤，以及玩家改名/删号后榜单上的展示。系统设计题答这类结构通常不会错：先明确数据从哪来、以什么粒度落库、什么时候刷、异常如何兜底。

问答题怎么答才不空

「为一个任务写测试用例」的评分点在于用例的覆盖面和可执行性，而不是文案漂亮。一份合格的用例要包含：前置条件（账号等级、前置任务是否完成、背包与体力状态）、操作步骤、预期结果（对话分支、任务道具、奖励内容与数量、任务状态流转），再补上异常场景——中途放弃任务、断线重连、任务 NPC 被其他玩家/事件占用、背包已满导致奖励发放失败、重复接取。写得越具体越占优，比如奖励要写到「原石 × N、摩拉 × N、经验书 × N」，异常要写到「背包满时应提示并保留奖励可补领」。

「自选游戏讲核心玩法」这类题考的是分析框架：先一句话说清核心循环（玩家做什么 → 获得什么 → 用来做什么），再说它的成长线与付费/留存动机，然后给优缺点各一到两条并落到机制上（例如「数值成长曲线前紧后松，导致中期手感变钝」），最后如果自己来做，要给出针对缺点的具体改法而不是泛泛的「加强社交」。整场下来给人的感觉是范围偏广：测试理论、游戏理解、逻辑分析和实际问题处理各占一块，准备时按这四块各找一点能聊深的东西。