蘑菇街的测试笔试题我手里刚好还有一份2019年的版本。前两天整理网盘翻出来重新看了一遍还是觉得这套题出得挺有水平——不是那种网上随便抄的八股文而是真能筛掉一批只会背概念、不会动脑子的人。今天就把这套题掰开揉碎了讲一遍重点不在于“给答案”而是让你搞清楚每一道题背后面试官到底想从你身上看到什么。先说下这套题的适用范围如果你是准备大厂测试岗实习、应届生校招或者想从功能测试转自动化方向的在职同学这套题的参考价值都不小。蘑菇街虽然主打电商但当年它的技术栈和移动端业务在杭州也算排得上号所以考题覆盖了基础理论、Linux、数据库、接口测试、移动端专项、用例设计这些维度几乎就是一份浓缩版的“测试工程师技能地图”。1. 考题整体观察这是一场“知识面思维深度”的双重筛选先聊一个很多人会忽略的问题笔试到底在筛什么人很多同学准备测试面试一上来就拼命刷题、背概念这其实是最低效的准备方式。从招聘方角度笔试环节的定位从来不是“考倒你”而是用最短的时间判断两件事——你的基础扎不扎实以及你遇到陌生问题时的反应路径是什么。蘑菇街这套2019年的卷子整体结构大概是这样的选择题约20道覆盖测试基础、网络协议、数据库、操作系统、数据结构判断题约10道抠细节专治“貌似懂了”简答题约4-5道冒烟测试与回归测试的区别、如何设计一个登录功能的测试用例、App闪退怎么排查综合设计题1-2道给一个购物车或者直播间场景让你从零开始写测试方案开放题1道比如“如何测试一个不知道规则的黑盒接口”考察测试思维和逻辑拆解能力这套组合拳打完一个人是背题库背出来的还是真的干过活、平时有积累基本一清二楚。1.1 从热词看测试行业的技术风向借这次写博文的机会我也顺手扫了一眼近期的测试相关热搜词发现几个很有意思的动向跟这套2019年的考题对照起来看能看出行业的变化轨迹自动化测试持续升温pytest、appium、Selenium、Jenkins这些关键词的搜索量一直居高不下说明企业已经不再满足于“能写脚本”而是要求测试工程师具备搭建框架、维护脚本的能力。专项测试需求爆发网速测试、内存测试、连接数测试、设备老化测试全自动执行脚本——这些词背后是业务场景的多元化尤其是车载测试、智能座舱测试、智能网联汽车道路测试这类新领域把测试的专业度推到了一个新高度。测试左移与开发融合双脉冲测试、芯片测试、EMC测试这些硬件领域的词上榜配合大模型投毒测试这类AI话题说明测试工程师的知识边界正在快速拓宽。把这些动向跟蘑菇街的真题放在一起看你会发现一个规律基础理论始终是底线但光有理论已经不够了企业要的是能解决实际问题的复合型测试人才。1.2 为什么从“电商业务”切入考查测试思维蘑菇街笔试题有个很典型的特征大量题目都挂在电商场景下。比如给你一个“购物车”功能让你写测试用例或者给你一个“直播间抢购”的场景让你设计压测方案。很多人觉得这只是业务背景的包装随便套个场景就行。其实不然。电商业务有两个特点决定了它是考察测试思维的最佳载体链路长从用户点击、前端渲染、接口调用、后端逻辑、数据库读写到最终支付回调任何一个环节出问题用户感知都是“APP卡住了”或者“下单失败”测试人员必须具备全链路排查的思维。并发高且业务规则复杂优惠券叠加、库存扣减、价格计算、订单状态流转这些规则本身就是bug的高发区。所以如果你准备的面试题库里全是“登录功能怎么测”这种泛泛的题目建议还是多结合具体业务场景去想一想。面试官不关心你知道多少概念关心的是你能不能在一个具体的业务里发现问题、拆解问题。2. 核心考点逐题拆解基础理论题背后的“为什么”这一节是全文的干货重点。我会把典型的考点题目列出来不仅告诉你“选什么”更会拆解“为什么这么选”以及“如果你答错了暴露的是什么问题”。2.1 测试金字塔与测试分层策略真题原型关于单元测试、集成测试、系统测试的层次关系下列描述正确的是这个知识点看似基础但很多人都理解得比较浅。测试金字塔的核心思想是底层单元测试数量最多越往上数量越少成本越高执行速度越慢。这样设计的底层逻辑是——bug发现得越早修复成本越低。如果你把这题答错了面试官大概率会判断你没有真正参与过项目迭代。因为在一个实际项目中如果系统测试阶段才发现底层逻辑错误那代价是灾难性的。回归测试要重跑相关模块要重测上线时间可能整个泡汤。我自己的经验是在回答这类题目时最好主动补充一句在实际项目中测试金字塔不是死板的如果你接手的是一个历史遗留项目底层的单元测试可能根本没有这时候就需要先通过接口测试把核心链路保护起来再逐步补单元测试。2.2 黑盒测试方法的适用边界真题原型等价类划分法和边界值分析法在以下哪个场景中最适用等价类划分的核心逻辑是“用最少的数据覆盖尽可能多的可能性”它的假设是同一等价类中的输入程序的处理逻辑是一致的。边界值分析法则是等价类的补充因为实践证明程序最容易出错的地方不在“区间内部”而在“区间的边界”上。有个经典例子一个输入框要求输入1到100的整数。用等价类划分你只需要测3个数据0无效、50有效、101无效。用边界值分析法你需要测5个数据0、1、2、99、100、101两个边界及其两侧。你测出bug的概率后者远高于前者。我当时复习这题时自己动手写过一个测试用例表格现在看依然很有用分享给你测试数据等价类边界点预期结果0无效等价类下边界外侧提示“请输入1-100的整数”1有效等价类下边界通过2有效等价类下边界内测通过99有效等价类上边界内测通过100有效等价类上边界通过101无效等价类上边界外侧提示越界面试时如果能把“为什么边界容易出错”解释清楚因为程序员常用还是的判断很容易写错这题的得分跟单纯背答案完全不同。2.3 冒烟测试与回归测试的底层区别真题原型简述冒烟测试和回归测试的区别它们分别在什么阶段执行如果只答“冒烟测试是测主流程回归测试是测所有功能”那只能得一半分。更完整的理解是冒烟测试解决的是“要不要继续测下去”的问题如果核心主流程都跑不通说明版本质量太差后续的系统测试、功能测试都没有意义直接打回开发重提。回归测试解决的是“改了旧代码之后老功能有没有坏”的问题它的核心价值是守护存量功能。这里有个实操点值得展开。现在很多团队会用自动化手段做“冒烟测试门禁”也就是每次开发提交代码后CI流水线自动跑一遍核心用例跑不过就阻断合并请求。这个机制的本质就是把传统的冒烟测试往前挪到了提测之前提前拦截低级问题。按我个人的经验你答这题时如果能主动提到“冒烟测试不适合做成全量自动化因为它强调的是快回归测试才适合逐步加大自动化覆盖率”面试官会立刻对你另眼相看——这一看就是有实战的人才说得出来的认知。2.4 登录功能用例设计所有人都答过但多数人答不全真题原型请设计一个登录功能的测试用例要求覆盖功能、安全、性能、兼容性四个方面。这题是面试题里的“Hello World”但恰恰是最能拉开差距的题。80%的人都能写出输入正确账号密码能登录、输入错误密码有提示。但只有少数人能把这道题答出层次感。一个让我比较满意的答题框架是这样的功能方面正常登录正确账号正确密码异常登录正确账号错误密码、错误账号正确密码、错误账号错误密码账号为空、密码为空、账号密码均为空密码是否区分大小写是否支持特殊字符登录成功后跳转页面是否正确登录成功后session/cookie是否生成记住密码、自动登录功能安全方面密码是否密文传输抓包看请求体密码是否密文存储防脱库连续多次输错密码是否触发锁定或验证码是否存在SQL注入风险输入 or 11 --登录态 token 是否会过期是否支持异地登录提醒验证码是否可以复用性能方面并发10个用户同时登录的响应时间并发100个用户登录时服务器是否报错弱网环境下登录是否超时、是否给出合理提示连续多次快速点击登录按钮是否产生重复请求兼容性方面不同浏览器Chrome、Safari、Firefox、Edge不同操作系统Windows、macOS、iOS、Android不同分辨率下的页面显示微信内置浏览器是否正常看出来了吗这个思路的本质不是“背用例”而是用质量模型去引导自己的思考。只要访谈者的思维从“功能有没有做对”升级到“功能在各种条件下是否仍然做对”用例自然就立体起来了。3. 实操环节从真题到真实项目的一线方法笔试里有一类题很多同学觉得“无解”“给你一个购物车功能你怎么测”本部分我会用一个类似的实操案例带你走一遍我真实做事的流程。你会发现笔试题里考的思考方式跟实际工作中的做法完全一致——只是笔试题没有告诉你所有上下文需要你自己补全假设。3.1 一个标准的“从零测试”实操流程拿到一个功能需求我一般会走这五步第一步拆解需求和埋点。把需求文档里涉及的功能点全部列出来每一条都能对应到一个界面组件或接口。比如购物车功能拆出来就有加购、删除、修改数量、选中/取消选中、批量删除、单品小计、总价计算、清空失效商品、结算跳转这些子功能点。用一个XMind或者Excel把这些功能点铺开作为后面用例的目录。第二步梳理业务规则和异常分支。这一步最考验功力。比如购物车中商品下架了怎么办、库存不足怎么办、价格变动了怎么办、优惠券抵扣规则和商品叠加规则是什么。这些规则不梳理清楚后期发现了再补用例沟通成本会高很多。第三步按照优先级设计用例。核心链路加购→结算→支付的用例优先级最高异常处理和边界条件次之兼容性和体验类的用例可以往后排。不要试图一次性写完所有用例测试用例是动态迭代的先保证核心链路覆盖再逐步补充。第四步准备测试数据和执行环境。这一步最容易被实习生忽略。有些公司测试环境的数据是要找开发帮忙造的比如一个“库存只剩1件”的商品、一个“已经领过优惠券”的账号、一个“被限制下单”的黑名单用户。等你进入用例执行阶段如果数据没备齐执行效率会非常低。第五步执行、记录、追踪。发现的bug不是提个单就完事了还要定期跟进、验证修复、做回归。这一步看起来简单但很多新人因为“不好意思催开发”导致bug迟迟没有解决。我的建议是提bug时把复现步骤写清楚、附上日志和截图这样你跟开发沟通的底气就足了。3.2 接口测试中的经典错误与正确姿势这套笔试题里还有一类高频题型给一个接口文档让你设计测试用例或者判断某个说法是否正确。这类题考察的就是接口测试的基本功。最常见的一个错误认知是接口测试就是测HTTP状态码。只要返回200就认为接口没问题这是个大坑。接口测试真正要验证的至少包括业务状态码HTTP 200不代表业务成功很多接口的业务状态码是封装在response body里面的比如code:0代表成功、code:50001代表参数错误。数据完整性返回的字段是否齐全、类型是否正确、嵌套层级是否完整、为空时是否返回了默认值。边界和异常入参缺失必填参数、传入超长字符串、传入非法类型、传入空值、传入不存在的ID。幂等性同一个请求发送两次结果是否一致。尤其是涉及到扣款、下单这类操作的接口幂等性测试做不好线上就等着出大事故。鉴权和越权未登录时访问接口是否被拦截普通用户能否通过修改ID来访问其他用户的数据。有一个经典案例某次项目里我测试一个优惠券领取接口用普通账号调用可以正常领取但把请求里的用户ID改成另一个人的居然也能领成功。这就是一个典型的越权漏洞属于安全测试的范畴。可以很肯定地说这类问题在功能测试阶段是测不出来的必须基于接口测试、加上安全测试的思维才能发现。3.3 移动端专项测试网页端测不到的那些坑题目中如果出现App专项测试很容易让只做过Web端测试的同学卡壳。蘑菇街的商业场景核心在App上所以移动端专项是必考方向。除了功能测试之外移动端至少还有几个专项值得掌握内存测试使用Profiler或Android Studio的Memory Profiler观察应用的内存占用曲线。如果内存只增不减大概率存在内存泄漏。典型的场景是页面退出后Activity或Fragment没有被回收。内存泄漏累积到一定程度就会引发OOM闪退。弱网测试电商App在弱网环境下的用户体验直接影响转化率。弱网测试关注的是请求超时后有没有重试机制、loading有没有超时限制、网络从弱网恢复到正常后页面数据能否自动刷新、是否有合理的“网络不给力”提示。中断测试这个经常被遗漏。App使用过程中来电话、来短信、闹钟弹出、用户主动切到后台再回来这些场景都会触发App生命周期变化。中断测试的核心是检查App在被中断后能否恢复原来的页面状态和数据是否还在。兼容性和老化测试不同机型、不同系统版本、屏幕分辨率差异都可能导致布局错乱或功能失效。设备老化测试全自动执行脚本这个词近期很热门本质上就是通过自动化脚本在大量真机或云真机平台上批量跑兼容性用例替代人工一台一台手测。这里的建议是准备面试时不必把每个专项都做到很深入但至少要能说清楚**“这个专项解决什么问题、用什么工具、典型的风险点是什么”**。这一套组合拳打下来面试官对你的印象会比那些只会说“我做过功能测试”的候选人好很多。4. 自动化测试框架选型与实测踩坑记录近几年笔试题里出现了一个新趋势不只是问概念还会让你写一小段自动化脚本或者让你说说pytest和unittest的区别。我专门用一节内容来写自动化测试也是因为这个方向是面试翻盘的关键——同样水平的候选人会自动化的一定更占优势。4.1 pytest vs unittest为什么我选择pytestPython技术栈里unittest是标准库自带的pytest是第三方库。从功能上讲pytest几乎是unittest的超集所以我个人的建议是新项目一律直接用pytest。用表格对比就非常直观对比维度unittestpytest断言方式使用self.assertXxx()依赖类的继承使用原生assert语句语法更简洁TestCase组织必须继承unittest.TestCase不需要继承任何类普通函数加test_前缀即可Fixture管理通过setUp/tearDown方法通过pytest.fixture装饰器支持参数化、作用域管理参数化需要依赖第三方库ddt内置pytest.mark.parametrize装饰器插件生态官方库为主有大量第三方插件如pytest-html、pytest-xdist、pytest-rerunfailures测试发现通过unittest.main()或TestLoader通过pytest命令自动递归查找test_*.py刚才说到pytest的生态这里稍微展开几个我定位问题时的“救命插件”pytest-xdist并行执行测试用例配合-n auto参数让多个CPU核心同时跑用例大型回归测试从几小时压缩到十几分钟不是梦。pytest-rerunfailures用例失败后自动重试。这个要小心使用它只适合处理偶发性的环境问题比如网络抖动不适合掩盖稳定的代码缺陷。pytest-html生成漂亮的HTML测试报告方便给团队和管理层同步测试结果。pytest-assume一个用例里想跑多个断言但希望断言失败后继续执行而不是立刻终止这个插件就能派上用场。4.2 Appium环境搭建的一点心得做App自动化测试Appium目前还是主流选择。但Appium的环境搭建对新手极不友好这里分享一个我实测下来比较稳的路线第一步安装Node.js环境。Appium本身是Node.js写的直接去官网下载LTS版本一直点下一步就能装好。第二步安装Java JDK如果App是Android端。需要注意Android自动化测试不一定非得用Java写脚本但Appium Server依赖ADB工具而ADB本质上是从Android SDK中调用的。环境变量JAVA_HOME、ANDROID_HOME要配置好具体路径每台机器不同这里就不展开细说了。第三步用Appium Inspector做元素定位。刚接触Appium的时候很多人被element定位卡住页面上的元素怎么都拿不到。Appium Inspector就是解决这个问题的——它可以把手机屏幕实时展示在电脑上像浏览器开发者工具一样去查看每个控件的ID、Name、ClassName。第四步写第一段自动化脚本。我建议用代码先跑一个最最简单、稳定的场景打开App点一个确定存在的按钮打印一句日志。走通全链路后再慢慢加入等待策略、数据准备、用例抽象。4.3 接口自动化测试框架的搭建逻辑“Java接口自动化测试框架”在热搜词里出现频率很高说明Java岗位的接口自动化需求确实很旺盛。但很多同学一上来就追求技术栈的复杂度TestNGSpringBootAllureJenkins全套上结果脚本还没写几行就被框架本身的配置折磨得够呛。我的建议是从最小可行框架起步逐步演进。一个最朴素的Java接口自动化框架只需三样东西HTTP客户端选择OkHttp或者Apache HttpClient负责发送HTTP请求并接收响应。测试框架TestNG或JUnit 5负责组织测试用例、执行测试、断言结果。数据驱动用JSON或YAML文件维护测试数据在测试代码中读取这些文件。先跑通这个最小模型后续再按需引入Allure报告、环境配置管理、CI/CD集成。框架是服务业务效率的不是用来炫技的。如果你走Python路线就更简单了Requests库负责发请求pytest负责组织用例PyYAML读配置Jenkins build时拉取代码、执行测试、发送报告邮件一个典型的自动化流水线就成型了。4.4 提高测试覆盖率从ATPG思维到代码覆盖率现在相当规模的测试团队都在关注“覆盖率”这个指标。这个指标本身是对测试完整度的一种量化度量代码覆盖率是其中的核心参考系之一。很多团队测覆盖率的方式很粗放跑一遍用例然后从覆盖率报告里看行覆盖率、分支覆盖率数字合格就算通过。但代码覆盖率提高不了的深层原因往往是测试数据准备不足或者是业务逻辑本身的分支太多用例设计时漏掉了大量分支。这里我从芯片测试领域借鉴一个概念ATPG覆盖率。芯片测试里的ATPG是通过自动生成测试向量用最少的测试向量尽可能覆盖更多的故障类型。映射到软件测试其实是相通的——你在设计用例的时候脑子里要有一张“故障模型表”穷举出所有可能出错的方式数值越界、空指针、并发竞争、状态未初始化...然后有针对性地设计用例去触发它效率远高于无脑地堆用例。一个提高代码覆盖率的思路是跑一次现有用例拿到覆盖率报告找出未覆盖的代码块。逐个分析这些未覆盖的代码块是逻辑分支、异常处理还是边界条件。针对性补充用例只补那部分缺口。跑完再次检查覆盖率看是否出现新的未覆盖分支。用这种方式做覆盖率是实打实地提高而不是靠统计口径玩数字游戏。5. 面试答题策略与避坑指南笔试过关后面试环节其实是另一个考场。很多同学笔试考得不错面试却因为一些表达和思路问题挂了相当可惜。这里总结一些实测有效的答题策略和常见误区。5.1 “测试思维”的表达方式从机械罗列到层层递进面试官让你设计测试用例你开口就背“正常情况、异常情况、边界情况”——这是一个典型的流水账回答面试官听完大部分内容都记不住。更好的表达方式是层层递进的逻辑结构。比如你可以说“对于这个功能我习惯分三个层次去考虑测试方案。第一层是功能正确性也就是主流程能不能走通比如登录功能正确账号密码能登录第二层是防护性也就是当用户输入不符合预期时系统能不能优雅处理比如密码错误时的提示是否友好、有没有尝试次数限制第三层是策略性也就是在复杂场景下比如并发登录、弱网登录系统是否仍然稳定。”这种表达方式的优势在于它不是一个点一个点地往外冒而是先搭建一个“功能—防错—稳定性”的思维框架再把具体用例填进去。面试官从你的表达中能看到结构化思维这才是测试工程师的核心竞争力。5.2 面试高频场景如何回答“你印象最深的bug”“你印象最深的bug是什么”这个问题几乎是必考的。很多人的回答是“我之前发现了一个bug是iPhone上页面显示错乱后来开发改成适配就好了。”—— 这个回答太单薄了。一个高分的回答应该包含四个要素背景在什么项目、什么版本、什么功能下发现的问题。过程你是怎么发现的是执行用例时发现的还是用户反馈后回查发现的定位你做了哪些排查动作看了日志抓了包查了数据库最终怎么定位到根因的结果怎么修复的修复后有没有做回归你在过程中沉淀了什么经验如果你是实习生没有太多实际经历也可以讲一个你“排查”过程中学习到的案例但一定要诚实说明背景不要编造经历。面试官大多是经验丰富的从业者编造的案例在他们面前很难经得起追问。5.3 测试岗位的职业发展路线最后再聊一个延伸话题。我经常被测试实习生问“测试是不是没有前途是不是比开发低一等”我的回答很直接测试工程师的发展路径远比大多数人想象得宽。只是很多人做测试第一年就躺在了“手动点点点”的舒适区里没有主动往深水区走。一线测试从业者大概有三条主流发展方向技术深耕型测试开发提升代码能力从写自动化脚本到搭建测试平台、开发测试工具解决团队效率问题这是目前薪资最有竞争力的一条路。业务专家型领域测试专家对某个特定行业或复杂业务场景有极深的理解比如金融交易的资金安全测试、车载系统的安全性测试、电商大促的全链路压测。这类专家的价值不在于能写多少代码而在于“别人测不出来的问题你能测出来”。质量管理型测试管理/质量保障负责人从个人执行转向团队管理规划和设计质量保障体系推进测试流程规范化和效能度量。从2025年的岗位需求反馈来看有一技之长的测试工程师依然很抢手懂性能、懂安全、懂车载、懂大模型评测的薪资普遍比单纯做功能测试的高一大截。所以不要为“测试有没有前途”焦虑先把自己手里的基本功练扎实再找准一个方向深扎进去。6. 常见问题速查与备考建议这部分就当是一份贴心售后把前面零零散散提到的关键点汇总成一个速查表方便你复习时对照。热点问题核心要点易踩的坑如何准备测试实习笔试重基础、重思维、重场景只刷题库不思考每个选项背后的原理测试用例设计基本功等价类边界值场景法打底只写正常流程不写异常分支自动化从哪入手先pytest脚本化再搭建框架一上来追求平台化陷入配置泥潭App专项测试关注什么内存、弱网、中断、兼容只看UI忽略性能与稳定性接口测试怎么测业务状态码、数据完整性、幂等、越权只看HTTP状态码面试怎么描述bug背景过程定位结果只讲现象不讲排查思路测试职业路线怎么选测开、业务专家、质量管理三条路长期停留在手工执行层针对笔试备考我的建议是至少提前三到四周做系统准备第一周梳理理论基础把测试基础、网络协议、数据库、Linux这些“硬知识”过一遍第二周专项突破主攻用例设计能力和测试方案设计能力每天挑一个身边的功能比如电梯、订票、ATM机做一次全要素用例设计第三周开始刷真题和模拟题重点是把自己的答案写下来不要只在脑子里过——写下来才会发现漏洞。第四周查漏补缺把薄弱环节集中攻克。备考的过程中你会逐渐发现一个事实测试工程师面试重点不在于你记住了多少个知识点而在于你能否在具体的业务问题里有逻辑、有条理地提出自己的测试方案。这是可以练习的而且练得越多越有底气。最后再分享一个小技巧面试时如果遇到完全没接触过的技术不要慌更不要硬答。诚实告诉面试官你确实没实践过然后补充说“如果让我来做我会先看官方文档再搭一个最小环境验证思路然后小步迭代”。面试官看到的是你的学习路径和解决问题的思路这比“什么都懂”更让人放心。