京东 零售 测试开发

1. 自我介绍2. 简单介绍一下你之前负责的项目以及工作内容3. 你刚刚说了测试的流程，那你在其中负责主要是什么内容？4. 你实习的时候，测的是哪些模块？5. 说下bug的生命周期6. 如果开发觉得你提的bug不是问题，你会怎么做？7. bug组成要素有哪些？8. 如果游戏闪退，你会提什么bug等级的单？9. 测试用例的设计方法有哪些？10. 针对王者荣耀妲己的大招设计测试用例11. 针对闪耀暖暖的付费衣服，你说下测试点12. 能接受高强度加班嘛？13. 反问

整体面试还是不错的，但是没后续了，不知道是哪里出了问题1. 项目拷打2. 你们从 PRD 到 design.md 这一层，是怎么保证“需求不丢失”的？AI 自检具体是怎么做的，有没有误判的情况？3. 你刚才提到“需求-代码映射”，能不能举一个具体例子，说明你们是如何做到精确定位到某个文件甚至某一段逻辑的？4. 你们的 tasks.md 拆分粒度是怎么控制的？拆太细和拆太粗分别会带来什么问题？5. 在 Multi-Agent 协作中，状态是怎么传递的？是靠文件、内存还是某种中心化状态管理？6. 你们有没有遇到 Agent 之间“决策冲突”的情况？比如设计和代码生成不一致，是怎么解决的？7. 你们为什么选择“技术方案驱动”，而不是直接让 AI 从 PRD 出码？8. 你们 `.catpaw/rules` 这套知识库，和像 OpenClaw 这种基于 RAG 的 memory，有什么区别？9. 如果知识库内容过多，AI 也会有上下文压力，你们是怎么做裁剪或者命中的？10. 你们有没有做 embedding 检索？11. 如果知识库里的内容是错的或者过期了，会不会对 AI 产生误导？你们怎么治理这个问题？12. 在一个非常大的存量项目里（比如几十万行代码），你们是怎么让 AI 快速理解项目结构的？13. 你们现在 AI 出码留用率是 50%+，那剩下 50% 主要问题出在哪里？14. 在复杂业务场景下，AI 出码质量下降，你觉得是什么问题？15. AI 有没有出现过“看起来对，但其实逻辑是错的”这种情况？16. 你们有没有做过代码 diff 级别的控制，比如限制 AI 修改范围？17. 你们基于 Playwright 做自动化测试，那测试用例是怎么保证覆盖率的？有没有评估指标？18. AI 自动修复 bug 的成功率大概是多少？有没有出现过“修复引入新 bug”的情况？19. UI 偏差这种问题你们怎么检测？20. 如果测试通过了，但业务逻辑是错的，这一层你们怎么解决？21. 你刚才说整体效率提升 20%，这个数据是怎么统计的22. AI 代码量提升很多，那你怎么评估“有效代码”和“冗余代码”的比例？

相信准备从事软件测试的小伙伴，面试时经常会遇到这个非常令人困扰的问题。所以今天我想结合自己的理解，聊聊我对这个问题的看法。首先，面对这种问题，我们真正要做的，不是去猜面试官到底想考察什么，而是把自己真正代入到对应的工作场景里。最好的方式，就是结合你的真实实习经历或者团队项目去理解。你可以想象这样一个场景：你按照团队当前的需求文档和测试标准去执行测试，结果发现系统表现和预期不一致，于是提了一个 Bug；但开发看完之后反手来一句：“这不是 Bug。”这时候你该怎么办？没有实习经历的小伙伴，或者项目一直是自己独立开发、独立测试的人，看到这种问题可能会很疑惑，甚至会觉得有点像左右脑互搏：要么第一反应是“这个开发不专业”，要么就是“是不是我测试工作没做好”。但实际上，这两种理解很多时候都不准确。真正做过实习、尤其是在中小公司待过的小伙伴，对这种情况一般都不会太陌生。因为现实里开发“不认 Bug”，很多时候并不是说他连最基本的底层逻辑错误都不承认——如果真到了这种程度，那确实就不是正常协作问题了。更常见的情况是：你发现的并不是那种会直接影响主流程、核心业务、系统正确性的重大缺陷，而是一些可优化、也可以暂时不优化的问题。比如说，公司表面上模仿大厂流程，制定了一套比较完整的需求文档和测试标准；但实际运行过程中，团队早就已经默认按另一套业务规则在长期稳定运转了。你作为临时加入的新测试，是严格按照文档去测的，所以发现了不一致，这其实很正常。又或者说，公司的业务标准已经变化了，但测试文档没有及时更新；这时候你按旧标准提 Bug，本质上也未必是你错，更未必是开发工作没做好，而是标准同步本身出了问题。所以这种时候，你当然不能上来就把问题理解成“开发不专业”，也不能一发现对方不认就立刻怀疑自己是不是出错了。真正成熟一点的处理方式，应该是先把这个问题放回到业务和标准里看。对于前面这种很常见的情况，实际工作里大家往往会很快接受公司真实运行的那套规则，不再拘泥于纸面标准。但如果你在面试里直接说“那我就接受了”，面试官往往又会觉得你这个测试没有原则。所以更合适的表达方式其实是：先和开发充分沟通，确认分歧到底来自哪里——是需求理解不一致、文档同步不及时，还是业务规则已经发生变化；然后把问题做好记录，根据影响范围将其归类为待优化项或者低优先级问题，同时推动测试标准和实际业务规则对齐。如果后续开发进行了优化，那就再做回归验证后关闭；如果最终确认现阶段不影响核心链路，也可以明确记录原因和处理结论，避免后面重复争议。回到“你认为是 Bug，开发不认为是 Bug 怎么办”这个问题本身，我认为比较好的回答方式应该是这样的：我在实习/项目中确实遇到过类似情况。面对这类分歧，我会先回到需求文档、原型、业务规则和实际场景中确认判断依据。如果与开发、产品/策划沟通后发现问题本质上是标准文档更新不及时，或者团队实际执行标准和文档存在偏差，我会把这个问题详细记录下来，归为待优化项，并推动测试文档和业务标准尽快对齐。如果它确实存在体验或规范上的偏差，但短期内不影响主流程和核心业务，我会结合影响范围合理定级，并持续跟进后续版本是否优化；如果最终确认是真实缺陷，我也会补充复现路径、影响范围和业务风险，继续推动问题解决，并在修复后完成回归验证。这个回答的意义在于，它既能体现你在真实业务场景中的沟通和协作能力，也能体现出你作为测试的基本准则是合格的：你不是一味硬刚开发，也不是别人一句“不是 Bug”你就算了，而是会基于标准、业务和风险去判断，并且把问题处理到位。而且这个回答还有一个好处，就是它天然帮你把问题边界框住了。因为如果面试官在你已经明确说明“先核实标准、再确认归因、再记录推进”的前提下，还继续追问“那如果开发就是不认真实缺陷怎么办”，那其实已经不是在考察你会不会处理问题了，而更像是在故意把协作问题极端化。你要明白，测试不是去对开发做恶意猜想的，正如你也不能对产品、策划先做恶意猜想一样。真正成熟的团队协作，讲的是基于事实和标准推进问题，而不是先预设别人不专业、别人不负责、别人故意卡你。以上就是我对这个问题的一些个人理解，也欢迎大家补充讨论，希望这篇内容能真正帮到正在准备测试面试的小伙伴。

攒攒人品！有面试过同岗的朋友欢迎评论区交流1.实习拷打2.项目拷打3.你们的 Agent 是单 Agent 还是多 Agent？为什么这么设计？有没有考虑过另一种方案？4.Agent 任务是怎么拆分的？拆分粒度是怎么决定的？5.上下文是怎么构建的？你们怎么避免上下文过长或者信息污染？6.如果上下文窗口不够，你优先保留哪些信息？为什么？7.你们做代码理解的时候，AST、调用关系这些信息是怎么用起来的？8.单测生成里，哪些代码其实不适合生成单测？你们是怎么识别并过滤的？9.覆盖率高但测试质量很差，这种情况你见过吗？你们是怎么解决的？10.mock在单测里什么时候是必须的？什么时候反而会带来问题？11.如果一个函数依赖数据库和RPC，你怎么让模型生成的单测还能稳定运行？12.你们怎么评估生成单测的质量？除了覆盖率，还有哪些指标？13.LLM的输入到底是什么？模型真正看到的是什么？14.self attention的核心作用是什么，为什么要拆成 QKV？为什么attention 可以建模长距离关系，15.为什么需要multi-head为什么 attention可以看成动态加权16.同一个 token的 Q、K、V 为什么不一样？17.attention复杂度很高，如果上下文特别长，你会怎么优化？18.模型产生幻觉的时候，一般是什么原因？工程上有什么办法降低19.Python有多线程吗？GIL 是干什么的？什么时候多线程是有用的？20.讲一下C++从源码到可执行文件的流程。21.手撕：给定数组的区间中位数之和:给定一个长度为n的数nums，一个区间 [l, r] 的 中位数 为：如果区间长度是奇数：排序后中间的数，如果是偶数：排序后靠左的那个数，要求：计算所有子数组的中位数之和