柠檬微趣游戏测试岗 AI 面：12 问覆盖测试流程、概率判断与奖励排查

《面试题目》

1. 自我介绍，为什么想从事游戏测试工程师？
2. 近期玩得最多的是什么游戏？从核心玩法、吸引点和游戏体验槽点或发现的 bug 两个方面进行评价
3. 最有成就感的事是什么，克服了什么困难？
4. 结合实际，测试流程包括哪些阶段？
5. 游戏测试与纯软件测试或 App 测试相比有哪些独特之处和重点关注的测试项？
6. 测试广告功能，重点关注哪些异常情况？
7. 中奖概率 1%，测试时连续抽了 200 次都没中，你认为概率是否有问题，接下来会怎么做？
8. 如何判断 bug 优先级？
9. 客户端显示奖励已领取，但玩家背包中没有新增奖励，如何排查？
10. 测试流程中的问答题
11. 如何判断一个版本可以上线？
12. 发现 bug 和预防 bug 哪个更重要？

《参考解析》

「最近在玩什么游戏」是游戏测试岗的隐藏考点。 面试官在验证两件事：你是不是真的玩游戏（对品类和玩法有体感），以及你有没有测试思维——能不能从体验槽点里说出可复现的问题。回答时按「核心玩法 → 吸引我的点 → 我发现的问题」三段讲，问题那一段要有具体场景（什么操作、什么条件下出现、预期与实际差在哪、影响谁）。只说「很好玩、没什么 bug」会直接暴露你没在认真观察。

游戏测试和普通 App 测试的差异，核心是「状态空间大 + 实时性 + 数值」。 独特之处在于：客户端与服务端的状态同步（弱网、断线重连、跨端登录、多端同一账号）、并发与多人交互（组队、交易、排行榜、跨服）、数值与概率（掉率、伤害计算、经济系统，需要大量数据统计而不是单次断言）、实时性（帧率、延迟、技能判定，端上要测不同机型与性能档位）、以及兼容性与外设（机型、系统版本、分辨率、模拟器）。重点测试项一般包括核心玩法闭环、新手引导、支付与充值、活动与奖励发放、以及跨版本的存档兼容。测试流程的阶段是需求评审 → 测试计划与用例设计 → 用例评审 → 冒烟 → 功能测试 → 集成/回归 → 性能与兼容 → 验收与上线 → 线上监控与复盘。

「1% 概率连抽 200 次都没中」这题考的是统计思维，不是算术。 200 次全不中的概率是 0.99^200 ≈ 13.4%，这个概率并不低——也就是说，在没有其他证据的情况下，200 次不中完全在正常波动范围内，不能据此判定概率有问题。正确的处理是：不凭单次体验下结论，而是加大样本做统计检验——用自动化脚本跑成千上万次，统计实际命中率与置信区间，和 1% 做显著性检验；同时排查实现侧的可能偏差（伪随机种子是否固定、概率是否被条件分支改写、是否区分了「保底计数」、是否按账号/时段分桶、活动配置是否真的生效）。补充一点：很多游戏实际上有保底机制，如果产品说明里有保底而 200 次没触发，那才是真 bug——所以要先把「期望值」定义清楚再验。

「客户端显示已领取但背包没有」是典型的跨端一致性问题，排查要分层。 从用户侧先确认可复现路径与时间点（哪个活动、哪次领取、什么网络状态），然后按数据链路往上查：客户端（是否有本地缓存/乐观 UI，请求到底发出没有、响应码是什么）→ 网关与服务端日志（领取请求是否到达、是否被判重、是否返回成功）→ 发放逻辑（奖励配置是否为空、道具 id 是否有效、是否走了异步发放队列）→ 背包查询（道具是否发到了错误的容器/分区、是否有过期时间导致立刻消失）→ 数据落库（事务是否提交、是否被后续操作覆盖）。最常见的三类根因是：客户端乐观展示但服务端失败、发放走异步队列而用户查询早于落库、以及道具配置变更导致旧数据读不出来。修完必须补一条对账机制，否则同类问题还会以「部分用户没收到」的形式再次出现。

bug 优先级与版本能否上线。 优先级不是按「发现顺序」或「难不难修」定，而是按影响面 × 严重度 × 可绕过性：崩溃/卡死/丢数据/支付异常属于最高级（阻塞上线），核心玩法不可用次之，数值错误、UI 重叠、体验问题依次递减；要有统一的判定标准并和策划/开发对齐，避免测试单方面拔高。至于「版本能不能上线」，判据是一组门槛条件而不是感觉：阻塞级与严重级 bug 清零（或已有明确规避方案与排期）、核心流程（登录、付费、新手、活动）冒烟通过、回归覆盖到位、性能与兼容达标、以及有可回滚/热更的兜底方案。「发现 bug 和预防 bug 哪个更重要」的标准答法是「都重要但预防的收益更高」——发现是事后止损，预防（需求评审时质疑规则漏洞、用例设计时覆盖边界、建立自动化回归和线上监控）降低的是复发率；但只讲预防会显得脱离实际，所以要说清两者在不同阶段的分工。

广告功能的异常测试，是游戏测试里少见的「依赖外部系统」的场景。 要覆盖的异常包括：无广告库存时请求失败或超时、播放中断（切后台、来电、网络切换）、播放完成但回调丢失（拿不到奖励）、回调重复（可能重复发奖，必须验证幂等）、跳过/关闭时机的判定、以及奖励发放与广告观看记录的对应关系（防止刷奖励）。这类功能的关键是幂等和状态校验放在服务端——客户端的「已观看」标记不可信，必须由服务端通过广告平台的回调或校验接口确认。