灵犀互娱测试开发一面：接口自动化架构、用例 Skill 与游戏题

《面试题目》

1. 自我介绍。
2. 讲一下滴滴日常业务工作细节。
3. 证件上传审核这个功能的细节测试点，详细讲一下。
4. 接口自动化框架是如何搭建的？讲一下架构。
5. 测试用例生成的 skill 设计思路详细讲解一下。
6. case 可用率和采纳率怎么统计的？
7. 场景题：用户上传图片这个功能涉及到的全部逻辑和流程节点有哪些？
8. 假如司机上传图片后查看看不到信息，bug 的排查思路是什么？
9. 如果通过查询数据库和日志定位的话，具体用到的命令和 SQL 是什么？讲一下思路。
10. 前端页面加载性能优化的方法有哪些？
11. HTTP 和 HTTPS 的区别？
12. 接口请求 GET 和 POST 的区别？
13. TCP 和 UDP 的区别？各自的常见场景？
14. Python 的进程、多线程、协程区别和关系是什么？
15. 百度做的 UI 自动化 skill 实现细节是怎样的？
16. 过程中碰到执行失败的情况怎么解决？
17. 你觉得工作中还有哪些场景可以用到 AI？
18. 为什么会选择测试这个岗位？
19. 测出的 bug 其它部门不认可，如何解决？
20. 手撕（伪代码）：两个数组求交集。
21. 开放题：给你一个铅笔，生活中有哪些使用场景？
22. 从学生到职场的转变，遇到过哪些无法处理的点，怎么解决的？
23. 有自学过哪些课外的计算机知识？
24. 你日常 vibecoding 做产品的话具体是怎么做的？
25. 在校期间有没有和同学协作的经历？
26. 合作时碰到意见分歧的场景，如何解决？
27. 平常玩哪些游戏比较多？
28. 王者荣耀你最喜欢的英雄？
29. 详细讲解一下这个英雄的技能。
30. 如果你来测试这个英雄你会怎么测试？
31. 如果你来设计这个游戏你会怎么优化？
32. 反问：部门业务、一面结果多会儿出？

《参考解析》

接口自动化框架：架构要按分层讲

答「框架怎么搭」时不要罗列工具，按分层与职责讲清楚。建议分五层：用例层（用数据驱动或关键字驱动描述业务场景，一个用例只验证一件事，断言明确）、接口层（封装请求模板、鉴权、签名、加解密、公共参数与重试，业务用例不直接写 HTTP 细节）、数据层（测试数据与期望结果分离，用 YAML/Excel/数据库存，支持环境切换与数据清理）、执行层（并发执行、失败重试、用例依赖与顺序控制、环境隔离）、报告与通知层（结果落库、失败自动重试与归因分类、推送群/看板）。要讲清几个关键设计决定：断言放在哪（业务断言与协议断言分开，避免把 200 当成通过）、如何保证用例独立性（每个用例自己造数据、自己清理，或用事务回滚）、如何做环境隔离（配置中心/环境变量，禁止把生产地址写进用例）、以及失败归因（区分环境问题、数据问题、真 bug，否则用例一多就没人看结果）。最后给度量：用例通过率、稳定性（同一版本重复跑的抖动）、执行时长、以及缺陷拦截数——这四项比「有多少条用例」更能说明框架的价值。

测试用例生成 Skill：可用率与采纳率怎么统计

这类 AI 辅助用例生成的系统，讲清链路最重要：输入（需求文档、接口定义、历史用例、线上缺陷）→ 切分与检索（把需求拆成可测点，检索相似历史用例）→ 生成（要求输出结构化用例：前提、步骤、预期，并标注来源与不确定项）→ 人工评审与采纳 → 回流（被采纳/修改/丢弃的样本作为下一轮的改进依据）。可用率与采纳率的统计口径必须显式定义：采纳率通常是「被写进用例库的条数 / 生成总条数」，可用率可以是「通过基本校验（格式完整、步骤可执行、有明确预期）的条数 / 生成总条数」或「一次评审即通过」；要按维度拆开看——按需求类型、按业务模块、按生成模型的版本，否则平均值会掩盖问题；同时要防「刷采纳率」的动机，比如把简单重复的用例无限生成，所以还应该看「新增覆盖的有效测试点数量」与「拦截到的缺陷数」。改进闭环是这套系统的核心：把人工修改的 diff 收集起来，反推提示词与检索策略该改哪里，这比换模型更有效。

场景题：上传图片的全链路与「看不到」的排查

「用户上传图片涉及的全部逻辑和流程节点」按端到端环节列举：选择/拍照（客户端权限、格式与大小限制、压缩与方向校正）→ 上传（网络切换、分片与断点续传、重试与幂等、超时）→ 接入层（网关鉴权、限流、大小与类型校验、病毒/内容安全扫描）→ 存储（对象存储直传还是服务端中转、生成唯一 key、多副本与 CDN 回源）→ 元数据落库（绑定用户与业务单号、状态机：上传中/成功/失败）→ 异步处理（转码/水印/OCR、回调通知）→ 展示（列表查询接口、缓存、鉴权与数据权限、前端渲染与图片加载失败兜底）→ 运维面（监控、日志、告警、清理与生命周期）。测试点要覆盖每层的异常分支：权限、格式、超大文件、重复上传、断网重传、并发上传、跨端一致性、以及安全（越权访问他人图片、恶意文件）。

「司机上传后看不到」的排查思路要按分层定位：先确认范围（是个别用户还是全部、某个端还是所有端、某个时间段还是持续），再按链路从后往前或从前往后切。客户端侧看请求是否发出、上传是否成功、返回的图片 ID 是否拿到；服务端看接口的成功率与耗时、是否被限流或鉴权拒绝；存储侧看对象是否存在（用返回的 key 直接访问）、是否是权限或签名过期；数据库看元数据是否落库、状态是否卡在「上传中」、绑定关系是否正确（用户/司机/业务单号）；展示侧看列表接口是否返回该记录、是否有缓存未失效、是否有数据权限过滤掉了。日志排查要给出具体动作：按 traceId 或用户 ID 串起全链路日志、按时间窗 grep 关键错误码、用 tail -f/grep -C 看上下文、看接口出入参与返回码；SQL 侧要能写出定位语句，比如按用户 ID 与时间查上传记录 select id, status, url, created_at from upload_record where user_id = ? order by created_at desc limit 20;，按状态统计卡住的比例 select status, count(*) from upload_record where created_at > now() - interval 1 day group by status;，以及检查是否存在但状态异常的记录。答题时把「先定界、再分层、用数据说话」这三步说明白，比背命令重要。

八股：HTTP/HTTPS、GET/POST、TCP/UDP、Python 并发

HTTP 与 HTTPS 的区别在安全层：HTTPS 在 HTTP 与 TCP 之间加了 TLS，提供机密性（加密）、完整性（防篡改）与身份认证（证书链校验），默认端口 443 对 80，代价是握手往返与加解密开销；实践上要能提到证书类型、TLS 版本演进与「抓包可见」这一点在排查中的区别。GET 与 POST 的差别要讲清语义而非传说：GET 用于获取资源、参数放 URL、可被缓存与收藏、幂等且安全；POST 用于提交数据、参数在 body、不幂等、不缓存；所谓「GET 有长度限制」其实是浏览器与服务器的实现限制而非协议规定。TCP 与 UDP 的差别是可靠与不可靠的取舍：TCP 面向连接、有序、有重传与流量控制、开销大；UDP 无连接、不保证顺序与到达、开销小、延迟低，常见场景是 DNS、音视频、游戏实时同步、QUIC；选择依据是「能不能容忍丢包与乱序、是否需要极低延迟」。Python 的进程、线程、协程要按「隔离级别与调度者」讲：进程有独立内存、可绕过 GIL 做并行计算，代价是创建与通信开销；线程共享内存、受 GIL 限制在 CPU 密集任务上无法并行但适合 IO 密集；协程是用户态调度、单线程内通过事件循环切换、切换成本最低，适合高并发 IO，但要求代码是非阻塞的（一旦调用阻塞库就会卡住事件循环）。要能给出实践结论：CPU 密集用多进程或把计算下沉到 C 扩展/其他语言，IO 密集用协程（asyncio/aiohttp），混合场景用进程池加协程。

开放题与职业选择

「给你一支铅笔，生活中有哪些使用场景」这类题没有标准答案，考的是发散与分类能力：可以按功能分类（书写、涂画、当书签、卷纸轴、通孔器、当楔子、当陀螺轴、当尺子做参照、当拨片、临时导电体），再按场景归类（办公、维修、手工、娱乐、紧急替代工具），并主动收一句「优先考虑低成本与不破坏他物的用法」。游戏相关的问题（玩什么游戏、最喜欢的英雄、技能讲解、怎么测试这个英雄、怎么优化这个游戏）是测试岗的常见切入点，背后考的是你能不能把「玩」翻译成测试维度：技能数值与描述是否一致（数值、冷却、范围、抬手与后摇）、边界与组合（技能连招、与装备/其他英雄的交互、极端数值）、状态异常（死亡瞬间释放、被控期间释放、断线与重连）、以及体验层面（平衡性、可读性、匹配与新手引导）。回答时要先给出这些维度，再落到具体英雄上，结构和内容都占分。至于「为什么选测试」和「bug 不被认可怎么办」，前者给真实动机（喜欢把系统边界摸清、对质量与工程效率有兴趣），后者按流程答：先用证据把问题说清（复现步骤、日志、影响面、数据），再对齐判定标准（是不是需求理解不一致），必要时请共同上级或产品裁定，并把结论沉淀成用例——避免把技术分歧变成人际对立。