爱奇艺测试开发秋招笔试题复盘：从算法到用例设计的备考指南

最近团队招人我把早几年的秋招笔试题翻出来当模拟卷用其中有一份爱奇艺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用混了”一个月后回头翻你会发现自己的薄弱点非常集中。第二条动手写测试用例每周至少两个。可以是任何一个简单功能比如计算器、登录框、购物车。写完之后对照等价类、边界值、场景法这三个维度自查覆盖度长期坚持下去用例设计的水平提升非常明显。第三条把写过的代码、做过的项目整理成可展示的内容。笔试过了之后还有面试面试官大概率会问“你简历上写的这个项目具体是怎么实现的”。如果你能当场打开自己写的代码或测试报告讲清楚印象分会比单纯背八股高很多。这三条建议不是什么高深理论都是我实际踩过坑之后总结出来的笨办法。不需要多聪明坚持做下去效果一定会体现在笔试和面试的结果里。