- 日期：2026-09-21
- 企业与岗位：去哪儿｜测试开发技术一面
- 适用层级：初级—中级
- 来源可信度：本人自述
内容说明
本篇为社区对用户分享面经的整理汇编，旨在帮助求职者了解面试考察方向。问题部分力求忠实还原原帖问答脉络；「参考答案 / 复盘思路」为整理方结合工程实践原创补充，仅供交流参考，不代表官方标准答案。
一、原面经涉及的面试问题（8项）
1. 你的测试Agent项目有什么难点和亮点？
参考答案 / 复盘思路： 回答时先交代项目要解决什么：例如脚本复用率低、回归维护成本高，传统关键词检索找不到可用用例。再按“输入需求→检索已有脚本→Agent选择或修改→执行→收集日志→人工确认”讲完整链路，说明哪些节点由模型决策，哪些由确定性规则控制。亮点不要写“接入了大模型”，而应强调可度量的工程改进，如有效召回率、生成脚本可执行率、人工修改次数及失败归因。最后选一个真实Bad Case讲清失败原因和修复方法；没有测过的数据就不要报具体提升百分比。
2. AI生成UI脚本时，元素定位不稳定，怎么解决？
参考答案 / 复盘思路： 先定位不稳定来自哪里：页面DOM频繁变动、异步渲染时机、iframe或Shadow DOM、还是模型生成了脆弱XPath。观察失败截图、DOM快照和Playwright Trace，并把“找不到元素”和“找到错误元素”分开统计。可优先用稳定的test id、role与可访问名称，配合自动等待及针对状态的显式断言；不要随意增加固定sleep。生成后应先在目标页面做唯一性校验和实际执行，再进入回归。修复是否有效，不只看通过率，还要用已知失败样本验证不会把错误操作误判为成功。
3. 在脚本检索中使用RAG，具体怎么实现？
参考答案 / 复盘思路： 先定义检索对象是整段脚本还是可复用步骤。把既有脚本按业务模块、页面、前置条件、版本和标签切分，保留测试目标、输入、断言及依赖等元信息；构建关键词和向量双路索引。用户描述一个新需求时，先用业务标签缩小范围，再进行语义召回和重排序，把命中的脚本片段及出处交给生成端。关键不是“搜到了相似脚本”，而是判断环境、账号权限和接口版本是否匹配。落地时还要运行候选脚本，并记录检索结果到最终可执行率的转化。
4. 标签检索与语义检索结合后的效果如何衡量？
参考答案 / 复盘思路： 准备一组人工确认的查询—相关脚本对，既包含准确标签查询，也包含口语化描述、同义词和歧义查询。分别跑纯标签、纯向量和混合检索，比较Recall@K、MRR、首条命中率，以及无关脚本进入前K的情况。要把“查找旧脚本”和“找不到时创建新脚本”区分：前者重召回，后者要控制误召回。然后按模块、脚本版本、长短查询拆分指标，检查混合方案究竟在哪些场景改善。最终仍需要人工抽样验证召回内容可否用于实际测试，而非只报向量相似度。
5. 文档持续增加后，怎么判断RAG召回质量有没有下降？
参考答案 / 复盘思路： 文档增量会带来同名脚本、过期页面版本和语义近邻的干扰，因此不能只看索引记录数增长。保留一个冻结的旧版回归查询集，再持续补充代表新业务的增量集；每次更新索引都比较Recall@K、nDCG或MRR，并监控过期文档被错误排在前面的比例。对召回下降的查询记录候选列表和索引版本，分析是分块、Embedding、重排还是元数据过滤出了问题。特别要维护文档失效和版本替换机制；新知识进来了，旧知识没有退场，也可能使RAG回答变差。
6. 自动化断言应该精确到元素位置，还是只判断元素存在？
参考答案 / 复盘思路： 先问清验收目标。若需求是“按钮能提交订单”，元素存在只能证明DOM中有按钮，应该验证它可点击、提交动作被触发、接口成功且订单状态符合预期。若需求明确规定布局、间距或层级，再增加相对位置、截图差异和多分辨率视觉回归。精确坐标断言通常较脆弱，字体、缩放或响应式布局变化都可能导致误报。可把语义定位与业务结果作为主要断言，视觉测试负责设计约束；还要区分元素隐藏、不可用与被其他层遮挡三种不同状态。
7. 如何测试MySQL索引是否生效？
参考答案 / 复盘思路： 首先拿到真实SQL、表结构、索引定义和有代表性的数据量。用EXPLAIN检查访问方式、使用的索引、预估扫描行数及排序或临时表情况；支持时用EXPLAIN ANALYZE查看实际执行耗时与扫描量。注意“显示使用某索引”不等于性能一定更好：低选择性字段、隐式类型转换、函数包裹列或联合索引最左前缀使用方式都可能影响收益。再用冷热缓存和不同数据分布做对比，观察P95耗时、锁等待及写入代价。结论应该是查询在目标负载下是否改善，而非只看key字段有没有值。
8. 设计一个发红包功能的测试用例。
参考答案 / 复盘思路： 先确认红包规则：普通/拼手气红包、总金额与最小金额、领取人数、有效期及退款时点。功能层覆盖金额精度、人数边界、无余额、权限、红包撤回和过期；并发层验证同一用户重复领取、最后一份红包竞争、请求重试和网络超时后状态一致。账务层必须检查总资金守恒，即已领金额、待领金额及已退金额之和与初始金额一致，并核对流水与账户余额。还应测试消息延迟、发放成功但响应丢失等故障，以及监控补偿任务。实际落地用幂等键、唯一约束和对账任务互相兜底。
延伸思考（社区补充）
AI生成脚本的首次通过率由85%提升至95%后，如何设计验证方案，证明这一提升并非以引入误判为代价？
思考方向： 可从固定回归基准集、分别统计误报与漏报口径、抽样复核差异用例等角度展开。这里的85%和95%是用于讨论的假设数据。
