企业官网建设流程全解析

1. 一份2019年的笔试卷，为什么今天还有参考价值

先说个很多人都有的误区：以为笔试面试题这种东西越新越好，2019年的卷子早该扔进回收站了。真不是这样。

测试岗的笔试和开发岗有个本质区别——开发岗的技术栈迭代非常快，三年前的框架可能已经没人用了；但测试岗笔试的核心，考察的是知识体系的完备度、逻辑思维的严密性和工程落地能力。这三样东西，恰恰不会因为时间推移而过时。2019年快手秋招测试B卷，放在今天来看，依然是测试工程师校招笔试的典型模板，甚至可以说，它基本框定了后面几年各大厂测试岗笔试的考察范围。

我当时拿到这套题的第一感受是：范围很广，但深浅有度。它不像一些公司那样堆砌偏题怪题，而是把测试岗真正需要的底层能力都覆盖到了——从测试基础理论到Linux操作，从数据库到网络协议，从自动化工具到代码能力，再到测试思维的场景题。基本就是一份“测试工程师能力模型”的清单式考察。

尤其值得一提的是，这套题对“测试思维”的考察比重相当大。很多同学复习的时候疯狂刷编程题、背八股文，结果在测试思维题上栽了跟头，这恰恰是校招测试岗最容易被忽视、也最拉分的地方。所以这篇文章我想从头到尾拆一遍这套题，结合当年的实际考察方式和现在的行业现状，聊聊每个板块到底在考什么、怎么复习最有效、哪些坑需要提前避开。

如果你正在准备测试岗的校招笔试，无论是快手还是其他大厂，这套题的含金量都值得你花时间认真过一遍。下面我们直接进入正题。

2. 看透整套卷子的“考点地图”：测试岗笔试到底在筛什么人

在看具体题目之前，先搞清楚一个更底层的问题：快手这样的公司，出这套笔试B卷，到底想筛出什么样的人？

测试工程师这个岗位，在很多不了解的人眼里就是“点点点”，随便一个人培训两周就能上岗。但在大厂的实际工作里，测试工程师是产品上线前最后一道防线，直接对线上质量负责。一个合格的测试工程师，至少要具备四层能力：基础的计算机功底、专业的测试方法论、自动化和工程化能力、解决问题的逻辑思维。快手这套卷子，就是围绕这四层能力设计的。

先从整体结构来看，这套卷子基本上涵盖以下几个板块，我按分值权重和考察频次排了个序：

这个顺序不是随便排的。从实际笔试的通过率来看，测试基础理论是送分题，但也是最容易丢分的地方；计算机基础是拉开差距的关键；自动化测试考察的是有没有真实项目经验；代码题是很多测试岗同学的心理阴影；而测试思维题，则是最能体现一个人“天生适不适合做测试”的试金石。

再拆细一点。测试基础理论部分，考的不是你能不能背出V模型和W模型的区别，而是给你一个实际场景，你能不能设计出覆盖全面的测试用例。计算机基础部分，Linux考的通常是最常用的命令，数据库考的也就是增删改查和join，但题目会用一些特殊场景来考察你理解得深不深。网络部分则是HTTP协议、TCP三次握手这类老生常谈，但也经常出“输入一个URL到页面显示，中间发生了什么”这种综合性题目。

自动化测试这个板块最有意思。笔试很少让你直接写自动化脚本，而是考察你对自动化框架的理解，比如元素的定位方式、等待机制的设计、用例的管理和报告的输出。还会问持续集成怎么和自动化结合起来。这说明什么？说明公司需要的不是会背几个API的人，而是真正理解自动化测试在工程体系中定位的人。

代码与算法部分，说实话对测试岗的要求比开发岗低不少。不会考动态规划、不会考红黑树，更不会让你手撕AVL。常见的就是数组、字符串处理、简单排序、递归这类基础题。但别掉以轻心，基础题也能考出层次感——比如一道看起来简单的字符串反转，可以衍生出内存效率、边界条件、输入校验等很多考察点。

最后是测试思维题，这是整个卷子里最灵活的部分。它可能是一道逻辑推理题，也可能是一个开放性的场景设计题，还可能是一个“如何测试一把椅子”这种经典题目的变体。这类题没有标准答案，但你回答的结构化程度、思维覆盖的全面性，决定了你的分数上限。

看明白这张考点地图，你就会发现，这套笔试筛的不是做题机器，而是基础扎实、有实战意识、思维清晰的准测试工程师。下面我逐个板块拆解备考要点。

3. 测试基础理论：送分题背后的“陷阱”最多

测试基础理论在整套卷子里占比不低，但也是最容易被轻视的部分。很多同学觉得“测试流程谁不知道”，结果一拿到题才发现，自己以为的理解和面试官想要的理解完全不是一回事。

我先列一下这个板块最简单也最容易出现的出题方式：

• 给你一个需求描述，要求设计测试用例
• 考察等价类划分、边界值分析、因果图、判定表这些用例设计方法
• 测试流程相关，比如缺陷的生命周期、测试报告包含哪些要素
• 测试分类，比如按阶段分的单元测试、集成测试、系统测试、验收测试，按方式分的黑盒测试和白盒测试

这些知识点本身不难，但笔试题目会出得很“活”。举个典型的例子：

假设有一个登录功能，输入框要求6-16位字母或数字，请设计测试用例。

这是测试岗笔试里最经典的题目，没有之一。很多人拿到这道题就开始写：“输入正确账号密码，登录成功；输入错误密码，提示错误……”然后写个七八条就交卷了。但这个答案在阅卷人眼里，基本就是不及格的水平。

为什么？因为这道题考察的核心是等价类划分和边界值分析，而且必须覆盖正常流、异常流、边界值、特殊字符、安全性等多个维度。一份完整的用例设计至少应该包括：

• 正常流：输入合法的6位、16位、中间值（比如10位）的账号密码，验证登录成功
• 边界值：5位（过短）、6位（最小合法值）、16位（最大合法值）、17位（过长）
• 异常流：账号为空、密码为空、账号密码都为空
• 特殊字符：输入中文、输入特殊符号（@、#、空格等）
• 格式校验：纯数字、纯字母、数字字母混合
• 安全性：输入SQL注入语句、输入超长字符串导致缓冲区溢出
• 交互逻辑：密码输入错误多次后是否有锁定机制、是否有验证码
• 兼容性：不同浏览器、不同操作系统下表现是否一致

你看，一个看似简单的登录功能，展开写可以写出三四十条用例。这不是在堆数量，而是体现了你的测试思维是否系统化。普通选手和优秀选手的区别，往往就在这里拉开了。

再来说说缺陷管理。笔试里经常考的是“缺陷报告中应该包含哪些要素”。这个很简单，就是标题、前置条件、复现步骤、期望结果、实际结果、严重程度、优先级、附件（截图或日志）。但有些同学会漏掉“复现步骤”或者“附件”，这就是基础不扎实的表现。

还有个高频考点是黑盒测试和白盒测试的区别。这个大家都会背，但题目经常换个问法：“以下哪些测试方法属于黑盒测试？”选项里混入语句覆盖、分支覆盖这些白盒测试的方法，一不留神就选错了。说到底不是不会，而是概念之间没有建立清晰的边界。

我的建议是，复习测试基础理论不要死记硬背，而是拿一个具体的功能（比如登录、购物车、搜索框）完整地走一遍用例设计流程，把等价类、边界值、场景法这些方法实际用一遍。你用过一次，就比背十遍概念都管用。

另外提一句，现在很多公司笔试里会增加一些测试左移和右移的概念题。所谓测试左移，就是测试介入的时间提前，在需求评审阶段就参与进去；测试右移，则是上线后继续关注线上监控和用户反馈。这类题在2019年的卷子里虽然不多，但在近年越来越常见，复习的时候顺着了解一下会有优势。

4. 计算机基础：Linux、数据库、网络是拉开差距的“分水岭”

计算机基础部分，是整个笔试里性价比最高的板块。为什么这么说？因为它的考察范围非常明确，翻来覆去就是Linux、SQL和计算机网络这三样，只要认真复习，拿分是板上钉钉的事。但同时，它也是很多非科班出身的测试同学最头疼的部分。

先说Linux。测试工程师日常工作中离不开Linux——查日志、看进程、操作文件、部署环境，每一项都需要Linux命令的功底。笔试里最常考的是以下几类：

• 文件操作：ls、cd、cp、mv、rm、touch、cat、less、tail
• 权限管理：chmod、chown、chgrp
• 进程管理：ps、top、kill
• 日志查看：tail -f、grep、awk、sed
• 网络相关：netstat、ping、curl、telnet
• 压缩解压：tar、zip、unzip

尤其值得注意的是组合用法。笔试题目经常不会直接问“查看文件的命令是什么”，而是给你一个场景：“线上服务报错了，请写出排查日志的命令。”这时候光会tail就不够了，你得能写出tail -f app.log | grep ERROR这种组合命令。更高阶一点的，还会要求用awk提取特定列、用sed替换文本、用sort和uniq做统计。

举个例子，一道我印象很深的题：

有一个access.log，每行记录包含IP、访问时间、请求URL、状态码。请统计访问次数最多的前10个IP。

这题的解答思路就是用awk提取IP列，sort排序，uniq -c去重统计，再sort按次数反排，最后head -10。全命令写出来就是：

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

这道题本身不难，但它考察的不是单个命令的记忆，而是多个命令串联解决实际问题的能力。这种能力靠背命令列表是练不出来的，必须真的在Linux环境里多操作几遍。

再说数据库。测试岗的SQL考察范围非常简单直接：增删改查、多表联查、聚合统计、基础排序分页。不会考索引优化、存储过程、触发器这些进阶内容。但就是这些基础内容，每年都有很多人丢分。

最容易翻车的是这一类题目：

有两个表：学生表（student）和成绩表（score），请查询所有成绩大于80分的学生姓名。

很多同学一看到就懵了，先join再where，逻辑绕来绕去，最后写出来的SQL要么语法错误，要么逻辑错误。其实正确写法很直接：

SELECT s.name FROM student s JOIN score sc ON s.id = sc.student_id WHERE sc.score > 80;

这道题考的就是多表联查和条件过滤。但我在实际批改中发现，很多同学不是不会SQL，而是不够熟练——平时写SQL的机会太少，一到考场上手生。所以即便你是计算机科班出身，也建议考前集中一周，每天在本地或者在线SQL练习平台上刷二十道题，把常用的语法练成肌肉记忆。

最后是网络基础。这个板块的考察范围非常经典，几乎就是HTTP协议、TCP/UDP、DNS解析、三次握手四次挥手这几件事。

HTTP协议是所有测试工程师的必修课。状态码是必考内容：2xx表示成功，3xx表示重定向，4xx表示客户端错误，5xx表示服务端错误。其中404（资源不存在）、500（服务器内部错误）、301（永久重定向）、302（临时重定向）这些高频状态码的含义，必须做到脱口而出。

还有一个超级经典的综合性大题：

请描述在浏览器中输入一个网址并按下回车后，整个网络请求的过程。

这道题考的是候选人对网络体系的理解程度，一个完整的回答应该是：

1. 浏览器解析URL，提取域名
2. DNS解析，将域名转换为IP地址
3. 浏览器与服务器建立TCP连接，进行三次握手
4. 浏览器发送HTTP请求（请求行、请求头、请求体）
5. 服务器处理请求并返回HTTP响应
6. 浏览器接收响应，解析HTML、CSS、JavaScript
7. 页面渲染完成
8. 连接保持或关闭（四次挥手）

很多同学回答到第4、5步就停了，或者把三次握手和四次挥手的过程搞混。这道题丢分的原因基本就两个：一是流程不完整，二是细节不准确。备考的时候建议自己动手画一遍这个流程，确保每个环节的顺序和描述都准确无误。

计算机基础这个板块的特点是多而杂，但每一项都不深。时间充裕的话系统过一遍教材，时间紧张的话就直接刷题，把常见题型练熟。对于想拿高分的同学来说，这一块是最应该下功夫的，因为它的提分速度最快、确定性最高。

5. 自动化测试与工具生态：笔试问的不是API用法，是工程思维

自动化测试这个板块，在2019年的笔试里主要分布在选择题和简答题中，近些年的比重还在增加。它的考察方向和实际操作非常贴近——不问你怎么用某个工具，而是问你怎么设计一套自动化的测试方案。

我看过不少同学的复习材料，大多集中在Appium怎么启动、Selenium怎么定位元素、Python的pytest或者Java的JUnit怎么写用例。这些当然要会，但笔试并不会出“请写出Appium启动App的代码”这种题。笔试更关心的是你在宏观层面的理解。

举几个高频出题方向：

• 自动化测试的适用场景和局限性
• Web自动化中元素定位的方式（id、name、class、xpath、css selector）以及优先选择顺序
• 等待机制：强制等待、隐式等待、显式等待的区别和适用场景
• 自动化用例的稳定性和数据管理问题
• 持续集成如何与自动化测试结合
• 接口测试和UI测试的区别及各自的定位

拿元素定位来举例。很多同学一上来就只知道用xpath，但实际项目中xpath的维护成本非常高，页面稍有改动，xpath可能就失效了。行业内比较推荐的优先级是：id优先，其次是name、class，再考虑css selector，最后才是xpath。这个逻辑背后的原因是稳定性：id和name一般是开发人员显式定义的，轻易不会变化；而xpath依赖于页面的DOM结构，层级变了就断了。

这个细节在笔试怎么考呢？给一个HTML片段，里面有几个定位属性，问你应该用哪种方式定位更合适。知道优先级背后的原理，这种题就是送分；只会背API的，就只能靠猜。

再来说等待机制。这几乎是自动化测试面试和笔试里必出的一题，三种等待方式的区别一定要说清楚：

• 强制等待（sleep）：固定时间等待，无论元素是否已经出现，简单粗暴但效率低
• 隐式等待（implicitly_wait）：设置一个全局等待时间，在查找元素时轮询等待，但只能处理元素存在性的等待
• 显式等待（WebDriverWait）：针对某个特定元素设置等待条件和超时时间，可以处理元素可见、可点击等复杂条件

笔试常出的场景是：“页面加载较慢，元素需要动态出现，用哪种等待方式更合理？”正确答案是显式等待，因为它在效率和稳定性之间取得了最佳平衡。但很多同学会答隐式等待，这其实忽视了隐式等待对页面加载和元素查找的全局影响。

关于自动化测试和持续集成的结合，考察方向主要是：Jenkins配置定时任务、自动化用例在流水线中的触发时机、测试报告的生成和展示、失败用例的自动重跑机制。这一块需要你真正在项目里做过一遍，光看文档很难形成体感。

有同学可能会问，2019年的卷子会不会不考Appium这些工具？答案是要考的，但考的是理解层面，不是应用层面。比如Appium的架构原理（客户端通过WebDriver协议与Appium Server通信，Server再通过各平台的自动化驱动操作设备）、iOS和Android在自动化上的差异（class name、权限弹窗处理方式不同等）、真机和模拟器测试的区别（覆盖面、速度、稳定性）。这些内容，光刷题是刷不出来的，需要你至少搭建过一次完整的自动化测试环境。

我说句实在话，自动化测试这个板块，笔试只是开胃菜，真正的考验在面试和入职之后。但笔试阶段能把工程思维体现出来，就已经能打败一大半候选人了。备考的时候别只盯着某个工具学，多问自己一句：**为什么这个工具要这样设计？它在整个测试体系中的定位是什么？**带着这种思路去复习，效果会完全不同。

6. 手写代码与算法：测试岗的编程题，考的是“不出错的能力”

很多准备测试岗的同学对代码题有种天然的恐惧，觉得“我又不开发，为什么要写代码”。实话说，这种心态如果不调整，笔试大概率会吃亏。

我一直认为，测试工程师写代码的能力，甚至比开发工程师更要求“稳”。开发写错一个逻辑可能上线后才会暴露，但测试写错一个脚本，可能导致整个回归测试的结果失真，比不测还危险。所以测试岗的代码题，考察的核心不是你会不会复杂的算法，而是在基础问题上能不能一次写对、边界条件覆盖全、代码风格清晰。

快手这套卷子的代码题，难度上限也就是LeetCode的简单到中等偏下水平。常见的出题方向包括：

• 字符串处理：反转、去空格、统计字符出现次数
• 数组操作：去重、排序、查找最大值最小值
• 基础算法：冒泡排序、二分查找、递归求斐波那契数列
• 简单数据结构：用数组实现栈、用两个栈实现队列

但考得简单不代表容易拿分。我见过太多人，写代码的时候不考虑边界条件，比如数组为空、字符串为null、数值越界，一写就崩。这恰恰是测试工程师最不能犯的错误——一个不考虑异常输入的测试脚本，本身就是有缺陷的。

举个例子，一道看起来很简单的题：

写一个函数，判断一个字符串是否是回文字符串。

正常思路是双指针从两端向中间遍历，这是标准解法。但你能不能在代码里处理空字符串、单字符串、大小写混合、带空格和标点的字符串？如果你的函数一上来就假设输入一定合法，那这段代码的质量就打了折扣。笔试阅卷人会根据你的容错意识来判断你的工程素养。

再比如数组去重那道题，很多人上来就写两层循环，时间复杂度O(n²)。这种解法不是不能过，但如果你能写出利用Set或者哈希表的O(n)解法，并且解释清楚为什么在数据量大的情况下O(n)更优，这就能让阅卷人眼前一亮。这不需要你有多深的算法功底，只要你有这个意识。

还有一点值得提醒：笔试写代码，千万别只在脑子里跑一遍就交卷。我自己的习惯是，写完代码后在草稿纸上手动模拟几个典型输入（正常值、边界值、异常值），跟着代码逻辑一步一步跑，确认没有语法错误和逻辑漏洞再提交。这个习惯在笔试中能帮你避免至少三分之一的低级错误。

至于是否需要专门刷算法题，我的建议是：如果时间充裕，LeetCode简单题刷50道，中等题刷30道，足够覆盖测试岗笔试的代码题范围。如果时间紧，就把字符串、数组、基础排序和递归这几类高频题型练熟，不要碰动态规划、图论这些进阶内容。

说到底，测试岗的编程题是“能力下限测试”——不是看你能跳多高，而是看你基础够不够稳。心态放平，把基本功打扎实，这部分的分数是完全可以拿满的。

7. 测试思维的场景题：答得“全”比答得“准”更重要

接下来聊整套卷子里最有趣，也是最拉分的部分——测试思维场景题。

这类题可能是一道逻辑推理，也可能是一个“你怎么测试某功能”的开放题目。它们没有标准答案，但通过你的回答，阅卷人能判断出你是否具备测试人员最核心的素质：结构化思维、发散性思维和批判性思维。

先看一个最经典的开放题变体：

给你一个电梯，你怎么测试它？

我第一次见这道题是在某大厂的一面，当时愣了一下，脑子里全是“按楼层按钮、看电梯能不能到”，回答得毫无章法。后来才明白，这种题考察的不是你懂不懂电梯，而是你有没有一套系统的测试方法论。

一个高分回答应该按维度拆解：

• 功能测试：楼层按钮、开关门、超载报警、紧急呼叫、楼层显示、运行方向指示
• 性能测试：满载运行速度、开关门时间、连续运行的稳定性、高峰期运载效率
• 压力测试：超载临界点、连续长时间运行是否过热保护
• 安全测试：停电时应急处理、困人故障报警、防火门联动、防夹功能
• 兼容性测试：不同类型的用户（老人、小孩、残疾人）、不同使用场景（搬运大件物品、推婴儿车）
• 边界测试：最顶层和最底层的停靠逻辑、多电梯联动时的调度算法

你看，一旦按维度拆解，思路就清晰了。这个逻辑不仅适用于电梯，任何“你怎么测试xxx”的问题都可以套用。笔试和面试官想看到的不是你背出某个标准答案，而是你面对一个陌生对象时，能不能快速建立测试框架。

还有一类思维题，考的是逻辑推理能力。比如：

8个球，其中有1个重量不一样，其他7个重量相同。用天平最少称几次能找出这个球？

答案是两次。思路是：把8个球分成3、3、2三组。第一次称3个对3个，如果平衡，则重量不同的球在剩下的2个里，第二次称一次就能找出；如果不平衡，则确定范围在轻的那一组3个里，第二次从3个中任取2个称量，就能锁定目标。

这种题目本身是小学数学思维题，但它出现在测试卷里，背后是有逻辑的——测试工程师每天都在做类似的“二分定位”工作，从大量看似正常的现象中，用最少的步骤定位到问题的根因。考的是思维方式，不是计算能力。

还有一类常见的考察方式是给一段产品描述，要求列出需要测试的点。这种题目的关键是思维覆盖的广度。比如给你一个视频App的“发布视频”功能，大多数人都能想到测试视频上传、封面选择、文案编辑这些主流程。但高分答案会额外覆盖到：弱网环境下的上传行为、视频格式兼容性（mp4、avi、mov）、超长视频的处理逻辑、存储空间不足时的提示、发布过程中切换后台的处理、重复点击发布按钮的防重处理。

这里我分享一个我的独家框架——测试点设计的六个维度，可以套用到任何场景题中：

• 正常功能：用户的常规操作路径是否按预期工作
• 异常处理：极端输入、非法操作、系统异常时是否有合理反馈
• 边界条件：数据的最大最小值和临界值
• 性能表现：响应时间、并发量、资源消耗
• 兼容适配：不同设备、版本、分辨率、浏览器
• 安全合规：权限控制、数据隐私、敏感信息处理

用这个六个维度去套任何场景，基本不会漏掉关键测试点。我后来在带团队的时候，也是用这个框架去培训新人设计测试用例，效果比看教材好得多。

场景题还有一个容易忽略的加分项：优先级思维。当你列出了一堆测试点之后，如果能主动说明哪些先测、哪些后测、哪些可以在时间不够的情况下适当取舍，这会让阅卷人觉得你有真实项目的经验，而不只是会背模板。比如“核心功能优先回归，边缘功能可以放到第二优先级”这样一句话，就能体现出你对测试风险控制的理解。

8. 针对这套卷子的完整备战路线与实战建议

前面拆了这么多，最后聊点实在的：如果我现在要准备这套笔试，我会怎么规划复习。

先说时间安排。假设你有一个月的完整准备时间，我建议这样分配：

第一周主攻测试基础理论。把所有用例设计方法过一遍，拿登录、购物车、搜索框三个经典功能练习用例设计，每天写一道场景题。这一周的目标是把测试基础分拿稳。

第二周主攻计算机基础。Linux和SQL重点刷题，网络协议理解为主。每天抽两小时动手操作Linux命令，一小时做SQL练习题。周末把“输入URL到页面显示”的完整流程画三遍，确保流程图烂熟于心。

第三周主攻自动化和代码题。搭建一次Appium或Selenium的自动化测试环境，跑通一个最简单的自动化用例，感受工具的完整工作流程。代码题每天刷3-5道LeetCode简单题，重点练字符串、数组和排序。

第四周查漏补缺。把前几周的错题重新做一遍，找一套近两年的真题模拟考试，严格按照笔试的时间限制来。重点练习如何在时间压力下保持冷静，合理分配每道题的作答时间。

再说做题策略。笔试的时间通常是比较紧张的，我自己的做题顺序是：先做自己熟悉的、确定能拿分的题目；再做需要思考的中等难度题；最后啃不确定的压轴题。遇到不会的题不要死磕，在做题前先把整张卷子扫一遍，对题量和难度做到心中有数。

还有一个很多人忽视的细节：笔试中的简答题，书写工整度和结构化程度真的会影响分数。同样一道测试用例设计题，一个答案是一坨文字堆在一起，另一个用“正常流、异常流、边界值”分点列出来，后者在阅卷体验上高出不止一个档次。哪怕内容一模一样，结构化表达也能让你多得几分。

最后送大家一个终极备考心法：不要只为了通过笔试而复习，而是借这次机会，真正把测试工程师的知识体系搭建起来。这套卷子之所以值得认真对待，是因为它覆盖的内容，就是入职之后每天都要用的东西。Linux命令你会天天敲，SQL查询你会天天写，用例设计你会天天做，自动化脚本你会天天维护。笔试只是检验你具不具备这些基本功，而真正的成长，是在每一次踩坑和复盘之后。

祝每一个认真准备的测试er，都能拿到心仪的offer。