测试开发工程师笔试题解析：考点、策略与实战技巧

1. 拿到试卷先别急着做题：这套笔试卷的命题逻辑

贝壳找房春招的测试开发工程师笔试卷，我前前后后帮好几个学弟学妹复盘过，这套“笔试卷2”在牛客和各类面经里被讨论的次数不算少。很多人一上来就急着刷选择题，结果前面的客观题纠结太久，后面的编程题和用例设计题只能草草收场。其实测试开发工程师的笔试，和普通后端开发的笔试有本质区别：后端笔试更看重算法和数据结构的熟练度，而测试开发的卷子通常想在一张卷子里同时看到你的代码能力、测试设计能力、系统排查能力和业务理解能力。

贝壳这类房产交易平台，业务链路比一般电商还要复杂一些——房源、经纪人、用户、带看、签约、贷款、售后，每个环节都有大量状态流转和异常场景。所以它的测试开发笔试题往往不是单纯背八股，而是会穿插一些贴近业务的场景题。比如给你一个搜索房源的输入框，让你设计测试用例；或者给你一段线上用户反馈“房源详情页打开很慢”，让你写排查思路。这些东西没有标准答案，但答题的逻辑和覆盖面，面试官一眼就能看出来你有没有真实接触过测试工作。

我的建议是：拿到试卷后，先花两到三分钟把整张卷子从头到尾扫一遍，标出哪些题是必拿分的基础题，哪些题需要写代码，哪些题是开放性的场景设计题。然后按“编程题 + 用例设计题 -> 客观题 -> 问答题”的顺序来做。为什么这么排？因为编程题和用例设计题分值高、区分度大，而且需要在头脑清醒的时候完成；客观题就算放到后面，靠感觉也能蒙对不少。很多人的教训是，前面十几道单选题磨了四十分钟，最后编程题只剩十分钟，随便写了几行没跑通的代码就交了，这种丢分方式特别可惜。

2. 网络协议与Linux命令：客观题里的高频考点和易错点

2.1 HTTP状态码：别只背数字，要理解业务语义

贝壳这套卷子的客观题里，HTTP状态码几乎是必考的。但考的往往不是“503代表什么”这种死记硬背，而是让你在具体的测试场景里判断这个返回码是否合理。

我见过不少候选人，能背出 200、301、404、500，但一问“401和403有什么区别”，就开始含糊。401是未认证，意思是“我不知道你是谁，请先登录”；403是禁止访问，意思是“我知道你是谁，但你没权限看这个东西”。这两个状态码在接口测试里特别容易混淆，尤其是权限系统设计不严谨的后端，经常把没有权限的请求错误地返回成401。所以答题时不要只写状态码数字，最好把对应的业务场景也写出来，比如“token过期返回401，前端应该跳转登录页；普通用户访问经纪人后台返回403，前端应该提示无权限”。

还有一个高频点是301和302的区别。301是永久重定向，302是临时重定向。在房产App里，PC端老链接跳转新的房源详情页，如果做的是301，搜索引擎会更新索引；如果做的是302，抓取器会认为只是临时跳转。测试工程师在验证跳转类需求时，一定要用curl加 -I 参数看响应头，别只在浏览器地址栏里看最终结果，因为浏览器会自动跟随重定向，你根本看不到中间那层返回码。

2.2 GET和POST：本质上不是“参数位置”的区别

很多人讲GET和POST的区别，只会说“GET参数在URL上，POST参数在body里”。这话没错，但不完整。在测试场景里，更重要的差异是这几个：

GET是幂等的，POST不是。所以同一个搜索请求，用户刷新两次，结果应该一样；但同一个支付请求，如果误用了GET，用户刷新两次就可能出现两笔订单。这正是测试用例设计时需要考虑的点：支付、下单、转账这类写操作，一定要断言接口只允许POST，并且后端要做幂等处理。GET请求会被浏览器、代理服务器缓存，POST一般不会；所以涉及敏感数据的查询，不应该通过URL传参，否则会在浏览器历史、日志系统里留下痕迹。我在实际接口测试中还遇到过一种情况：GET参数太长，超过某些代理服务器的限制直接返回414，而POST就没有这个问题。所以在做兼容性测试时，要考虑不同网关对URL长度的限制。

2.3 TCP三次握手和DNS解析：基础题里的坑

客观题里如果出现TCP三次握手，无非是考“为什么需要第三次”。这话要从连接可靠性的角度答：第三次握手是为了让服务端确认客户端收到了自己的SYN+ACK，防止因为网络延迟导致客户端已经放弃连接，而服务端还在傻等，从而占用大量半连接资源。这本质上是通信双方对初始序号达成一致的过程，测试中遇到连接建立缓慢或大量超时，往往就和半连接队列溢出有关。

DNS解析也是一个容易被忽略的考点。现在很多公司做了多活机房和智能DNS，同一个域名在不同网络环境下解析出来的IP可能不一样。测试同学在排查“为什么我这边能访问，用户那边不能访问”时，第一件事就是对比两边的DNS解析结果。我记得有一次线上反馈App某个图片加载不出来，最后定位是DNS解析到了已经下线的旧机房IP。所以笔试里如果问“域名解析流程是什么”，你要按完整链路答：浏览器缓存、操作系统hosts文件、本地DNS服务器、根DNS服务器、顶级域服务器、权威服务器，每一层都可能命中缓存，每一层都可能出问题。

2.4 Linux命令：用真实的排查场景来记

Linux命令的考察，贝壳这套卷子大概率不会只让你写“如何查看CPU使用率”这种傻白甜问题，而是会结合日志文件，让你统计某个状态码出现的次数、找出某个时间段的错误日志。

下面是我整理的一套常用命令对照表，基本覆盖测试开发笔试里最常出现的命令场景。

很多人会忽略空文件名、空格、特殊字符对shell命令的影响，这在笔试里可能看不出来，但在实际工作中特别重要。比如统计日志中有没有包含“status=1”的行，直接用grep "status=1"没问题，但如果日志里还有“status=10”，也会被一起匹配出来，这时就需要用 grep "status=1[^0-9]" 这样的正则来收口。测试开发工程师写命令，一定要对边界条件敏感，这跟写代码是一个道理。

3. SQL与数据查询题：连表、聚合和索引是重头戏

3.1 手写SQL的常见陷阱

贝壳这类房产平台，业务数据天然就是多表关联的，所以笔试卷里SQL题几乎是必考。我看到的常见考法有三种：一是单纯查询，给你几张业务表，让你查出某类数据；二是统计类查询，让你按城市、按时间维度做聚合；三是优化类问题，给你一条执行很慢的SQL，让你分析原因并优化。

先说一个最容易扣分的点：ON后面的连接条件写错，导致结果集膨胀。很多人在写多表连接时，只关注要查询的字段，却忘了每张表的过滤条件应该放在哪里。内连接时，把过滤条件写在ON和WHERE里，结果通常一样；但左连接时，如果过滤条件写在ON里，会保留左表所有记录，写在WHERE里则会把不满足条件的左表记录也过滤掉。这个区别在统计“每个城市有多少有效房源”这样的题目里非常关键。

举一个我复盘时常见的题目：有两张表，house（房源表）和 city（城市表），house 里有 city_id 和 status 字段，status=1 表示在售。如果要统计“每个城市在售房源数大于100的城市，按数量降序输出”，SQL可以这样写：

SELECT c.city_name, COUNT(h.id) AS house_cnt FROM city c LEFT JOIN house h ON c.id = h.city_id AND h.status = 1 GROUP BY c.city_name HAVING house_cnt > 100 ORDER BY house_cnt DESC;

这里要注意几点：COUNT(h.id) 不会统计NULL记录，所以如果城市下没有在售房源，结果是0而不是1；GROUP BY的字段不是h.city_id，而是c.city_name，否则某些数据库会在 only_full_group_by 模式下直接报错；HAVING是在分组后才过滤，不能写成 WHERE house_cnt > 100。

3.2 索引失效：不会查explain就等于没答到点上

SQL题的第二问，通常是“这条查询很慢，怎么优化”。很多人的第一反应是“加索引”，但加索引之后还有一个坑：如果查询写法不正确，索引照样失效。

最常见的失效场景包括：在索引列上使用函数，比如 WHERE DATE(create_time) = '2023-04-01'，哪怕 create_time 有索引也用不上，正确写法是 WHERE create_time >= '2023-04-01' AND create_time < '2023-04-02'；隐式类型转换，比如手机号字段是varchar，却传入一个整数，数据库可能会放弃索引；LIKE 左模糊，比如 LIKE '%二手房%'，索引失效；OR连接多个条件，如果OR两边的字段不都是索引列，整体可能放弃索引。

笔试里如果给你一条慢SQL，我的答题思路是这样：先讲怎么定位慢SQL，用慢查询日志或者 explain 命令，看 type、key、rows 这些字段；再讲为什么慢，比如全表扫描、数据量太大、返回列过多；最后讲优化方案，包括调整索引、改写SQL、减少返回字段、分页优化、甚至把统计类查询放到离线数仓里。一个完整的排查链路，比一个孤零零的优化方案要值钱得多。

3.3 事务隔离级别：数据一致性问题的理论基础

客观题里如果考数据库，事务的四个隔离级别也是常客。读未提交、读已提交、可重复读、串行化，对应的脏读、不可重复读、幻读。MySQL默认是可重复读，这套理论背起来不难，但你要结合业务来理解，比如房产签约时，用户看到的价格和实际下单价是否可能不一致；优惠券发放时，如何避免超发。

测试开发工程师写SQL的能力，其实不只是写查询语句，而是通过数据的变化验证业务逻辑是否正确。比如支付成功后，订单状态要从未支付变为已支付，余额要扣减，积分要增加，这三件事必须在一个事务里完成。如果只更新了订单状态，余额扣减失败，就会造成超卖或者账实不符，这种问题在测试时一定要构造中间状态去验证。

4. 测试用例设计题：场景覆盖和预期结果比“等价类”三个字更重要

4.1 从登录功能说起：完整用例怎么拆

测试用例设计题是测试开发笔试里区分度最高的题型之一。贝壳这套卷子里大概率会出现一个贴近业务的用例设计题，可能是登录、搜索、下单、优惠券这类通用功能，也可能是带看预约、房源发布这类房产特色功能。很多人一看到“设计登录功能的测试用例”，就只写“输入正确账号密码能登录、输入错误账号密码有提示”，然后结束。这样写，得分基本是零。

一个完整的登录功能用例，应从正常流程、异常流程、边界数据、安全、性能、兼容性、接口层面这样拆下去。我经常会用一个非常细的用例表格来展示什么叫“场景覆盖”：

注意最后一行，很多同学会漏掉“已有登录态继续登录”的场景。这恰恰是实际测试中最容易出现问题的点——token是否覆盖、旧设备是否会退出，这些属于需求文档里没有明确写、但用户一定会遇到的场景。测试用例设计的本质，就是在和“用户可能怎么做”做博弈。

4.2 业务场景建模：搜索、优惠券、支付背后的状态流转

如果用例设计题考到类似“搜索房源”这种业务功能，你要比登录题多走一步：把需求拆成数据状态和页面交互。

搜索框的功能其实很典型：输入关键词、点击搜索、展示列表、点击房源进入详情。但你要考虑的异常包括：关键词为空时点击搜索，是禁用按钮还是提示输入；关键词超过长度限制，是截断还是禁止输入；特殊字符，比如输入“%”、“_”、SQL注入语句，是转义还是直接过滤；搜索结果过多，分页加载时出现重复数据怎么办；搜索无结果时，页面是展示空态还是推荐热门房源；搜索结果的排序逻辑是什么，排序字段变化时是否需要重新请求接口。

优惠券这类题目则更偏状态流转。一张优惠券有未使用、已使用、已过期、已锁定、已退款几个状态，测试用例要覆盖每个状态之间的合法流转，还要防止非法流转，比如已经使用的优惠券能否被再次使用，退款时是否恢复优惠券，过期时间精确到秒时，临界点的判定是否正确。

我比较推荐笔试中采用“三步法”来做用例设计题：第一步，把需求拆成功能点，画出正常流程；第二步，针对每个正常流程分支，列出异常分支和用户可能的误操作；第三步，对涉及数据约束和状态流转的部分，补充边界值、时间边界、并发场景。这样写出来的用例有层次，面试官能看出你脑子里装着一套完整的测试方法论。

4.3 用例设计题的答题模板：写清楚“预期结果”是得分关键

笔试答题和实际工作中写用例不太一样，实际工作可以依赖测试管理工具，笔试则要把用例表格直接写在卷子上。我的习惯是列四列：用例编号、操作步骤、测试数据、预期结果。看起来简单，但很多人写着写着就把“预期结果”省了，只写“点击登录按钮，验证提示是否正确”。什么叫正确？你没说要提示什么文案，面试官没法判断你是不是真的理解需求。

还有一个细节：用例设计题的优先级标注也很重要。P0是最核心的正常流程，P1是主要异常流程，P2是边界和体验类。标注优先级可以帮助面试官看到你的重点判断能力，而不是一字排开二十条用例毫无主次。我见过一个候选人写搜索框用例，每条都写“验证搜索结果是否正确”，面试官问什么叫“正确”，他答不上来。这就是典型的只写了步骤，没有写清楚判定标准。

5. 编程题：边界条件和用例意识才是分水岭

5.1 最容易出现的算法题类型

测试开发工程师笔试里的编程题，难度通常介于“基础数据结构”和“中等算法”之间，很少出现压轴级别的难题。贝壳这套卷子的编程题，比较常见的方向是字符串处理、数组和哈希表、链表、二叉树遍历、排序和二分查找。如果题目稍微绕一点，可能会考 LRU 缓存、版本号比较、括号匹配这类工程中经常遇到的场景。

很多人有一个误区：测试开发工程师的编程题只要写出来就行，不用管性能。这话只对了一半。笔试判卷时，除了功能性，还会看你的时间复杂度是否能过掉测试数据。比如反转链表，用递归和迭代都能写，但递归在链表很长时可能会导致栈溢出，如果你在注释里说明“这里不用递归，因为链表长度可能超过递归深度”，这就是一个很好的测试开发思维。

5.2 一道贴近业务的题目：搜索关键词高亮

我在帮人复盘时，经常拿一道“关键词高亮”的编程题举例。背景非常贴合搜索业务：用户在搜索框输入关键词，前端要把搜索结果中命中的文字加粗。要求实现一个函数，输入原始文本和关键词，输出高亮后的HTML字符串，关键词大小写不敏感。

这道题看着简单，但测试点非常多：关键词为空时，直接返回原文；关键词在文本中重复出现，要全部高亮；多个关键词重叠时，如何避免重复高亮；文本中包含HTML标签时，是否先转义；大小写不敏感；关键词里有正则特殊字符时，直接 re.sub 会报错。一个候选人的代码如果能正确处理这些边界，基本就能拿到高分。

下面是一个可以写在卷子上的参考实现：

import re def highlight(text: str, keyword: str) -> str: if not text or not keyword: return text # 用 re.escape 防止关键词里的正则特殊字符干扰匹配 pattern = re.compile(re.escape(keyword), re.IGNORECASE) # 这里要注意：如果正文里有 < 和 >，应该先做 HTML 转义 escaped = text.replace("&", "&amp;").replace("<", "&lt;").replace(">", "&gt;") # 在转义后的文本里做替换，避免把标签内部的高亮破坏掉 return pattern.sub(lambda m: f"<b>{m.group(0)}</b>", escaped)

写完代码，一定要在后面补一块“测试用例验证”：

• 输入 highlight("hello world", "")，期望返回 "hello world"
• 输入 highlight("HELLO World", "hello")，期望两个单词都加粗，因为大小写不敏感
• 输入 highlight("aaaa", "aa")，期望结果是<b>aa</b><b>aa</b>（注意不要因为正则非贪婪匹配产生间隔）
• 输入 highlight(" ", "script")，期望标签被转义后再高亮，避免XSS

这种“代码 + 测试用例”的答法，就是测试开发工程师笔试卷上的加分姿势。面试官看到你写代码的同时还在考虑XSS和正则特殊字符，会认为你有真实的安全意识和工程思维。

5.3 写代码时的测试思维

除了题目本身，编程题还会考察你的代码鲁棒性。比如函数入参是None、空列表、负数、极大值、浮点数精度问题，这些都要在写代码时提前做好防御。

我记得有一道题是“给定一棵二叉树，返回它的层序遍历结果”。很多人只写了BFS模板，却没有处理根节点为None的情况，直接访问 root.val 就报了AttributeError。还有一道题是“字符串转整数”，需要考虑正负号、前导空格、越界、空字符串、非数字字符。这些边界条件，与其等程序跑挂了再调试，不如在写代码时就直接用多一层判断挡掉。

建议在笔试编程题的答题区，先写一句“思路说明”，再写代码，再写“复杂度分析”，最后写“补充测试用例”。这个结构可以让面试官快速了解你的思考过程。即使代码只跑通了一半，逻辑完整的答题也比闷头写对的代码更容易拿到过程分。

5.4 LRU缓存：测试开发高频数据结构题

LRU缓存是我在测试开发笔试复盘里看到频率极高的一道题。它表面是设计题，其实考的是哈希表加双向链表的组合使用。Python里可以用 collections.OrderedDict 快速实现，但如果在笔试里直接调用现成库，会给人一种没有理解底层原理的感觉。

from collections import OrderedDict class LRUCache: def __init__(self, capacity: int): self.capacity = capacity self.cache = OrderedDict() def get(self, key: int) -> int: if key not in self.cache: return -1 # 移动到末尾表示最近使用 self.cache.move_to_end(key) return self.cache[key] def put(self, key: int, value: int) -> None: if key in self.cache: self.cache.move_to_end(key) self.cache[key] = value if len(self.cache) > self.capacity: # 弹出最久未使用的一项 self.cache.popitem(last=False)

这道题的测试用例非常好写：容量为0的操作，get不存在的key返回-1；put重复key时更新值并调整顺序；容量满后插入新key会淘汰最久未使用的key；get操作会改变淘汰顺序。如果你能把这些测试用例都列出来，比单纯把代码写对更符合测试开发岗位的定位。

6. 自动化与工具题：手写脚本和框架设计的给分逻辑

6.1 接口测试工具题怎么答

贝壳这套卷子的问答部分，大概率会让你讲一讲接口测试的方法或者工具使用。别小看这道题，面试官能从你的回答里判断你是真的做过接口测试，还是只在网上看过教程。

接口测试的核心不是“用Postman发个请求看看返回”，而是断言。很多人测试接口时只看HTTP状态码是200，就认为通过，但200只是网络传输成功，不代表业务成功。接口返回码可能是0表示成功，也可能业务code是10001表示参数错误。所以你要把“业务成功”和“传输成功”分开来断言。用Postman写断言时，通常会写：

pm.test("响应状态码为200", function () { pm.response.to.have.status(200); }); pm.test("业务code为0", function () { var jsonData = pm.response.json(); pm.expect(jsonData.code).to.eql(0); }); pm.test("返回房源列表不为空", function () { var jsonData = pm.response.json(); pm.expect(jsonData.data.list.length).to.be.above(0); });

如果要写一个轻量级的接口自动化框架，Python + requests + pytest 基本是标配。笔试里如果让你画框架结构，我会这样画：config目录放环境配置，api目录放接口封装，cases目录放测试用例，utils目录放通用工具函数，report目录放测试报告。测试数据通过yaml或excel管理，测试结果通过pytest的allure插件生成，最后在Jenkins上定时执行并发送通知。

6.2 UI自动化的关键考点

UI自动化的面试题，通常绕不开元素定位和等待机制。很多人只知道Selenium有八种定位方式，但实际测试中最常用、稳定性最高的仍然是 id。尽量避免用绝对路径的XPath，因为页面结构稍微调整就会挂掉。测试开发笔试里如果考UI自动化设计，更倾向于考PO模式（Page Object），它的核心是“把页面元素定位和操作逻辑从测试用例里分离出来”，让用例只关心业务步骤和断言，不关心页面细节。

等待机制是一个隐含的坑。隐式等待（implicitly_wait）是全局等待，设置一次对后续所有元素查找生效；显式等待（WebDriverWait）是针对某个元素等待特定条件。面试官比较喜欢问“为什么不能用time.sleep固定等待”，答案很简单：固定等待会让用例变慢，而且机器性能不同，等待时间不够时用例可能会随机失败。正确的做法是显式等待配合 expected_conditions，比如元素可见、可点击、出现在DOM中。

6.3 框架设计题：分层不是堆目录

还有一类题目是“如果让你设计一个自动化测试框架，你会怎么设计”。很多人的回答是“要把公共方法封装起来”，这句话太泛了。面试官更想看的是你对可维护性、数据驱动、环境隔离、可扩展性的思考。

一个比较成熟的作答思路是：测试数据与脚本分离，接口地址、账号密码、开关配置放到不同环境的配置文件中；测试用例写成数据驱动形式，用 pytest 的 parametrize 加载数据；断言统一封装，把业务断言和底层断言分开；日志统一记录，每个用例执行时能够清晰看到请求参数、响应结果和报错堆栈；测试报告自动生成，并且失败用例能自动截图或者记录响应数据。

下面是一个简单的 pytest 数据驱动接口测试用例：

import pytest import requests BASE_URL = "https://api.example.com" @pytest.mark.parametrize("keyword, expect_count", [ ("学区房", 10), ("北京", 20), ("", 0), ]) def test_search_house(keyword, expect_count): resp = requests.get(f"{BASE_URL}/house/search", params={"keyword": keyword}) assert resp.status_code == 200 data = resp.json() assert data["code"] == 0 if expect_count == 0: assert data["data"]["total"] == 0 else: assert data["data"]["total"] >= expect_count

这个用例里有几个设计细节值得在答题时说明：keyword为空时期望返回0条，这是合理的业务约束；status_code和业务code分开断言；用例数据写在装饰器里，后续新增数据不需要改代码。如果笔试题让你“设计接口测试用例”，你完全可以把这种结构写上去，面试官会认为你研究过真实的自动化落地方案。

7. 线上问题排查与项目复盘：别把压轴题答成八股文

7.1 用户反馈“页面打不开/打开慢”，你怎么排查

贝壳这类to C平台，线上问题排查题几乎是笔试的标配。问法通常是：“有用户反馈房源详情页打不开了，你怎么排查？”或者“接口响应变慢，你如何定位是网络问题、代码问题还是数据库问题？”

一个合格的测试开发工程师，不应该只停留在“复现Bug”的层面，而要有完整的排查链路。我的作答思路是：先确认影响范围，是单个用户还是全部用户，是特定机型还是所有机型，是特定网络还是所有网络；然后抓包看请求是否发出、响应时间是多少、HTTP状态码是什么；如果是后端问题，看应用日志有没有异常堆栈，看监控系统里接口的RT和错误率是否出现明显上涨；如果接口本身没问题，再查数据库慢查询、Redis缓存命中率、依赖的下游服务是否超时；最后根据根因给出修复建议并设计回归用例。

这个过程很像侦探破案，不能用“查日志”三个字一笔带过。你要能说清楚怎么查日志，比如先 grep 出该用户的请求ID，再根据请求ID去链路追踪系统里找整条调用链，看看时间消耗在哪个环节。这里顺带会考到一个点：一个好的日志系统必须打印“请求ID + 耗时 + 关键参数”，否则排查问题的时候就像大海捞针。

7.2 从笔试题到面试：如何在项目复盘中体现测试价值

笔试通过之后，面试里大概率会追问一个真实的项目经验。这时候很多人容易踩一个坑：把项目描述成一个功能测试的流水账，比如“我负责模块的冒烟测试、回归测试，每天执行用例，提交了Bug”。这种描述没有展现出测试开发工程师的独特价值。

我建议用“问题 -> 动作 -> 结果”的结构来讲项目。比如你发现房源列表的接口在低网速下经常超时，于是写了一个弱网模拟脚本，在Charles里设置3G网络限速，构造了200个并发请求，发现接口在10秒内没有返回的比例高达30%。然后你推动开发做了接口缓存和列表分页优化，优化后超时比例降到5%。这个故事里既有问题意识、有工具能力，也有数据佐证，面试官听完就能直观感受到你的工程能力。

还有一点：面试官很喜欢问“你这个项目里印象最深的一个Bug是什么”。不要选一个改一行代码就能修好的低级Bug，而要选一个需要跨模块排查、最终发现根因很有启发性的Bug。比如曾经有一次商家上传的房源图片在详情页偶现倒置，排查到最后发现是前端读EXIF信息旋转角度时，用了错误的坐标系。这种Bug能同时体现你的耐心、技术深度和业务理解。

7.3 如何通过笔试展现“质量思维”

最后说一个我反复强调的点：测试开发工程师笔试，答案的“标准性”没有“工具性”重要。面试官录用的不是一台知道所有答案的搜索引擎，而是一个能在复杂系统里快速理解需求、发现风险、把质量风险量化表达出来的人。

所以我建议你在做完每一道题时，都问自己三个问题：我的答案有没有覆盖正常流程之外的场景？我的结果有没有明确的判定标准？我的方案有没有考虑成本和收益？这三个问题，其实就是“质量思维”的起点。

我当年春招笔试时，也犯过只顾结果不顾过程的错误，后来才慢慢明白，测试开发这个岗位的笔试，从来不只是在考你会不会写代码，而是在考你会不会像一个真正的工程师那样思考和取舍。如果你能把每个功能都拆成正常、异常、边界三层来想，把每个问题都落到“如何验证、如何度量、如何回归”上，你离一份满意的笔试成绩就不远了。