提前批测开三面，已OC！

大家好，我是洋子

近期百度提前批已经开始有一段时间了，甚至已经有不少 25 届的同学 oc 了，这里分享一位已经顺利 oc 百度提前批测开岗位同学的三轮面试面经

整个三轮技术面试总体难度不高，但考察知识广度比较广，如果有觉得后端竞争比较激烈的同学，也可以试一试测开岗位，选择大于努力，结合自身情况趋利避害选择最适合自己的并不是什么丢脸的事，找到工作才是最重要的

面经链接：https://www.nowcoder.com/feed/main/detail/0550f6a83d424223a8a7c41c0335b758
作者：哈球池扶手包包

7.10 投递简历

7.12 电话一面 20min

1. 为什么转码呀，当时怎么考虑的？
2. 有哪些offer了？测开方面了解哪些内容呀？
3. 现在有个招聘系统，它只有接口没有页面，对添加候选人模块设计一个测试用例？（这问题答的一般，没回答到点上）
4. 测试用例设计方法有哪些？
5. 其实刚才第3个问题问的是纯粹的接口，可以用jemter进行测试吗？
6. 那用jemter怎么进行操作呢？断言需要断言哪些内容？
7. MySQL的事务特性？
8. ACID4个隔离性解决了什么问题？（好像答错了，答4个隔离级别解决的问题了，复盘才听到…）
9. MySQL的默认隔离级别是什么？

7.17 二面 60min

1. 自我介绍
2. Redis持久化
3. Redis用于什么场景？
4. 业务里加了Redis，然后怎么对其中的一些数据点进行测试？
5. 输入URL从键入到显示发生了什么？
6. 对网页当中的错误，怎么区分是前端还是后端的？可以用什么工具区分？
7. Linux命令了解过吗？
8. 查看Nginx错误日志的linux命令？筛选包含500这种错误关键字的命令？
9. SQL语句，学生表、成绩表，查出三年级里英语成绩第三的人的学生名和英语成绩？
10. SQL语句再简化一下
11. 算法手撕：两个栈实现一个队列
12. 对接口测试的了解？
13. 有哪些测试工具了解过吗？
14. 反问

7.19 三面 45min

1. 自我介绍
2. 一个web网页的页面展示错误了，如何定位是前端代码还是服务端代码的问题（二面问过了，又问了一次）
3. 如果是后端的问题，怎么判断是哪个后端哪个模块呢？
4. 场景：一个推荐接口，类似于手机百度和小红书，它们都有个推荐列表，这个推荐列表会根据用户的历史访问信息，比如他可能比较喜欢访问历史、娱乐类的信息，会为他推荐感兴趣的内容。为这个推荐接口设计一个测试用例。
5. 你刚刚说用户历史访问数据为空，应该返回什么？（前面测试用例说了7个case，说太多我有点忘了，后面看录音是第二个case，所以这里卡了一段时间…后面还是回答上了，说我答得有点不自信…难绷）
6. 测试行业里“线上问题”的定义是什么？
7. 如果遇到线上问题，完整的处理流程是怎么样的？
8. 逻辑思维题：3个封闭箱子，分别是全为苹果、全为橙子、苹果和橙子混装，标签贴的都是错的。现打开其中一个箱子，拿出一个水果。能否根据选择的这一个箱子拿出来的水果，来为3个箱子贴上正确的标签？
9. 回到刚刚的测试用例，你说的多样性是什么？（我直接蒙了，我感觉我没说过啊…我看录屏发现不是我说的那7个case里的，就是最后提了一嘴，我说除了这7个主要的case，别的可能还包括异常情况处理、接口规范检查、用户体验测试这样，我在用户体验测试这里随口说了一句：从用户的角度出发检查一下推荐内容的多样性。…又是多嘴引发的问题…所以这个问题我直接就卡住了哈哈哈）
   所以这个问题我胡乱答了，当时真记不住了，我一直以为说的是用户体验层面，其实后来我觉得应该想问的推荐内容的多样性怎么保证？比如说推荐内容类型、主题、推荐内容的更新频率、推荐内容的时效性这些角度。这个问题答得稀烂哈哈哈
10. 你的优点和缺点是什么？实习时长多久？
11. 你对转正的需求的程度是怎么样的呢？
12. 反问

7.22 电话oc，最迟24号前可收到offer
7.23 offer

面试分析

接下来洋子带大家看几道面试题目，整场面试八股文部分偏简单，面试题答案在学习圈子里面已经覆盖，想要获取测开高频面试题答案，欢迎加入我的学习圈子

我这里选择3道比较有价值的面试题目：

• 网页报错，前后端Bug如何定位
• 线上问题的定义和处理流程
• 测试场景题：设计推荐信息接口的测试用例

第一道：网页报错了如何定位是前端还是后端问题

这个问题之前写了一篇文章来分析解答《这到底是前端Bug还是后端Bug》，问题答案参考这篇文章即可。这个面试官还追问了一下，如果是后端的问题，怎么判断是哪个后端哪个模块？

现在互联网大厂普遍采用的是微服务架构，要精准定位到问题出现在后端的哪个模块上面，需要结合基建来看

如果是后端日志打印比较规范，可以直接通过log id结合日志trace平台或者登录对应线上机器进行查看warning log报错信息定位分析，有的日志能还能记录接口的调用链信息，通过调用链能知道对应的模块

如果日志打印不规范，则很难直接通过日志得出问题的服务在哪个模块，这个时候我们可以通过结合日志信息以及看具体的后端代码逻辑进行定位出问题的模块

另外，如果业务建设了线上系统监控，还可以使用监控工具（如Prometheus、Grafana等）查看系统性能指标，是否有某个模块出现了异常的CPU、内存或响应时间。结合告警系统，设置关键指标的阈值，当超出阈值时会触发告警，这样可以迅速识别出问题模块

第二道：线上问题的定义和处理流程

线上问题的定义简单来说，影响功能，用户体验的问题等都可归结为线上问题，详细定义如下

在互联网产品研发、运维、迭代及服务提供的全过程中，由于技术缺陷、流程不畅、资源配置不当、系统设计不合理或外部因素干扰等原因，导致的阻碍产品功能实现、用户体验下降、服务效率减低、安全性受损或业务目标受阻的一系列问题。

这些问题涵盖了从软件开发的前端、后端、数据处理、系统架构到运维管理、用户体验、市场适应性等多个层面，需要通过系统化的管理和技术手段，包括但不限于敏捷开发、持续集成与交付(CI/CD)、自动化测试、DevOps文化、项目管理工具的应用、以及细致的用户反馈循环机制等，进行预防、识别、分析和解决，以保障互联网产品与服务的高质量持续发展

至于线上问题的处理流程，在大厂一般都有线上问题处理规范以及线上问题定级标准，发生线上问题后，并不是先去定位问题的原因，第一时间一定是先想办法止损，特别是出现资损的时候，先解决问题再去定位原因

止损后再定位问题原因，定位原因后进行排期修复（这里一般指长期的修复方案，不是短期的止损手段），测试通过后重新上线（服务端Bug）或者发版（客户端Bug）

最后进行Case Study复盘，避免再出现相同线上问题

第三道：场景题–设计推荐信息接口的测试用例

这道题目挺有意思的，咱们来分析一下，首先设计接口测试用例一般从接口的功能（入参、返回值）考虑，被测接口如果涉及高并发场景，需要考虑进行性能测试，若涉及敏感数据传输，还需要进行安全测试

但这道题赋予了一个具体的业务场景，这是一个推荐接口，类似于手机百度和小红书，它们都有个推荐列表，这个推荐列表会根据用户的历史访问信息，比如他可能比较喜欢访问历史、娱乐类的信息，会为他推荐感兴趣的内容

那我们回答就需要结合业务场景去回答，否则答案就会显得很空，这道题也可以进行举一反三，个性化推荐大家也许并不陌生，像刷抖音短视频，淘宝的购物列表，小红书展示内容，背后都涉及推荐算法

测试用例 1：推荐内容的准确性

• 测试目标：验证推荐内容是否符合用户的历史访问偏好。
• 前置条件：
  用户A有明确的内容偏好，频繁访问历史类文章。
  用户B喜欢娱乐和科技类内容。
• 测试步骤：
  登录用户A，调用推荐接口。
  检查返回的推荐列表，记录推荐的内容类别。
  登录用户B，调用推荐接口。
  检查返回的推荐列表，记录推荐的内容类别。
• 预期结果：
  用户A的推荐内容应主要集中在历史类。
  用户B的推荐内容应包含娱乐和科技类内容。

测试用例 2：推荐接口的响应时间（性能测试）

• 测试目标：验证推荐接口在不同并发条件下的响应时间是否在合理范围内。
• 前置条件：正常网络环境。
• 测试步骤：
  单次调用推荐接口，记录响应时间。
  模拟100个并发用户同时调用推荐接口，记录响应时间。
  模拟1000个并发用户同时调用推荐接口，记录响应时间。
• 预期结果：
  单次调用响应时间应在200ms内。
  100个并发时，响应时间应在500ms内。
  1000个并发时，响应时间应在1秒内，且无明显超时。

测试用例 3：无效输入的处理（异常场景）

• 测试目标：验证推荐接口对无效或异常输入的鲁棒性。

鲁棒性指：系统或程序在面对异常情况、错误输入或不利条件时，仍然能够保持正常功能或避免崩溃的能力

• 前置条件：
  用户未登录或登录状态失效。
• 测试步骤：
  使用无效的用户ID调用推荐接口。
  使用空的用户ID调用推荐接口。
  使用超长的字符作为用户ID调用推荐接口。
• 预期结果：
  接口应返回适当的错误信息，如“用户未登录”或“无效用户ID”。
  系统不应崩溃或出现未捕获的异常。

测试用例 4：冷启动（新用户）的推荐效果

• 测试目标：验证推荐接口在新用户或历史数据较少的用户上的表现。

• 前置条件：
  用户C刚注册账号，无访问历史。

• 测试步骤：
  登录用户C，调用推荐接口。
  记录返回的推荐内容。

• 预期结果：
  返回的内容应为系统默认推荐（如热门内容），或通过冷启动策略生成的内容。
  推荐内容不应出现完全空白或无关紧要的信息。
  测试用例

测试用例5：推荐内容的多样性

• 测试目标：验证推荐内容的多样性，以确保用户长时间使用不会感到内容单一。

• 前置条件：用户D有广泛的兴趣爱好，访问过多个类别的内容。

• 测试步骤：
  登录用户D，调用推荐接口多次，间隔不同时间段。
  检查每次返回的推荐列表，记录内容类别的分布。

• 预期结果：
  每次调用推荐接口返回的内容应具有一定的多样性，不应集中于单一类别。
  推荐内容应根据用户的持续访问行为进行动态调整。

测试用例 6：推荐内容的更新频率

• 测试目标：验证推荐内容是否能够根据用户的最新访问记录及时更新。

• 前置条件：用户E的历史访问数据已有固定的访问偏好。

• 测试步骤：
  用户E访问多个新类别的内容。
  立即调用推荐接口，记录推荐内容。
  再次访问不同类别内容后，重新调用推荐接口。

• 预期结果：推荐内容应能够快速反映用户的新访问行为，及时调整推荐内容的类别和主题。

以上是推荐接口测试用例主要的测试用例，大家如果还有补充的欢迎评论

这道题目还可以继续延伸，是对推荐算法里面涉及的推荐策略进行测试，算法的测试有很多步骤，很重要的就是算法的效果测试，比如A/B Test等等，欢迎大家一键三连（点赞，在看，转发），有机会单独讲一下算法测试