1. 投递前需要想清楚的三件事先自报家门我是2024届毕业生参加的是2024年秋招Shopee QA提前批笔试。坦白说投递之前我对Shopee的了解主要停留在电商业务和东南亚市场但对这家公司的QA岗位到底考什么、看重什么心里完全没底。真正做完笔试之后我发现它考察的东西和传统互联网大厂的测开笔试有重叠也有很不一样的地方。如果你也在准备类似岗位这篇文章可以帮你少走很多弯路。先说结论Shopee QA提前批笔试的整体风格偏“实用主义”不考偏题怪题但非常看重你有没有测试思维、边界意识和从现象反推本质的能力。热搜词里的“shopee逆向”也让我印象深刻——不过先别想歪这里说的“逆向”不是破解App、不是逆向工程而是测试圈里常说的“逆向思维”拿到一个问题不从正向实现角度出发而是从输出、现象、异常结果倒推可能的原因和测试点。这个能力在笔试中占了很大的比重后面我会专门展开讲。在投递之前我觉得有三件事值得先想清楚否则容易在笔试中迷失方向。第一QA和测开在Shopee笔试中是不是一回事我的理解是Shopee的QA提前批笔试更偏向“测试工程师”的通用能力底座但对代码有一定要求。如果你以为纯黑盒手工测试就能应付那大概率会翻车。笔试里会出现代码题只是不像开发岗那么侧重算法优化而是考察你能不能写出正确、可扩展、可验证的代码逻辑以及能不能用代码解决测试数据构造、结果校验这类问题。所以投递前至少要把一门编程语言练到能够写清楚函数和类的程度推荐Python或Java。第二提前批和正式批的节奏差异。提前批通常流程更快笔试通过后会有面试面试通过后有机会提前锁定offer。但提前批的笔试时间往往和秋招其他公司撞车。我当时就遇到了两家公司的笔试时间重叠最后不得不在同一时间段内切换两个考试窗口。这种压力下提前对Shopee笔试的题型和时间分配做功课价值就体现出来了。第三你自己的目标岗位方向。Shopee的QA下面可能细分方向不同比如业务质量保障、测试开发工具链、性能测试专项等。提前批笔试大概率是统一卷但你可以在主观题里往自己想去的方向靠。比如我的侧重点是测试开发所以考场上有意识地多写了一些关于自动化测试框架选型和用例设计思路的内容。如果你偏业务测试那就多展示你对业务场景的理解。这一点很关键因为笔试不只是答题更是一次有限范围内的自我展示。2. 笔试原题复盘从题型看考察逻辑虽然严格来说每个候选人拿到的题目可能略有不同但从我这一批的反馈来看题型结构相对稳定。整体分为三块客观题选择题/判断题、场景设计题、手写代码题。下面我凭记忆做一个复盘重点不是贴原题而是拆解每类题背后的考察逻辑这样你就算遇到不同的题目也能知道怎么应对。2.1 客观题里的测试概念比想象中更“抠细节”客观题部分大概覆盖了这些知识点软件测试生命周期、缺陷生命周期、白盒测试与黑盒测试的区别、静态测试与动态测试、回归测试策略、等价类划分、边界值分析、判定表、场景法、因果图、测试覆盖率语句覆盖、分支覆盖、条件覆盖、路径覆盖、敏捷测试和DevOps中的测试角色、API测试和UI测试的差异。听起来都是教材内容但Shopee的出题风格不是直接问“什么是边界值”而是给一个具体场景让你选哪个测试用例最能发现某个缺陷。比如有一类题很典型给出一段函数问下面哪组测试数据能覆盖分支条件组合的最大比例。这种题就需要你真正理解覆盖率的计算而不是背概念。我印象比较深的一道题是关于“缺陷密度”的。题目描述了一个团队在迭代结束时统计到每千行代码缺陷数为5问你如何评价这个数字。选项包括质量很好、质量不好、无法仅凭这个数字判断、需要结合测试用例数和代码复杂度综合判断。正确答案显然是“无法仅凭这个数字判断”。这道题看似简单但很多人会掉进“数字越低越好”的直觉陷阱。这说明Shopee考察的是质量度量思维而不仅仅是知识点本身。2.2 场景设计题给一个登录功能你会怎么测场景设计题是整场笔试的重头戏。可以说这道题回答得好不好直接决定你能不能进面。题目描述非常简单给定一个手机号验证码登录功能支持图形验证码请设计测试用例并说明你的测试优先级。这道题看起来是送分题但每年都有很多人栽在这里。问题出在大多数人只会列TestCase列表比如“输入正确手机号和验证码登录成功”“输入错误验证码提示错误”“图形验证码过期提示重新获取”然后就没有然后了。这种回答只能拿基础分。高分回答需要体现三点分层思维、风险思维、可执行思维。我的分层框架是这样的功能层正常流程、异常流程、中断恢复比如登录过程中网络断开再恢复接口层验证码发送接口的频控、手机号格式校验、验证码校验次数限制、登录Token有效期兼容层不同系统版本、不同浏览器/WebView、弱网环境安全层验证码是否在日志中泄露、图形验证码是否可以OCR识别绕过、暴力破解是否受限性能层并发请求时验证码发送是否超时、登录接口响应时间是否在可接受范围然后针对每一层再展开具体的测试点。比如在“验证码校验次数限制”这个点我会写同一手机号在30秒内是否限制发送短信验证码错误输入超过5次是否要求重新获取图形验证码连续输错是否触发锁定策略锁定时间是否合理锁定后是否仍然可以通过别的接口绕过。这种设计之所以好是因为它把单个功能拆成了多个维度而且每个维度都有可执行的边界条件。面试官看到这种回答会觉得你是一个有系统思维的测试工程师而不是一个只会点点点的执行者。2.3 手写代码题测试人员也要会写生产级代码提前批笔试的代码题难度接近于LeetCode简单到中等但有一道题非常有意思——它要求你实现一个“简易的验证码校验器”输入参数是手机号、验证码、过期时间输出是校验结果。看起来很简单但有几个隐藏考点是否处理了手机号的边界情况空字符串、非数字、长度不对、国家区号是否处理了验证码为空、长度不一致、含非数字字符的情况是否处理了过期时间的边界刚刚过期、刚好在有效期最后一毫秒返回值是否有明确的状态码和错误信息而不是只返回true/false代码是否简洁、可读、易于写单元测试我当时花了几分钟写了第一版然后立刻发现问题我没有处理验证码被篡改但仍在校验时间内的场景。这个场景虽然在函数内部很难模拟但在真实系统中很常见——比如验证码存储过期但缓存未清干净。所以在代码里我特意加了一个“存储时间戳”和“当前时间戳”的比较逻辑并且用注释标出边界值的含义。这道题给我的感受是Shopee很看重候选人的工程素养。就算你算法题刷得不够多但只要你把代码写得干净、健壮、可测试分数一定不会低。反过来如果你只追求AC但代码一塌糊涂反而会给面试官留下隐患。3. “逆向”能力在QA笔试中的真实含义现在来说说热搜词里那个“shopee逆向”。我第一次看到这个词的时候脑子里也闪过几个“黑客感”满满的画面。但仔细研究之后我发现它大概率是求职圈子里用来概括Shopee QA笔试风格的一个说法——逆向思维。什么是逆向思维就是不是从“需求是什么、功能该怎么实现”的正向路径出发而是从“如果这里出问题系统会表现出什么现象、原因可能有哪些”的反向路径入手来设计测试策略和定位缺陷。这种能力在QA岗位中非常稀缺因为很多测试人员习惯了“根据需求写用例、按用例执行、提交缺陷”的正向流水线。但真正高效的QA往往是在看到一个新功能的第一时间脑子里就会自动冒出“如果用户输入了超长文本会怎样”“如果服务端返回了空数据会怎样”“如果数据库连接超时了会怎样”这一串逆向假设。然后把这些假设变成测试点再变成用例。这就是逆向思维。3.1 这里的逆向不是破解而是反推与复盘有同学可能看过一些帖子说Shopee笔试有一类“逆向题”要求你根据一段代码或者一个线上事故报告反推出问题根因。我没有遇到真正意义上的“破解类”题目但确实遇到了一道很典型的反推题题目给出以下信息用户反馈在支付成功后订单状态显示为“待付款”而在App重启后状态恢复为“已付款”。请列出可能的原因并设计一个排查方案。这道题拿到手大多数人的第一反应是“这是一个App的本地状态同步问题”。但如果你只答到这个层面就漏掉了非常多的可能性。我的回答分成了三层客户端层本地数据库更新失败、Activity/Fragment状态未刷新、缓存策略导致读到脏数据接口层支付回调推送丢失、客户端请求订单详情接口失败后返回了旧数据、服务端返回了错误的订单状态字段服务端层支付网关回调处理延迟、订单状态机更新失败、数据库事务未提交但返回了成功然后我设计了一个排查顺序先从最简单的App重启后恢复“已付款”这个线索入手推断本地状态不是唯一的判断依据服务端状态大概率正确。因此问题基本锁定在客户端缓存或推送回调处理。接着再去看接口日志确认支付成功后客户端是否有拉取最新订单详情的请求如果有返回什么如果没有则往本地状态同步机制上查。这种从现象倒推、层层缩小范围的思路就是逆向思维的核心。3.2 用输出倒推输入的思考框架如果把逆向思维抽象成一个可以迁移的方法论我常用的框架是四条线第一条线异常输出线。先不看输入只看输出。用户看到了什么错误提示、页面有什么异常展示、接口返回了什么状态码。把这些信息全部列出来。第二条线输入外推线。正常输入是什么用户在真实使用中可能给出哪些异常输入输入边界在哪里输入之间的依赖关系是什么第三条线依赖倒查线。这个功能依赖了哪些下游服务、缓存、数据库、第三方SDK这些依赖任何一个出问题会产生当前看到的输出吗第四条线状态机制线。这个功能是否有状态流转各个状态之间的转换条件是什么是否有可能从一个状态跳变到另一个状态而跳变路径被截断或重复触发用这个框架去拆解任何一个故障都会比“感觉是缓存问题”要扎实很多。笔试中如果能把这四条线展现在答案里面试官很容易get到你的分析能力。3.3 一个实际案例从崩溃日志定位前端还是后端为了让你更直观地理解“逆向”在笔试中的呈现方式我再分享一个我在模拟题里练习过的场景假设App在用户点击“支付”后偶发崩溃崩溃日志显示NullPointerException堆栈指向PaymentConfirmActivity.onCreate()。请问如何判断问题在前端还是后端这里有个常见的误区一看到NullPointerException就说是前端代码问题。实际上这个NullPointerException很可能是一个表象真正的根因可能藏在后端返回的数据里。如果你用逆向思维第一步不是打开代码找空指针而是反向追溯空指针的对象来源。我的排查路径是先看崩溃堆栈中抛异常的对象是什么比如它是一个订单对象还是一个支付配置对象再看这个对象的数据来源是上一个页面通过Intent传过来的还是从本地数据库读取的还是从网络请求后解析得到的如果是网络请求得到的数据那么就去查网络请求的返回字段看该字段在正常情况下是否有值在异常情况下是否可能为null如果后端接口在某种边界条件下比如订单金额为0、支付渠道未配置会返回payment_info: null那么前端在解析时没有做判空处理就会导致NPE所以真正的问题可能是“后端没有做好数据完整性与缺省值兜底”也可能“前端缺乏对异常数据的容错”。两者都有责任但需要根据日志和接口数据来确定主责。这类题在笔试中往往是以“请你给出定位思路”的形式出现考察的就是你遇到线上问题时的第一反应——是抢着背锅还是有条不紊地定位。4. 手写测试用例的黄金模板与现场演示虽然前面已经提到了登录功能的用例设计框架但我觉得有必要单独用一章来说说“手写测试用例”这个笔试必考题。因为这几乎是任何QA笔试都绕不开的坎而很多候选人现场写出来的用例质量和面试官的期望差距明显。我总结了一套“黄金模板”基本可以应对80%的功能用例设计题。这套模板分为两部分用例要素和用例层次。4.1 功能用例的八大要素很多同学在笔试中写用例时只写了“操作步骤”和“预期结果”这是不够的。一套完整、规范、可追踪的功能用例至少应该包含以下八个要素用例编号有规律比如LOGIN_001、LOGIN_002用例标题一句话说明测试点做什么、验证什么前置条件比如已安装App、网络正常、服务端测试环境可用测试数据具体的手机号、验证码、过期时间操作步骤编号列出每一步清晰可执行预期结果具体、可判断最好包含响应内容和状态码实际结果笔试时留空面试时可让候选人判断优先级P0/P1/P2或者高/中/低为什么要有优先级因为在有限的测试时间内不可能执行所有用例。面试官看到你标注了优先级就会觉得你有风险意识。而且优先级的定义也需要说明比如“P0是核心流程阻塞问题不加验证会导致系统不可用”“P1是主要功能偏离需求”“P2是界面体验或轻微缺陷”。4.2 从登录需求现场编写一组合格用例我们以“手机号验证码登录功能”为例现场写一组用例。需求本身很简单但合格用例的价值在于覆盖面和可执行性。用例编号用例标题前置条件测试数据操作步骤预期结果优先级LOGIN_001正确手机号和验证码登录成功测试环境可用图形验证码通过手机号13800001234验证码1234561. 输入正确手机号2. 点击获取验证码3. 输入收到的验证码4. 点击登录页面跳转至首页返回登录成功状态码200P0LOGIN_002验证码错误时登录失败图形验证码通过手机号13800001234验证码9999991. 输入正确手机号2. 获取验证码3. 输入错误验证码4. 点击登录提示“验证码错误”停留在当前页面P0LOGIN_003手机号为空点击登录图形验证码通过手机号为空验证码1234561. 手机号输入框留空2. 点击登录提示“请输入手机号”不请求接口P1LOGIN_004手机号含非数字字符图形验证码通过手机号138-0000-12341. 输入带横线的手机号2. 失去焦点自动过滤非数字或提示格式错误P1LOGIN_005验证码过期后登录已获取验证码并等待超过5分钟手机号13800001234验证码1234561. 获取验证码2. 等待超过6分钟3. 输入原验证码4. 点击登录提示“验证码已过期请重新获取”P1LOGIN_006同一手机号高频请求验证码已登录状态下再触发手机号138000012341. 点击获取验证码2次2. 等待30秒3. 再次点击提示“操作过于频繁请稍后再试”P1LOGIN_007网络中断恢复后登录网络环境可切换手机号13800001234验证码1234561. 输入正确信息2. 点击登录3. 在请求返回前断开网络4. 等待超时后恢复网络提示“网络异常”或恢复后自动重试成功P2这张表虽然只有7条用例但已经覆盖了正常流程、异常校验、过期场景、频控场景、弱网场景。如果笔试时间充裕还可以补充杀掉App后重新打开登录页验证码是否失效、同一验证码能否在多个设备上使用、登录成功后关闭飞行模式再打开是否仍然保持登录、验证码在日志中是否明文输出等。4.3 边界值、等价类、场景法的组合使用很多人学了等价类和边界值但不会用到实际题目中。其实笔试中最给分的点恰恰是你把这些方法组合起来使用的痕迹。比如“验证码有效期”这个需求如果有效期是5分钟那你的测试数据至少应该覆盖边界等于300秒刚好在有效期最后一秒——应该成功边界等于301秒超过有效期1秒——应该失败等价类30秒、3分钟、5分钟内的随机时间——成功等价类6分钟、10分钟——失败同理手机号校验也有边界11位、12位、10位、含区号8613800001234、含空格。把这些数据设计出来在用例中体现面试官一眼就能看出你有测试设计功底。场景法也值得专门提一下。不常见的写法是“主成功场景-备选场景-异常场景”。例如登录的主成功场景是“输入手机号-获取验证码-输入验证码-点击登录-进入首页”。备选场景是“验证码发送后用户主动关闭页面再重新打开继续登录”。异常场景是“图形验证码被遮挡导致无法识别”。把这些场景用文字或流程图的方式表述出来你的答案就完整了。我这里有一个经验笔试中手写用例时尽量在答题的最前面写出你的设计方法和优先级规则然后用表格或列表呈现用例。这样即使你后面的用例不够完美面试官也会觉得你有良好的测试设计习惯而这个习惯远远比具体用例内容更能预测未来的工作表现。5. 线上笔试的踩坑记录与提效技巧回到笔试本身。除了知识储备线上笔试的“临场操作”也会直接影响你的分数。我参加了不少线上笔试Shopee这场的系统体验还不错但还是有几点想吐槽和提醒。5.1 网络与浏览器环境线上笔试最怕的是中途断网。有些同学习惯用Wi-Fi但考场高峰期Wi-Fi可能会波动。我的建议是如果条件允许优先用有线网络连接电脑或者用手机热点作为备用方案。笔试开始前一定要提前检查浏览器兼容性一般会推荐Chrome或者Edge不要用Safari或旧版IE。另外最好把弹窗拦截功能关掉因为在线笔试系统可能会弹出答题确认框、连接检测框被拦截后就可能出状况。我当时遇到的一个坑是系统要求开启摄像头监考但浏览器权限没有提前设置好导致进入考试后前五分钟一直在调试摄像头权限。等真正开始答题已经比预定时间晚了五分钟。虽然总时长不变但心理压力一下就上来了。所以强烈建议你在前一天提前进入模拟测试链接把摄像头、麦克风、屏幕共享权限全部授权一遍不要等到考试当天再临时处理。5.2 时间分配遇到不会的题怎么止损我拿到的这套笔试题量不算特别大但主观题非常耗时间。尤其是手写测试用例那道题如果你真想写得完整至少需要25-30分钟。如果前面客观题纠结太久后面就很容易写不完。我自己的时间分配策略是先快速浏览一遍所有题目标记出每道题的预估用时。客观题每题控制在1分钟以内遇到拿不准的不要死磕先用排除法选出最可能的答案再做一个标记等主观题全部答完后再回来思考。主观题先做自己有把握的比如登录功能用例设计再做需要深入分析的逆向题。代码题放在最后因为代码题容易写high一不留神就会写太久。有一个比较实用的止损技巧如果在主观题上卡住了先把你的思路用关键词或提纲形式写在答题框里。比如说“我认为可能的原因包括客户端、接口、服务端”再简单展开几句。线上笔试的评分很多时候是人工阅览你只要展示了结构性思考就算没有完整答完也能拿到部分分数。千万不要因为想不出完美答案就完全留白。5.3 最后的检查清单交卷前如果还有剩余时间我建议按下面这个清单过一遍代码题是否通过了自己的样例边界值是否覆盖了空输入、超长输入、并发调用用例设计题是否有遗漏的正常流程优先级是否标注清楚客观题中标记的题目是否重新检查过有没有看错“不正确的是”“不属于”这类否定词答题框内有没有粘贴的格式错乱比如原本缩进好的代码变得乱糟糟。是否有网络断线导致的答案未保存在交卷前最好定期点击保存按钮如果系统有。我个人还有一个小习惯写代码题时会在代码注释里简要说明自己的设计思路和测试计划。比如“这里使用了一个缓存机制确保同一验证码在有效期内不会被重复校验失败而锁定”。这种注释虽然不影响代码AC但能让阅卷人看到你的工程思维。有几家公司的面试官后来在面试时提到了我的笔试注释说明他们真的有认真看。另外关于“逆向”这个词我还想多说一句如果你在笔试中看到某个异常场景题尽量别只盯着“功能本身”看。多往上面提到的依赖倒查线和状态机制线想往往能发现隐藏的得分点。这也是我自己在这次笔试中最受益的思路——很多人会写“点击支付按钮后崩溃”的用例但很少有人会写“支付成功后服务端回调丢失”的用例而后者往往才是线上故障的根源。现在回想起来Shopee QA提前批笔试的难度并不在于题有多深而在于它要求你在有限时间内展示出一个QA工程师最核心的素质能把模糊的问题拆解成清晰的测试方案能用逆向思维从表面上合理的现象里发现潜在的风险能在写代码时保持对边界和容错的敏感。这些素质不是临时刷题能刷出来的更多的是平时在做项目、写用例、处理线上问题时的积累。如果你正打算投递这个岗位不妨在笔试前给自己做一次“逆向思维模拟训练”找一个你最近接触过的功能不问“它应该怎么工作”而是问“它在什么情况下会坏、坏了之后会怎样”。把这个问题问透了你离通过笔试就真的不远了。 
长河君 · 2026/8/31 11:28:26 · 阅读 1.2k Shopee QA提前批笔试复盘：逆向思维与测试用例设计实战
1. 投递前需要想清楚的三件事先自报家门我是2024届毕业生参加的是2024年秋招Shopee QA提前批笔试。坦白说投递之前我对Shopee的了解主要停留在电商业务和东南亚市场但对这家公司的QA岗位到底考什么、看重什么心里完全没底。真正做完笔试之后我发现它考察的东西和传统互联网大厂的测开笔试有重叠也有很不一样的地方。如果你也在准备类似岗位这篇文章可以帮你少走很多弯路。先说结论Shopee QA提前批笔试的整体风格偏“实用主义”不考偏题怪题但非常看重你有没有测试思维、边界意识和从现象反推本质的能力。热搜词里的“shopee逆向”也让我印象深刻——不过先别想歪这里说的“逆向”不是破解App、不是逆向工程而是测试圈里常说的“逆向思维”拿到一个问题不从正向实现角度出发而是从输出、现象、异常结果倒推可能的原因和测试点。这个能力在笔试中占了很大的比重后面我会专门展开讲。在投递之前我觉得有三件事值得先想清楚否则容易在笔试中迷失方向。第一QA和测开在Shopee笔试中是不是一回事我的理解是Shopee的QA提前批笔试更偏向“测试工程师”的通用能力底座但对代码有一定要求。如果你以为纯黑盒手工测试就能应付那大概率会翻车。笔试里会出现代码题只是不像开发岗那么侧重算法优化而是考察你能不能写出正确、可扩展、可验证的代码逻辑以及能不能用代码解决测试数据构造、结果校验这类问题。所以投递前至少要把一门编程语言练到能够写清楚函数和类的程度推荐Python或Java。第二提前批和正式批的节奏差异。提前批通常流程更快笔试通过后会有面试面试通过后有机会提前锁定offer。但提前批的笔试时间往往和秋招其他公司撞车。我当时就遇到了两家公司的笔试时间重叠最后不得不在同一时间段内切换两个考试窗口。这种压力下提前对Shopee笔试的题型和时间分配做功课价值就体现出来了。第三你自己的目标岗位方向。Shopee的QA下面可能细分方向不同比如业务质量保障、测试开发工具链、性能测试专项等。提前批笔试大概率是统一卷但你可以在主观题里往自己想去的方向靠。比如我的侧重点是测试开发所以考场上有意识地多写了一些关于自动化测试框架选型和用例设计思路的内容。如果你偏业务测试那就多展示你对业务场景的理解。这一点很关键因为笔试不只是答题更是一次有限范围内的自我展示。2. 笔试原题复盘从题型看考察逻辑虽然严格来说每个候选人拿到的题目可能略有不同但从我这一批的反馈来看题型结构相对稳定。整体分为三块客观题选择题/判断题、场景设计题、手写代码题。下面我凭记忆做一个复盘重点不是贴原题而是拆解每类题背后的考察逻辑这样你就算遇到不同的题目也能知道怎么应对。2.1 客观题里的测试概念比想象中更“抠细节”客观题部分大概覆盖了这些知识点软件测试生命周期、缺陷生命周期、白盒测试与黑盒测试的区别、静态测试与动态测试、回归测试策略、等价类划分、边界值分析、判定表、场景法、因果图、测试覆盖率语句覆盖、分支覆盖、条件覆盖、路径覆盖、敏捷测试和DevOps中的测试角色、API测试和UI测试的差异。听起来都是教材内容但Shopee的出题风格不是直接问“什么是边界值”而是给一个具体场景让你选哪个测试用例最能发现某个缺陷。比如有一类题很典型给出一段函数问下面哪组测试数据能覆盖分支条件组合的最大比例。这种题就需要你真正理解覆盖率的计算而不是背概念。我印象比较深的一道题是关于“缺陷密度”的。题目描述了一个团队在迭代结束时统计到每千行代码缺陷数为5问你如何评价这个数字。选项包括质量很好、质量不好、无法仅凭这个数字判断、需要结合测试用例数和代码复杂度综合判断。正确答案显然是“无法仅凭这个数字判断”。这道题看似简单但很多人会掉进“数字越低越好”的直觉陷阱。这说明Shopee考察的是质量度量思维而不仅仅是知识点本身。2.2 场景设计题给一个登录功能你会怎么测场景设计题是整场笔试的重头戏。可以说这道题回答得好不好直接决定你能不能进面。题目描述非常简单给定一个手机号验证码登录功能支持图形验证码请设计测试用例并说明你的测试优先级。这道题看起来是送分题但每年都有很多人栽在这里。问题出在大多数人只会列TestCase列表比如“输入正确手机号和验证码登录成功”“输入错误验证码提示错误”“图形验证码过期提示重新获取”然后就没有然后了。这种回答只能拿基础分。高分回答需要体现三点分层思维、风险思维、可执行思维。我的分层框架是这样的功能层正常流程、异常流程、中断恢复比如登录过程中网络断开再恢复接口层验证码发送接口的频控、手机号格式校验、验证码校验次数限制、登录Token有效期兼容层不同系统版本、不同浏览器/WebView、弱网环境安全层验证码是否在日志中泄露、图形验证码是否可以OCR识别绕过、暴力破解是否受限性能层并发请求时验证码发送是否超时、登录接口响应时间是否在可接受范围然后针对每一层再展开具体的测试点。比如在“验证码校验次数限制”这个点我会写同一手机号在30秒内是否限制发送短信验证码错误输入超过5次是否要求重新获取图形验证码连续输错是否触发锁定策略锁定时间是否合理锁定后是否仍然可以通过别的接口绕过。这种设计之所以好是因为它把单个功能拆成了多个维度而且每个维度都有可执行的边界条件。面试官看到这种回答会觉得你是一个有系统思维的测试工程师而不是一个只会点点点的执行者。2.3 手写代码题测试人员也要会写生产级代码提前批笔试的代码题难度接近于LeetCode简单到中等但有一道题非常有意思——它要求你实现一个“简易的验证码校验器”输入参数是手机号、验证码、过期时间输出是校验结果。看起来很简单但有几个隐藏考点是否处理了手机号的边界情况空字符串、非数字、长度不对、国家区号是否处理了验证码为空、长度不一致、含非数字字符的情况是否处理了过期时间的边界刚刚过期、刚好在有效期最后一毫秒返回值是否有明确的状态码和错误信息而不是只返回true/false代码是否简洁、可读、易于写单元测试我当时花了几分钟写了第一版然后立刻发现问题我没有处理验证码被篡改但仍在校验时间内的场景。这个场景虽然在函数内部很难模拟但在真实系统中很常见——比如验证码存储过期但缓存未清干净。所以在代码里我特意加了一个“存储时间戳”和“当前时间戳”的比较逻辑并且用注释标出边界值的含义。这道题给我的感受是Shopee很看重候选人的工程素养。就算你算法题刷得不够多但只要你把代码写得干净、健壮、可测试分数一定不会低。反过来如果你只追求AC但代码一塌糊涂反而会给面试官留下隐患。3. “逆向”能力在QA笔试中的真实含义现在来说说热搜词里那个“shopee逆向”。我第一次看到这个词的时候脑子里也闪过几个“黑客感”满满的画面。但仔细研究之后我发现它大概率是求职圈子里用来概括Shopee QA笔试风格的一个说法——逆向思维。什么是逆向思维就是不是从“需求是什么、功能该怎么实现”的正向路径出发而是从“如果这里出问题系统会表现出什么现象、原因可能有哪些”的反向路径入手来设计测试策略和定位缺陷。这种能力在QA岗位中非常稀缺因为很多测试人员习惯了“根据需求写用例、按用例执行、提交缺陷”的正向流水线。但真正高效的QA往往是在看到一个新功能的第一时间脑子里就会自动冒出“如果用户输入了超长文本会怎样”“如果服务端返回了空数据会怎样”“如果数据库连接超时了会怎样”这一串逆向假设。然后把这些假设变成测试点再变成用例。这就是逆向思维。3.1 这里的逆向不是破解而是反推与复盘有同学可能看过一些帖子说Shopee笔试有一类“逆向题”要求你根据一段代码或者一个线上事故报告反推出问题根因。我没有遇到真正意义上的“破解类”题目但确实遇到了一道很典型的反推题题目给出以下信息用户反馈在支付成功后订单状态显示为“待付款”而在App重启后状态恢复为“已付款”。请列出可能的原因并设计一个排查方案。这道题拿到手大多数人的第一反应是“这是一个App的本地状态同步问题”。但如果你只答到这个层面就漏掉了非常多的可能性。我的回答分成了三层客户端层本地数据库更新失败、Activity/Fragment状态未刷新、缓存策略导致读到脏数据接口层支付回调推送丢失、客户端请求订单详情接口失败后返回了旧数据、服务端返回了错误的订单状态字段服务端层支付网关回调处理延迟、订单状态机更新失败、数据库事务未提交但返回了成功然后我设计了一个排查顺序先从最简单的App重启后恢复“已付款”这个线索入手推断本地状态不是唯一的判断依据服务端状态大概率正确。因此问题基本锁定在客户端缓存或推送回调处理。接着再去看接口日志确认支付成功后客户端是否有拉取最新订单详情的请求如果有返回什么如果没有则往本地状态同步机制上查。这种从现象倒推、层层缩小范围的思路就是逆向思维的核心。3.2 用输出倒推输入的思考框架如果把逆向思维抽象成一个可以迁移的方法论我常用的框架是四条线第一条线异常输出线。先不看输入只看输出。用户看到了什么错误提示、页面有什么异常展示、接口返回了什么状态码。把这些信息全部列出来。第二条线输入外推线。正常输入是什么用户在真实使用中可能给出哪些异常输入输入边界在哪里输入之间的依赖关系是什么第三条线依赖倒查线。这个功能依赖了哪些下游服务、缓存、数据库、第三方SDK这些依赖任何一个出问题会产生当前看到的输出吗第四条线状态机制线。这个功能是否有状态流转各个状态之间的转换条件是什么是否有可能从一个状态跳变到另一个状态而跳变路径被截断或重复触发用这个框架去拆解任何一个故障都会比“感觉是缓存问题”要扎实很多。笔试中如果能把这四条线展现在答案里面试官很容易get到你的分析能力。3.3 一个实际案例从崩溃日志定位前端还是后端为了让你更直观地理解“逆向”在笔试中的呈现方式我再分享一个我在模拟题里练习过的场景假设App在用户点击“支付”后偶发崩溃崩溃日志显示NullPointerException堆栈指向PaymentConfirmActivity.onCreate()。请问如何判断问题在前端还是后端这里有个常见的误区一看到NullPointerException就说是前端代码问题。实际上这个NullPointerException很可能是一个表象真正的根因可能藏在后端返回的数据里。如果你用逆向思维第一步不是打开代码找空指针而是反向追溯空指针的对象来源。我的排查路径是先看崩溃堆栈中抛异常的对象是什么比如它是一个订单对象还是一个支付配置对象再看这个对象的数据来源是上一个页面通过Intent传过来的还是从本地数据库读取的还是从网络请求后解析得到的如果是网络请求得到的数据那么就去查网络请求的返回字段看该字段在正常情况下是否有值在异常情况下是否可能为null如果后端接口在某种边界条件下比如订单金额为0、支付渠道未配置会返回payment_info: null那么前端在解析时没有做判空处理就会导致NPE所以真正的问题可能是“后端没有做好数据完整性与缺省值兜底”也可能“前端缺乏对异常数据的容错”。两者都有责任但需要根据日志和接口数据来确定主责。这类题在笔试中往往是以“请你给出定位思路”的形式出现考察的就是你遇到线上问题时的第一反应——是抢着背锅还是有条不紊地定位。4. 手写测试用例的黄金模板与现场演示虽然前面已经提到了登录功能的用例设计框架但我觉得有必要单独用一章来说说“手写测试用例”这个笔试必考题。因为这几乎是任何QA笔试都绕不开的坎而很多候选人现场写出来的用例质量和面试官的期望差距明显。我总结了一套“黄金模板”基本可以应对80%的功能用例设计题。这套模板分为两部分用例要素和用例层次。4.1 功能用例的八大要素很多同学在笔试中写用例时只写了“操作步骤”和“预期结果”这是不够的。一套完整、规范、可追踪的功能用例至少应该包含以下八个要素用例编号有规律比如LOGIN_001、LOGIN_002用例标题一句话说明测试点做什么、验证什么前置条件比如已安装App、网络正常、服务端测试环境可用测试数据具体的手机号、验证码、过期时间操作步骤编号列出每一步清晰可执行预期结果具体、可判断最好包含响应内容和状态码实际结果笔试时留空面试时可让候选人判断优先级P0/P1/P2或者高/中/低为什么要有优先级因为在有限的测试时间内不可能执行所有用例。面试官看到你标注了优先级就会觉得你有风险意识。而且优先级的定义也需要说明比如“P0是核心流程阻塞问题不加验证会导致系统不可用”“P1是主要功能偏离需求”“P2是界面体验或轻微缺陷”。4.2 从登录需求现场编写一组合格用例我们以“手机号验证码登录功能”为例现场写一组用例。需求本身很简单但合格用例的价值在于覆盖面和可执行性。用例编号用例标题前置条件测试数据操作步骤预期结果优先级LOGIN_001正确手机号和验证码登录成功测试环境可用图形验证码通过手机号13800001234验证码1234561. 输入正确手机号2. 点击获取验证码3. 输入收到的验证码4. 点击登录页面跳转至首页返回登录成功状态码200P0LOGIN_002验证码错误时登录失败图形验证码通过手机号13800001234验证码9999991. 输入正确手机号2. 获取验证码3. 输入错误验证码4. 点击登录提示“验证码错误”停留在当前页面P0LOGIN_003手机号为空点击登录图形验证码通过手机号为空验证码1234561. 手机号输入框留空2. 点击登录提示“请输入手机号”不请求接口P1LOGIN_004手机号含非数字字符图形验证码通过手机号138-0000-12341. 输入带横线的手机号2. 失去焦点自动过滤非数字或提示格式错误P1LOGIN_005验证码过期后登录已获取验证码并等待超过5分钟手机号13800001234验证码1234561. 获取验证码2. 等待超过6分钟3. 输入原验证码4. 点击登录提示“验证码已过期请重新获取”P1LOGIN_006同一手机号高频请求验证码已登录状态下再触发手机号138000012341. 点击获取验证码2次2. 等待30秒3. 再次点击提示“操作过于频繁请稍后再试”P1LOGIN_007网络中断恢复后登录网络环境可切换手机号13800001234验证码1234561. 输入正确信息2. 点击登录3. 在请求返回前断开网络4. 等待超时后恢复网络提示“网络异常”或恢复后自动重试成功P2这张表虽然只有7条用例但已经覆盖了正常流程、异常校验、过期场景、频控场景、弱网场景。如果笔试时间充裕还可以补充杀掉App后重新打开登录页验证码是否失效、同一验证码能否在多个设备上使用、登录成功后关闭飞行模式再打开是否仍然保持登录、验证码在日志中是否明文输出等。4.3 边界值、等价类、场景法的组合使用很多人学了等价类和边界值但不会用到实际题目中。其实笔试中最给分的点恰恰是你把这些方法组合起来使用的痕迹。比如“验证码有效期”这个需求如果有效期是5分钟那你的测试数据至少应该覆盖边界等于300秒刚好在有效期最后一秒——应该成功边界等于301秒超过有效期1秒——应该失败等价类30秒、3分钟、5分钟内的随机时间——成功等价类6分钟、10分钟——失败同理手机号校验也有边界11位、12位、10位、含区号8613800001234、含空格。把这些数据设计出来在用例中体现面试官一眼就能看出你有测试设计功底。场景法也值得专门提一下。不常见的写法是“主成功场景-备选场景-异常场景”。例如登录的主成功场景是“输入手机号-获取验证码-输入验证码-点击登录-进入首页”。备选场景是“验证码发送后用户主动关闭页面再重新打开继续登录”。异常场景是“图形验证码被遮挡导致无法识别”。把这些场景用文字或流程图的方式表述出来你的答案就完整了。我这里有一个经验笔试中手写用例时尽量在答题的最前面写出你的设计方法和优先级规则然后用表格或列表呈现用例。这样即使你后面的用例不够完美面试官也会觉得你有良好的测试设计习惯而这个习惯远远比具体用例内容更能预测未来的工作表现。5. 线上笔试的踩坑记录与提效技巧回到笔试本身。除了知识储备线上笔试的“临场操作”也会直接影响你的分数。我参加了不少线上笔试Shopee这场的系统体验还不错但还是有几点想吐槽和提醒。5.1 网络与浏览器环境线上笔试最怕的是中途断网。有些同学习惯用Wi-Fi但考场高峰期Wi-Fi可能会波动。我的建议是如果条件允许优先用有线网络连接电脑或者用手机热点作为备用方案。笔试开始前一定要提前检查浏览器兼容性一般会推荐Chrome或者Edge不要用Safari或旧版IE。另外最好把弹窗拦截功能关掉因为在线笔试系统可能会弹出答题确认框、连接检测框被拦截后就可能出状况。我当时遇到的一个坑是系统要求开启摄像头监考但浏览器权限没有提前设置好导致进入考试后前五分钟一直在调试摄像头权限。等真正开始答题已经比预定时间晚了五分钟。虽然总时长不变但心理压力一下就上来了。所以强烈建议你在前一天提前进入模拟测试链接把摄像头、麦克风、屏幕共享权限全部授权一遍不要等到考试当天再临时处理。5.2 时间分配遇到不会的题怎么止损我拿到的这套笔试题量不算特别大但主观题非常耗时间。尤其是手写测试用例那道题如果你真想写得完整至少需要25-30分钟。如果前面客观题纠结太久后面就很容易写不完。我自己的时间分配策略是先快速浏览一遍所有题目标记出每道题的预估用时。客观题每题控制在1分钟以内遇到拿不准的不要死磕先用排除法选出最可能的答案再做一个标记等主观题全部答完后再回来思考。主观题先做自己有把握的比如登录功能用例设计再做需要深入分析的逆向题。代码题放在最后因为代码题容易写high一不留神就会写太久。有一个比较实用的止损技巧如果在主观题上卡住了先把你的思路用关键词或提纲形式写在答题框里。比如说“我认为可能的原因包括客户端、接口、服务端”再简单展开几句。线上笔试的评分很多时候是人工阅览你只要展示了结构性思考就算没有完整答完也能拿到部分分数。千万不要因为想不出完美答案就完全留白。5.3 最后的检查清单交卷前如果还有剩余时间我建议按下面这个清单过一遍代码题是否通过了自己的样例边界值是否覆盖了空输入、超长输入、并发调用用例设计题是否有遗漏的正常流程优先级是否标注清楚客观题中标记的题目是否重新检查过有没有看错“不正确的是”“不属于”这类否定词答题框内有没有粘贴的格式错乱比如原本缩进好的代码变得乱糟糟。是否有网络断线导致的答案未保存在交卷前最好定期点击保存按钮如果系统有。我个人还有一个小习惯写代码题时会在代码注释里简要说明自己的设计思路和测试计划。比如“这里使用了一个缓存机制确保同一验证码在有效期内不会被重复校验失败而锁定”。这种注释虽然不影响代码AC但能让阅卷人看到你的工程思维。有几家公司的面试官后来在面试时提到了我的笔试注释说明他们真的有认真看。另外关于“逆向”这个词我还想多说一句如果你在笔试中看到某个异常场景题尽量别只盯着“功能本身”看。多往上面提到的依赖倒查线和状态机制线想往往能发现隐藏的得分点。这也是我自己在这次笔试中最受益的思路——很多人会写“点击支付按钮后崩溃”的用例但很少有人会写“支付成功后服务端回调丢失”的用例而后者往往才是线上故障的根源。现在回想起来Shopee QA提前批笔试的难度并不在于题有多深而在于它要求你在有限时间内展示出一个QA工程师最核心的素质能把模糊的问题拆解成清晰的测试方案能用逆向思维从表面上合理的现象里发现潜在的风险能在写代码时保持对边界和容错的敏感。这些素质不是临时刷题能刷出来的更多的是平时在做项目、写用例、处理线上问题时的积累。如果你正打算投递这个岗位不妨在笔试前给自己做一次“逆向思维模拟训练”找一个你最近接触过的功能不问“它应该怎么工作”而是问“它在什么情况下会坏、坏了之后会怎样”。把这个问题问透了你离通过笔试就真的不远了。