小红书测试运维岗笔试复盘：题型、考点与答题策略

2024 年春招，我报了小红书的测试&运维岗，第一批笔试全程踩完之后，最大感受是：这张卷子不是让你背概念，而是逼你把“测试思维”和“运维能力”拼到同一条链路上。要是只刷过测试用例设计题，或者只会背 Linux 命令，很容易在后面的场景题、脚本题里卡住。这篇复盘把我那场笔试的题型结构、考点范围、答题顺序和踩坑细节都写清楚了，希望能给准备类似岗位的同学一点参考。

1. 笔试之前，先把岗位画像摸清楚

1.1 测试&运维岗为什么会被合并成一张卷子

先想明白一个问题：为什么小红书这类互联网公司，会把测试和运维放进同一批笔试？因为岗位描述虽然叫“测试&运维”，实际业务场景里往往需要一个人同时具备测试开发和站点可靠性两方面的能力。

小红书的业务形态比较特殊：内容社区、电商、本地生活、广告，多个业务线并行，产品迭代速度非常快。测试同学不能只会写用例，还要能搭自动化测试平台、做接口巡检、维护测试数据，甚至参与线上质量监控；运维同学也不能只会装系统配网络，还要理解业务测试场景，在发布、扩容、故障恢复时知道怎么配合研发快速定位问题。所以这张卷子注定是混编的，不会只考某一类知识。

我在考前把岗位 JD 翻来覆去看了几遍，整理出三个核心能力要求：

• 基础扎实：操作系统、网络协议、数据库、常用工具链；
• 自动化意识：能写脚本，懂测试框架，理解 CI/CD 流程；
• 故障排查思维：给你一个线上现象，你能按合理链路定位问题。

这三条基本就是笔试的出题范围。后面我的复习计划也完全是按这三条线展开的，事实证明效率很高。

1.2 第一批笔试的题型结构和时间分配

从实际体验来看，整张卷子大体分四类：客观题、SQL 题、代码/脚本题、场景分析题。

客观题以选择和判断为主，覆盖面很杂，Linux、网络、软件测试理论、容器、数据库概念都会出现，单题分值不大，但量多，不能忽略。SQL 题通常是给表结构写查询或统计，属于必得分项。代码/脚本题会要求写一段排序、字符串处理或自动化测试脚本，语言不限。场景分析题最综合，一般是“线上接口超时”“发布后 CPU 飙升”这类问题，让你写排查步骤和解决方案。

时间分配上，我的真实感受是：客观题不能恋战，每道题控制在 1-2 分钟内；SQL 题要优先做，因为套路感强，拿分稳定；代码题至少留 30 分钟，把思路和主体代码写完整；场景题放最后，虽然开放性最强，但只要你逻辑链完整，写多写少都能拿分。

1.3 结合热搜词整理的核心考点地图

这里我先放一张自己归纳的考点地图，后面每个章节会展开讲：

记住这张表，再对照自己的短板去补，比漫无目的刷题高效得多。

2. 测试方向：不是只背“边界值”就够

2.1 软件测试基础，最容易拿分也最容易丢分

测试基础是整张卷子里最友好的部分，但很多人恰恰在基础题上翻车。客观题喜欢考这些点：测试分类（单元测试、集成测试、系统测试、验收测试的区别）、黑盒白盒的典型方法（等价类划分、边界值分析、决策表、因果图、语句覆盖、判定覆盖）、缺陷优先级与严重级别的区分、回归测试的执行阶段、冒烟测试的目的。

笔试里很容易出现“以下哪个属于白盒测试方法”这种选择题。如果你只背过“等价类、边界值”，很可能会选错，因为边界值和等价类都是黑盒方法，白盒方法要看语句覆盖、判定覆盖、条件覆盖这些。这类题没有捷径，建议把黑盒、白盒、静态、动态四条线串起来记。

还有一类题是给场景设计测试用例。比如“登录密码长度为 6-12 位，请设计用例”，这属于典型的边界值加等价类场景。答题时我会写清楚：先划分有效/无效等价类，再补上 5、6、12、13 这几个边界值，最后加一个全字符类型、超长输入、空输入等异常场景。这个套路在笔试题里非常通用，建议直接背下来当模板用。

2.2 SQL 题：千万别只懂 select

SQL 在测试笔试中几乎是必考题，原因是测试工作必然要写 SQL 造数据、核对结果、做断言。小红书这类业务涉及用户、笔记、商品、订单、作者等多张表，笔试常考的就是多表关联查询和聚合统计。

这一类题的套路很固定，通常是给你两张或三张表，比如用户表、订单表、商品表，让你查出：

• 每个用户的订单数；
• 订单金额最高的前 N 个用户；
• 某时间段内有订单但无评论的用户；
• 查询重复数据或去重统计。

想拿稳这类题，必须掌握 JOIN（尤其要搞清 LEFT JOIN 和 INNER JOIN 的区别）、GROUP BY 加 HAVING、聚合函数（COUNT、SUM、AVG、MAX、MIN）、子查询，以及窗口函数（ROW_NUMBER、RANK）。窗口函数在互联网公司笔试里出现频率不低，因为业务总离不开“排名”“Top N”问题。

写 SQL 时有个容易踩的坑：条件到底写在 WHERE 还是 HAVING。比如“筛选订单数大于 5 的用户”，订单数是聚合结果，必须用 HAVING，不能写成 WHERE COUNT(*)>5，这个错误非常典型。笔试时间紧，容易顺手写错，建议交卷前专门检查一遍聚合条件的归属。

2.3 自动化测试：Appium、Selenium 要“能用”而不是“听过”

自动化测试在这批笔试里不是单纯考概念，而是会结合场景出题。小红书的业务以 App 为主，所以 Appium 相关知识点出现概率不低，但 Web 侧的 Selenium 也不能忽略。

笔试常见问法：

• Appium 的定位方式有哪些？答案是 resource-id、class name、accessibility id、xpath、UIAutomator 等；
• 自动化用例中如何处理等待？显式等待和隐式等待的区别，以及为什么不能只用固定 sleep；
• Page Object 模式的核心思想？页面封装、元素定位集中管理、业务逻辑与实现分离；
• 如何保证自动化用例稳定性？比如元素找不到、网络延迟、弹窗干扰。

我建议考前把所有知识点落到“执行路径”上去理解。比如你写一个 Appium 脚本，启动 Appium Server 后，客户端通过 WebDriver 协议把命令发给 Appium Server，Appium Server 再通过对应平台的驱动框架去驱动设备。理解了这条链路，笔试里“Appium 服务端的角色是什么”这类题就很好答。

补充一个真实经验：我复习自动化时，一开始只背断言方法名，但笔试里问的是“APP 启动后出现升级弹窗，自动化脚本应该怎么处理”。这种题没有标准答案，考察的是异常场景应对能力。合理的回答是先判断弹窗出现条件，用显式等待识别弹窗元素，能关则关，不能关则跳过用例或标记失败，而不是一上来就说“不处理”。

2.4 接口测试和网络基础：测试同学不能不懂网络

测试笔试中和网络相关的题，通常不是刁钻的抓包协议细节，而是：HTTP 状态码的含义（200、301、302、400、401、403、404、500、502、503）、GET/POST 的区别以及幂等性、常见请求头和响应头（Content-Type、Authorization、Cache-Control）、HTTPS 比 HTTP 多了一层什么、TLS 握手大致流程、DNS 解析流程。

这些知识点既是接口测试的基础，也是后面运维方向反复要用的内容。笔试里出现过和“登录接口返回 302 是否合理”有关的题，本质上是在考重定向机制。如果你只知道“302 是临时重定向”，却不知道浏览器会跟随 Location 头，就很难判断正确性。复习网络知识时，我建议用抓包工具自己看一次真实请求的完整流程，把状态码、请求头、响应体对应起来，比硬背效果好得多。

3. 运维方向：Linux、网络、容器一个都躲不掉

3.1 Linux 常用命令，不是“会 ls”而是“会用管道解决问题”

运维方向的客观题和场景题里，Linux 命令是重头。很多人以为只要背下常用命令就行，实际笔试拿分的关键在于能不能用组合命令解决真实问题。

以文本处理为例，下面几个命令在笔试中反复出现：

• grep：按模式过滤文本，常配合字符串、正则；
• awk：按列处理文本，比如打印日志中的时间字段、IP 字段；
• sed：流式编辑，替换、删除、插入文本；
• cut、sort、uniq：处理简单分隔符、排序、去重统计；
• xargs：把标准输入转换成命令行参数，批量操作时非常关键。

一道典型场景题是“统计日志文件 access.log 中访问量最高的前 10 个 IP”。比较完整的答案是：

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

这个组合看起来简单，但很多人会漏掉sort或uniq -c的用法。uniq只能去除相邻重复行，所以必须先sort再uniq -c，最后再按次数倒序排序。笔试批改很看重步骤是否完整，建议平时在终端多敲几遍，形成肌肉记忆。

再比如系统资源查看，除了top、free -h、df -h，笔试还喜欢问：top输出的 load average 是什么意思；如何查看某个进程占用的文件句柄；如何看端口被哪个进程占用（netstat -tunlp或ss -tunlp）；内存测试怎么进行，比如用memtester或定位内存泄漏。这里提醒一下，笔试虽然不一定让你做硬件级内存测试，但会问“free 命令中 available 和 free 的区别”“Swap 分区使用率过高怎么办”。准备的时候要把底层概念搞清楚，而不是只背参数。

3.2 网络运维与常用测试工具：ping/telnet/curl 不是摆设

“网速测试”“网络运维工具箱”这些热词背后，对应的其实就是一套网络排障工具链。笔试和实际工作中最常用的网络排查命令包括：

• ping：测试连通性和延迟，基于 ICMP；
• telnet：测试指定端口是否开放，注意现在很多系统默认不装 telnet，会用nc替代；
• nc：即 Netcat，可以测试端口连通性、做端口转发，功能灵活但参数复杂；
• curl：测试 HTTP 服务，可以指定请求方法、请求头、带 cookie、看响应状态和耗时；
• traceroute或mtr：查看路由路径，定位链路问题；
• dig/nslookup：DNS 解析排查。

笔试常见的场景题是这样的：线上用户反馈 App 图片加载失败，让你列出排查步骤。合理链路是：先确认是局部问题还是全局问题；如果全局有问题，检查 CDN、域名解析和源站；如果局部问题，检查当前网络出口和运营商链路；随后用dig看域名解析是否正常，用curl -I看资源响应状态码，用ping和traceroute定位是延迟还是丢包。这个思路，本质上是一张无形的排查决策树，比单个命令更重要。

场景题答题时要注意：不能只写命令，要写“为什么用这个命令、命令输出什么样说明什么”。我笔试时在这一点上吃过亏，光写了命令列表，没写判断逻辑，得分肯定不高。建议用“现象—假设—验证—定位”的框架组织答案，读起来清晰，批改者也容易给分。

3.3 Kubernetes 和 containerd 的调用链，必须理解到“实体”层面

运维方向里“想知道 Kubernetes 是如何调用 containerd 的，从原理到实体调用架构”是热搜词，也是这批笔试里可能出现的进阶题。到了真实生产环境，一个 Pod 从调度到运行要经过 kubelet、容器运行时、containerd、runc 等多个组件协作。

我把整条调用链拆成几层：

1. Kubernetes API Server 接收 Pod 创建请求，经过调度器分配节点；
2. 节点上的 kubelet 通过 Watch 机制感知到 Pod 被调度到本节点；
3. kubelet 调用 CRI（Container Runtime Interface）接口，请求 containerd 创建容器；
4. containerd 作为守护进程，先通过 CRI 插件管理镜像和容器生命周期，然后调用 runc；
5. runc 是真正的容器运行时，负责基于 Linux 内核的 namespace、cgroup 等能力创建/运行容器进程。

笔试中常见的问题是：“kubelet 为什么不能直接调用 Docker，而要经过 containerd？”答案在于 CRI 接口是标准抽象层，把 kubelet 和具体容器运行时解耦。你能写出“kubelet –(CRI)–> containerd –(OCI)–> runc”这条链路，就已经超过很多人。更细一层，还可以提一下 containerd 内部的containerd-shim，它负责在 runc 退出后继续持有容器进程的 stdio 和状态信息。

实际备考时，我建议在本地用 minikube 或 k3s 搭一个最小集群，然后学一下crictl的用法，比如crictl ps、crictl logs、crictl inspect。故障排查时，有时候kubectl信息不够，需要用crictl直接看节点上容器运行时的真实状态。这种从理论到实体的练习，会让笔试中关于容器运行时的问题不再是死记硬背。

3.4 Docker、监控与 CI/CD：运维知识的“下半场”

Docker 基础知识也是必考的，常考考点：Dockerfile 常用指令（FROM、RUN、CMD、ENTRYPOINT、COPY、ADD、EXPOSE、ENV）、镜像和容器的区别、容器和虚拟机的区别、Docker 网络模式（bridge、host、none、container）、数据卷和绑定挂载的使用场景、如何让容器里的日志落到宿主机。

这些概念不难，但笔试容易出组合题。比如“某个容器无法访问外网，但宿主机可以，可能的原因是什么？”答案可能是容器网络模式设置问题、DNS 配置问题、iptables 规则问题，也可能只是容器里没配默认路由。这类题目没有唯一答案，你写得越全面越能得分。

监控和 CI/CD 也是运维岗笔试的高频内容。监控方面常问：监控系统的基本组成（采集、存储、展示、告警）、常用监控指标（CPU、内存、磁盘、网络、业务接口 QPS/错误率/耗时）、日志、指标、链路追踪“三件套”的关系、Prometheus 的架构和 Pull 模式、Alertmanager 告警流程、全链路追踪中 trace 和 span 的含义。

CI/CD 方面，Jenkins 是常客，但笔试更看重你对流水线的理解，而不只是某个插件的配置。比如会问“代码提交后，如何自动触发测试并部署到测试环境”，你要能说出代码仓库 Webhook、流水线构建、测试任务执行、产物归档、部署到目标环境这样一条完整链路。现在不少团队已经转向 GitLab CI 或云原生 CI，但核心逻辑没变。

3.5 自动化运维与效率工具：积累自己的工具箱

很多读者会搜“IT 运维效率工具”“运维手册包含哪些”“网络运维工具箱”，这些在场景题里也能体现。比如题目问“你如何保证线上服务变更的稳定性”，除了写标准发布流程，还可以补充：灰度发布、蓝绿部署、自动化回滚、变更前后的巡检脚本、告警阈值预检等。这些都是效率工具和流程意识的体现。

至于“运维手册包含哪些”，我的经验是至少包含四块内容：环境信息（服务器、网络、依赖服务）、日常操作手册（发布、扩缩容、备份、重启）、故障处理 SOP（常见故障现象、排查步骤、恢复动作）、联系人信息（研发、DBA、安全、第三方平台）。笔试如果让你设计运维手册目录，直接按这四块扩展，结构就非常完整。

自动化测试工具方面，虽然 Appium 和 Selenium 属于测试技术，但在持续集成环境中，它们就是运维流水线上的重要节点。一个合格的运维候选人，至少要能看懂测试脚本在流水线里的作用，会配触发条件，会处理测试产物。小红书这类互联网公司对测试和运维的边界本来就模糊，能打通两条线的人反而更受欢迎。

4. 实战笔试过程复盘：我是怎么做完这张卷子的

4.1 拿到卷子后，我给自己定了一个“做题顺序”

我拿到卷子后没有按顺序硬做，而是先快速扫一遍所有题目，分出三档：必得分、争取得分、最后冲击。必得分通常是 SQL 题和部分客观题；争取得分是代码题和常见网络概念题；最后冲击是开放性的场景分析题。

对整个时间分配，我的建议是：客观题 40 分钟、SQL 题 20 分钟、代码题 30 分钟、场景题 30 分钟，剩下时间检查。具体节奏可以这样：

• 0-10 分钟：快速浏览全卷，标记各题分数和难度；
• 10-50 分钟：客观题；
• 50-70 分钟：SQL 题；
• 70-100 分钟：代码/脚本题；
• 100-130 分钟：场景分析题；
• 最后 20 分钟：检查姓名、考号、有无漏题、SQL 是否写错、代码缩进是否完整。

这个节奏不是我一开始就会的。之前我在别的公司笔试里，把大量时间耗在客观题上，导致后面的代码题没时间写。所以这一场我强制自己在客观题上“快进”，不确定的题先标记，不恋战。

4.2 客观题里的高频陷阱

客观题看似简单，但陷阱密集。把自己碰到的几类陷阱整理一下：

• 概念偷换：比如把“集成测试”说成“针对单个模块的测试”，实际这是单元测试的特点；
• 命令混淆：比如systemctl start和systemctl enable的区别，前者是立即启动，后者是设置开机自启；
• 状态码误判：比如 403 和 404 的区别，一个是不允许访问，一个是资源不存在；
• K8s 资源对象混淆：Deployment、StatefulSet、DaemonSet 适用场景不同；
• 数据库隔离级别：脏读、不可重复读、幻读分别对应哪个隔离级别。

这类题没什么技巧，就是考察基础是否成体系。建议准备时把“易混淆概念”做成一张对比表，考前过一遍。比如：

4.3 代码/脚本题：不只是“能跑”，还要“会表达”

代码题在这批笔试里不一定是完整算法题，更可能是让你写一个脚本，比如：

• 解析日志文件，统计某个接口的平均耗时；
• 写一个函数，判断一个字符串是否为合法 IP；
• 实现一个简单的数组去重或 Top K 排序；
• 模拟用户登录接口的自动化测试脚本。

以“解析日志并统计接口平均耗时”为例，如果允许用 Shell，可以写：

grep "/api/note" access.log | awk -F' ' '{sum+=$NF; count++} END {print sum/count}'

如果允许用 Python，可以写：

import re total = 0 count = 0 pattern = r'"/api/note[^"]*"\s+\d+\s+(\d+\.?\d*)' with open('access.log', 'r') as f: for line in f: m = re.search(pattern, line) if m: total += float(m.group(1)) count += 1 print(total / count if count else 0)

笔试评分不仅看最终结果，更看你有没有考虑异常情况：文件不存在怎么办？日志格式不匹配怎么办？除数为零怎么办？如果你把这些防御逻辑写进注释或分支，会显得专业很多。

写代码题时还有一条经验：先把思路用注释写在最上面。很多批改者会先看代码结构，再决定是否运行；如果你注释里写出“1.读取文件 2.正则提取耗时 3.累加求平均”，即使代码有小 bug，分数也不会太低。

4.4 场景分析题：用“现象—假设—验证”结构拿分

场景分析题是最能拉开差距的部分，也是运维工程师和测试工程师日常工作的真实写照。题目大概长这样：

“某业务接口在高峰期 P99 延迟从 200ms 涨到 2s，服务没有宕机，请分析可能原因并写出排查步骤。”

如果只写“可能是慢 SQL、网络问题”，基本拿不到高分。我用下面这个框架来答：

1. 确认现象：延迟上升是偶发还是持续？影响范围是单个接口还是所有接口？先从监控平台上看 QPS、错误率、GC、CPU、内存、磁盘 IO、网络带宽等基础指标；
2. 定位瓶颈：按“应用层—中间件—数据库—外部依赖”逐层排查。应用层看日志和调用链，中间件看 Redis 慢命令、MQ 堆积，数据库看慢查询和连接池，外部依赖看第三方接口耗时；
3. 做对比实验：把某台机器流量摘掉，看是否恢复；或者回滚最近一次变更，验证是否为发布引入；
4. 给出结论和应急措施：扩容、限流、降级、切流量、回滚，根据业务影响面选择；
5. 事后改进：补监控告警、加性能测试用例、优化代码或 SQL、完善发布预案。

这个框架不只是笔试答题技巧，也是真实工作中的排查习惯。答题时我会刻意把“验证”写在“结论”前面，比如先用top看 CPU，用free看内存，用iostat看磁盘 IO，用ss看连接数，用curl测接口耗时，再结合链路追踪定位具体节点。写得越具体，越像真的做过，得分自然越高。

提示：如果是测试方向的场景题，可以换成测试思维来回答。比如“线上出现偶发支付失败，作为测试人员你如何分析？”你可以从用例覆盖、日志检查、数据一致性、接口幂等性、并发场景回归几个角度展开。核心是展示你的排查链路完整且可执行。

5. 常见问题与避坑清单

5.1 复习时最容易被忽略的“非典型考点”

结合热点趋势，我再补充几个容易被忽略但笔试里可能出现的非典型考点：

• 网速测试：不只是speedtest，要理解带宽、延迟、抖动的关系；
• RTMP 测试地址：直播领域常见，懂推拉流地址结构是加分项；
• 鼠标回报率测试：硬件外设方向，一般互联网业务笔试不会考，但涉及终端硬件时可能出选择题；
• UOS 运维工具 / LiveCD：部分政企项目会考察，知道它可以做系统救援和诊断即可；
• 安全测试：渗透测试、安全扫描工具（如 nmap、Burp Suite）要了解基本用法；
• 冒烟测试：知道它在发布流程中的位置，和回归测试区分开；
• AI 测试：现在不少公司开始考察 AI 应用的测试方法，比如大模型输出的评测和断言。

这些点不一定出现，但一旦出现，往往是用来拉开差距的。不建议花大量时间背它们，但至少要知道概念和应用场景。

5.2 笔试中暴露出的三个共性问题

从我的复盘和周围同学的反馈来看，第一批笔试里大家最常见的失误有三个：

第一，客观题太恋战。很多人卡在一道选择题上思考五分钟，最后代码题只能草草收尾。我的建议是第一遍先凭直觉快速作答，标记不确定的题，等所有题做完再回头抠。

第二，场景题只有结论没有过程。比如写“数据库慢查询导致接口慢”，却没有写“我先查看了慢查询日志才得出这个结论”，这会让人觉得你是猜的。一定要把排查链路写出来，哪怕多花几行。

第三，工具命令只写名字不写参数。比如写“用 curl 测接口”，却不写curl -w指定耗时输出，或者不写-X POST明确请求方法。真实工作中这种做法不被认可，笔试也一样。要习惯把参数写完整。

5.3 给下一批考生的一条实用建议

如果让我给一句最浓缩的经验，就是：把测试和运维当“一条链路”去复习，而不是两门孤立的课。测试用例设计要能落到自动化脚本里，自动化脚本要能挂到 CI/CD 流水线上，流水线部署完要在监控和日志里验证，验证完反过来又驱动新的测试用例。这条链路里的每一个环节，都会在笔试里出现，而且是连着出现的。

备考时建议你这样安排：

• 用一周时间把网络（HTTP、DNS、TCP）、Linux 命令、SQL 三个基础域补牢；
• 再用一周时间系统过一遍测试理论和自动化测试框架；
• 第三周围绕 Docker、Kubernetes、CI/CD 搭一套自己熟悉的最小实践环境；
• 最后两三天做真题模拟和错题整理，重点看场景题的答题框架。

我当时就是把“网络排查”和“自动化测试”放在同一个学习计划里，用本地虚拟机加两个测试脚本反复练，效果比零散刷题好很多。现在回想那场第一批笔试，虽然没有收到最理想的通知，但它帮我建立了一个完整的知识框架，往后面试和实际工作中，这套框架一直在反馈给我价值。