游戏好友与组队怎么测：关系状态、邀请竞态、权限与跨端同步

m0_59437018

20人浏览 · 2026-08-08 09:00:00

m0_59437018 · 2026-08-08 09:00:00 发布

游戏好友与组队怎么测：关系状态、邀请竞态、权限与跨端同步

摘要：好友和组队功能把关系链、在线状态、邀请消息、房间成员与玩法准入连在一起。本文用状态机和并发不变量拆解好友申请、黑名单、组队邀请、队长迁移与跨端同步。

标签：游戏测试、好友系统、组队测试、关系链、状态一致性

一、面试官真正想考什么

这类题考察的是多人交互建模。面试官会观察你是否区分“社交关系”和“临时队伍关系”，是否能处理双方同时操作，以及能否说明客户端缓存与服务端权威状态不一致时如何恢复。

二、30 秒合格回答

我会分别建立好友关系状态机和队伍状态机。好友侧覆盖申请、同意、拒绝、删除、拉黑、备注、上限和隐私权限；组队侧覆盖创建、邀请、申请、审批、队长转移、踢人、离队、匹配和解散。重点设计双方同时加好友、邀请与拉黑同时发生、最后一个队伍名额被多人接受、队长掉线等竞态，并验证服务端权限、消息去重、跨端刷新和断线恢复，最终确保双方看到的关系与队伍成员集合收敛一致。

三、2 分钟高分回答：两个核心状态机

好友关系不能只用一个布尔值表示：

无关系 -> A申请B -> 待处理 -> 双向好友
   |          |          |       |
   +------ 拉黑/拒绝/过期 <--- 删除

队伍可以抽象为：

无队伍 -> 邀请中/申请中 -> 队员 -> 队长
                              |       |
                            离队     转让/解散

还要明确邀请过期、玩家已进入其他队伍、队伍已满、正在匹配或战斗中的限制。

四、核心测试范围

1. 好友关系

精确搜索、推荐列表、最近玩家和跨服玩家；
双方同时申请、重复申请、撤回、拒绝和过期；
好友上限在多个申请同时同意时不能被突破；
单向删除与双向关系解除后的展示和消息权限；
黑名单优先级，以及邀请、私聊、赠送和推荐是否被拦截；
在线状态、最后上线时间和隐身设置的可见范围。

2. 组队流程

队长邀请、玩家申请、自动同意和房间密码；
角色等级、玩法解锁、段位、跨服与版本准入；
满员、邀请过期、重复接受和已加入其他队伍；
队长转移、踢人、主动离队、掉线超时和队伍解散；
匹配中、加载中、战斗中能否修改成员；
队员准备状态、地图选择和队长权限。

3. 消息与跨端同步

邀请消息具有唯一 ID，重复推送不能生成多条有效邀请；
手机和模拟器同时登录时，一端处理后另一端及时失效；
断线重连后拉取权威成员快照，而不是继续使用本地列表；
队伍频道、语音频道和玩法服务器随成员变更同步；
旧页面发起操作时服务端再次校验关系版本。

五、连续追问与参考答案

追问 1：A 和 B 同时向对方发送好友申请会怎样？

产品应定义合并为好友还是保留一条待处理记录。测试同时请求、不同到达顺序和重试，验证最终只有一条关系记录、双方列表一致、好友数各增加一次，通知不会重复轰炸。

追问 2：三个人同时接受只剩一个位置的队伍邀请呢？

用屏障同时释放接受请求，服务端原子判断队伍版本和容量，只允许一个成功。失败者应收到“队伍已满”等可理解结果，成员数、频道成员和玩法房间必须一致。

追问 3：队长掉线后如何测试？

先明确是立即转让、保留一段时间还是解散。覆盖短线重连、超时、战斗内外、唯一队员和多名候选人；验证新队长选择规则稳定，旧队长回来后不会恢复过期权限。

追问 4：拉黑后对方还能从历史邀请进入队伍怎么办？

说明邀请接受接口只校验了邀请有效期，没有读取最新关系权限。修复应在最终入队时再次检查黑名单、队伍容量和玩法准入，历史消息同时标记失效。

追问 5：双方好友列表不一致，怎么定位？

用双方角色 ID 和关系记录 ID 查询关系服务的权威状态，再检查事件投递、缓存版本、分页游标和客户端刷新。区分底层关系写入不一致，还是一方读到旧缓存或列表遗漏。

六、项目案例表达模板

我遇到过队长踢人后，被踢玩家仍进入匹配房间的问题。队伍服务已移除成员，但匹配服务使用了数秒前的成员快照。通过队伍版本号关联日志确认是过期快照。我推动匹配确认阶段再次校验队伍 ID、版本和成员集合，成员变更时主动取消旧匹配票据；随后补测踢人、离队、掉线和多端操作，确保队伍服务、频道与匹配房间最终一致。