最近团队招人，我把早几年的秋招笔试题翻出来当模拟卷用，其中有一份爱奇艺2019秋招测试开发方向笔试题（B），网上还能找到不少回忆版。花了一个晚上完整复盘了一遍，最大的感受是：虽然过去了好几年，大厂测试开发笔试的考察框架几乎没有变——编程题考算法和代码功底，客观题考操作系统、网络、数据库这些计算机基础，主观题考用例设计和场景分析。尤其是测试开发这个岗位，比纯后端开发更看重“代码能力+测试思维”的复合度。
这篇文章不打算逐题报答案，那没有意义。我想做的是把这类笔试题背后的考察逻辑、每类题型的应对思路、以及我后来在实际工作里反推出来的准备方法，全部拆开讲清楚。无论你是正在准备秋招春招的应届生，还是想从功能测试转测试开发的同行，或者是已经入行想查漏补缺的测试工程师，这份复盘应该都能派上用场。
1. 测试开发笔试题的考察底色：先搞清楚这场考试在考什么
1.1 爱奇艺这类视频平台对测试开发的特殊要求
先说一个很多人会忽略的点：同样叫“测试开发”，不同行业的考察侧重点其实差很多。电商公司爱考高并发下单场景，金融公司爱考资金安全与状态一致，而爱奇艺这种视频平台，核心业务是内容播放和用户增长，所以笔试题里会明显偏向视频播放链路、会员权益、评论弹幕、推荐排序这三类业务场景。
这意味着什么？意味着你备考时不能只刷通用的数据结构题，还得站在“视频类产品测试”的角度去准备。比如让你设计一个“视频起播”功能的测试用例，你要能想到弱网条件下的秒开率、首帧渲染时间、断点续播状态、分辨率切换逻辑、多端登录互踢等场景，这些在通用的测试理论书里不一定讲得细，但在实际笔试里很拉分。
回到这份B卷本身，从题型分布来看，它基本沿用了当时大厂测试开发笔试的主流模式：单选多选覆盖计算机基础和测试理论，两三道编程题考察代码实现能力，还有一道或两道大分值的用例设计/场景分析题。整套题做下来，与其说是考察“你背了多少知识”，不如说是在筛选“你有没有具备一个测试开发的基本思维框架”。
1.2 整张卷子的题型配比与答题节奏建议
我记得这份卷子总体上分为客观题和主观题两大部分。客观题数量不算少，考点集中在：计算机网络（TCP/UDP、HTTP状态码、DNS解析流程）、操作系统（进程线程、死锁、内存管理）、Linux常用命令、数据库SQL编写与索引优化、数据结构与算法基础、软件测试基础理论（测试用例设计方法、缺陷生命周期、自动化测试模型）这六个模块。
主观题里，编程题通常是两道，一道偏字符串/数组处理，一道偏数据结构（链表、二叉树这类），都需要写完整代码并考虑边界情况。最后是测试用例设计大题，我记得是围绕一个视频相关功能展开的，要求设计测试用例并说明测试重点。
这里我特别想强调答题节奏。这类笔试通常是两小时左右，但如果你在选择题上磨蹭太久，后面编程和用例设计基本写不完。我后来给团队新人做模拟笔试时，总会建议一个时间分配比例：客观题控制在40到45分钟，编程题每题控制在20到25分钟，最后留30到35分钟给用例设计大题。也就是说，客观题要会就会、不会就猜，千万别纠结，因为后面两道编程题随便写完都比选择题多拿好几分。
2. 代码题复盘：算法只是壳，测试思维才是魂
2.1 出现频率最高的几类编程题
爱奇艺笔试题里的编程题，风格上比较接近LeetCode中等难度的题目，很少出纯Hard题，但会在简单题里埋细节坑。以当年的笔试题风向来看，出现频率最高的题型大概是这四类：
- 字符串处理：字符串匹配、去重、翻转、最长子串、括号匹配这类。这类题考察的是你对字符边界、空串、大小写这类细节的处理能力。
- 数组与双指针：合并有序数组、两数之和变种、移动零、判断回文串等。双指针是性价比最高的算法思路，掌握好能解决不少数组题。
- 链表操作：反转链表、删除倒数第N个节点、判断环形链表。这类题考察的是指针操作功底，也是面试官喜欢追问细节的题型。
- 二叉树遍历：前中后序遍历、层序遍历、最大深度。二叉树题往往是“能不能写出递归基线条件”的分水岭。
有意思的地方在于，招测试开发时考察算法，并不指望你像一个算法岗候选人那样把动态规划玩出花来。笔试官想看到的是：你写代码是否规范，边界条件是否考虑周全，以及“如果让你给这个方法写测试用例，你能不能说出该测哪些输入”。
2.2 一道典型的字符串处理题的两种解法
我挑一道当年类似风格的题目来拆解：给定一个字符串，找出第一个只出现一次的字符，返回它的下标，不存在则返回-1。这道题放在LeetCode里就是简单题，但笔试里能拉开差距的点往往在两个地方：时间复杂度和对“字符集范围”的把握。
最直接的解法是用哈希表记录每个字符出现的次数，然后再次遍历字符串找到第一个count为1的字符。代码如下：
def first_unique_char(s: str) -> int: from collections import Counter count = Counter(s) for i, ch in enumerate(s): if count[ch] == 1: return i return -1再往下想，如果字符串只包含小写字母，可以优化成固定大小的数组来替代哈希表，避免哈希冲突的开销：
def first_unique_char(s: str) -> int: count = [0] * 26 for ch in s: count[ord(ch) - ord('a')] += 1 for i, ch in enumerate(s): if count[ord(ch) - ord('a')] == 1: return i return -1这两种写法笔试中都能拿分，但如果你能顺便补一句“如果用数组替代哈希表，前提是明确字符集范围，而且空间复杂度从O(k)变成O(26)”，这个表达会很加分。因为测试开发的工作中，你不仅要写代码，还要能解释代码在不同输入下的表现，这正是面试官想看的素质。
2.3 为什么练习算法题时要刻意加上“测试视角”
很多候选人刷题时只关注“通过率”和“运行时间”，但我一直建议准备测试开发岗的同学，在刷完每道题后多问自己三个问题：这个方法在空输入下会怎样？在超长输入下会不会溢出或超时？如果有重复元素，结果会被影响吗？
这三个问题是面试官特别喜欢在笔试之后的面试环节追问的。比如你会写反转链表，但面试官问你“如果链表只有一个节点，你的代码会不会崩？”如果你只在LeetCode上刷过题，可能没太注意这个细节，因为测试用例已经帮你覆盖了。但在笔试手写代码时，没有在线判题系统帮你兜底，你必须在写代码的过程中就主动考虑这些边界情况。
我开始带新人后，会让他们专门维护一个“边界情况清单”：空值、单元素、全相同、全不同、极大极小值、字符串含空格和特殊字符。刷每一道算法题时，都强迫自己把这些情况在代码里过一遍。这个习惯一旦养成，收益不只是笔试，日常开发中写测试代码也顺手很多。
3. 测试用例设计题：这是拉开分差的核心题
3.1 等价类与边界值：一套能直接套用的大题模板
笔试最后的测试用例设计大题，往往是整张卷子里单题分值最高的。这类题没有标准答案，但有一套阅卷时非常看重的得分结构，基本就是等价类划分、边界值分析、场景法、错误推测这四板斧。只要结构清晰、覆盖度高，哪怕和出题人的预期不完全一致，也能拿高分。
以“用户输入手机号注册账号”这个简单功能为例。等价类划分要拆出有效等价类和无效等价类：有效类包括11位、以1开头、第二位为3-9的数字；无效类包括位数不足、位数超长、非数字字符、以0开头、以1开头但第二位不是3-9等。边界值就是10位、11位、12位、0位、1位这些临界情况。这种题人人都能写几个用例，但拉开差距的点在于：你能不能把“有效无效”说完，并且用表格形式让阅卷人一眼看清覆盖矩阵。
我在面试中遇到过很多候选人，写用例时想到一条写一条，完全没有方法论支撑。而笔试想看到的恰恰是方法论。所以不管题目怎么变，我建议都按这个顺序组织答案：先划分等价类，再挑边界值，再补充业务场景，最后用错误推测补漏。
3.2 场景法与时序题：针对视频业务的具体拆解
爱奇艺的测试设计大题，大概率会围绕视频业务展开，比如“设计视频缓存功能的测试用例”或“设计会员到期续费状态的测试用例”。这类题如果只用等价类和边界值去套，容易流于表面，因为真正的考察点藏在业务时序里。
拿“视频缓存”来说，至少要考虑这些场景：开始缓存时点击暂停、缓存到一半切换网络（Wi-Fi切4G/5G）、缓存完成后删除视频、缓存占用空间满、同一账号在两台设备同时缓存、缓存后的视频在会员过期后还能不能看等。这些场景之间有先后关系和状态流转，只有用“场景法”才能系统地整理出来。
这类题还有个高分技巧：先画一条正常流程的“快乐路径”，再逐个环节注入异常。比如正常路径是“点击缓存按钮 -> 开始下载 -> 下载完成 -> 可离线播放”，异常注入可以是“点击缓存 -> 网络断开 -> 提示失败/自动重试 -> 恢复下载”。把主流程和异常分支清清楚楚地列出来，阅卷人会觉得你确实做过测试，而不只是背过几个概念。
3.3 用例设计题的标准作答格式
我见过不少候选人选题会做，但写出来的答案像流水账，想到哪写到哪。这里分享一个我笔试和面试时都推荐的标准格式，四栏结构：用例编号、前置条件、操作步骤、预期结果。
前置条件这块最容易被忽略，但其实很能体现专业度。比如测试“移动端断点续播”，前置条件要写明“登录状态有效”、“视频已缓存到50%”、“网络已断开”，这样这个用例才可复现。预期结果不要写“应该正常”，要写具体可验证的行为，例如“播放进度条保持在50%处，缓冲图标出现，网络恢复后从50%继续播放”。
我当年在笔试时用这个四栏格式答题，分数一直不差。后来工作里评审测试用例，也一直用同样的结构要求团队。它不一定会让你写出多惊艳的用例，但至少能保证你的答案是完整的、可执行的，而这个底线，在阅卷时已经能超过相当一部分人。
4. 基础八股题：网络、OS、Linux和数据库的常考范围
4.1 计算机网络：从TCP三次握手到HTTP状态码
这里的“八股”没有任何贬义。测试开发日常要定位问题，尤其排查线上接口超时、数据不一致这类问题时，网络基础是基本功。笔试题里计算机网络占比不小，常考的就那么几类：TCP三次握手和四次挥手、TCP和UDP的区别、HTTP和HTTPS的区别与握手过程、常见HTTP状态码的含义、DNS解析流程、Cookie和Session的区别。
备考时别只背结论，要想一想“这道题在测试工作中会怎么用”。比如TCP三次握手没完成，客户端表现是什么？这对应了“连接超时”的报错；HTTP 502和504的区别，排查时怎么区分是网关连不上还是上游响应超时？这些从测试视角去理解，八股就不再是死记硬背。
我在笔试复盘时还发现，爱奇艺这类偏C端产品的公司，对HTTP状态码的考察特别细。除了最常用的200、404、500，还经常拿301、302、304、403、502、503来出题，尤其是301永久重定向和302临时重定向的区别、304协商缓存的触发条件，这两个点几乎是常青考点。
4.2 Linux与数据库：测试开发日常的吃饭家伙
Linux命令和SQL，这两块是测试开发笔试的“送分题”，也是实际工作中天天用的东西。Linux常考的不外乎：文件操作（ls、cd、cp、mv、rm、find）、查看日志（tail、head、grep、less）、进程管理（ps、top、kill）、权限管理（chmod、chown）、网络排查（netstat、ping、curl、telnet）。
SQL这块，重点掌握：单表查询、聚合函数（count、sum、avg、max、min）、group by和having的配合、join多表连接、子查询、排序和分页。笔试中容易出错的是having和where的混用，记住where是对行做筛选，having是对分组后的结果做筛选，这个区分在很多题里都是关键。
我自己招人时会比较看重候选人有没有写过“稍微复杂一点的SQL”。因为测试里造数据、验证数据，经常会遇到需要多表关联的场景。如果你连left join和inner join的区别都说不清楚，后面做接口测试、数据一致性校验时会非常吃力。
4.3 遇到不会的题怎么办：给分点思维
笔试时遇到不会的客观题，不要空着，尽量结合已有知识排除掉明显错误的选项。遇到不会的主观题，哪怕没有完整思路，也要把能想到的知识点写上去，比如“这道题我会先考虑等价类划分”“这里应该做边界值测试”。因为大厂笔试的主观题往往是按给分点评分，你多写一个合理的方向，就多一个得分点。
我在复盘这份卷子时发现，有些题放在今天看确实有时代痕迹，但核心考点一点没变。比如当年考过的“如何测试一个推荐算法”今天依然是热点，题目可能会换成“如何测试一个AI对话功能”，但底层思路一样：定义输入输出、划分等价类、准备测试数据、设计评估指标、考虑异常输入。
5. 从这道笔试往回看：测试开发学习路线怎么排
5.1 核心技能栈与学习优先级
我经常被问到“测试开发到底要学什么”，这里结合这份笔试题的考点，给一个比较务实的学习优先级排序。
第一优先级是编程语言和算法基础。不管是Python还是Java，至少熟练掌握一门。Python在测试领域用得最广，因为上手快、第三方库多，适合写脚本、做自动化；Java则是很多大厂测试平台后端的主力语言，如果你想做测试工具开发，Java大概率逃不掉。算法方面，把LeetCode的Top 100简单中等题刷明白就足够应付大部分笔试。
第二优先级是计算机基础三件套：操作系统、计算机网络、数据库。这些东西不需要学到科班顶尖水平，但核心概念必须清楚，因为笔试客观题会有大量覆盖，实际工作中排查问题也离不开它们。
第三优先级是测试理论与测试设计方法。等价类、边界值、场景法、因果图、正交试验这些要能说清楚，并会应用到具体案例中。我在面试中常发现一个现象：很多候选人能背出“等价类划分”的定义，但给他一个真实功能，却说不清怎么划分。这说明理论学得不扎实，还没内化成思维习惯。
5.2 刷题之外的准备：项目、框架、自动化实战
笔试只是第一关，后面还有面试。面试官一定会问项目经验。对没有实际工作经验的应届生来说，最好的项目就是自己搭一套自动化测试框架。哪怕只是用Python的pytest、requests库写一个针对某个开源网站的接口自动化脚本，也值得拿出来讲。关键是要讲清楚：为什么用这个框架？怎么处理测试数据？怎么收集测试报告？遇到定位不到元素的问题是怎么解决的？
搜索热词里有一条叫“用opencode开发一个项目从需求到设计到开发到测试”，这个方向对测试开发来说其实特别对路。你不需要真的开发一个完整的产品，但可以尝试用AI辅助工具或者自己动手，把一个简单的需求从设计到测试完整走一遍。这个过程会让你更理解开发视角，也能帮你在面试中回答“开发和测试的协作流程”这类问题。
另外，现在AI测试开发是个热点方向，大模型在测试用例生成、缺陷定位、自动化脚本维护方面确实能派上用场。笔试复习之余，可以关注一下AI如何辅助测试的实践案例，比如用大模型生成测试数据、用AI识别UI元素变化等。这不是短时间能突击的，但长期积累下来会有差异化优势。
6. 踩坑实录：我复盘这份题目时的几个教训
6.1 时间分配失败的典型情况
我自己当年做这类笔试题时踩过最大的坑，就是选择题上花太多时间，最后编程题只写了一题。后来复盘才发现，客观题里的某些网络、数据库题，你就算纠结五分钟也不一定做对，而编程题哪怕只写出一个能跑的解法也能拿不少分。所以时间分配不只是技巧问题，而是策略问题。
这里给一个更细的操作建议：拿到卷子先花两分钟扫一遍全部题目，标注出哪些题你一看就有思路，哪些题完全没头绪。然后按“先易后难、先高分后低分”的顺序做题。优先做编程题里顺手的那道，再做用例设计大题，最后回头啃选择题。因为编程和用例设计是主观题，只要写就有分，选择题完全不会的时候只能靠猜。
6.2 面试官真正想看的“测试思维”到底是什么
我后来坐在面试官的位置上，发现很多候选人笔试分数不低，但面试一聊就露馅，原因在于只有“做题思维”没有“测试思维”。什么是测试思维？举个小例子：给你一个登录功能，普通思维是测“账号密码正确能不能登录”，测试思维想的是“账号密码正确不一定能登录成功——可能账号被锁定、密码过期、触发了验证码、IP被限制、token下发失败”。
测试思维的核心是“对假设保持怀疑”，翻译成技术语言就是“穷举无效输入、验证非正常路径、关注状态流转”。笔试里的用例设计题、场景分析题，本质上就是在有限的篇幅里考察你有没有这个思维习惯。所以备考时不要只刷题，要多问自己：这个功能如果上线了，最可能在哪里出问题？如果让我来测，我会怎么把这个问题找出来？
6.3 一些可以直接用的备考建议
按我自己带人的经验，最后给三条最实在的建议。
第一条，建立错题本。不要只记录错题本身，要把错题背后的知识点和思考漏洞一起记下来。比如“边界值没考虑到空字符串”“SQL的having和where用混了”，一个月后回头翻，你会发现自己的薄弱点非常集中。
第二条，动手写测试用例，每周至少两个。可以是任何一个简单功能，比如计算器、登录框、购物车。写完之后对照等价类、边界值、场景法这三个维度自查覆盖度，长期坚持下去，用例设计的水平提升非常明显。
第三条，把写过的代码、做过的项目整理成可展示的内容。笔试过了之后还有面试，面试官大概率会问“你简历上写的这个项目，具体是怎么实现的”。如果你能当场打开自己写的代码或测试报告讲清楚，印象分会比单纯背八股高很多。
这三条建议不是什么高深理论，都是我实际踩过坑之后总结出来的笨办法。不需要多聪明，坚持做下去，效果一定会体现在笔试和面试的结果里。
