搜狗2020校招测试岗笔试第一场，我到现在还记得那套题的风格——不堆砌偏题怪题，却能在两小时内把你的真实水平摸得明明白白。后台也一直有学弟学妹问这类校招测试笔试到底考什么、怎么准备，今天就把这轮笔试的考察结构、核心知识点、场景题套路和编程题思路完整拆一遍。无论你是正在备战校招的应届生，还是想从功能测试转测试开发的老手，这份复盘都能帮你把"测试笔试到底在考什么"这件事理顺。
这轮笔试整体给人的感觉是：题型跨度大但层次清楚，既有送分的基础题，也有专门拉差距的综合题。如果你只是背了几道测试理论题就上场，大概率会在场景设计和编程题上卡住。反过来，如果你有实际项目经验，哪怕题没刷完，也能靠思路拿分。下面我按模块把笔试内容拆开讲，每一块都会说清楚考什么、为什么考、怎么答才稳。
1. 笔试整体架构与考察重点回顾
1.1 题型分布与时间分配
这轮笔试的题型大致分四类：选择题与判断题、简答题、测试场景设计题、编程题。选择题覆盖计算机网络、操作系统、数据库、数据结构这些计算机基础，偶尔穿插一两道测试理论；简答题主要考测试基础概念，比如黑盒白盒的区别、测试的生命周期；场景设计题是重头戏，要求针对某个具体功能写出完整的测试用例；编程题通常是两道左右，难度在LeetCode中等偏下，但要求手写且思路清晰。
整体时间大概两小时，我个人建议的分配比例是：选择判断题控制在30分钟内，简答题20分钟，场景设计题40分钟，编程题留出30分钟。实际考试中，很多人折在时间分配上——前面选择题纠结太久，后面编程题只能草草收场。我的经验是：选择题里拿不准的，先按第一印象选，做个标记，全卷写完再回头琢磨。
这轮笔试的题目量不算特别大，但信息密度高，尤其是场景题，一个题目里往往埋了三四个隐藏需求。审题一定要慢，落笔一定要快。我见过太多同学一上来就写用例，写到一半发现把需求理解偏了，整段重来，非常浪费时间。
1.2 从笔试题看测试团队的用人倾向
这套题出得挺有水平，它不考死记硬背的概念，而是考你能不能站在一个测试工程师的角度去思考问题。比如简答题里不会直接问"什么是回归测试"，而是给你一个版本迭代场景，问你哪些用例需要回归、怎么评估回归范围。这种问法背后的潜台词是：团队需要的不只是会执行用例的手，而是能思考"为什么测这些、怎么测更高效"的人。
另外，编程题的存在本身就传递了一个信号——搜狗的测试岗位不是纯手工测试，而是要求具备测试开发能力的。你可以用任何语言写，但代码质量、边界处理、思路清晰度都会被综合评估。这跟行业趋势是一致的：测试岗位的门槛正在向"测开一体化"靠拢，只会点功能测试已经很难过了。
还有一个细节值得注意：整套题里没有出现任何偏门框架或工具题，而是聚焦在计算机基础、测试方法论和逻辑思维上。这说明笔试阶段他们不指望你什么工具都会，工具可以进公司再学，但基础不牢就很难补。这也是我给所有备战校招的同学的建议——优先夯实基础，工具和框架是锦上添花。
2. 测开基本功：核心知识点逐项拆解
2.1 测试理论基础与用例设计方法
测试基础理论是笔试的基本盘。黑盒测试和白盒测试的区别、测试用例的八大要素、缺陷的生命周期、测试计划包含哪些内容，这些属于必背内容，送分题不能丢。但真正拉开差距的是用例设计方法——等价类、边界值、因果图、判定表、场景法、正交实验，你得知道每种方法适合什么场景，并且能在题目里综合运用。
举个例子，笔试题里如果让你测一个"用户注册"功能，很多人的第一反应是列出账号、密码、手机号、邮箱这些字段，然后每个字段写几条正常和异常用例。这种答法只能拿基础分。更好的做法是：先用等价类把输入域划清楚，再用边界值把每个等价类的边界卡死，比如密码长度6-20位，那5、6、7、19、20、21这六个值必须覆盖；然后考虑业务规则之间的组合，比如用户名已存在、密码过于简单、验证码错误，这些属于流程异常分支，要用场景法把主流程和备选流程都走一遍。
我当时刷题的一个体会是：不要背用例，要背"设计用例的方法"。方法掌握以后，不管题目换成什么功能，你都能往里面套。另外，边界的选取要结合业务语义，比如金额的边界是0.01和最大限额，而不是只看数据类型；字符串的空值、空格、全角半角、超长输入这些边界，也需要刻意积累。
2.2 计算机网络考点盘点
测试工程师笔试里的网络题，不会像开发岗那样深挖TCP拥塞控制的数学推导，但基本概念必须扎实。高频考点集中在：TCP和UDP的区别、三次握手四次挥手过程及状态变化、HTTP和HTTPS的区别、HTTP常见状态码含义、GET和POST的区别、Cookie和Session的区别、DNS解析过程。
这轮笔试里有一道题是给一段网络抓包日志，问你TCP建连过程分别对应第几个包、每个包里的标志位是什么。这类题在平时可以这样练：用Wireshark抓一次自己访问网页的包，对照三次握手的时序图看一遍，印象会非常深刻。纯靠背状态转换图也能过，但遗忘速度快。
关于GET和POST的区别，现在面试官和笔试都越来越不喜欢教材上的标准答案，而是希望你结合应用场景说。比如GET请求参数在URL里，有长度限制，会被浏览器缓存，适合幂等的查询操作；POST请求参数在body里，相对安全，适合提交数据。笔试答题时尽量从语义层面答，再结合场景举例，会比只列三个"官方区别"得分高。
2.3 Linux与命令行笔试高频题
Linux命令是测试岗笔试的常客，毕竟后端日志查看、环境部署、自动化脚本执行都离不开命令行。高频考点包括：文件操作（ls、cd、cp、mv、rm、find）、权限管理（chmod、chown、chgrp）、进程管理（ps、top、kill）、网络命令（ping、curl、netstat、telnet）、文本处理（grep、sed、awk、sort、uniq、tail、head）、压缩与打包（tar、zip、gzip）、系统资源查看（free、df、du）。
笔试里最常考的形式是"给定一个场景，写出对应的命令"——比如"统计日志文件中某关键字出现的次数"、"查找当前目录下所有大于100M的文件"、"查看某端口是否被占用"。这类题的答案通常不唯一，但考察点很明确：你知道用什么命令完成什么目标，并且能组合起来处理真实问题。
我建议你把这些命令按"目的"整理成速查表，而不是按命令本身排列。比如"我想看日志"对应的命令组合是tail -f、grep、awk，"我想查服务状态"对应ps -ef|grep xxx、netstat -anp|grep port，这样记忆负担小，答题也快。笔试时如果记不清某个参数，写一个能解决问题的替代方案也比留空强。
2.4 数据库与SQL考察方式
数据库题在测试笔试里几乎必考，主要围绕SQL编写展开。高频场景包括：单表查询（where、order by、group by、having）、多表连查（inner join、left join、right join）、子查询、聚合函数、去重、分页、增删改查。有些严格一点的笔试还会让你写一条"查出每门课成绩都大于80分的学生姓名"这类经典题目，考查分组和条件的嵌套。
这里有个很容易踩的坑：很多人写SQL时只在脑海中模拟数据量很小的情况，没考虑重复数据、NULL值、空表这些边界。笔试阅卷虽然不执行代码，但要展示你对边界条件的考虑。比如分组统计时，NULL字段会被group by单独分到一组，这在统计结果里经常是隐藏bug。
推荐刷题方式是：去在线SQL练习平台每天写10条，重点练连表查询和子查询，因为这是笔试区分度的重灾区。还可以尝试把需求先翻译成中文逻辑，再翻译成SQL，这样思路不容易乱。
3. 场景题与手写测试设计：真正拉开差距的地方
3.1 测试场景设计的答题套路
场景题的典型形式是："请针对XX功能设计测试用例，至少写15条"。这个XX可能是搜索框、购物车、文件上传、扫码支付、消息推送，几乎覆盖互联网产品的常见功能。很多人一看到"至少写15条"就慌了，其实只要按套路走，30条都写得出来。
我有一个用了很久的答题框架，分六层：功能测试、界面测试、易用性测试、兼容性测试、安全性测试、性能及异常测试。每一层都往下钻：
- 功能层先走主流程：正常输入得到正常结果；再走分支流程：取消、删除、断网、超时、重复提交。
- 界面层关注布局、文案、错别字、提示语是否清晰、按钮状态是否置灰。
- 兼容性考虑不同操作系统、浏览器、分辨率、机型。
- 安全性考虑越权访问、SQL注入、XSS、敏感信息明文展示。
- 异常场景考虑弱网、无网、服务器异常、返回超时。
- 数据维度考虑边界值、超长输入、特殊字符、空值、重复数据。
以"搜索框"为例，用这个框架可以轻松写出覆盖正常搜索、空搜索、特殊字符、超长关键词、连续空格、前后空格、搜索结果为空、搜索历史、热门推荐、点击搜索按钮、回车触发、弱网、断网、服务器超时、大量并发搜索等20多条用例。关键在于你不是想到哪写到哪，而是按维度枚举，这样既不容易漏也不会乱。
3.2 自动化测试思路题怎么做
自动化相关的内容在笔试中一般不会让你直接写Appium或pytest代码，更常见的问法是："如何对XX功能做自动化测试？请描述你的实现思路。"这类题考的不是代码能力，而是你对自动化测试体系的理解：选型、分层、用例管理、报告输出、持续集成。
比如问"如何对登录功能做自动化测试"，建议按层级来答。第一层说清楚UI自动化用什么框架（比如Selenium、Appium），怎么定位元素、怎么处理等待；第二层说清楚接口自动化怎么做，把登录抽象为一个接口用例，用pytest管理数据驱动；第三层说清楚怎么集成到CI/CD流水线里，什么时候跑冒烟集、什么时候跑全量回归。如果能说到登录验证码怎么处理（接口层屏蔽、测试环境关闭、万能验证码），就是加分项。
还有一个容易忽略的点：自动化用例的稳定性设计。笔试里如果问"用例偶尔失败怎么排查"，考察点其实是等待策略（显式等待vs强制sleep）、测试数据隔离、用例依赖管理。这些属于实战经验，没跑过自动化测试框架的人很容易答空，所以建议在准备阶段自己搭一个小型pytest项目，哪怕只有10个用例，也能把fixture、conftest、断言、报告这些概念串起来。
3.3 安全测试和性能测试的入门考点
安全测试和性能测试在笔试中占比不高，但出现频率很高，属于"懂的人能拉开差距，不懂的人只能瞎编"的模块。安全测试的入门考点主要是：SQL注入、XSS、CSRF、越权访问、文件上传漏洞。笔试常考的是"给一个接口，你会做哪些安全测试"，或者"列举你听说过的主流Web安全漏洞"。
性能测试的考点更偏概念和流程：性能测试的类型（负载测试、压力测试、并发测试、稳定性测试）、常用指标（QPS、TPS、响应时间、吞吐量、错误率、CPU使用率、内存使用率）、性能测试的大致流程（脚本录制、参数化、场景设置、监控、分析调优）。高频简答题是"发现系统响应时间过长，你如何定位问题"。
这类题不需要你实际做过性能项目才能答，但需要你理解测试目标。比如回答"如何定位响应时间过长"，可以从前端、网络、后端三层拆解：先看是否资源加载耗时，再看是否网络拥塞，最后看后端接口耗时和数据库慢查询。分析链路清晰，比堆砌术语更容易拿高分。
4. 编程题与手撕代码：比的是熟练度不是智商
4.1 高频算法题整理与思路
搜狗测试笔试的编程题，一般不会上动态规划、图论这种对测试岗位来说过于偏门的算法，更多集中在：字符串处理、数组操作、链表、栈与队列、二分查找、简单递归、哈希表去重。难度大概在LeetCode简单到中等之间，但限时手写，考察熟练度。
有一类特别高频的题是"字符串中第一个不重复的字符"、"反转链表"、"有效的括号"、"合并两个有序数组"这类经典题。我的建议是：笔试前一周把LeetCode Top 100里的简单题和中等偏下题过一遍，重点看双指针、哈希表、栈这三种数据结构对应的题型，测试岗的算法题基本绕不开这些套路。
写代码时还要注意风格。即使是在笔试中，变量命名、缩进、注释也展示了你的工程素养。建议从第一行就保持规范的命名，不要在最后"整理代码"。另外，不要在核心逻辑里写一堆无用的判断分支，代码要简洁清晰，让阅卷人一眼看懂你的思路。
4.2 手写SQL与Shell脚本
除了算法编程题，测试笔试偶尔还会让你手写SQL和Shell脚本。SQL前面讲过了，Shell脚本的常见题目是"写一个脚本，监控某个进程是否存在，不存在则告警"或者"统计日志文件中某字段的出现次数并排序"。这类题目的考点是命令组合和基本语法：变量、循环、函数、if判断、定时任务。
我的经验是，准备一个常用Shell模板：文件开头声明#!/bin/bash，定义日志函数，逻辑入口用main函数包起来，这样即使忘记个别命令参数，整体结构也在，能拿基础分。如果完全忘了某个命令的写法，可以用sleep + ps + grep等兜底组合实现类似效果，尽量别留白。
另外，SQL和Shell的笔试答案最好加上注释，说明"这条语句的目标是XX"，既方便阅卷人也显得专业。有时候你的SQL写得不是最优解，但注释里体现了清晰的分析思路，反而比闷头写一大段强。
4.3 写用例时的代码规范问题
这里说的"代码规范"不是指编程题，而是指测试场景设计题里，如果你需要用伪代码或脚本片段来描述校验逻辑，同样要注意规范。比如让你设计一个"校验身份证号"的测试方案，你可以在用例里加入类似"正则匹配^[1-9]\d{5}(18|19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])\d{3}[\dXx]$"的描述，这比一句话带过更显专业。
笔试阅卷时，语言表达清晰度直接影响印象分。场景题中建议用表格或清单式的方式列出用例，每条用例包含前置条件、操作步骤、预期结果三列。这三大件缺一不可，不要只写"输入错误密码，提示错误"，要写清楚前置环境、输入数据、期望提示文案。
5. 备考复盘与避坑指南
5.1 我在准备过程中踩过的坑
第一次准备测试岗笔试时，我犯过一个典型的错误：花大量时间刷测试理论题，把"等价类""边界值"的定义背得滚瓜烂熟，结果一到场景设计题就眼高手低。后来才意识到，理论是工具，不是答案。真正要练的是拿到一个具体功能后，能不能迅速把它拆解成多个可执行的用例。
第二个坑是忽视了计算机网络和操作系统的基础题。总以为测试岗不会深挖这些内容，结果笔试时选择题里一半以上都是基础题。尤其是Linux命令和HTTP状态码，几乎是送分题，如果因为没复习而丢分，非常可惜。现在回过头看，准备校招笔试应该以计算机基础为主，测试理论为辅，不能本末倒置。
第三个坑是编程题没限时练习。笔试和平时刷题的区别是：实时答题、有压力、需要一次写对。如果你平时刷题不计时、不手写，到了笔试现场很可能因为紧张而卡壳。建议找一套历年题，严格按两小时时间模拟一遍，再复盘失分点。
5.2 校招测试岗笔试的通用建议
如果你现在才开始准备，我建议按优先级排序：先补计算机基础（网络、操作系统、数据库、数据结构），这是笔试的大头；再刷测试基础题和场景设计题，这是你区别于纯开发候选人的地方；最后刷编程题，保持手感。工具框架可以等笔试通过后再深入。
还有一点心态上的建议：测试岗笔试考的是"质量思维"和"工程思维"，不是考天才。如果你觉得某道场景题不知道怎么答，先回到最本源的思路——用户会怎么用这个功能？哪里可能出问题？怎么证明它没问题？这三个问题想清楚了，题就答出来一半。
另外，准备一个属于自己的"用例设计模板"，把上面说的六层框架（功能、界面、易用性、兼容性、安全、性能）记在脑子里。不管笔试还是面试，这个模板都能让你瞬间进入状态，不用临场想。
5.3 从笔试到面试的衔接准备
笔试结束到面试通知之间，往往只有几天时间，这个窗口期不要干等。把笔试里的错题重新整理一遍，特别是那些"看了答案才恍然大悟"的题，这些都是你知识体系的漏洞。面试官常问的"你笔试里那道题是怎么想的"，其实是在考察你有没有复盘能力。
我当时在笔试结束后做的第一件事，是把场景设计题里没写完整的用例重新补全，然后模拟面试官追问："哪些用例优先级最高？哪些场景可以自动化？"把这些想清楚以后，面试时遇到类似问题就非常有底气。
还有一个小技巧：准备几个真实项目里的测试故事。面试官更想听到的是你怎么在项目中发现问题、推动解决，而不是背概念。笔试刷题帮你过关，面试讲故事帮你拿offer，两者要并行准备。
最后再分享一个我在笔试和面试中反复用到的思路：测试工程师的核心竞争力不是"会找bug"，而是"能系统性地找到重要的bug"。笔试里的每一道场景题、每一个边界值、每一种异常分支，本质上都在考这个能力。把这个主线想清楚，你会发现刷题不再是死记硬背，而是在训练解决问题的肌肉记忆。
