京东测试开发岗面经合集（二）：测试流程、Python 自动化与职业规划

《面试题目》

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

1. 实习的难点在哪里？
2. 你是怎么解决的？
3. 为什么选择做测试？
4. 为什么不考虑转正呢？
5. 你为什么觉得自己适合做测试呢？
6. 个人的职业规划是什么？
7. 能提前实习吗？
8. 京东创新零售和京东零售的区别是什么？
9. 面试结果什么时候出？

面经 02 · 京东测试开发岗（2025-09-21）

10. 场景题：在京东商城 APP 搜索「手机」时页面无结果，怎么定位 bug？
11. Linux 中怎么删除当前目录下所有层级目录里，大小超过 100MB 的文件？
12. 如果是用 Python，上述删除文件的操作怎么做？
13. 介绍一下迭代器的用法？
14. 介绍一下 Python 的多线程在自动化测试中有什么作用？为什么不用多进程？
15. 个人情况聊天：之前在京东实习干的啥？测试开发和运维开发两个岗位怎么选？哪里人？本科到研究生是考的还是申请的？为什么选这个学校读研？研究生课题是啥？为什么不选科技企业而选择互联网企业？啥时候毕业？能留新加坡工作吗？为什么不留？
16. 公司的测试业务流程是怎么样的？
17. 什么时候知道二面结果？

面经 03 · 京东测试开发岗（2025-09-19）

18. 为什么想选择测试开发？
19. 测试方法有哪些？
20. 有没有用过京东产品？怎么来测试？
21. 讲一下实习做过的项目？怎么做的？
22. 实习遇到的最大困难？
23. 大学期间最有成就感的事情？最困难的事情？
24. 未来的职业规划？有意向转开发吗？
25. 能不能提前实习？

面经 04 · 京东测试开发岗（2025-09-18）

26. 多进程和多线程
27. sql 题：联表查询排序
28. 为什么做测开？
29. 工作中遇到比较难解决的问题
30. 本科觉得自己哪门课学得比较好
31. 是不是所有表都要加索引，在哪些表加索引？
32. 觉得自己有什么优点缺点

面经 05 · 京东测试开发岗（2025-09-18）

33. 请介绍自己，重点分享与用户研究、调研项目或用户洞察相关的经历（如用研实习、校园调研项目、用户行为分析）
34. 你为什么申请京东的用户研究岗位？对「用户研究在京东科技加零售产品中的核心价值」的理解是什么？
35. 你认为用户研究的核心目标是什么？如何平衡「用户需求」与「业务目标」？
36. 你熟悉哪些用户研究方法？（如问卷调查、深度访谈、可用性测试）这些方法在京东零售 APP 优化中的适用场景有何差异？
37. 你有过设计研究方案的经历吗？比如为校园 APP 设计调研，如何确定研究目标与方法？

面经 06 · 京东测试开发岗（2025-09-16）

38. 测试系统用例怎么测试？
39. 如果给你一个测试场景，比如说注册系统，你怎么具体测试？
40. linux 相关命令，怎么从指定目录里抓包关键字？
41. 合并两个有序列表
42. 求目标和的最小长度子数组

面经 07 · 京东测试开发岗（2025-09-16）

43. 介绍部门情况
44. 简历上的内容比较偏向算法和开发，为什么选择测开这个岗位？
45. 黑盒白盒灰盒测试的概念
46. 实际工作中测试的整体流程
47. 测试用例应该包含哪些信息？
48. 给定手机端的登录界面，设计测试用例（功能、性能、弱网、兼容、UI）
49. 用 postman 进行接口测试的时候写过断言吗，简单说说
50. 自动化测试框架有了解过吗？
51. 对大模型的了解，在大模型 agent 开发或者大模型辅助开发上有没有什么研究？大模型如何在工作中应用以提高效率？
52. 3-5 年的职业规划

面经 08 · 京东测试开发岗（2025-09-16）

53. 测试的生命周期分哪几个阶段？
54. 测试在这些过程中，最重要的环节是什么？
55. 如果时间比较紧张，你已经测了 80~90% 以上，项目经理问能不能符合上线，你表示还没有测完，其他人觉得大部分测过了、剩下的不那么重要功能或者有问题可以接受，这个时候你怎么处理这个事情？
56. redis 和数据库都有了解相关知识吗？比如说哈希结构的数据是如何查询的？大概命令是什么（HGETALL 查询所有）？数据库如果加索引的语句怎么查询？
57. 京东的 app 用过吗？假设说我这有一个需求：新增了一种类型的优惠券，特性是阶梯式满减，对这份产品进行测试，你会从哪几个方面去设计你的用例？
58. 为什么想做测试呢？
59. 有想过自己的职业规划吗？不说长远的，短期 3 年左右的职业规划有想过吗？
60. 反问面试官：（晚上 9 点多）现在这个时间点没下班是日常吗？

《参考解析》

面经 01 / 03 / 07 · 求职动机与职业规划

1. 「为什么做测试」这类动机题要有具体理由：面试官问这句是在筛「会不会干半年就跑」。有效的答法是给出一条自洽的逻辑链，比如「实习里做后端时最常被线上问题回灌，我在定位问题时发现自己更喜欢把质量控制在前面 → 测开的自动化与工具建设正好结合了开发和测试 → 我想做的是让团队少踩坑而不是单纯点点点」。要避开的坑：不要说「测试比开发简单」「开发岗没面上先做测试」、不要把测开只描述成写脚本，也不要在同一场面试里既说想做开发又说热爱测试。被追问「有意向转开发吗」时，诚实但给出边界：短期专注测开的能力积累，长期希望能往质量架构或效能平台走，这个回答既真实又不打脸。

2. 职业规划要分层说、给时间粒度：短期（1 年内）落到具体能力——熟悉业务与测试流程、独立负责模块的用例设计与自动化覆盖、掌握接口与性能测试工具；中期（2-3 年）落到产出——搭建或维护自动化与 CI 体系、做质量度量与线上监控、能主导一个方向的测试方案；长期（3-5 年）落到方向——质量架构、效能平台或测试团队管理。面试官真正想听的是「你的规划跟这个岗位的成长路径是否重合」，所以答题时最好能把岗位内容嵌进去（比如京东的测开既写工具也做业务测试）。被问「为什么不考虑转正」「能提前实习吗」这类流程问题，答案要具体到时间点，「能，随时可以，论文已经安排好了」比「应该可以」可信得多。

面经 02 / 06 · Linux、Python 与自动化

3. Linux 与 Python 的实操题：删除当前目录下所有层级中超过 100MB 的文件，命令思路是 find . -type f -size +100M 先看结果，确认无误再加 -delete 或 -exec rm -f {} +；要提醒自己先执行一遍不带删除的版本，避免误删。Python 里的等价写法是 os.walk 或 pathlib.Path.rglob 遍历、用 stat().st_size 判断、再 os.remove，注意跳过符号链接、捕获单个文件的删除异常不让整个遍历中断、并记录日志（删了哪些文件），大批量删除还应加 dry-run 开关。从指定目录抓关键字用 grep -rn "关键字" 目录，配合 --include='*.log'、-A/-B 看上下文，文件是压缩包就用 zgrep。迭代器的要点是「惰性求值 + 一次性」：iter() 拿到迭代器后 next() 逐个产出、耗尽后抛 StopIteration，for 循环与生成器都基于这套协议；它的价值是内存友好（大文件逐行读、流式处理），坑是迭代器只能遍历一次，需要重复遍历时要重新构造或落成列表。

4. Python 多线程在自动化测试里的作用：自动化测试是典型 IO 密集型任务——大量时间花在等接口响应、等浏览器渲染、等文件读写上，所以用多线程能显著缩短整轮用例的执行时间，而 CPython 的 GIL 只影响纯计算任务，对 IO 等待会自动释放锁，因此多线程在这个场景是有效的。为什么不用多进程：进程启动与通信开销大、内存占用成倍增加、共享测试数据与报告汇总更麻烦、调试困难；只有在需要真正并行计算（比如大批量图片比对、加密运算）或者要绕过 GIL 时才用多进程或协程。工程上要注意：线程数不是越多越好（受下游服务承载与本地资源限制），用例之间必须互相隔离（各自独立的账号与数据），共享资源（driver、数据库连接、报告文件）要加锁或用线程本地存储，失败重试与超时要显式设置，否则一个用例卡住会拖死整轮。

面经 07 / 08 · 测试流程与用例设计

5. 测试生命周期与用例要素：生命周期按「需求评审 → 测试计划 → 用例设计 → 环境与数据准备 → 执行与缺陷跟踪 → 回归与验收 → 上线与线上验证 → 复盘」讲，并说清每个阶段的产出物（测试计划、用例、缺陷单、测试报告、线上验证结论）。被问「最重要的环节」时，答需求评审与用例设计最有说服力：缺陷发现得越早修复成本越低，而用例设计决定了后面所有执行的上限；也要承认「线上验证与监控」在工程上是最后一道闸，尤其对交易类链路。用例的要素包括：用例编号与标题、所属模块与优先级、前置条件（账号、数据、环境）、操作步骤（含具体参数）、预期结果（可判定，不要写「正常显示」）、以及善后与是否可自动化。登录界面这类具体题按维度展开：功能（正常登录、密码错误、账号不存在、验证码错误与过期、记住我、多端互踢）、性能（并发登录、响应时间）、弱网（超时、重试、重复提交）、兼容（机型、系统版本、分辨率、输入法）、UI 与可用性（布局、文案、错误提示、键盘遮挡）、安全（密码明文传输、暴力破解限流、账号枚举、日志脱敏）。这一题的加分项是主动说明优先级排序与不测什么（比如第三方登录只验证回调），显示你有取舍意识。

面经 08 · 上线决策与 Redis、SQL

6. 「没测完但项目经理要上线」怎么答：这是典型的风险决策题，答题要落到流程而不是表态。思路是：先把「没测完的部分是什么」讲清楚——剩下的用例覆盖哪些功能、优先级如何、有没有涉及资金与主流程；再量化风险——给出「已覆盖的核心链路 + 未覆盖的边角场景 + 每项可能的线上影响与回滚成本」；然后给出可执行方案——分级发布（灰度、按用户比例放量）、加开关保证可快速回滚、上线窗口避开高峰、同步准备线上验证清单与监控告警阈值、明确回滚触发条件；最后把决策权与责任归属说清：我给出风险评估与建议，是否上线由项目经理/业务负责人拍板，但结论要留痕（邮件或群内记录），事后必须补测缺失部分。这样既不是「没测完就不能上」的僵硬，也不是「领导说上就上」的甩锅。Redis 部分要能说出 HGETALL key 取整个哈希、HGET key field 取单个字段、HMGET 取多个字段，并提醒生产上慎用 HGETALL（大 key 会阻塞单线程）；MySQL 加索引的语句是 ALTER TABLE t ADD INDEX idx_name (col)，查已有索引用 SHOW INDEX FROM t 或 SHOW CREATE TABLE t。阶梯满减优惠券的用例要覆盖边界：恰好达到门槛、差一分未达、跨档位叠加规则、退款后的券状态、并发领取与超发、过期与失效、以及前端展示金额与后端计算结果是否一致。