企业官网建设流程全解析

1. 写在前面：Shopee QA笔试到底在考什么

2024年秋招提前批，我投了Shopee的QA（Quality Assurance，质量保障）方向，拿到笔试通知后说实话有点意外，因为很多人都说QA岗门槛不高，实际上过了笔试才发现，这个岗位筛人一点都不含糊。提前批笔试和正式批最大的区别在于：它不是为了过滤“完全不会的人”，而是在一群基础达标的人里挑出“思维足够细、逻辑足够严谨、抗压能力在线”的那一批。笔试单场时间通常安排在1到1.5小时，题目不多，但每一道都有足够的区分度。

很多人对QA有个误解，觉得就是“点点点”，找个Bug、跑跑回归就完事了。但Shopee的QA笔试，说白了是在考三件事：第一，你对测试理论和用例设计的掌握有没有系统化；第二，你对常用技术栈（数据库、接口、基础算法）的理解能不能落到实际；第三，你能不能快速读题、快速决策、把思路清晰表达出来。尤其是最后一点，笔试里一旦出现开放型题目，阅卷人看的就是你的思维路径，而不是最终那个“正确答案”。

这篇文章不是官方题解，我没有办法拿到原题和标准答案。我最想分享的是：这套笔试背后的考察逻辑是什么、每类题型该怎么准备、哪些地方最容易被扣分。我尽量把能回忆到的题型还原成示例，再配合完整的解题思路，相当于给你搭建一个“笔试复现环境”。准备秋招QA的同学，或者实习想投质量保障方向的，都可以拿来当作一份踩坑经验看。

2. 笔试全貌：题型结构、时间分配和底层逻辑

2.1 提前批和正式批的差异，你得先搞明白

提前批笔试最典型的特征是“时间紧、题量小、筛选狠”。正式批可能分多轮、更偏向全面能力测试，提前批更像是海选：在一批简历看起来都还行的候选人里，用最短的时间把思维方式不合适的人筛出去。所以提前批题目往往不是那种背一背八股就能过的，而是需要你在现场思考的组合型问题。

我当时收到的笔试邮件里，写了在线测评平台、开始时间和截止时间，整体没有给具体的题型说明。真正进入系统之后才发现，题目大概分成这几个模块：基础测试理论题、测试场景设计题、数据库SQL题、一两道逻辑编程题。全英文题目，有些题目选项有中文翻译，但很多核心题干还是英文，英文阅读能力差的话会非常吃亏。

2.2 各题型的大致占比与考察意图

从我的复盘来看，整场笔试中不同模块的权重并不是平均分配的。下面这张表是我根据自己的记忆和和同期同学的交流汇总出来的，不能保证百分百精确，但至少能反映趋势。

有人可能会想，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. 数据库与SQL：QA的基本功，笔试里的“实打实”题目

5.1 为什么QA要考SQL

很多准备QA的同学对SQL不太重视，觉得那是后端工程师的事。但你仔细想想，QA如果要验证一个数据修复是否正确，查看数据是否符合预期，最常用的手段就是写SQL去查。笔试考SQL，查的不是你能不能背出语法，而是你有没有用数据去验证测试结果的意识。

我记得笔试里有一道题是给了两张表，一张是用户表，一张是订单表，要求统计每个用户的订单总金额，并且只显示总金额大于1000的用户，按金额降序排列。这就是非常典型的聚合查询题，核心是GROUP BY、HAVING、ORDER BY三个关键字的配合。

类似的题目我建议大家在准备阶段至少练熟这几种：单表查询、多表连接查询、子查询、聚合函数求总和均值、分组过滤、排序、去重、分页。题目难度不会超过这个范围，但写错一点就可能整题丢分，所以平时一定要亲手在MySQL或SQLite上跑一遍，不要只看题解。

5.2 笔试常考的SQL句式拆解

下面我写一下最典型的“统计用户订单总金额”这个题目，顺手把书写规范也提一下。假设有两个表：

• users（user_id, user_name）
• orders（order_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这个岗位，要的不是“全对”，而是在面对不确定时依然能结构化思考的人。