测试开发 / 软件测试面试常见问题有哪些？怎么准备（校招 / 社招）

一句话：在软件交到用户手里之前，尽可能早、尽可能便宜地把问题找出来，并且让团队对「这个版本能不能上线」心里有数。测试不是只在开发写完之后点一点，而是贯穿整个迭代：需求评审时找出说不清、自相矛盾的地方；开发期间写测试方案和用例；提测后执行测试、提缺陷、跟进修复；上线前做回归和风险评估；上线后盯监控和用户反馈，必要时参与复盘。

常见方向有四类，面试侧重点差别不小：

• 功能测试（业务测试）：最常见的入门方向。重点是理解业务、设计用例、找缺陷、推动修复。面试会大量考用例设计和测试思维。
• 自动化测试：把重复的回归用例写成脚本，包括接口自动化和 UI 自动化（Web、App）。面试会问框架怎么搭、用例怎么维护、怎么接进持续集成。
• 性能测试：做压测、找瓶颈、给容量评估。面试会问指标、压测方案设计和瓶颈定位思路。
• 测试开发（测开）：用写代码的方式提升测试效率和质量，比如测试平台、数据构造工具、流量回放、覆盖率统计、质量看板。面试对编码和工程能力的要求接近开发岗。

实际工作中这几类经常是混在一起的：一个人既做业务测试也写接口自动化，很常见。级别上大致是：初级（能按需求独立设计和执行用例）→ 中级（能负责一个业务线的质量，搭自动化）→ 高级 / 资深（能定测试策略、建质量体系、带人）→ 负责人（跨团队的质量规划和效能建设）。级别越高，面试里「你怎么确保这个业务的质量」比重越大，「这个命令怎么用」比重越小。

JD 上的每一句要求，几乎都能对应到面试里的一类问题。拿到 JD 先按下表拆一遍，就知道该重点准备哪里。

小技巧：JD 里写「测试开发」的岗位，基本会按开发岗的标准考编码，有时还会考数据结构和算法；只写「测试工程师」的岗位，用例设计和业务理解的比重更大。先判断岗位偏哪一边，再分配准备时间。

不同公司轮次不完全一样，互联网公司常见的结构如下，具体以招聘方通知为准：

社招常见的变化：一面就会深挖项目，基础概念题占比下降；高级岗位会问测试策略和质量体系，比如「一个新业务从零开始你怎么建立质量保障」。实习面试一般 2–3 轮，难度比正式校招略低，但用例设计题和简单编程题照样会考。

1. 01黑盒测试和白盒测试有什么区别？专业知识技术一面校招 · 实习 · 跳槽转行基础

   考察点： 测试基本概念是否清楚，能否说出各自适用的阶段，而不是只背定义。

   答题思路：

   • 黑盒测试：不看代码，只看输入和输出是否符合需求。关注「功能对不对」。常用方法有等价类划分、边界值分析、场景法、判定表、错误推测。
   • 白盒测试：看代码内部结构，按逻辑路径设计用例。关注「代码每条路走没走到、走得对不对」。常用的是语句覆盖、判定覆盖、条件覆盖、路径覆盖等。
   • 适用阶段：白盒多用在单元测试，通常由开发或测开配合完成；黑盒多用在系统测试和验收测试。
   • 补一句灰盒：接口测试经常介于两者之间——看接口文档和部分实现逻辑，但从外部调用验证。
   • 实战判断：两者不是二选一，比如用覆盖率工具发现某个分支从没被执行过，就可以反过来补黑盒用例。

   校招怎么答 / 社招怎么答： 校招讲清区别、方法和适用阶段即可；社招可以说说团队有没有统计覆盖率，覆盖率数据是怎么用来指导补用例的。

   可能的追问： 语句覆盖和判定覆盖有什么区别？覆盖率 100% 是不是就没 bug 了？

   练一练
2. 02讲一下软件测试的一般流程。专业知识技术一面校招 · 实习 · 跳槽转行基础

   考察点： 是否知道测试在整个迭代中的位置，是否有「测试越早介入越好」的意识。

   答题思路：

   • 按阶段讲：需求分析和评审 → 制定测试计划（范围、策略、人力、风险）→ 设计测试用例并评审 → 准备测试环境和数据 → 提测后先冒烟 → 执行用例、提交和跟踪缺陷 → 回归测试 → 输出测试报告、评估上线风险 → 上线后验证和监控。
   • 强调两个点：需求评审阶段测试就要参与，此时发现问题成本最低；用例要评审，否则容易遗漏。
   • 可以提一句：敏捷团队里这些阶段会压缩、并行，但每个环节要做的事还在。

   校招怎么答 / 社招怎么答： 校招把流程讲完整、每步说出产出物；社招讲你们团队实际怎么运转的，比如提测标准是什么、哪些环节做了自动化、准出标准由谁定。

   可能的追问： 提测标准一般包括什么？测试报告里要写哪些内容？

   练一练
3. 03冒烟测试、回归测试、验收测试分别是什么？专业知识技术一面校招 · 实习 · 跳槽转行基础

   考察点： 常用测试类型的目的、时机和范围。

   答题思路：

   • 冒烟测试：提测后最先做，只测最核心的主流程，判断这个版本「能不能测下去」。冒烟不过可以打回。
   • 回归测试：代码改动后，验证原来正常的功能有没有被改坏。范围可以是全量回归，也可以按改动影响面做选择性回归。回归最适合做自动化。
   • 验收测试：站在用户或业务方角度确认是否满足需求，通常在上线前由产品或业务方参与。
   • 用一句话串起来：冒烟管「能不能测」，回归管「改没改坏」，验收管「是不是要的东西」。

   可能的追问： 回归测试的范围你怎么确定？冒烟用例怎么挑？

   练一练
4. 04为什么说测试不能证明软件没有缺陷？专业知识技术一面技术二面校招 · 社招进阶

   考察点： 对测试本质的理解，以及有没有「风险驱动」的思维。

   答题思路：

   • 输入组合、运行环境、使用路径几乎是无穷的，穷举测试不可能做到。测试只能证明「在这些用例下没发现问题」。
   • 所以测试要做的是：用有限的资源，覆盖风险最高、用户最常用的部分，把剩余风险降到可以接受。
   • 怎么判断「测得差不多了」：需求覆盖情况、用例执行和通过情况、缺陷收敛趋势、遗留缺陷的严重程度、核心路径有没有自动化守护。
   • 加一句态度：正因为不能证明没有缺陷，上线后的监控、灰度和快速回滚同样是质量保障的一部分。

   校招怎么答 / 社招怎么答： 校招讲清原理和风险驱动；社招可以讲讲团队的准出标准和上线后的兜底手段。

   可能的追问： 什么叫缺陷集群现象？你怎么判断一个版本可以上线了？

   练一练
5. 05给你一个登录页面，你会怎么设计测试用例？情景应变技术一面校招 · 社招 · 实习 · 跳槽转行基础

   考察点： 测试思维是否成体系。几乎必考，面试官看的不是你列了多少条，而是有没有分类、有没有遗漏大块。

   答题思路：

   • 先问清楚需求，再开始列：支持哪些登录方式（账号密码、手机验证码、第三方）、密码规则、失败几次锁定、是否有「记住我」。这一步本身就是加分项。
   • 按维度分类输出：
   • 功能：正确账号密码登录成功；账号或密码错误；为空；大小写；前后空格；记住我和退出登录；忘记密码入口。
   • 边界：用户名和密码的最短、最长长度及其两侧；特殊字符、中文、表情。
   • 异常：网络中断、服务超时、重复点击登录按钮、已被锁定或注销的账号。
   • 安全：密码是否明文传输和明文显示、错误提示是否暴露「账号存在」、连续失败是否限制、SQL 注入和脚本注入输入、登录态过期和多端登录策略。
   • 兼容：不同浏览器、不同手机系统和屏幕尺寸。
   • 性能：高并发登录时的响应时间。
   • 易用性：回车能否提交、Tab 切换顺序、错误提示是否清楚。
   • 最后补一句优先级：先确保核心路径和安全，再覆盖兼容和易用性。

   示范回答（校招版）：

   我会先确认几个需求细节：这个页面是账号密码登录还是也支持验证码，密码有没有长度和字符规则，连续输错有没有锁定。假设是账号密码登录，我会从七个方面来设计。功能上，正确账号密码能登录成功并跳到首页，错误的账号或密码给出提示，用户名或密码为空时不能提交，还要测「记住我」和退出登录。边界上，用户名和密码取最短长度、最长长度以及多一位少一位的值，再试一下特殊字符和中文。异常上，测网络断开、重复快速点击登录按钮会不会重复提交。安全上，看密码框是不是掩码显示、错误提示会不会暴露「这个账号存在」、连续输错是否被限制，以及输入单引号这类注入字符时系统是否正常处理。然后是兼容性，在几种常用浏览器和手机上看显示和功能。性能上关注登录接口的响应时间。最后是易用性，比如回车能不能直接登录、提示是否清楚。我在【课程项目 / 实习项目】里测登录模块时，就是因为测了前后空格，发现【用户名带空格时提示信息不一致】的问题。

   示范回答（社招版）：

   我先说思路再列点。拿到登录需求，我会先和产品确认登录方式、密码和锁定规则、登录态有效期和多端策略，这几项决定了用例的大头。然后我会分三层来设计。第一层是界面和功能，正常登录、各种错误输入、边界长度、空值和空格，这一层大部分会沉淀成接口自动化，UI 只留一两条主流程。第二层是安全和风控，这是登录最容易出事故的地方：传输是否加密、错误提示是否可被用来枚举账号、失败次数限制和验证码触发、会话过期、改密码后旧登录态是否失效、多端同时登录的处理。这部分我会拉开发一起过一遍实现。第三层是稳定性和体验，比如高峰期并发登录的响应时间、依赖的短信或第三方服务挂了怎么降级、弱网下的提示。我在【某项目】里负责登录改造时，就是在第二层发现了【改密码后其他设备仍保持登录】的问题，上线前修掉了。之后我们把登录相关的核心用例全部纳入了每次发布的自动化回归。

   可能的追问： 如果只能测 5 条用例，你选哪 5 条？验证码登录又要多测什么？

   练一练
6. 06等价类划分和边界值分析怎么用？举个例子。专业知识技术一面校招 · 实习 · 跳槽转行基础

   考察点： 最基础的两种黑盒用例设计方法能否落到具体输入上。

   答题思路：

   • 等价类划分：把输入分成若干组，同一组里的值对程序来说「效果一样」，每组取一个代表值就够。分有效等价类（合法输入）和无效等价类（非法输入）。
   • 边界值分析：大量缺陷出在边界上，所以在边界本身以及边界两侧各取值。
   • 举例：年龄输入框要求 18 到 60 的整数。有效等价类是 18–60 的整数；无效等价类有小于 18、大于 60、小数、非数字、空值。边界值取 17、18、19、59、60、61。
   • 两者通常配合使用：先用等价类划分出区间，再在区间的边界上用边界值补充。
   • 设计用例时，一条用例尽量覆盖多个有效等价类，但每条用例只放一个无效等价类，避免错误互相掩盖。

   可能的追问： 判定表和因果图适合什么场景？输入有多个参数互相影响时怎么设计？

   练一练
7. 07给你一个水杯（或电梯、购物车），你会测哪些点？情景应变技术一面校招 · 实习 · 跳槽转行基础

   考察点： 发散思维加归纳能力。面试官想看你能不能把发散出来的点归到几个维度里，而不是零散地报点。

   答题思路：

   • 先确认需求和使用场景：给谁用、装什么、有什么特殊功能（保温、刻度、防漏）。
   • 再按维度展开：功能（能不能装水、刻度准不准、盖子能不能拧紧）、性能（保温时长、耐高温和低温）、可靠性（摔落、反复开合）、安全（材料是否无毒、高温下有无异味、边缘是否划手）、易用性（握持、清洗、单手开盖）、兼容性（能否放进车载杯架）、外观。
   • 如果是购物车，就换成软件维度：加购、改数量、删除、库存不足、商品下架、价格变化、优惠叠加、未登录与登录后的合并、多端同步、并发修改。
   • 结尾说优先级：先测核心功能和安全，再测其他维度。

   可能的追问： 这些点里你会先测哪三个，为什么？如果给你半小时，你怎么安排？

   练一练
8. 08需求文档写得不清楚，你怎么设计用例？情景应变技术一面业务面社招 · 校招进阶

   考察点： 主动性和沟通能力，以及面对不确定性时怎么确保质量。

   答题思路：

   • 先自己整理疑问：把说不清、有歧义、有遗漏（异常情况、边界、权限）的地方列成清单。
   • 主动找产品澄清，最好在需求评审会上当面提，结论记录到需求文档或会议纪要里，避免口头约定后各说各的。
   • 暂时确认不了的，先按合理假设设计用例，并在用例里标明假设，后续确认后再调整。
   • 可以参考竞品或系统里已有的类似功能，作为讨论的依据。
   • 提一句长期改进：推动需求模板里补上异常流程、边界规则这些常被漏掉的部分。

   校招怎么答 / 社招怎么答： 校招讲清「先问、记录、按假设设计」的思路即可；社招最好讲一个因为提前澄清避免了返工的真实例子。

   可能的追问： 产品也说不清楚怎么办？上线后发现是需求理解偏差，算谁的问题？

   练一练
9. 09接口测试一般测哪些内容？专业知识技术一面技术二面校招 · 社招 · 跳槽转行基础

   考察点： 是否真的做过接口测试，能否超出「传参看返回」的层面。

   答题思路：

   • 参数校验：必填和非必填、类型、长度和范围、格式、空值、特殊字符、多传和少传参数。
   • 返回结果：状态码是否符合约定（可以顺带说 200、400、401、403、404、500 的含义），返回结构和字段类型，业务数据是否正确，必要时查库核对数据是否真的写进去了。
   • 鉴权：不带登录态、登录态过期、越权访问（用 A 用户的身份操作 B 用户的数据）。
   • 业务逻辑：状态流转是否正确（比如订单不能从已取消直接变成已发货）、幂等（重复提交同一个请求会不会产生两条记录）。
   • 异常与稳定性：依赖服务超时或报错时的处理、并发调用、大数据量。
   • 工具层面：用接口调试工具做手工验证，再用代码（如 Python 的请求库加测试框架）做自动化。

   校招怎么答 / 社招怎么答： 校招把维度说全，最好举一个自己测过的接口；社招重点讲越权、幂等、并发这类容易出线上问题的点，以及怎么沉淀成自动化。

   可能的追问： 怎么测一个接口的幂等性？GET 和 POST 有什么区别？

   练一练
10. 10接口自动化里，登录态和接口之间的依赖怎么处理？专业知识技术二面校招 · 社招进阶

    考察点： 是否写过真实的接口自动化，而不是只跑过单条请求。

    答题思路：

    • 登录态：在测试开始前统一登录一次，把 Token 或 Cookie 存起来供后续用例使用，比如用测试框架的前置夹具（fixture）在会话级别获取；Token 过期要能自动刷新。
    • 接口依赖：比如「下单」依赖「先创建商品」。做法是把依赖的数据在用例前置里准备好，前一个接口的返回值通过变量提取传给下一个接口。
    • 尽量减少用例之间的依赖：每条用例自己准备数据、自己清理数据，这样可以单独运行、并行运行，失败也好定位。
    • 测试数据：用独立的测试账号和数据；能用接口或直接写库造数据，就不要依赖界面操作。
    • 第三方依赖：对不稳定或收费的外部服务，用挡板（mock）模拟返回。

    可能的追问： 用例之间共享数据会出什么问题？mock 用多了会有什么风险？

    练一练
11. 11你们的自动化测试框架是怎么搭的？案例分析技术二面社招 · 校招深挖

    考察点： 自动化是不是真正落地了，框架设计有没有想清楚分层和维护成本。社招自动化、测开岗位核心题。

    答题思路：

    • 先说背景：为什么要做自动化，要解决什么问题（回归太耗人力、发布频率高）。
    • 讲分层：配置层（环境、账号）、请求和工具封装层（统一发请求、日志、重试）、业务封装层（把业务操作封装成方法，UI 自动化常用页面对象模式）、用例层（只写测试步骤和断言）、数据层（数据驱动，用例和数据分离）。
    • 讲断言：不只断言状态码，还要断言关键业务字段，必要时查库。
    • 讲报告和通知：执行结果生成报告，失败自动通知到群或负责人。
    • 讲接入流水线：代码提交或每日定时触发，核心用例作为发布的准入检查。
    • 讲效果和问题：用例规模、执行时长、发现了多少问题，用你自己的真实数据；以及仍然存在的不足。

    示范回答（校招版）：

    我在【实习项目 / 个人项目】里搭过一个接口自动化框架，用的是 Python 加 pytest。我分了四层：最底层是配置，把不同环境的地址和测试账号放在配置文件里，切换环境只改一个参数；第二层是请求封装，统一处理请求头、登录 Token、日志打印和超时；第三层是按业务封装的接口方法，比如「登录」「创建订单」；最上层是用例，用例里只写调用和断言。测试数据放在单独的数据文件里，用参数化做数据驱动，一个接口的多组边界数据只写一条用例。断言我除了看状态码，还会检查返回里的关键字段，下单类接口还会去数据库查一下数据有没有写对。跑完用插件生成测试报告。整个框架覆盖了【N 个】接口、【M 条】用例，跑一遍大约【X 分钟】。做的过程中我发现最大的问题是用例之间互相依赖，一条失败会连带一片，后来改成每条用例自己准备数据，就好定位多了。

    示范回答（社招版）：

    我们做自动化的出发点是【某业务】每【两周】发一次版，回归要【N 人】测【X 天】，而且容易漏。我的思路是先接口、后 UI，按测试金字塔来分配。接口自动化框架分五层：配置层管理多环境和账号；基础层封装请求、日志、重试和签名；业务层把常用操作封装成方法，供用例和造数工具共用；用例层只关心步骤和断言；数据层用数据文件做数据驱动，并且每条用例自己造数据、自己清理，支持并行执行。UI 自动化只覆盖【十几条】核心主流程，用页面对象模式，减少页面改版带来的维护量。框架接进了持续集成：开发提交合并请求时跑冒烟集，每天夜里跑全量，发布前跑一遍核心集作为准入，失败会把报告和失败日志推到群里，并标记是用例问题、环境问题还是真实缺陷。落地【几个月】后，回归时间从【X 天】降到【Y 小时】，自动化在发布前拦下了【若干个】问题。还没做好的地方是用例稳定率，环境问题导致的误报还偏多，这是我下一步在治理的事。

    可能的追问： 哪些用例适合自动化，哪些不适合？框架里的失败重试会不会掩盖真实问题？

    练一练
12. 12自动化用例越来越多、越来越不稳定，你怎么治理？情景应变技术二面社招深挖

    考察点： 自动化维护的实战经验。写自动化不难，难的是让它长期可信。

    答题思路：

    • 先度量：统计每条用例近期的失败率和执行时长，把失败按原因归类——产品真缺陷、用例本身写得有问题、环境或数据问题、依赖服务不稳定。
    • 按原因治理：用硬等待（固定睡几秒）的改成显式等待元素或条件；用例共享数据的改成数据隔离；依赖不稳定外部服务的用 mock；环境问题推动环境稳定性建设。
    • 建立机制：新用例要评审；连续不稳定的用例先移出准入集合并限期修复；定期清理过时用例；把稳定率作为一个持续看的指标（具体数值用你团队的真实数据）。
    • 谨慎对待失败自动重试：可以减少偶发误报，但要记录重试情况，避免把真实的偶现问题掩盖掉。

    可能的追问： 偶现的失败，你怎么判断是产品问题还是用例问题？用例太多执行太慢怎么办？

    练一练
13. 13UI 自动化和接口自动化怎么取舍？什么是测试金字塔？专业知识技术二面校招 · 社招进阶

    考察点： 对自动化投入产出比的判断。

    答题思路：

    • 测试金字塔：底层是单元测试，数量最多、跑得快、也最稳定；中间是接口（服务）测试；顶层是 UI 端到端测试，数量最少。越往上越接近用户真实操作，但越慢、越脆弱、维护成本越高。
    • 接口自动化：稳定、快、容易定位问题，能覆盖大量业务逻辑和边界，适合作为回归的主力。
    • UI 自动化：能验证真实用户路径和前后端联调结果，但容易受页面改动影响。适合只覆盖少量核心主流程。
    • 选择依据：功能是否稳定、回归频率高不高、手工执行成本多大、维护成本能不能承受。频繁改版的页面不适合急着做 UI 自动化。
    • 常见的反模式是「冰激凌筒」：UI 用例一大堆、接口和单元测试很少，结果维护不过来。

    可能的追问： 单元测试应该由谁来写？App 的 UI 自动化和 Web 有什么不同？

    练一练
14. 14性能测试关注哪些指标？专业知识技术一面技术二面校招 · 社招基础

    考察点： 是否理解性能指标的含义和相互关系。

    答题思路：

    • 响应时间：一般看平均值，更要看分位数（如较慢的那 5%、1% 请求的耗时），平均值容易掩盖长尾。
    • 吞吐量：单位时间处理的请求数或事务数（常说的 TPS、QPS）。
    • 并发数：同一时间在系统里发起请求的用户或线程数。
    • 错误率：失败请求占比。
    • 服务器资源：CPU、内存、磁盘 I/O、网络带宽，以及数据库连接数、线程池使用情况等。
    • 讲关系：并发逐步增加时，吞吐量先上升，到某个点后不再上升甚至下降，响应时间明显变长、错误率上升，这个拐点附近就是系统的容量上限。
    • 区分测试类型：负载测试、压力测试、稳定性（长时间）测试、容量测试。

    可能的追问： 平均响应时间和分位数响应时间有什么区别？性能测试的场景和数据怎么设计才接近真实？

    练一练
15. 15压测时发现某个接口变慢了，你怎么定位瓶颈？情景应变技术二面社招深挖

    考察点： 性能问题的分层排查思路，以及和开发、运维协作定位的能力。

    答题思路：

    • 先确认现象：是所有请求都慢还是部分慢，是一开始就慢还是压力上去才慢，响应时间分位数和错误率怎么变化。同时排除压测机自身的瓶颈（压测机的 CPU、带宽被打满也会表现为「接口慢」）。
    • 分层排查：
    • 应用层：CPU 是否打满、是否频繁垃圾回收、线程池或连接池是否耗尽、有没有锁竞争。
    • 数据库：慢查询、缺索引、锁等待、连接数不够。
    • 缓存：命中率是否下降、有没有大量请求直接打到数据库。
    • 依赖服务和网络：下游接口是否变慢、网络带宽和延迟。
    • 工具：服务器监控、应用日志、链路追踪（看一次请求在各个环节分别耗时多少）、数据库慢查询日志。
    • 定位后和开发一起验证修复效果，用同样的场景和数据再压一次对比。

    可能的追问： 怎么判断是压测机的瓶颈还是被测系统的瓶颈？压测会不会影响线上，怎么隔离？

    练一练
16. 16写一个函数，判断字符串是否是回文；再统计字符串里每个字符出现的次数。专业知识笔试技术一面校招 · 实习 · 跳槽转行基础

    考察点： 基本编码能力、边界意识，以及测试人员特有的「写完先自测」习惯。

    答题思路：

    • 回文：双指针从两头往中间比较，遇到不同就返回否；或者把字符串反转后比较。双指针空间开销更小。
    • 先问清楚规则：是否忽略大小写、空格和标点，空字符串算不算回文。
    • 统计字符次数：遍历字符串，用字典（哈希表）计数；Python 里也可以说一下标准库里的计数工具，但最好先手写一遍。
    • 写完主动补测试用例：空字符串、单个字符、偶数和奇数长度、含大小写和空格、含中文。这一步对测试岗特别加分。
    • 说复杂度：两者都是遍历一遍，时间复杂度 O(n)。

    校招怎么答 / 社招怎么答： 校招写对、写干净、主动补用例；测开岗位的社招可能会把题目难度提高到中等算法，要提前保持手感。

    可能的追问： 找出字符串里第一个只出现一次的字符？列表去重并保持原顺序？

    练一练
17. 17常用的 Linux 命令有哪些？线上出问题时你怎么查日志？专业知识技术一面校招 · 社招 · 跳槽转行基础

    考察点： 能否在服务器上独立定位问题，而不是一出问题就找开发。

    答题思路：

    • 文件和目录：ls、cd、cp、mv、mkdir、find。
    • 看文件内容：cat、less、head、tail，实时看日志用 tail -f。
    • 过滤和统计：grep（加上 -n 看行号、-C 看上下文）、wc -l 计数、awk 取某一列、sort 和 uniq -c 做统计。
    • 进程和端口：ps -ef、top、netstat 或 ss 看端口、kill。
    • 资源：df -h 看磁盘、free 看内存。
    • 查日志的思路：先根据时间点和请求标识（比如订单号或请求 ID）用 grep 过滤出相关日志，再看报错的上下文；统计某类错误出现了多少次，判断影响范围。

    可能的追问： 怎么统计日志里出现次数最多的 10 个 IP？某个端口被占用了怎么查是哪个进程？

    练一练
18. 18写一条 SQL，查出某张表里重复的数据。专业知识笔试技术一面校招 · 实习 · 跳槽转行基础

    考察点： SQL 分组聚合的基本功。测试日常要查库核对数据、造测试数据，SQL 是必备技能。

    答题思路：

    • 思路：按判断「重复」的字段分组，筛出组内数量大于 1 的组。
    • 写法：SELECT name, COUNT(*) FROM users GROUP BY name HAVING COUNT(*) > 1。
    • 讲清 WHERE 和 HAVING 的区别：WHERE 在分组前过滤行，HAVING 在分组后过滤组。
    • 如果要查出重复的完整记录，可以用子查询或者和分组结果关联。
    • 再顺带准备几种常考写法：多表关联（内连接和左连接的区别）、排序取前几名、按条件统计。

    可能的追问： 怎么删除重复数据只保留一条？内连接和左连接的结果有什么不同？

    练一练
19. 19自动化测试怎么接入持续集成？失败了怎么处理？专业知识技术二面社招 · 校招进阶

    考察点： 是否把自动化真正融进了研发流程，而不是「想起来跑一下」。

    答题思路：

    • 触发时机分层：代码提交或合并请求时跑单元测试和冒烟集（要快，几分钟内出结果）；每日定时跑全量回归；发布前跑核心集作为准入检查。
    • 流水线做的事：拉代码、构建、部署到测试环境、执行用例、生成报告、通知结果。
    • 失败处理：先看是不是环境或数据问题，再看是否用例问题，最后确认是不是真实缺陷；真实缺陷要阻断合并或发布，并指派给对应开发。
    • 保持可信：流水线如果经常误报，大家就会习惯性忽略它，所以稳定性比用例数量更重要。
    • 工具只是举例：常见的持续集成工具和代码托管平台自带的流水线都可以实现，重点是流程设计。

    可能的追问： 冒烟集怎么控制在几分钟内跑完？多人同时提交时测试环境冲突怎么办？

    练一练
20. 20你开发过什么测试工具或平台？解决了什么问题？案例分析技术二面终面社招深挖

    考察点： 测开岗位核心题：有没有发现效率瓶颈并用工程手段解决的能力，以及工具是否真正被用起来。

    答题思路：

    • 从问题出发讲，而不是从技术出发：当时团队痛点是什么（造数据慢、环境不好用、回归没数据、缺陷趋势看不清）。
    • 讲方案：做了什么工具（造数平台、接口测试平台、mock 服务、覆盖率统计、质量看板等），技术选型和架构的关键取舍。
    • 讲推广：怎么让别人愿意用，比如先在一个小组试点、写文档、收集反馈迭代。
    • 讲效果：用你自己的真实数据，比如节省了多少时间、覆盖了多少业务、使用人数。
    • 讲反思：哪里设计得不好，如果重来会怎么做。

    校招怎么答 / 社招怎么答： 校招如果有自己写的小工具（比如批量造数据的脚本、简单的测试报告汇总工具）也可以讲，重点是你发现了什么问题；社招要讲清从需求、设计到推广落地的完整过程。

    可能的追问： 这个平台的用户是谁？使用率不高的时候你怎么办？代码质量怎么确保？

    练一练
21. 21一个缺陷报告应该包含哪些内容？严重程度和优先级有什么区别？专业知识技术一面校招 · 实习 · 跳槽转行基础

    考察点： 缺陷报告写得好不好，直接决定开发的修复效率。

    答题思路：

    • 内容：标题（一句话说清在哪、做了什么、出现什么问题）、所属模块和版本、测试环境（系统、浏览器、设备、账号）、前置条件、复现步骤、预期结果、实际结果、严重程度和优先级、附件（截图、录屏、日志、请求和返回）、复现概率。
    • 标准：开发拿到后不用来问你就能复现。
    • 严重程度是「影响有多大」（崩溃、数据错误、功能不可用、界面问题），优先级是「多急着修」。两者不一定一致：比如首页的公司名称写错了，严重程度低但优先级高。
    • 缺陷的生命周期：新建 → 指派 → 修复 → 验证 → 关闭，验证不通过则重新打开。

    可能的追问： 偶现的缺陷怎么提？复现不了的缺陷怎么办？

    练一练
22. 22开发说「这不是 bug」，你怎么处理？行为题（STAR）技术一面业务面校招 · 社招 · 实习进阶

    考察点： 沟通方式和专业判断，既不能轻易放弃，也不能变成争吵。

    答题思路：

    • 先自查：确认能稳定复现、环境和数据没问题、自己对需求的理解没有偏差。
    • 回到依据：拿需求文档、设计稿、接口约定说话，而不是「我觉得」。
    • 需求没写清楚的，拉产品一起确认，由产品判断是不是预期行为。
    • 确实是「设计如此」但体验不好的，可以作为优化建议提出，而不是硬当缺陷。
    • 结论要记录下来，关闭或调整缺陷状态时写清原因，方便以后追溯。
    • 用 STAR 讲一个真实例子，重点是你怎么沟通、最后怎么达成一致。

    校招怎么答 / 社招怎么答： 校招可以讲实习或团队项目里的分歧，重点是方式；社招可以加一层机制改进，比如推动在需求评审时把容易争议的规则写清楚。

    可能的追问： 如果产品也站在开发那边，但你认为会影响用户，你怎么办？

    练一练
23. 23上线前时间不够、用例测不完，怎么办？情景应变技术二面业务面社招 · 校招进阶

    考察点： 风险意识和取舍能力，以及能否把风险讲清楚而不是默默背锅。

    答题思路：

    • 按风险排优先级：核心业务路径、涉及资金和数据的功能、本次改动影响面大的地方优先；低频、边缘的功能往后放。
    • 提效：能跑的自动化先跑起来；和开发一起做重点模块的自测或交叉测试。
    • 主动同步：把「测了什么、没测什么、有什么风险」明确告诉项目负责人和产品，由团队共同决定是延期、缩减范围还是带着已知风险上线。
    • 兜底：上线后加强监控、准备回滚方案，尽快补测剩余用例。
    • 复盘：为什么时间不够，是需求变更晚、提测延期还是评估不准，下次怎么提前预防。

    可能的追问： 如果负责人坚持要按时上线，你怎么做？上线后出了问题，责任怎么算？

    练一练
24. 24线上出了一个漏测的问题，你怎么复盘？行为题（STAR）技术二面业务面社招 · 校招深挖

    考察点： 责任心和从问题里改进流程的能力。不甩锅，也不只是认错。

    答题思路：

    • 先处理：配合开发和运维止血（回滚、开关降级、修复），评估影响范围。
    • 找原因，分清是哪一类：需求理解偏差、用例设计没覆盖到、用例有但没执行、测试环境和线上不一致、上线流程绕过了测试。
    • 补救：补上对应的用例，能自动化的加进回归集。
    • 改进流程：从一个点推到一类问题，比如补充同类场景的检查清单、推动测试环境数据更贴近真实、加上线上监控告警。
    • 讲态度：坦诚承认测试环节的遗漏，同时用事实说清各环节原因，把重点放在怎么不再发生。

    示范回答（校招版）：

    我在【实习 / 课程项目】里遇到过一次。【某个功能】上线后，用户反馈【某种情况下页面报错】。我先帮开发一起复现，确认是【输入为空 / 某种特殊数据】时没有做处理。复盘时我回头看自己的用例，发现我测了正常数据和明显错误的数据，但没有考虑到【这种边界情况】，是用例设计上的遗漏。我做了三件事：第一，把这个场景补进用例，修复后重新验证；第二，按同样的思路检查了其他几个类似的输入框，又发现了【一个】类似问题；第三，我给自己整理了一份输入类功能的检查清单，包括空值、超长、特殊字符、前后空格这些，之后每次设计用例都对照一遍。这件事让我意识到边界值不能凭感觉挑，要有方法。

    示范回答（社招版）：

    我们在【某次版本】上线后，【某业务】出现了【某类数据计算错误】，影响了【一小部分】用户，发现后【X 小时内】通过回滚止住了。复盘时我先把时间线和事实理清楚，再按环节找原因：需求里其实写了这个规则，测试用例也覆盖了，但测试环境的数据都是新造的，没有【某种历史状态】的数据，所以用例跑通了，线上的老数据却触发了问题。这是测试环节的遗漏，我在复盘会上直接认了。改进上做了三件事：一是补用例，并把这类场景加进接口自动化回归；二是和开发、运维一起推动测试环境定期导入脱敏后的线上数据样本，覆盖更多真实的数据状态；三是在这个业务的关键指标上加了监控告警，数据异常时能更早发现。之后我们把「数据迁移和历史数据兼容」加进了需求评审和测试方案的检查项。我觉得漏测复盘的重点不在追究谁，而是让同一类问题以后不再出现。

    可能的追问： 如果复盘发现主要是开发的问题，你还会在复盘里讲测试的遗漏吗？怎么衡量改进措施有没有效果？

    练一练
25. 25为什么选择做测试？以后会不会转开发？动机与求职意向HR面终面校招 · 社招 · 跳槽转行基础

    考察点： 动机是否真实、稳定，对测试岗位的认识是否到位。

    答题思路：

    • 讲真实的原因：比如在实习或项目里发现自己对找问题、确保质量更有兴趣，或者喜欢站在用户角度思考，能举一个具体的小事更有说服力。
    • 讲你对岗位的认识：测试不是「点点点」，它需要业务理解、技术能力和沟通能力，测开方向对编码要求也很高。
    • 讲规划：短期把业务测试和自动化做扎实，中期往测试开发、性能、质量体系建设等方向深入，长期希望能负责一个业务的整体质量。规划要和应聘的岗位方向一致。
    • 关于「会不会转开发」：不要贬低测试，也不要为了显得安心而说假话。可以说你更想在质量和效能方向上用技术深入下去，写代码的能力会一直练，但方向是做好质量。
    • 转行的同学：讲清楚为什么从原来的行业转过来、为转行做了哪些准备（学习、做项目），以及原来的经验在测试里怎么用得上（比如对业务流程的理解）。

    校招怎么答 / 社招怎么答： 校招讲清动机和成长路径；社招讲清在测试方向上的积累和下一步想深入的点，以及为什么这个岗位适合下一步。

    可能的追问： 你觉得测试和开发最大的区别是什么？三年后你希望自己是什么样？

    练一练

点「练一练」会复制这道题，并跳到页面底部的下载入口；打开 OfferGod 模拟面试后粘贴即可。

你在测试面试里遇到过本页没写到的用例设计题、场景题，或者被追问到答不上来的情况吗？欢迎通过页面底部「发现内容有误或侵权？告诉我们」把题目和当时的情况告诉我们，采纳后会补进题库，帮到后面准备的人。