搜狗校招测试岗笔试复盘：场景题与测试思维实战解析

搜狗2020校招测试岗笔试第二场，我是下午场考的。说实话，第一场考完心态有点崩，第二场本来不打算去了，后来想想反正简历也投了，多一次笔试多一次经验，硬着头皮上了。结果没想到第二场的题目风格和第一场差别挺大，反而让我觉得更有得写、有得复盘。

先说结论：搜狗这场测试笔试，整体难度属于中等偏上，不纯考八股文，很多题是给一个具体场景让你分析怎么测、怎么设计用例、怎么排查问题。这跟很多公司直接甩一堆"软件测试的定义""V模型和W模型的区别"那种题完全不一样，它更看重你的测试思维和工程落地能力。

我用了一晚上把整张卷子的考点、我做题的思路、以及后来对答案发现的问题整理了一遍，尽量还原考试时的真实状态。这篇就当是给后面投搜狗或者类似互联网公司测试岗的同学一个参考，尤其是那些觉得"测试笔试就是背理论"的人，看完你应该会改变一些看法。

1. 第二场笔试的试卷结构：跟第一场完全不是一个路子

先给个整体印象。搜狗这场笔试是在牛客网系统上做的，总时长90分钟，题量大概在35道左右，但分布有点出人意料：

这个结构其实已经透露了很多信息：搜狗对测试工程师的要求不是"会写测试用例"就够了，而是你既要有计算机基础（网络、操作系统、数据结构），还得有测试专业能力（场景分析、用例设计、自动化、性能排查）。

我当时第一场考的时候，单选和多选占了绝大部分，问答题特别少，所以第二场看到有3道大题的时候愣了一下。后来想想也合理——测试岗不考场景设计，光靠背理论选ABCD，根本筛不出真正干过活的人。

1.1 搜狗这场笔试想筛选什么样的人

从题目设计倒推一下，搜狗测试笔试的重点大概是这么几个方向：

第一是基础扎实。计算机网络、Linux操作、数据库查询这些是测试工程师的日常工具，不懂这些，连bug都没法定位。第二是有测试思维，不是只写"输入正确数据返回正确结果"这种用例，而是能想到异常场景、边界场景、并发场景。第三是动手能力，也就是编程题和场景题，能不能把想法落成代码，能不能设计出可执行的测试方案。

我考完跟朋友聊，大家普遍觉得：选择题还能蒙一蒙，场景题是真的裸奔，平时没做过实际测试项目的人，一下子就能看出来。

1.2 时间分配的血泪教训

90分钟做35道题，听起来平均每题两分半，但实际上完全不是这么算的。选择题里有一些是计算题，比如子网掩码划分、时间复杂度推导，一道题可能要算五六分钟；场景题更不用说了，三道大题我用了将近40分钟。

我个人的建议是：选择题控制在40分钟内做完，遇到卡壳超过3分钟的题先标记跳过去，编程题一旦看到就马上开始写，场景题留到最后用剩余时间集中输出。我这次就是这么干的，最后场景题虽然写得不算完美，但起码每道都答满了，不至于大面积空白。

2. 选择题里的高频考点：Linux、网络、数据结构一个都没落下

第二场的选择题，整体风格是"偏实战、爱挖坑"。我挑几个印象比较深的点展开说，这些也是测试笔试里最高频的几类。

2.1 Linux命令：不考命令拼写，考你知不知道什么时候用

Linux题大概出了3到4道，都不难，但很讲究细节。比如有一道题问："查看某个进程监听的端口号，用哪个命令组合？"选项里有netstat -anp、ps -ef、top、lsof -i。

这道题其实有两个正确答案，一个是netstat -anp | grep 进程名，另一个是lsof -i。单看命令本身都对，但题目说"最常用且能过滤端口"，那netstat -anp配合管道过滤就更合适。这种题就是考你平时到底用没用过，而不是背没背过。

还有一道题是给了一个日志文件，问怎么快速找到其中包含"ERROR"的行数。正确做法是grep -c "ERROR" xxx.log，但选项里混了grep "ERROR" xxx.log | wc -l——这个其实也数得出来，只是多了一步管道。这种"两个答案都能做，但哪个更优"的题目，在搜狗的卷子里出现了好几次。

提示：测试笔试里遇到Linux题，先别急着选，看清楚题目问的是"能实现"还是"最优实现"。大多数公司在这道题上埋的坑，就是让你在"能用"和"好用"之间做选择。

2.2 TCP/IP和HTTP：会背三次握手不够，要会分析报文

网络题大概有4道，其中一道非常经典：给出TCP三次握手的序列号变化，问你第二次握手的SYN和ACK标志位分别应该是什么。这道题考的不只是三次握手的顺序，而是你有没有真正理解seq和ack的数值关系——客户端发seq=x，服务端回复seq=y, ack=x+1，然后客户端再发seq=x+1, ack=y+1。

我见过很多人在这种题上翻车，原因是只记了"三次握手是SYN、SYN+ACK、ACK"这个口诀，但没理解每一步的序列号是怎么推出来的。测试工程师排查网络问题时，经常要看抓包结果，如果连序列号变化都看不懂，基本没法干活。

另一道HTTP题也很有代表性：问"HTTP/1.1中Connection: keep-alive的作用是什么"——这题本身不难，但选项里混了一个"保持数据加密状态"，这是典型干扰项，Connection: keep-alive跟加密没关系，它只是让TCP连接不立即断开，可以复用。

还有一道问了Cookie和Session的区别。这个几乎是所有测试笔试必考题，搜狗的考法是给一个场景："用户登录后，服务器重启，为什么客户端还能保持登录状态？"答案是Session存在服务端，但SessionID存在Cookie里，服务器重启后Session数据丢失，但Cookie里的SessionID还有效，所以客户端以为还在登录，实际请求时会发现Session不存在。这个场景很贴近真实测试中遇到的"登录态失效"bug。

2.3 数据结构和算法：难度不高，但需要选对方法

选择题里数据结构大概有4道，主要考时间复杂度和基本的排序搜索。有一道题印象深刻：给一个有序数组，要求查找某个元素，问最优时间复杂度是多少。答案是O(log n)的二分查找。但选项里有个O(n)的线性查找，很多同学一看到"查找"就直接选了顺序查找，忽略了"有序数组"这个前提。

还有一道排序题：问"快速排序在最好情况下的时间复杂度"，这个最好情況是O(n log n)，最坏是O(n²)。题目设置了一个陷阱——把"最坏情况"和"平均情况"混在一起当干扰项。其实快速排序平均和最好都是O(n log n)，只有极端的逆序输入才会退化成O(n²)。

这一块我的建议是，复习数据结构时一定要把每个算法的"最好/最坏/平均"三种时间复杂度都列一遍，因为笔试非常喜欢从三个复杂度里挑一个考。

2.4 数据库：SQL查询和索引，考的是基本功

数据库题出了两道，一道是SELECT ... WHERE ... GROUP BY ... HAVING ... ORDER BY的执行顺序，另一道是索引失效场景。

执行顺序那题，很多人会搞混WHERE和HAVING的执行时机。正确顺序是FROM>WHERE>GROUP BY>HAVING>SELECT>ORDER BY。WHERE是在分组前过滤，HAVING是在分组后过滤，这个区别在测试数据库时特别重要——你查数据时如果过滤条件放错位置，可能查出完全不同的结果。

索引失效那题问的是："哪个操作会导致索引失效？"选项里包括WHERE age + 1 > 20、WHERE name LIKE '张%'、WHERE id IN (1,2,3)、WHERE create_time BETWEEN '2020-01-01' AND '2020-12-31'。正确答案是age + 1 > 20，因为对索引列做了计算，导致优化器没法走索引。这个知识点在测试环境做数据查询时很实用，你查慢的时候第一反应就应该是"是不是索引没走"。

3. 编程题：不考难题，考你能不能写"能跑的代码"

编程题一共两道，都不算难，但非常考验基础功。

3.1 第一题：字符串去重保序

题目大概是：给定一个字符串，去除重复字符，并且保持第一次出现的顺序输出。

看到这道题我第一反应是用LinkedHashSet，因为它正好满足"去重+保序"两个条件。我用的Java，代码大概是这样：

public static String removeDuplicate(String str) { if (str == null || str.isEmpty()) { return ""; } Set<Character> set = new LinkedHashSet<>(); for (char c : str.toCharArray()) { set.add(c); } StringBuilder sb = new StringBuilder(); for (char c : set) { sb.append(c); } return sb.toString(); }

但这里有个隐藏考点：题目说字符范围可能包含Unicode，不一定是ASCII。如果用char遍历，遇到emoji或者中文可能拆成两个char，导致结果错误。我当时用的是str.codePoints()转成int再处理，稳妥很多：

public static String removeDuplicate(String str) { if (str == null || str.isEmpty()) { return ""; } Set<Integer> seen = new LinkedHashSet<>(); str.codePoints().forEach(seen::add); StringBuilder sb = new StringBuilder(); seen.forEach(cp -> sb.appendCodePoint(cp)); return sb.toString(); }

注意：很多笔试编程题的测试用例不会卡你Unicode，但你自己心里要有数。用char遍历在绝大多数情况下没问题，但一旦测试用例里有中文或特殊字符，就是case没过和AC的区别。

3.2 第二题：字符串括号匹配

这道题是经典题：给定一个只包含( ) [ ] { }的字符串，判断括号是否匹配。

我用栈来解决：

public static boolean isValid(String s) { Deque<Character> stack = new ArrayDeque<>(); Map<Character, Character> map = Map.of(')', '(', ']', '[', '}', '{'); for (char c : s.toCharArray()) { if (map.containsKey(c)) { if (stack.isEmpty() || stack.pop() != map.get(c)) { return false; } } else { stack.push(c); } } return stack.isEmpty(); }

这道题的边界条件其实就三个：空字符串返回true、遍历完栈不为空返回false、遇到右括号时栈为空返回false。写的时候能覆盖这三种情况，基本就稳了。

不过，搜狗的程序题对输入输出格式有明确要求，比如"输入一行字符串，输出true或false"，但牛客网的系统里，如果你用Scanner读，需要注意末尾可能有换行符或空格，最好trim()一下。我当时就是没trim，结果有一个case怎么都过不去，排查了半天才发现是输入里带了不可见字符。

4. 场景问答题：三道题全是实际项目里会遇到的问题

这三道大题才是整场笔试的区分度所在。我复盘的时候觉得，搜狗出这些题并不是指望应届生能答出完美方案，而是想看你面对一个真实复杂场景时，有没有一套自己的分析框架。

4.1 第一题：输入法候选词排序功能的测试设计

搜狗是做输入法的，所以第一道场景题就是"搜狗输入法候选词排序功能"的测试用例设计。需求描述大概是：根据用户的历史输入习惯和当前上下文，把候选词按概率从高到低排序，前5个展示在候选栏。

这道题我拿到的时候有点懵，因为"候选词排序"听起来不是一个功能，而是一个算法模型。后来我理了一下思路，按照"功能测试+接口测试+性能测试+兼容性测试"四个维度去拆解：

功能测试要覆盖的case包括：正常输入拼音时，候选项是否按概率降序排列；用户选择了第3个候选词后，这个词的权重是否提升，下次排序是否前移；输入上下文变化时（比如打完"我想"再打"吃"），候选词是否根据上下文重新排序；特殊输入（空串、单字符、生僻字）时，候选词是否为空或兜底默认排序。

接口测试要关注：排序接口的入参（用户ID、上下文、拼音串）缺失时，是否返回默认候选；候选词最大返回数量有没有上限；接口超时或异常时，前端是否有兜底展示逻辑。

性能测试要关注：输入法每敲一个字母都会触发候选词请求，所以排序接口的响应时间必须控制在几十毫秒内，否则打字会有卡顿感。

兼容性测试要覆盖：iOS和Android两端候选词排序逻辑是否一致；不同屏幕尺寸下候选词的滚动和展示；第三方输入法嵌入某些App时，候选栏是否被遮挡。

我写完功能测试那一部分就花了不少时间，但我觉得这道题拿分的重点在于"有没有想到上下文和用户行为对排序的影响"，也就是你能不能理解这个功能背后的算法逻辑，而不只是测试表面的UI展示。

经验：测一个带算法模型的功能，千万不要只测"输入输出是否正确"。你得往深了想一层——模型是依赖什么特征做决策的，这些特征变化时，输出会不会跟着变，以及变了之后是否符合预期。

4.2 第二题：新闻App首页信息流的性能测试方案设计

第二道场景题是：新闻App首页信息流，用户下拉刷新时会请求一批新内容，平均响应时间要求小于1秒，请设计性能测试方案。

这道题其实非常考验工程能力。我当时的思路是，一个完整的性能测试方案至少包含这四块：

环境准备：用测试环境还是线上环境？如果线上有真实流量，怎么隔离测试数据？测试机的配置要和线上一致吗？这些都得在方案里写明。

测试数据：模拟多少用户同时刷新？每个用户刷新的频率是多高？是不是要模拟不同网络环境（4G、Wi-Fi、弱网）？不同网络下响应时间肯定不一样，所以测试数据要分层。

监控指标：除了平均响应时间，还要看TP95、TP99（保证绝大多数用户比平均响应时间更慢的感受）、错误率、吞吐量（QPS）、服务端CPU和内存。仅看平均值是一个大坑，因为小部分慢请求会把平均值拉高，但大部分用户感受是好的。

压测执行：用JMeter或者Locust模拟并发，先跑一个小规模的冒烟测试（比如10个并发），确认脚本没问题，再逐步加大到100、500、1000，观察系统在哪个并发量开始出现性能拐点。

我当时在答题时写了一个具体的压测脚本示例（用JMeter的BeanShell还是太啰嗦了，我直接写的伪代码逻辑）：

- 场景：下拉刷新首页信息流 - 并发数：逐步递增 10 → 50 → 100 → 200 → 500 - 每阶段持续时间：5分钟 - 观察指标： - 平均响应时间 < 1s - TP99 < 2s - 错误率 < 0.1% - CPU < 70%，内存无持续增长 - 结论判定：如果某阶段TP99超过2s或错误率超过0.1%，记录此时并发数作为系统瓶颈

这道题的另一个隐藏考点是弱网测试。手机App在生产环境里大量用户是4G网络，尤其在地铁、电梯等场景，网络质量很差。如果只在公司Wi-Fi下测性能，结果完全不能代表线上用户真实体验。所以方案里得包含弱网工具（比如Charles的Throttle设置或者网易的NetTest）来模拟高延迟、高丢包。

4.3 第三题：接口自动化测试框架的设计思路

第三道场景题是：如果让你为搜狗输入法云同步服务设计一个接口自动化测试框架，你会怎么做？

这道题我觉得是三道里最有区分度的。因为很多人可能没用过接口自动化框架，只能写出"用Postman测接口"这种答案。但搜狗显然想招的是有工程能力的人。

我的回答框架大概是这样的：

框架选型：用Java + TestNG + HttpClient（或者Python + pytest + requests），因为Java在搜狗内部用得很多，TestNG的依赖管理和数据驱动比较方便。用HttpClient而不是Postman，是因为Postman更适合手工测试，做不了断言和报表集成。

用例分层：基础请求层（封装公共的请求方法、鉴权逻辑）、业务用例层（每个接口一个测试类，用TestNG的@DataProvider做参数化）、数据层（测试数据写在YAML或Excel里，方便非开发同学维护）。

断言设计：不能只断言HTTP状态码200，还要断言业务字段，比如response里的code是否为0、关键的data字段是否符合预期。我见过太多人接口测试只查status code，结果接口返回200但业务逻辑是错的。

持续集成：写完用例要有CI/CD跑起来，我写的是在Jenkins上配置定时任务，每天凌晨跑一遍全量用例，跑完发测试报告。这样出了问题能第一时间发现，不需要等人来报告。

数据隔离：测试环境要有一套独立的测试账号和数据，不能用线上数据，否则测试数据污染线上，会出大事故。

答完之后我觉得，这道题能不能拿高分，不在于你用了多牛的框架，而在于你有没有把"数据驱动""断言""持续集成""环境隔离"这些工程化关键词说全。搜狗这场笔试，不会考你某个工具的具体API，而是考你有没有完整的工程视野。

5. 从热搜词反推搜狗测试笔试的复习重点

考完之后，我顺手搜了一下"搜狗2020校招测试笔试"相关的内容，发现其他考生回忆的考点里，有几个高频词值得专门准备：Appium、pytest、Jenkins、安全测试、冒烟测试、渗透测试。

这些词其实对应了测试工程师日常工作的几个核心方向。我建议准备搜狗这类大厂测试笔试前，重点复习这几块：

5.1 自动化测试：Appium和pytest是标配

Appium是移动端UI自动化的主流框架，笔试可能不会让你写具体代码，但会问它的架构原理：Appium是通过WebDriver协议转发指令到手机上的UiAutomator或XCUIDriver，所以它能跨平台。你只要理解"客户端-服务端-设备驱动"这个三层架构，就能应付大部分题目。

pytest是Python测试框架，笔试可能考它的fixture机制、参数化@pytest.mark.parametrize、插件化（比如pytest-html生成测试报告）。这些属于Python测试的基础常识，需要会写简单的断言和fixture用法。

5.2 性能和安全测试：要懂基本概念

性能测试的重点是压测工具（JMeter、Locust）和监控指标（TPS、响应时间、错误率、CPU、内存），这个我在场景题4.2里已经详细写了。

安全测试的话，测试岗笔试不会考太深的渗透技术，但会问一些基础概念：比如什么是SQL注入、XSS、CSRF，它们有什么危害，怎么在测试中简单验证。对于应届生来说，知道"安全测试是测什么"比"怎么渗透"更重要。

5.3 冒烟测试：不知道这个，面试现场会露怯

冒烟测试（Smoke Test）这个词，在笔试题里可能作为概念题出现。它的意思是：每次构建出新版本后，先跑一遍核心功能的主路径用例，如果不通过就直接打回开发改，不进入详细测试阶段。这个"冒烟"是一种形象说法——如果新版本连核心路径都跑不通，就像电路板一上电就冒烟了，根本不用再做后续测试。

5.4 设备老化测试和双脉冲测试：硬件测试岗才会考

我在热搜词里看到了"设备老化测试全自动执行脚本"、"双脉冲测试"、"内存RCD SI测试"这些词，这些其实是硬件测试方向的内容。搜狗如果招的是硬件测试工程师，确实会涉及这些。但如果是软件测试岗，大概率不会考这么深。准备笔试前先看清楚岗位JD，别拿硬件测试的题去冲刺软件测试岗，那就白准备了。

技巧：看你投的岗位是"测试开发工程师"还是"测试工程师"，两者笔试侧重点完全不同。测开会更重编程和自动化，测试会更重用例设计和业务理解。搜狗这场笔试题看起来是偏测试工程能力，但编程题的存在意味着它也对代码能力有要求。

6. 校招测试笔试备考的通用方法论：从搜狗这场题反推

考完搜狗这场，我把前面准备其他公司笔试时用的方法也串起来整理了一下。测试校招笔试，本质上逃不出下面这几类，搜狗这场基本全踩了一遍：

6.1 计算机基础是底线，不能偏科

Linux命令、计算机网络、数据库、数据结构，这四门课是测试笔试的四梁八柱。搜狗这场选择题大概有三分之二是这些内容。复习的时候不要只盯着一门刷，每门都要过一遍。网络重点看TCP/UDP、HTTP/HTTPS、DNS；Linux重点看文件操作、日志查看、进程管理、网络排查；数据库重点看SQL查询、索引、事务；数据结构重点看数组、链表、栈、队列、树、图的基础操作和时间复杂度。

6.2 测试理论要跟场景结合，不能只背概念

单纯问"等价类划分是什么"这种题，现在是越来越少了。搜狗这次是直接给你一个输入法候选词排序的功能，让你设计用例。所以准备的时候，要多看真实App功能或者后端接口，然后用等价类、边界值、场景法、错误推测法去拆解。

我自己的训练方法是：打开手机里的任意一个App，选一个功能（比如微信的朋友圈发布），用10分钟时间在纸上写尽可能多的测试用例，然后对照"正常流程、异常流程、边界条件、并发条件、兼容性条件"这五个维度查漏补缺。练个20个功能，测试思维基本就出来了。

6.3 编程题刷的是手感，不是题量

搜狗的两道编程题都是LeetCode简单到中等难度，但真正拉开差距的不是解题思路，而是代码能不能一次性跑通。很多人在本地IDE写得好好的，一贴到在线评测系统就各种问题：Scanner没读完、输出带了调试信息、边界条件没考虑。

这个没有捷径，就是多练。我建议至少提前两周开始，每天在牛客或LeetCode上做2-3道题，重点练字符串、数组、栈/队列、哈希表这几个高频考点。测试笔试的编程题一般是"用代码实现某个小功能"，不太会考特别复杂的动态规划或者图论。

6.4 场景题要形成自己的回答框架

我在4.1和4.2写到的回答结构，其实就是我自己的框架：功能测试、接口测试、性能测试、兼容性测试、安全测试、异常测试。这套框架的好处是，不管题目给出什么样的功能，我都能用这套结构去套，保证不遗漏。

但要注意，套框架不是背模板，框架里的每一个维度，你都应该结合题目场景展开。比如题目给的是"输入法候选词排序"，你就不能只说"验证排序结果是否正确"，还要具体到"用户选择某个候选词后权重如何变化"这种细节。框架保证你的回答结构完整，细节决定你的回答有没有深度。

7. 考完复盘：那些我应该在考场上做得更好的地方

整理完考卷分析，还得诚实面对自己踩过的坑。这场笔试我拿到了面试机会，但回头看，至少有四个地方如果能提前准备，成绩会更好。

第一个是网络报文的细节。三次握手的序列号推导，我在复习时确实看懂了，但考试一紧张就有点懵，在草稿纸上推了两遍才敢选。这类题如果平时不亲自抓包看一下序列号变化的规律，光靠背是记不牢的。

第二个是SQL执行顺序。我准备的时候主要背了"先WHERE再GROUP BY再HAVING"，但题目把ORDER BY和SELECT的执行顺序也加进来问，我就有点犹豫。实际上ORDER BY是在SELECT之后执行的，所以可以使用SELECT里的别名；而HAVING虽然也在SELECT之前执行，但在MySQL里却可以用别名，这个例外容易把人搞晕。建议复习时把标准SQL和MySQL的差异单独列出来。

第三个是场景题的时间分配。我三道场景题里，第一道输入法候选词排序写得特别详细，导致后面两道题的时间有点紧张。现在复盘的话，第一道题点到为止，把主要用例写出来就行，把时间匀给后面的性能测试方案和自动化框架设计，可能整体得分更高。

第四个是编程题的输入处理。我前面提到没trim输入导致一个case没过，这个真的是非常低级的错误。编试题里，输入数据经常带不可见字符，Scanner.nextLine()读出来的字符串，最好直接trim()掉首尾空格和换行符。

最后说说心态。第二场笔试跟第一场最大的区别，是我没有因为第一场考砸了就摆烂，每一道题都当"这题我不会，但我至少要写点什么"来对待。尤其场景题，最怕的是看到题目觉得"这怎么测啊"就空着，你哪怕只写"先测正常流程，再测边界情况"，也比交白卷强。笔试不是要你答出满分答案，而是通过你的回答看到你的思考路径。这个思路，后来我面试时也一直在用。