陈祉伊 · 测试岗面试题库

结构身份 → 一段实习 → 两个项目（一句话各概括）→ 技能栈 → 求职意向。控制在 60–80 秒。

别踩千万别说「因为我代码写得不好」「测试比开发轻松」。这两句直接出局。

参考答案

优点挑一个和岗位强相关的，然后立刻给证据。

「细心 + 有记录习惯。我习惯把每个测试点列成清单，执行一条划一条，因为漏测往往不是因为不会，而是因为忘了。图书借阅项目里我按「借阅数量、归还时间、权限、库存」四类拆了 60 多条用例，就是为了不漏。」

缺点说一个真实但不致命、且已在改善的。

「我目前比较明显的短板是自动化经验偏少，之前的测试主要是手工功能测试。我现在在学 Python 写接口自动化，用 requests + pytest 把校园 APP 的登录和消息接口写成脚本跑起来，也看过 Selenium 的元素定位，但还没到能独立搭框架的程度。」

参考答案

别踩不要说「我想先做测试，以后转产品/转开发」——任何一句「转岗」都会让你出局。

必须先做功课回答里必须出现这家公司具体的东西：产品名、行业、技术栈、规模。空话（「贵公司平台大、发展好」）等于没答。

岗位B（欧哈游，动漫/游戏类，20–99 人，自研小程序 + App）示例：

用 STAR情境、任务、行动、结果，重点在行动和可量化的结果。

参考答案「版本上线前赶进度我完全可以配合，实习的时候有过连着几天跟版本、晚上等开发修完 bug 再复测的情况，我觉得这是测试岗的正常节奏。我抗压的方式是把事情拆小：先列清楚还有多少条用例、多少个待复测的缺陷、哪些是阻塞上线的，按优先级排，心里有数就不慌了。」

不要只答「能」，要给方法论，这样听起来是成熟而不是顺从。

其他 offer有就说有（但别说具体公司名去抬价，除非你确实想比价）；没有就说「目前主要在推进几个方向，还没有到最终确认的阶段」——既不撒谎也不显得没人要。

到岗时间（实习生必答，且是考察重点）

三个词 + 各一个证据，说完就停：

• 较真：看到「保存成功」的提示，我会去数据库里确认那条记录真的写进去了，而不是只看页面。
• 有条理：习惯用清单和表格管理测试点，缺陷描述固定写「环境 / 前置条件 / 步骤 / 实际 / 期望 / 影响范围」六段。
• 愿意沟通：缺陷被判定「不是 bug」时，我会去翻需求文档或者拉产品确认，而不是自己憋着或者直接放弃。

答题结构项目是什么（一句话）→ 我负责的范围 → 我怎么做的（方法）→ 结果（数字）。

他在验证你是否真的会用等价类、边界值，而不是背概念。这题答得好，后面一半的技术题都不用答了。

答题框架先分类，再逐类展开，最后补「非功能」维度。

这题一定要背熟这是你简历上含金量最高的一个点，答好了直接证明「你有安全意识、会用工具、能推动修复」。

完整叙事（按这个顺序讲）：

1. 怎么发现的：我在 Postman 里测消息列表接口时，习惯把登录接口返回的 token 那行先注释掉再发一次，看看服务端有没有做校验。结果发现不带 token 请求，接口照样返回 200，而且返回了消息列表数据。
2. 确认不是误判：我又换了两个账号试，发现 A 账号不带 token 也能拿到数据；再试了消息详情接口，同样能拿到。说明不是某一个接口的问题，是这一批消息接口都缺鉴权。
3. 影响评估：这意味着任何人只要知道接口地址和参数格式，就能拉到别人的消息内容，属于越权访问（未授权访问），严重程度我定的是「严重」，优先级「高」——因为它涉及用户隐私数据泄露，且不需要任何前置条件。
4. 怎么提的缺陷：在禅道里写清楚环境、请求方法、URL、Header（说明未携带 token）、请求体、实际响应（200 + 数据）、期望响应（401 或 403）、影响范围、复现步骤，并附上 Postman 的请求截图。
5. 开发怎么修的：在网关/拦截器层加了统一鉴权，token 缺失或失效直接返回 401；同时把 token 的校验从「只在前端判断」改成「服务端强制校验」。
6. 怎么复测的：回归时我不只测了原来那两个接口，而是把消息模块所有接口都跑了一遍不带 token 的情况，另外补测了「带过期 token」和「带伪造 token」两种，确认都返回 401，才关闭缺陷。同时建议把这类「未授权访问」加进回归清单。

他在验证数字是不是编的。回答必须具体到「模块 + 现象 + 原因」。

安全答法给出分布比例 + 挑 2 个讲透（不要报流水账）：

参考答案

• 怎么选机型：不是越多越好，按「覆盖度」选 —— ① 主流品牌各一台（华为/小米/OPPO/vivo）；② 高低版本系统各一台（如 Android 10 和 Android 14）；③ 不同屏幕分辨率/比例（刘海屏、挖孔屏、平板比例）；④ 条件允许加一台低配机测性能。
• 测什么：安装卸载、启动、页面布局（是否错位/被状态栏遮挡/文字截断）、功能可用性、控件响应、系统权限弹窗（相机、存储、通知）、深色模式、字体放大、横竖屏切换、与系统返回键的交互。
• 工具：真机 + 云测平台（如 Testin、WeTest）批量跑兼容；adb 连真机看日志。
• 结果处理：记录「机型 + 系统版本 + 现象 + 截图/日志」，同一现象在多机型出现就合并成一个缺陷并列出受影响机型。

参考答案「最常用的是按业务主键去查。比如测完登录，我会查用户表看最后登录时间有没有更新；测完消息已读，查消息表看 is_read 字段是不是从 0 变成了 1；测完列表分页，会对比接口返回的 total 和 select count(*) 的结果是否一致。」

可能会让你现场写提前准备这 4 条：

-- 1. 查某个用户的登录信息是否正确落库
SELECT user_id, phone, last_login_time, login_count
FROM t_user WHERE phone = '15940645583';

-- 2. 核对消息已读状态是否更新
SELECT msg_id, user_id, is_read, read_time
FROM t_message WHERE user_id = 1001 ORDER BY create_time DESC;

-- 3. 对比接口返回的总条数与库里的实际条数
SELECT COUNT(*) FROM t_message WHERE user_id = 1001 AND is_deleted = 0;

-- 4. 查有没有重复数据（数据异常排查常用）
SELECT phone, COUNT(*) AS cnt FROM t_user
GROUP BY phone HAVING cnt > 1;

参考

激活（Active） → 测试提交，指派给开发 → 开发确认后改为 已解决（Resolved），并填写解决方案（已修复 / 设计如此 / 重复 / 无法复现 / 延期 / 不予修复）→ 测试回归验证：通过则 关闭（Closed）；不通过则重新 激活并指派回开发。

可能出现的分支：开发认为不是 bug → 转给产品/测试确认；需求变更导致 → 挂起或关闭；版本发布后发现的 → 记录到线上问题清单。

关键区分严重程度（Severity）看影响，优先级（Priority）看要不要马上改，两者不一定一致。

「高严重 + 低优先级」的例子：某个极少使用的老机型上闪退——影响严重（崩溃），但用户量极小，可以排到下个版本修。

「低严重 + 高优先级」的例子：登录页的错别字——不影响功能，但首页第一眼就能看到，上线前必须改。

他在验证你的排查方法论，而不是「我发现了然后交给开发」。

答题模板：分层定位

1. 先确认现象边界：是一直超时还是偶发？单人借还是多人同时借？换了账号/书也一样吗？（排除账号、数据个例）
2. 抓包看请求本身：用 Fiddler 看这条请求的耗时明细、请求体大小、有没有重复请求、网络是否正常。（排除网络和前端）
3. 看服务端：响应是「慢」还是「根本没返回」？如果是 504 且有响应体，说明服务端处理超时；如果一直 pending，可能是连接没释放。
4. 缩小范围：同样的接口，参数简单（只借 1 本）时快，参数复杂（一次借多本）时慢 → 怀疑业务逻辑里有循环查询或大事务。
5. 给出结论：我在并发借阅同一本书时必现，耗时从两百毫秒涨到五秒以上，怀疑是库存扣减时的锁等待或慢 SQL，把对比数据给到开发。

参考答案（按业务规则拆）

参考答案「我按纵向和横向两个方向测。纵向是不同角色：普通用户、管理员、未登录，分别去访问对方的页面和接口，看有没有被拦住。横向是同一角色不同人：用 A 的登录态去请求 B 的借阅记录 id，看能不能拿到——这个如果没做校验就是水平越权。」

具体动作：

• 前端层面：直接输 URL 访问后台页面 → 应该被重定向或提示无权限
• 接口层面：用 Postman 拿普通用户的 token 调管理员的删除图书接口 → 应该返回 403
• 参数层面：把请求里的 userId 改成别人的 → 应该返回无权限或空数据
• 状态层面：退出登录后用旧 token 再请求 → 应该 401

准备 2 个能讲透的（建议就用下面这两个，和你前面讲的技术点呼应）：

• 库存超卖：两个人同时借同一本只剩 1 本的書，都借成功了，库存变成 -1。高危原因：直接造成业务数据错误，且用户已经拿到书，事后修数据成本高。
• 越权查看他人借阅记录：改 URL 里的 id 就能看到别人的借阅历史和手机号。高危原因：隐私泄露。
• （备选）逾期罚金算错：跨月计算时把两个月的天数算成 30 天，导致少收罚金。
• （备选）归还后库存没回补：书还了但库存没加回去，导致后面的人借不到。

怎么定义高危「我的判断标准是三条：会不会导致数据错误、会不会影响核心流程走不通、有没有安全风险。满足任意一条我就标高危。」

你有双端经验，这题必须答得比别人好

他在验证你是不是真的进过公司，而不是挂名实习。

「犯过的错」这题在考反思能力必须有真错，且必须有后来改了什么机制。

参考答案「线上问题和测试阶段不一样，用户反馈往往只有一句『打不开』，信息很少。我的做法是先去捞日志、看有没有对应的报错，再按用户给的机型、时间、账号去复现。」

• 先定级：影响面多大？是所有用户还是个别机型？核心流程还是边缘功能？影响面大就立刻升级给负责人。
• 先止血再定位：能回滚就回滚、能开关就关掉入口，先让用户能用。
• 定位后再修：把复现步骤和日志给研发。
• 事后闭环：问一句「这个场景为什么测试阶段没覆盖到」，把它补进用例库。这是我最看重的一步。

标准答案

1. 需求分析：读需求文档/原型，参加需求评审，找出需求里的歧义、遗漏、不可测的点，产出「测试需求」
2. 测试计划：定范围、策略、资源、排期、风险（谁测什么、什么时候测完）
3. 测试用例设计：用等价类、边界值、场景法、判定表等方法写用例，然后用例评审（测试、开发、产品一起过）
4. 测试环境与数据准备：搭环境、造数据
5. 冒烟测试：提测后先跑主流程
6. 测试执行：按用例执行，记录结果，提交缺陷
7. 缺陷管理与回归：跟踪修复，逐条复测，做多轮回归
8. 测试报告：用例执行率、通过率、缺陷统计与分布、遗留问题与风险、是否可上线的结论
9. 上线验证 + 复盘：发布后线上冒烟，事后复盘漏测原因

七种方法等价类划分、边界值分析、判定表、因果图、场景法（流程分析）、错误推测法、正交实验法。

等价类把输入分成「有效等价类」和「无效等价类」，每一类取一个代表值。目标是少测但不能漏。

边界值错误最容易发生在边界上，所以取边界本身和它两侧的值。

举例：密码 6–20 位

用例编号、所属模块、用例标题、优先级、前置条件、测试数据、操作步骤、预期结果、实际结果、测试人/时间、备注。

好坏的标准（这句能加分）：

• 可执行：换一个人照着步骤也能跑，不需要问作者
• 可判定：预期结果是明确的，「显示正常」不合格，要写「显示『登录成功』并跳转首页」
• 独立：一条用例只验证一个点，失败时能直接定位
• 可复用：能在下个版本回归时直接跑

答题顺序先讲流程，再讲关注点，最后讲工具。

流程：拿到接口文档（URL、方法、参数、返回结构）→ 设计用例 → 在 Postman 里配置环境和变量 → 发请求 → 校验状态码 + 响应体字段 + 数据库 → 异常场景。

关注点（按这个清单说）：

• 正常：必填参数齐全、类型正确，返回是否与文档一致
• 参数校验：必填不传、传空、传 null、类型错（字符串传数字）、超长、特殊字符、SQL 注入字符串
• 鉴权：不传 token、传错误 token、传过期 token
• 业务异常：库存不足、余额不足、重复提交（幂等）
• 边界：分页 page=0、pageSize=1000；金额 0、负数
• 性能：响应时间是否在可接受范围
• 数据一致性：接口返回成功，库里是否真的写进去了

• Cookie：存在浏览器端的一小段数据，每次请求自动带上。本身不安全，可被篡改。
• Session：存在服务端，用 sessionId 关联（sessionId 一般放在 Cookie 里）。服务端有状态，集群下需要共享（如存 Redis）。
• Token（JWT）：服务端签发、客户端保存（Header 或 localStorage），服务端不存状态，靠验签和过期时间校验。适合分布式和多端。

测试视角「我会关注：token 过期后是否跳登录、退出登录后旧 token 是否失效、多端登录是否互踢、token 在请求头还是 URL（放 URL 会留在日志里，有风险）。」

面试只说「会 cd ls」等于不会要说「我用它干什么」：

加分「定位问题时我一般先 tail -f 挂着日志，操作一次页面看日志有没有新报错，再去 grep 关键字找上下文。」

正确结构：承认差距（10%）→ 用经历密度替换年限（60%）→ 用可验证的东西背书（20%）→ 给承诺（10%）

备用弹药（如果对方继续追问）

• 「我实习期间一共执行了多少条用例、提了多少缺陷、复测了多少条」——数字越具体越可信
• 「我可以先做一个试用期，如果一个月内达不到您的预期，我自己会说明」——愿意被验证
• 「我现在每周可以到岗 5 天，能长期实习到毕业，如果双方合适我希望能转正」——解决他们的用工顾虑

他在验证你是不是「拿到需求就照着点」，还是真的会先想清楚。

答题框架：三步

1. 读懂：逐条读需求文档和原型，把业务流程画一遍（谁、在什么条件下、做什么、结果是什么），画不出来说明没读懂。
2. 找问题：重点看四类——歧义（「适当提示」是多长时间）、遗漏（异常情况怎么处理、失败了怎么办）、冲突（和新功能/旧功能有没有矛盾）、不可测（没有明确预期结果就没法判断对错）。
3. 产出：① 一份测试需求/测试点清单（按模块列出要验证什么）；② 一份需求疑问清单，在需求评审会上逐条问清楚，会后邮件/文档留档；③ 一份影响范围分析（这次改动会影响哪些老功能）。

六要素

诚实处理如果没独立写过完整测试计划就直说：「完整计划我没独立写过，但实习时参与过排期，也看过同事的计划，我理解结构是这几块。」——不要编。面试官一追问细节就露馅。

拆解「资材」= 测试资产，包括：

• 用例库：按模块归档、编号规范、可复用，下个版本能直接拿来回归
• 缺陷记录：禅道里的缺陷单、统计、分布
• 测试数据：账号、造数脚本、初始化 SQL
• 环境信息：测试环境地址、版本号、配置说明
• 执行记录：哪条用例什么时候跑的、结果如何、谁跑的（可追溯）

参考答案「我的理解是测试过程要可追溯、可复用。可追溯是指任何一个结论都能查到依据——这个功能测过没有、什么时候测的、谁测的；可复用是指用例、数据、环境这些下个版本还能用，不用每次从零开始。我在项目里会按模块建用例目录，缺陷单写全六要素，测试数据单独存一份说明，这样别人接手也能看明白。」

参考答案「我的习惯是分两层：日常同步和节点汇报。」

• 日常：每天在群里同步一句——今天测了什么模块、执行多少条、提了几个 bug、有没有阻塞。有阻塞当天就抛出来，不憋到最后一天。
• 节点：用例设计完、测试执行过半、上线前，各做一次阶段性汇报。
• 汇报结构：进度（计划 vs 实际）+ 质量（缺陷数量、严重程度分布、是否收敛）+ 风险（哪些没测完、哪些缺陷没修完、会不会影响上线）+ 需要支持（要谁配合做什么）。

六要素 + 两个附加

他在验证你有没有「从执行者到分析者」的意识。

四步法

1. 摸清全貌：先看菜单和页面结构，画出功能地图（一级模块 → 二级功能 → 具体页面）。这一步不求深，求全。
2. 理清业务流：挑核心链路（如「用户注册 → 借书 → 归还」）走一遍，画流程图，标出关键状态和判断条件。业务流程比功能列表更重要，因为 bug 往往出在流程的衔接处。
3. 建立对应关系：把「功能」和「业务规则」对上——这个页面背后有哪些规则（额度、时限、权限）。做成一张功能-规则矩阵，这张表就是以后回归测试的底稿。
4. 标注变更影响：新需求来了，对着这张表判断「这次改动会影响哪几个功能、哪些老功能要回归」。这是梳理老系统最实际的用途。

项目总结四块

• 数据：用例数/执行率/通过率、缺陷总数、按模块和严重程度分布、修复率、平均修复时长、遗留问题
• 结论：本版本质量如何、是否可以上线、遗留风险是什么
• 问题：哪些环节卡住了（提测质量差、需求变更频繁、环境不稳定）
• 改进：每个问题对应一个具体动作（如「提测前要求开发自测并附自测清单」），并指定下版本落地

个人总结「我一般写三件事：这个版本我做得好的、做得不够的、下个版本要改的一个具体习惯。比如上个版本我发现自己的用例在『异常中断』这类场景覆盖不足，下个版本我就在用例模板里加了一栏『中断/异常』强制自己填。」

四步，别跳步

1. 先自查：翻需求文档和原型，确认自己没理解错。有明确依据就直接贴出来（「需求文档 3.2 写的是 X」）。
2. 找第三方：需求没写清楚 → 拉产品确认。产品说按现在这样，那就是需求问题，我把缺陷关掉并备注「产品确认按现设计」；产品说应该是 X，那这就是 bug。
3. 讲影响不讲对错：不说「你做错了」，说「这个情况下用户会看到 XX，可能导致 XX 后果，你看要不要处理」。把问题从「谁对」转成「影响多大」。
4. 留痕 + 升级：达不成一致就先记录（缺陷挂起并写清分歧点），在测试报告里列为「遗留风险」，由负责人决策。不要自己默默吞掉，也不要越级告状。

参考答案：风险驱动

1. 先保核心：按「用户使用频率 × 影响严重程度」排优先级，主流程、支付、登录这类先测，边缘功能和 UI 往后放。
2. 砍范围不砍质量：明确说「这几块这次测不到」，而不是「都测了但都只点了一遍」。
3. 提高效率：把重复性的回归用接口自动化或脚本替代；用等价类减少冗余用例。
4. 提前暴露：在还有时间解决的时候说「按这个进度会漏掉 X 模块」，让团队决定是加人、延期还是砍需求。
5. 记录下来：风险清单写进测试报告，上线后重点监控那部分。

参考答案「我觉得不能只用『提了多少 bug』来衡量，因为 bug 多可能是版本质量差，而不是测试厉害。我更看三个指标：」

• 缺陷逃逸率：上线后发现的缺陷数 ÷（测试阶段 + 上线后发现的总数）。这个低，说明测得住。
• 缺陷有效性：提的缺陷里被开发认可并修复的比例。这个高，说明不是瞎提。
• 回归效率：同样范围的回归，这版用了多久。这个降，说明资产（用例、脚本）在起作用。

「还有一个不太好量化但我很在意的：开发愿不愿意提前找我聊需求。如果他们做之前会问一句『这个你怎么看』，说明测试已经往前站了。」

不要硬编「我测过小程序」很容易被一句「那你用什么工具看的？真机调试怎么开的？」问穿。

诚实 + 迁移 + 已自学，三段式

先讲流程点击登录 → 调 wx.login() 拿 code → 后端用 code + appid + secret 换 openid/session_key → 生成业务 token 返回 → 前端存起来。

再讲测试点

• 首次登录：弹出授权框 → 允许 → 登录成功、信息正确落库
• 拒绝授权：点拒绝后是否还能浏览基础内容？再点登录是否会重新弹？会不会卡死在不允许就进不去的死循环？
• 取消：弹窗直接关掉
• 已授权再次登录：是否免弹窗直接登录
• 在微信设置里删除授权后再进入：是否重新要求授权
• 换设备/换微信号：同一微信在不同手机登录，数据是否同步；不同微信登录是否串号
• code 只能使用一次：重复用同一个 code 请求应该失败
• token 过期后：是否静默刷新或跳登录，不能白屏
• 退出登录后再进：旧 token 是否失效
• 请求头伪造/不带 token 调需要登录的接口 → 应 401

第一步：分清楚三种

第二步：四个核心指标（必须能脱口而出）

• 并发数 / 线程数：同时发请求的用户量
• TPS / QPS：每秒处理的事务数/请求数，衡量处理能力
• 响应时间（RT）：一般看平均、90%、99% 分位（P99 比平均值更能反映真实体验）
• 错误率：失败请求占比，一般要求 < 1% 甚至 0
• 辅助：CPU、内存、磁盘 IO、网络带宽——用来判断瓶颈在哪

第三步：JMeter 怎么做（说出组件顺序）

怎么造弱网① 手机自带网络模拟（部分安卓开发者选项）；② Charles / Fiddler 的限速功能（设置带宽和延迟，模拟 2G/3G/丢包）；③ 专门的弱网工具（如 Network Link Conditioner）；④ 真机进电梯/地下室实测。

测什么

• 加载慢时有没有 loading 提示、有没有骨架屏，用户知不知道在等
• 超时设置是否合理，超时后有没有友好提示和重试入口
• 弱网下重复提交：网络慢用户会连点，会不会下两个单/借两次书
• 弱网切换到 4G/WiFi 时，请求会不会中断、页面会不会白屏
• 弱网下的数据一致性：请求发出去了但响应没回来，实际后端成功了没有

按时间轴答，显得有条理

1. 上线前：核心流程全量回归 + 上一版本线上问题的回归验证 + 兼容性抽查 + 上线检查清单（版本号、开关配置、域名指向、埋点）。
2. 上线时：如果有灰度/白名单，先小范围放量，观察错误率和反馈；准备好回滚方案。
3. 上线后：马上做一轮线上冒烟（用真实账号走主流程），盯日志和告警 30 分钟到 1 小时，看崩溃率、接口错误率。
4. 出问题：先回滚止血，再定位，再修复重发——顺序不能反。

参考答案（用你真实的素材改编）

参考答案「一个人做测试，最怕的是什么都想测、结果什么都没测透。我的做法是：」

• 先定底线：列出「上线绝对不能出问题的功能」，这部分每次必测、测透。
• 建立资产：用例库、冒烟清单、上线检查清单先建起来——一个人的时候，靠流程和文档弥补人手的不足。
• 借力：推动开发自测（提测前跑一遍自测清单）、推动产品在需求阶段把规则写清楚，这些都是不花钱的「测试资源」。
• 提效：把重复的回归用接口自动化或脚本跑，人只做需要判断的部分。
• 管住风险：明确告诉负责人「以现在的人手，这块我保不住，需要你决策」——不要一个人硬扛到上线爆炸。

参考答法（先算清自己的课表再答）

面试前必须做去应用商店/微信搜一下他们的产品，实际用 10 分钟，记下 3 个你觉得可以改进的点。

参考框架「我看了你们的小程序/APP，主要做 XX。我注意到两点：一是 XX 页面的加载有点慢，二是 XX 操作的路径比较长。如果我来测，我会先重点看这块。」

别答「没学过」四个字就结束，也不要吹「我很熟 Selenium」。

参考答案

推荐准备两个（都不难，今天就能写出来）

① 接口自动化小脚本：

import requests, pytest

BASE = "http://test.api.com"

def test_login_success():
    r = requests.post(f"{BASE}/api/login",
                      json={"phone": "13800000000", "pwd": "123456"})
    assert r.status_code == 200
    assert r.json()["code"] == 0
    assert "token" in r.json()["data"]

def test_login_wrong_pwd():
    r = requests.post(f"{BASE}/api/login",
                      json={"phone": "13800000000", "pwd": "wrong"})
    assert r.json()["code"] != 0

def test_message_no_token():
    # 不传 token，期望 401
    r = requests.get(f"{BASE}/api/message/list")
    assert r.status_code == 401

② 一个小工具脚本：比如读 Excel 里的用例数据，批量发请求校验（用 openpyxl + requests），或者批量比对数据库和接口返回的数据。

怎么讲「我写这个是为了解决一个具体问题——回归的时候那几条接口每次都要在 Postman 里手点，我就想能不能一键跑完。功能是能跑了，但写得很粗糙，没有做配置分离，换个环境还得改代码。」——能自嘲代码粗糙，反而显得真实。

正确结构：SQL 通用能力（60%）+ 方言差异（30%）+ 学习动作（10%）

SQLServer vs MySQL 差异速查表（背下来）

假设表结构

t_user(id, name, phone, status)                      -- 用户表
t_book(id, title, category, stock, total)            -- 图书表
t_borrow(id, user_id, book_id, borrow_time, return_time, status)
-- status: 0=借出未还, 1=已归还, 2=逾期

题 1：查询「张三」当前未归还的图书

-- 通用写法（MySQL / SQLServer 都一样）
SELECT u.name, b.title, br.borrow_time
FROM t_borrow br
JOIN t_user u ON br.user_id = u.id
JOIN t_book b ON br.book_id = b.id
WHERE u.name = '张三' AND br.status = 0;

讲思路「三张表要关联，用 JOIN；筛选条件一个是用户姓名、一个是借阅状态，都放在 WHERE 里。」

题 2：统计每个分类的借阅次数，取前 3 名

-- MySQL
SELECT b.category, COUNT(*) AS cnt
FROM t_borrow br JOIN t_book b ON br.book_id = b.id
GROUP BY b.category
ORDER BY cnt DESC
LIMIT 3;

-- SQLServer
SELECT TOP 3 b.category, COUNT(*) AS cnt
FROM t_borrow br JOIN t_book b ON br.book_id = b.id
GROUP BY b.category
ORDER BY cnt DESC;

讲思路「按分类分组 → COUNT 计数 → 按计数倒序 → 取前 3。唯一区别就是 MySQL 用 LIMIT，SQLServer 用 TOP。」（主动指出差异，正好呼应 6.3）

题 3：找出借阅超过 5 本的用户

SELECT u.id, u.name, COUNT(*) AS borrow_cnt
FROM t_borrow br JOIN t_user u ON br.user_id = u.id
GROUP BY u.id, u.name
HAVING COUNT(*) > 5;

讲思路「筛聚合结果要用 HAVING 不能用 WHERE——WHERE 在分组前执行，那时还没有 COUNT 的结果。」这是最常被考的细节。

题 4：找出所有逾期未还的记录（借出超过 30 天）

-- MySQL
SELECT * FROM t_borrow
WHERE status = 0 AND DATEDIFF(NOW(), borrow_time) > 30;

-- SQLServer
SELECT * FROM t_borrow
WHERE status = 0 AND DATEDIFF(DAY, borrow_time, GETDATE()) > 30;

讲思路「注意 DATEDIFF 的参数顺序不一样：MySQL 是 DATEDIFF(结束, 开始) 只用两个参数，SQLServer 是 DATEDIFF(单位, 开始, 结束) 三个参数。这个坑我踩过。」——说出「我踩过」比背文档可信十倍。

JD 已经给了三段结构，顺着说

1. 测试过程：测了什么范围、用了什么方法、多少条用例、执行了多少、在什么环境、什么时间完成。
2. 测试结果：通过率、缺陷总数、按模块分布、按严重程度分布、遗留缺陷清单。
3. 缺陷修复情况：已修复多少、修复率、未修复的原因和计划、复测结果。
4. （加分）结论与建议：是否达到上线标准、存在哪些风险、下个版本建议改进什么。

加分话术「我写报告有个原则：结论先行。第一段就写『本次测试覆盖 XX 模块，执行用例 X 条，通过率 X%，遗留 X 个缺陷，其中 P1 有 X 个，建议 XX』，让别人三十秒能看完重点，细节放后面。」

参考答案：六个维度扫描

再补一句「另外我会做一次反向检查：把需求文档拿出来，逐条对应用例，看有没有哪条需求没有用例覆盖。这比凭感觉判断『应该够了』靠谱。」

例子一：上传头像格式（jpg/png/gif/不支持格式）、大小（刚好 2MB / 2MB+1KB）、尺寸（超大图/1×1 像素）、文件名含中文/特殊字符、上传中断网、上传中取消、同一张图重复上传。

例子二：搜索框空搜索、单个字符、超长字符串（如 1000 字）、特殊字符（'、%、_、emoji）、SQL 注入字符串（' or 1=1 --）、XSS 字符串（<script>）、前后空格是否被处理、无结果时的空状态展示。

例子三：借阅数量（你的项目）上限 5 本：借 4 本可借、借第 5 本可借、借第 6 本应提示超限；还 1 本后额度释放；同时借 2 本时是按总量判断还是逐本判断。

如果没有「系统的培训班我没参加过，但我是按测试的知识体系自己学的——测试理论（流程、方法、用例设计）看书和文档，工具（禅道、Postman、Fiddler）是在项目里用起来的，MySQL 是课程学过加项目里练的。我觉得比培训更有用的是我真的在一个版本里从头跟到尾，踩过『缺陷描述写不清被开发打回』这种坑。」

要点不要为了迎合 JD 编造培训经历，但要证明「自学路径 = 培训内容」。把「理论 + 工具 + 实战」三块都说全，效果等同于培训。

顺序很重要：先解决，再解释，最后复盘

1. 第一时间配合止血：不复现就先看日志和用户反馈，判断影响范围，配合开发回滚或修复。这时候不解释、不甩锅。
2. 事后主动复盘：不等人来问，自己先写清楚——这个问题为什么没被测出来？是需求没写清、用例漏了、环境造不出来、还是时间不够没测到？
3. 给出机制性的改进：不是「我下次注意」，而是「我把这个场景补进了用例库」「我建议这类改动要加一条回归项」。
4. 承认该承认的：如果是我的疏漏，我说是我的问题；如果是需求变更没同步给测试，我说明流程断在哪一环。客观，不揽责也不推责。

这题要「真诚地承认 + 精准地缩小」

原则不说前东家坏话，不显得是被淘汰，给一个「向前走」的理由。

参考「那段实习是三个月的固定实习期，到时间就结束了，不是因为我做得不好。走的时候带我的同事还问我要不要继续，但那时候我要回学校处理课程，就先结束了。这段经历让我确定了自己想做测试，所以现在想找一份能长期做下去的。」

这题在测自我认知答「不知道」显得没想法，答「我没什么问题」显得自大。

参考「如果没录用，我猜最大的可能是经验年限——我这个岗位要求两年，我确实不够，这个我能理解。其次可能是自动化这块，如果团队希望来了就能写脚本，我目前还做不到。但这两点我都在补，如果是因为这个，我希望能有机会用几个月证明一下。」

这题在测方法论，不是知识量

1. 要资料：需求文档、原型、历史用例、上一版的测试报告、缺陷列表（看历史缺陷最快了解系统哪里脆弱）
2. 自己上手用：以用户身份把主流程走一遍，边用边记疑问
3. 画图：画功能地图和核心流程图，画不出来的地方就是我不懂的地方
4. 问人：把疑问整理成清单，一次性问产品/开发，而不是随时打断
5. 定计划：根据以上，列出测试重点和排期，跟负责人对一次

实习生「我了解这个岗位的实习薪资大概在 XX 到 XX 之间，我按公司的标准来就行，更看重能不能真的参与项目。」——实习生不要谈价，谈时长和成长。

正式岗（岗位A）给一个区间，不要给单点：「我了解同类岗位在这个城市大概是 X 到 Y，我的期望在这个区间内，具体可以看岗位职责和成长空间。」

如果被追问具体数字先问回去：「方便说一下这个岗位的预算范围吗？」对方给了，你说「这个范围我是可以接受的」。

诚实 + 转化「说实话重复的回归确实枯燥，我不否认。但我的处理方式是把它变成一次性的事——比如整理成检查清单、能脚本化的就脚本化。我在实习的时候就是把主流程整理成冒烟清单，后来别人也在用。所以我不会一直重复同一件事，我会想办法让它变少。」

这个回答既承认了现实（不装），又展示了主动性（这正是 JD 想要的）。

三个词 + 每个一个证据（说完就停，别展开成长篇）：

• 细致——缺陷描述会自己先照着步骤走一遍再提交
• 靠谱——答应今天给结论的事不会拖到明天
• 爱琢磨——看到不顺的地方会想「能不能更省事」

同事评价「带我的同事说过一句我记到现在：『你提的 bug 我能直接看懂，不用问你。』我觉得这是对我最高的评价。」