BIGO 测试开发三面：AI 做 UI 自动化的难点与场景拷打

《面试题目》

1. 请做一下自我介绍。
2. 三段实习的实习时长和离职原因分别是什么？
3. 挑你实习过程中最有含金量的两个产出讲一下。
4. 这两段经历哪一个对你的提升最大？
5. 用 AI 做 UI 自动化，实现过程中遇到的难点讲一下。
6. 如果 UI 自动化实现过程中需要识别的场景非常复杂，并出现元素识别不到的情况，可以从哪些点优化？
7. 如果希望通过自然语言、基于模型生成 Playwright 脚本，你认为难点在哪里，如何优化？
8. 如果用 AI 做接口自动化，对比 AI 做 UI 自动化，两者各自的优势和缺点是什么？
9. 如果有批量的脚本 2000 多条，但是执行效率很低，请做一下脚本优化，把执行耗时降下来。
10. 双十一秒杀活动，数据库库存数据和线上订单显示数据不一致，你认为问题出在哪些方面？
11. 你做 AI 生成测试用例的 skill 的过程中，遇到的问题以及整体设计思路。
12. 你对于工作的业务线和工作内容有没有期望值？
13. 用例设计题：以我们当前的腾讯会议聊天框为例，设计测试用例。
14. 对于测开和纯业务测试，你认为它们业务关注点有哪些差别？
15. 现在有其它 offer 吗，是否可以接受广州 base？

《参考解析》

元素识别不到的优化：先定位是哪一类「识别不到」——定位器失效（前端改版、动态 class、DOM 结构变化）、元素还没出现（时序问题）、元素在视口外或被遮挡（iframe、shadow DOM、弹窗遮罩、虚拟列表未渲染）、还是渲染方式特殊（canvas/WebGL、自绘控件无障碍信息缺失）。对应四类手段：① 定位策略从「脆弱选择器」升级为语义与稳定属性优先——getByRole/getByLabel/data-testid/文本内容的多候选回退链，而不是 nth-child 或带 hash 的 class；② 时序上把固定 sleep 换成显式等待（expect(locator).toBeVisible() 这类自动重试断言），并统一设置合理的超时与重试；③ 结构上要先 frameLocator 进 iframe、穿透 shadow DOM、滚动或搜索定位虚拟列表里的目标项，被遮挡时先关闭遮罩或强制滚动到可视区；④ 兜底能力上引入视觉/多模态模型——截图 + 坐标点击只能当最后手段（分辨率、缩放、多语言一变就废），更稳的做法是让模型结合 DOM 快照和可访问性树来推荐候选定位器，再由此生成稳定的选择器，人工确认一次后沉淀进脚本。工程化层面还要有「元素库」——页面对象模式集中管理定位器，前端改版只改一处；以及失败时自动留截图、DOM 快照、视频与控制台日志，否则排查成本比写脚本还高。

自然语言生成 Playwright 脚本的难点与优化：难点有五个层次。① 需求到断言的信息缺失——用户说「测一下登录」，没说成功标志是什么、异常分支怎么处理，模型只能猜；对策是让模型先产出结构化的测试意图（前置条件、步骤、预期结果）供人确认，再生成代码。② 选择器不可靠——纯文本生成时模型凭空编 class 名，必须把真实的 DOM/可访问性树作为上下文喂给模型（可用 Playwright 的 aria snapshot 或精简 DOM），并约束它优先用 role/label/testid，生成后再做一次「定位器可用性校验」。③ API 幻觉——模型可能写出不存在的 API 或过期写法（waitForTimeout 滥用、旧版 elementHandle 风格），对策是把 Playwright 版本与官方 API 摘要放进上下文，并在沙箱里真的跑一遍，把报错回灌给模型自修复若干轮。④ 等待与稳定性——生成的脚本往往靠 sleep 撑，需要后处理成自动等待断言 + 统一超时 + 重试策略，去掉写死的时长。⑤ 可维护性——生成的是「一堆平铺步骤」而不是可复用的 Page Object / fixture，需要约定目录结构、参数化测试数据、用 storageState 复用登录态，并给生成的脚本打上来源标记便于追溯。整体架构建议是「自然语言 → 结构化用例（JSON/YAML，可评审）→ 模板化生成代码 → 沙箱执行 → 失败回灌自修 → 人工确认入库」，把不确定性挡在结构化用例这一层，而不是让模型直接改仓库里的脚本。

2000+ 脚本执行效率优化：先测量再优化，别上来就并发。① 摸清耗时分布——统计每个脚本耗时、失败重试占比、setup/teardown 占比，通常能找到几个「超级长尾」脚本和大量重复的前置操作。② 并行化：Playwright 原生支持 worker 级并行与分片（--shard），按用例粒度切分；要注意测试间隔离（独立账号/租户、独立数据、独立浏览器上下文），否则并行会带来 flaky。③ 砍掉重复成本：登录态用 storageState 复用，mock/桩掉与本次验证目标无关的第三方依赖，把「造数据」从 UI 操作改成接口或数据库直插（UI 只走被测路径）。④ 分层测试——把大量可以用接口层验证的场景从 UI 层下沉到接口层，UI 只保留真正需要走界面的关键路径，这是收益最大的一步（2000 条里往往有一半根本不需要 UI）。⑤ 调度与缓存：按历史失败率/改动影响面做测试选择（只跑受影响用例）、失败用例优先重跑、分时段跑全量、把结果缓存做增量；CI 上按标签分 smoke / full 两级门禁。⑥ 减少等待——去掉 sleep、合并断言、减少不必要的页面跳转，必要时拦截无关静态资源。⑦ 横向扩容——容器化执行集群（Selenium Grid / Playwright 容器池），按队列动态伸缩。最后要给验收口径：总时长、P95 单用例时长、flaky 率三者一起看，只压时长而把稳定性压崩是负收益。

秒杀场景下库存与订单显示不一致怎么排查：先按「读路径 / 写路径 / 缓存与异步」三段切。① 超卖或写丢失：库存扣减是否用原子操作（Redis DECR/Lua 脚本、DB 的 UPDATE ... WHERE stock >= n 带条件更新）而不是「先查再改」；有没有对同一商品的并发扣减做串行化（分段库存、队列削峰、分布式锁），以及事务边界是否覆盖了扣减与订单创建。② 缓存不一致：库存大量走 Redis，订单落 DB，两者更新顺序（先删缓存还是先写库）与失败补偿决定了一致性窗口；常见坑是「缓存删除失败没重试」「双写并发交叉覆盖」，对策是 Cache-Aside + 延迟双删/订阅 binlog 失效，或干脆让库存以 Redis 为准、DB 做异步对账。③ 异步链路延迟：下单走 MQ 异步落库、订单状态机有中间态（待支付/已锁定未落库），用户在窗口期内看到「扣了库存没订单」是设计使然，但要看消息是否可能丢（发送方确认、消费幂等、死信与重试）、有没有积压。④ 展示层口径：前端展示的是「活动剩余库存」还是「实时库存」，是否算上了未支付订单占用的额度、是否按用户维度做了限购过滤；不同入口（详情页、购物车、订单列表）读的可能不是同一份数据，需要统一口径并明确「最终一致」的时限。⑤ 数据核对：用对账任务按商品维度比对 Redis 计数、DB 库存、有效订单数，把差异分类成「未支付占用」「消息积压」「重复扣减/漏扣」；同时查监控（Redis 慢查询、MQ 堆积、DB 锁等待与热点行更新）与日志里的幂等键重复。答题收尾要给出根治方案：库存扣减统一入口 + 幂等键 + 对账补偿任务 + 前端展示口径明示（「以支付结果为准」），并说明这是个一致性与性能的取舍问题，不是单纯的 bug。

腾讯会议聊天框的测试用例设计：按测试维度搭骨架，覆盖「功能 / 边界 / 兼容 / 性能 / 安全 / 异常」。功能侧：发送文本消息（多行、换行、长文本）、表情/图片/文件/代码块、@某人、引用回复、消息撤回与删除、私聊与全体消息的切换、消息状态（发送中/成功/失败重发）、历史消息加载（上滑分页）、搜索与定位、未读红点计数、多端同步（PC 与手机同时在线互发）。边界：空消息不能发、超长消息截断或阻止、连续快速发送、粘贴超大文本/富文本、特殊字符与 emoji（含组合 emoji、零宽字符）、@不存在的人、消息里带链接。场景组合：会中/会后、主持人/联席主持人/普通参会者/等候室成员/外部成员的不同权限（谁能发全体消息、谁能私聊、禁言状态能否发送）、被踢出或会议结束瞬间发消息、断网重连后消息补发与去重、多设备登录时的消息一致性。界面与兼容：窗口缩放、深浅色、多语言、不同分辨率与操作系统、输入法中文候选与回车行为。性能：消息量大时的滚动流畅度、长会话内存占用、弱网下的发送时延与失败率。安全：XSS 注入（消息里带脚本）、消息加密与内容审核、撤回后是否真的对所有人不可见。每类挑出优先级最高的正向与反向用例写清前置条件、步骤、预期结果，并说明哪些用接口/自动化覆盖、哪些必须手工——这套「先分维度、再分角色与状态、最后标优先级」的结构，比零散罗列用例更能体现测开思维。