这套蘑菇街2019届校招的测试类笔试题放在今天看依然很有参考价值。先说结论它没有去考“背概念”而是把一个电商业务里的测试场景切成很多小题考察的是你有没有测试思维、能不能从业务的坑里跳出来设计用例以及对技术栈的熟练程度。很多学弟学妹拿这套题来问我说感觉题量大、范围广不知道从哪下手。这篇内容我会按我的理解把这类测试笔试的考点、答题套路和踩过的坑完整拆一遍适合正在准备校招测试岗、或者刚转行做测试的同学参考。1. 蘑菇街校招测试笔试的核心考点从业务场景反推测试思维1.1 不是考背概念而是考场景拆解我见过太多人备考测试拿着“软件测试的定义”“V模型是什么”翻来覆去地背结果一到笔试题里“设计一个优惠券功能的测试用例”就懵了。蘑菇街这套笔试题给我的感觉是概念题很少场景题占大头。像支付、购物车、商品列表这些电商核心模块全都被拆成了具体业务场景让你去补用例、找缺陷。这背后透露出一个重要信息测试工程师的价值不是“会定义缺陷”而是能在复杂业务里快速识别风险点。比如“用户领取优惠券后下单”这个场景如果你只写“验证优惠券能抵扣金额”那基本等于没写。真正的测试点应该覆盖优惠券领取条件是满100减20还是无门槛、是否只能领取一张、优惠券是否过期、是否支持与其他优惠叠加、下单后优惠券状态是否变成已使用、发生退款时优惠券是否退回、并发领取会不会超发等等。这就是场景拆解能力。面试官想要的不是标准答案而是你能不能把一个功能点拆成一个完整的测试矩阵。这个能力是平时一点一点积累出来的不是考前突击能补上的。1.2 测试技术栈的实用考察Linux、SQL、接口、移动端除了用例设计这套笔试题里还有一块非常务实的部分就是技术栈考察。电商公司的测试日常无非是这几件事看日志定位问题、用SQL查数据、调用接口验证状态、在移动端复现Bug。所以笔试题里会出现类似这样的题线上用户反馈下单失败给你几百兆的日志文件请用Linux命令定位异常。这道题考察的是你熟不熟悉grep、tail、awk这些命令以及能不能根据时间戳和异常关键字缩小范围。写一条SQL语句查出一张订单表中近7天支付成功的订单总量和总金额。这道题看着简单但会埋坑让你用“近7天”而不是“最近一条”考察你是否会用DATE_SUB或者时间区间过滤。有一个接口返回码是500请分析可能原因以及如何用Postman/curl验证。这里除了答题还会考察你对HTTP状态码是否敏感比如400和500的区别、服务端异常和客户端参数错误的区别。再加上移动端测试最近几年越来越重要所以Appium、兼容性测试、弱网测试也经常会被拎出来问。像“如何用Appium编写一条冒烟测试用例”“在弱网环境下如何验证页面是否卡死”这些题目考察的是你不仅会手动测还知道怎么用工具去解决问题。1.3 为什么电商公司喜欢这么考先理解一个问题蘑菇街这类电商平台跟做企业级软件的公司测试侧重有什么不同企业软件的测试很多时候在跟流程打交道但电商测试是和钱、货、用户直接紧密绑定的任何一个金额计算错误、库存超卖、优惠券被薅羊毛背后都是真金白银的损失。所以电商公司的测试笔试题往往会故意把业务规则埋得很深。比如“订单金额为0也能支付成功”这种低级Bug怎么发现必须靠边界值分析支付金额为0、为负数、为超大金额、为小数、为带三位小数的金额这些等价类和边界都要能想到。另外电商业务链路很长用户浏览商品、加购物车、下单、支付、库存扣减、订单状态流转、退款、售后。任何一个环节出问题都可能引发用户投诉。所以在笔试里会考察你是否具备“端到端思维”——不是只盯着某一个页面而是会想到数据在各个环节之间怎么流转、会不会丢、会不会不一致。这也就解释了为什么蘑菇街的笔试不是单一方向的题而是把业务理解、用例设计、技术能力、问题排查混在一起考。公司需要的是一个能真正扛起业务测试的人而不是只会按现有用例点点点的执行者。2. 必考题型拆解用例设计、场景分析与自动化脚本2.1 用例设计题从“登录”到“优惠券叠加”的完整思路很多准备测试笔试的同学第一个接触的用例设计题就是“如何测试一个登录功能”。虽然这道题已经被写烂了但它依然是校招笔试的保留节目。为什么因为登录功能麻雀虽小、五脏俱全它可以扩展到前端校验、后端校验、网络异常、安全攻击等多个层面。先说最基础的框架以“用户名密码登录”为例至少要考虑正常流程正确的用户名、正确的密码能登录成功并跳转到首页。等价类划分用户名分为注册过的、未注册的、为空的密码分为正确的、错误的、为空的用户名和密码组合成不同类型。边界值分析比如用户名/密码长度为1个字符、达到最大允许长度、超过最大长度密码是否包含空格、大小写、特殊符号。异常中断登录过程中断网、服务器超时、多次点击登录按钮、快速切换页面。安全性SQL注入用户名输入 or 11、密码明文传输、连续登录失败是否有验证码和锁定策略。兼容性不同浏览器、不同操作系统、移动端和PC端。如果你能在笔试里把这些维度都写出来基本能证明你有一定的测试思维。再往深处一步就是电商特有的场景。比如“购物车结算时使用优惠券”它比登录复杂得多。我会这么拆功能逻辑优惠券是否可用、使用门槛是否满足、金额计算是否正确、使用后是否失效。状态流转下单前、下单后、支付后、退款后优惠券状态分别是未使用、已使用、已锁定、已退回。并发场景多终端同时使用同一张优惠券会不会出现被重复使用。时间边界优惠券有效期的起始时刻和结束时刻比如票券在24:00过期正好在23:59:59使用。数据一致性支付成功后优惠券核销记录是否与订单关联一笔订单使用多张优惠券时的明细是否清晰。这些点看起来多但底层方法是一致的等价类划分、边界值分析、场景法、状态转换、并发异常。你需要做的不是背具体用例而是记住方法然后像剥洋葱一样把业务剥开。2.2 场景题如何应对“电商大促”测试大促是电商测试最高压的场景也几乎是校招笔试里必问的题。给你一个很常见的场景“双11当天商品详情页访问量突增如何设计性能测试方案以及如何排查线上性能瓶颈”很多同学第一反应是“用压测工具打并发”但这只是浅层回答。一个完整的大促测试思路应该是分析系统架构画出核心链路客户端请求经过网关、负载均衡、应用服务、缓存、数据库、外部依赖。找出最可能成为瓶颈的点比如数据库连接数、Redis缓存命中率、接口线程池大小。设计压测模型预估核心接口的并发用户数、TPS、响应时间指标区分正常情况、峰值情况、异常情况一般会用阶梯加压的方式观察系统从稳定到性能拐点的过程。数据准备压测数据要贴近真实比如商品库存、用户量、优惠券库存不能是空的否则结果不准确。监控指标除了响应时间和TPS还要看CPU、内存、磁盘IO、GC频率、数据库连接数、慢查询数。安全与降级如果系统扛不住有没有熔断、限流、降级的预案比如服务降级后用户看到的是缓存数据还是报错页面。除了性能大促场景题还会和安全测试、兼容性测试混在一起。比如“大促期间用户使用不同品牌手机同时访问如何做兼容性测试”这类题考察的是你把控质量策略的能力不是真的一个个真机去测而是要懂怎么选机型、怎么用云真机平台、怎么覆盖系统版本和屏幕分辨率。2.3 自动化脚本题手写一个冒烟测试脚本的要点蘑菇街这套笔试里如果出现自动化脚本题通常不是让你写一个大项目而是考察你是否具备基本的脚本能力和工程意识。比如“请用Python编写一条冒烟测试用例验证首页可以正常返回200状态码”。这种题我建议直接写一个pytest风格的脚本因为这是目前最主流的测试框架之一。在回答时只需要输出完整的代码并补充说明为什么这么写。import pytest import requests BASE_URL https://example.com def test_home_page_returns_200(): resp requests.get(f{BASE_URL}/) assert resp.status_code 200 def test_home_page_has_title(): resp requests.get(f{BASE_URL}/) assert title in resp.text看到没有这里的关键不是说“我会用requests”而是说“我知道测试脚本必须包含断言”。很多同学在笔试里写脚本只写了请求一行后面没了这是大忌。测试脚本没有断言等于没有执行结果根本不是一条合格的测试用例。更进一步的加分项是会在脚本里做异常处理、日志输出、测试数据清理。比如接口测试用例执行后插入的测试数据要不要清理如果不清理下一次跑脚本会因为重复数据而失败。这类细节是真实项目中一定会遇到的写在笔试卷子上会非常加分。3. 笔试过程复盘从读题到交卷的实操策略3.1 第一步不是写答案而是补全需求我见过很多人在笔试时拿到“设计一个搜索功能的测试用例”上来就写输入关键词、点击搜索、展示结果……三分钟写完了然后自认为没问题。这是最典型的丢分方式。真实的测试场景里需求从来不是完整的。搜索功能就包含很多隐含问题搜索支持精确匹配还是模糊匹配空关键词能不能搜搜索历史有没有记录搜索结果是分页的分页参数如何校验搜索排序默认是按相关性还是按销量如果有搜索广告广告和自然结果如何混排所以拿到题目后我一般会先做一件事在答案开头列出“前置假设”。比如“假设这是一个电商平台的商品搜索功能用户为普通注册用户支持关键词搜索和筛选默认按综合排序显示20条每页”。这样做有两个好处第一面试官看到你不是背题而是在解题前做一些需求澄清第二后续用例可以自洽不会让人挑出逻辑漏洞。笔试不一定要跟面试官面对面但你依然可以在卷面上展示自己的分析过程。遇到模糊需求不要慌更不要草率写一堆无效用例。先把范围圈定再针对范围内做详细展开。3.2 用例设计三步法等价类、边界值、场景法我知道很多人一听到“等价类、边界值”就觉得是学校里的理论题但实际上所有用例设计题都可以用这三个步骤来结构化回答。第一步用等价类划分把输入数据切成“有效类”和“无效类”。比如一个价格输入框有效类是大于0且不大于10000的数字无效类是0、负数、超范围、非数字、空。第二步对每个等价类的边界做补充测试。边界值是最容易出Bug的地方接口的参数校验、金额计算、库存扣减全是边界易错点。第三步用场景法把正常路径和异常路径串起来。正常路径是“加购-下单-支付-发货-收货”异常路径是“支付超时-订单取消-库存回滚-优惠券退回”。这套方法放到任何用例设计题里都管用。哪怕你遇到的是一个陌生的业务功能只要抓住“输入条件、前置状态、操作路径、预期结果、异常分支”这五个点就能写出像样的用例。举一个例子题目是“测试电商平台结算页的收货地址功能”。使用三步法等价类已填写完整地址、地址缺省、地址有敏感词、地址格式错误、地址超过限制长度。边界值地址最多可输入100个字符需要测99、100、101手机号是11位需要测10、11、12位。场景法新用户没有地址时点击结算会弹窗引导新增地址有多个地址时如何设置默认地址选好地址后重新登录地址是否还在修改地址后返回结算页价格和配送费是否重新计算。这样写出来的答案既有层次又有业务深度。3.3 缺陷报告的关键字段不要只写“页面报错”笔试里有时候会让你写一条缺陷记录。很多同学直接写“首页打不开报500错误”这种描述根本不合格。企业级缺陷报告至少要包含以下几个字段标题简洁描述问题比如“iOS端 14.0在弱网环境下提交订单提示网络异常且无法重试”。环境信息机型、OS版本、App版本、网络环境。步骤尽量写清楚前置条件和可复现步骤不是写“随便点击就会崩溃”而是要写“先进入商品详情页-点击立即购买-选择优惠券-点击提交订单”。预期结果和实际结果这两项是核心必须写清楚。日志与截图日志的异常堆栈、接口返回信息、截图或录屏都要能帮助开发快速定位。严重程度和优先级比如“支付成功但订单状态未更新”是严重级别“按钮颜色不对”是次要级别。如果在笔试里你给出的缺陷报告包含这些字段就已经比大多数应届生专业了。缺陷管理不是形式主义它是开发和测试之间沟通的载体写得越清晰协作效率越高。3.4 时间分配先做分值大的再补边界测试笔试题通常题量不小我见过有人在一道用例设计题里写了100多条用例结果后面SQL题和自动化题完全没时间写。这是非常可惜的。我自己的经验是拿到试卷先通读一遍把题型和分值标出来。分值大的题优先做特别是用例设计题这类题只要框架正确、覆盖到重要场景就能拿大部分分数不需要写满到100条。反而是那种“一条用例不漏”的强迫症会把自己活活耗死。另外边界值题和异常场景题往往是踩分点但不要放在最前面写。先把主流程走通再把边界和异常补充进去这样即使时间不够也不会导致整道题只有一半。笔试考察的不仅仅是准确率还有你在有限时间内的决策能力——这一点和真实的测试排期很像。4. 常见问题与避坑指南那些笔试里丢分的细节4.1 只测正常流不测异常流和中断场景我在审校招笔试卷子时最常看到的问题就是用例全是“输入正确、操作顺利、结果正确”。不是说这些不对而是说这类用例占了太多比例根本没有体现测试的风险意识。异常流和中断场景才是测试工程师的核心价值。比如下单支付过程中杀进程、断网、切换应用、来电打断这些场景在数据一致性和用户体验上很容易出问题。又比如重复点击按钮会不会产生重复订单提交订单后关闭App再次打开时订单状态是否同步。如果你能把这些场景写进用例面试官会认为你有真实项目经验而不是只在教材里读过测试理论。4.2 忽略移动端与兼容性维度很多笔试答案在写用例时脑子里默认是在“PC端网页”上操作完全忽略了移动端。但蘑菇街本身就是电商App用户大部分来自手机端。移动端的测试维度至少包括不同机型iPhone、Android主流机型、不同系统版本如iOS 15/16/17、Android 10/11/12、不同屏幕分辨率、横竖屏切换、多任务切换、来电和消息推送干扰。更关键的是网络维度。真实用户环境不是千篇一律的Wi-Fi而是地铁、电梯、地下室等弱网场景。弱网下页面是否会长时间白屏、请求是否超时、有无重试机制、超时后是否给出友好提示这些都是电商App测试必填的用例。笔试里能主动写出“弱网测试”这个维度的同学已经很少了。4.3 自动化脚本只写用例不写断言和清理还有一个非常容易丢分的点就是自动化脚本写得“有头无尾”。有人能写出打开页面的代码但就是看不到assert断言有人把测试数据写死在脚本里跑完不清理第二次就失败。比较规范的脚本结构应该是测试准备准备测试数据或前置状态、测试执行发起操作、断言验证检查实际结果与预期结果是否一致、测试清理清理测试数据、恢复环境。如果你在笔试里能把这四个步骤都写到说明你对自动化测试的理解已经达到了工程实践的级别。另外我想提一点脚本里的断言不应只检查“状态码200”还要检查关键字段是否符合预期。比如创建一个订单接口不能只看返回成功还要验证订单号是否生成、订单金额是否准确、数据库里是否真的有这条记录。这种“接口数据库”双重验证是实际工作中最常见的做法。4.4 安全测试只会说“SQL注入”不会说业务风险安全测试本身是个大方向校招笔试一般不会让你写渗透测试脚本但会考一些基础风险概念。特别是电商业务里最常见的是越权问题。普通用户A能不能通过修改请求中的订单号查看用户B的订单详情这就是水平越权。普通用户能不能把自己改成管理员然后访问后台接口这就是垂直越权。除了越权还有重放攻击支付回调接口被恶意重复调用导致金额被重复入账促销接口被脚本反复请求把库存刷光。这类安全问题跟业务紧密挂钩写进用例里会让答案更有含金量。我曾经面试过一位应届生问他“如何测试一个优惠券领取接口”他回答“验证参数正确、返回成功”。后来我引导他如果这个接口没做风控用户可以刷新100次领取100张优惠券怎么办他才意识到要去校验领取次数和用户权限。测试思维不是天生的而是要不断给自己出难题。这套蘑菇街2019届校招测试类笔试题真正值得我们练的不是题目本身而是题目背后那种“测试要替用户多想一步”的习惯。我在之后带实习生的时候也会用同样的思路来出题给一个电商小功能看对方能挖出多少测试点。那些能答出异常流、边界值、安全风险的候选人哪怕技术经验不多我也会愿意给一个机会。因为测试这个岗位最怕的就是只会照着写好的用例执行而不是自己去发现问题的边界。