IM 即时通讯系统测试面试题

本文档包含 18 道 IM 即时通讯系统方向的高频面试题，覆盖业务模型与协议选型、消息可靠性、群聊与推送、多端同步、特殊消息、长连接与海量在线、弱网与重连、安全与反垃圾、客户端本地存储、监控与稳定性。IM 是国内大厂（钉钉、企业微信、飞书、抖音 IM、小红书私信、电商客服）测试岗位的高频考点，复习时建议结合自己接触过的 IM 产品对号入座。

一、业务模型与消息可靠性（4题）

Q1: IM 系统的业务模型和分层架构是什么样？

答案：

IM 表面看就是"发消息"，但生产级 IM 系统涉及的业务域和技术栈相当庞大。

业务模型上有四大对象：用户、关系链（好友、群成员）、会话（单聊、群聊、系统通知）、消息（文本、图片、富媒体、信令）。所有功能都围绕这四个对象展开。

技术分层一般这样划分：

接入层负责海量长连接（生产中单机几十万长连接是常态），承担鉴权、协议解码、限频。业务层按职责拆服务，重点是消息服务（消息收发、存储、推送编排）和长连接服务（在线状态、消息下发）的解耦。数据层用 HBase / MongoDB 这类天然适合海量消息存储的数据库，配合 Redis 存在线状态。

测试视角下，每层关注点不同：接入层重点测长连接稳定性和并发量；业务层测消息正确性和状态机；数据层测海量写入和查询性能；外部依赖测降级（推送通道异常时长连接兜底）。

Q2: IM 协议选型有几类？分别有什么测试关注点？

答案：

IM 协议选择直接影响实时性、流量、电量、跨平台能力，常见四类：

私有 TCP 协议。大厂自研（微信 mmtls、钉钉、飞书都是），基于 TCP 自定义二进制协议，通常用 Protobuf 编码。优势是极致的流量和性能优化，缺点是 Web 端不能用、防火墙偶尔会拦截。

WebSocket。基于 HTTP 升级的全双工协议，Web 端原生支持。多数中小 IM 和 Web IM 采用，开发体验好，但流量略大于私有 TCP。

MQTT。物联网协议，单向订阅模式，适合一对多消息推送场景，部分聊天应用用作辅助协议。

HTTP 长轮询 / SSE。早期 Web IM 兜底方案，实时性差但兼容性好，多数现代 IM 不再主用，仅作为弱网降级。

测试关注点：

协议格式合规。报文按协议规范打包/解包，所有字段类型、长度、字节序、可选字段处理正确。多用模糊测试（fuzz）发畸形包看会不会崩。

连接生命周期。建连、握手、鉴权、心跳、断开、重连各环节状态机正确。

消息边界。TCP 是流式协议没有消息边界，必须有"魔数 + 长度"或"分隔符"做粘包/拆包处理，测试时主动制造网络分片看是否能正确解包。

协议版本兼容。客户端版本和服务端版本不一致时（新字段、新消息类型），双方都要能优雅降级。这是 IM 灰度发布最容易出问题的点。

跨平台一致性。同一份协议在 iOS、Android、Web、PC 端实现差异，要测各端互通。

抓包工具上 Wireshark / Charles / WSinspector 都常用，私有协议需要写自定义解码插件。

Q3: 消息的"不丢、不重、有序"三大保证怎么测？

答案：

这是 IM 最经典的面试题，也是 IM 系统的核心 KPI。每个保证都有自己的实现机制和测试方法。

不丢失。消息从客户端发出到对方收到要经历"客户端 → 接入 → 业务 → 存储 → 推送 → 对方接入 → 对方客户端"七步，任何一步丢都算丢。机制上靠"逐跳 ACK + 重试"，每一跳都要拿到下游的确认才认为成功。测试时在每一跳模拟超时和异常（杀进程、断网、数据库写失败），断言消息要么到达要么明确返回失败，绝不能"返回成功但消息没了"。

不重复。重试机制天然会带来重复，去重靠"client_msg_id"（客户端生成的全局唯一 ID）。服务端、客户端都要按这个 ID 去重。测试方法：人为让客户端重发同一条消息，断言对端只收到一次；让服务端重试推送，断言客户端只展示一次；离线消息上线拉取，断言不会和已收到的重复。

有序。单聊场景下要求"A 发给 B 的消息按 A 发送顺序到达 B"。机制上服务端按会话维度生成单调递增的 seq_id，接收方按 seq_id 排序展示。测试时让发送方快速发 100 条消息，断言接收方收到的顺序与发送顺序一致；模拟网络抖动让后发的消息先到，断言客户端能根据 seq_id 重新排序。

群聊有序比单聊难，要求"所有群成员看到的消息顺序一致"。机制上由群消息服务统一生成 seq_id，扇出到所有成员。测试时多个成员同时发消息，断言所有成员看到的群消息顺序完全一致。

实战中这三个保证是 IM 团队的核心质量指标，通常会有线上巡检脚本持续验证，发现率作为月度报表汇报。

Q4: 端到端 ACK 设计是什么样？读扩散和写扩散怎么选？

答案：

端到端 ACK 是 IM 可靠投递的基础，需要分清几类 ACK：

服务端 ACK。服务端收到客户端发的消息并持久化后回 ACK，告诉客户端"消息我收到了"。客户端拿到 ACK 才把"发送中"变成"已发送"。

下行 ACK。接收方客户端收到消息后回 ACK 给服务端，服务端知道这条消息已经送达。送达后服务端把这条消息从"待推送"队列移除，避免重复推送。

已读 ACK。接收方查看消息后发"已读"信号，发送方看到"已读"标记。这是业务层 ACK，不影响可靠投递。

测试时要清楚区分这几类 ACK，每种都设计独立用例。常见 Bug 是把"送达 ACK"当"已读 ACK"用，导致用户没看消息就显示已读。

读扩散 vs 写扩散是 IM 架构上的核心选型，决定消息怎么存。

写扩散。消息发送时为每个接收方写一份。优点是接收方读取简单（只查自己邮箱即可）、未读数容易计算；缺点是写放大严重，万人群一条消息写 1 万份。微信、钉钉的群消息基本用写扩散。

读扩散。消息只存一份，每个用户记录"读到哪儿了"，读时按会话拉取。优点是写入轻、存储节省；缺点是读取重，要按用户读位置筛选，未读数计算复杂。微博、Twitter Feed 是读扩散的典型。

测试关注点不同：

写扩散关注一致性。一条消息扇出到 N 个邮箱要保证原子（要么全成功要么全失败），万人群压测时观察扇出延迟。

读扩散关注读取性能。万人群下用户拉取最新消息的延迟、分页正确性、跨设备的"已读位置"同步。

实际生产中常用"混合扩散"：小群（< 200 人）写扩散，超大群（> 1000 人）读扩散，临界点根据业务调优。测试时要识别系统采用哪种扩散方式，针对性设计场景。

二、群聊、推送与多端同步（5题）

Q5: 群聊和万人群的消息分发怎么测？

答案：

群聊比单聊难在"扇出"，特别是万人群级别（飞书、钉钉、微信都支持 1 万-2 万人群），单条消息要扇出到所有在线成员、为所有离线成员存离线、给所有成员更新未读数，是 IM 系统压力最大的场景。

测试维度：

正确性。所有群成员应收到消息（在线立即收到、离线上线后能拉到）；非群成员不应收到；被踢出的成员从踢出之后的消息不应收到。

时延。万人群发消息后，最后一个在线成员收到的时延（P99 一般要求 < 3 秒）。测试时用脚本模拟万人群在线，断言所有成员收到的时间分布。

顺序。多个成员同时发消息时，所有成员看到的顺序应一致。可以构造"A 和 B 同时发消息"，断言所有人看到的 A、B 顺序相同。

未读数。每个成员的未读数应正确递增、查看消息后正确清零、跨端打开后同步。万人群是未读数 Bug 高发区，典型 Bug 是离线消息上线后未读数不正确。

@消息。@某人、@all 要有差异化通知（声音 / 强提醒 / 横幅），被 @的人即使设置了消息免打扰也要收到提醒。

性能。万人群下扇出 QPS、消息存储写入压力、推送队列堆积情况。生产中通常用"分批扇出 + 异步推送 + 离线降级"组合策略保稳定。

退群与踢人。退群后不再收到群消息但能查看历史；被踢出后历史消息要不要清掉，按产品策略测试。

万人群专项测试一般要联动后端、SRE 团队做压测演练，模拟"一个万人群同时 100 人发消息"的极端场景，观察整个链路是否扛得住。

Q6: 群已读未读、@消息怎么实现和测？

答案：

群已读未读是 IM 里最复杂的小功能之一，特别是企业 IM（钉钉、飞书、企业微信）对已读未读功能要求严格。

实现上有两种主流方案：

逐人维护。给每个成员存一个 last_read_seq_id（用户最后已读消息的 seq_id），消息发送方查询时实时聚合所有成员的已读状态。优点是数据准确，缺点是查询开销大，特别是万人群。

按消息维度维护。给每条消息维护一个"已读人数 / 未读人数"，成员阅读时更新。优点是查询快，缺点是数据可能漂移。

测试要点：

正确性。100 人群 50 人已读时，发送方应看到"50 人已读 / 50 人未读"，点开列表能看到具体名单；新加入的成员从加入时刻起算未读，不应"被动已读"之前的历史消息。

边界。退群成员、被禁言成员、机器人成员是否计入已读未读统计；删除自己离开后是否影响他人计数。

性能。万人群已读未读列表查询的响应时间；超大量已读状态写入对存储的压力。

实时性。某成员阅读后，发送方查询要在多久内看到状态变化（通常要求秒级）。

@消息测试除了基础功能，重点要测：

@all 和 @个人的差异。@all 通常有额外权限（仅群主/管理员能用）、提醒强度更高。

混合 @。一条消息 @多个人时，每个人都应被通知，并且通知里高亮的是自己被 @的位置。

撤回与编辑。撤回带 @的消息时，对应通知应消失；编辑后新增 @某人，新被 @的人应收到通知（部分产品策略是不收，按产品定义）。

跨端通知。在 PC 端 @某人，TA 在手机上应收到推送通知。

Q7: 离线消息存储与拉取怎么测？

答案：

离线消息是 IM 的核心能力之一，指用户不在线期间收到的消息，上线后能"拉回来"。这个看似简单的需求，工程上有不少坑。

存储模型。常见做法是每个用户维护一个"离线消息表"（或叫"邮箱"），收到一条消息时如果接收方不在线，就往他的邮箱里写一份；上线时按时间或 seq_id 拉取。也有"统一存储 + 用户拉取位置"模式（读扩散）。

测试关注点：

完整性。离线期间收到的所有消息上线后都能拉到，包括单聊、群聊、系统通知、@提醒。

顺序。拉取的消息按发送时间或 seq_id 排序，前后端展示一致。

去重。上线时拉的消息中有部分在离线期间已经通过推送通道收到过（即客户端本地存在），不应重复展示。客户端去重靠 client_msg_id 或服务端 msg_id。

分页与上限。离线消息可能积累几千上万条，要测分页拉取（如每页 100 条、按 seq_id 翻页）、超过上限的处理（一般是"只保留最近 N 条"）。

时效。某些消息类型（如音视频通话邀请）有有效期，超时不应再下发。

跨设备。用户有多端时，A 端在线收过的消息，B 端上线后应不应再拉，要按产品定义测试。

边界场景：

新设备登录。新设备应能拉到一定时间窗内的历史消息（如最近 30 天）。

退出登录后重新登录。退出登录是否清空本地、重新登录是否拉全。

切换账号。多账号设备切换时各账号离线消息隔离。

实际生产中离线消息存储是 IM 的存储大头（占消息存储 60% 以上），测试要联动 SRE 评估存储成本和清理策略。

Q8: IM 推送怎么测？厂商通道和长连接怎么协同？

答案：

IM 推送是个综合工程问题，需要长连接通道和厂商通道（FCM、APNs、华为、小米、OPPO、VIVO 等）协同工作。

工作机制：

用户 APP 在前台。长连接在线，直接通过长连接推消息，不需要厂商通道。

APP 退到后台但进程存活。Android 上长连接可能因后台限制断开，需要走厂商通道发"通知"，用户点击通知后唤起 APP 重连。iOS 上后台 socket 会被系统挂起，必须走 APNs。

APP 完全退出。必须走厂商通道，用户点击通知唤起 APP。

测试覆盖维度：

通道选择策略。在不同前后台状态下应选择正确的通道。测试时模拟前台、后台、退出三种状态，断言通道选择正确。

token 管理。每个厂商有自己的 push token，用户切设备、卸载重装、清除数据后 token 会变。要测 token 注册、更新、失效处理。token 失效时应自动剔除并切换通道。

去重。长连接到了一份，厂商通道也到了一份，客户端必须去重（基于 msg_id）。测试时人为让两路同时到，断言只展示一次。

时效。推送延迟（厂商通道有几秒~几十秒延迟）、推送送达率（厂商通道通常 70%~95%，不同设备差异大）、用户唤起率。

降级。某个厂商通道故障时能否切到备用通道（如华为通道挂了用短信兜底）；所有厂商通道挂了，长连接是否能正常工作。

通知样式。标题、内容、声音、横幅、震动、角标在各厂商通道下都应一致；折叠通知（多条消息折叠为一条提醒）；通知分组（按会话分组）。

权限。用户未授予通知权限时业务侧如何处理（如服务端不下发或下发到 silent 通道）。

测试时常借助厂商提供的测试工具（华为推送平台、小米推送 Console、APNs Debugger）观察通道状态，结合本地抓包验证下发链路。

Q9: 多端消息同步怎么实现和测？

答案：

现代 IM 都支持多端登录（手机 + PC + Web 同时在线），多端同步是 IM 的"软实力"，体验做不好用户感知会很差。

实现机制。每个用户维护一个全局递增的 sync_seq，所有变更（发消息、收消息、读消息、改设置）都按 sync_seq 排序。每个端记录"自己的 sync_seq 位置"，启动时按 last_sync_seq 拉取增量。

测试关注点：

消息同步。A 端发出去的消息，B 端、C 端应实时看到（同步延迟通常 < 1 秒），且内容、状态一致。

已读同步。A 端读了消息，B 端、C 端的未读数应同步更新。这个看似简单，但实际很多 IM 产品做不好（已读慢同步、跨端未读数对不上），是高频投诉点。

会话同步。新建群、加好友、改备注名、置顶会话、删除会话，所有端应同步状态。

操作同步。撤回、编辑、收藏消息，所有端应同步看到操作结果。

冲突处理。两个端同时操作（如 A 删消息、B 撤回同一条消息）时谁优先。一般按时间戳或操作类型优先级处理。

跨端能力差异。手机端能拍照发图，PC 端能拖拽文件，要测各端独有能力的正确性。

弱网下的同步。一个端长时间离线后上线，要能拉取期间所有变更并按顺序应用，不能漏不能错。

测试方法上常用"多设备联调"，准备多个测试账号、多台设备（或模拟器）同时操作，借助自动化工具（Appium + 多端协同）批量验证。也可以用"日志埋点 + 离线分析"的方式，看每个端是否在合理时间窗内同步到期望状态。

三、特殊消息、长连接与弱网（5题）

Q10: 撤回、编辑、引用、转发等特殊消息怎么测？

答案：

特殊消息看着只是消息的"花活"，但每种都有自己的状态机和约束。

撤回消息测试要点：

权限。普通成员只能撤回自己发的消息，群管理员能撤回他人消息，时间窗一般限制 2 分钟（产品策略）。要测有权限和无权限两种场景。

时效。在时间窗内撤回成功，超时撤回失败。测试边界：刚好 2 分钟、2 分钟差 1 秒。

副作用。撤回后所有端（包括离线后再上线的端）都应看到"对方撤回了一条消息"提示；已 @的提醒应消失；已被引用的消息撤回后引用部分如何处理（多数显示"[已撤回]"）。

存储。撤回的消息是物理删除还是逻辑删除？多数 IM 是逻辑删除（保留内容用于后续审计、合规要求），客户端展示"已撤回"占位。

编辑消息（部分产品支持，如飞书、Telegram）。

时效。多数限制编辑时间窗（如 24 小时）。

可见性。所有端应看到编辑后内容，已读人数和已读状态不应重新计算（除非 @的人变了）。

版本历史。是否保留编辑历史，部分产品（Slack、飞书）支持查看历史版本。

引用消息测试。引用本身要带原消息快照（防止被引用者撤回后引用变空）；引用消息的转发、撤回、删除要按产品策略处理。

转发消息测试。

合并转发。多条消息合并成一个"聊天记录"对象，转发给别人后能展开查看。要测合并消息内不同消息类型（文本、图片、文件、引用）都能正确展开。

逐条转发。每条作为独立消息转发，要测转发权限（部分敏感消息禁止转发）、转发后水印、转发链路追溯。

跨群转发。从一个群转到另一个群，权限和审计要正确。

撤回级联。原消息被撤回后，已转发的副本一般不受影响（产品策略）。

这些特殊消息容易在跨端、离线、弱网场景下出 Bug，建议每个特殊消息都单独维护一份用例集做回归。

Q11: 富媒体消息（图片、视频、文件）怎么测？

答案：

富媒体消息和文本消息的差异在于"消息体不在 IM 链路中传输，而是先上传到对象存储（OSS / S3），消息里只存 URL"。

完整流程：客户端选文件 → 客户端上传到 OSS → OSS 返回 URL → 客户端发送消息（消息体含 URL + 元信息） → 接收方收到消息 → 接收方按需从 OSS 下载渲染。

测试关注点：

上传环节。大文件分片上传、断点续传、上传失败重试、并发上传多个文件、上传过程中网络中断、上传过程中切换网络（WiFi 切 4G）、上传速度限制。

文件大小与格式。图片大小上限（多数 IM 是 20MB~100MB）、视频大小上限、超大文件提示、格式白名单（防止上传可执行文件）、ICO 文件的特殊处理。

预览与缩略图。图片上传后服务端要生成缩略图（用于聊天列表预览、消息列表预览），生成失败的兜底处理。

下载与缓存。接收方查看时按需下载、已下载的本地缓存、缓存过期策略、清理缓存后再次查看能拉回。

WiFi / 蜂窝差异。WiFi 下自动下载、蜂窝下手动确认，要测设置项的生效。

权限与安全。被撤回的消息文件能否还能下载（一般是"消息撤回后服务端记录拒绝下载"）、文件 URL 有时效性、防盗链。

特殊场景。文件正在上传时撤回消息、上传成功但发送消息失败、下载到一半网络断了。

视频消息额外关注。

转码。服务端要把上传的视频转成多档分辨率（240p / 480p / 720p / 1080p），并选择合适的封面。

播放。在线流式播放、本地缓存后播放、横竖屏切换、后台播放、断网恢复。

文件消息额外关注。

格式提示。常见格式（doc / xls / pdf / zip）显示对应图标。

在线预览。某些格式（PDF / Office）支持在线预览，要测预览功能和原始下载能力分别正确。

实战中富媒体消息是 IM 系统故障率最高的部分（依赖 OSS、CDN、转码等多个外部服务），测试覆盖度要远高于纯文本消息。

Q12: 长连接维护、心跳和海量在线压测怎么做？

答案：

IM 服务端最核心的指标之一是"单机长连接数"，国内大厂的 IM 接入服务单机一般维持 50 万~150 万长连接，是性能压测的重点对象。

长连接维护机制。

心跳。客户端定时（移动端一般 30~180 秒、Web 30 秒）发心跳包给服务端，服务端回应。心跳间隔太短耗电、太长容易被运营商网络回收。

NAT 保活。移动网络 NAT 表项一般 5 分钟超时，心跳间隔通常控制在这之内。不同运营商超时时间不同，要按运营商动态调整。

断线检测。客户端检测心跳超时主动重连；服务端检测客户端无响应主动关闭连接释放资源。

会话续连。重连后能恢复上次的会话状态（不需要重新拉历史消息），靠客户端记录的 last_sync_seq 实现增量同步。

测试维度：

心跳准确性。心跳间隔是否符合配置、心跳失败时的重试策略、不同网络环境下心跳调整策略。

断线重连。手动断开 WiFi / 飞行模式 / 切换网络后能否在合理时间内（一般 < 5 秒）重连成功；重连后能否拉取期间错过的消息。

海量在线压测。

工具上常用 tcpkali、自研压测工具、甚至直接用 Linux 多进程模拟。难点是单机能模拟的客户端数受端口数（默认 6 万）、文件描述符（要调大到几十万）、CPU 内存限制。

压测目标包括：

单机最大连接数。压到单机崩溃前的极限值，看是哪个资源先成瓶颈（FD、内存、CPU、带宽）。

建连速度。每秒能新建多少长连接（用于评估突发场景下的服务端能力）。

心跳吞吐。所有连接同时发心跳，服务端 CPU 占用、回包延迟。

消息扇出。在大量在线连接基础上做消息推送压测，看推送延迟分布。

异常恢复。压测中关掉一台服务端节点（故意触发故障），观察连接是否平滑迁移到其他节点。

资源监控。压测时同步监控 CPU、内存、网络带宽、TCP 连接数、句柄数、ETIME 等系统指标，定位瓶颈。

生产环境上线前压测通常要做到目标 QPS 的 1.5~2 倍，留出应急冗余；大促前还要做"全链路扩容压测"。

Q13: 弱网环境下的 IM 测试要点有哪些？

答案：

IM 主战场在移动端，弱网（地铁、电梯、电梯里、跨国漫游、3G、地下停车场）下能不能可靠工作直接影响产品口碑。弱网测试是 IM 测试的核心专项。

工具上常用 Charles + Network Throttling、Apple Network Link Conditioner、Android 系统自带的 GSM/EDGE 模拟、专业工具 ATC（Facebook 开源）。Charles 可以模拟带宽限制、延迟、丢包，覆盖 90% 的弱网场景。

测试维度：

低带宽。模拟 50kbps、100kbps 带宽下发消息、收消息、加载图片、视频上传的体验。重点关注超时设置、降级策略（图片自动降为缩略图、视频提示用户改用 WiFi）。

高延迟。注入 500ms、1s、3s 的 RTT，断言客户端不卡死、有合理的进度提示、超时不至于让用户等到崩溃。

丢包。模拟 5%、10%、30% 丢包率，断言消息最终能送达（靠重试），但应给用户"正在发送"的状态反馈。

网络抖动。短时间断开（1~10 秒）再连接，看消息发送队列是否能正确恢复、长连接是否能自动重连、未发送的消息是否保留。

网络切换。WiFi 切 4G、4G 切 WiFi、4G 切 5G，过渡期间是否丢消息、是否会重复发消息、长连接重建速度。

弱网降级。某些功能在弱网下应自动降级，如视频通话切语音、HD 切普清、自动下载关闭、图片预加载关闭等。

异常场景：

发消息时网络断开。客户端应将消息加入本地队列，网络恢复后自动重发，期间显示"发送中"状态。

接收消息时网络断开。重连后通过同步机制拉取期间错过的消息。

正在通话时切网络。短时间内 RTC 应能恢复，否则提示用户重连。

漫游和跨国。跨运营商、跨国时 IP 变化，长连接需要重建，对端能否感知到对端"漂移"。

弱网测试通常每次大版本都做，自动化用例覆盖关键场景，手工探索覆盖长尾问题。

Q14: 多端登录冲突与踢人测试怎么做？

答案：

多端登录策略是 IM 产品的核心策略之一，不同产品差异巨大：

微信。移动端互踢（手机 + 平板二选一登录），PC 端需要扫码且手机在线才能保持。

企业 IM（钉钉、飞书、企业微信）。手机 + PC + Web 多端同时在线，互不踢出。

Telegram。任意多端同时在线，互不冲突。

每种策略下测试关注点不同，但核心问题相似。

主动踢人测试。

同账号登录新设备时旧设备应被踢下线、踢下线后接收方在 IM 收到通知。要测踢下线后旧设备能否立即感知（一般在收到下一条消息或心跳响应时感知）、踢下线后旧设备的消息发送是否被拒绝。

边界场景：旧设备处于离线状态（手机锁屏后）时新设备登录，旧设备何时感知（一般在网络恢复后立刻收到"被踢"信号）；旧设备登录中（弱网状态）时新设备登录是否正常完成。

被动踢人测试。

由后台管理员强制踢人下线（封号、风控触发），各端应立即感知并跳转登录页。

跨端会话同步测试。

A 端发消息，B 端立刻收到副本（不是从对方收到的，而是自己发的同步副本）。

A 端读消息，B 端的未读数清零。

A 端撤回消息，所有端撤回成功。

权限差异。某些功能仅特定端可用（如手机扫码支付、PC 端剪贴板增强），跨端使用时要正确报错或引导切换。

设备管理测试。

在"设备管理"页面查看所有登录设备，能主动下线某个设备；远程下线的设备应被踢下线，但不影响其他设备。

安全性。登录新设备时是否需要二次验证（验证码、生物识别），异地登录、新设备登录是否触发风控告警。

实际 IM 测试中"多端冲突"是高频投诉来源，特别是企业 IM 的多端协同体验，要建立专项回归集长期维护。

四、安全、客户端与监控（4题）

Q15: IM 消息加密和隐私怎么测？

答案：

IM 消息加密涉及传输安全和端到端加密两个层级，测试要分清两者差异。

传输安全（最低要求）。客户端到服务端使用 TLS 加密（HTTPS / WSS），私有协议在 TCP 上面套自己的加密层（如微信 mmtls）。测试时用抓包工具看是否能解出明文，不能就说明传输层加密有效；同时要测证书校验（用伪造证书攻击应被拒绝）、TLS 版本（禁用 TLS 1.0/1.1）。

端到端加密（E2EE）。消息只有发送方和接收方能解密，服务端只是密文中转。Signal、WhatsApp、iMessage 是典型代表，国内 IM 大多不做（监管要求要可见明文）。

E2EE 测试要点：

密钥协商。通信前双方协商共享密钥（Signal 协议），要测密钥协商成功率、密钥泄露后能否前向安全（Forward Secrecy）。

群聊 E2EE。群消息发到 N 个人，怎么协商共享密钥；新成员加入后能不能看到加入前的消息（一般不能，符合 E2EE 原则）。

设备验证。新设备登录后老设备能否验证身份；身份变更（换设备）时对方能否感知。

隐私测试维度：

数据最小化。服务端只保存必要数据，定期清理过期数据。要审计敏感数据（聊天内容、定位、通讯录）是否符合产品声明的留存策略。

权限授权。客户端请求通讯录、位置、相册、麦克风等权限要有明确说明，不应过度索取。

数据导出与删除。GDPR / 个保法要求用户能导出自己的数据、能删除账号及数据。要测导出数据的完整性、删除后数据真正不可恢复（包括备份）。

合规检查。国内 IM 需要符合《个保法》《数据安全法》《网络安全法》《生成式 AI 管理办法》（如果有 AI 功能）等。

防截屏（部分企业 IM 提供）。看消息时不允许截屏（iOS 通过遮罩层、Android 通过 FLAG_SECURE），测试时尝试截屏、录屏、第三方截屏工具、远程协助截屏。

水印。看消息时显示用户身份水印，防止内部泄密。要测水印不能被去掉、能正确显示当前用户身份。

Q16: 敏感词过滤和反垃圾消息怎么测？

答案：

IM 是黑灰产高发场景：诈骗、传销、违法信息、广告、骚扰。反垃圾能力是 IM 系统的合规底线和产品口碑。

敏感词过滤测试维度：

词库覆盖。所有合规要求的敏感词（涉政、涉黄、涉暴、违法广告）都在词库里。测试时维护一份"敏感词清单"，覆盖各类目，定期更新。

变形识别。黑产会用同音字、繁简变换、特殊符号、谐音、火星文规避识别。如"赌博"变形为"DU 博""赌 bo""dǔ博""睹博"等。测试时要把变形规则做成生成器，自动生成大量测试用例。

上下文识别。某些词在不同上下文里意义不同（如"自杀"在心理咨询群里是正常话题）。测试时关注误伤率，给真实合法用例打白。

处理策略。识别后处理一般有几档：屏蔽（消息不发送）、替换（敏感字变成 *）、警告（发出但提醒）、入审（人工复核）、封禁（用户/账号封禁）。测试每一档策略的触发条件和效果。

反垃圾消息测试维度：

高频发送识别。短时间内向多人发同一内容（典型垃圾消息特征）触发限频或拦截。要测正常用户广播（节日祝福）会不会被误伤。

可疑链接识别。识别钓鱼链接、短链跳转、可疑域名，要测识别准确率和误伤率。

陌生人验证。陌生人加好友时是否要求验证消息、单聊前几条消息是否过审。

举报与封禁。用户举报后多久人工/自动处理；举报达到阈值后自动限制功能。

测试方法上常用"红蓝对抗"：红队（攻击方）尝试各种规避手段发垃圾消息，蓝队（防御方）观察哪些被识别哪些漏过，迭代规则。这种对抗每月一次，持续提升识别能力。

误伤率监控。线上常态化监控被拦截消息的误判率（用户申诉率、人工复核误判率），过高时要回滚规则。这个指标比识别率更重要，"宁可漏 1000 也不错杀 1 个"在 IM 里是真理。

Q17: IM 客户端本地存储与缓存怎么测？

答案：

IM 客户端本地存储是用户体验的关键环节，决定了离线模式下能否查看历史消息、消息加载速度、APP 启动速度。

存储设计。主流 IM 客户端用 SQLite（移动端）或 IndexedDB（Web）存本地消息，还会有图片、视频、文件的本地缓存目录。

测试关注点：

数据完整性。本地存的消息和服务端一致；意外杀进程后再启动数据不丢；卸载重装后重新拉取数据。

存储性能。万条消息以上的会话搜索响应时间；启动时加载会话列表的速度；插入新消息的延迟。

数据库升级。APP 版本升级时数据库 schema 变更要平滑迁移。要测从历史多个版本（最早支持版本到当前）跨版本升级，每个跨度都验证数据完整性。

缓存清理。磁盘空间紧张时自动清理过期缓存、按 LRU 清理；用户主动"清除缓存"功能要清理对应数据但保留消息记录（产品策略）。

加密。敏感数据（消息内容、token）在本地存储时是否加密；root 设备能否直接读数据库（一般要求加密保护）。

并发安全。多线程同时读写数据库（接收消息线程 + UI 线程）不能损坏数据。Android 上要测进程被杀场景下的数据库一致性。

跨平台一致性。同一用户在 iOS 和 Android 上的本地数据结构、查询行为应一致（用户切换平台时无感）。

容量上限。本地消息存储上限（一般几 GB），达到上限后的清理策略；图片视频缓存的清理策略。

边界场景：

低存储空间。设备只剩 100MB 时下载文件应有提示。

数据库损坏。模拟数据库文件损坏（用工具改写），客户端应有恢复机制（重新拉取）。

切账号。多账号切换时本地数据隔离，互不干扰。

测试方法上常用 ADB 抓取数据库直接 SQL 查询验证、Charles 抓接口对比服务端数据、自动化脚本生成大量消息做压力测试。

Q18: IM 系统的核心监控指标有哪些？怎么测稳定性？

答案：

IM 系统的稳定性 SLA 通常做到 99.9% 以上（年故障时间 < 9 小时），监控覆盖度直接决定问题发现速度。

核心监控指标分四类。

业务指标。消息发送量、消息送达率、消息送达延迟（P50/P95/P99）、单聊和群聊 DAU、长连接在线数、推送送达率、活跃群数等。这些是产品同学最关心的"健康度"指标。

技术指标。接口 QPS、响应时间、错误率、TCP 连接数、长连接 RT、CPU/内存/磁盘水位、消息存储写入延迟、MQ 堆积、Redis 命中率等。SRE 同学的日常巡检对象。

容量指标。服务器节点数、长连接节点容量水位、存储集群容量、带宽水位。容量预警是大促和突发流量的关键。

故障指标。告警次数、故障次数、平均恢复时间（MTTR）、影响用户数。每次故障都会沉淀这些指标用于复盘。

稳定性测试维度：

容灾演练。定期断开某个机房、停掉一组服务、Kill 一台数据库主节点，看服务是否能自动切换、用户是否感知。多数大厂要求"分钟级容灾"。

故障注入（Chaos Engineering）。借助 ChaosBlade、Chaos Mesh 在生产或预发环境注入故障（网络延迟、丢包、CPU 满载、磁盘 IO 慢、进程挂掉），看系统反应。

降级演练。每个核心功能要有降级开关，演练时人工开启，验证降级后用户体验可接受。如"消息撤回服务"挂了，发消息不应受影响；"已读未读服务"挂了，消息正常收发但已读功能临时不可用。

压测与扩容演练。定期做生产压测，并演练自动扩容流程（K8s HPA、火山引擎弹性资源），验证扩容生效时间和上限。

灰度发布。新版本上线灰度（1% → 5% → 20% → 100%），每个阶段观察核心指标变化，发现异常立即回滚。要测灰度切流是否平滑、回滚是否秒级生效。

值班响应。线上故障时值班同学多久响应、多久定位、多久恢复。可以做"演练日"（Game Day），人为造故障考核团队应急能力。

监控告警的常见反模式：

告警过多（狼来了），关键告警被淹没。

告警阈值不合理，业务正常波动也告警。

告警没人响应，半夜响起没人处理。

测试同学在 IM 项目里通常会和 SRE 紧密配合，参与制定核心 SLO、监控指标和压测方案，把"质量"从功能维度扩展到稳定性维度。