美丽联合2019届校招的测试类笔试题我印象还挺深的。当年这波题在圈子里流传度不低很多准备面电商类测试岗的同学都拿它练过手。现在回头看这套题最大的价值不是题目本身而是它很典型地反映了互联网公司校招测试岗的考察逻辑基础扎不扎实、用例设计有没有套路、数据库和Linux基本功过不过关、有没有一点代码思维。这篇文章我就以这套题为主线把测试类校招笔试的常见题型、背后考点和应对思路完整拆一遍适合正在准备测试开发、软件测试校招的同学参考也适合想系统梳理测试基础知识的在职新人。1. 校招测试笔试题到底在考什么1.1 整张试卷的构成与时间分配先说说这类电商公司测试校招笔试题的整体结构。一般来说90分钟到120分钟的笔试时间题量在40到60道之间题型分布大致是单选题15到20道多选题5到10道判断题5到10道简答题2到3道设计题手写测试用例1道数据库SQL题1到2道编程题1道有时候还会加一道逻辑推理题。我见过不少同学拿到卷子就开始按顺序刷题结果做到后面的设计题和编程题时时间不够了。这里有个非常重要的时间分配原则分值越高的题越要先保证完成度。像手写测试用例和编程题一道题的分值往往抵得上10道选择题就算选择题最后蒙几个也不影响大局但设计题写不完是真的可惜。建议的时间分配是选择题和判断题控制在35到40分钟内简答题20分钟SQL题10分钟手写用例题20到25分钟编程题留15到20分钟。如果逻辑题特别难果断放到最后再做别在一道题上卡超过8分钟。1.2 测试岗笔试图谱与考察逻辑我复盘了美丽联合这套题以及同期其他电商公司的测试笔试题发现考察内容基本围绕六个板块展开考察板块大概占比典型题型测试基础理论25%-35%概念选择、判断对错、流程分析用例设计方法15%-20%等价类、边界值、场景法简答数据库SQL10%-15%多表查询、子查询、聚合函数Linux与计算机网络10%-15%常用命令、HTTP状态码、TCP/UDP编程与算法10%-15%简单算法、字符串处理、数组操作逻辑思维与场景题5%-10%智力题、测试场景分析这个结构其实透露了一个信息校招笔试不指望你有多深的实战经验它考察的是你有没有建立起测试思维的基本框架。所谓测试思维说白了就是“怎么把一个问题拆成可以验证的颗粒度”然后用系统的方法把这些颗粒度覆盖完整。这个能力很大程度是通过测试理论的学习和用例设计方法的训练建立起来的。2. 测试基础理论题拿到基础分的通关钥匙2.1 等价类与边界值用例设计的万能起手式测试基础理论这块最常考也最实用的就是等价类划分和边界值分析。这套题里有一道典型的单选某个输入框要求输入1到100的整数问以下哪个测试数据组合覆盖了有效的等价类和边界值。这种题考的不是你能不能写代码而是你懂不懂测试用例设计的基本原则。等价类的核心思想是“用最少的用例覆盖尽量多的输入情况”。把输入域划分成若干个子集每个子集中的数据对程序来说都是“等效的”只要测一个代表值就可以了。比如1到100的整数有效等价类就是1到100之间的任意整数无效等价类就包括小于1的整数、大于100的整数、非数字字符、负数、小数、空值、超长字符串等。边界值分析则是等价类方法的重要补充大量的程序缺陷都集中在输入范围的边界附近。1到100这个范围需要重点测的边界值包括0、1、2、99、100、101再加上一个中间值比如50作为有效等价类的代表。我在现在的实际工作中写用例依然遵循这条规矩先划等价类再补边界值然后用错误推测法补异常场景。多选题容易考到的是“下列哪些属于黑盒测试方法”选项里混着白盒的语句覆盖、路径覆盖如果不清楚黑盒和白盒的划分很容易掉坑。黑盒测试关注的是功能需求不关注内部实现白盒测试关注的是代码逻辑和覆盖率。2.2 场景法、判定表与错误推测的实战场景场景法在电商系统测试中用得特别多笔试也喜欢用具体的业务场景来考察。比如题目给出一个“用户下单支付”的流程要求分析主场景和备选场景。主场景就是“登录→浏览商品→加入购物车→提交订单→支付成功→订单完成”备选场景包括支付超时、余额不足、库存不足、商品已下架、支付密码错误、网络中断等。很多同学在答这类题的时候容易漏掉异常分支只盯着正常流程走。但面试官想看到的恰恰是你对异常情况的把握能力。好的测试用例设计者脑子里要有一个“如果这里出错了会怎样”的自动追问机制。比如下单时库存只有1件两个用户同时下单系统应该怎么处理这就是并发场景下的用例设计电商公司特别看重这一点。判定表法的核心价值在于处理多个条件组合的情况。笔试中常见的题目是“某功能包含3个条件每个条件有2种取值请设计测试用例”。这时候直接用判定表列出来条件组合有2的3次方共8种情况规范地列出每一种组合的预期结果比拍脑袋写用例要系统得多。3. 手写测试用例电商核心链路的高频考法3.1 购物车与下单链路的用例设计思路美丽联合这个公司是做电商业务的所以手写用例题基本逃不开购物车、订单、优惠券、支付这几个核心模块。这类题给的场景一般很简单比如“请针对购物车删除功能设计测试用例”但越简单的题越考验功力。我拿到这种题会先划分测试维度而不是一条接一条地蒙头写。一般来说维度包括功能测试、异常测试、兼容性测试、性能测试、安全测试、界面易用性测试。功能测试是最核心的要覆盖正常流程和异常流程。拿“购物车删除商品”来说功能方面至少要有单选删除、多选删除、全选删除、删除最后一件商品后购物车是否显示为空、删除后商品是否从结算列表移除、删除后能否恢复比如有“恢复删除”功能的话。异常方面要考虑网络中断时点击删除、删除请求超时重复点击、删除不存在或已失效的商品、删除过程中商品库存发生变化。兼容性至少要想到不同操作系统下、不同手机型号下、不同浏览器下的表现。性能方面简单提及“批量删除时是否需要翻页、删除1件和50件商品的响应时间差异”就够了。写用例时一个常见的送命操作是只写“删除成功购物车商品消失”这种一句话用例。有经验的面试官一看就知道没做过事。一条合格的用例至少包含用例编号、所属模块、用例标题、前置条件、测试步骤、测试数据、预期结果、优先级。写的时候不用太纠结格式但关键要素必须完整尤其是“前置条件”和“测试数据”这两个是最多人都忽略的地方。3.2 优惠券和支付模块的设计要点再来看看优惠券模块的用例设计这是电商笔试的保留题型。优惠券涉及的状态有未使用、已使用、已过期、已锁定下单未支付时。设计用例时要注意领券成功的条件用户是否登录、是否符合领取条件、是否已领完、用券的规则满减门槛、适用范围、使用时段、过期处理过期后是否还能使用、过期提醒、退款的场景订单使用了优惠券后退款优惠券是否退回、退回后是否还有效。这些场景里有一个特别容易考察的细节优惠券金额和订单金额的边界关系。比如一张满100减20的优惠券订单总额刚好是100.01元能不能用刚好是100.00元能不能用设计用例的时候这种边界值一个都不能漏。支付模块的用例设计更看重流程的完整性。正常的支付流程是提交订单→选择支付方式→跳转支付平台→支付成功→回调通知→订单状态更新。测试用例要覆盖支付成功、支付取消、支付超时、支付密码错误、余额不足、重复支付回调、支付结果异步通知延迟等情况。尤其是“支付成功但订单状态未更新”这个场景在真实项目中很常见笔试时能把这种场景写出来面试官会认为你确实了解分布式系统下的数据一致性问题。4. 数据库与Linux测试工程师的基本功4.1 SQL题目考察思路与典型场景测试岗的SQL题不会考得太难重点在查询语句主要考察单表查询、条件过滤、聚合函数、排序分组、多表连接、子查询。美丽联合这套题里的SQL题我记得考了一道商品表和订单表的关联查询要求查出一个分类下销量前十的商品。这类题的思路其实是固定的。先明确要查哪些字段、从哪些表取数据再想清楚关联关系最后写过滤条件和排序。以“查询每个分类下的商品数量”为例常规写法是SELECT category_id, COUNT(*) AS product_count FROM product GROUP BY category_id;如果题目加了一个条件“只统计库存大于0的商品”就变成SELECT category_id, COUNT(*) AS product_count FROM product WHERE stock 0 GROUP BY category_id;再加一个难度等级“只返回商品数量大于10的分类”就需要用到HAVING子句SELECT category_id, COUNT(*) AS product_count FROM product WHERE stock 0 GROUP BY category_id HAVING COUNT(*) 10;笔试里经常有人把WHERE和HAVING搞混。记住一条WHERE是在分组前过滤行HAVING是在分组后过滤组。这个区别在SQL题里几乎是必考的。如果考到子查询典型的场景是“查询订单金额大于平均订单金额的订单”。这种题有两个解法一种是用子查询一种是用窗口函数。校招笔试一般允许子查询但如果你会窗口函数会是个加分项。SELECT order_id, amount FROM orders WHERE amount (SELECT AVG(amount) FROM orders);4.2 Linux常用命令的笔试考察方式Linux命令在测试笔试里考的其实很基础主要是那些测试人员日常要用的命令。比如查看进程用ps、查看端口占用用netstat、日志查看用tail和grep、文件权限用chmod、文件查找用find和grep。出题方式通常是给出一个场景让你选择对应命令或者给出命令选项问它的作用。一个很常见的题目是线上有个bug需要查看某个应用的实时日志应该用什么命令组合标准答案是tail -f app.log如果想过滤出包含某个关键字的日志行就是tail -f app.log | grep ERROR如果我记得没错这类题经常在“查看日志中某时间段的错误信息”这个场景上周旋。实用做法是先用grep定位关键词再配合head和tail截取上下文。我在实际排查问题的时候最常用的组合是grep -n 2024-01-01 10:00 app.log | head -50这条命令的意思是在日志文件中查找特定时间点的内容并显示前50行-n参数会显示行号方便回溯上下文。笔试虽然不考这种复杂组合但理解管道符的含义很重要它几乎算Linux题的必考概念。网络基础方面HTTP状态码是高频考点。302是重定向400是客户端请求语法错误401是未认证403是禁止访问404是资源不存在500是服务器内部错误502是网关错误503是服务不可用。测试人员看到502和503要能区分502是网关拿不到后端响应503是服务暂时不可用可能是过载或维护中。5. 编程题与逻辑思维题拉开差距的分水岭5.1 常见编程题目的解题方向测试岗的编程题和开发岗有区别难度通常低一档核心是考察最基本的编码能力和逻辑思维。常见的题目类型包括字符串反转、数组去重、求最大公约数、简单排序、回文判断、二分查找、括号匹配等。美丽联合这套题里的编程题我记得是跟字符串处理有关的。编程题不一定限定语言C、Java、Python都可以。但既然你是投测试岗大部分同学选Python写的比较多因为测试工具链里Python的使用频率最高。一个常见的字符串去重题用Python可以这样写def deduplicate(s): result for ch in s: if ch not in result: result ch return result这个写法时间复杂度是O(n^2)笔试能过但如果你用集合去重再保留原有顺序会显得更有意识def deduplicate(s): seen set() result [] for ch in s: if ch not in seen: seen.add(ch) result.append(ch) return .join(result)看起来差别不大但面试官从这段代码能看出你有没有考虑效率问题。测试岗的编程题不追求复杂的算法但要写得干净、有注释、边界考虑周全尤其是空输入、单个字符输入、全重复输入这些情况都要在代码里体现处理逻辑。还有一类编程题跟测试技能直接挂钩比如“写一个函数判断一个数是否为素数”或者“实现一个简单的计算器”。这类题本质上考察的是你写代码的规范性如果要写测试代码的话能不能顺便写出几条用例来验证自己的函数这是测试岗笔试编程题区别于开发岗的关键加分点。5.2 逻辑假设题与性能基础概念的结合考察逻辑题在校招笔试里偶尔会作为附加题出现占比不高但很影响整体印象分。典型的逻辑题有烧绳子问题、过桥问题、找假币问题、赛马问题等。这类题目考察的不是知识储备而是分析和推理能力。拿经典的“8个球找1个较重的球天平最少称几次”来说答案是2次。思路是先把8个球分成3、3、2三组第一次称3对3如果平衡就在剩下的2个里再称一次解决如果不平衡重的那组3个球里取两个再称一次也能判断出来。这类题的关键是把问题规模二分或三分而不是一个一个去比较。性能测试的基础概念也是笔试常客常见的考察点有响应时间、吞吐量、并发用户数、TPS、QPS、PV、UV等概念的区别。特别是TPS和QPS很多人以为是一个东西其实不完全一样。QPS是查询每秒的请求数TPS是每秒的事务数一个事务可能包含多个请求。举例来说一个下单操作前端会调用商品查询、库存校验、订单创建、支付等多个接口那么一次下单就是一个事务但会产生好几个QPS。性能测试的流程也是一个简答热点需求分析→测试计划→脚本编写→压力测试→负载测试→稳定性测试→瓶颈分析→调优→回归测试。笔试里如果问到性能测试的步骤按照这个链路答基本不会丢分。6. 测开方向的加分项与备考建议6.1 自动化与接口测试在笔试中的体现近年来的测试岗笔试题有一个明显趋势自动化测试和接口测试的占比越来越大。美丽联合这套题里虽然自动化题目不多但同期其他大厂的笔试题里自动化相关的概念题已经稳定出现了。自动化测试常考概念包括selenium的元素定位方式id、name、class_name、xpath、css_selector、PO模式Page Object设计、数据驱动测试、关键字驱动测试、测试框架pytest和unittest的区别。接口测试常考的是GET和POST的区别、HTTP与HTTPS的区别、cookie和session的区别、token认证机制、接口测试的断言内容。有一个概念题非常经典“http和https的区别是什么”。正常的回答是HTTPS在HTTP的基础上加了SSL/TLS加密层数据传输更安全默认端口不同HTTP是80HTTPS是443HTTPS需要申请CA证书。这是面试官最想听到的三点但如果笔试是简答题可以再补充一句HTTPS解决了数据被窃听和篡改的风险但握手过程更耗时对性能有一定损耗。再比如cookie和session的区别这个也是高频题。cookie存放在客户端session存放在服务端cookie有大小限制一般是4KBsession在服务端受内存限制cookie可以被用户禁用session不受影响。记住一句话cookie是通行证session是服务端的档案室。6.2 备考路线与几点实用建议整套题复盘下来我最大的感受是校招测试笔试的题库虽然千变万化但核心考点是非常稳定的。如果你准备时间有限按这个优先级来复习先把测试基础理论尤其是等价类和边界值吃透然后练熟SQL的基本查询和常用Linux命令再花时间写几套手写测试用例的题最后刷一些Python或Java的基础编程题。写用例题的时候一定要自己动手写不要只看别人的答案。我见过很多同学看解析的时候觉得“这不难”但一到笔试现场30分钟写不了几个完整的用例。用我前面说的维度拆解法每个模块至少练两遍直到形成肌肉记忆。SQL题建议多练习GROUP BY与HAVING的组合、子查询和多表连接这三个点是电商类笔试SQL题的重灾区。Linux命令则要理解原理不要死记硬背。比如管道符的本质是把前一个命令的输出作为后一个命令的输入理解了这一点任何命令组合的题你都能自己推出来。再一个问题就是编程题的时间控制。如果一道编程题超过20分钟还没有完整思路先写一个暴力解法拿部分分不要空着。测试岗笔试的编程题往往只要逻辑正确就能拿大部分分数不要求最优解。最后分享一个小技巧。笔试的时候如果遇到不会的题千万不要空着。尤其是简答题和设计题把你想到的相关知识点都写上去哪怕只是列个大纲也比空白卷强得多。测试岗的笔试评分往往更看重答题思路你写出了等价类的划分思想就算最终用例写得不完整面试官也会给你相应的分数。这是我带过的校招生里最实用的一条应试经验。
校招测试笔试题全解析：从用例设计到SQL与Linux考点
美丽联合2019届校招的测试类笔试题我印象还挺深的。当年这波题在圈子里流传度不低很多准备面电商类测试岗的同学都拿它练过手。现在回头看这套题最大的价值不是题目本身而是它很典型地反映了互联网公司校招测试岗的考察逻辑基础扎不扎实、用例设计有没有套路、数据库和Linux基本功过不过关、有没有一点代码思维。这篇文章我就以这套题为主线把测试类校招笔试的常见题型、背后考点和应对思路完整拆一遍适合正在准备测试开发、软件测试校招的同学参考也适合想系统梳理测试基础知识的在职新人。1. 校招测试笔试题到底在考什么1.1 整张试卷的构成与时间分配先说说这类电商公司测试校招笔试题的整体结构。一般来说90分钟到120分钟的笔试时间题量在40到60道之间题型分布大致是单选题15到20道多选题5到10道判断题5到10道简答题2到3道设计题手写测试用例1道数据库SQL题1到2道编程题1道有时候还会加一道逻辑推理题。我见过不少同学拿到卷子就开始按顺序刷题结果做到后面的设计题和编程题时时间不够了。这里有个非常重要的时间分配原则分值越高的题越要先保证完成度。像手写测试用例和编程题一道题的分值往往抵得上10道选择题就算选择题最后蒙几个也不影响大局但设计题写不完是真的可惜。建议的时间分配是选择题和判断题控制在35到40分钟内简答题20分钟SQL题10分钟手写用例题20到25分钟编程题留15到20分钟。如果逻辑题特别难果断放到最后再做别在一道题上卡超过8分钟。1.2 测试岗笔试图谱与考察逻辑我复盘了美丽联合这套题以及同期其他电商公司的测试笔试题发现考察内容基本围绕六个板块展开考察板块大概占比典型题型测试基础理论25%-35%概念选择、判断对错、流程分析用例设计方法15%-20%等价类、边界值、场景法简答数据库SQL10%-15%多表查询、子查询、聚合函数Linux与计算机网络10%-15%常用命令、HTTP状态码、TCP/UDP编程与算法10%-15%简单算法、字符串处理、数组操作逻辑思维与场景题5%-10%智力题、测试场景分析这个结构其实透露了一个信息校招笔试不指望你有多深的实战经验它考察的是你有没有建立起测试思维的基本框架。所谓测试思维说白了就是“怎么把一个问题拆成可以验证的颗粒度”然后用系统的方法把这些颗粒度覆盖完整。这个能力很大程度是通过测试理论的学习和用例设计方法的训练建立起来的。2. 测试基础理论题拿到基础分的通关钥匙2.1 等价类与边界值用例设计的万能起手式测试基础理论这块最常考也最实用的就是等价类划分和边界值分析。这套题里有一道典型的单选某个输入框要求输入1到100的整数问以下哪个测试数据组合覆盖了有效的等价类和边界值。这种题考的不是你能不能写代码而是你懂不懂测试用例设计的基本原则。等价类的核心思想是“用最少的用例覆盖尽量多的输入情况”。把输入域划分成若干个子集每个子集中的数据对程序来说都是“等效的”只要测一个代表值就可以了。比如1到100的整数有效等价类就是1到100之间的任意整数无效等价类就包括小于1的整数、大于100的整数、非数字字符、负数、小数、空值、超长字符串等。边界值分析则是等价类方法的重要补充大量的程序缺陷都集中在输入范围的边界附近。1到100这个范围需要重点测的边界值包括0、1、2、99、100、101再加上一个中间值比如50作为有效等价类的代表。我在现在的实际工作中写用例依然遵循这条规矩先划等价类再补边界值然后用错误推测法补异常场景。多选题容易考到的是“下列哪些属于黑盒测试方法”选项里混着白盒的语句覆盖、路径覆盖如果不清楚黑盒和白盒的划分很容易掉坑。黑盒测试关注的是功能需求不关注内部实现白盒测试关注的是代码逻辑和覆盖率。2.2 场景法、判定表与错误推测的实战场景场景法在电商系统测试中用得特别多笔试也喜欢用具体的业务场景来考察。比如题目给出一个“用户下单支付”的流程要求分析主场景和备选场景。主场景就是“登录→浏览商品→加入购物车→提交订单→支付成功→订单完成”备选场景包括支付超时、余额不足、库存不足、商品已下架、支付密码错误、网络中断等。很多同学在答这类题的时候容易漏掉异常分支只盯着正常流程走。但面试官想看到的恰恰是你对异常情况的把握能力。好的测试用例设计者脑子里要有一个“如果这里出错了会怎样”的自动追问机制。比如下单时库存只有1件两个用户同时下单系统应该怎么处理这就是并发场景下的用例设计电商公司特别看重这一点。判定表法的核心价值在于处理多个条件组合的情况。笔试中常见的题目是“某功能包含3个条件每个条件有2种取值请设计测试用例”。这时候直接用判定表列出来条件组合有2的3次方共8种情况规范地列出每一种组合的预期结果比拍脑袋写用例要系统得多。3. 手写测试用例电商核心链路的高频考法3.1 购物车与下单链路的用例设计思路美丽联合这个公司是做电商业务的所以手写用例题基本逃不开购物车、订单、优惠券、支付这几个核心模块。这类题给的场景一般很简单比如“请针对购物车删除功能设计测试用例”但越简单的题越考验功力。我拿到这种题会先划分测试维度而不是一条接一条地蒙头写。一般来说维度包括功能测试、异常测试、兼容性测试、性能测试、安全测试、界面易用性测试。功能测试是最核心的要覆盖正常流程和异常流程。拿“购物车删除商品”来说功能方面至少要有单选删除、多选删除、全选删除、删除最后一件商品后购物车是否显示为空、删除后商品是否从结算列表移除、删除后能否恢复比如有“恢复删除”功能的话。异常方面要考虑网络中断时点击删除、删除请求超时重复点击、删除不存在或已失效的商品、删除过程中商品库存发生变化。兼容性至少要想到不同操作系统下、不同手机型号下、不同浏览器下的表现。性能方面简单提及“批量删除时是否需要翻页、删除1件和50件商品的响应时间差异”就够了。写用例时一个常见的送命操作是只写“删除成功购物车商品消失”这种一句话用例。有经验的面试官一看就知道没做过事。一条合格的用例至少包含用例编号、所属模块、用例标题、前置条件、测试步骤、测试数据、预期结果、优先级。写的时候不用太纠结格式但关键要素必须完整尤其是“前置条件”和“测试数据”这两个是最多人都忽略的地方。3.2 优惠券和支付模块的设计要点再来看看优惠券模块的用例设计这是电商笔试的保留题型。优惠券涉及的状态有未使用、已使用、已过期、已锁定下单未支付时。设计用例时要注意领券成功的条件用户是否登录、是否符合领取条件、是否已领完、用券的规则满减门槛、适用范围、使用时段、过期处理过期后是否还能使用、过期提醒、退款的场景订单使用了优惠券后退款优惠券是否退回、退回后是否还有效。这些场景里有一个特别容易考察的细节优惠券金额和订单金额的边界关系。比如一张满100减20的优惠券订单总额刚好是100.01元能不能用刚好是100.00元能不能用设计用例的时候这种边界值一个都不能漏。支付模块的用例设计更看重流程的完整性。正常的支付流程是提交订单→选择支付方式→跳转支付平台→支付成功→回调通知→订单状态更新。测试用例要覆盖支付成功、支付取消、支付超时、支付密码错误、余额不足、重复支付回调、支付结果异步通知延迟等情况。尤其是“支付成功但订单状态未更新”这个场景在真实项目中很常见笔试时能把这种场景写出来面试官会认为你确实了解分布式系统下的数据一致性问题。4. 数据库与Linux测试工程师的基本功4.1 SQL题目考察思路与典型场景测试岗的SQL题不会考得太难重点在查询语句主要考察单表查询、条件过滤、聚合函数、排序分组、多表连接、子查询。美丽联合这套题里的SQL题我记得考了一道商品表和订单表的关联查询要求查出一个分类下销量前十的商品。这类题的思路其实是固定的。先明确要查哪些字段、从哪些表取数据再想清楚关联关系最后写过滤条件和排序。以“查询每个分类下的商品数量”为例常规写法是SELECT category_id, COUNT(*) AS product_count FROM product GROUP BY category_id;如果题目加了一个条件“只统计库存大于0的商品”就变成SELECT category_id, COUNT(*) AS product_count FROM product WHERE stock 0 GROUP BY category_id;再加一个难度等级“只返回商品数量大于10的分类”就需要用到HAVING子句SELECT category_id, COUNT(*) AS product_count FROM product WHERE stock 0 GROUP BY category_id HAVING COUNT(*) 10;笔试里经常有人把WHERE和HAVING搞混。记住一条WHERE是在分组前过滤行HAVING是在分组后过滤组。这个区别在SQL题里几乎是必考的。如果考到子查询典型的场景是“查询订单金额大于平均订单金额的订单”。这种题有两个解法一种是用子查询一种是用窗口函数。校招笔试一般允许子查询但如果你会窗口函数会是个加分项。SELECT order_id, amount FROM orders WHERE amount (SELECT AVG(amount) FROM orders);4.2 Linux常用命令的笔试考察方式Linux命令在测试笔试里考的其实很基础主要是那些测试人员日常要用的命令。比如查看进程用ps、查看端口占用用netstat、日志查看用tail和grep、文件权限用chmod、文件查找用find和grep。出题方式通常是给出一个场景让你选择对应命令或者给出命令选项问它的作用。一个很常见的题目是线上有个bug需要查看某个应用的实时日志应该用什么命令组合标准答案是tail -f app.log如果想过滤出包含某个关键字的日志行就是tail -f app.log | grep ERROR如果我记得没错这类题经常在“查看日志中某时间段的错误信息”这个场景上周旋。实用做法是先用grep定位关键词再配合head和tail截取上下文。我在实际排查问题的时候最常用的组合是grep -n 2024-01-01 10:00 app.log | head -50这条命令的意思是在日志文件中查找特定时间点的内容并显示前50行-n参数会显示行号方便回溯上下文。笔试虽然不考这种复杂组合但理解管道符的含义很重要它几乎算Linux题的必考概念。网络基础方面HTTP状态码是高频考点。302是重定向400是客户端请求语法错误401是未认证403是禁止访问404是资源不存在500是服务器内部错误502是网关错误503是服务不可用。测试人员看到502和503要能区分502是网关拿不到后端响应503是服务暂时不可用可能是过载或维护中。5. 编程题与逻辑思维题拉开差距的分水岭5.1 常见编程题目的解题方向测试岗的编程题和开发岗有区别难度通常低一档核心是考察最基本的编码能力和逻辑思维。常见的题目类型包括字符串反转、数组去重、求最大公约数、简单排序、回文判断、二分查找、括号匹配等。美丽联合这套题里的编程题我记得是跟字符串处理有关的。编程题不一定限定语言C、Java、Python都可以。但既然你是投测试岗大部分同学选Python写的比较多因为测试工具链里Python的使用频率最高。一个常见的字符串去重题用Python可以这样写def deduplicate(s): result for ch in s: if ch not in result: result ch return result这个写法时间复杂度是O(n^2)笔试能过但如果你用集合去重再保留原有顺序会显得更有意识def deduplicate(s): seen set() result [] for ch in s: if ch not in seen: seen.add(ch) result.append(ch) return .join(result)看起来差别不大但面试官从这段代码能看出你有没有考虑效率问题。测试岗的编程题不追求复杂的算法但要写得干净、有注释、边界考虑周全尤其是空输入、单个字符输入、全重复输入这些情况都要在代码里体现处理逻辑。还有一类编程题跟测试技能直接挂钩比如“写一个函数判断一个数是否为素数”或者“实现一个简单的计算器”。这类题本质上考察的是你写代码的规范性如果要写测试代码的话能不能顺便写出几条用例来验证自己的函数这是测试岗笔试编程题区别于开发岗的关键加分点。5.2 逻辑假设题与性能基础概念的结合考察逻辑题在校招笔试里偶尔会作为附加题出现占比不高但很影响整体印象分。典型的逻辑题有烧绳子问题、过桥问题、找假币问题、赛马问题等。这类题目考察的不是知识储备而是分析和推理能力。拿经典的“8个球找1个较重的球天平最少称几次”来说答案是2次。思路是先把8个球分成3、3、2三组第一次称3对3如果平衡就在剩下的2个里再称一次解决如果不平衡重的那组3个球里取两个再称一次也能判断出来。这类题的关键是把问题规模二分或三分而不是一个一个去比较。性能测试的基础概念也是笔试常客常见的考察点有响应时间、吞吐量、并发用户数、TPS、QPS、PV、UV等概念的区别。特别是TPS和QPS很多人以为是一个东西其实不完全一样。QPS是查询每秒的请求数TPS是每秒的事务数一个事务可能包含多个请求。举例来说一个下单操作前端会调用商品查询、库存校验、订单创建、支付等多个接口那么一次下单就是一个事务但会产生好几个QPS。性能测试的流程也是一个简答热点需求分析→测试计划→脚本编写→压力测试→负载测试→稳定性测试→瓶颈分析→调优→回归测试。笔试里如果问到性能测试的步骤按照这个链路答基本不会丢分。6. 测开方向的加分项与备考建议6.1 自动化与接口测试在笔试中的体现近年来的测试岗笔试题有一个明显趋势自动化测试和接口测试的占比越来越大。美丽联合这套题里虽然自动化题目不多但同期其他大厂的笔试题里自动化相关的概念题已经稳定出现了。自动化测试常考概念包括selenium的元素定位方式id、name、class_name、xpath、css_selector、PO模式Page Object设计、数据驱动测试、关键字驱动测试、测试框架pytest和unittest的区别。接口测试常考的是GET和POST的区别、HTTP与HTTPS的区别、cookie和session的区别、token认证机制、接口测试的断言内容。有一个概念题非常经典“http和https的区别是什么”。正常的回答是HTTPS在HTTP的基础上加了SSL/TLS加密层数据传输更安全默认端口不同HTTP是80HTTPS是443HTTPS需要申请CA证书。这是面试官最想听到的三点但如果笔试是简答题可以再补充一句HTTPS解决了数据被窃听和篡改的风险但握手过程更耗时对性能有一定损耗。再比如cookie和session的区别这个也是高频题。cookie存放在客户端session存放在服务端cookie有大小限制一般是4KBsession在服务端受内存限制cookie可以被用户禁用session不受影响。记住一句话cookie是通行证session是服务端的档案室。6.2 备考路线与几点实用建议整套题复盘下来我最大的感受是校招测试笔试的题库虽然千变万化但核心考点是非常稳定的。如果你准备时间有限按这个优先级来复习先把测试基础理论尤其是等价类和边界值吃透然后练熟SQL的基本查询和常用Linux命令再花时间写几套手写测试用例的题最后刷一些Python或Java的基础编程题。写用例题的时候一定要自己动手写不要只看别人的答案。我见过很多同学看解析的时候觉得“这不难”但一到笔试现场30分钟写不了几个完整的用例。用我前面说的维度拆解法每个模块至少练两遍直到形成肌肉记忆。SQL题建议多练习GROUP BY与HAVING的组合、子查询和多表连接这三个点是电商类笔试SQL题的重灾区。Linux命令则要理解原理不要死记硬背。比如管道符的本质是把前一个命令的输出作为后一个命令的输入理解了这一点任何命令组合的题你都能自己推出来。再一个问题就是编程题的时间控制。如果一道编程题超过20分钟还没有完整思路先写一个暴力解法拿部分分不要空着。测试岗笔试的编程题往往只要逻辑正确就能拿大部分分数不要求最优解。最后分享一个小技巧。笔试的时候如果遇到不会的题千万不要空着。尤其是简答题和设计题把你想到的相关知识点都写上去哪怕只是列个大纲也比空白卷强得多。测试岗的笔试评分往往更看重答题思路你写出了等价类的划分思想就算最终用例写得不完整面试官也会给你相应的分数。这是我带过的校招生里最实用的一条应试经验。