2023年秋招-小红书-测试运维岗-第三批笔试校招笔试这关说不重要是假的说决定一切也是夸张了。我前前后后带过好几届实习生也帮团队筛过简历、看过笔试题发现很多人对测试运维岗的笔试理解有偏差——以为就是背背Linux命令、刷刷LeetCode就完事了。实际上像小红书这种体量的公司测试和运维岗的笔试早就不是单纯考知识点而是通过题目在考察你有没有系统解决问题的能力。我拿到的是2023年秋招第三批的测试运维岗笔试试卷整体做下来印象很深题量不小覆盖面广而且有好几道题明显是故意挖坑的。这篇文章就按照我的实际做题顺序和复盘思路把这套卷子里最有代表性的题目类型、解题逻辑、易错点全部拆开讲一遍。不管你是正在备战校招还是准备跳槽这套思路都能直接用上。1. 这套笔试试卷的结构与出题逻辑为什么它和你想象的不一样先说结论这套卷子不是纯技术题也不是纯行测题而是**基础技术场景分析系统设计心态测试四合一**的混合体。我印象里整个答题时间是90分钟题目总量大概在40道左右包含单选、多选、判断、简答和2道场景分析大题。1.1 四大题型板块的比例分布从实际做题体验来看四个板块的权重大致如下板块大致占比考察目标典型形式通用技术基础35%Linux/网络/数据库/协议选择题、判断题测试专业能力25%用例设计、自动化、测试思维简答、场景设计运维专业能力25%部署、监控、故障排查、CI/CD场景分析、案例分析综合素质与逻辑15%沟通表达、优先级判断、学习能力开放题、情景题这个比例很有意思。它说明小红书对测试运维岗的定位是T型人才——在专业深度上至少要有一头精通测试或运维但另一头也不能完全不懂。尤其是测试和运维之间那层墙现在大厂越来越不想要了。1.2 出题人有意识地在打破测试和运维的边界卷子里有几道题特别能体现这个倾向。比如有一道题大概是这样的线上服务出现接口超时测试环境无法复现作为测试和运维你会如何协作排查这道题本身不难但它摆明了在考两件事第一测试人员是否理解线上环境和测试环境的差异第二运维人员是否有能力把线上问题拆解成可验证的假设。如果你只懂自己那一亩三分地这道题基本拿不到高分。还有一道选择题也让我印象深刻问的是灰度发布和A/B测试的核心区别。很多人看到这题觉得简单——灰度发布是运维的事A/B测试是测试的事。但正确答案恰恰要求你理解两者本质上是同一套基础设施在不同目标下的应用灰度发布的目标是降低变更风险A/B测试的目标是验证业务假设。出题人考察的不是概念本身而是你能否看清底层逻辑的一致性。1.3 时间分配策略我为什么先做场景题这套卷子的题量老实说按部就班做大概率会有点赶。我的策略是先做最后两道场景分析大题再回头做选择题。原因很简单场景分析题分值高、需要组织语言如果在最后剩下5分钟才匆匆作答哪怕你思路是对的写出来的东西也是一团乱麻阅卷人根本抓不到重点。而选择题即使时间紧蒙对的概率也还在。不过这里有个前提你得快速扫一遍所有题目对整体难度有个判断。我大概花了两分钟浏览全卷发现场景题虽然分值高但都是基于日常运维和测试常见问题心里有底了才敢先做大题。如果题目超出预期这个策略就不一定成立。2. 通用技术基础部分看似送分实则全是陷阱这部分覆盖Linux、网络、数据库、HTTP协议等表面上是背多分但实际做下来发现出题人特别喜欢在看似确定的地方加一个反转条件。2.1 Linux命令题不是考你会不会敲而是考你熟不熟悉真实场景卷子里Linux相关的题目大概有6到7道覆盖了文件操作、进程管理、权限控制、日志排查等常见场景。有一道判断/改错题我记得很清楚原题大意是某同学在排查线上问题时使用grep error app.log | grep -v timeout | awk {print $4}过滤日志请指出这条命令可能遗漏哪些问题。这题考得刁钻。表面上是考管道和正则实际上是在考日志分析的完整思维。只过滤包含error的行意味着漏掉了WARN级别但实际严重的日志漏掉了因日志拆分被截断的上下文漏掉了同一时间窗口内其他服务的关联日志我给的答案里还补充了一点用grep -v timeout去过滤超时可能把真正需要关注的超时后重试成功这类关键线索也过滤掉了。这种题没有标准答案但答得越全面越能体现你的线上排查经验。还有一道题考察top和free命令的理解问的是系统load average高于CPU核数但CPU idle很高可能是什么原因。这题的正确选项里包括大量D状态进程不可中断睡眠频繁的内存换页IO等待过高。很多人看到load高就选CPU忙但实际上面试官要考的是load avg的计算机制包含不可中断睡眠进程这个细节。这个点我在之前的项目里踩过坑——线上MySQL实例load高但CPU不忙最后定位到是磁盘IO饱和一堆进程在等IO完成。2.2 网络协议题三次握手和DNS是永远的重点网络题主要集中在TCP/IP、HTTP、DNS这几个层面。有一道多选题问的是TCP建立连接过程中可能出现SYN丢包的原因有哪些选项包括半连接队列溢出全连接队列溢出防火墙拦截SYN包服务端进程阻塞正确答案是前三项第四项是干扰选项。服务端进程阻塞影响的是accept队列而不是SYN队列。这道题考察的是对TCP连接建立全链路的理解而且和运维日常的ss -lnt看到的Recv-Q、Send-Q数值能对上号——这些数值就是用来判断连接队列状态的。DNS相关的题也有一道比较有意思问客户端访问域名解析结果时而正常时而超时可能的原因。这里考的是DNS缓存、TTL策略、DNS轮询、以及本地/etc/resolv.conf配置。我额外补充了一点如果使用的是公有云DNS还需要考虑DNS服务器本身是否做了限流这在大促、活动流量突增时特别常见。2.3 数据库题索引和锁是必考点数据库相关题量不大也就三四道但几乎每道都在考两个核心概念索引的工作机制和锁的隔离级别。有一道题是给出如下查询SELECT * FROM orders WHERE user_id 123 AND status PAID ORDER BY create_time DESC;问应如何设计索引。最合适的答案是(user_id, status, create_time)联合索引。但要注意status选择性低如果区分度不够放在第二位可能导致索引效率不高此时可以考虑(user_id, create_time)并在应用层过滤status。这种题目没有绝对标准答案关键是你要能把区分度最左前缀回表这些概念讲清楚。还有一道关于MySQL死锁的判断题考的是事务A先更新user再更新order事务B先更新order再更新user是否必然死锁。正确答案是不一定因为能否形成死锁取决于两个事务是否真的持有对方需要的锁以及锁的申请顺序是否形成循环等待。如果在不同的数据行上操作即使顺序相反也不会死锁。2.4 本部分复盘怎么准备这类基础题通用技术基础部分其实是最好准备的因为它有明确的范围和标准答案。我的建议是Linux命令不要只背参数要模拟真实排查场景去用网络协议重点关注三次握手、四次挥手、TCP状态转换、DNS解析链路数据库重点掌握索引设计、锁机制、事务隔离级别、慢查询排查HTTP协议重点关注状态码语义、缓存机制强缓存/协商缓存、HTTPS握手流程这部分出错的主要原因往往不是不知道而是想太多。比如有的题明明在问TCP层你非要联想到HTTP层结果选了个看起来更高级但不符合题意的答案。做题时一定要先判断题目在哪个层面提问再去做答。3. 测试专业能力部分用例设计题考察的是思维框架不是答案本身测试岗相关题目在这套卷子里占比其实挺高的大概有8到10道。但最核心的不是那些概念题而是一道完整的测试用例设计题和一道接口自动化测试的方案设计题。3.1 经典的登录功能测试用例设计题怎么答才能高分这道题几乎是测试岗笔试的必考题了原题大概是请设计微信/小红书App登录功能的测试用例要求覆盖功能、兼容性、安全、性能等维度。大部分人看到这题就开始写输入正确账号密码登录成功输入错误密码提示错误输入空账号提示为空这样答只能拿及格分因为你只是在列场景没有建框架。一个高分答案应该有清晰的层次结构比如从以下几个维度展开功能维度正常流程正确账号正确密码、验证码登录、第三方授权登录异常流程错误密码、账号不存在、账号被锁定、密码错误多次触发验证码边界场景密码长度边界、特殊字符、空格处理、账号前后有空格中断场景登录过程中断网、App切后台再切回、来电打断兼容性维度不同操作系统版本iOS 15/16/17Android 10-14不同屏幕尺寸、刘海屏/挖孔屏适配不同网络环境Wi-Fi、4G、5G、弱网、无网安全维度密码是否加密传输登录态是否安全存储是否防止暴力破解、撞库是否存在越权风险性能维度弱网环境下登录耗时是否可接受高并发下服务器能否扛住登录接口的响应时间、成功率兼容性还应该考虑使用第三方登录微信/QQ/手机号时的授权页能否正常回调杀掉App进程后登录态是否保持多设备同时登录的会话处理我当时在答这道题时特意注意了一个细节功能测试要区分前置条件、操作步骤、预期结果三个要素。比如密码错误多次触发验证码这道用例前置条件是该用户已连续输错密码3次操作步骤是第4次输入正确密码预期结果是提示需要输入验证码并正确展示验证码组件。把这三个要素列清楚阅卷人一眼就能看出你会不会写规范的测试用例。3.2 接口自动化测试方案设计题如何体现工程化能力这道题我记得也比较清楚问的是现在需要为一个用户信息查询接口设计自动化测试方案你会怎么做很多人看到这题第一反应是用Postman调接口写断言。如果你真的这么答基本会被Pass掉。这道题考察的是工程化落地能力至少要从以下几个层面来答第一层接口分析层面明确接口协议HTTP/HTTPS、请求方法GET/POST、参数类型分析接口的入参、出参、错误码、异常场景梳理接口依赖是否需要登录态、是否依赖其他服务第二层测试数据设计准备正常数据、边界数据、异常数据、脏数据数据准备方式直接在测试库造数据还是通过接口造数据数据清理策略每个用例执行后是否需要还原环境第三层自动化框架设计选择语言和框架Python Requests Pytest或 Java RestAssured TestNG封装公共方法请求发送、断言、日志、报告实现数据驱动通过 YAML/Excel/JSON 管理用例数据集成CI/CD在Jenkins或GitLab CI中定时执行输出测试报告第四层稳定性与可维护性处理接口依赖token自动获取、参数关联失败用例自动重试机制环境切换配置化我当时重点强调了测试数据与用例逻辑分离这个点。因为很多团队的接口自动化做不下去原因就是数据和逻辑耦合在一起改一个数据要改代码改完还不知道影响哪些用例。用数据驱动的方式把每条用例的请求参数、预期结果放在一个独立文件里用例代码本身不做业务逻辑这样才能真正可持续迭代。3.3 测试思维题如何判断你是执行型还是思考型测试除了用例设计和方案设计卷子里还有几道题专门考察测试思维。比如如果开发告诉你说这次改动只加了一个字段影响范围很小不用测试你会怎么做这道题没有标准答案但高分方向很明确先表示理解再说明零变更不是零风险的原因请求查看代码diff确认改动是否真的只加了一个字段评估这个字段是否影响了已有的序列化、存储、展示链路如果影响面确实小建议做冒烟验证如果影响面被低估坚持要求补充回归测试这道题考察的是沟通能力和风险意识本质上是看你能否在配合开发节奏和守住质量底线之间找到平衡。测试不是开发的对立面但也不能扮演好好先生。3.4 测试部分的整体复盘测试专业能力部分的备考核心是理解测试的系统性思维而不只是记住测试方法。我给你几个建议把常用的测试设计方法等价类划分、边界值分析、场景法、错误推测法、正交实验法吃透做到能口头解释、能举例说明准备几个详细的测试用例设计案例登录、购物车、订单流程、文件上传、搜索功能等每个都要能按功能、兼容性、安全、性能四个维度展开接口自动化一定要有完整的落地方案从框架选型到CI集成从数据管理到报告输出了解一点App专项测试包括安装/卸载/升级测试、兼容性测试、弱网测试、消息推送测试、异常场景测试来电、短信、低电量、存储空间不足4. 运维专业能力部分场景题的核心是故障排查的思路链运维专业能力的题目如果只看单题难度其实没有基础知识部分高。但它更接近实际工作——给你一个线上故障的零散信息你要能串成一条完整的排查链路。4.1 线上服务CPU飙升的排查考察的不是top命令是分析框架卷子里有一道非常有代表性的题原题大意是线上Java服务突然CPU使用率飙升至90%以上请描述你的排查步骤。很多人第一反应是用top看看哪个进程CPU高然后用jstack看线程栈。这个思路没错但太笼统了缺乏可执行性。一个完整的排查链路应该是第一步确认现象确认CPU飙高是偶发还是持续确认影响范围单机还是整个集群确认是否有明显的触发事件发布、流量突增、定时任务、缓存变更第二步定位进程执行top -c找到CPU占用最高的进程PID执行top -Hp pid定位到具体的线程IDtid这里要特别注意top -Hp看到的线程ID是十进制的而jstack输出的线程ID是十六进制的。你需要转换一下常用命令是printf %x\n tid第三步分析线程栈执行jstack pid stack.log抓取线程栈快照如果是瞬间飙高不好抓现场可以多抓几次间隔1-2秒在线程栈中搜索CPU飙高线程对应的nid分析该线程在做什么频繁GC导致CPU高重点关注GC线程执行jstat -gcutil pid 1000观察GC频率和耗时业务逻辑死循环看线程栈是否长时间停留在某个业务方法锁竞争看是否有大量线程处于BLOCKED状态正则表达式回溯这个很难从栈上直接看出来但现象是CPU高且执行时间增长第四步结合上下文判断如果多个线程栈都指向同一个组件很可能是该组件自身问题如果线程栈各不相同更像是整体负载过高导致CPU排队关注GC日志尤其是Full GC的频率和GC耗时我当时在答案里专门强调了不能用一次jstack的结果就下结论这个点。CPU问题是动态的一次快照只能反映那一刻的线程状态。至少要抓3次以上每次记录时间对比线程栈的变化。如果三次都指向同一个线程在做相同的事情定位才比较可信。4.2 核心链路追踪与故障定位如果只知道看日志就输了还有一道题考察的是全链路追踪原题大意是用户反馈App首页打开很慢你作为运维如何快速定位瓶颈这题的高分答案不是去看服务器日志而是要先给出一个完整的链路拆解明确用户访问路径客户端DNS解析 → CDN → 网关 → 应用服务 → 缓存 → 数据库/下游依赖逐层排除先确认是整体慢还是个例看客户端上报的性能监控数据再看CDN/静态资源是否命中如果首页大量静态资源未命中CDN回源会大幅拖慢首屏再看网关层响应耗时如果网关耗时高可能是后端服务响应慢也可能是网关自身的限流、熔断策略触发再看应用服务的调用链通过SkyWalking或Cat等APM工具看每个Span的耗时最后看依赖组件Redis慢查询、数据库慢SQL、下游接口响应时间定位并响应当定位到某个组件后判断是性能瓶颈还是故障决定是扩容、限流还是降级我还特别提到了一个常见的坑用户说的慢和系统监控的慢往往不是同一回事。用户感知的慢是端到端耗时包括网络传输、客户端渲染、DNS解析而监控通常只覆盖服务端耗时。如果只看服务端指标可能什么都查不到因为瓶颈在客户端到服务端之间的网络链路。这就是为什么要先确认用户侧的感知再逐层排查。4.3 发布与变更管理题这些细节最容易丢分卷子里关于发布和变更的题有两三题考的主要是灰度发布、回滚策略、变更窗口等。有一道场景题我记得很清楚你在凌晨2点收到告警某服务的错误率从0.1%突增到5%同时你查到该服务在凌晨1点50分刚发布了新版本。此时你会怎么做这道题的标准答题思路先止损如果错误率在持续攀升毫不犹豫执行回滚保留现场回滚前记录当前版本的镜像ID、配置、日志方便后续排查回滚后验证确认服务恢复错误率回到正常事后复盘分析新版本引入的问题是代码bug、配置错误还是依赖变更但这里有个细节很多人会忽略你如何判断错误率突增和发布之间是否真的相关如果发布了20分钟之后错误率才开始上升而且上升的是某个特定接口的错误率可能与发布无关而是下游依赖故障。你至少要做两个验证一是确认新版本Pod/实例的运行状态二是看错误的具体类型是超时、5xx还是业务错误码是否与本次变更相关。可以说变更管理这块不仅考技术也考判断力和决策力。运维的核心职责不是避免一切变更而是在变更出错时能以最快的速度恢复服务同时保留足够的线索用于复盘。4.4 CI/CD与监控告警题考察全链路思维最后还有几道关于CI/CD和监控告警的选择题、判断题难度不大但有一个点我想特别提示一下。有一道题问的是监控告警中什么情况下会出现告警风暴选项包括多个服务因同一个底层故障同时告警、告警阈值设置不合理、监控采集频率过高、告警通知渠道配置错误。正确答案是前两个。这道题其实在考一个运维设计原则告警要收敛要有根因分析的能力而不是每个现象都发一条告警。我在回答中补充了实际工作中常用的做法设置告警聚合规则将同一时间窗口内相同组件的告警合并设置告警依赖关系比如某数据库故障时不重复发送依赖它的所有服务的告警设置告警升级策略避免高频告警导致值班人员麻木对告警进行告警即故障的闭环管理每条告警都要有责任人、处理时间、后续改进4.5 运维部分整体复盘运维专业能力部分的备考要点三大核心能力故障排查、变更管理、稳定性保障常用命令和工具要熟练但更重要的是理解排查链路和分析思路遇到故障排查题遵循确认现象 → 定位进程/线程 → 分析原因 → 验证假设 → 恢复上线 → 复盘改进这个框架监控告警要理解告警收敛告警降噪告警升级等运维设计原则了解容器化和Kubernetes的基础概念因为现在很多运维题的背景就是云原生环境5. 从这套笔试看测试运维岗的未来技术栈边界正在消失这套卷子做下来我最大的感触是小红书这类公司对测试运维岗的要求已经不再是专精一隅而是一专多能了。从题目比例和难度分布来看有几个趋势非常明显。5.1 测试和运维的技术栈正在深度融合测试需要懂部署、懂监控、懂链路追踪因为自动化测试跑在容器里需要排查测试环境问题运维需要懂测试思维因为发布前的验证、发布后的灰度观察、A/B实验的数据分析本质上是用测试的方法验证运维的变更两者都需要掌握代码能力无论是写自动化脚本还是维护运维平台都离不开编程卷子里那道测试环境复现不了线上却有问题的场景题就是这种融合趋势的直接体现。你要能拆解测试环境和线上环境的差异——配置、数据量、流量特征、依赖服务、网络拓扑——这些差异测试和运维需要一起分析才能找到根因。5.2 从执行者到平台建设者的转变现在大厂的测试运维岗已经不太需要只会手工点点点的人也不太需要只会敲命令看监控的人。卷子里多次出现的方案设计平台能力工具建设类题目实际上是在筛选那些未来能搭建质量保障体系、能构建自动化运维平台的人。几个值得关注的技术方向测试开发方向测试平台、精准测试、流量录制回放、Mock服务、契约测试SRE方向SLI/SLO体系、容量规划、弹性伸缩、混沌工程、稳定性设计云原生运维方向Kubernetes、容器化、Serverless、GitOps、可观测性Metrics/Logging/Tracing三支柱AIOps方向异常检测、根因定位、告警降噪、智能运维如果你现在还在用做测试就是写用例、做运维就是看监控的心态看待这两个岗位后面一定会碰壁。未来更有竞争力的是那些既懂测试方法论、又会写自动化工具、还能理解运维稳定性设计的复合型人才。5.3 笔试作答中体现经验感的小技巧最后分享几个笔试作答的实操技巧这是我在做这套卷子和帮别人复盘时总结出来的作答时使用总-分-总结构任何一道简答题或场景题先给出结论/总体思路再分点展开细节最后做简短总结。这和写技术方案是一个逻辑。阅卷人一天要看几百份卷子你如果开头三行抓不住他后面的内容就很难被认真看。涉及排查题时写排查步骤和每一步的目的。比如执行 top -Hp 定位到具体的线程ID转为十六进制后在 jstack 输出中查找对应线程——不要只写看线程栈要写清楚怎么看、看什么、为什么看。遇到设计题时先定义场景再给出方案。比如接口自动化测试设计先说要确认接口的协议、入参、出参、依赖方再说怎么设计用例、怎么搭建框架。没有场景定义的设计方案是空中楼阁。留白比写满更重要。如果你对某道题没有把握不要试图用一大段模糊的描述去掩盖。写清楚你确定的、标记出你不确定的、说明你会怎么去验证这样反而会给阅卷人留下思路清晰、态度诚实的好印象。5.4 后续还可以这样扩展笔试只是第一步通过之后还有面试。面试中面试官大概率会沿着你笔试答卷中的某些细节往下追问。所以笔试结束后一定要做一次完整的自我复盘每道题答了什么、为什么这么答、有哪些地方答得不够好。这比考完就扔要有用得多。另外建议在笔试前就开始积累一个自己的技术案例库比如你曾经解决过的一个线上问题、你设计过的一个测试方案、你优化过的一个CI/CD流程。这些真实案例在笔试的开放题和面试的项目深挖环节能给你提供的支撑远超任何标准答案。我在实际带人的过程中发现那些笔试、面试表现稳定的人往往不是刷题最多的而是**对每个问题都能讲清楚我遇到了什么问题、怎么分析的、怎么解决的、踩了什么坑**的人。这套方法论在任何岗位都适用测试运维岗尤其如此。