面经
Q1：POM 设计模式是怎么分层的？从脚本执行到生成报告经历了哪些层级？
面试官考察意图：
- 验证你是否真的写过 POM 框架，还是只背了概念。
- 考察你对项目架构的理解深度（BasePage / Page / Script / Report 各层职责）。
知识点：
- POM 三层/四层架构：BasePage（基类封装）→ Page（页面对象）→ Script（测试脚本）→ Report（测试报告）。
- BasePage 的核心封装方法：
fd_element()、base_input()、base_click()、get_shot()、base_switch_frame()。 - 显式等待 vs 隐式等待的区别：作用范围、等待条件、性能影响。
推荐回答话术：
“在安享智慧理财项目中，我把框架分成了四层。
第一层是 BasePage 基类，我在里面封装了 Selenium 的通用操作，比如
fd_element()用来做元素定位，内部集成了显式等待；base_input()封装了‘清空默认值再输入’的逻辑；还有base_click()、失败自动截图的get_shot()、以及 Frame 切换的通用方法。这样所有的 Page 类继承 BasePage 就能直接调用这些方法，不用重复写代码。第二层是 Page 页面对象层，比如登录页、借款申请页。我把页面上的元素定位信息抽出来作为类属性，然后把业务操作封装成方法。比如登录页的
login(username, pwd)方法，调用 BasePage 的base_input和base_click完成登录动作。第三层是 Script 测试脚本层，只关注业务逻辑，比如先登录、再申请借款、然后验证结果。完全不用关心元素怎么定位。
第四层是 Report 报告层，通过 Allure 把执行结果生成可视化 HTML 报告。
关于显式等待和隐式等待的区别：隐式等待是全局设置的，只要
driver在查找元素时找不到就会等，缺点是绑定在find_element上，不够灵活。显式等待是针对特定元素等特定条件，比如等按钮可点击、等弹窗出现。我在 BasePage 里封装的是显式等待，因为它更精准，当元素出现就立即返回，不用等到超时。”
Q2：Fixture 的 scope 参数有哪些？Conftest.py 的作用是什么？
面试官考察意图：
- 验证你是否真的用过 Fixture 管理登录态。
- 考察对 Conftest 机制的理解（作用域传播、就近优先原则）。
知识点：
- scope 的四个级别：function（默认）、class、module、session。
- yield 关键字的作用：返回值给用例，用例执行完毕后继续执行清理代码。
- Conftest.py 的作用域传播规则：同级目录和子目录自动生效，子目录可以覆盖父目录同名 fixture。
推荐回答话术：
“Fixture 的 scope 有四个级别。function 是默认的，每个测试函数执行一次；class 是整个测试类执行一次；module 是整个 py 文件执行一次；session 是整个测试会话执行一次。
在理财项目中，我用的
scope=‘class’，因为一个测试类里的多个用例用同一个登录状态就够了，没必要每次都重新登录，这样能节省执行时间。yield 关键字的作用是：yield 前面的代码是前置操作，比如打开浏览器、执行登录；yield 后面的代码是后置操作，比如退出浏览器、清理测试数据。yield 可以把登录后的 driver 对象传给用例用。
Conftest.py 的作用是存放共享的 fixture。pytest 会自动从用例所在目录向上递归查找 conftest。它的作用域是对同级目录和所有子目录的测试文件生效。如果子目录也有 conftest 并且定义了同名 fixture，子目录的会覆盖父目录的，这叫就近优先原则。”
Q3：如果登录按钮的 ID 变了，你的框架需要改几个地方？
面试官考察意图：
- 验证你是否真正理解“解耦”的含义。
- 考察 POM 模式的核心价值：一处修改，处处生效。
知识点：
- 元素定位与业务逻辑解耦的核心思想：定位信息集中在 Page 类管理，脚本只调用业务方法。
推荐回答话术：
“只需要改 一个地方，就是 LoginPage 类里的
login_btn属性定义的地方。比如原来写的是self.login_btn = (By.ID, ‘login-btn’)，现在改成self.login_btn = (By.ID, ‘submit-btn’)。其他所有测试脚本完全不用动，因为它们调用的是
self.base_click(self.login_btn)这个方法，不关心底层 ID 是什么。这就是 POM 模式‘将元素定位与业务逻辑解耦’的核心价值：开发改元素属性，我只维护 Page 类一个地方就行，不会出现改了几十个脚本的噩梦。”
Q4：回归效率提升 60% 是怎么算出来的？自动化在什么情况下不适合做？
面试官考察意图：
- 验证你的量化成果是否有依据。
- 考察你对自动化测试适用场景的判断力（不是所有场景都适合自动化）。
知识点：
- 自动化效率计算的常见方法：手工执行时间 ÷ 自动化执行时间。
- 自动化测试的局限性：需求频繁变更的模块、验证码/人脸识别场景、一次性测试、界面未稳定的新功能。
推荐回答话术：
“这个数字是我估算的。以前手工跑一遍借款、投资、还款这 20 个核心场景大概要 30 分钟，现在用自动化脚本跑完只需要 10 分钟左右，效率大概提升 60% 到 70%。
至于自动化不适合做的情况，我认为有几种：第一，需求频繁变更的功能，今天写了明天就改，维护成本比手工还高；第二，有验证码或者人脸识别这种强人机验证的场景，绕过机制太复杂；第三，一次性测试或探索性测试，没必要写脚本；第四，界面还没稳定的新功能，元素频繁变动，脚本会大量报错。”
Q5：自媒体端和管理端的测试侧重点有什么不同？
面试官考察意图：
- 考察你是否理解双端测试的差异。
- 验证你是否有用户视角（自媒体用户 vs 运营审核员）。
知识点：
- 自媒体端：面向内容创作者，侧重点是文章发布的体验、富文本编辑器、图片上传、草稿箱可用性。
- 管理端：面向内部运营，侧重点是批量操作效率、审核流程准确性、敏感词拦截有效性、数据列表筛选准确性。
推荐回答话术：
“我觉得两端的测试侧重点确实不同。自媒体端面向博主和内容创作者，我更关注发布体验，比如标题字数限制、封面图上传的各种格式组合、富文本编辑器好不好用、存草稿和定时发布正不正常。
管理端是给内部审核员用的，我更关注审核流程的准确性，比如批量通过和驳回的并发安全、敏感词是否有效拦截、筛选条件的组合查询结果是否正确。还有非功能测试，管理端因为是 B/S 架构，浏览器的兼容性也是重点。”
Q6：解释正交实验法，你在筛选模块的具体因子和水平是什么？
面试官考察意图：
- 验证你是否能讲清楚正交实验法的原理和实际应用。
- 考察你是否理解正交实验法的局限性。
知识点：
- 正交实验法的核心：从全排列中选取“均匀分散、齐整可比”的组合，用最少的用例覆盖两两交互。
- 局限性：不能保证三三交互的覆盖。
- 弥补方式：对业务高风险的三条件组合额外补充用例。
推荐回答话术：
“正交实验法是一种用最少的用例覆盖多条件交互的组合测试方法。核心思想是‘均匀分散、齐整可比’，从全排列中挑出有代表性的组合。
在黑马头条的筛选模块，我有四个因子：文章状态有 5 个水平（全部、草稿、待审核、通过、失败），关键字有 2 个水平（精确、模糊），频道列表有 4 个水平（java、python、其他、全部），发布日期有 4 个水平（今天、过去+当前、时间段、当前+未来）。全排列是 5×2×4×4 等于 160 条。我用正交表裁剪到大概 25 条核心组合，保证任意两个因子之间的所有水平组合至少出现一次。
它的局限性是不能保证三个或更多因子的交互被完整覆盖，所以对于业务上特别重要的三条件组合，比如‘待审核+科技频道+今天发布’，我会额外手工补充 1 到 2 条用例做重点验证。”
Q7：“分页导出数据不一致”这个 Bug 是怎么发现的？
面试官考察意图：
- 验证你是否真的发现并提交过这个 Bug。
- 考察你描述 Bug 的能力（现象、复现步骤、提单要素）。
知识点：
- Bug 发现过程：执行测试用例时不通过。
- Bug 单要素：标题、严重程度、优先级、复现步骤、预期结果、实际结果、截图。
推荐回答话术：
“这个 Bug 是我在测黑马头条后台文章筛选功能时发现的。导出功能有两个按钮：一个是‘导出当前页’，一个是‘导出全部’。我当时的测试操作是：搜索结果有 3 页，我停在第 2 页，点击‘导出当前页’。预期是下载的 Excel 只有第 2 页的 20 条数据。但实际下载下来发现包含了所有 3 页的数据，跟‘导出全部’没区别。
我提 Bug 的时候写了标题大概是‘文章筛选-分页导出当前页数据-导出的数据为全部页面数据而非当前页’。填了复现步骤、测试环境、浏览器版本，附上了导出的 Excel 截图和页面对比截图。严重程度我标的是‘中’，因为功能逻辑错了但不是系统崩溃。”
Q8：优先级和严重程度有什么区别？
面试官考察意图：
- 考察你是否理解缺陷管理的基本概念。
- 验证你在实际工作中能否正确判断 Bug 的修复顺序。
知识点：
- 严重程度：Bug 对系统功能的影响程度（崩溃 = 致命，错别字 = 轻微）。
- 优先级：修复的紧急程度（影响上线 = P0，可以下版本修 = P3）。
- 两者不总是一致：一个严重程度低但影响公司形象的 Bug（Logo 错误）优先级可能很高。
推荐回答话术：
“严重程度是看 Bug 对系统功能的破坏程度，比如系统崩溃、数据丢失属于致命；功能错误、金额算错属于严重；界面错别字属于轻微。
优先级是看修 Bug 的紧急程度，由产品和测试共同确定。P0 就是阻塞上线必须马上修，P3 可以下个版本再处理。
两者不一定一致。举个例子，一个错别字的严重程度是轻微，但如果这个错别字出现在公司首页 Logo 上，那优先级可能就是 P0。反过来，一个很严重的功能 Bug，如果只在一个极少人用的模块里，优先级可能降到 P2。”
Q9：写一条 SQL 查询：查询 2025 年 3 月“待审核”状态的文章
面试官考察意图：
- 验证你是否真的会写 SQL。
- 考察基本的 WHERE 条件组合和日期函数。
知识点：
- 基本 SELECT 语句：
SELECT * FROM articles WHERE status = '待审核' AND create_time BETWEEN '2025-03-01' AND '2025-03-31'; - 索引的概念：加速查询的数据结构，类似书的目录。
- 慢查询排查思路：先看 SQL 执行计划（EXPLAIN），再确认是否命中索引。
推荐回答话术：
“我会这么写：
SELECT id, title, status, create_time FROM articles WHERE status = ‘待审核’ AND create_time >= ‘2025-03-01’ AND create_time < ‘2025-04-01’;索引是一种加速数据库查询的数据结构，相当于给书的目录建了一个索引，找内容更快。如果查询很慢，我会先让开发帮忙看一下执行计划 EXPLAIN，看看有没有命中索引、是不是全表扫描，然后再判断是加索引还是优化 SQL 语句。”
Q10：常用 Linux 命令有哪些？页面访问不了怎么排查？
面试官考察意图：
- 验证你是否真的用过 Linux 基本命令。
- 考察你排查线上问题的思路（网络→进程→日志逐层排查）。
知识点：
- 常用命令：
tail -f（实时日志）、ps -ef | grep java（查进程）、netstat -anp | grep 端口（查端口）、top（查资源）、grep（过滤关键字）。 - 排查思路：先看服务是否活着 → 再看日志是否报错 → 再看资源是否耗尽。
推荐回答话术：
“最常用的有：
tail -f实时看日志、grep过滤关键字、ps -ef | grep java看 Java 进程是否活着、netstat -anp | grep 8080看端口是否在监听、top看 CPU 和内存有没有打满。如果页面访问不了，我的排查思路是：第一步，先看对应服务器能不能 ping 通，网络有没有问题。第二步，SSH 上去用
ps -ef看 web 服务进程还在不在。第三步，用netstat看端口是否正常监听。第四步，用tail -f看日志目录下的 catalina.out 或者 error.log，看有没有报错。第五步，用top或df -h看 CPU、内存、磁盘有没有耗尽。”
Q11：什么是线程安全问题？金融系统什么场景会触发？
面试官考察意图：
- 考察你是否能将编程基础概念（多线程）应用到测试场景中。
- 验证你是否理解“并发超卖”这个经典的金融测试 Bug。
知识点：
- 线程安全：多个线程同时访问共享资源，由于执行顺序不确定导致数据异常。
- 金融系统的经典并发 Bug：余额超卖/超取（同一账户同时被多个投资请求扣款，余额扣成负数）。
- 测试验证方法：用 JMeter 设置多线程同时请求同一个接口，检查数据库余额是否正确。
推荐回答话术：
“线程安全问题就是多个线程同时操作同一个共享变量时，由于 CPU 调度的不确定性，导致数据出现异常。最典型的例子就是两个线程同时执行‘读取余额 → 判断够不够 → 扣款’这个操作，因为读和写之间有间隙，可能两个线程都读到余额 100 块，然后都扣了 100 块，最后余额变成负的。
在理财项目里，投资抢标就是高风险场景。比如一个借款标还剩 100 块额度，两个投资人同时投 100 块，如果后端没加锁或者用乐观锁，就可能两个都投成功，造成超卖。
如果我要验证这个并发问题，我会用 JMeter 设置 50 个线程，同时请求投资接口，每个线程投 10 块钱，总共应该扣 500 块。然后去数据库查账户余额和标的剩余额度，看是不是和预期一致。”
Q12：GET 和 POST 的区别？用 Postman 怎么做断言？
面试官考察意图：
- 考察 HTTP 协议基础。
- 验证你是否真的用过 Postman 做接口测试。
知识点：
- GET vs POST：参数位置、安全性、幂等性、缓存。
- Postman 断言：Tests 标签中用 JavaScript 写
pm.test()，常用断言：状态码、响应时间、JSON 字段值。
推荐回答话术：
“GET 和 POST 的区别主要有几点：第一，GET 参数在 URL 后面，POST 参数在 body 里，所以 POST 相对安全，不会在浏览器历史记录和日志里暴露参数。第二，GET 有长度限制，POST 理论上没限制。第三，GET 是幂等的，多次请求结果一样；POST 不一定是幂等的，多次请求可能创建多条记录。
测接口时，状态码是基础：200 正常、4xx 是客户端问题、5xx 是服务端问题。
用 Postman 做断言，我在 Tests 标签里写 JS 代码。比如断言状态码是 200：
pm.test(‘状态码为200’, function(){ pm.response.to.have.status(200); });。断言返回体里有 token：pm.test(‘返回token’, function(){ var jsonData = pm.response.json(); pm.expect(jsonData.data).to.have.property(‘token’); });。如果要模拟 100 个用户并发，我会用 JMeter，设置线程组 100 个线程，Ramp-Up 时间 5 秒，然后加 HTTP 请求采样器填登录接口地址和参数，最后用聚合报告看压测结果。”
Q13：需求评审中发现模棱两可的地方，你会怎么做？
面试官考察意图：
- 考察你在团队协作中的沟通能力和主动性。
- 验证你是否理解需求文档的质量标准。
知识点：
- 需求文档中不能出现的词：大概、可能、差不多、根据情况。
- 处理方式：记录并会议提问 → 要求产品经理明确具体规则。
- 合格需求的特征：有具体规则、无模糊词语、有界面原型、有异常处理描述。
推荐回答话术：
“如果我发现需求文档里有模棱两可的地方，我会先标记下来，自己理解一下可能的几种实现方式，然后在需求评审会上提出来，让产品经理明确给结论。
比如我当时测黑马头条登录功能，如果需求文档只写了‘用户名长度有限制’，没有写具体多少位，我就会在会上追问：‘这个长度限制具体是多少？最小几位、最大几位？超出限制是前端直接拦截还是后端报错？’一定要把各种情况问清楚才能写用例。
我觉得一个合格的需求文档，规则必须具体，不能出现‘大概’、‘可能’这种词；功能逻辑要完整，正常情况和异常情况都要有描述；最好有 UI 原型图，方便核对界面元素。”
Q14：上线前一天发现严重 Bug，开发来不及修，你怎么处理？
面试官考察意图：
- 考察你的风险意识和职业判断力。
- 验证你在压力场景下的处理流程。
知识点：
- 正确流程：先评估影响范围 → 拉产品、开发、项目经理一起决策 → 不管结果怎样都要记录和跟踪。
- 优先级判断标准：是否影响核心功能、影响用户数量、是否有临时规避方案。
推荐回答话术：
“首先我会确认这个 Bug 的影响范围：是所有用户都会遇到，还是只有极端场景下才触发？有没有变通办法，比如临时隐藏这个功能入口？
然后我会马上拉产品经理、开发负责人和项目经理一起讨论，把这个 Bug 的严重程度、影响范围、修复需要的时间都说清楚。如果确实来不及修，大家一起决定是延期上线、还是带着这个 Bug 上线但做好临时预案。
关于判断修不修的标准，我主要看三点：第一，是不是核心功能，非核心功能可以晚点修；第二，影响用户多不多，如果只是后台某个报表数据显示差了一点点，可以下版本修；第三，有没有临时规避方案，如果有就可以降级处理。”
Q15：你怎么用 AI 提高效率？能举个需求反推的例子吗？
面试官考察意图：
- 考察你是否真的会用 AI 工具，还是只写了个噱头。
- 验证你对 AI 工具在测试中角色定位的理解。
知识点：
- AI 应用场景：需求反推（只有 UI 图推导规则）、用例查漏补缺、测试计划生成。
- AI 的局限性：可能遗漏特殊边界场景、无法理解业务上下文、生成内容仍需人工审核。
- 正确使用方式：AI 辅助 + 人工审查优化，不是直接拿 AI 输出当最终产物。
推荐回答话术：
“我主要在三个场景用 AI：第一是需求反推，当只有 UI 图没有需求文档时，我让 AI 以产品经理的角色帮我推导页面上各个输入框的规则。第二是用例查漏补缺，我列出已有的测试点，让 AI 帮我看看有没有遗漏的边界值和异常场景。第三是生成测试计划等文档的初稿。
举个需求反推的例子：我在测黑马头条后台筛选功能时，只有原型图没有详细规则文档。我把筛选页面的截图描述给 AI，让它以产品经理身份反推需求。AI 帮我输出了一份规则文档，比如状态筛选应该包含全部、草稿、待审核、通过、失败五个选项；日期筛选开始时间不能晚于结束时间；关键字支持精确和模糊搜索。我再根据这些规则设计测试点，效率高了很多。
但 AI 生成的用例我不会直接用。AI 有时候会‘偷懒’，比如漏掉一些极端的边界值、或者对一些业务隐含的约束理解不到位。所以我的做法是：用 AI 出初稿，人工审查补充，再定稿执行。”
Q16：你作为测试新人，最大的优势是什么？未来 2-3 年的规划？
面试官考察意图：
- 考察你的自我认知是否清晰。
- 验证你的职业规划是否匹配公司培养方向。
知识点：
- 优势：结合简历亮点来说，如自动化落地能力 + 编程基础 + 工程化思维。
- 规划：技术方向（自动化/测开）或业务方向（金融/互联网深度发展），合理即可。
推荐回答话术：
“我觉得我最大的优势有两点。第一是自动化落地能力，别的应届生可能学过 Selenium 理论，但我是真正从头搭建过一个 POM 分层框架，从 BasePage 封装到 Allure 报告都走过一遍。第二是我的编程基础，蓝桥杯省一让我在理解代码逻辑和排查复杂 Bug 时更有优势，比如多线程并发问题我能直接看懂代码里的锁。
未来规划方面，前 1 到 2 年我想先把功能测试和自动化测试做实，能独立负责一个完整模块或项目的测试。第 2 到 3 年，我会往测试开发方向发展，深入接口自动化和性能测试，学习 CI/CD 持续集成。我也希望能参与框架的二次开发，从执行者变成建设者。”
以上就是 16 个面试问题的完整知识点梳理和回答建议。建议你对着每个问题口头演练一遍，用你自己的语言表达出来，确保面试时能流畅自信地作答。
贡献者
freeway348