京东测试开发岗面经合集（一）：AI Coding、测试用例设计与网络基础

《面试题目》

面经 01 · 京东测试开发岗（2026-06-04）

1. 介绍下研究生专业
2. 开发的功能涉及到资金，是怎么做风险把控的？
3. 说到重构了 300 行代码，具体是怎么抽象的？你认为这些代码具有什么特性才被抽象成公共方法的？
4. 实习过程中有使用 AI coding 吗？
5. AI coding 帮你弥补了哪一部分的不足？在这个过程中怎么样让它生成的代码可用率更高，有哪些使用技巧？
6. 在这个过程中你觉得 Claude 能满足你的要求吗？
7. 为什么要用到 think-execute 机制？
8. 怎么保证 think-execute 机制循环规划出来的路径是符合项目预期的？

面经 02 · 京东测试开发岗（2026-05-12）

9. Transformer 的原理，self-attention
10. Context Engineering
11. 用过哪些 agent，有没有自己设计过 skill？

面经 03 · 京东测试开发岗（2026-04-21）

12. 异步如何测试？（回答从查询数据变更入手）
13. 登陆界面测试用例
14. 你的 skill 的流程是什么样子的？
15. 你们的环境有哪几套？

面经 04 · 京东测试开发岗（2026-04-17）

16. 代码题：反转字符串
17. 键入 www.baidu.com，整个的流程，具体都涉及到哪些协议？
18. 为什么 http 使用的是 tcp，不使用 udp？
19. tcp 三次握手过程
20. 快速排序工作原理
21. 如何才能设计出好的测试用例（不是针对某一具体测试用例，而是针对一个功能如何设计）？
22. 如何在使用尽可能少的测试用例的情况下尽可能全面地测试软件或功能？
23. 如何使用 AI 为你的生活或工作减负？

面经 05 · 京东测试开发岗（2026-03-27）

24. 问我 ICPC 经历，有没有印象深刻的题目（聊了七八分钟成都站树上启发式合并）
25. 我是学后端的，测开没接触过，测开主要是要干些啥？
26. 实习时间有要求吗？

面经 06 · 京东测试开发岗（2026-03-19）

27. 测试用例设计方法，被要求现场给一个登录框设计用例
28. 功能测试、性能测试、安全测试的区别，各适合什么场景？
29. 京东测试开发一面过了等二面大概要多久，正常流程是几轮？

面经 07 · 京东测试开发岗（2026-03-09）

30. 学校项目与工程开发的区别
31. 代码题：给定一个日志文件，请解析出所有等级为「ERROR」的日志，统计对应方法名出现的次数，并按次数降序排列

面经 08 · 京东测试开发岗（2026-03-06）

32. 对项目源码是否有过功能叠加或优化？遇到过什么问题？
33. 在项目中使用的 Kafka，如何保证消息不丢失和顺序性？
34. 你认为 AI 平台目前最大的问题或瓶颈是什么？
35. 了解死锁吗？如何产生及解决？
36. 你知道哪些设计模式？请举例说明
37. 代码题：将一个 9 位整型数字转换为人民币大写形式（注意处理中间的零）
38. 目前的科研项目是什么？
39. 你对测试开发岗位的理解？更倾向于开发还是测试？
40. 日常是否使用 AI 辅助编程？
41. 最熟悉的数据库是？

面经 09 · 京东测试开发岗（2026-01-09）

42. 假设现在要对一个京东「秒杀」下单接口进行测试，你会从哪些方面去设计测试用例？
43. 如果要你为这个「秒杀」接口设计自动化测试，你会选用什么框架和技术栈？为什么这么选？
44. 如果自动化测试脚本在持续集成（CI）环境中偶尔会失败，但本地运行是稳定的，你觉得可能是什么原因？排查思路是什么？
45. 你如何理解测试左移和测试右移？在实际项目中可以如何实践？
46. 在需求评审会上，如果你认为开发的设计方案在可测试性上存在隐患，或者遗漏了异常场景，你会怎么沟通？
47. 性能测试中，你如何判断一个系统的瓶颈是在应用服务器、数据库还是网络？
48. 除了功能、性能，你觉得像京东购物车这样的核心功能，还需要关注哪些非功能性的质量属性？
49. 你了解哪些测试覆盖率的概念？在实际项目中，你会追求高代码覆盖率吗？为什么？
50. 你对测试开发这个岗位未来的职业发展有什么自己的看法？

面经 10 · 京东测试开发岗（2025-12-30）

51. 浏览器中输入 url 后发生什么
52. tcp vs udp
53. 讲讲 sql 事务，什么场景用事务
54. 左连接、右连接、全连接和内连接区别
55. 进程线程区别
56. 软件开发各阶段中测试人员如何参与
57. 讲讲黑盒白盒灰盒测试
58. 微信支付展示付款码场景设计测试用例
59. 手撕（10min）：无重复字符最长字串，分析时间复杂度

面经 11 · 京东测试开发岗（2025-12-17）

60. 浏览器输入 url 后的整个过程
61. 多进程和多线程
62. get 和 post 的区别
63. sql 题：联表查询排序
64. 是否所有表都要加索引，在哪些表加索引呢？
65. 为什么做测开？
66. 工作中遇到比较难解决的问题

面经 12 · 京东测试开发岗（2025-12-14）

67. 测试了解什么？
68. 提 bug 需要注意哪些点？
69. 测试用例的内容
70. 常见的 http 状态码包括哪些
71. post 和 get 的区别
72. 常用的 linux 命令有哪些
73. Java 里重载和重写的区别
74. 数据结构中的链表
75. 数组和集合的区别，哪个可变长度？
76. 设计京东搜索的测试用例
77. 写一个 SQL 找出月薪大于平均月薪的员工
78. SQL：表中出现最少的商品

面经 13 · 京东测试开发岗（2025-12-13）

79. 数组和链表的区别，分别适用的场景

《参考解析》

面经 09 / 12 / 10 · 测试用例设计

1. 场景类用例设计题怎么答：通用的骨架是「功能、边界、异常、并发、兼容、性能、安全、可恢复」八个维度，答的时候按被测对象挑重点，别八股式地全铺一遍。以秒杀下单接口为例：功能上覆盖正常下单、库存为 0、活动未开始与已结束；边界覆盖库存恰好等于购买量、限购数量上下沿、金额为最小单位；异常覆盖参数缺失与越界、重复提交、支付失败与超时；并发是重点——同一用户并发下单（防重）、大量用户抢同一商品（超卖）、缓存与数据库不一致时的表现；兼容覆盖多端与不同版本；性能覆盖峰值 QPS、响应时间与降级后的表现；安全覆盖刷单、脚本抢购、越权查看他人订单。搜索无结果这类「定位 bug」题要按链路排查：先确认是所有人还是个人（账号、地域、灰度）、再看前端请求参数与返回、然后追网关到搜索服务的日志与调用链、再看索引是否同步（数据有没有进索引、索引是否重建中）、最后看过滤规则与召回结果，每一步都要能给出「怎么验证是这一层的问题」。付款码、登录框、优惠券阶梯满减这类题目同理，答题的价值在于「维度全 + 每个维度能举出具体 case + 说清优先级」，而不是堆几十条用例。

2. 测试左移、覆盖率与流程题：测试左移是把质量活动往需求与设计阶段挪：需求评审时提可测试性与验收标准、设计阶段做接口契约与 mock、编码阶段单测与静态检查、提测前冒烟；测试右移是往线上挪：灰度发布、线上拨测与监控告警、日志与链路追踪、故障演练与回滚预案。覆盖率要分类讲：行覆盖率、分支覆盖率、条件覆盖率、以及更贴近业务的接口覆盖率与需求覆盖率；高代码覆盖率不等于高质量——它只能证明代码被执行过，证明不了断言对不对、边界有没有覆盖，追求数字还会催生「为了覆盖率而写的无效测试」，所以合理做法是核心链路与高风险模块要求高覆盖，并配合变异测试与需求覆盖矩阵。CI 里偶发失败而本地稳定，常见原因是环境差异（依赖版本、配置文件、数据库初始状态）、并发与时序（端口冲突、共享测试数据、异步等待不足）、资源限制（内存、超时设置太紧）、外部依赖不稳定（第三方接口、网络），排查手段是保存失败现场（截图、日志、trace）、隔离执行找出互相干扰的用例、把不稳定用例打标签单独统计而不是直接重跑掩盖。

面经 04 / 10 / 11 · 网络、系统与数据库八股

3. 输入 URL 到页面展示、协议与抓包：链路是 URL 解析与缓存检查 → DNS 解析（浏览器缓存、hosts、递归查询）→ TCP 三次握手 → TLS 握手（HTTPS 场景）→ 发 HTTP 请求（经过网关、CDN、负载均衡）→ 服务端处理并响应 → 浏览器解析 HTML/CSS 构建渲染树、布局与绘制、执行 JS。涉及的协议按层列：应用层的 HTTP/HTTPS、DNS，传输层的 TCP/UDP（QUIC 场景是 UDP 上的 HTTP/3），网络层的 IP、ICMP，链路层的 ARP 与以太网。为什么 HTTP 用 TCP 而不是 UDP：HTTP 需要可靠、有序、不丢字节的传输语义，TCP 自带重传、排序、流量与拥塞控制；用 UDP 就得在应用层把这些重新实现一遍（HTTP/3 的做法正是如此，但那是为了绕开 TCP 的队头阻塞，而且在 QUIC 里把可靠性做回来了）。三次握手的价值是双方确认收发能力并同步初始序列号、协商 MSS 与窗口；要能顺口说出 SYN、SYN+ACK、ACK 三段以及第三次可以携带数据、前两次不行。Linux 抓包关键字考察的是 grep 与日志过滤的组合能力，现场能写「在指定目录递归找文件、再用 grep 过滤关键字」这类命令即可，注意别用会扫全盘的写法。

4. SQL、索引与事务的答法：联表查询排序的模板是 select ... from a join b on a.id = b.a_id where ... order by ... limit ...，答题时说明连接类型的选择依据（内连接取交集，左连接保留左表全部行、右表无匹配补 NULL）、以及排序字段有没有索引（没有就会 filesort）。「是否所有表都要加索引」的答案是不要：索引会占空间并拖慢写入，适合加的是 WHERE、JOIN、ORDER BY 常用且区分度高的列，以及需要唯一约束的列；不适合的是区分度极低的列（性别）、频繁大范围更新的列、以及写远多于读的表。找字段最大值要能提到 max() 走索引可以取到索引最右端，比排序后取第一条更省。事务的四大特性与隔离级别在测试岗也会问，重点说清脏读、不可重复读、幻读分别被哪个级别解决，以及线上更常用读已提交的原因（并发性能与锁范围），并提一句「RC 下要靠业务层兜住不可重复读」。Redis 与数据库的对比题按「数据模型、持久化、事务、扩展方式、适用场景」五点答，别只说「一个快一个慢」。

面经 01 / 02 / 08 · AI Coding 与 Agent 相关

5. AI Coding 的可用率与 think-execute 机制：让生成代码可用率更高的经验可以按「输入、过程、验证」三段讲：输入侧给足上下文（相关文件、接口定义、技术栈与版本、代码规范）、把需求拆成小粒度任务、明确验收标准与不要动的地方；过程侧先让模型出方案再动手、要求小步提交、每步保持可编译、遇到报错把完整堆栈回灌而不是只描述现象；验证侧必须自己读 diff、跑单测与类型检查，并发、错误处理和权限相关的改动要额外 review。被问「Claude 能满足要求吗」这类主观问题，说清楚它在什么任务上可靠（有明确模式的增删改、样板代码、测试补全）、什么任务上要盯紧（跨模块重构、并发与状态管理、陌生框架），比一句「很好用」可信。think-execute（先规划再执行）机制的意义是把「想清楚」和「动手改」分成两段，避免模型一上来就大范围改文件、方向错了才发现；保证循环规划路径符合项目预期的手段是：把项目约束写进执行前的检查清单、限制可改动的文件范围、要求每步产出可验证的结果（编译 / 测试通过）、对高风险步骤要求人工确认、并设最大轮数与终止条件防止无限循环。Agent 与 skill 的问题按「Agent 是带工具、记忆与循环的运行时，skill 是把某类任务的做法与约束封装成可复用的能力包」来区分，再补一句 skill 的价值在于沉淀流程与减少重复提示词。

6. 性能瓶颈定位与质量属性：判断瓶颈在应用、数据库还是网络，靠的是分段测量而不是猜：先在压测中同时采集应用侧指标（CPU、内存、GC、线程池队列、接口耗时分布）、数据库指标（QPS、慢查询、连接数、锁等待、IO 使用率）、网络指标（带宽、RTT、重传率、DNS 耗时），再看哪一段的耗时占比最高；常用手法是逐层加压（只压应用层、再压到库）与打点计时（把一次请求拆成网关、应用、缓存、数据库、外部调用几段），也可以用链路追踪直接看 span 耗时。链路级的表现能交叉验证：应用 CPU 高而数据库空闲多半是应用问题；数据库 IO 或锁等待高、应用线程大量等待就是库的问题；带宽打满或 RTT 抖动大、重传多则是网络问题。核心功能除了功能与性能，还要关注可用性（故障时的降级与恢复）、数据一致性（购物车金额与库存）、安全（越权、重复提交、价格篡改）、兼容性与可访问性、可观测性（日志、监控、告警是否覆盖）以及幂等与可回滚。这类开放题用「先分维度、再给验证手段」的结构答，比罗列名词得分高。