社交 Feed 系统测试面试题

本文档包含 18 道社交 Feed 系统方向的高频面试题，覆盖 Feed 架构与推拉模型、推荐排序、A/B 实验、热搜与热点、信息流广告、互动（点赞/评论/转发）、关系链、通知系统、话题与超话、内容审核、防刷防作弊、监控大盘。Feed 是国内大厂（微博、抖音、小红书、知乎、B 站、X / Twitter）的核心业务形态之一，准备时建议把自己用过的产品当作案例对照展开。

一、Feed 架构与数据模型（4题）

Q1: Feed 流的推拉模型怎么选？

答案：

Feed 流是社交系统的核心，本质问题是"用户 A 关注了 1000 人，怎么把 1000 人的最新动态高效组合成一条时间轴"。工程上有三类经典方案。

推模式（Push / Fan-out on Write）。用户发动态时主动写到所有粉丝的"收件箱"，粉丝读时直接查自己的收件箱。优点：读极快，扩展性好。缺点：大 V 发一条要扇出几百万、几千万次写入（"明星结婚导致微博崩溃"就是这个原因）。

拉模式（Pull / Fan-out on Read）。用户读时主动去拉所有关注对象的最新动态，聚合排序后展示。优点：写极轻量、存储省。缺点：读极重，关注 1000 人就要做 1000 次查询。

推拉结合。普通用户走推模式（粉丝少扇出便宜），大 V 走拉模式（避免百万级扇出）。读时把"普通收件箱"+"大 V 拉取"两路合并。Twitter 早期就是这套架构，国内微博、小红书也都用类似方案。

选型考虑：

读写比。读多写少用推模式（多数社交产品），读写均衡用拉模式（少数）。

用户分层。粉丝量分布是否长尾（少数大 V + 大量普通用户）。

实时性。推模式更实时，拉模式有聚合延迟。

存储成本。推模式收件箱重复存储，拉模式按需聚合更省。

测试关注点：

推模式扇出。大 V 发动态时扇出延迟、扇出完整性（千万粉丝是否都收到了）、扇出过程中失败重试、扇出期间粉丝列表变化（新增、删除粉丝）的处理。

拉模式聚合。关注 1000 人时聚合时长、分页正确性、聚合时部分依赖超时的降级。

混合模式合并。两路数据合并排序的正确性、去重、顺序一致性。

实战 Bug 多在边界场景：扇出未完成时粉丝刷新看到部分新动态、删除关注后还能看到旧动态、聚合时某条慢查询拖垮整体响应。

Q2: 推拉结合的 Feed 模型怎么测？

答案：

推拉结合是主流方案但测试复杂度高，因为有两套并行的链路，要测它们的合作、合并、降级。

测试维度：

边界判定。"什么用户走推、什么走拉"通常按粉丝数阈值划分（如粉丝 > 100 万走拉模式）。要测：

阈值附近（99 万 vs 101 万）行为是否正确切换。

阈值切换时机（用户从普通涨到大 V 的过渡）。

不同业务场景（普通动态 vs 视频 vs 直播预告）是否用同一阈值。

扇出 + 拉取的合并。

时间戳排序。两路数据合并后按发布时间排序，要测时间戳精度（毫秒级，否则同秒发的两条顺序可能乱）。

去重。如果普通用户互相关注的大 V 同时被推和被拉，会不会重复出现。

新鲜度。两路数据更新延迟可能不同（推可能慢几秒），要测整体新鲜度是否一致。

写时扇出正确性。

扇出范围。当前在线粉丝 / 全量粉丝 / 活跃粉丝，不同策略都要测。

扇出顺序。一般按粉丝活跃度优先扇出（活跃用户优先看到），要测优先级队列正确。

扇出幂等。重试或并发场景下不应扇出多次（粉丝看到重复）。

读时聚合正确性。

关注列表变化的同步。用户关注/取关后多久生效到 Feed。

聚合的实时性。新发布的内容多久能拉到。

排序稳定性。同一用户多次刷新 Feed，前几条应大致相同（不应每次完全打乱）。

异常处理。

某路数据源故障（推模式收件箱不可达）的兜底（降级到完整拉模式）。

部分关注对象不可达的处理（跳过 vs 失败重试）。

数据一致性。

冷启动。新用户刚关注一批人，立即打开 Feed 能否看到内容（推模式还没扇出来）。

历史数据迁移。架构升级时新老两套 Feed 数据怎么合并、用户能否平滑过渡。

测试方法：

人工对比。模拟一组用户的关注关系，按预期推演 Feed 内容，和系统实际返回比对。

自动化用例。配置不同关注关系矩阵（1 个大 V、10 个普通用户、混合），多次刷新看是否符合预期。

线上巡检。监控两路数据的延迟分布、合并失败率、Feed 内容缺失率，超过阈值告警。

Feed 系统测试的"正确性"判断标准模糊（什么样算"对"），更多靠业务直觉和长期数据观察。

Q3: Feed 分页和回滚怎么测？

答案：

Feed 流的分页跟普通分页不同，因为内容是动态新增的（用户随时发新动态），传统"page + size"分页会出问题。

经典 Bug。用户翻到第 3 页（第 21~30 条）时，刚好有 5 条新内容发布，第 4 页（21+10=31~40）就会重复显示原来的 26~30 条。这是 Feed 分页最经典的"漂移"问题。

主流分页方案：

按时间戳分页（Cursor-based）。每次请求带"上次拉到的最后一条的时间戳"，服务端返回比这个时间戳早的 N 条。优点：不会因新增数据漂移。这是 Feed 的事实标准。

按 ID 分页。和时间戳类似，但用消息 ID 作为游标。

混合分页。结合时间戳和 ID，处理同毫秒发布的多条。

测试维度：

分页正确性。

第一页加载、下拉刷新、上拉加载更多，三个动作返回的数据正确。

边界条件：第一页 0 条数据、不足一页、刚好一页、超过一页。

刷新与回顶。

下拉刷新加载新内容，断言新内容在最上面、旧内容保留、不重复。

回顶（点 Tab 或滚动按钮）后能否快速回到顶部并刷新。

新内容标识。下拉时如果有新内容，要不要展示"有 N 条新内容"的横幅提示。

无限滚动 vs 分页按钮。

无限滚动（Feed 流标配）。下拉到底自动加载下一页，要测加载状态、失败重试、到底提示。

分页按钮。某些场景（评论列表、动态详情）用按钮分页，测翻页、跳页、最后一页禁用。

回滚与历史。

用户点了一条动态进详情，返回 Feed 应回到原来的位置（不是回到顶部）。

刷新 Feed 后跳转再返回，行为是否一致。

特殊场景。

广告插入。Feed 中按规则插入广告，要测广告位置准确、广告不参与去重、广告点击行为正常。

视频自动播放。某些 Feed 会在视频条目滑到屏幕中央时自动播放，要测自动播放策略、滑出时停止、上下条切换的播放接续。

预加载。Feed 通常预加载下一屏的内容和图片，要测预加载策略和性能影响。

异常路径：

加载失败重试机制。

返回数据格式异常（字段缺失、类型不对）的容错。

长时间不刷新后再回来，已经过期了多久的内容（一般 24 小时以上）要给"重新刷新"提示。

测试方法上多用自动化 + 手工探索结合。自动化覆盖正向、边界、错误；手工探索找设计不合理的体验问题。

Q4: Feed 的排序策略有哪些？怎么测？

答案：

Feed 排序是产品策略的核心，从最简单的"时间倒序"到最复杂的"个性化推荐"，不同产品差异巨大。

主流排序策略：

时间倒序（Reverse Chronological）。最朴素的方案，按发布时间从新到旧。优点：直观、可预期。缺点：用户错过没及时刷的内容、活跃用户淹没不活跃用户。Twitter、微博早期都用。

热度排序（Hot）。按互动量（点赞、评论、转发）排序，热门内容先看到。适用于"广场式"产品（如 Reddit、虎扑）。

算法推荐（Algorithmic）。综合用户兴趣、行为相似度、内容质量等多因素排序。抖音、小红书、Twitter 现在都是这套。

混合排序。多种策略混合，比如"前 3 条算法推荐 + 接下来时间倒序"，或"主页用算法、关注页用时间"。

测试维度：

时间倒序测试。

时间精度。同秒发的多条动态怎么排（一般用 ID 或精度 ms 级时间戳）。

时区。跨时区用户看到的"现在时间"是否正确。

发布时间和展示时间。"5 分钟前"这种相对时间的渲染。

热度排序测试。

权重计算。点赞、评论、转发各占多少权重，要按规则验证。

时间衰减。热度随时间下降，老内容不能一直占榜。

榜单刷新频率。多久重排一次（一般几分钟）。

防刷。机器刷热度应被识别（详见 Q17）。

算法排序测试（详见 Q5、Q6）。是测试系统里最难的部分，重点测 A/B 实验、效果评估、降级兜底。

混合排序测试。

策略边界。前 3 条用算法、第 4 条开始时间倒序，要测过渡区域是否合理。

策略切换。用户主动切换排序方式（如"时间 / 热度 / 推荐"按钮），切换后内容立即更新。

策略灰度。新排序策略灰度发布，部分用户看到新版、部分看到旧版，要测灰度切流和 A/B 评估。

异常路径。

排序服务故障的降级。算法服务挂了降级到时间倒序，时间倒序也挂了降级到"系统精选内容"，最终都不能空白。

数据延迟。排序依赖的特征（用户兴趣、热度数据）延迟时，排序结果是否会异常波动。

实战中"用户为什么没看到某条动态"是产品最常见的投诉，测试同学要能用排序日志和用户行为日志快速定位"是没有这条""被排到很后""排序了但用户没下滑"哪一种原因。

二、推荐排序与 A/B 实验（5题）

Q5: 推荐系统怎么分层？每层怎么测？

答案：

现代推荐系统是个庞大的工程系统，从用户进入到看到推荐内容要经过几个阶段，每个阶段都有自己的测试关注点。

推荐分层（业界标准）：

召回（Recall）。从亿级内容池里选出几千个候选。多路召回是主流：用户兴趣召回、协同过滤召回、相似召回、热门召回、新内容召回等。

粗排（Pre-rank）。从几千个候选选出几百个，用轻量模型（LR、FM、轻量 DNN）快速打分。

精排（Fine-rank）。从几百个候选精排，用复杂模型（Wide&Deep、DIN、Transformer）输出几十个。

重排（Re-rank）。最后阶段做多样性、去重、广告插入、商业化调权等。

每层测试关注点：

召回测试。

召回完整性。给定用户特征，每路召回应返回预期范围的候选数（如兴趣召回 200 条、协同过滤 100 条）。

召回时延。每路召回响应时间（一般要求 P95 < 50ms），多路并行后总时延。

召回质量。召回的内容与用户兴趣的相关度，可建"金标准用户画像"测试集。

新内容召回。新发布内容多久能进召回池（一般几分钟到几小时）。

冷启动召回。新用户没有行为数据时的召回策略（一般用热门、地域热门、用户画像启动）。

粗排测试。

打分准确性。给定输入特征，模型输出分数应符合预期。

粗排速度。几千个候选打分时延（一般 P95 < 30ms）。

粗排和精排的一致性。粗排选出来的应该是精排打分较高的（否则精排白排）。

精排测试。

模型版本切换。新模型上线 vs 旧模型，结果差异分析。

特征质量。输入特征是否新鲜（用户实时行为应反映在特征里）、特征是否完整（不应大量缺失）。

精排时延。几百个候选打分时延（一般 P95 < 100ms）。

重排测试。

多样性。同一用户连续刷 50 条，品类、作者、内容类型不应过度集中。要测多样性指标（如品类熵）。

去重。同一作者的多条内容不应连续出现、用户看过的内容不应再次出现。

广告插入。按规则插入广告（如每 10 条插 1 条），要测插入位置、广告内容相关性。

业务规则。各种运营规则（推置顶内容、压制低质内容、保护新人内容）。

测试方法：

模拟用户。建一组"标准用户画像"（喜欢宠物、喜欢美食、新用户、活跃用户），跑推荐链路看输出是否合理。

回放测试。线上真实用户的请求日志在测试环境回放，对比新老版本的差异。

A/B 实验（详见 Q7）。新算法上线必须 A/B 实验，统计学显著后才全量。

线下指标。AUC、NDCG、Recall@K 等，用历史数据评估模型质量。

推荐系统的测试不是单一接口测试，是"用户体验"测试，需要建立完整评估体系（线下指标 + 线上 A/B + 用户调研三位一体）。

Q6: 推荐的多样性和冷启动怎么测？

答案：

多样性和冷启动是推荐系统的两大经典难题，做不好直接影响用户体验。

多样性问题。算法过度依赖"用户兴趣"会导致信息茧房，用户只看到同一类内容。要在"相关度"和"多样性"间平衡。

多样性维度：

品类多样性。50 条内容里美食占比不应超过 70%。

作者多样性。同一作者的内容不应连续超过 2 条。

内容形式多样性。图文、视频、直播应有合理比例。

时效性多样性。新内容（24 小时内）和优质老内容混合。

观点多样性。同一话题不同观点都呈现（如新闻 Feed）。

地域多样性。本地内容 + 异地热门内容混合。

测试方法：

指标计算。

品类熵。熵越高多样性越好。

Jaccard 相似度。相邻条目的相似度，越低越多样。

ILSD（Intra-List Similarity Diversity）。列表内平均相似度。

线下回归。每次算法升级都跑这些指标对比，不能下降。

人工评估。让人工浏览 50 条 Feed，主观打分（不重复、不无聊、有惊喜）。

冷启动问题。新用户没有行为数据，怎么推、推什么。

新用户冷启动策略：

注册时让用户选兴趣标签（"你感兴趣的话题"）。

基于地域、性别、年龄、手机型号等基础特征推荐。

启动时推热门内容（"今日热门"），看用户互动行为快速收集兴趣信号。

引入老用户行为做迁移（同 device id 之前的行为、同手机号之前的账号）。

新内容冷启动策略：

刚发布的内容没有互动数据，要主动"投流"给一批种子用户。

种子用户的反馈（点击、停留、互动）决定后续投流量级。

投流失败的内容会被快速淘汰，避免占用流量。

测试方法：

冷启动场景模拟。注册一个全新账号，按各种路径使用（直接浏览 vs 选兴趣后浏览），看推荐策略生效。

兴趣探测速度。从"全无兴趣"到"明显有偏好"的转变需要多久（一般 30 分钟内能看到变化）。

新内容投流。发布一条新内容，跟踪它的投流路径、覆盖用户数、互动反馈。

冷启动指标。

新用户次日留存（看冷启动有没有快速吸引到用户）。

新用户首次互动率。

新内容曝光率（新内容多快能获得初次曝光）。

实战中多样性和冷启动会持续优化，测试同学要参与指标定义、长期监控、A/B 评估，是推荐质量的长期保障者。

Q7: A/B 实验系统怎么测？

答案：

A/B 实验（Online Controlled Experiments）是推荐和产品迭代的核心工具。测试同学常常负责实验平台的质量保障和实验数据的可信性。

A/B 实验流程：

定义假设。"新推荐算法比旧的能提升 CTR 5%"。

分流。把用户随机分到对照组（旧算法）和实验组（新算法）。

收集数据。运行一段时间（一般 7~14 天）。

统计分析。计算两组指标差异、统计学显著性。

决策。显著且业务正向则全量推广，否则回滚。

测试维度：

分流准确性。

分流均匀。50% / 50% 实验时，两组用户特征分布应基本一致（年龄、地区、活跃度等），不能出现"实验组都是高活跃用户"这种偏差。

分流稳定。同一用户每次访问应分到同一组，不应反复切换。

分流隔离。多个实验同时跑互不干扰。每个实验有独立的分流规则。

灰度切换。实验流量比例可动态调整（1% → 10% → 50% → 100%）。

数据收集准确性。

指标埋点。所有关键行为（点击、播放、互动、留存）都要埋点上报，不丢不重。

实验归因。用户行为要正确归因到所属实验组，不能错算。

数据延迟。从行为发生到数据可分析的时延（一般 T+1）。

指标计算准确性。

基础指标。CTR、播放完成率、停留时长、留存率，每个都要单元测计算逻辑。

统计显著性。用 t 检验、卡方检验等统计方法判断差异是否显著（一般要求 p-value < 0.05）。

样本量。要保证实验时间和样本量足够（功效分析）。

异方差和分层。某些指标在不同用户群表现差异大（VIP 用户 vs 普通用户），要分层分析。

实验可信度：

A/A 测试。把同一算法分两组跑，理论上指标应无显著差异。如果有差异说明分流或指标有问题。每个新实验前都要做 A/A 验证。

新颖效应。用户对新功能本能感兴趣，刚上线时指标好看，几天后回落。要等"稳态"再做决策。

季节性。节假日、大促期间用户行为异常，实验最好避开。

实验冲突。多个实验同时跑互相影响，要测正交分流和实验隔离。

实验生命周期：

实验配置。能配置实验流量、目标用户、过滤规则、统计指标。

实验启停。能随时启动、暂停、终止、回滚。

实验数据看板。实时看实验指标，发现异常立即停止。

实验结果存档。所有历史实验的配置、数据、决策都存档。

线上事故响应：

实验组指标异常恶化（如 CTR 暴跌、错误率飙升）时能否秒级回滚。

异常告警机制（实验组指标偏离阈值时告警值班）。

A/B 实验是工程 + 统计 + 业务的综合，测试同学的核心价值是保证"实验数据可信"，否则团队基于错误结论做错误决策，损失远大于功能 Bug。

Q8: 热搜和热点系统怎么测？

答案：

热搜是社交产品的"晴雨表"，是用户感知最强、监管最严、商业价值最高的功能之一。技术上看似简单（统计热度排序），实际涉及实时计算、防刷、人工干预、合规审核多方面。

热搜计算流程：

数据采集。搜索量、点赞、评论、转发、阅读等行为实时上报。

实时聚合。按时间窗口（如最近 1 小时、最近 6 小时）聚合各内容/话题的热度分。

热度算法。一般 = 互动量 × 时间衰减系数 × 质量加权 - 反刷量。

排序与展示。按热度分排序，展示 Top N（如热搜 Top 50）。

人工干预。运营按规则置顶、压制、删除某些条目。

测试维度：

热度计算准确性。

权重正确。点赞 1 分、评论 2 分、转发 3 分这种权重要按配置准确执行。

时间衰减。1 小时前的互动应有更高权重，24 小时前的权重低。

新鲜度。最近 30 分钟突然上升的话题应快速涌现（"事件爆发"）。

实时性。

热度变化的延迟（一般要求 < 5 分钟）。

突发事件（明星结婚、灾难新闻）的反应速度。

热搜刷新频率（一般每 5~15 分钟刷新）。

排序稳定性。

不应剧烈波动（热搜每分钟都在变会让用户困惑）。

平滑过渡（话题热度上升/下降时排名应平滑变化）。

防刷与反作弊（详见 Q17）。

机器刷量识别（同一 IP 大量搜索）。

僵尸账号识别（注册后立即活跃）。

恶意热搜（黑产推热）。

人工干预。

置顶。运营手动置顶（如重要通知、紧急公告）。

下沉。压制低质或敏感话题。

删除。涉政涉黄等违规内容直接移除。

每种操作都要有权限校验、操作日志、生效时间、可回滚。

商业化热搜。

部分热搜是付费投放的（明星打榜、品牌活动），要测投放、计费、排序加权、用户体验（一般要有"广告"标识）。

合规与监管。

涉政热搜的处理（一般直接屏蔽并不留痕迹）。

敏感时段（重大会议期间）的限制策略。

监管要求的报送和审计。

特殊场景：

突发事件。地震、疫情、明星离世等突发事件，热搜要能秒级捕捉并展示。

事件持续。同一事件持续几天热度，要避免长期占榜。

事件演化。一个事件可能有多个相关话题（如疫情有"确诊数""新增地区""防控措施"等），要测话题聚合和分发。

测试方法：

模拟数据。用脚本模拟海量搜索、互动行为，看热搜变化是否符合预期。

回放历史。用真实历史热点数据回放，验证算法在不同场景下的表现。

实时监控。线上热搜变化大盘，发现异常立即告警和介入。

实战中"热搜事故"屡见不鲜（如重大新闻没上热搜、负面热搜被刷上去），每次事故都是测试体系的改进机会。

Q9: 信息流广告怎么测？

答案：

信息流广告是国内互联网最大的变现方式（抖音、快手、小红书、微博、知乎都是），融合了内容、推荐、广告、计费、风控。测试要覆盖整个变现链路。

广告业务链路：

广告主投放。客户在广告后台投放广告：定向人群、出价、预算、素材。

投放系统。广告进入候选池，等待被推荐到 Feed。

竞价分发（RTB）。用户刷 Feed 时实时竞价，价高者中标。

展示与点击。广告插入到 Feed，用户点击跳转。

转化追踪。用户点击后的行为（下载、注册、购买）归因到广告。

计费结算。按 CPC（点击）、CPM（千次曝光）、CPA（行动）等模式计费。

测试维度：

定向精准度。

人群定向。年龄、性别、地域、兴趣、行为定向是否生效。

排除定向。已购买过的用户不应再看到该广告。

设备定向。iOS / Android / 不同机型差异化投放。

时段定向。指定时段才投放。

竞价正确性。

竞价规则。第二高价计费（GSP）或一价计费（FPA）的算法正确。

底价。低于底价的广告不展示。

预算控制。当天预算用完后停止投放。

频次控制。同一用户每天看到同一广告不超过 N 次。

展示与点击。

广告位插入。按规则插入到 Feed（如每 10 条插 1 条），要测插入位置、密度、用户体验影响。

广告标识。要有"广告"标签（监管要求），不能伪装成普通内容。

点击跳转。点击后跳转到广告主的目标（落地页、APP 下载、电商商品）。

兼容性。各端（iOS、Android、H5）的广告渲染、跳转一致。

转化追踪。

归因模型。用户点击广告 → 下载 APP → 注册 → 购买，每一步归因到广告，要测归因准确性。

归因窗口。点击后多久内的行为算归因（一般 24 小时、7 天、30 天）。

去重。同一用户多次点击同一广告，归因只算一次。

防作弊（详见 Q17）。

机器刷点击（黑产帮广告主刷量赚钱）。

机器刷曝光（拉低 CTR 让广告下架）。

恶意点击（竞争对手刷点击耗预算）。

计费准确性。

每次点击/曝光按规则计费，金额正确。

预算消耗实时反馈给广告主。

计费数据可对账（广告主反馈数据 vs 平台数据）。

广告主后台测试。

投放配置。各种定向、出价、预算、素材的配置 UI 和保存。

数据看板。曝光、点击、CTR、CPA、ROI 等指标的实时展示和导出。

权限。多账号、子账号、代理商的权限管理。

合规：

广告法。"绝对""最好""国家级"等禁用词识别。

行业准入。医疗、金融、教育、保健品等敏感行业有专门资质要求。

未成年人保护。某些广告不投给未成年用户。

测试方法：

广告主视角测试。模拟广告主创建广告 → 投放 → 看数据 → 续费的完整链路。

平台视角测试。看广告分发链路、计费链路、风控链路。

用户视角测试。看到广告的体验、跳转流畅度、是否影响 Feed 体验。

广告测试是商业化的核心，资深测试同学的价值在于能从"广告主、平台、用户"三方视角全面保障。

三、互动、关系链与通知（5题）

Q10: 点赞、评论、收藏、转发的测试要点有什么不同？

答案：

四种互动看着简单，工程上每种有自己的存储模型、并发挑战、产品策略，测试关注点差异很大。

点赞测试要点：

幂等。同一用户重复点赞同一条内容应只生效一次（一般是"取消点赞"行为）。

实时性。点赞后所有用户看到的点赞数应秒级更新（一般通过本地乐观更新 + 服务端最终一致）。

聚合。海量点赞（万级、十万级）的展示常用"模糊数字"（10w+、100w+），要测各档显示规则。

性能。点赞操作不应阻塞用户行为（点赞失败也不应影响后续操作）。

防刷。同一用户高频点赞、机器点赞要识别。

评论测试要点：

层级。一级评论 + 回复（二级评论），有些产品三级（盖楼，如网易云音乐）。要测层级展示、回复关系、删除时子评论的处理。

排序。最新、最热、按楼层、按时间分桶。

@和回复。@某人能否给对方推送通知、@到不存在的用户的兜底。

权限。仅作者能删自己评论、博主能删任意评论、管理员能删全部。

敏感词。评论内容要过审，违规自动屏蔽并通知发布者。

折叠。低质评论、违规评论自动折叠或隐藏。

收藏测试要点：

收藏夹。是否支持多个收藏夹、收藏夹的增删改、收藏夹的分享。

收藏状态。已收藏 vs 未收藏的状态显示要准。

排序。按收藏时间、按内容时间、按自定义排序。

取消收藏。从收藏列表里看的内容被取消后，已经查看过的本地缓存如何处理。

权限。私密收藏夹仅自己可见、公开收藏夹他人可见但不能修改。

转发测试要点：

转发类型。

原创转发（再创作，加自己评论）。

直接转发（一键转发到自己主页）。

跨平台分享（分享到微信、QQ、其他 APP）。

引用关系。转发链是否能追溯到原作者、原作者删除后转发链如何处理。

权限。原作者设置"禁止转发"时不能转发；转发后能否在转发者主页删除。

数据归属。转发的曝光、互动归原作者还是转发者，按业务规则。

跨平台。分享到微信时的卡片样式、跳转回 APP 的链路、对方未安装 APP 的兜底。

并发与一致性：

四种互动都涉及"计数器"，常用 Redis 自增 + 异步写 DB。要测：

并发自增不丢数据。

Redis 与 DB 最终一致（详见 24-Q14）。

计数器值过大（几亿点赞）的存储和展示。

测试时建议每类互动建独立的回归用例集，覆盖正向、并发、异常、权限、跨端各场景。

Q11: @、私信和通知系统怎么测？

答案：

通知系统是社交产品的"血管"，把"用户行为"转化为"对方感知"，做不好用户会错过重要互动或被骚扰。

@功能测试：

@提示。输入 @ 后弹出好友列表/最近联系人，要测搜索、模糊匹配、滚动加载。

@权限。被 @的人能否看到（一般好友、关注、陌生人有不同策略）。@陌生人是否会触发反骚扰策略。

@通知。被 @的人收到通知，要测推送时机、推送内容、点击跳转到对应位置。

@撤销。撤回带 @的内容时，对应通知应消失或标记"已撤回"。

@格式。@后面的用户名展示为高亮 + 可点击。

私信测试：

陌生人私信。陌生人发私信的策略（默认免打扰 / 验证消息 / 直接接收）。

私信会话。多轮对话、消息撤回、已读未读、富媒体消息（类似 IM 系统，详见 25 章）。

私信权限。被对方拉黑、关闭私信、对方注销账号后的体验。

私信安全。敏感词过滤、诈骗识别、举报机制。

通知中心测试：

分类展示。互动通知（点赞、评论、@）、关注通知、私信、系统通知分类展示。

未读管理。按分类计数、跨端同步、清零规则。

通知聚合。同一类多条通知聚合显示（"5 个人赞了你"），要测聚合规则、点击展开、不聚合的特殊场景。

历史。通知保留多久（一般 30 天 ~ 1 年），过期自动清理。

通知触达：

APP 内消息。打开 APP 立即看到。

推送通道。

前台：APP 内 banner / toast。

后台：厂商通道（华为、小米、OPPO、APNs 等，详见 25 章）。

精细化：

频次控制。同一用户每日推送上限、相同类型推送合并。

时段控制。免打扰时段（22:00 ~ 08:00）不推送。

用户偏好。用户可配置哪些类型推送、推送方式。

A/B 实验。推送文案、推送时机、推送密度的 A/B 优化。

合规：

不能滥发。监管和苹果/Google 都对推送有限制，违规会被下架。

明确触达目的。每条推送要让用户能明确知道为什么收到。

可关闭。用户能在 APP 内或系统设置关闭推送。

通知系统是社交产品体验的"双刃剑"，做好了拉活，做不好用户卸载。测试同学要在频次、内容、时机三个维度精细把控。

Q12: 关注关系和粉丝列表怎么测？

答案：

关注关系是社交系统的"图结构"基础，所有 Feed、推荐、通知都依赖关注图谱。测试时要把关系链当作独立的领域来覆盖。

关系类型：

单向关注（关注）。如 Twitter、微博，A 关注 B 不需要 B 同意。

双向好友（互关）。需要双方都关注对方（A 关注 B + B 关注 A）才形成好友关系。

特别关注。在普通关注上加额外标记，对方发动态优先看到、提醒。

互相关注。系统自动识别"我关注的人也关注我"，标记为互关。

私密关注。关注对方但对方看不到我是粉丝（如微博的"悄悄关注"）。

测试维度：

关注与取关。

关注成功后立即生效，关注列表新增一条。

取关后立即从关注列表移除，对方粉丝列表减少。

关注/取关的频率限制（防恶意刷粉）。

并发关注。同时点击关注按钮多次只生效一次（幂等）。

关注上限。普通用户一般 2000 ~ 5000 个关注上限，VIP 用户上限更高。

粉丝列表。

排序。一般按关注时间倒序，也可按互动密切度。

分页加载，万粉丝以上的列表分页效率。

筛选。按特别关注、互关、新粉丝等过滤。

权限。

私密账号。陌生人申请关注需要审批，未审批的不能看到内容。

黑名单。被拉黑后无法关注对方、无法看对方内容、无法私信。

地区限制。某些国家/地区互关受限制。

关注衍生功能。

关注用户的内容自动出现在主页 Feed。

特别关注的人发动态强提醒（推送 + 红点）。

关注互动统计（你和 TA 互相点赞了多少次）。

异常路径。

注销账号。被关注的账号注销后，关注关系如何处理（一般保留以备恢复，但不展示）。

被封禁。封禁用户的关注关系是否生效（一般保留但内容不可见）。

数据迁移。批量导入关注关系（如新用户从旧账号迁移），要测数据一致性。

技术挑战：

百万级粉丝。明星账号粉丝几千万，查询性能要专门优化。

实时性。关注/取关后多久同步到所有依赖方（Feed、推荐、通知）。

大 V 扇出。详见 Q1，大 V 发动态如何扇出几千万粉丝。

关注关系的图谱也用作反作弊（详见 Q17）。异常关注模式（一夜涨百万粉、关注大量僵尸账号）是黑产典型特征。

Q13: 黑名单、屏蔽和免打扰怎么测？

答案：

这三个功能看着小但实际复杂，因为涉及"用户如何屏蔽信息"，每个细节都影响用户体验和产品口碑。

黑名单（拉黑）测试：

拉黑后果（一般规则）。

被拉黑用户不能看到我的动态、评论、点赞。

被拉黑用户不能给我发私信、@我、评论我。

被拉黑用户不能关注我；如果已经关注，关系应解除。

被拉黑用户不能搜索到我的账号（部分产品支持）。

我能否看到被拉黑用户的内容（一般保留可见性，由产品策略定）。

互相拉黑。A 拉黑 B、B 也拉黑 A 时双方互不可见。

拉黑解除。能恢复但历史互动不会重新出现。

边界场景。

被拉黑用户的旧评论是否保留（一般保留并显示"已被屏蔽"）。

被拉黑用户的旧点赞是否保留。

被拉黑用户在我关注的人的动态下的评论我是否能看到。

群聊中拉黑某人，群消息中此人发言我是否能看到。

屏蔽（不感兴趣 / 不想看到）：

屏蔽用户。不想看到这个用户的内容，但不需要彻底断绝（不像拉黑）。屏蔽后此人内容不出现在我的 Feed 和推荐，但搜索、关注关系不受影响。

屏蔽话题。不想看到某个话题，相关内容自动过滤。

屏蔽内容类型。如不想看到广告、政治内容、负面新闻。

屏蔽关键词。包含特定关键词的内容自动隐藏。

屏蔽策略测试：

生效范围。Feed、推荐、搜索、通知、私信，每个场景的屏蔽生效。

生效时间。设置屏蔽后多久能完全生效（一般立即，但底层缓存可能有几秒延迟）。

可撤销。屏蔽后能否随时取消。

举报联动。多人屏蔽某内容时是否自动降权或触发审核。

免打扰测试：

时段免打扰。设置 22:00 ~ 08:00 不接收推送，要测：

跨日时段（22:00 ~ 次日 08:00）的处理。

时区变更后是否按新时区。

紧急通知是否例外（如安全告警）。

分类免打扰。可以单独关闭点赞通知、评论通知、关注通知等，但保留私信。

会话免打扰。某个特定群或某个特定人的私信免打扰。

智能免打扰。如开会时段自动免打扰（接入日历）。

权限和审计：

操作日志。所有拉黑、屏蔽、解除操作都有日志，便于追溯和分析（特别是企业 IM 的合规要求）。

权限。账号被封禁时其设置的拉黑/屏蔽是否仍生效。

测试方法上常用"双账号互测"，A 账号操作、B 账号验证效果，覆盖各类生效范围。

Q14: 话题、超话和群组怎么测？

答案：

话题（Topic / Hashtag）、超话（微博特有，话题升级版）、群组都是"内容聚合"机制，把零散的内容按主题组织起来。

话题测试：

话题创建。

用户在内容中加 #话题# 标记，是否自动创建话题。

话题命名规则（不能太长、不能特殊字符、不能重名）。

话题审核（敏感话题自动拒绝创建）。

话题聚合。

带同一话题的内容自动归类到话题页。

聚合时延（新发的话题内容多久能进话题页）。

排序（按时间、按热度、按互动）。

话题搜索。

按话题名搜索，模糊匹配、热门话题优先。

搜索关键词命中话题名时优先展示话题。

话题展示。

话题热度（参与人数、内容数、阅读量）。

话题描述（部分话题有官方介绍）。

话题相关推荐（看完一个话题推相似话题）。

超话测试（微博特有，进阶版话题）：

主持人机制。每个超话有主持人和小主持人，权限：管理内容、删帖、置顶、签到管理。

签到。用户每天可签到，签到累积影响超话排名。

等级。基于签到、发帖、互动的等级系统，等级影响权限。

商业化。粉丝团付费加入、专属表情包、超话广告。

群组测试（如 QQ 群、微信群、微博群、超话群）：

创建。普通用户能创建多少群、群成员上限。

管理。

群主、管理员、普通成员的权限差异。

加入审批（开放群直接加、私密群需审批）。

踢出、禁言、解散。

群消息。

类似 IM 消息系统（详见 25 章），但需考虑群规模、消息密度。

群公告、群规、群相册等增强功能。

群发现。

按兴趣、地域、好友推荐群。

热门群榜单。

群分类目录。

商业化。

付费群（用户付费加入）。

群打赏、群红包。

合规。

群内容审核（违规内容连坐处罚群主、解散群）。

涉政、涉黄、传销等违法群的识别和封禁。

群主实名（监管要求）。

测试场景：

万人群消息分发（详见 IM 章节，但话题/超话场景可能上百万参与者）。

千万阅读量话题的浏览体验。

热点话题瞬时涌入（明星结婚突然涌入几百万参与）的稳定性。

测试时要把话题/超话/群组当成独立产品维度，建立专门的回归集。

四、内容安全、防作弊与监控（4题）

Q15: 社交内容审核怎么测？

答案：

社交内容审核是国内监管最严的领域之一，每天有海量 UGC 内容（文字、图片、视频、音频）涌入，必须建立分级审核体系。

审核分级：

事前审核。某些类型内容（如视频、直播预告、敏感话题）发布前必须过审才能展示。审核延迟一般几分钟到几小时。

实时审核。多数内容（文字、点赞、评论）实时审核，毫秒级判断是否放行。

事后审核。已经展示的内容定期回查，违规内容下架并处罚。

人工抽审。机审通过的内容按比例（一般 1%~5%）抽样人审，发现机审漏过的违规。

审核内容类型：

文本。涉政、涉黄、违法、广告、辱骂、敏感词。

图片。涉黄、涉政、暴力、Logo（盗用品牌）、二维码（外链广告）、文字内容（图片里的字也要识别）。

视频。逐帧识别，覆盖图像维度 + 音频维度（详见直播章节 27-Q15）。

音频。语音转文字后做文本审核 + 直接的音频特征识别（如喊话声、敏感音乐）。

链接。检查链接指向的网站是否违规（钓鱼、诈骗、违禁品）。

测试维度：

机审准确率。

真阳率（违规被识别）。建立各类违规样本库，每月跑回归看真阳率。

误判率（正常被错判）。建立白样本库（真实合规内容），测误判率，过高会引发投诉。

机审覆盖率。

各类内容（图、文、音、视频、链接）都覆盖。

跨语言（中文 + 英文 + 方言 + 少数民族语言）。

变形识别（敏感词的同音、谐音、繁简、火星文变体，详见 IM 章节 25-Q16）。

人审流程。

人审队列优先级（高粉丝主播、热门内容、突发事件优先）。

人审决策一致性（同一内容多人审核的判断一致性）。

人审 SLA（一般要求 < 30 分钟出结果）。

处罚梯度（详见 27-Q14）。

警告 → 限流 → 封号 → 永久禁言 → 设备封禁。

申诉流程。

误判申诉的提交、审核、反馈流程。

申诉成功后内容恢复、处罚撤销、信用恢复。

监管联动。

违规事件按要求报送公安、网信办。

国家级专项行动（如"清朗行动"）的特殊审核加强。

监管巡检的数据导出和留存（最少 6 个月，部分 10 年）。

测试方法：

样本库测试。建立标准的违规/合规样本库，每次审核策略更新后跑回归。

红蓝对抗。专门组织红队尝试规避审核（用变体、谐音、图片掩盖、隐喻），蓝队改进识别规则。

线上巡检。每日扫描审核日志，发现异常告警（如某类违规突然激增、机审误判率上升）。

监管演练。模拟监管突击检查，验证数据可追溯性、响应时效。

内容审核做得好可以避免平台级事故，做得差是平台关停的直接原因。测试同学要把内容审核当作 P0 级保障来做。

Q16: 敏感词识别和变形对抗测试

答案：

敏感词识别是内容审核最基础也最有挑战的部分。看似简单（关键词匹配），实际要面对各种变形规避。

敏感词分类：

涉政。政治人物、政治事件、敏感时段。

涉黄。色情、低俗。

违法。诈骗、毒品、赌博、传销、非法交易。

辱骂。脏话、人身攻击。

广告。微商、外链、违规营销。

特殊行业敏感词。

医疗：处方药、疗效承诺、虚假宣传。

金融：违规理财、非法集资。

教育：虚假学历、应试内容。

变形对抗（黑产规避手段）：

同音字。"杜博"代替"赌博"，"涉黄"代替"涉黄"。

谐音字。"渣男"用拼音 ZN 代替。

繁简变换。"國家"vs"国家"。

特殊符号。"赌·博"中间加点。

火星文。"莻黴"等非常规字符。

英文混拼。"DUbo"。

emoji 代替。用 emoji 拼出违禁词。

图片化。把违禁词写在图片里，文本审核拦不住。

测试维度：

基础词识别。每个敏感词的命中率，标准词全部应被识别。

变形识别能力。

建立"变形规则生成器"，自动从标准词生成各种变形。

测试时给系统输入各种变形，看识别率。

上下文识别。

"自杀"在心理咨询群是正常话题，在攻击性发言里是违规。

需要结合上下文语义判断，传统关键词匹配不够，要用 NLP 模型。

误伤率。

测合规内容里包含敏感词的场景（如新闻报道犯罪事件、医学讨论疾病），不应被错杀。

误伤率高是用户投诉的主要来源。

处理策略。

直接屏蔽（消息不发出）。

替换为 *（敏感字打码后发出）。

警告但允许（提醒用户敏感）。

人工审核（高风险词进队列）。

封禁（高频违规直接封号）。

每种策略的触发条件和效果要测试。

词库管理：

敏感词分级。

L0：必拦（涉政高敏感）。

L1：高敏感（涉黄、违法）。

L2：中敏感（辱骂、广告）。

L3：低敏感（轻度敏感词）。

不同级别对应不同处理策略。

词库更新。

热点事件后快速增词（如某新闻人物涉案）。

变更同步到所有审核节点的时效。

词库版本管理和回滚。

灰度发布。新增词先灰度，避免大规模误伤。

测试方法：

样本对抗。维护一份"变形样本库"，每次词库更新后跑回归。

红蓝对抗。红队不断发明新变形，蓝队改进识别。

线上巡检。监控敏感词命中率、误判率、新出现的可疑词，及时入库。

模型监控。NLP 模型的精度、召回、F1 指标，发现下降立即重训。

敏感词测试是内容审核的"地板能力"，做不好就是基础失守。测试同学要把它当成长期对抗工作，建立持续迭代的机制。

Q17: 防刷、防机器人测试要做哪些？

答案：

社交产品是黑灰产高发战场：刷量、刷粉、刷热搜、刷评论、刷点赞、网络水军、机器人账号。反作弊能力是产品口碑和商业化收入的生命线。

常见作弊手段：

机器刷量。用脚本模拟用户行为，刷粉、刷赞、刷评论、刷阅读、刷热搜。

群控。一台主控机控制几十台手机/模拟器，规模化操作。

改机。用改机软件伪造设备 ID、IMEI、IP、地理位置，让一台设备伪装成 N 台。

养号。注册大量账号后慢慢"养"（少量正常行为），然后批量用于刷量或洗钱。

水军。雇用真人在指定话题下发言、互动，因为是真人行为难以识别。

接码平台。用临时手机号注册账号，避开手机号绑定限制。

防御维度：

设备指纹。

唯一性。同一设备多次启动 ID 一致；多次清缓存、重装 APP 后能否识别同一设备。

抗改。改机软件下能否识别异常。

跨平台一致。iOS / Android 各有自己的指纹技术（iOS 限制较严）。

行为分析。

操作速度。人眼不可能 100ms 内连续点击几次。

时间模式。半夜 3 点高频活跃可疑。

滑动轨迹。机器滑动是直线，人是曲线。

输入规律。机器打字速度恒定，人有快慢变化。

社交图谱。

新账号社交结构。机器账号关注的都是大 V 或互关账号，社交图谱不真实。

异常关注模式。短时间内关注几百人、被关注几千次。

互动模式。互动只在固定时段、固定对象。

账号画像。

注册渠道。同 IP、同设备的批量注册可疑。

养号特征。注册后空白期太长、突然活跃。

行为多样性。只点赞不评论、只发文不互动，模式单一。

测试维度：

识别准确率。

真阳率（机器/黑产被识别）。建立"已知黑样本库"，覆盖各种作弊手段。

误伤率（真人被错判）。建立"白样本库"（真实用户行为），过高会引发投诉。

实时性。

识别延迟。理想是请求到达瞬间判断，最多几十毫秒。

风控规则生效。新规则发布后多久全网生效。

风控规则。

规则配置。配置后台的规则增删改查、上下线、灰度。

规则组合。多个规则同时触发的优先级和综合判定。

规则可解释。被识别的用户能看到大致原因（不是黑盒）。

二次验证。

中风险用户触发二次验证：验证码、人脸识别、短信。

每种验证方式的成功率和绕过率。

绕过验证的处罚机制。

申诉流程。

误判用户的申诉路径。

申诉的人工审核效率。

申诉成功后处罚撤销。

线上对抗：

红蓝对抗。每月组织红队尝试新作弊手段，蓝队改进规则，是长期对抗。

线上巡检。

关键指标（新增账号、刷量比例、可疑互动）的实时监控。

异常波动（如某地区新增 100x、某时段刷量比例飙升）告警。

数据可视化。反作弊大盘展示拦截量、识别量、误伤量等关键指标。

效果评估：

NPS（用户体验影响）。误伤太多会伤害真用户。

商业价值（节省的广告费、节省的运营成本）。

监管合规（防止平台被滥用）。

反作弊是社交平台的"军备竞赛"，资深测试同学的核心价值是建立"识别 + 评估 + 改进"的对抗闭环。

Q18: 社交产品的核心数据指标和监控大盘怎么测？

答案：

社交产品的运营高度数据驱动，每天看几十个核心指标，数据看板的准确性直接关系到产品决策的正确性。测试同学经常负责保障数据的可信度。

核心数据指标分类：

用户指标。

DAU / MAU。日活、月活，最核心指标。

新增。新注册用户数。

留存。次日留存、7 日留存、30 日留存（用户黏性）。

流失。一段时间内未活跃的用户。

回流。流失后再次活跃的用户。

用户分层（新用户、活跃用户、沉默用户、流失用户）。

内容指标。

UGC 生产量。每天发布的动态、视频、评论数。

内容质量。平均互动率、举报率、违规率。

内容分发。曝光量、点击量、CTR。

爆款率。互动量超过阈值的内容占比。

互动指标。

互动率。点赞率、评论率、转发率、收藏率。

回访率。用户多次回到 APP 的频率。

时长。平均使用时长。

打开次数。平均每日打开 APP 次数。

商业指标。

广告收入。每千次曝光收入（eCPM）、广告收入趋势。

电商 GMV（直播带货、社区电商）。

会员收入。

留存价值（LTV）。

技术指标。

性能。接口 RT、错误率、CPU/内存。

稳定性。崩溃率、ANR 率（Android）、卡死率。

测试维度：

指标计算准确性。

公式正确。每个指标的计算公式（如"互动率 = 互动数 / 曝光数"）实现要严格按照定义。

数据源准确。从哪些埋点取数、数据延迟、丢失率。

去重和归因。同一用户多次行为如何聚合、行为归因到内容/广告/事件。

埋点测试。

覆盖度。所有需要的事件都埋点，不漏。

正确性。事件名、参数、时机准确。

时效性。从行为发生到数据可用的延迟。

数据一致性。

跨大盘一致。同一指标在不同看板（产品看板、运营看板、技术看板）数值应一致。

跨工具一致。自家埋点系统 vs 第三方分析工具（GrowingIO、神策）的数据应一致或差异可解释。

历史可重算。任何指标都能基于原始日志重新计算，不能"现在看是这个值，明天就变了"。

异常监测。

阈值告警。指标突破阈值（如 DAU 突然下降 5%）告警。

异常检测。机器学习的异常检测，发现非阈值突破的异常模式（如某地区 DAU 异常下降）。

数据安全。

权限。看板访问权限分级，敏感数据（财务、用户隐私）仅授权人员可见。

脱敏。展示数据时按规则脱敏，不暴露原始 PII。

审计。数据查询和导出的日志，便于追溯。

测试方法：

数据回归。每次新版本发布后重新计算关键历史日的数据，确认未变化。

对账。和第三方数据源（如苹果/Google 后台、广告平台）对账，验证数据准确。

人工抽查。运营同学手工抽样几个用户/内容，对照 APP 实际行为验证数据。

A/B 实验。实验组数据收集的隔离性和准确性（详见 Q7）。

实战中数据指标"看着对实际错"是常见隐患（如埋点漏埋、归因错误、计算公式过时）。测试同学要把数据看板当作"产品"来对待，建立专门的回归用例和定期对账机制。