1. 写在前面Shopee QA笔试到底在考什么2024年秋招提前批我投了Shopee的QAQuality Assurance质量保障方向拿到笔试通知后说实话有点意外因为很多人都说QA岗门槛不高实际上过了笔试才发现这个岗位筛人一点都不含糊。提前批笔试和正式批最大的区别在于它不是为了过滤“完全不会的人”而是在一群基础达标的人里挑出“思维足够细、逻辑足够严谨、抗压能力在线”的那一批。笔试单场时间通常安排在1到1.5小时题目不多但每一道都有足够的区分度。很多人对QA有个误解觉得就是“点点点”找个Bug、跑跑回归就完事了。但Shopee的QA笔试说白了是在考三件事第一你对测试理论和用例设计的掌握有没有系统化第二你对常用技术栈数据库、接口、基础算法的理解能不能落到实际第三你能不能快速读题、快速决策、把思路清晰表达出来。尤其是最后一点笔试里一旦出现开放型题目阅卷人看的就是你的思维路径而不是最终那个“正确答案”。这篇文章不是官方题解我没有办法拿到原题和标准答案。我最想分享的是这套笔试背后的考察逻辑是什么、每类题型该怎么准备、哪些地方最容易被扣分。我尽量把能回忆到的题型还原成示例再配合完整的解题思路相当于给你搭建一个“笔试复现环境”。准备秋招QA的同学或者实习想投质量保障方向的都可以拿来当作一份踩坑经验看。2. 笔试全貌题型结构、时间分配和底层逻辑2.1 提前批和正式批的差异你得先搞明白提前批笔试最典型的特征是“时间紧、题量小、筛选狠”。正式批可能分多轮、更偏向全面能力测试提前批更像是海选在一批简历看起来都还行的候选人里用最短的时间把思维方式不合适的人筛出去。所以提前批题目往往不是那种背一背八股就能过的而是需要你在现场思考的组合型问题。我当时收到的笔试邮件里写了在线测评平台、开始时间和截止时间整体没有给具体的题型说明。真正进入系统之后才发现题目大概分成这几个模块基础测试理论题、测试场景设计题、数据库SQL题、一两道逻辑编程题。全英文题目有些题目选项有中文翻译但很多核心题干还是英文英文阅读能力差的话会非常吃亏。2.2 各题型的大致占比与考察意图从我的复盘来看整场笔试中不同模块的权重并不是平均分配的。下面这张表是我根据自己的记忆和和同期同学的交流汇总出来的不能保证百分百精确但至少能反映趋势。模块大致占比考察核心最容易丢分点测试理论25%测试类型、测试用例、缺陷生命周期概念混淆细节选项拿不准场景设计题30%等价类划分、边界值、场景覆盖考虑不全面漏边界SQL/数据库25%多表查询、聚合函数、索引思路子查询和分组条件写错算法/编程题20%基础数据结构、逻辑实现、复杂度控制输入输出处理不当边界条件缺失有人可能会想QA又不用像后端开发那样刷那么多LeetCode算法题占比低一点没问题。但你说巧不巧算法题往往出现在最后前面的场景题已经消耗大量脑力算法题就成了压垮骆驼的最后一根稻草。所以提前批不只是考你会不会还考你在时间压力下还能不能保持清醒。2.3 为什么QA笔试要考编程题这里我想多说一句。很多同学不理解QA为什么要写代码包括我自己一开始也很纳闷。后来做软件测试的时间久了就懂了质量保障工作的自动化程度越来越高一个不懂代码的QA面对稍微复杂一点的接口测试、自动化脚本编写、日志排查会非常被动。笔试里放一道或两道编程题不是真要你写出一个多复杂的系统而是检验你有没有用代码逻辑去解决问题的意识。如果你对QA笔试的理解还停留在“会背测试方法就行”那大概率会在编程题上栽跟头。笔试里出现的编程题通常不是纯粹的算法竞赛题而是和场景结合的比如“用一个函数判断两个时间段是否有重叠并给出测试用例”。这种题考察的其实是两件事逻辑正确性以及你能否站在测试角度补全边界条件。2.4 备考资料怎么看、刷题范围怎么定我个人当时的准备思路是把官方文档和题库当作“最低纲领”把场景设计和数据库当作“冲刺重点”。测试理论部分尽量把等价类划分、边界值分析、因果图、错误推测这些方法过一遍配合网上能找到的常见场景题练手。SQL部分不用刷太难的但多表关联、GROUP BY HAVING、子查询这些一定要练熟。笔试前我还特意做了一件事把所有常见测试场景整理成模板比如登录、注册、购物车、支付、搜索、订单状态流转每个场景把正常流、异常流、边界条件、权限问题、数据一致性列一遍。这个模板帮助我极大压缩了考场上构思用例的时间。3. 测试理论基础看起来简单其实全是坑3.1 概念题不是白给分细节决定胜负理论题看起来都是选择题好像蒙也有机会但你要是真的一知半解去蒙大概率会选错。Shopee笔试题里出现频率很高的几个概念有白盒测试和黑盒测试的区别、回归测试和冒烟测试的区别、缺陷严重级别和优先级的区别、单元测试集成测试系统测试验收测试的执行顺序。这些概念单拎出来谁都能说上一两句但笔试里它会用很具体的场景包装一下。举个例子题目里说“一个缺陷可能导致用户数据丢失但只出现在某一个极其冷门的安卓版本上”让你判断这个缺陷的严重级别是Critical还是Major优先级是Urgent还是Normal。很多人会把严重级别和优先级混为一谈实际上严重级别描述的是影响程度优先级描述的是修复的先后顺序数据丢失影响程度极高但冷门版本用户量少修复优先级可以比一个影响大量用户但程度较轻的问题略低。要注意的是不同的公司对缺陷优先级定义有细微差别但整体逻辑相通。我当时的答题策略是先判断“最严重”的那个维度再看“最紧急”的那个维度最后把两者区分开选项。如果选项里出现一句“严重级别高的缺陷优先级一定高”那基本可以判断为错误选项。3.2 测试用例设计题几乎必考等价类和边界值要刻进DNA测试用例设计是QA笔试的绝对主战场。最常见的考法是给你一个功能点限定时间让你设计测试用例。应届生的通病是只写“正常流程”觉得功能能跑通就行但阅卷人想看到的是你对抗性测试的敏感度。举个例子笔试里有一道题让我印象很深给一个“用户注册”页面要求用户名长度6到20个字符只能包含字母和数字密码长度8到16位且必须包含大写字母、小写字母和数字请设计测试用例。当年我在考场上的第一反应是写正常用例合法用户名加合法密码注册成功。之后才补了各种异常情况。但第二次准备时我总结出了更系统的思路完整的测试用例应该按下面这样组织正常流程合法边界内用户名和密码组合验证注册成功边界值用户名为6个字符、20个字符、密码为8位、16位非法值用户名少于6个字符、多于20个字符、包含空格、包含下划线、全数字密码、全字母密码特殊输入用户名和密码都为空、用户名和密码相同、用户名包含表情符号业务约束用户名已存在、密码与确认密码不一致、注册接口重复提交前端与后端校验绕过前端限制直接请求接口是否同样拦截兼容性不同浏览器、不同操作系统、移动端和PC端表现是否一致安全性SQL注入字符尝试、XSS字符尝试、密码是否明文传输你可能会说正常谁能在笔试时想得这么全确实我一开始也做不到。后来我总结出一个在考场上快速迭代的方法先从“正常流”入手然后强迫自己沿着“边界值、异常值、业务约束、安全、兼容性”这条固定的思维链走一遍每次都用同一套框架。这样虽然不能保证覆盖百分百但至少不会漏掉最明显的几类。一个很实用的技巧是遇到功能描述题时先把所有名词圈出来所有动词圈出来。名词通常是可以划分的输入项和数据对象动词通常是可以触发的操作和状态变化。这样一边读题一边拆解能迅速建立起测试范围的地图。3.3 非功能测试场景题很容易忽视的送分/送命题除了功能测试笔试里时不时会出现关于性能测试、兼容性测试、安全测试、易用性测试的选择题。这些题考得不算深但概念不清会直接翻车。有一道题我记得比较清楚问的是“一个电商系统出现页面加载速度变慢作为QA你应该首先关注什么”四个选项分别是响应时间是否超出SLA、数据库连接是否泄露、服务器CPU是否满负荷、是否存在死锁。这道题好多人会直接选CPU或者数据库但我认为如果作为QA第一件事应该是确认问题能不能稳定复现、影响范围有多大然后才是定位原因。笔试里它考的其实是“QA的思维起点”而不是“DBA的排查起点”。所以我的建议是非功能测试部分不要死记硬背工具和指标要理解“QA在非功能测试中的角色是定义场景和验证结果而不是代替开发做性能调优”。想明白这一点很多题都能凭常识做出来。3.4 测试原则和缺陷报告检验你有没有实战经验笔试里偶尔会出现“下面哪项是最好的缺陷描述”这类题。四个选项都描述了同一个Bug但一个信息完整、步骤明确另一个只写了“页面报错”。这题几乎就是白送分但也会筛掉一部分没有真正写过Bug的同学。一个合格的缺陷描述至少要包含环境信息、前置条件、复现步骤、预期结果、实际结果、日志或截图。笔试时如果让你写缺陷描述就按照这个模板去套千万不要只写一两句感觉式的描述比如“搜索功能有问题”阅卷人根本看不出你的思路。按照“环境步骤预期实际”四要素来写就算题干信息不全也要把自己能构建的上下文补上。还有一个容易被忽略的考点是缺陷生命周期。要清楚New、Open、Fixed、Rejected、Closed、Reopen这些状态的流转关系。笔试有时候会给你一段流程描述让你判断哪个环节出问题了比如“开发修完Bug后直接关闭了Bug单这样对吗”。正确答案肯定是“不对应该先由测试人员验证通过后再关闭”。4. 场景设计题QA笔试的核心战场也是拉开差距的地方4.1 为什么会单独把场景题拎出来讲测试理论题和场景设计题在笔试里是两种完全不同的物种。理论题你可以靠背场景题完全没有范围它模拟的是你入职后“拿到一个需求就要能设计测试方案”的真实工作状态。Shopee提前批的场景题非常贴合电商业务这也和Shopee的行业属性直接相关——它的核心商业模式就是电商所以笔试题里出现购物车、订单支付、优惠券这类场景太正常了。我当时遇到的一个场景题大概是这样的设计一个“购物车删除商品”功能的测试用例限定10分钟。看似简单但越是简单的功能越考验你思维的缜密程度。我当时在草稿纸上把购物车删除功能拆成了几个维度正常删除删除单个商品、删除多个商品、删除最后一个商品商品状态商品已下架、商品库存为零、商品已失效、商品为赠品用户状态未登录直接操作、登录后操作、session过期后操作数据一致性删除后购物车数量是否正确、价格汇总是否更新、优惠券是否要重新计算并发操作两个设备同时操作同一购物车、删除时恰好下单界面交互删除确认弹窗、撤销删除、删除过程的loading状态、删除失败提示性能与稳定性快速连续删除多个商品是否卡顿、弱网环境下删除是否超时写完这个框架之后我还给自己定了一个原则场景设计题永远不要只回答“能跑通就行”要把“功能本身”“数据状态”“用户状态”“异常情况”“前后端一致性”这些层次都展开。这个原则在后来复盘时证明非常有效因为阅卷人想看到的不是标准答案而是你脑海中那张“测试地图”到底画得有多大。4.2 等价类划分和边界值分析拿高分的基础操作等价类划分听起来专业其实就是把输入条件分成“有效等价类”和“无效等价类”每一类里取一个代表值来测试。边界值分析就是专门盯着那些刚好在边界上的值因为经验告诉我们程序员最容易写错的就是边界条件。拿登录功能举例假设手机号必须是11位数字有效等价类11位纯数字无效等价类包含非数字字符、10位、12位、为空边界值第11位多余的临界、输入10位后加一位变成11位、输入11位再删一位变成10位注意笔试时不能只在脑子里过最好在草稿纸上画一张区间图把正常区间、小于下限、大于上限、等于下限、等于上限都标出来。这样遇到复杂的区间需求比如年龄限制、金额满减也不会乱。4.3 状态转换和业务流设计电商场景的高频考点电商功能的明显特点是有状态流转订单从待付款变成已付款从已付款变成已发货从已发货变成已签收中间还可能插入取消、退款、售后等分支。QA笔试只要遇到订单类场景几乎必考状态流转。这种题我有一个万能解法先把所有状态列出来然后连线画出合法状态转换路径再检查每个路径上有没有非法跳转。简单来说就是画一张状态机图。比如订单不能从“待付款”直接跳到“已完成”必须经过“已付款”“已发货”“已签收”如果测试用例里出现这种非法跳转被允许的情况那就是严重缺陷。我强烈建议准备阶段就自己画一遍电商核心流程的状态图从用户浏览商品、加入购物车、提交订单、支付、发货、签收、评价、售后。把这个流程里的每一个状态转变都写成用例笔试就会很从容。4.4 数据组合和兼容性超越“单一用例”的全局视野有些场景题给的条件不只是一个参数而是多个参数的组合比如“优惠券满100减20限新用户首单使用商品本身打8折优惠是否可以叠加”这种。你如果只用单参数测试是测不出组合场景里的Bug的。组合测试的思路是先用Pairwise两两组合的思路覆盖主要参数组合然后手动补上高风险组合。虽然笔试场景下不太可能让你设计上百条用例但至少你要体现出“我知道多参数组合会产生很多场景我会用正交法或配对测试来缩减用例数量”的意识。兼容性测试也是这类场景题里常用的补充点功能在iOS端正常、安卓端异常在Chrome正常、Safari异常在4G网络正常、Wi-Fi异常。这些不是每次笔试都会给分但写上绝对比不写强因为它体现的是你的行业常识。5. 数据库与SQLQA的基本功笔试里的“实打实”题目5.1 为什么QA要考SQL很多准备QA的同学对SQL不太重视觉得那是后端工程师的事。但你仔细想想QA如果要验证一个数据修复是否正确查看数据是否符合预期最常用的手段就是写SQL去查。笔试考SQL查的不是你能不能背出语法而是你有没有用数据去验证测试结果的意识。我记得笔试里有一道题是给了两张表一张是用户表一张是订单表要求统计每个用户的订单总金额并且只显示总金额大于1000的用户按金额降序排列。这就是非常典型的聚合查询题核心是GROUP BY、HAVING、ORDER BY三个关键字的配合。类似的题目我建议大家在准备阶段至少练熟这几种单表查询、多表连接查询、子查询、聚合函数求总和均值、分组过滤、排序、去重、分页。题目难度不会超过这个范围但写错一点就可能整题丢分所以平时一定要亲手在MySQL或SQLite上跑一遍不要只看题解。5.2 笔试常考的SQL句式拆解下面我写一下最典型的“统计用户订单总金额”这个题目顺手把书写规范也提一下。假设有两个表usersuser_id, user_nameordersorder_id, user_id, amount, order_time要统计每个用户订单总金额只显示总金额大于1000的用户并按总金额降序排列SQL可以这样写SELECT u.user_name, SUM(o.amount) AS total_amount FROM users u INNER JOIN orders o ON u.user_id o.user_id GROUP BY u.user_id, u.user_name HAVING SUM(o.amount) 1000 ORDER BY total_amount DESC;注意几个容易出错的地方GROUP BY后面如果是MySQL低版本里SELECT的非聚合字段必须都在GROUP BY中出现否则报错。所以上面把u.user_id和u.user_name都放进了GROUP BY。HAVING是用来过滤聚合结果的WHERE不能出现在它后面过滤聚合结果。如果你只用了u.user_name进行GROUP BY语法上可能没问题但如果有重名用户会出问题所以最好带上唯一主键user_id。除了这种常规聚合笔试还可能考“查找连续登录天数”“查找每个商品类目的销售额Top3”这类稍微进阶的题但万变不离其宗底层都是窗口函数和表连接。建议提早把ROW_NUMBER()、RANK()、DENSE_RANK()的区别搞清楚这几个是SQL高频考点。5.3 事务、索引和锁QA笔试里的“超纲”题有些同学会问QA笔试真的会考事务隔离级别和索引失效吗我告诉你会但占比不大而且通常是以判断题或选择题的形式出现。比如给你一个场景“两个事务同时修改同一行数据会发生什么”让你判断是什么问题。这就是考你对脏读、不可重复读、幻读的理解。索引失效也是个常考的小点给一条SQL问会不会走索引。典型的坑包括“在索引列上使用函数”“隐式类型转换导致索引失效”“LIKE以%开头的模糊查询”等。这些知识对于QA来说不是多余的因为在排查线上数据问题时如果完全不懂索引机制你连怎么把SQL写快都不知道。我建议准备阶段用半天时间把数据库事务四大特性ACID、四种隔离级别、脏读不可重复读幻读、索引的B树原理、普通索引和唯一索引的区别全部过一遍。不需要像后端工程师那样钻得很深但遇到题能选对就行。5.4 笔试中SQL题的时间管理SQL题一般是笔试里比较耗时的一种。我的经验是先把表结构和字段看清楚再在草稿纸上写出逻辑思路最后才动手写代码。不要在题目还没有完全理解的时候就急着往答题框里敲磕磕绊绊反而是浪费时间。还有一个细节笔试平台不一定支持本地数据库调试所以你写出来的SQL必须一遍过。这就要求平时练习的时候养成“写完自查”的习惯检查表名、字段名、关键字大小写平台通常不区分但你自己得统一风格、聚合函数参数、JOIN条件、WHERE与HAVING的位置。这些看似基础却最能反映真实水平。6. 逻辑编程题与英文题不只是开发岗的专利6.1 编程题在QA笔试中的真实样貌我遇到的编程题不是那种纯粹的“两数之和”而是更接近软件测试思维的题。比如给你一个函数说明它的功能让你找出里面的Bug或者给你一段代码让你列出可能的测试用例。这种题目其实很妙它既考编程能力又考测试敏感度。举个例子一个非常经典的题目是判断一个字符串是否是回文串同时忽略空格和大小写。代码可能长这样def is_palindrome(s: str) - bool: s s.replace( , ).lower() left, right 0, len(s) - 1 while left right: if s[left] ! s[right]: return False left 1 right - 1 return True如果笔试让你写测试用例你要能覆盖这些场景空字符串应返回True还是False取决于题目定义单字符字符串永远是回文纯符号字符串如“!#”应该怎么处理含大小写字母的字符串“Aba”应为True只包含字母数字和忽略符号如果题目没有明确处理符号这就是一个边界超长字符串会不会有性能问题输入是None或非字符串类型需要处理吗这些点只要写一半就能让阅卷人感受到你具备测试思维。在笔试中编程题并不是要你展示多炫技的算法而是要展示你的代码风格、边界处理能力和测试意识。6.2 英文题干阅读别让语言成为技术之外的障碍Shopee笔试的一个显著特点是英文题干很多中文同学一开始不太适应。我建议提前在系统里确认语言选项如果可以选择中文就果断选中文不要因为担心“英文版加分”就硬用英文答题。笔试的目的是展示技术能力不是展示英语能力能保证读题准确最重要。但如果系统就是英文界面那就要习惯阅读英文技术术语。高频词先弄熟regression testing回归测试、boundary value边界值、equivalence partitioning等价类划分、acceptance testing验收测试、test case测试用例、priority和severity优先级和严重级别、pull request代码评审合并请求、sprint迭代周期、staging environment预发布环境。读题的时候把关键词用鼠标或草稿纸记下来尤其是“not”“except”“always”“must”这类限定词往往决定一个选项的对错。我见过太多同学不是不会做而是把“以下哪项不是测试用例的设计方法”看成了“哪项是”一失手就是整题错。6.3 编程语言选择和输入输出细节笔试平台支持的编程语言一般很全Python、Java、C、Go、JavaScript都有。我的建议是选自己最熟的语言不要因为“Java写出来更正式”就临时切换。用Python的优势是代码量小、写起来快、字符串处理方便很适合笔试场景。输入输出这一块同样容易翻车。有些平台要求你处理多组输入有些要求只处理一次还有的是类Whiteboard模式只需要补全函数。我建议提前到系统里看几次示例输入输出格式熟悉一下平台的要求。还有一个小技巧如果平台允许本地IDE编译就优先在本地跑一遍样例如果只能用在线编辑器至少也要在脑子里过一遍“正常输入”“空输入”“超长输入”三种情况。代码提交前把变量名拼写、缩进、退出条件都检查一遍能避免很多无谓的扣分。6.4 逻辑题和智力题QA岗位的隐藏考点除了编程题有些笔试会夹杂一两道逻辑推理题比如“有8个球其中一个偏重用天平最少称几次能找出来”答案是两次。这类题考的不是知识储备而是短时间内能否把问题建模。QA的工作里经常要判断一个异常现象最可能的原因逻辑推理能力确实是核心素质之一。对付这种题没有捷径只能靠平时多练。我准备时刷了一些经典的逻辑题比如天平找次品、倒水问题、过桥问题、真假话问题。不一定会考原题但刷过之后再遇到类似的题至少第一反应不是慌而是用“穷举、分组、二分”的通用方法去推。7. 实战全流程复盘从开考到交卷的完整操作手册7.1 开考前20分钟你需要做的事提前批笔试是在线上进行的开考前的那一段时间非常关键。我当时提前25分钟就坐到电脑前先做了三件事检查网络和备用网络手机热点开好确保断网可以立即切换关闭所有不必要的浏览器标签页和后台程序尤其是微信等弹窗软件很多在线笔试系统会检测切屏一旦被记为作弊非常麻烦准备好草稿纸、两支笔、身份证件以及一瓶水进入考试页面之后先别急着点“开始”花两三分钟把答题界面熟悉一下看看有没有语言切换、题目后退、标记未答等功能。确认好之后深呼吸再开始。7.2 答题顺序策略先拿分再攻坚笔试平台通常允许自由跳题前一道题没做完也可以先做后面的。我的答题顺序是先做测试理论选择题再做SQL题再做场景设计题最后做编程题。这样安排的原因是理论选择题最轻快能迅速进入答题状态并积累信心SQL题分值实打实趁脑子清醒先把语法写对场景设计题需要较多发散思维放到中间做不容易手忙脚乱编程题放最后即使卡住了也不影响前面的大头分数但要注意选择题如果做不出来不要恋战。可以先标记一下回头有时间再琢磨。系统一般会显示倒计时要养成随时瞟一眼时间的习惯预设一个“最后15分钟无论如何都进入检查模式”的底线。7.3 草稿纸的正确用法让你看得见自己的思路很多人笔试时草稿纸用得乱七八糟想到哪写到哪。我个人的习惯是把草稿纸分区左上角记题目关键数据和条件右上角画状态图或等价类区间图左下方写SQL或代码的伪代码右下方留白用来检查时补漏这样最大的好处是当你在SQL或编程题上卡住时能快速回头看到自己最初的思路不用在脑子里反复回溯。而且答题结束后如果想检查之前场景题有没有漏项草稿纸上的状态图能帮你一眼看出来。7.4 提交前的检查清单我给自己定了一个非常机械的检查流程每次笔试最后几分钟都按这个走所有题目是否都已作答未作答的是否确实不会是否有题目把“Not”看成“是”导致选反尤其是技术类选择题SQL字段是否有拼写错误GROUP BY是否和SELECT字段对应编程题输入输出是否与示例一致是否有死循环和越界场景题是否完整覆盖正常、异常、边界、安全、兼容性五个层次最终提交前是否保存并确认不要因为超时自动交卷而手忙脚乱这套清单救了我好几次。上一次模拟笔试我就是在检查时发现SQL里表名写错了当时距离交卷只剩3分钟改完刚好赶上。复查的时间再紧张也值得留。8. 踩坑日记那些明明会却扣分的地方8.1 英文审题的坑限定词和否定词我印象最深的一次丢分就是理论选择题里有一道题问“以下哪个选项不属于黑盒测试方法”。我当时看到“黑盒测试”很熟悉立刻开始回忆等价类划分、边界值分析、因果图然后选了“语句覆盖”。问题是我没注意到题干里强调的是“不属于”而语句覆盖恰恰是白盒测试的内容所以选它其实是正确的。从这以后我给自己立了一个规定读题时先把否定词圈出来遇到“except”“not”“不属于”“不能”这类词就停下来重新确认选项。这不是技术问题是审题习惯问题但审题习惯恰恰是QA最核心的素养之一。8.2 SQL细节的坑HAVING和WHERE的混用SQL题里有一个非常经典的踩坑点是把聚合条件写在WHERE后面。比如要找总金额大于1000的用户就写了SELECT user_id, SUM(amount) FROM orders WHERE SUM(amount) 1000 GROUP BY user_id;这段代码在绝大多数数据库里会直接报错因为WHERE不能包含聚合函数。正确写法是把过滤条件放到HAVING里。这个错误在笔试里一出现整题基本没分。所以我提醒自己凡是看到“总和、平均值、数量”这类聚合词就要条件反射地考虑HAVING。8.3 场景设计题的坑只写正常场景忽略异常和边界应届生写测试用例最常见的问题就是“正常流全覆盖异常流一片空白”。比如让你设计“取消订单”的测试用例你能很快写出取消待付款订单成功、取消已付款订单需要客服介入但你有没有想过这些问题订单已经发货后用户取消会怎样取消请求发出后网络闪断会怎样重复点击取消按钮会不会生成两条取消记录取消后优惠券会不会返还库存会不会回滚这些点正是阅卷人拉开分数的地方。所以我准备了很长时间的“异常场景清单”网络异常、重复提交、并发操作、数据不存在、状态不匹配、权限不足、第三方依赖超时、系统重启恢复。每次写用例前对着清单扫一遍就能补出很多漏项。8.4 在线笔试系统使用层面的坑在线笔试系统最怕的其实不是题目难而是环境出问题。我在正式笔试前专门提前半小时做了一次“环境自检”摄像头能不能正常工作、浏览器版本是否兼容、系统有没有自动复制粘贴限制、代码编辑器是否支持高亮。还有一个细节是“切屏监控”和“键盘记录”之类的防作弊机制不要抱着侥幸心理去切屏查资料一旦触发警告极有可能被判违规。笔试考的不只是知识储备也考你在规则约束下的临场发挥这一条尤其在提前批里很重要。9. 复盘与进化笔试之后我学到了什么9.1 笔试本质上是一场“思维体检”很多人以为笔试是知识的比拼但我越来越觉得它更像是一场“思维体检”。它不是为了让你“背出所有测试用例”而是在短时间内通过有限的问题看你遇到问题时会怎么拆解、怎么选路径、怎么补全边界。这个能力恰恰是QA日常工作中最需要的。举个例子一个资深QA和初级QA在接到“测一下搜索功能”这个需求时的反应完全不一样。初级会直接打开App输几个关键词看看能不能搜出结果资深会先问搜索的范围是什么支持排序吗结果分页怎么处理报错提示在哪里空结果页面怎么展示后台日志怎么查思维差距才是真正的水平差距。9.2 从准备笔试到准备工作两者的共性大于差异准备Shopee QA笔试的过程让我提前把“测试工程师的思考方式”完整地训练了一遍。以前我看一个功能只会想“好不好用”现在我会不自觉地列出边界条件、异常流程和数据一致性规则。这种转变不是靠刷几道题就有的而是靠刻意练习“像QA一样思考”。所以我的建议是不要为了秋招才临时抱佛脚把每次笔试都当成一次系统思维训练。哪怕最后没进这家公司你的思维方式也升级了。这笔账怎么算都不亏。9.3 给下一届QA候选人的三个具体建议第一个建议是把“等价类划分、边界值分析、场景法、错误推测”练到形成肌肉记忆。笔试时想都不用想就能写出来才有余力去思考更难的问题。第二个建议是坚持每周手写至少五条SQL尤其是GROUP BY和窗口函数。笔试环境下没有编译器手写SQL能显著降低你语法错误的概率。第三个建议是给自己建一个“测试用例素材库”把登录、注册、购物车、订单、搜索、评论、退款这些高频场景的用例框架提前写好考场上直接套用修改。这套素材库不但能帮你通过笔试到了实习和正式工作里依然是极好的效率工具。最后再分享一个小技巧笔试过程中如果遇到完全没思路的场景题不要直接放弃先把它拆成“输入、操作、状态、输出”四个部分能写多少写多少。只要你展示出清晰的拆解过程哪怕结论不完美阅卷人也愿意给分。QA这个岗位要的不是“全对”而是在面对不确定时依然能结构化思考的人。