蘑菇街2019届校招-测试类笔试题我前后帮不少学弟学妹复盘过。有个很反直觉的现象这套笔试卷子里几乎没有正经的编程题但刷掉的人里一大半代码能力都还不错。原因其实很现实——测试岗笔试的核心不是看你写不写得出算法而是看你有没有一套在脑子里自动运转的测试思维。这篇东西不是标准答案汇编而是结合真题回忆、题库讨论和我自己带人复盘时整理出来的完整拆解包含考察方向的底层逻辑、典型题目的答题套路、以及那些让人丢分的细节。如果你正准备测试岗校招或者刚转行做测试想系统地查漏补缺这篇应该能帮你少走不少弯路。1. 先搞清楚蘑菇街想通过笔试筛出什么样的人1.1 电商测试岗位的能力模型不是“点点点”蘑菇街的业务核心是商品、交易、营销、支付这四块。电商产品的功能链路长、角色多一个用户从注册到下单再到售后中间要经过十几个模块不同模块之间还有状态同步和金额计算。所以这个岗位要的人不是只会照着用例点点点的执行者而是能理解业务、能设计出有效用例、能发现别人发现不了的问题的人。笔试就是围绕这个诉求设计的。它不会问你“TCP三次握手是哪三次”这种和业务毫无关系的孤岛知识而是会考你“登录功能怎么设计用例”“订单金额怎么校验”这种能直接映射到工作场景的题目。哪怕考Linux和SQL也是以“定位线上问题”为背景来考。理解了这一点你就能明白为什么很多编程很强的人反而挂了——他们做题时没有切换到测试视角。1.2 从热词分布反推考点三条主线如果去看当时测试笔试相关的讨论热词会发现几条明显的主线linux面试题、appium测试、pytest测试框架、接口自动化测试这些高频词指向的是硬技能安全测试、渗透测试、冒烟测试这些词指向的是测试专项知识。再结合当年校招的整体风向基本可以把考点收敛成三大类第一类测试基础与用例设计。这是最核心的包括测试流程、测试用例设计方法、缺陷管理、冒烟测试和回归测试的概念边界。第二类实操硬技能也就是Linux命令、SQL查询、日志分析。这类题最能拉开差距因为很多科班出身的同学反而没系统练过。第三类工具与框架的认知比如Appium怎么定位元素、JMeter怎么设计压测场景、Pytest的fixture是什么。笔试不会要求你手写完整脚本但会考察你懂不懂分层思想、懂不懂数据驱动。近几年测试行业又扩展出车载测试、智能座舱测试、AI测试这些新方向但在2019届的电商校招笔试里这些东西不会占太多篇幅。主线还是围绕功能测试、接口测试、自动化测试和安全测试来展开。1.3 题型结构的大致判断从大家回忆出来的信息看这套卷子的结构通常是单选或多选考概念简答题考理论用例设计题给一个具体功能最后一两道综合题给出业务场景让你设计测试方案。整体时间一般在60到90分钟题目量不算少所以时间分配很关键。我的建议是把时间分成三块概念题控制在20分钟以内不会的不要纠结先蒙一个标记好后面有时间再回头用例设计题留30分钟这类题是主观分大头宁可多写也不要写得太精简综合题必须留足15分钟因为要写出完整思路包括前置准备、测试范围、风险点。如果你在这些题上能稳住节奏基本就赢了一大半。2. 测试基础理论题背会概念只是及格线2.1 测试用例设计题的正确拆解法笔试里最容易出现的就是“请为登录功能设计测试用例”这类题。我见过太多人上来就写输入正确账号密码能登录输入错误密码提示错误。写完之后就交卷了然后被刷掉。问题不是他没学过测试而是他只用了“功能正常流”这一种视角。正确的拆法是先界定被测对象。登录功能至少包含用户名输入框、密码输入框、登录按钮、记住密码、忘记密码入口、第三方登录入口、验证码机制。然后对每个元素做输入分析。用户名要考虑长度为0、长度为1、正常长度、超长、包含空格、包含特殊字符、大小写混合密码要考虑对错、过期、连续错误锁定、是否支持粘贴、是否显示明文或掩码。这还没完还要考虑异常场景比如断网、弱网、服务器超时、并发重复点击提交以及安全性问题比如SQL注入、暴力破解防护、验证码有效期。我建议在答题时用一个二维矩阵来组织横向是测试维度纵向是具体场景。这样即使你写的用例数量不是最多的面试官也能看出你有结构化的思路。拿登录来说你可以分功能、安全、性能、兼容性、易用性五大类每个类别下再写3到5条。这种答法在阅卷时非常占优因为它展示的是思维框架而不是零散的记忆。2.2 缺陷报告与Bug生命周期送分也送命有些同学看到“描述一个你印象最深的Bug”或者“请写出一个缺陷报告要包含哪些要素”这种题觉得太简单了随便写几个字段就完事。但这里有个隐藏陷阱——严重级别和优先级很容易被混为一谈。严重级别指的是这个缺陷对系统的破坏程度功能不可用、数据丢失、界面错乱、提示文案错误严重级别依次降低。优先级指的是修复的先后顺序立即修复、本版本修复、下版本修复、可暂缓。一个Bug可以严重级别很高但优先级不高比如某个冷门页面出现数据错乱影响用户少你排到下个版本再修也没问题也可以严重级别不高但优先级很高比如首页的某个按钮文案写错了虽然不影响功能但影响品牌形象产品经理会催着马上改。答题时最好是手写一个完整的Bug单示例标题写明模块和现象比如“购物车-删除商品后数量角标未更新”环境信息写设备型号和系统版本前置条件写用户已登录且有1件商品在购物车复现步骤按1、2、3写清楚预期结果写“角标从1变为0”实际结果写“角标仍显示1”再附上截图或日志。这些字段看起来基础但能把它们写得完整的人反而是少数。2.3 冒烟测试、回归测试、兼容性测试的边界这三个概念在校招笔试里的出场率极高。很多人背定义背得很熟但一到结合场景就答错。比如面试官问“版本上线前先跑冒烟测试还是先跑回归测试”有人就答反了。冒烟测试的本质是“能不能测”的验证。它的名字源于硬件领域一个新电路板插上电如果冒烟了说明硬件有问题就别继续往下测了。软件里的冒烟测试是在新版本提测后先跑一遍覆盖核心主流程的用例比如登录、首页加载、商品加购、下单确认构建基本可用才允许进入详细测试阶段。它是第一道门不是用来发现深层次Bug的。回归测试的本质是“改了之后有没有改坏”。开发修复了一个Bug或者加了一个新功能你要验证原有功能依然正常。回归测试的用例池通常是从历史用例里挑出来的重点用例而不是把整个项目用例全部跑一遍。兼容性测试则是在不同设备、不同浏览器、不同系统版本上验证产品表现一致。笔试如果出现“Android和iOS哪个优先级更高”这种题不要直接回答系统而要反问目标用户用什么设备最多用数据说话。3. Linux、SQL与日志排查笔试拉开差距的实操硬题3.1 Linux命令题不是背命令是背场景很多人在笔试前背了一堆Linux命令但一遇到具体场景就懵了。比如题目给你一个场景“有一个Java进程CPU占用率异常偏高请用命令找出这个进程并进一步排查”。单纯背过ps和top是不够的你得把整个排查链路串起来。第一步用ps -ef | grep java找到对应的Java进程记住它的PID。第二步用top -H -p PID查看这个进程内各个线程的CPU占用情况找到占用率最高的线程ID。第三步把线程ID转成十六进制printf %x\n 线程ID然后用jstack PID | grep 十六进制线程ID 去查看这个线程当时的堆栈信息看它卡在哪个方法上。这个链路才是面试官想看到的排查能力。顺手整理一份高频命令对照表笔试前过一眼很有用场景命令说明实时查看日志tail -f app.log跟踪文件新增内容按关键字过滤日志grep -i error app.log忽略大小写匹配错误查看端口占用netstat -tlnp | grep 8080确认服务监听状态查看进程列表ps -ef | grep java过滤目标进程动态查看资源top 或 top -H -p PID查看进程线程资源占用查看磁盘使用df -h确认磁盘是否写满查看内存占用free -m检查可用内存统计日志行数wc -l app.log快速评估日志量3.2 SQL题从单表查询到业务聚合SQL是测试笔试里的必考题但考的粒度通常不会太深重点集中在单表查询和简单多表关联上。很多同学在大学里学过SQL但看到具体业务表就乱了因为不熟悉电商领域的数据模型。给你一个高频考法表orders(id, user_id, amount, create_time)要求查出“总消费金额前3的用户ID和总金额”。这种题考的是GROUP BY、ORDER BY、LIMIT和聚合函数的组合使用。标准写法是SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ORDER BY total_amount DESC LIMIT 3;这里有几个容易踩的坑GROUP BY的字段必须包含在SELECT的非聚合列里否则在严格模式下会直接报错ORDER BY要用别名total_amount而不是SUM(amount)的表达式虽然MySQL支持但可读性差LIMIT的位置一定要放在最后。如果题目改成“每个用户的订单数”那就要用COUNT(*)而不是SUM(amount)。记住一点看到“每个”“按XX分组”就用GROUP BY看到“前N”就用ORDER BY加LIMIT这是最朴素的解题规律。3.3 日志分析与问题定位的答题套路日志分析题往往不会直接给你一段日志而是问你“App闪退你作为测试工程师怎么排查”。这种题没有标准答案但答题时一定要体现“从现象到原因”的收敛过程。我的回答框架是四步。第一步确定问题范围闪退是必现还是偶现发生在什么机型、什么系统版本、什么页面、什么操作路径。第二步收集日志Android优先看Logcat和Bugly崩溃堆栈iOS看Crash日志和Xcode的Device Log如果没有现成日志就尝试复现并手动抓取。第三步关联定位看崩溃堆栈的顶部是哪一层代码看是否是内存暴涨导致的OOM看是否是某个接口返回了预期外的数据格式。第四步验证猜想在开发修复后用相同设备同版本系统走一遍原始路径再跑一遍相邻模块的回归确认没有连带影响。按这个结构去写哪怕你对具体工具不熟也能给阅卷人留下“这个人是干过活的”印象。最忌讳的是直接回答“我让开发看看”笔试里这样写等于白卷。4. 自动化、接口与安全校招笔试里的加分题真相4.1 Appium与移动端测试考的是分层思维Appium是最常被提到的自动化工具很多学校甚至把Appium列入课程设计。笔试里考Appium的目标通常不是让你默写出完整的Capability配置而是考察你理不理解自动化测试的根本问题脚本怎么定位元素、怎么处理等待、怎么保证稳定性。元素定位是最基础的权利。id优先因为classname太容易重复XPath虽然灵活但性能和稳定性差。如果题目问“Appium定位一个登录按钮有哪些方式”你可以列出resource-id、class name、XPath、Android UI Automator的text定位这几种并说清楚各自的优缺点。等待问题也是高频隐式等待影响所有元素查找显式等待只针对特定元素笔试里如果问“页面加载慢导致脚本执行失败怎么办”答案不是盲目加sleep而是用显式等待等待元素出现再配合页面加载完成的标志。一个好的答题示例是from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 显式等待登录按钮出现 btn_login WebDriverWait(driver, 10).until( EC.presence_of_element_located((AppiumBy.ID, com.mogu:id/btn_login)) ) btn_login.click()这段代码不是考点本身但它展现了你在等什么、为什么等、等了之后做什么这就是分层思维。4.2 Pytest、JMeter与接口自动化工具属性的优先级笔试里出现Pytest和JMeter相关的题目本质上不是在考工具命令而是在考“你怎么看待自动化在整个测试体系里的位置”。Pytest是接口自动化最常用的框架之一fixture是它的核心用来做前置准备和清理参数化用pytest.mark.parametrize可以做到一组数据跑一个用例。举个例子一道接口测试设计题“请针对‘用户登录接口’设计自动化接口测试用例”。你要拆解的维度包括参数完整性和合法性缺参、多参、空值、类型错误、账户状态正常、被锁定、未注册、密码策略正确、错误、过期、加密与安全密码是否明文传输、是否支持错误尝试锁定、以及接口响应结果的断言点状态码、业务码、返回数据字段的格式。一套用例能覆盖这些点说明你已经不是“用Postman调通接口”的初级水平了。JMeter在笔试里常考的是压测场景的组成部分线程组设置并发数和循环次数HTTP请求采样器配置协议、域名、路径和参数断言验证响应结果聚合报告查看吞吐量、平均响应时间和错误率。如果题目问“怎么做一个100并发的接口压测”你的回答应该包含先设定目标再准备测试数据然后设计单接口脚本和混合链路脚本最后施压并同时监控服务器资源。工具只是手段思路才是分数。4.3 安全测试、渗透测试考到什么程度为止校招笔试里的安全题不会让你去渗透一个真实系统但常常会用概念题来过滤基础薄弱的人。出现频率最高的几个名词是SQL注入、XSS、CSRF和越权。SQL注入的核心逻辑是用户输入被拼接进了SQL语句导致数据库执行了非预期命令。答题时最好能举一个例子登录框里输入 OR 11如果后台直接拼接就可能绕过密码校验。对应地测试人员要做的验证是在输入框里尝试特殊字符和恶意Payload观察是否报错或是否返回异常数据。XSS关注的是脚本是否会被执行CSRF关注的是请求是否缺少来源验证和Token越权则是一个经典的业务逻辑漏洞——普通用户能不能通过改URL参数访问另一个用户的订单。如果遇到“你作为测试怎么发现一个SQL注入漏洞”这种题我的答题顺序是第一步用单引号、闭合符号提交到输入参数观察页面是否出现数据库报错第二步用布尔条件试探比如参数后加AND 11和AND 12看响应差异第三步用抓包工具重放请求跳过前端限制查看响应体第四步将结果整理成缺陷报告提交开发而不是一味深挖。笔试只要写出这种“识别到风险、验证到现象、记录到报告”的闭环就够了。5. 场景设计题笔试卷子里最像工作的部分5.1 购物车与支付流程的测试用例怎么铺蘑菇街这种电商公司最喜欢考“购物车加购”和“下单支付”的测试设计题。很多人的第一反应是点击加购商品出现在购物车然后完事了。但电商业务里的购物车远没有那么简单它牵扯到金额、库存、商品状态、用户状态、并发、优惠活动等多个核心系统。我的拆法分五层。第一层是功能加购空状态、加购非空状态、改数量、删商品、选商品结算、全选、批量删除、失效商品展示。第二层是金额计算满减、优惠券、会员折扣、多种优惠叠加的顺序这个最容易出Bug因为计算顺序不同结果差异很大。第三层是异常场景库存不足、商品下架、重复点击加购导致重复添加、支付超时、支付成功但回调未通知、余额不足。第四层是权限与安全未登录加购、A用户访问B用户购物车、接口越权。第五层是兼容性Android、iOS、H5三端表现是否一致切后台再回来数据是否刷新。写用例的时候可以这样组织编号前置条件操作步骤预期结果优先级购物车-001用户已登录购物车为空点击商品详情页“加入购物车”加购成功角标变为1购物车列表显示该商品P1购物车-002商品库存仅剩1件购物车中修改数量为5提示库存不足无法修改数量保持原值P1购物车-003商品已参加满300减50活动购物车中添加价格总计350元的商品结算页展示优惠后金额扣减50元P1购物车-004网络切换为弱网点击加购出现加载提示网络恢复后数据正确P25.2 性能测试相关概念题的回答框架性能测试在笔试里常见的考法是两种一种是概念题问QPS、TPS、并发用户数、响应时间、吞吐量分别是什么意思另一种是方案设计题比如“系统预计支撑1万QPS你怎么设计压测方案”。前者靠背后者靠框架。回答方案设计题时我建议你按“目标、环境、场景、实施、分析”五个层次展开先明确性能指标目标比如接口的平均响应时间小于200毫秒错误率小于0.1%再确认压测环境最好和生产环境隔离但资源配置一致接着设计压测场景包括单接口基准测试、混合链路测试、峰值并发测试和稳压测试然后选择施压工具比如JMeter或Gatling设置并发线程数和持续时间最后要看服务端监控CPU、内存、磁盘IO、GC频率、慢SQL、JVM线程池状态都要关注。这里要特别强调一点压测不是“跑完看个数字”就结束的它的核心价值是定位瓶颈。当你把并发从100提到500时响应时间从50毫秒涨到2秒你要能说出瓶颈在数据库连接池还是应用层线程池或者更上游的网络带宽。笔试能写到这一层说明你是真懂压测。5.3 主观题答案不是重点思考过程才是最后一道综合题通常很开放比如“你怎么理解测试工程师的价值”“开发说这个Bug不用改你怎么办”“如果上线前发现一个高严重级Bug你怎么决策”。这类题没有标准答案但有高下之分。答“怎么理解测试价值”时不要写成“测试是保证软件质量的最后一道防线”这种口号而是要说测试的核心价值是提供质量信息和风险决策依据在合适的时间用合适的成本发现和预防问题帮助团队在业务快速迭代和质量保障之间做权衡。答“开发说Bug不用改”时标准思路是先复现确认问题存在再站在用户路径上说明影响范围用数据和优先级说话如果双方各执一词就拉产品经理一起决策同时记录风险后续持续跟进。这个顺序体现的是协作能力不是死磕。如果你是第一次看到开放题心里发慌记住一个公式理解业务目标、拆解影响范围、给出备选方案、说明决策逻辑、补充风险记录。按这个公式走你的思考过程就会显得严密。6. 笔试之后的复盘与补强路径6.1 建一张自己的测试知识地图笔试结束之后不管结果如何复盘都比刷题更重要。我是建议所有准备测试岗的人都建一张自己的知识地图把平时零散学的东西结构化。大致分六块测试理论与流程、测试用例设计方法、操作系统与网络基础、数据库与Linux、自动化测试框架与工具、专项测试方向性能、安全、兼容性。每一块下面再拆细一点。比如“测试用例设计方法”下面要能随时说出等价类、边界值、场景法、错误推测法、判定表、正交实验这些方法各自适用什么场景。比如“性能测试”下面要能分清负载测试、压力测试、稳定性测试的区别。这张地图不需要一次填满每次看完一篇文章、做完一道题就更新一次三个月后再回头对比你会明显发现自己知识体系的补全速度。6.2 从笔试到面试项目经验怎么讲才有说服力笔试过了还有面试面试官大概率会问你“做过什么测试相关工作”。很多应届生说没有实习经历不知道怎么回答。我的建议是不要说自己没项目而是准备1到2个自己动手练过的Demo项目。举例来说你可以用Pytest写一个针对某个公开接口的自动化测试Demo用例里覆盖正常参数、异常参数、依赖登录态的场景再配合Allure生成测试报告。面试官问到这个项目时你讲清楚三件事被测接口是什么你用到了哪些测试设计方法脚本在无人运行时怎么保证数据准确性。这比你在简历上写“熟悉Python、熟悉Pytest”要有说服力得多。如果你做过本地服务的性能测试用JMeter对一个本地部署的服务施压观察吞吐量和响应时间的变化这也是很棒的面试素材。讲项目时用STAR法背景、任务、行动、结果。不要说“我做过一个接口自动化项目”要说“我在练手项目中用Pytest编写了40条接口用例覆盖正常和异常场景解决了测试数据被重复创建的问题最终把接口回归时间从3小时压缩到20分钟”。有数字、有方法、有结果才算有说服力。6.3 分阶段准备建议三类人群怎么安排时间不同基础的人准备节奏完全不同我给三类人群分别排了一个时间方案。第一类是还有半年以上的在校生。建议前三个月系统学测试理论同时每天刷30分钟Linux和SQL第四个月开始动手做Appium或Pytest项目第5到6个月集中刷校招真题并复盘错题。第二类是笔试前一个月才开始准备的求职者不要贪多把精力集中在用例设计题、Linux命令、SQL这三类高频考点上每天练2道场景设计题并写完整思路同时把常见的自动化相关概念题背熟。第三类是从开发或其他岗位转过来的同学建议先把“测试用例设计方法”和“缺陷管理流程”补扎实再上一个自动化Demo项目因为你最缺的不是工具而是测试视角。时间分配可以参考这样的比例基础理论占30%Linux和SQL占25%自动化和接口测试占20%场景设计题占15%简历项目准备占10%。当然这个比例不用太死板但主线清楚心态就不容易慌。我自己带过的应届生里笔试高分和实际干活靠谱的人重合度其实没那么高。但反过来那些愿意把一套登录功能用例写出六十条、愿意对一个“先登录再下单”的用户路径反复追问的人往往成长最快。笔试只是一张入场券真正让你站住脚的还是平常积累的那股较真劲儿。回头再看蘑菇街这套笔试题你会发现它其实一直在传递一个信息这个岗位需要的是会思考的人而不是会背题的人。 蘑菇街测试笔试题深度拆解：从用例设计到自动化与安全
蘑菇街2019届校招-测试类笔试题我前后帮不少学弟学妹复盘过。有个很反直觉的现象这套笔试卷子里几乎没有正经的编程题但刷掉的人里一大半代码能力都还不错。原因其实很现实——测试岗笔试的核心不是看你写不写得出算法而是看你有没有一套在脑子里自动运转的测试思维。这篇东西不是标准答案汇编而是结合真题回忆、题库讨论和我自己带人复盘时整理出来的完整拆解包含考察方向的底层逻辑、典型题目的答题套路、以及那些让人丢分的细节。如果你正准备测试岗校招或者刚转行做测试想系统地查漏补缺这篇应该能帮你少走不少弯路。1. 先搞清楚蘑菇街想通过笔试筛出什么样的人1.1 电商测试岗位的能力模型不是“点点点”蘑菇街的业务核心是商品、交易、营销、支付这四块。电商产品的功能链路长、角色多一个用户从注册到下单再到售后中间要经过十几个模块不同模块之间还有状态同步和金额计算。所以这个岗位要的人不是只会照着用例点点点的执行者而是能理解业务、能设计出有效用例、能发现别人发现不了的问题的人。笔试就是围绕这个诉求设计的。它不会问你“TCP三次握手是哪三次”这种和业务毫无关系的孤岛知识而是会考你“登录功能怎么设计用例”“订单金额怎么校验”这种能直接映射到工作场景的题目。哪怕考Linux和SQL也是以“定位线上问题”为背景来考。理解了这一点你就能明白为什么很多编程很强的人反而挂了——他们做题时没有切换到测试视角。1.2 从热词分布反推考点三条主线如果去看当时测试笔试相关的讨论热词会发现几条明显的主线linux面试题、appium测试、pytest测试框架、接口自动化测试这些高频词指向的是硬技能安全测试、渗透测试、冒烟测试这些词指向的是测试专项知识。再结合当年校招的整体风向基本可以把考点收敛成三大类第一类测试基础与用例设计。这是最核心的包括测试流程、测试用例设计方法、缺陷管理、冒烟测试和回归测试的概念边界。第二类实操硬技能也就是Linux命令、SQL查询、日志分析。这类题最能拉开差距因为很多科班出身的同学反而没系统练过。第三类工具与框架的认知比如Appium怎么定位元素、JMeter怎么设计压测场景、Pytest的fixture是什么。笔试不会要求你手写完整脚本但会考察你懂不懂分层思想、懂不懂数据驱动。近几年测试行业又扩展出车载测试、智能座舱测试、AI测试这些新方向但在2019届的电商校招笔试里这些东西不会占太多篇幅。主线还是围绕功能测试、接口测试、自动化测试和安全测试来展开。1.3 题型结构的大致判断从大家回忆出来的信息看这套卷子的结构通常是单选或多选考概念简答题考理论用例设计题给一个具体功能最后一两道综合题给出业务场景让你设计测试方案。整体时间一般在60到90分钟题目量不算少所以时间分配很关键。我的建议是把时间分成三块概念题控制在20分钟以内不会的不要纠结先蒙一个标记好后面有时间再回头用例设计题留30分钟这类题是主观分大头宁可多写也不要写得太精简综合题必须留足15分钟因为要写出完整思路包括前置准备、测试范围、风险点。如果你在这些题上能稳住节奏基本就赢了一大半。2. 测试基础理论题背会概念只是及格线2.1 测试用例设计题的正确拆解法笔试里最容易出现的就是“请为登录功能设计测试用例”这类题。我见过太多人上来就写输入正确账号密码能登录输入错误密码提示错误。写完之后就交卷了然后被刷掉。问题不是他没学过测试而是他只用了“功能正常流”这一种视角。正确的拆法是先界定被测对象。登录功能至少包含用户名输入框、密码输入框、登录按钮、记住密码、忘记密码入口、第三方登录入口、验证码机制。然后对每个元素做输入分析。用户名要考虑长度为0、长度为1、正常长度、超长、包含空格、包含特殊字符、大小写混合密码要考虑对错、过期、连续错误锁定、是否支持粘贴、是否显示明文或掩码。这还没完还要考虑异常场景比如断网、弱网、服务器超时、并发重复点击提交以及安全性问题比如SQL注入、暴力破解防护、验证码有效期。我建议在答题时用一个二维矩阵来组织横向是测试维度纵向是具体场景。这样即使你写的用例数量不是最多的面试官也能看出你有结构化的思路。拿登录来说你可以分功能、安全、性能、兼容性、易用性五大类每个类别下再写3到5条。这种答法在阅卷时非常占优因为它展示的是思维框架而不是零散的记忆。2.2 缺陷报告与Bug生命周期送分也送命有些同学看到“描述一个你印象最深的Bug”或者“请写出一个缺陷报告要包含哪些要素”这种题觉得太简单了随便写几个字段就完事。但这里有个隐藏陷阱——严重级别和优先级很容易被混为一谈。严重级别指的是这个缺陷对系统的破坏程度功能不可用、数据丢失、界面错乱、提示文案错误严重级别依次降低。优先级指的是修复的先后顺序立即修复、本版本修复、下版本修复、可暂缓。一个Bug可以严重级别很高但优先级不高比如某个冷门页面出现数据错乱影响用户少你排到下个版本再修也没问题也可以严重级别不高但优先级很高比如首页的某个按钮文案写错了虽然不影响功能但影响品牌形象产品经理会催着马上改。答题时最好是手写一个完整的Bug单示例标题写明模块和现象比如“购物车-删除商品后数量角标未更新”环境信息写设备型号和系统版本前置条件写用户已登录且有1件商品在购物车复现步骤按1、2、3写清楚预期结果写“角标从1变为0”实际结果写“角标仍显示1”再附上截图或日志。这些字段看起来基础但能把它们写得完整的人反而是少数。2.3 冒烟测试、回归测试、兼容性测试的边界这三个概念在校招笔试里的出场率极高。很多人背定义背得很熟但一到结合场景就答错。比如面试官问“版本上线前先跑冒烟测试还是先跑回归测试”有人就答反了。冒烟测试的本质是“能不能测”的验证。它的名字源于硬件领域一个新电路板插上电如果冒烟了说明硬件有问题就别继续往下测了。软件里的冒烟测试是在新版本提测后先跑一遍覆盖核心主流程的用例比如登录、首页加载、商品加购、下单确认构建基本可用才允许进入详细测试阶段。它是第一道门不是用来发现深层次Bug的。回归测试的本质是“改了之后有没有改坏”。开发修复了一个Bug或者加了一个新功能你要验证原有功能依然正常。回归测试的用例池通常是从历史用例里挑出来的重点用例而不是把整个项目用例全部跑一遍。兼容性测试则是在不同设备、不同浏览器、不同系统版本上验证产品表现一致。笔试如果出现“Android和iOS哪个优先级更高”这种题不要直接回答系统而要反问目标用户用什么设备最多用数据说话。3. Linux、SQL与日志排查笔试拉开差距的实操硬题3.1 Linux命令题不是背命令是背场景很多人在笔试前背了一堆Linux命令但一遇到具体场景就懵了。比如题目给你一个场景“有一个Java进程CPU占用率异常偏高请用命令找出这个进程并进一步排查”。单纯背过ps和top是不够的你得把整个排查链路串起来。第一步用ps -ef | grep java找到对应的Java进程记住它的PID。第二步用top -H -p PID查看这个进程内各个线程的CPU占用情况找到占用率最高的线程ID。第三步把线程ID转成十六进制printf %x\n 线程ID然后用jstack PID | grep 十六进制线程ID 去查看这个线程当时的堆栈信息看它卡在哪个方法上。这个链路才是面试官想看到的排查能力。顺手整理一份高频命令对照表笔试前过一眼很有用场景命令说明实时查看日志tail -f app.log跟踪文件新增内容按关键字过滤日志grep -i error app.log忽略大小写匹配错误查看端口占用netstat -tlnp | grep 8080确认服务监听状态查看进程列表ps -ef | grep java过滤目标进程动态查看资源top 或 top -H -p PID查看进程线程资源占用查看磁盘使用df -h确认磁盘是否写满查看内存占用free -m检查可用内存统计日志行数wc -l app.log快速评估日志量3.2 SQL题从单表查询到业务聚合SQL是测试笔试里的必考题但考的粒度通常不会太深重点集中在单表查询和简单多表关联上。很多同学在大学里学过SQL但看到具体业务表就乱了因为不熟悉电商领域的数据模型。给你一个高频考法表orders(id, user_id, amount, create_time)要求查出“总消费金额前3的用户ID和总金额”。这种题考的是GROUP BY、ORDER BY、LIMIT和聚合函数的组合使用。标准写法是SELECT user_id, SUM(amount) AS total_amount FROM orders GROUP BY user_id ORDER BY total_amount DESC LIMIT 3;这里有几个容易踩的坑GROUP BY的字段必须包含在SELECT的非聚合列里否则在严格模式下会直接报错ORDER BY要用别名total_amount而不是SUM(amount)的表达式虽然MySQL支持但可读性差LIMIT的位置一定要放在最后。如果题目改成“每个用户的订单数”那就要用COUNT(*)而不是SUM(amount)。记住一点看到“每个”“按XX分组”就用GROUP BY看到“前N”就用ORDER BY加LIMIT这是最朴素的解题规律。3.3 日志分析与问题定位的答题套路日志分析题往往不会直接给你一段日志而是问你“App闪退你作为测试工程师怎么排查”。这种题没有标准答案但答题时一定要体现“从现象到原因”的收敛过程。我的回答框架是四步。第一步确定问题范围闪退是必现还是偶现发生在什么机型、什么系统版本、什么页面、什么操作路径。第二步收集日志Android优先看Logcat和Bugly崩溃堆栈iOS看Crash日志和Xcode的Device Log如果没有现成日志就尝试复现并手动抓取。第三步关联定位看崩溃堆栈的顶部是哪一层代码看是否是内存暴涨导致的OOM看是否是某个接口返回了预期外的数据格式。第四步验证猜想在开发修复后用相同设备同版本系统走一遍原始路径再跑一遍相邻模块的回归确认没有连带影响。按这个结构去写哪怕你对具体工具不熟也能给阅卷人留下“这个人是干过活的”印象。最忌讳的是直接回答“我让开发看看”笔试里这样写等于白卷。4. 自动化、接口与安全校招笔试里的加分题真相4.1 Appium与移动端测试考的是分层思维Appium是最常被提到的自动化工具很多学校甚至把Appium列入课程设计。笔试里考Appium的目标通常不是让你默写出完整的Capability配置而是考察你理不理解自动化测试的根本问题脚本怎么定位元素、怎么处理等待、怎么保证稳定性。元素定位是最基础的权利。id优先因为classname太容易重复XPath虽然灵活但性能和稳定性差。如果题目问“Appium定位一个登录按钮有哪些方式”你可以列出resource-id、class name、XPath、Android UI Automator的text定位这几种并说清楚各自的优缺点。等待问题也是高频隐式等待影响所有元素查找显式等待只针对特定元素笔试里如果问“页面加载慢导致脚本执行失败怎么办”答案不是盲目加sleep而是用显式等待等待元素出现再配合页面加载完成的标志。一个好的答题示例是from appium import webdriver from appium.webdriver.common.appiumby import AppiumBy from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC # 显式等待登录按钮出现 btn_login WebDriverWait(driver, 10).until( EC.presence_of_element_located((AppiumBy.ID, com.mogu:id/btn_login)) ) btn_login.click()这段代码不是考点本身但它展现了你在等什么、为什么等、等了之后做什么这就是分层思维。4.2 Pytest、JMeter与接口自动化工具属性的优先级笔试里出现Pytest和JMeter相关的题目本质上不是在考工具命令而是在考“你怎么看待自动化在整个测试体系里的位置”。Pytest是接口自动化最常用的框架之一fixture是它的核心用来做前置准备和清理参数化用pytest.mark.parametrize可以做到一组数据跑一个用例。举个例子一道接口测试设计题“请针对‘用户登录接口’设计自动化接口测试用例”。你要拆解的维度包括参数完整性和合法性缺参、多参、空值、类型错误、账户状态正常、被锁定、未注册、密码策略正确、错误、过期、加密与安全密码是否明文传输、是否支持错误尝试锁定、以及接口响应结果的断言点状态码、业务码、返回数据字段的格式。一套用例能覆盖这些点说明你已经不是“用Postman调通接口”的初级水平了。JMeter在笔试里常考的是压测场景的组成部分线程组设置并发数和循环次数HTTP请求采样器配置协议、域名、路径和参数断言验证响应结果聚合报告查看吞吐量、平均响应时间和错误率。如果题目问“怎么做一个100并发的接口压测”你的回答应该包含先设定目标再准备测试数据然后设计单接口脚本和混合链路脚本最后施压并同时监控服务器资源。工具只是手段思路才是分数。4.3 安全测试、渗透测试考到什么程度为止校招笔试里的安全题不会让你去渗透一个真实系统但常常会用概念题来过滤基础薄弱的人。出现频率最高的几个名词是SQL注入、XSS、CSRF和越权。SQL注入的核心逻辑是用户输入被拼接进了SQL语句导致数据库执行了非预期命令。答题时最好能举一个例子登录框里输入 OR 11如果后台直接拼接就可能绕过密码校验。对应地测试人员要做的验证是在输入框里尝试特殊字符和恶意Payload观察是否报错或是否返回异常数据。XSS关注的是脚本是否会被执行CSRF关注的是请求是否缺少来源验证和Token越权则是一个经典的业务逻辑漏洞——普通用户能不能通过改URL参数访问另一个用户的订单。如果遇到“你作为测试怎么发现一个SQL注入漏洞”这种题我的答题顺序是第一步用单引号、闭合符号提交到输入参数观察页面是否出现数据库报错第二步用布尔条件试探比如参数后加AND 11和AND 12看响应差异第三步用抓包工具重放请求跳过前端限制查看响应体第四步将结果整理成缺陷报告提交开发而不是一味深挖。笔试只要写出这种“识别到风险、验证到现象、记录到报告”的闭环就够了。5. 场景设计题笔试卷子里最像工作的部分5.1 购物车与支付流程的测试用例怎么铺蘑菇街这种电商公司最喜欢考“购物车加购”和“下单支付”的测试设计题。很多人的第一反应是点击加购商品出现在购物车然后完事了。但电商业务里的购物车远没有那么简单它牵扯到金额、库存、商品状态、用户状态、并发、优惠活动等多个核心系统。我的拆法分五层。第一层是功能加购空状态、加购非空状态、改数量、删商品、选商品结算、全选、批量删除、失效商品展示。第二层是金额计算满减、优惠券、会员折扣、多种优惠叠加的顺序这个最容易出Bug因为计算顺序不同结果差异很大。第三层是异常场景库存不足、商品下架、重复点击加购导致重复添加、支付超时、支付成功但回调未通知、余额不足。第四层是权限与安全未登录加购、A用户访问B用户购物车、接口越权。第五层是兼容性Android、iOS、H5三端表现是否一致切后台再回来数据是否刷新。写用例的时候可以这样组织编号前置条件操作步骤预期结果优先级购物车-001用户已登录购物车为空点击商品详情页“加入购物车”加购成功角标变为1购物车列表显示该商品P1购物车-002商品库存仅剩1件购物车中修改数量为5提示库存不足无法修改数量保持原值P1购物车-003商品已参加满300减50活动购物车中添加价格总计350元的商品结算页展示优惠后金额扣减50元P1购物车-004网络切换为弱网点击加购出现加载提示网络恢复后数据正确P25.2 性能测试相关概念题的回答框架性能测试在笔试里常见的考法是两种一种是概念题问QPS、TPS、并发用户数、响应时间、吞吐量分别是什么意思另一种是方案设计题比如“系统预计支撑1万QPS你怎么设计压测方案”。前者靠背后者靠框架。回答方案设计题时我建议你按“目标、环境、场景、实施、分析”五个层次展开先明确性能指标目标比如接口的平均响应时间小于200毫秒错误率小于0.1%再确认压测环境最好和生产环境隔离但资源配置一致接着设计压测场景包括单接口基准测试、混合链路测试、峰值并发测试和稳压测试然后选择施压工具比如JMeter或Gatling设置并发线程数和持续时间最后要看服务端监控CPU、内存、磁盘IO、GC频率、慢SQL、JVM线程池状态都要关注。这里要特别强调一点压测不是“跑完看个数字”就结束的它的核心价值是定位瓶颈。当你把并发从100提到500时响应时间从50毫秒涨到2秒你要能说出瓶颈在数据库连接池还是应用层线程池或者更上游的网络带宽。笔试能写到这一层说明你是真懂压测。5.3 主观题答案不是重点思考过程才是最后一道综合题通常很开放比如“你怎么理解测试工程师的价值”“开发说这个Bug不用改你怎么办”“如果上线前发现一个高严重级Bug你怎么决策”。这类题没有标准答案但有高下之分。答“怎么理解测试价值”时不要写成“测试是保证软件质量的最后一道防线”这种口号而是要说测试的核心价值是提供质量信息和风险决策依据在合适的时间用合适的成本发现和预防问题帮助团队在业务快速迭代和质量保障之间做权衡。答“开发说Bug不用改”时标准思路是先复现确认问题存在再站在用户路径上说明影响范围用数据和优先级说话如果双方各执一词就拉产品经理一起决策同时记录风险后续持续跟进。这个顺序体现的是协作能力不是死磕。如果你是第一次看到开放题心里发慌记住一个公式理解业务目标、拆解影响范围、给出备选方案、说明决策逻辑、补充风险记录。按这个公式走你的思考过程就会显得严密。6. 笔试之后的复盘与补强路径6.1 建一张自己的测试知识地图笔试结束之后不管结果如何复盘都比刷题更重要。我是建议所有准备测试岗的人都建一张自己的知识地图把平时零散学的东西结构化。大致分六块测试理论与流程、测试用例设计方法、操作系统与网络基础、数据库与Linux、自动化测试框架与工具、专项测试方向性能、安全、兼容性。每一块下面再拆细一点。比如“测试用例设计方法”下面要能随时说出等价类、边界值、场景法、错误推测法、判定表、正交实验这些方法各自适用什么场景。比如“性能测试”下面要能分清负载测试、压力测试、稳定性测试的区别。这张地图不需要一次填满每次看完一篇文章、做完一道题就更新一次三个月后再回头对比你会明显发现自己知识体系的补全速度。6.2 从笔试到面试项目经验怎么讲才有说服力笔试过了还有面试面试官大概率会问你“做过什么测试相关工作”。很多应届生说没有实习经历不知道怎么回答。我的建议是不要说自己没项目而是准备1到2个自己动手练过的Demo项目。举例来说你可以用Pytest写一个针对某个公开接口的自动化测试Demo用例里覆盖正常参数、异常参数、依赖登录态的场景再配合Allure生成测试报告。面试官问到这个项目时你讲清楚三件事被测接口是什么你用到了哪些测试设计方法脚本在无人运行时怎么保证数据准确性。这比你在简历上写“熟悉Python、熟悉Pytest”要有说服力得多。如果你做过本地服务的性能测试用JMeter对一个本地部署的服务施压观察吞吐量和响应时间的变化这也是很棒的面试素材。讲项目时用STAR法背景、任务、行动、结果。不要说“我做过一个接口自动化项目”要说“我在练手项目中用Pytest编写了40条接口用例覆盖正常和异常场景解决了测试数据被重复创建的问题最终把接口回归时间从3小时压缩到20分钟”。有数字、有方法、有结果才算有说服力。6.3 分阶段准备建议三类人群怎么安排时间不同基础的人准备节奏完全不同我给三类人群分别排了一个时间方案。第一类是还有半年以上的在校生。建议前三个月系统学测试理论同时每天刷30分钟Linux和SQL第四个月开始动手做Appium或Pytest项目第5到6个月集中刷校招真题并复盘错题。第二类是笔试前一个月才开始准备的求职者不要贪多把精力集中在用例设计题、Linux命令、SQL这三类高频考点上每天练2道场景设计题并写完整思路同时把常见的自动化相关概念题背熟。第三类是从开发或其他岗位转过来的同学建议先把“测试用例设计方法”和“缺陷管理流程”补扎实再上一个自动化Demo项目因为你最缺的不是工具而是测试视角。时间分配可以参考这样的比例基础理论占30%Linux和SQL占25%自动化和接口测试占20%场景设计题占15%简历项目准备占10%。当然这个比例不用太死板但主线清楚心态就不容易慌。我自己带过的应届生里笔试高分和实际干活靠谱的人重合度其实没那么高。但反过来那些愿意把一套登录功能用例写出六十条、愿意对一个“先登录再下单”的用户路径反复追问的人往往成长最快。笔试只是一张入场券真正让你站住脚的还是平常积累的那股较真劲儿。回头再看蘑菇街这套笔试题你会发现它其实一直在传递一个信息这个岗位需要的是会思考的人而不是会背题的人。