1. 从这份试卷反推搜狐社交中心的岗位画像先说个可能和很多人预期不太一样的事实一份校招笔试卷子真正考的不是你已经会了什么而是你有没有可能在入职之后快速学会那些东西。搜狐2018秋招第二批社交中心的测试工程师试卷放在今天复盘依然是测试岗笔试题里很典型的样本——它考的是一整套测试思维 计算机基础 业务理解的综合能力而不是单纯背概念、刷题库。我当年带过好几个校招进来的测试工程师面试的时候技术栈背得滚瓜烂熟一到实际业务场景就抓瞎。反过来也见过一些看起来基础一般的候选人却在笔试里拿到了高分——原因很简单他们知道怎么把抽象的问题转化成可执行、可验证的测试步骤这种能力在社交产品这种重交互、重实时、重体验的业务里比多背几个API名称重要得多。所以在正式开始拆解这份试卷的考点之前有必要先搞清楚一个问题搜狐社交中心当时到底在做什么业务测试工程师进去之后要面对的是什么搜狐的社交业务线核心是狐友这类移动社交产品。这类产品有几个逃不开的技术特点第一消息系统要求高实时性弱网环境、消息乱序、离线推送都是日常第二社交关系链天然复杂好友、关注、粉丝、分组、拉黑、屏蔽各种状态互相交叉第三内容是UGC用户生成内容审核、反垃圾、推荐策略都需要持续迭代。再加上搜狐本身的媒体基因社交产品还经常带着明星账号入驻、活动运营、热点话题这类运营属性极强的功能。这样的业务场景决定了测试工程师的工作远不止点点点。你需要懂TCP/UDP的差异才能判断消息推送在弱网下为什么会丢你得有HTTP协议的基本功才能定位接口返回的数据为什么和预期不一致你得具备数据结构和算法的基础才能设计出覆盖边界条件的测试用例——比如一个用户关注列表上限是5000人那4999、5000、5001这三个边界值对应的测试数据怎么构造这份试卷考的就是这些。它不是一份用来筛选书呆子的卷子而是一份用来判断你能不能在这个岗位的日常挑战中活下来的卷子。接下来我按照试卷典型的题型分布逐个拆解它想考察的能力和你应该怎么应对。2. 测试理论题不是背概念是看你会不会翻译2.1 测试用例设计方法笔试里最隐蔽的送分题测试理论这块笔试试卷里最常出现的题目类型之一就是针对某个功能设计测试用例。很多人一看这题就懵因为题目给的功能描述往往只有一两句话比如设计一个登录功能的测试用例。你如果真的只写了输入正确的用户名和密码点击登录验证能登录成功那这题基本就废了。这类题真正想考察的是你有没有一套结构化的用例设计方法论。我在这类题目上总结了一套固定的答题框架先功能后异常再边界最后体验。所谓先功能指的是覆盖功能的所有正常分支。登录这个功能正常分支就包括正确用户名正确密码、正确用户名错误密码、不存在的用户名、空用户名、空密码。每个分支都要单独建一条用例。后异常覆盖的是系统在异常情况下的表现。比如连续输错5次密码会不会触发锁定锁定的时长是多少锁定期间尝试登录会有什么提示如果系统正在维护登录页面怎么显示服务器返回500错误时用户看到的是友好的提示还是白屏再边界用的是边界值分析法。用户名长度限制是多少有的系统用户名最长16个字符那15、16、17就是三个边界值密码做不做长度下限校验有的系统要求至少8位那7、8、9也是边界。这些边界值测试列出来能大量暴露开发在校验逻辑上的疏漏。最后体验是我常提醒候选人的加分项。密码框是否支持明文切换显示输入密码时有没有大小写锁定提示登录成功后的跳转逻辑是否合理这些不具备明确的对错标准但能体现你对用户体验的敏感度这在社交产品测试里非常关键。2.2 黑盒、白盒与灰度发布别只答定义要说使用场景笔试里大概率会考到黑盒测试和白盒测试的区别以及各自的适用场景。这个概念简单但我见过太多人答得干巴巴的——黑盒测试是不知道内部实现只看输入输出白盒测试是知道内部实现针对代码逻辑写测试。定义没问题但如果你想拿到高分必须多说一层在社交中心的实际工作中这两种测试方法分别用在哪些环节。我的理解是黑盒测试是测试工程师的日常主体。功能测试、接口测试、端到端测试绝大部分都是从用户视角和外部接口视角去验证产品行为符合预期。而白盒测试往往发生在两个场景一是代码评审阶段测试工程师review开发提交的代码变更判断改动可能影响哪些既有功能从而补充回归测试范围二是配合开发做单元测试覆盖率分析确保核心模块的底层逻辑真的被测到了。比黑盒白盒更容易被忽略的是灰度发布。社交产品几乎不可能做到所有用户一次性上线新版本因为一旦有严重bug影响面就是全量用户。所以测试工程师必须理解灰度发布策略先让内部员工用再放5%的流量没问题了逐步扩大到20%、50%最后全量。笔试如果考到新版本上线你需要注意什么灰度发布和版本回滚方案一定要写上这能体现你有真实的线上发布经验意识。2.3 缺陷生命周期一个表格胜过三段描述关于缺陷管理笔试常见的考法是给你一个缺陷报告模板让你填写或者让你描述一个Bug从发现到关闭的完整流程。这类题最大的坑在于很多人把流程描述得过于理想化——开发修复→测试验证→关闭完全没考虑到实际协作中的复杂情况。我的建议是回复这种题首选结构化表达我一般会先在纸上快速画出状态流转的逻辑New新建→Open打开→Fix修复→Verify验证→Closed关闭同时每个状态都要考虑分支。开发填无法复现怎么办转为Rejected测试重新补充复现步骤如果还是无法复现打回给开发一起排查开发说不是bug是功能设计如此怎么办需要产品经理介入确认修复版本上线后又复现了怎么办Bug重新打开而且要优先处理因为这意味着第一轮修复没有覆盖到根因。我做了个小表格来记录这些信息笔试现场不一定有时间画表但答题思路必须清晰缺陷状态状态含义触发角色常见去向New缺陷已提交测试工程师经确认后转Open或转RejectedOpen缺陷被承认待处理开发工程师修复中转Fix或延后处理Fix缺陷已修复开发工程师提测后转VerifyVerify缺陷待验证测试工程师验证通过转Closed未通过重新OpenRejected拒绝处理开发工程师补充说明后测试确认或升级讨论Closed已关闭测试工程师回归测试中复现则重新OpenReopen重新打开测试工程师验证失败后激活缺陷管理题其实考的是你做事的闭环意识。社交产品功能迭代快bug数量多如果你不能把每个缺陷的状态管理清楚漏测、误判、上线事故都是早晚的事。3. 社交业务场景题测试用例设计的高阶战场3.1 好友关注功能一上来就考你的全链路思维社交中心的笔试几乎必考的一道题是好友/关注相关的测试用例设计。这道题我见过太多次了题目形式一般是请针对微信好友添加功能设计完整的测试用例或者现在有一个关注功能A关注B后B会收到通知请设计测试用例。这类题考察的不是你能不能列出一堆用例而是你的用例有没有层级、有没有闭环、有没有考虑到业务特有的边界。以用户A关注用户B为例一个合格的设计思路应该包含下面几层功能层A点击关注按钮后A的关注列表出现BB的粉丝列表出现AB收到你有一个新粉丝的通知A的按钮状态从关注变为已关注。这只是最基础的正常路径你在笔试里只写这些是拿不到高分的。交互层A和B已经是互关状态时A再操作会怎么样有的产品是隐藏关注按钮有的产品是显示互相关注标签但不可点击。A取消关注后再重新关注BB会不会收到两条通知如果会这算bug还是产品预期B拉黑了A之后A还能不能关注B关注后对话是否会被B看到这一层考的是你对社交产品业务规则的理解拉黑和关注之间的状态组合是最容易出边界bug的地方。系统层A关注B的同时B也关注A两个请求并发到达服务器最终的关系状态应该是什么关注接口在弱网环境下点击两次客户端要做防止重复提交的处理那么测试用例怎么验证这个防重逻辑是生效的B删除账号后A的关注列表里B还在不在如果还在点击B的头像会跳到哪里B注销后重新注册A的关注关系还会恢复吗数据层关注按钮的埋点事件是否上报关注成功的记录在服务端和客户端是否一致B不在线时收到关注通知下次登录后通知角标和列表是否正确展示你看一个简单的关注功能从功能层展开到数据层至少能写出40到50条有区分度的用例。笔试的时候只要你能覆盖到交互层和系统层就已经超过大多数候选人了。3.2 消息收发场景高并发的实时性验证社交产品笔试里另一类高频场景题是消息相关比如设计一个单聊功能的测试用例或者如何验证消息推送的可靠性。这类题对于没有做过实时通信测试的同学来说很容易踩坑——因为它的核心难点不在界面操作而在网络异常和服务端逻辑。先说最基础的功能用例A给B发一条文本消息B在线且处于聊天窗口B应该立即看到消息且不出现重复或乱序B离线消息以通知形式推送B点开通知进入会话页能看到历史记录A发送消息后网络突然断开界面应该提示发送失败并提供重发按钮重发成功后消息不能重复展示。这些写完进阶的用例就需要考虑实时通信的专有问题了。消息到达的顺序性A快速发出5条消息B客户端收到的顺序是否保证和发送顺序一致如果有一条消息发送失败剩余的消息是怎么展示的是插入失败标记还是照常展示消息的幂等性A重发同一内容B会不会收到两条一模一样的消息这条其实很考验服务端的去重逻辑。再往深挖一步弱网和异常场景对消息类功能来说几乎是无底洞。电梯里信号不稳定、地铁隧道里断网、手机飞行模式切换回蜂窝网络这些场景下消息发送会有哪些表现延迟消息到达之后如果消息体长度超限比如发了一段超长文本或者一串异常字符客户端会不会崩溃语音消息和图片消息在弱网下的上传进度展示是否准确这些用例如果没有真实的弱网测试环境去验证笔试阶段凭借逻辑推导写出来反而是加分项。注意消息类用例不要只写打开聊天窗口输入文字发送这种儿童级用例一定要围绕实时性、可靠性、顺序性、幂等性这四个维度去展开这是面试官阅卷时的核心打分点。3.3 信息流与推荐内容测试的独特挑战搜狐的社交产品里信息流的比重很大所以笔试也会出现如何测试信息流列表这类场景题。信息流测试和功能测试最大的区别在于它没有一个绝对的正确结果你没法断言这条内容必须出现在这个位置你验证的是推荐策略是否符合预期逻辑。这种情况下测试用例的写法要跟着策略走。比如信息流有一条规则是新发布的内容有更高概率出现在顶部那用例就验证用户B发布一条新内容后用户A下拉刷新B的新内容是否在较前位置如果B是A的特别关注对象B的内容是否被优先展示同一设备上连续刷新的内容是否出现大量重复。信息流测试里还有一个经典考点分页加载。向上滑加载第2页、第3页时数据会不会重复快速滑动到第20页时会不会出现内存溢出列表中的图片加载失败时占位图是否显示正常滑到列表底部时是否在提示没有更多内容的同时正确触发加载更多很多没有内容产品测试经验的候选人会在这类题上失分因为他们仍然在用功能测试的思维去套只写验证字段是否正确展示。而真正做过信息流测试的人都明白这个模块的难点在数据一致性列表数据和服务端数据是否同步、性能表现滑动流畅度、内存占用和策略验证推荐逻辑是否符合运营规则三个维度上。能围绕这三个维度展开写才算踩到了这类题的高分区间。4. 计算机基础笔试社交产品测试的底层功力4.1 数据结构与算法不考手写红黑树但考逻辑搜狐社交中心的测试工程师笔试卷计算机基础部分的难度不会特别高出现手写快速排序或者二叉树遍历的概率不大但数据结构的基础概念和算法思维一定会涉及到。毕竟测试工程师日常要理解代码逻辑、设计测试数据、分析问题根因数据结构的基础打不扎实后来会很吃力。我建议复习的重点在几个最实用的方向数组和链表的区别以及它们在不同场景下的增删改查效率栈和队列在消息系统里的应用——实际上消息队列本身就是一个经典的应用场景测试工程师理解了队列的先进先出特性才能明白为什么消息要按序处理哈希表的原理缓存设计里HashMap的冲突处理是根因分析的基础。还有一个很容易被忽视但笔试常考的点时间复杂度和空间复杂度。不需要你去推导多么复杂的算法复杂度但你要能判断一个双层循环实现的功能复杂度是O(n²)而用哈希表优化后可以降到O(n)。软测工作中设计测试数据时如果数据量达到百万级别O(n²)和O(n)的算法执行时间可能相差几十倍这直接决定了你是在跑10分钟还是跑10秒的用例。笔试如果想在数据结构这块读得更顺刷题可以适当偏向字符串处理、数组遍历、HashMap的运用这几种类型。因为社交产品的确最常操作这些数据结构用户列表、关注关系、消息内容、标签体系本质上都是字符串和数组的组合处理。4.2 HTTP协议与网络基础移动端测试逃不掉的知识点社交产品的移动端测试有一道绕不过去的坎就是网络。笔试中HTTP协议相关的题目几乎年年都有考点集中在这些地方HTTP和HTTPS的区别——不只是多了个加密证书校验、中间人攻击、会话劫持才是测试工程师要理解的重点。弱网测试的场景里用Charles或者Fiddler抓包你会经常遇到证书校验失败导致请求中断的情况测试报告里怎么定级这类问题就很考验对HTTPS原理的理解。HTTP的请求方法——GET和POST的区别PUT和DELETE的语义这些在接口测试中每天都要用。社交产品里获取信息流列表是GET发布动态是POST修改个人资料是PUT删除一条评论是DELETE。理解了方法语义才能去判断一个接口的设计是否RESTful。HTTP状态码——200是成功301/302是重定向400是请求参数错误401是未认证403是禁止访问404是不存在500是服务端异常502是网关错误503是服务不可用。笔试可能会给你几个异常状态码让你分析接口调用可能出了什么问题这时候你能不能说出排查方向就很关键了。TCP和UDP的区别在社交产品里也有天然的应用场景消息推送如果走的是TCP长连接你就要考虑连接保活、心跳机制、断线重连这些测试点如果某些实时音视频功能走UDP就要验证丢包、乱序、抖动对音视频质量的影响。能把这些关联起来写在卷面上面试官会认为你真的理解网络原理而不只是背了几个名词。4.3 数据库基础SQL必考但社交场景的查询更值钱数据库几乎是每份测试工程师笔试卷的必考模块而且通常不只考理论还会给你一张简单的表结构让你写SQL。对于测试工程师来说写SQL不是为了做开发而是为了构造测试数据、核对测试结果、清理脏数据。所以笔试中出现的SQL题目考察方向非常具体一是单表查询。给定一个用户表id, username, age, gender, city让你查出年龄大于25岁的男性用户按年龄倒序排列。这属于最基本的SELECT语句写不出来基本没戏。二是聚合查询。给定一个关注关系表id, user_id, follow_id, create_time统计每个用户的粉丝数或者查出粉丝数大于100的用户。这类题目考察的是GROUP BY和HAVING的用法在社交产品测试里很常见——测试人员需要构造一个有2000个粉丝的用户作为测试数据日常操作就是通过SQL批量插入follow记录。三是多表关联。给定用户表和关注表查出每个用户关注了哪些人以及这些人的昵称。这是JOIN的基本用法。笔试答题的时候有一个技巧SQL语句尽量写得结构清晰关键字大写每个条件单独一行别把一长串SQL挤在一行里。阅卷人看你的SQL就像看代码逻辑清晰是加分项。5. 逻辑思维与场景推理题这些题目隐藏了真正的筛选门槛5.1 开放型问题从答案看测试思维社交中心测试工程师笔试的压轴题往往是一道开放型问题。比如有一个陌生人社交App上线后出现用户投诉收不到验证码请分析可能的原因并给出排查方案或者如果只能用一个测试用例来验证一个新上线的朋友圈功能你会选择什么用例为什么这类题没有标准答案但恰恰是最能拉开分数差距的题目。因为它考的不再是知识点而是你的测试思维是否成熟。以验证码收不到为例一个成熟的测试工程师会从端到端的全链路上分析客户端有没有正确调用发送验证码的接口接口有没有被限流拦截短信服务商有没有返回发送成功的回执短信通道在运营商侧有没有被拦截用户手机信号是否正常手机有没有开启短信拦截功能号码是否在运营商的黑名单里说白了测试思维的核心是穷举可能性和分诊优先级。笔试的时候你不需要真的把所有可能性都排查一遍但你的答题思路必须体现出来先分模块客户端、服务端、第三方、用户侧再分优先级先查最高概率的问题最后给出验证方法怎么确认是这个原因导致的。能按照这个结构来回答这题基本就拿稳了。5.2 智力题与逻辑题平时积累更重要校招笔试尤其是稍微有点规模的互联网公司试卷都喜欢来一两道逻辑推理题。常见的有判断真假话问题、过桥问题、无限水和两个水桶倒水问题、赛马问题等。这些题网上流传的面试题集里基本都有提前刷一遍很占便宜。这类题的实际价值不在于你真的会做多少道而在于你面对一道从没见过的逻辑题时能不能有条不紊地拆解。我推荐的方法是公式化思考先明确题目给了哪些已知条件再明确结论需要满足哪些约束然后从小到大递推或排除法。很多时候答案就藏在某一个被忽略的约束条件上。6. 备考建议与踩过的坑6.1 笔试现场的时间分配策略校招笔试通常是一张卷子结构包括选择题、简答题、设计题和大题时间大概在90到120分钟。我的经验是时间分配的核心原则是先把该拿到的分保住再啃硬骨头。选择题和填空题属于快题每道题不超过1分半钟遇到卡壳的就先跳过别在选择题上跟一道题死磕——我当年就吃过这个亏一道关于排序算法稳定性的选择题纠结了6分钟导致信息流测试用例设计题只剩10分钟写最后草草列了几条用例就交卷了事后发现那道选择题其实也就1分。简答题每道控制在8到10分钟能画表格就画表格能列编号就列编号因为阅卷人通常没有耐心看你几大段密密麻麻的文字。测试用例设计题一定要留至少25分钟这是全卷最有区分度的题目值最高的分。注意校招笔试阅卷量大阅卷人看一份卷子的时间通常不超过5分钟。卷面结构清晰、关键信息突出比你写再多内容都重要。小标题、编号、加粗、表格这些排版细节在笔试卷子上同样适用。6.2 两份标准答案式的答题模板为了让你少走弯路我直接把我比较认可的两类答题模板分享出来。一是针对功能测试用例设计的模板按这个结构组织答案用例编号模块前置条件操作步骤预期结果优先级TC-FUNC-001关注用户A、B均为注册用户A登录后进入B的主页点击关注按钮按钮变为已关注B的粉丝列表出现AP1TC-INTER-001关注A已拉黑BA访问B的主页检查关注按钮状态不显示关注按钮或点击后提示由于拉黑设置无法关注P1TC-SYS-001关注弱网环境A点击关注后网络断开再恢复系统提示关注失败请重试不会出现重复关注P1二是针对接口测试用例设计的模板和功能用例的表格类似但多了几个字段请求方法、请求URL、请求参数、预期响应码、响应体校验点。看到这类问题直接把表格框架写上内容哪怕不太完整结构对了都能拿到不错的分数。6.3 笔试之后的及时复盘测试工程师这个岗位有个很有意思的地方它的日常工作之一就是发现错误并推动解决所以这个岗位的笔试结果其实是在考察你有没有把遇到问题和陷入问题分开的能力。笔试结束后如果还有机会拿到反馈一定要主动去复盘每道题的得分情况。但如果拿不到反馈也不要把卷子扔到一边——自己凭记忆重新做一遍把每一道拿不准的题都翻书或查资料确认清楚。我当年笔试的时候做错了一道关于TCP三次握手的题目没有认真对待后来在另一个公司的面试里被问到一模一样的问题又卡壳了。从那之后我养成了一个习惯每一次笔试后把错题整理成笔记按知识点分类尤其是那些自己看完答案才恍然大悟的题往往就是真实的薄弱环节。6.4 千万别在卷子上犯的低级错误最后说几个我见过真实的、低级的、完全可以避免的失分点第一写了SQL但没有写分号。虽然阅卷人不会真的去执行你的SQL但卷面的专业度已经拉低了。第二测试用例表里预期结果写了能正常使用这种废话。预期结果必须具体到可验证的程度比如点击关注按钮后按钮文案变为已关注且B的粉丝数加1。第三答非所问。题目让设计好友添加的用例有的人花大篇幅写接口压测和性能指标却没有一条真正覆盖用户视角的功能验证这类答案会被认为审题能力不过关。第四编程类题目只写思路不写代码。如果题目明确要求写出代码实现至少要给出核心代码段纯文字描述很难让阅卷人相信你真的会写。7. 关于测试工程师这个岗位我最后想多说一句复盘这份试卷的时候很多同学可能会问都2024年了看一份2018年的笔试卷子还有意义吗我的回答是测试工程师考察的核心能力模型这几年甚至没有太大的变化。变的只是业务形态和技术栈——从web测试转向移动端测试从功能测试为主转向接口自动化、UI自动化、性能测试的全栈测试但结构性思维这个底层能力从未变过。测试工程师本质上做的是质量翻译的工作把产品需求翻译成可验证的测试用例把用户反馈翻译成开发能复现的缺陷报告把业务风险翻译成优先级的决策依据。这套翻译能力恰恰是笔试卷子在短短两个小时里想考察的东西。如果你正在准备测试工程师岗位的校招笔试我的建议是不要抱着刷题背答案的心态去复习而是把每一道题目当作一个真实的业务问题去思考。社交产品测试之所以在笔试题里那么有代表性是因为它的业务逻辑足够复杂、技术栈足够全面、用户场景足够多样——你能在这一类题目里游刃有余其他领域的测试题基本也不会太难。希望这篇对试卷的复盘能给你一些实质性的帮助。如果你在准备测试岗笔试时有什么具体的困惑也欢迎在评论区聊一聊我看到了会尽量回复。