蘑菇街校招测试笔试复盘：题型拆解与答题思路全攻略

蘑菇街2019届校招测试笔试我踩过的坑题型复盘和答题思路一次讲透又到一年校招季后台好几个学弟学妹问我测开岗笔试怎么准备。我翻出当年整理的面经笔记发现蘑菇街2019届校招测试岗那套笔试题特别有代表性难度不算变态但覆盖面很广很能筛出真正做过测试的人。这套题让我印象最深的是它不考死记硬背的八股文而是把一个电商业务场景拆开揉碎用大量实际工作里会遇到的问题来考你。不管你是准备大厂测开岗还是中小厂测试岗把这套题的思路吃透比刷几十套普通笔试题都管用。今天我就按照当年的笔试题型把每类题背后的考察意图、答题思路、参考解法一步步拆开讲最后再聊聊我自己笔试时踩过的坑和总结的应试策略。1. 蘑菇街测试笔试的整体风格与考察逻辑1.1 当年笔试题型分布蘑菇街2019届校招测试岗笔试在线完成总时长大概120分钟题量不大但单题分值高。从题型结构来看分为四个部分单项选择题约10题覆盖软件测试理论、Linux命令、数据库SQL、网络协议基础多项选择题约5题考察测试用例设计思路、兼容性测试、性能测试指标问答题约3题重点考察测试用例设计、缺陷定位思路、接口测试方案综合题约2题一道测试场景设计一道自动化测试或性能测试方案设计。这种题型分布很典型前两部分筛基础后两部分筛实战能力。蘑菇街作为电商业务场景基本围绕商品搜索、加购、下单、支付、订单状态流转这些核心链路出题。1.2 测试岗笔试真正想筛选什么很多同学准备笔试时沉迷于刷概念题比如“什么是回归测试”“什么是冒烟测试”但蘑菇街这套题给我的感觉是概念只要知道就行它真正想筛的是三件事。第一你有没有完整的测试思维。给你一个功能你能不能从功能、兼容、性能、安全、异常场景多个维度去拆解而不是只想到“输入正常数据会不会通过”。第二你有没有实际动手经验。笔试题里夹杂了大量Linux命令、数据库查询、日志分析、接口抓包的场景没在测试环境里摸爬滚打过的人很难答到点子上。第三你有没有排查问题的逻辑。给你一个线上问题你能不能从页面表现、日志、接口、数据库、缓存一层层定位而不是只会说“提bug给开发”。想明白这三点你再看这套题就会发现它其实在模拟一个测试工程师一天的日常工作。2. 高频必考测试基础与用例设计题2.1 黑盒用例设计经典题怎么答蘑菇街笔试问答题第一道场景大概是“设计一个优惠券领取功能的测试用例”。这种题在电商测试里出现频率极高因为优惠券涉及用户状态、金额计算、时间限制、使用条件等多重逻辑。拿到这种题我建议用“先分类、后枚举”的思路作答而不是想到哪写到哪。分类的方式可以这样功能维度领券入口、领券成功、券到账、券展示、券使用、券过期、券退回数据维度正常金额、边界金额0元、1分、最大面额、负数、超长数字、小数用户维度新用户、老用户、未登录用户、黑名单用户、重复领取用户时间维度活动开始前、开始瞬间、进行中、结束瞬间、结束后异常维度网络中断、重复点击、并发领取、服务端超时、券库存为0兼容维度不同操作系统、不同APP版本、不同机型。然后对每个维度再枚举具体用例。比如“重复领取”这个场景你要写清楚前置条件用户已领取过该券、操作步骤再次点击领取按钮、预期结果提示已领取不发新券不扣库存。另外一个很关键的得分点是用例设计题一定要写“预期结果”。我当年批过一些简历很多同学写用例只写步骤不写预期结果这个在面试官眼里是致命伤。没有预期结果的用例执行的人根本不知道对错。2.2 白盒与代码分析题怎么答蘑菇街笔试选择题里有一道典型的白盒题给一段简单的Java或Python代码问分支覆盖、条件覆盖的用例设计。比如给一个判断订单状态的方法里面有if-else嵌套问至少需要几条用例才能达到分支覆盖。这类题看起来是代码题其实是考察你对覆盖率的理解。我总结一个最实用的答题逻辑语句覆盖每条语句至少执行一次分支覆盖判定覆盖每个判断的真假分支至少各执行一次条件覆盖每个判断中的每个条件的真假都要至少出现一次路径覆盖从入口到出口的所有可能路径至少执行一次。四个覆盖率的粒度从粗到细写用例数也依次增加。笔试中如果问你“最少几条用例”一般默认答案是分支覆盖的用例数。你可以在答题时先画一下代码的判定结构数一数有几个判断节点每个判断有两个分支再考虑是否存在可合并路径最后给出用例数。这类题制胜的关键是不要只看if条件本身还要看有没有else、有没有return提前退出、有没有循环。循环也算一个判定节点进入循环和退出循环是两条分支。2.3 用例设计题答题模板和得分点问答题里写用例设计千万别写口语化的废话直接用表格列出来表达高效又专业。我常用的模板是用例编号前置条件测试步骤测试数据预期结果优先级拿“优惠券领取”举例可以写用例编号前置条件测试步骤测试数据预期结果优先级TC_Coupon_001用户已登录活动未开始进入活动页点击领取无提示“活动未开始”按钮置灰高TC_Coupon_002用户已登录活动进行中券库存充足点击领取正常数据提示“领取成功”券进入卡包高TC_Coupon_003用户已登录活动进行中券库存为0点击领取库存0提示“手慢了券被抢光”高TC_Coupon_004用户已登录已领取过该券再次点击领取用户已有券提示“已领取过”不重复发放高TC_Coupon_005未登录用户进入活动页点击领取未登录态跳转登录页登录后返回活动页中我写这个表的时候会特别注意“前置条件”填得完整不完整因为前置条件决定用例能不能稳定复现。比如并发领取类的用例前置条件就写“用户已登录活动进行中准备多台设备或并发工具”。这个答题模板的得分点在于维度覆盖全、预期结果明确、优先级合理、有前置条件。做到这四点面试官一眼就能看出你有实际写用例的经验。3. Linux、数据库与HTTP测开基础三件套3.1 Linux常用命令与排查思路蘑菇街笔试的Linux题目一般两种考法一种是直接给场景让你写命令比如“找出日志文件中出现次数最多的IP前10个”另一种是给一段命令问你输出结果是什么。先说第一种“找出日志文件中出现次数最多的IP前10个”这是测试岗笔试的经典题考察sort、uniq、awk、head的组合用法。标准答案awk {print $1} access.log | sort | uniq -c | sort -rn | head -10如果你对awk不太熟也可以用cut提取第一列假设日志第一列是IPcut -d -f1 access.log | sort | uniq -c | sort -rn | head -10注意这里有个坑uniq只能去除相邻的重复行所以必须先sort再uniq否则统计结果会出错。很多同学直接用cat access.log | uniq -c出来的数字是错的。我在笔试时专门用这条去检查发现这是一个很容易丢分的小细节。再说第二种给你一个命令问输出比如ps -ef | grep java | grep -v grep我在自己的面试复盘笔记里专门写过这题考察的不只是ps和grep重点是grep -v grep它用来过滤掉那条grep进程本身。很多人不知道这个细节会认为这条命令会匹配到那个grep进程。有实际部署经验的人一眼就能看懂这就是线上排查Java进程时的常用命令。3.2 SQL查询与测试数据准备数据库SQL题也是测试岗笔试的常客蘑菇街这套题里有两道SQL一道是简单查询一道是联表查询。我的经验是先不要急着写SQL语句先把表结构和业务关系想清楚再动笔这样不容易丢分。典型的题目是有三张表user用户表、order订单表、order_item订单明细表问“查询最近30天内下单次数超过5次的用户ID和下单次数”或者“查询每个商品类目的销售额Top10”。我写SQL时会特别注意几个点用LEFT JOIN还是INNER JOIN取决于业务上是否需要保留没有匹配记录的行GROUP BY和聚合函数配合使用时SELECT中的非聚合列必须出现在GROUP BY里时间过滤条件写在WHERE里但要注意时间字段的类型和时区比如有的表存的是时间戳有的存的是datetime数据量大时DISTINCT的性能比EXISTS差笔试中如果考察优化思路要主动提到索引、分区、limit。另外我还遇到过一道很有意思的题给一个表表中商品价格有重复问获取价格排名第二的商品名称。这题用子查询或者窗口函数都可以解SELECT product_name FROM product WHERE price ( SELECT DISTINCT price FROM product ORDER BY price DESC LIMIT 1,1 );用窗口函数row_number()或者dense_rank()思路更清晰SELECT product_name FROM ( SELECT product_name, price, DENSE_RANK() OVER (ORDER BY price DESC) rk FROM product ) t WHERE rk 2;注意这两个写法在“价格并列”时的结果不同DISTINCT子查询只取一个最接近的值dense_rank会返回所有并列第二的商品。笔试答案里写清楚这个差异反而能体现你的思考深度。3.3 HTTP接口测试与抓包分析要点HTTP协议是测试岗笔试绕不开的内容蘑菇街的题主要考状态码、请求方法、幂等性。这部分我喜欢用一个“接口调试实战”的视角来回答。选择题大概率考状态码200是OK201是Created301是永久重定向302是临时重定向400是客户端参数错误401是未认证403是禁止访问404是资源不存在500是服务端内部错误502是网关错误503是服务不可用504是网关超时。其中最容易错的是401和403。401是“你没登录”403是“你登录了但没权限”一句话概括就是“认证”和“授权”的区别。我当年笔试时选对了但面试时被追问“如果接口返回401你会怎么排查”我答了四个步骤第一步检查请求头Authorization是否携带token第二步检查token是否过期看expire字段第三步检查token签名是否正确和后端确认密钥或用JWT调试工具解析第四步检查是否是因为服务端缓存或Redis中token状态被主动失效。这个排查顺序很实用因为实际工作中遇到401九成都是token带错或过期剩下的是权限配置问题。另外HTTP方法幂等性也常考。在电商下单接口里POST方式因为不保证幂等重复提交可能创建多个订单所以实际设计中一般会加幂等键幂等token。笔试里如果问你“如何避免用户重复点击下单产生两个订单”你要能写出方案比如前端置灰按钮、后端根据幂等键去重、数据库唯一索引约束三个层级互相兜底。4. 自动化与接口测试从笔试题到实战能力4.1 自动化测试框架选型与原理蘑菇街的综合题有一道是“设计一个自动化测试方案”题目大概给了一个Web端购物车功能问你会用什么框架、怎么组织用例、怎么处理数据。这题没有标准答案但考察的知识点非常集中。我的回答框架是先选型再讲架构最后说落地的难点。选型方面Web端我用Selenium移动端用Appium接口层用Python的requests或Java的RestAssured再搭配pytest或TestNG做用例组织。讲讲原理Selenium和Appium的核心机制其实是同一套思路通过WebDriver协议把测试脚本里的命令解析成浏览器或手机能理解的操作指令再通过浏览器的调试端口或手机端的UiAutomator/XCUITest驱动真实界面去执行操作。你不需要深挖每一行实现但你要能说清楚脚本、驱动程序、目标设备三者之间的关系。架构上我一般建议分层设计用例层只写业务场景和断言不写操作细节页面对象层Page Object每个页面封装成类页面元素和操作方法放一起公共层封装启动浏览器、截图、日志、报告生成、数据库连接。为什么要分层因为一个自动化项目如果所有脚本都堆在一起页面元素一改几十个脚本全都要改。用Page Object模式页面改动只影响对应的页面类。我实际维护过电商自动化用例体会特别深元素定位一旦变更没有分层的项目只能加班熬夜。4.2 Appium与移动端测试笔试考点题里如果出现了Appium大概率考这几个点第一Appium的定位方式。Android端支持id、name、class name、xpath、UIAutomator等iOS端支持accessibility id、class name、xpath、iOS Predicate String。你在笔试中答定位方式时记得补一句“优先使用稳定属性定位比如resource-id或accessibility idxpath定位虽然万能但页面结构一变就很脆”。第二滑动操作的坐标处理。Appium里面滑动一般用swipe或TouchAction但坐标不能写死因为不同分辨率适配不一样。我比较推荐的做法是先获取屏幕宽度和高度再用相对位置滑动。这个细节在实际工作中非常常见笔试写出来很加分。第三混合应用的处理。点击按钮会跳到一个WebView页面此时自动化脚本经常定位不到元素。这个问题的本质原因是WebView渲染的内容不再走原生控件树而是HTML页面。解决方式是用driver.contexts切换上下文切到对应的WebView context然后用Selenium那套元素定位方式去处理页面内容。4.3 接口自动化测试框架设计思路接口自动化几乎是测开岗笔试的必考内容蘑菇街综合题里也有一道和接口测试相关的题。我的回答思路一般围绕四个问题展开怎么做数据管理、怎么做断言、怎么做报告、怎么集成到持续集成里。先讲数据管理我的思路是测试数据和测试逻辑分离不把数据硬编码在脚本里。常见方案是用json或yaml文件存放接口请求参数用pytest的参数化功能去驱动用例。比如一个登录接口# data/login_data.yaml - case_name: 正常登录 username: test_user password: 123456 expect: 200 - case_name: 密码错误 username: test_user password: wrong expect: 401然后在测试代码里import pytest import yaml import requests with open(data/login_data.yaml, encodingutf-8) as f: login_cases yaml.safe_load(f) pytest.mark.parametrize(case, login_cases, ids[case[case_name] for case in login_cases]) def test_login(case): resp requests.post(http://api.example.com/login, json{ username: case[username], password: case[password] }) assert resp.status_code case[expect]这种设计维护成本低加新用例只需要在yaml里加一段不需要改代码。再讲断言我的习惯是分层断言第一层响应状态码第二层业务code第三层关键字段值第四层数据库落库数据。只断言状态码是不够的因为服务端可能返回200但是业务失败。接口测试一定要校验“业务正确性”而不只是“通信成功”。报告和持续集成方面pytest可以搭配allure-pytest生成漂亮的HTML报告在Jenkins里配置定时任务或代码提交后自动触发。笔试里如果问CI怎么集成你只要把链路描述清楚代码push到GitLab触发webhook、Jenkins拉代码并执行pytest、跑完生成allure报告并上传、测试结果通过企业微信或邮件通知相关人这就算完整闭环了。4.4 如何回答“如何测试登录接口”这类开放题我在校招笔试和面试里被问过好几次“给你一个登录接口你怎么测”这道题能区分出有实战经验和没实战经验的人。我的回答套路是这么组织的功能测试正确用户名和密码能否登录成功用户名正确、密码错误提示是否正确且不泄露用户是否存在用户名不存在的情况密码为空、用户名为空、前后有空格密码是否支持特殊字符、超长密码、中文字符验证码图形验证码或短信验证码的过期时间、错误次数限制记住密码功能对密码的存储是否安全。安全测试弱口令校验比如123456、qwerty这类密码是否会被拒绝SQL注入在用户名和密码字段输入单引号、or 11等字符串登录接口是否做限流和防暴力破解比如连续5次失败是否锁定或增加验证码接口是否使用HTTPS传输密码是否加密传输token过期后是否被强制要求重新登录。兼容性和异常场景不同浏览器、不同操作系统、不同网络环境弱网、断网、请求超时下的处理服务端宕机时前端如何提示多端同时登录同一账号的处理。性能测试并发100、500、1000用户同时登录服务端的响应时间和错误率如何数据库连接池是否够用慢查询有没有拖垮数据库。还有一点特别容易被遗漏幂等性。登录接口本身应该是幂等的但密码错误后多次重复提交不能触发短信验证码重复发送不能导致账号被永久锁定这类场景也是要测的。把这道开放题答全了面试官基本上就认为你有过完整的功能测试实践因为只看过书的人绝对想不到弱网、SQL注入、多端登录这些维度。5. 性能测试与调优笔试中的压轴题5.1 性能测试流程及核心指标蘑菇街笔试选择题里有一道问“性能测试有哪些常用指标”大项有并发用户数、TPS、响应时间、吞吐量、错误率、资源利用率。这几个名词看着简单但笔试里经常设置陷阱。我解释一个最容易被混淆的概念并发用户数和在线用户数。比如系统里有1000个在线用户但同一时间真正在操作的人可能只有100个这100才是并发用户数。性能测试中我们压测的是并发用户数不是在线用户数。TPSTransactions Per Second是每秒钟系统能处理的事务数。响应时间则是单个请求从发出到收到响应的时间。这两个指标容易产生误解TPS高不代表响应时间就一定低因为可能有大并发在支撑大量请求排队处理每个请求等了很久。合格的做法是同时看两个指标别被单个数字迷惑。我用我的实操项目举例我压测过一个订单查询接口目标要求是并发用户50TPS不低于300平均响应时间不超过500ms错误率低于0.1%。最终压测结果TPS只有240平均响应时间850ms系统CPU使用率已经95%。这会引导你进入性能分析环节。5.2 性能测试中如何定位瓶颈笔试中如果问“压测发现问题怎么排查”这题比“性能指标有哪些”含金量高很多。我自己压测时的排查路径一般是先看网络再看服务端应用日志然后看数据库和中间件最后看监控。具体来说先用压测工具JMeter、Locust确认瓶颈现象是响应时间变长还是错误率飙升再看压测机和被压服务所在机器的网络带宽、网络延迟排查是否有网络拥塞。如果网络没事就登录应用服务器看CPU、内存、磁盘IO、文件句柄数通过top、vmstat、iostat这些命令看。数据库方面登录MySQL后查看慢查询日志mysqld_slow_query_log用EXPLAIN分析查询计划看是否走了索引、有没有全表扫描。我之前排查过一个问题接口突然变慢最后定位到是SQL查询没有命中索引导致慢查询拖垮了整个服务的连接池。这是很典型的性能瓶颈。缓存层也要排查Redis的命中率、内存淘汰策略、过期键堆积以及服务端缓存穿透、缓存击穿、缓存雪崩。这三大问题在电商高并发场景里出现频率极高。蘑菇街作为电商业务对缓存问题的考察也在意料之中。笔试题的压轴题很可能就是“如果商品详情页接口在大促时出现超时你会从哪些方面分析和解决”回答时可以把缓存层的排查放进去。我建议回答这类题先亮出排查步骤再逐层展开然后给出实际发生的case。比如先讲我用top看到CPU飙高再用jstack查看线程快照发现大量线程阻塞在数据库连接获取上再确认连接池被慢SQL占满最后定位到那条SQL缺索引。把这个链条讲完整面试官会觉得你真的做过。5.3 性能测试方案设计题的作答框架还有一类综合题会直接问“给一个秒杀活动请你设计性能测试方案”。这类题的作答是有框架的我总结了一个通用的方案模板明确测试目标确认业务目标如支持多少用户同时参与秒杀和性能指标TPS、响应时间、错误率分析业务场景梳理秒杀链路涉及的接口如商品详情、创建订单、扣减库存、支付回调构建测试数据准备商品库存数据、用户账号数据、优惠券数据注意数据量和真实环境接近设计测试模型不同接口的并发比例分配比如浏览商品30%、加购20%、下单30%、支付20%执行压测小并发调优逐级加压记录各阶段指标监控与定位观察应用、数据库、缓存、消息队列的监控数据调优与回归针对瓶颈做代码优化、SQL优化、缓存优化或扩容然后回归验证。用这个框架作答能保证逻辑完整不会漏掉关键环节。同时你可以补充一个重要结论性能测试一定是从小并发逐步压上来的直接跑5000并发然后看系统挂不挂这种做法在实际工作中是没有价值的因为你需要知道系统在50、100、200、500并发时各自的拐点在哪里。6. 应试策略与常见问题6.1 笔试时间分配蘑菇街这套题题型多建议拿到题先花三分钟通读一遍全卷评估一下哪些题有把握、哪些题需要更多思考。我的策略是先做选择题和填空题因为这些题只要你知识储备到位基本不花时间先把能拿的分全部拿到手再集中火力做问答题和综合题。问答题和综合题的分值往往占大头特别是用例设计和测试方案设计每道题认真答可以写很久。建议留至少50分钟给这类题。如果时间不够哪怕方案不完整也要把大框架搭出来把能想到的维度都列出来因为这类题是按点给分的框架完整就能拿到基础分。6.2 雷区和扣分点我总结这套题容易丢分的地方用例设计只写正常流程不写异常和边界场景。这是最致命的电商系统出问题往往在异常场景写SQL时不考虑表关联语义该用内连接的用了左连接导致结果集不一致性能测试只答指标名字不答分析方法面试官看不出你有没有真实项目经验自动化测试题目只聊用什么工具不聊数据管理、报告、CI集成显得没有完整落地经验回答开放题时不做结构化组织想到哪写到哪很难让面试官抓住重点。笔试时间允许的情况下每道开放题尽量分类分点作答。比如“登录接口怎么测”我会先写功能测试、再写安全测试、再写性能测试每个分类下用一句话概括测试要点。这样的回答看起来很清晰。6.3 校招测试岗笔试的复习重点根据这套题反推准备校招测试岗笔试的复习重点可以这么规划测试基础理论黑盒白盒分类、等价类边界值场景法、测试流程、缺陷生命周期、覆盖率概念 Linux命令文件操作、日志查看、进程管理、网络排查、文本处理三剑客grep/sed/awk 数据库增删改查、聚合、联表、子查询、索引原理、查询优化 网络基础TCP三次握手四次挥手、HTTP状态码、HTTPS原理、Cookie和Session、token认证机制 接口测试请求方法、请求头、鉴权方式、接口测试用例设计、mock和抓包工具 自动化测试Selenium、Appium、pytest、数据驱动、关键字驱动、Page Object模式 性能测试指标、流程、工具、瓶颈分析思路 业务场景电商核心链路、优惠券、秒杀、购物车、订单状态流转。每个知识点我都会建议“至少能举一个实际场景说明它怎么用”比如讲Linux命令时结合“看日志定位报错”的场景来记而不是死记参数。写在最后的个人总结当年笔试蘑菇街这一套题目我最大的收获是重新理解了“测试工程师”这个岗位。它不是简单的点一点、看一看而是需要你同时懂业务逻辑、懂代码实现、懂系统架构、懂用户使用习惯。后来我自己在带实习生的过程中也喜欢用类似的笔试题来筛人。我发现真正能拿高分的人并不是背了多少题而是平时学习时喜欢多问一句“为什么”。为什么登录要加密传输为什么数据库要加索引为什么接口要做幂等为什么性能测试要从小并发开始。搞清楚这些为什么笔试里不管题目怎么换都能用逻辑推导出答案。如果你正在准备校招测试岗笔试希望这篇文章能帮你少走一些弯路。笔试只是第一步后面还有面试环节会继续深挖。如果有机会我会再把蘑菇街这套题的面试环节单独写一篇出来聊。