2024年秋招刚开始那阵子我身边好几个投测试岗的同学都在讨论Shopee的提前批笔试。相比很多公司笔试安排在简历筛选之后很久、流程慢得让人焦虑Shopee这波节奏明显快很多——简历投出去没多久就收到了在线笔试通知用的是牛客或者HackerRank这类在线测评系统全程摄像头监控限时一个半小时左右。作为QA方向的候选人这场笔试的考察点和平时在学校里刷的题很不一样。它不单纯看你会不会写代码也不单纯考测试理论而是把两者揉在一起试图判断你有没有“测试思维”。我整理了一下自己做题和周围同学复盘的信息把题型分布、高频考点、时间分配、备战路线全部梳理成一篇完整的复盘。如果你打算投跨境电商或者大厂测试岗这篇内容应该能帮你少走不少弯路。1. QA笔试题到底在考什么——先想明白再动手很多同学拿到笔试通知第一反应就是赶紧刷LeetCode生怕编程题卡住。但实际上QA岗的笔试逻辑和开发岗有本质区别。开发岗侧重“我能不能把功能写出来”QA岗侧重“我能不能发现哪里会出问题并验证它不出问题”。带着这个认知去看题你会发现自己准备的侧重点完全不同。1.1 从岗位JD反推考察维度我当时特地把Shopee QA校招JD里的关键词拉出来看了几遍里面反复出现的是“质量意识”“测试设计”“自动化”“跨团队沟通”。这些词翻译成笔试考察点大概就是下面这几个维度计算机基础网络协议、操作系统、数据库、Linux常用命令。这些是测试工程师理解系统行为的基础尤其电商场景下接口测试、性能问题排查都依赖这些知识。编程能力不要求你写出多复杂的算法但至少能用Python或Java写自动化脚本、处理测试数据。出题难度一般落在LeetCode Easy到Medium之间。SQL能力QA验证数据正确性、造测试数据、分析线上问题都要写SQL窗口函数这些进阶语法也是常客。测试设计能力给你一个具体功能让你列测试场景。这一块是QA岗的“专业分”也是很多半路转测试的同学最没底的模块。1.2 为什么电商公司特别爱考这些Shopee的核心业务是跨境电商订单、支付、物流、优惠券、商家管理这些模块每个都是QA的主战场。跨境电商意味着分布式系统、多时区、多币种、高并发这些场景天然会带来数据一致性和时序问题。所以笔试里频繁出现SQL题、并发相关的选择题、异常处理的编程题都是有原因的。比如订单状态流转支付成功但扣库存失败怎么办用户下单时用了优惠券退款的时候优惠券怎么处理这些业务逻辑背后全是边界条件和异常分支QA恰恰就是守在这些边界上的人。笔试设计这些题目表面是考技术实际是看你有没有能力理解和验证复杂的业务规则。1.3 提前批和正式批的差异我了解到的信息是Shopee提前批笔试的整体难度会比正式批稍微友好一点但考查范围更广。提前批更像是“广泛撒网重点捕捞”通过笔试先筛掉基础薄弱的人后面面试再深入考察测试思维和项目经验。另外提前批有个很现实的好处就是流程短。笔试通过后很快安排面试而且就算提前批挂了有些公司后续正式批还能再投。所以提前批对于想进Shopee的同学来说相当于多了一次模拟演习的机会哪怕没通过也能通过笔试题目反推出公司重视的能力模型为后续面试做准备。2. 题型拆解与真题复盘——按模块过一遍目前从各个渠道汇总的信息来看Shopee QA提前批笔试时间一般是60到90分钟题目结构大致分为四个模块计算机基础选择题单选加多选、SQL题、编程题、测试用例设计题。每个模块的侧重点和准备方式都不一样下面分开说。2.1 计算机基础选择题高频考点与避坑选择题覆盖的知识点比较杂但高频区很集中。我复盘下来出现频率最高的是这几块TCP和UDP的区别、三次握手和四次挥手的具体过程以及为什么握手是三次而不是两次。进程和线程的区别、死锁产生的四个必要条件、常用的进程调度算法。Python基础语法陷阱比如可变对象作为默认参数、深拷贝浅拷贝、列表推导式的作用域。Linux常用命令特别是grep、awk、sed、find、top、netstat这些测试日常会用的命令。数据库的ACID特性、事务隔离级别、脏读不可重复读幻读的区别。常见数据结构的时间复杂度比如哈希表查找、二叉搜索树查找、快排最坏情况。选择题里最容易翻车的其实是多选。单选还可以靠排除法蒙多选只要漏选或错选一个就全扣分而且有些选项表述得非常模棱两可。我在准备后期专门过了一遍计算机网络的分层模型尤其是HTTP和HTTPS的握手过程这块几乎是必考。注意如果笔试里出现了“下列关于XX说法正确的是”这种多选一定要把每个选项都当成判断题来做。不确定的不要选少选还能得部分分错选直接零分。2.2 SQL题数据分析能力是QA的隐藏加分项SQL题在QA笔试里的分量一年比一年重。原因很简单QA日常工作中到处都要和数据打交道验证前端展示的数据和数据库一致、构造测试数据、排查线上订单异常、统计自动化测试覆盖率。SQL写不溜很多工作根本没法推进。Shopee的SQL题基本都放在电商场景里常见的出题方式有这些找出每个用户最近一笔订单的信息。统计每个商品类别的销售额排行取前几名。找出连续三天都有登录行为的用户。计算优惠券的使用率按渠道分组对比。把订单表和退款表关联起来分析退款率最高的商品。这里需要特别重视窗口函数也就是ROW_NUMBER、RANK、DENSE_RANK、SUM OVER这组语法。很多“分组取Top N”的题用GROUP BY写起来非常费劲用窗口函数三行就搞定了。我拿一道典型的题目举例表orders包含字段order_id, user_id, product_id, order_amount, order_time。请找出每个用户下单金额最高的订单信息。SELECT user_id, order_id, product_id, order_amount, order_time FROM ( SELECT user_id, order_id, product_id, order_amount, order_time, ROW_NUMBER() OVER ( PARTITION BY user_id ORDER BY order_amount DESC, order_time ASC ) AS rn FROM orders ) t WHERE rn 1;这道题最核心的逻辑就是PARTITION BY user_id按用户分组ORDER BY order_amount DESC把金额最大的排第一然后取rn等于1的行。要注意如果同一个用户有两笔相同金额的订单需要再加一个排序字段保证结果唯一不然同样金额的订单可能随机取一条这就是测试思维里的“确定性”问题。SQL题写完后建议自己再检查一遍边界情况表中只有一条记录怎么办金额为负数怎么办关联字段有NULL怎么办。这些细节不只是笔试加分项实际测试工作中验证SQL正确性时同样要考虑。2.3 编程题能用代码自动化才能提效编程题部分QA岗的要求比开发岗低一些但不是说就能完全不准备。我周围有同学抱着“我是做测试的为什么要写代码”的心态去笔试结果编程题直接空白后面面试再优秀也很难救回来。从题型上看QA笔试编程题偏重字符串处理、数组操作、逻辑判断基本不考复杂的图论或动态规划。比如判断一个字符串是否为有效的订单编号。解析日志文件统计某个接口的失败率。将两条有序数组合并成一条有序数组。实现一个简单的LRU缓存淘汰策略。校验优惠券编码是否符合规则并计算总优惠金额。这些题目本身算法难度不大但题面会套上电商的业务场景让你觉得是在解决一个真实问题。我当时拿到的编程题大意是给定一组订单区间每个区间包含开始时间和结束时间把有重叠的区间合并之后返回合并后的区间列表。这道题在LeetCode上叫“合并区间”是Medium难度。思路分两步走先把区间按开始时间排序然后遍历区间判断当前区间的开始时间是否小于等于前一个合并区间的结束时间如果是就合并不是就开一个新的区间。def merge_intervals(intervals): if not intervals: return [] intervals.sort(keylambda x: x[0]) merged [intervals[0]] for start, end in intervals[1:]: prev_start, prev_end merged[-1] if start prev_end: merged[-1][1] max(prev_end, end) else: merged.append([start, end]) return merged写这道题的时候有个容易漏的细节合并的时候需要取max(prev_end, end)因为新区间的结束时间可能比前一个区间的结束时间短直接赋值会把区间缩短导致结果错误。这种细节就是典型的“边界条件”要么是测试思维敏感的人一眼发现要么是没意识到的人调试半天还不明白错在哪里。另一个高频题是版本号比较。电商系统发版频繁QA经常需要判断两个版本号的大小确认线上环境部署的是不是预期版本。题目要求实现一个函数输入1.0.2和1.0.10输出后者更大。def compare_version(v1, v2): parts1 v1.split(.) parts2 v2.split(.) max_len max(len(parts1), len(parts2)) for i in range(max_len): n1 int(parts1[i]) if i len(parts1) else 0 n2 int(parts2[i]) if i len(parts2) else 0 if n1 n2: return 1 elif n1 n2: return -1 return 0这道题的核心是“缺位补零”。版本号1.0和1.0.0应该是相等的如果直接比较字符串长度就会出错。做法是把短的版本号缺的位置补成0再逐段比较。思路不复杂但很能体现一个人考虑问题是否周全。编程题部分建议用自己最熟练的语言去写不要在现场尝试用新语言。我习惯用Python写起来快而且不用声明变量类型笔试时间紧张时这个优势非常明显。提示在线笔试平台一般支持切换语言但切换后代码不互通。进去之后先看整体题量再决定每道题的时间分配千万别在一道选择题上耗太久。2.4 测试用例设计题拉开差距的关键测试用例设计题是QA笔试的“送命题”也是“送分题”。说它送命是因为很多没有系统学过测试理论的候选人完全不知道从哪下手说它送分是因为只要掌握一套结构化的分析方法这类题反而最好拿分。常见的出题形式是给你一个具体功能让你设计测试用例。比如设计“加入购物车”功能的测试用例。设计“登录接口”的测试用例。设计“优惠券满减”功能的测试用例。答题的核心是覆盖面要全要有层次感。我一般会从功能、异常、边界、兼容、性能、安全这几个维度去拆然后逐个展开。下面用“购物车优惠券满100减20”这个场景举个栗子用例编号测试场景操作步骤预期结果优先级TC01正常满减购物车商品合计120元使用满100减20券实付100元优惠券扣减成功P0TC02金额恰好等于阈值购物车合计正好100元使用满100减20券实付80元满减生效P0TC03金额不足阈值购物车合计99.9元使用满100减20券提示“还差0.1元可用券”不可使用P0TC04已过期优惠券选择一张已过期的满100减20券置灰不可选择或提示已过期P1TC05优惠券叠加同时选择两张可叠加的满减券按叠加规则计算优惠金额P1TC06退款后优惠券状态订单全额退款优惠券退回账户在有效期内可继续使用P1TC07并发下单两个设备同时使用同一张优惠券只有一个订单能使用成功另一个提示优惠券已被使用P1TC08金额精度商品总价为100.005元按支付规则四舍五入到分满减按实付金额计算P2每个用例都要把操作步骤和预期结果写清楚别只写一句话“测试正常满减”就完事。面试官或阅卷人看的是你能不能把需求转换成可执行、可验证的用例这是QA最核心的日常能力。我自己的答题习惯是先写功能用例再写异常和边界用例最后补兼容、性能、安全相关的用例。这样按照优先级从高到低排列即使时间不够阅卷人也能看到你系统性的思考过程而不是零散的几个想法。3. 笔试现场流程与控制——细节决定成败笔试内容本身很重要但很多同学忽视了“考试现场”这个变量。线上笔试和线下考试完全不同环境、时间、网速、设备都可能成为影响结果的因素。这些看似琐碎的细节往往决定着你能不能把真实水平发挥出来。3.1 线上笔试的环境准备Shopee的笔试通常使用在线代码测评平台要求开启摄像头浏览器会全程锁屏监控。我建议提前半小时做以下准备找一个网络稳定的环境有线网络比Wi-Fi更稳妥。如果只能用Wi-Fi务必确认没有其他设备占用大带宽否则代码提交卡住的时候人都要急疯。准备好身份证或学生证放在手边开考前可能需要拍照验证身份。关掉所有无关软件尤其是会弹窗的消息应用。有些平台检测到切出浏览器次数过多会直接交卷被误判作弊那真的没地方说理。如果平台允许准备本地IDE和编译器。在线编辑器没有代码补全也没有本地调试环境出bug了只能靠肉眼排查效率低很多。注意笔试过程中不要频繁切换浏览器窗口。如果确实需要查看题目而切出动作要快不要在其他页面停留太久。我就听说过有人因为切出去查资料被系统判定作弊这比考砸更冤。3.2 时间分配策略笔试时长一般在60到90分钟题目数量在5到8道之间。我推荐的时间分配策略是选择题控制在15到20分钟SQL题15分钟编程题留足40分钟测试用例题15分钟。先做选择题是因为它们单题耗时短能做多少做多少先把基础分拿到手。SQL和编程题需要打字和调试放在中间做脑子里要保持清醒。测试用例设计题放在最后因为这类题思考为主、写作为辅就算时间不够也能快速列出要点拿部分分数。编程题如果卡住了别死磕。先跳过做后面的题目最后有时间再回来补。笔试平台通常按通过用例比例给分就算只能通过部分case也能得到一定分数比空白交卷好得多。3.3 不会做的时候怎么办笔试最怕的不是不会而是“明明有思路但代码怎么写都过不了全部case”。这种时候我建议分三步处理第一步把题目里能想到的边界条件列出来确保自己的代码至少覆盖了空输入、单元素、全相同元素这几类情况。第二步在代码里写注释把思路写清楚。有些笔试平台的评分会参考代码风格和注释更重要的是注释能帮你在检查和复查时快速回忆代码逻辑。第三步如果只通过了部分用例把通过的用例名复制下来分析看看它们覆盖了哪类场景再反推自己代码漏了哪类场景。这其实就是测试思维在笔试中的应用——先看哪些过了再看哪些挂了根据差异定位问题。打完代码之后一定要自己构造几个用例跑一遍。笔试平台允许自定义测试用例不要偷懒跳过这一步。很多小bug就是靠最后这十分钟自测发现的。4. 备战攻略——不同基础的人怎么准备笔试的考察范围看起来很广但准备起来其实是有一条清晰的路线图的。我结合自己和周围同学的经验按不同基础水平给出具体的备战方案。4.1 零基础转测试先把地基打好如果你是非科班转测试或者已经学了测试基础但代码能力偏弱前期准备重心要放在“补齐硬技能”上第一SQL是性价比最高的投入。花一周时间把SELECT、JOIN、GROUP BY、HAVING、窗口函数练熟笔试里SQL题基本就能拿下大半。第二网络基础和操作系统按“面试高频题”去准备不需要啃完整本教材把TCP三次握手、HTTP状态码、进程线程区别、死锁条件这些常考题吃透就行。第三编程题从LeetCode的Easy题开始刷优先选字符串、数组、哈希表相关的题目。每天两三道刷够两个月就能Cover笔试难度。第四测试理论系统过一遍等价类划分、边界值分析、场景法、因果图然后找几个常用App的功能比如登录、搜索、购物车、支付自己练着写测试用例练完对照网上的优秀用例找差距。4.2 有基础的同学查漏补缺加上限如果你代码能力不错也有过一些测试相关的项目经历或实习经验准备的重点就是“查漏补缺”和“提升上限”。查漏补缺的方向是Linux命令、Git操作、Docker基础这些平时不做运维不常用、但笔试会考的知识点。我当时把鸟哥的Linux私房菜里“常用命令”那一章从头过了一遍又用虚拟机把grep、awk、sed的实际用法跑了一遍笔试遇到命令行题就完全不慌了。提升上限的方向是业务理解和测试设计。电商类公司的笔试题一定会站在业务角度出题所以不能只看枯燥的技术书还要理解电商系统是怎么运转的。我当时把一整个电商主流程从头到尾梳理了一遍用户注册登录、浏览商品、加购、下单、支付、库存扣减、订单发货、确认收货、售后退款。每个环节画一张流程图标出哪些地方容易出现数据不一致、超卖、重复支付、状态不流转的问题。梳理完这一遍之后再做测试用例设计题就特别顺。4.3 刷题资源与针对性准备笔试准备不用买很多课资源在精不在多。我用下来比较顺手的工具和资源有这些SQL练习SQLZoo和LeetCode的Database板块从简单查询到窗口函数都有覆盖每天刷三题。Python/算法LeetCode Hot 100里的字符串、数组、哈希表题全部刷完基本就能应付测试岗笔试。Linux练习自己装一个虚拟机装个Ubuntu系统每天敲几遍查找日志、统计文件、查看进程的命令比死记硬背有效得多。测试理论翻一遍《软件测试的艺术》或者搜“软件测试面试题”看高频考点重点掌握测试用例设计方法。另外强烈建议在正式笔试之前自己模拟一次完整流程。计时90分钟闭卷开启摄像头用白纸写草稿完全按照考试环境来。模拟完你才会知道自己的时间分配差在哪里哪个模块速度不达标怎么调整节奏。4.4 电商业务知识的补充学习Shopee的业务不只是简单的买卖商品海外市场决定了它的系统会更复杂。我当时专门研究了一下跨境电商和本地电商的区别发现几个特别容易在笔试和面试中出现的业务点秒杀场景下高并发如何保证不超卖支付回调失败时订单状态如何流转优惠券过期和退款的时序问题多币种订单的金额精度处理以及物流轨迹异常时系统如何容错。每个问题背后都有对应的技术方案比如分布式锁、事务消息、状态机、幂等性设计。虽然是QA岗但了解这些方案的原理会帮你更好地判断测试重点和风险点。5. 常见失分点与复盘心得——帮你们少踩坑笔试结束不等于这件事就结束了及时的复盘才是提升的关键。我见过太多同学笔试结束就对答案、看分数然后就不了了之。其实每次笔试暴露出来的问题都是下一次笔试前最值得优先补的内容。5.1 最容易被扣分的五个细节结合我和周围同学的复盘QA笔试失分最多的地方往往不是题目本身难而是一些细节问题第一SQL题没考虑数据中的NULL。很多题目里的商品类别或用户ID都有空值直接GROUP BY会把NULL归成一组和预期结果不一致。第二编程题输出格式不匹配。题目要求输出逗号分隔你输出的是空格分隔平台直接判定Wrong Answer连部分分都没有。第三异常分支没有处理。题目说“输入的订单号可能为空字符串”你的代码直接调用了字符串方法空字符串时直接报错。第四选择题多选漏选。宁可少选也不要错选错选一道题可能把整个模块的分数拉低很多。第五测试用例设计漏了业务规则。比如一个电商满减功能你测了各种金额组合但忘了测“退款后优惠券是否退还”和“优惠券是否可与其他促销叠加”这两个业务规则这种遗漏在面试官眼里是致命的。5.2 笔试后的复盘方法每场笔试结束后我建议用表格把这次笔试的所有题目整理一遍包括题型、考察知识点、自己的得分情况、失分原因、对应的改进方向。不用写得很复杂关键是找出自己的薄弱模块。失分点原因分析改进动作优先级SQL窗口函数题没写出来平时只写GROUP BY对PARTITION BY不熟刷完LeetCode Database板块窗口函数专题高编程题边界条件漏判没有自己构造测试用例提交前至少自测3组用例包含空值和极端值高测试用例缺少异常场景业务背景了解不足梳理电商全流程找每个环节的异常分支中复盘还有一个容易被忽略的作用你能通过笔试题目反推公司对QA岗位的定位。如果编程题占比很高说明这家公司期望QA具备较强的自动化开发能力如果测试用例设计题占比高说明QA会深度参与需求评审和用例评审如果SQL和数据分析类题目多说明日常测试工作会很依赖数据验证或者有专门的测试数据团队需要紧密协作。这些信息对后续面试准备非常有指导意义。5.3 关于笔试和面试衔接的思考笔试通过只是第一关但它在整个招聘流程里的作用被很多人低估了。笔试成绩往往会同步给面试官作为面试提问的起点。我在面试时就被问过“你笔试里合并区间的代码用了排序如果在海量数据下内存不够放你会怎么做”。这其实就是笔试题目在面试环节的延伸考察的是系统设计和工程思维的边界。所以别抱着“笔试过了就万事大吉”的心态。每道笔试题都可以往深处再想一想如果数据量扩大一百倍怎么办、如果系统并发提高一百倍怎么办、如果需求变更了代码结构怎么调整。多做这层思考面试被追问的时候你才有话可说。最后再分享一个小经验笔试前一定要睡够保持脑子清醒比临时抱佛脚多刷几道题有用得多。Shopee的笔试题目量不算大但每道题都需要你在“编码能力”和“测试思维”两个维度上同时发力。我在笔试前连续刷了大半个月的题最后临考前一天反而没怎么刷把之前整理的错题本过了一遍就早早休息了第二天状态明显比平时好。稳扎稳打把这个流程走完你就已经赢过大多数裸考的人了。 Shopee QA提前批笔试深度复盘：题型拆解与备战攻略
2024年秋招刚开始那阵子我身边好几个投测试岗的同学都在讨论Shopee的提前批笔试。相比很多公司笔试安排在简历筛选之后很久、流程慢得让人焦虑Shopee这波节奏明显快很多——简历投出去没多久就收到了在线笔试通知用的是牛客或者HackerRank这类在线测评系统全程摄像头监控限时一个半小时左右。作为QA方向的候选人这场笔试的考察点和平时在学校里刷的题很不一样。它不单纯看你会不会写代码也不单纯考测试理论而是把两者揉在一起试图判断你有没有“测试思维”。我整理了一下自己做题和周围同学复盘的信息把题型分布、高频考点、时间分配、备战路线全部梳理成一篇完整的复盘。如果你打算投跨境电商或者大厂测试岗这篇内容应该能帮你少走不少弯路。1. QA笔试题到底在考什么——先想明白再动手很多同学拿到笔试通知第一反应就是赶紧刷LeetCode生怕编程题卡住。但实际上QA岗的笔试逻辑和开发岗有本质区别。开发岗侧重“我能不能把功能写出来”QA岗侧重“我能不能发现哪里会出问题并验证它不出问题”。带着这个认知去看题你会发现自己准备的侧重点完全不同。1.1 从岗位JD反推考察维度我当时特地把Shopee QA校招JD里的关键词拉出来看了几遍里面反复出现的是“质量意识”“测试设计”“自动化”“跨团队沟通”。这些词翻译成笔试考察点大概就是下面这几个维度计算机基础网络协议、操作系统、数据库、Linux常用命令。这些是测试工程师理解系统行为的基础尤其电商场景下接口测试、性能问题排查都依赖这些知识。编程能力不要求你写出多复杂的算法但至少能用Python或Java写自动化脚本、处理测试数据。出题难度一般落在LeetCode Easy到Medium之间。SQL能力QA验证数据正确性、造测试数据、分析线上问题都要写SQL窗口函数这些进阶语法也是常客。测试设计能力给你一个具体功能让你列测试场景。这一块是QA岗的“专业分”也是很多半路转测试的同学最没底的模块。1.2 为什么电商公司特别爱考这些Shopee的核心业务是跨境电商订单、支付、物流、优惠券、商家管理这些模块每个都是QA的主战场。跨境电商意味着分布式系统、多时区、多币种、高并发这些场景天然会带来数据一致性和时序问题。所以笔试里频繁出现SQL题、并发相关的选择题、异常处理的编程题都是有原因的。比如订单状态流转支付成功但扣库存失败怎么办用户下单时用了优惠券退款的时候优惠券怎么处理这些业务逻辑背后全是边界条件和异常分支QA恰恰就是守在这些边界上的人。笔试设计这些题目表面是考技术实际是看你有没有能力理解和验证复杂的业务规则。1.3 提前批和正式批的差异我了解到的信息是Shopee提前批笔试的整体难度会比正式批稍微友好一点但考查范围更广。提前批更像是“广泛撒网重点捕捞”通过笔试先筛掉基础薄弱的人后面面试再深入考察测试思维和项目经验。另外提前批有个很现实的好处就是流程短。笔试通过后很快安排面试而且就算提前批挂了有些公司后续正式批还能再投。所以提前批对于想进Shopee的同学来说相当于多了一次模拟演习的机会哪怕没通过也能通过笔试题目反推出公司重视的能力模型为后续面试做准备。2. 题型拆解与真题复盘——按模块过一遍目前从各个渠道汇总的信息来看Shopee QA提前批笔试时间一般是60到90分钟题目结构大致分为四个模块计算机基础选择题单选加多选、SQL题、编程题、测试用例设计题。每个模块的侧重点和准备方式都不一样下面分开说。2.1 计算机基础选择题高频考点与避坑选择题覆盖的知识点比较杂但高频区很集中。我复盘下来出现频率最高的是这几块TCP和UDP的区别、三次握手和四次挥手的具体过程以及为什么握手是三次而不是两次。进程和线程的区别、死锁产生的四个必要条件、常用的进程调度算法。Python基础语法陷阱比如可变对象作为默认参数、深拷贝浅拷贝、列表推导式的作用域。Linux常用命令特别是grep、awk、sed、find、top、netstat这些测试日常会用的命令。数据库的ACID特性、事务隔离级别、脏读不可重复读幻读的区别。常见数据结构的时间复杂度比如哈希表查找、二叉搜索树查找、快排最坏情况。选择题里最容易翻车的其实是多选。单选还可以靠排除法蒙多选只要漏选或错选一个就全扣分而且有些选项表述得非常模棱两可。我在准备后期专门过了一遍计算机网络的分层模型尤其是HTTP和HTTPS的握手过程这块几乎是必考。注意如果笔试里出现了“下列关于XX说法正确的是”这种多选一定要把每个选项都当成判断题来做。不确定的不要选少选还能得部分分错选直接零分。2.2 SQL题数据分析能力是QA的隐藏加分项SQL题在QA笔试里的分量一年比一年重。原因很简单QA日常工作中到处都要和数据打交道验证前端展示的数据和数据库一致、构造测试数据、排查线上订单异常、统计自动化测试覆盖率。SQL写不溜很多工作根本没法推进。Shopee的SQL题基本都放在电商场景里常见的出题方式有这些找出每个用户最近一笔订单的信息。统计每个商品类别的销售额排行取前几名。找出连续三天都有登录行为的用户。计算优惠券的使用率按渠道分组对比。把订单表和退款表关联起来分析退款率最高的商品。这里需要特别重视窗口函数也就是ROW_NUMBER、RANK、DENSE_RANK、SUM OVER这组语法。很多“分组取Top N”的题用GROUP BY写起来非常费劲用窗口函数三行就搞定了。我拿一道典型的题目举例表orders包含字段order_id, user_id, product_id, order_amount, order_time。请找出每个用户下单金额最高的订单信息。SELECT user_id, order_id, product_id, order_amount, order_time FROM ( SELECT user_id, order_id, product_id, order_amount, order_time, ROW_NUMBER() OVER ( PARTITION BY user_id ORDER BY order_amount DESC, order_time ASC ) AS rn FROM orders ) t WHERE rn 1;这道题最核心的逻辑就是PARTITION BY user_id按用户分组ORDER BY order_amount DESC把金额最大的排第一然后取rn等于1的行。要注意如果同一个用户有两笔相同金额的订单需要再加一个排序字段保证结果唯一不然同样金额的订单可能随机取一条这就是测试思维里的“确定性”问题。SQL题写完后建议自己再检查一遍边界情况表中只有一条记录怎么办金额为负数怎么办关联字段有NULL怎么办。这些细节不只是笔试加分项实际测试工作中验证SQL正确性时同样要考虑。2.3 编程题能用代码自动化才能提效编程题部分QA岗的要求比开发岗低一些但不是说就能完全不准备。我周围有同学抱着“我是做测试的为什么要写代码”的心态去笔试结果编程题直接空白后面面试再优秀也很难救回来。从题型上看QA笔试编程题偏重字符串处理、数组操作、逻辑判断基本不考复杂的图论或动态规划。比如判断一个字符串是否为有效的订单编号。解析日志文件统计某个接口的失败率。将两条有序数组合并成一条有序数组。实现一个简单的LRU缓存淘汰策略。校验优惠券编码是否符合规则并计算总优惠金额。这些题目本身算法难度不大但题面会套上电商的业务场景让你觉得是在解决一个真实问题。我当时拿到的编程题大意是给定一组订单区间每个区间包含开始时间和结束时间把有重叠的区间合并之后返回合并后的区间列表。这道题在LeetCode上叫“合并区间”是Medium难度。思路分两步走先把区间按开始时间排序然后遍历区间判断当前区间的开始时间是否小于等于前一个合并区间的结束时间如果是就合并不是就开一个新的区间。def merge_intervals(intervals): if not intervals: return [] intervals.sort(keylambda x: x[0]) merged [intervals[0]] for start, end in intervals[1:]: prev_start, prev_end merged[-1] if start prev_end: merged[-1][1] max(prev_end, end) else: merged.append([start, end]) return merged写这道题的时候有个容易漏的细节合并的时候需要取max(prev_end, end)因为新区间的结束时间可能比前一个区间的结束时间短直接赋值会把区间缩短导致结果错误。这种细节就是典型的“边界条件”要么是测试思维敏感的人一眼发现要么是没意识到的人调试半天还不明白错在哪里。另一个高频题是版本号比较。电商系统发版频繁QA经常需要判断两个版本号的大小确认线上环境部署的是不是预期版本。题目要求实现一个函数输入1.0.2和1.0.10输出后者更大。def compare_version(v1, v2): parts1 v1.split(.) parts2 v2.split(.) max_len max(len(parts1), len(parts2)) for i in range(max_len): n1 int(parts1[i]) if i len(parts1) else 0 n2 int(parts2[i]) if i len(parts2) else 0 if n1 n2: return 1 elif n1 n2: return -1 return 0这道题的核心是“缺位补零”。版本号1.0和1.0.0应该是相等的如果直接比较字符串长度就会出错。做法是把短的版本号缺的位置补成0再逐段比较。思路不复杂但很能体现一个人考虑问题是否周全。编程题部分建议用自己最熟练的语言去写不要在现场尝试用新语言。我习惯用Python写起来快而且不用声明变量类型笔试时间紧张时这个优势非常明显。提示在线笔试平台一般支持切换语言但切换后代码不互通。进去之后先看整体题量再决定每道题的时间分配千万别在一道选择题上耗太久。2.4 测试用例设计题拉开差距的关键测试用例设计题是QA笔试的“送命题”也是“送分题”。说它送命是因为很多没有系统学过测试理论的候选人完全不知道从哪下手说它送分是因为只要掌握一套结构化的分析方法这类题反而最好拿分。常见的出题形式是给你一个具体功能让你设计测试用例。比如设计“加入购物车”功能的测试用例。设计“登录接口”的测试用例。设计“优惠券满减”功能的测试用例。答题的核心是覆盖面要全要有层次感。我一般会从功能、异常、边界、兼容、性能、安全这几个维度去拆然后逐个展开。下面用“购物车优惠券满100减20”这个场景举个栗子用例编号测试场景操作步骤预期结果优先级TC01正常满减购物车商品合计120元使用满100减20券实付100元优惠券扣减成功P0TC02金额恰好等于阈值购物车合计正好100元使用满100减20券实付80元满减生效P0TC03金额不足阈值购物车合计99.9元使用满100减20券提示“还差0.1元可用券”不可使用P0TC04已过期优惠券选择一张已过期的满100减20券置灰不可选择或提示已过期P1TC05优惠券叠加同时选择两张可叠加的满减券按叠加规则计算优惠金额P1TC06退款后优惠券状态订单全额退款优惠券退回账户在有效期内可继续使用P1TC07并发下单两个设备同时使用同一张优惠券只有一个订单能使用成功另一个提示优惠券已被使用P1TC08金额精度商品总价为100.005元按支付规则四舍五入到分满减按实付金额计算P2每个用例都要把操作步骤和预期结果写清楚别只写一句话“测试正常满减”就完事。面试官或阅卷人看的是你能不能把需求转换成可执行、可验证的用例这是QA最核心的日常能力。我自己的答题习惯是先写功能用例再写异常和边界用例最后补兼容、性能、安全相关的用例。这样按照优先级从高到低排列即使时间不够阅卷人也能看到你系统性的思考过程而不是零散的几个想法。3. 笔试现场流程与控制——细节决定成败笔试内容本身很重要但很多同学忽视了“考试现场”这个变量。线上笔试和线下考试完全不同环境、时间、网速、设备都可能成为影响结果的因素。这些看似琐碎的细节往往决定着你能不能把真实水平发挥出来。3.1 线上笔试的环境准备Shopee的笔试通常使用在线代码测评平台要求开启摄像头浏览器会全程锁屏监控。我建议提前半小时做以下准备找一个网络稳定的环境有线网络比Wi-Fi更稳妥。如果只能用Wi-Fi务必确认没有其他设备占用大带宽否则代码提交卡住的时候人都要急疯。准备好身份证或学生证放在手边开考前可能需要拍照验证身份。关掉所有无关软件尤其是会弹窗的消息应用。有些平台检测到切出浏览器次数过多会直接交卷被误判作弊那真的没地方说理。如果平台允许准备本地IDE和编译器。在线编辑器没有代码补全也没有本地调试环境出bug了只能靠肉眼排查效率低很多。注意笔试过程中不要频繁切换浏览器窗口。如果确实需要查看题目而切出动作要快不要在其他页面停留太久。我就听说过有人因为切出去查资料被系统判定作弊这比考砸更冤。3.2 时间分配策略笔试时长一般在60到90分钟题目数量在5到8道之间。我推荐的时间分配策略是选择题控制在15到20分钟SQL题15分钟编程题留足40分钟测试用例题15分钟。先做选择题是因为它们单题耗时短能做多少做多少先把基础分拿到手。SQL和编程题需要打字和调试放在中间做脑子里要保持清醒。测试用例设计题放在最后因为这类题思考为主、写作为辅就算时间不够也能快速列出要点拿部分分数。编程题如果卡住了别死磕。先跳过做后面的题目最后有时间再回来补。笔试平台通常按通过用例比例给分就算只能通过部分case也能得到一定分数比空白交卷好得多。3.3 不会做的时候怎么办笔试最怕的不是不会而是“明明有思路但代码怎么写都过不了全部case”。这种时候我建议分三步处理第一步把题目里能想到的边界条件列出来确保自己的代码至少覆盖了空输入、单元素、全相同元素这几类情况。第二步在代码里写注释把思路写清楚。有些笔试平台的评分会参考代码风格和注释更重要的是注释能帮你在检查和复查时快速回忆代码逻辑。第三步如果只通过了部分用例把通过的用例名复制下来分析看看它们覆盖了哪类场景再反推自己代码漏了哪类场景。这其实就是测试思维在笔试中的应用——先看哪些过了再看哪些挂了根据差异定位问题。打完代码之后一定要自己构造几个用例跑一遍。笔试平台允许自定义测试用例不要偷懒跳过这一步。很多小bug就是靠最后这十分钟自测发现的。4. 备战攻略——不同基础的人怎么准备笔试的考察范围看起来很广但准备起来其实是有一条清晰的路线图的。我结合自己和周围同学的经验按不同基础水平给出具体的备战方案。4.1 零基础转测试先把地基打好如果你是非科班转测试或者已经学了测试基础但代码能力偏弱前期准备重心要放在“补齐硬技能”上第一SQL是性价比最高的投入。花一周时间把SELECT、JOIN、GROUP BY、HAVING、窗口函数练熟笔试里SQL题基本就能拿下大半。第二网络基础和操作系统按“面试高频题”去准备不需要啃完整本教材把TCP三次握手、HTTP状态码、进程线程区别、死锁条件这些常考题吃透就行。第三编程题从LeetCode的Easy题开始刷优先选字符串、数组、哈希表相关的题目。每天两三道刷够两个月就能Cover笔试难度。第四测试理论系统过一遍等价类划分、边界值分析、场景法、因果图然后找几个常用App的功能比如登录、搜索、购物车、支付自己练着写测试用例练完对照网上的优秀用例找差距。4.2 有基础的同学查漏补缺加上限如果你代码能力不错也有过一些测试相关的项目经历或实习经验准备的重点就是“查漏补缺”和“提升上限”。查漏补缺的方向是Linux命令、Git操作、Docker基础这些平时不做运维不常用、但笔试会考的知识点。我当时把鸟哥的Linux私房菜里“常用命令”那一章从头过了一遍又用虚拟机把grep、awk、sed的实际用法跑了一遍笔试遇到命令行题就完全不慌了。提升上限的方向是业务理解和测试设计。电商类公司的笔试题一定会站在业务角度出题所以不能只看枯燥的技术书还要理解电商系统是怎么运转的。我当时把一整个电商主流程从头到尾梳理了一遍用户注册登录、浏览商品、加购、下单、支付、库存扣减、订单发货、确认收货、售后退款。每个环节画一张流程图标出哪些地方容易出现数据不一致、超卖、重复支付、状态不流转的问题。梳理完这一遍之后再做测试用例设计题就特别顺。4.3 刷题资源与针对性准备笔试准备不用买很多课资源在精不在多。我用下来比较顺手的工具和资源有这些SQL练习SQLZoo和LeetCode的Database板块从简单查询到窗口函数都有覆盖每天刷三题。Python/算法LeetCode Hot 100里的字符串、数组、哈希表题全部刷完基本就能应付测试岗笔试。Linux练习自己装一个虚拟机装个Ubuntu系统每天敲几遍查找日志、统计文件、查看进程的命令比死记硬背有效得多。测试理论翻一遍《软件测试的艺术》或者搜“软件测试面试题”看高频考点重点掌握测试用例设计方法。另外强烈建议在正式笔试之前自己模拟一次完整流程。计时90分钟闭卷开启摄像头用白纸写草稿完全按照考试环境来。模拟完你才会知道自己的时间分配差在哪里哪个模块速度不达标怎么调整节奏。4.4 电商业务知识的补充学习Shopee的业务不只是简单的买卖商品海外市场决定了它的系统会更复杂。我当时专门研究了一下跨境电商和本地电商的区别发现几个特别容易在笔试和面试中出现的业务点秒杀场景下高并发如何保证不超卖支付回调失败时订单状态如何流转优惠券过期和退款的时序问题多币种订单的金额精度处理以及物流轨迹异常时系统如何容错。每个问题背后都有对应的技术方案比如分布式锁、事务消息、状态机、幂等性设计。虽然是QA岗但了解这些方案的原理会帮你更好地判断测试重点和风险点。5. 常见失分点与复盘心得——帮你们少踩坑笔试结束不等于这件事就结束了及时的复盘才是提升的关键。我见过太多同学笔试结束就对答案、看分数然后就不了了之。其实每次笔试暴露出来的问题都是下一次笔试前最值得优先补的内容。5.1 最容易被扣分的五个细节结合我和周围同学的复盘QA笔试失分最多的地方往往不是题目本身难而是一些细节问题第一SQL题没考虑数据中的NULL。很多题目里的商品类别或用户ID都有空值直接GROUP BY会把NULL归成一组和预期结果不一致。第二编程题输出格式不匹配。题目要求输出逗号分隔你输出的是空格分隔平台直接判定Wrong Answer连部分分都没有。第三异常分支没有处理。题目说“输入的订单号可能为空字符串”你的代码直接调用了字符串方法空字符串时直接报错。第四选择题多选漏选。宁可少选也不要错选错选一道题可能把整个模块的分数拉低很多。第五测试用例设计漏了业务规则。比如一个电商满减功能你测了各种金额组合但忘了测“退款后优惠券是否退还”和“优惠券是否可与其他促销叠加”这两个业务规则这种遗漏在面试官眼里是致命的。5.2 笔试后的复盘方法每场笔试结束后我建议用表格把这次笔试的所有题目整理一遍包括题型、考察知识点、自己的得分情况、失分原因、对应的改进方向。不用写得很复杂关键是找出自己的薄弱模块。失分点原因分析改进动作优先级SQL窗口函数题没写出来平时只写GROUP BY对PARTITION BY不熟刷完LeetCode Database板块窗口函数专题高编程题边界条件漏判没有自己构造测试用例提交前至少自测3组用例包含空值和极端值高测试用例缺少异常场景业务背景了解不足梳理电商全流程找每个环节的异常分支中复盘还有一个容易被忽略的作用你能通过笔试题目反推公司对QA岗位的定位。如果编程题占比很高说明这家公司期望QA具备较强的自动化开发能力如果测试用例设计题占比高说明QA会深度参与需求评审和用例评审如果SQL和数据分析类题目多说明日常测试工作会很依赖数据验证或者有专门的测试数据团队需要紧密协作。这些信息对后续面试准备非常有指导意义。5.3 关于笔试和面试衔接的思考笔试通过只是第一关但它在整个招聘流程里的作用被很多人低估了。笔试成绩往往会同步给面试官作为面试提问的起点。我在面试时就被问过“你笔试里合并区间的代码用了排序如果在海量数据下内存不够放你会怎么做”。这其实就是笔试题目在面试环节的延伸考察的是系统设计和工程思维的边界。所以别抱着“笔试过了就万事大吉”的心态。每道笔试题都可以往深处再想一想如果数据量扩大一百倍怎么办、如果系统并发提高一百倍怎么办、如果需求变更了代码结构怎么调整。多做这层思考面试被追问的时候你才有话可说。最后再分享一个小经验笔试前一定要睡够保持脑子清醒比临时抱佛脚多刷几道题有用得多。Shopee的笔试题目量不算大但每道题都需要你在“编码能力”和“测试思维”两个维度上同时发力。我在笔试前连续刷了大半个月的题最后临考前一天反而没怎么刷把之前整理的错题本过了一遍就早早休息了第二天状态明显比平时好。稳扎稳打把这个流程走完你就已经赢过大多数裸考的人了。