LLM 接口自动化和传统 REST 有何不同？

👔 Raina面试官： LLM 应用的接口自动化和传统 REST API 自动化有何不同？

🙋 候选人：

核心差异：断言从精确匹配变成结构化+语义+rubric，测试从确定性变成采样+统计。
REST：status code、固定 JSON、幂等、毫秒级响应可严格 assert。LLM API：流式 SSE 要测 chunk 顺序和首 token 延迟；输出非确定，assert 改 schema 校验 + 关键词/regex 软断言 + judge 评分；多轮要维护 session/context。
还要测 token 用量、finish_reason、tool_calls 结构，以及超时重试对上下文的影响。

👔 Raina面试官： CI 里怎么做才稳？

🙋 候选人：

分层：mock 测工程逻辑，采样测真实模型。
PR 门禁：mock LLM 回固定响应，验路由、鉴权、流式协议、错误处理。nightly：抽 10% Eval case 打真模型，聚合通过率。别把 flaky 语义断言卡在每次 commit 上。

Mock 模型响应 vs 调用真实模型，测试环境里怎么选？

👔 Raina面试官： Mock 模型响应和调真实模型，测试环境里你怎么选？

🙋 候选人：

分层用：工程链路用 Mock，质量门禁用真实模型。
Mock 适合测 API 契约、超时重试、流式解析、错误码映射——快、稳、不花钱。真实模型适合 Eval、prompt 回归、E2E 对话质量——能暴露模型行为变化。
CI 里 PR 门禁优先 Mock + 小样本真实调用；release 前或 nightly 跑真实模型 Eval。

👔 Raina面试官： Mock 怎么设计才不容易和真模型脱节？

🙋 候选人：

录golden response fixture，覆盖流式 chunk、空输出、拒答、tool call 几种形态。
定期用真实模型刷新 fixture，对比 schema 和 token 边界。Mock 只固定输出形态，不固定具体文案。

确定性测试和采样测试在 CI 里怎么搭配？

👔 Raina面试官： 确定性测试和 Sampling 在 CI 里怎么搭配？

🙋 候选人：

PR 跑确定性 + 小样本采样，nightly 扩大采样量。
确定性：API 契约、路由、鉴权、流式协议、固定 seed 的回归 case——必须 100% pass。采样：从 Eval 集随机抽 N 条（如 20～50），跑 LLM judge 或 rubric，看聚合分数是否低于基线。
采样要有固定 random seed 或可复现的 stratified 子集，方便 diff 对比。

👔 Raina面试官： 采样失败了算 block merge 吗？

🙋 候选人：

看阈值设计。通常显著退化 block，边缘波动 warn + 人工 triage。
PR 采样集要小但敏感（核心场景）；全量统计留给 nightly，避免 CI 又慢又 flaky。

Prompt / 模型 / 配置变更，CI 应触发哪些测试？

👔 Raina面试官： Prompt、模型或配置变了，CI 流水线应该触发哪些测试阶段？

🙋 候选人：

按变更类型映射：动什么跑什么层，避免一刀切全量。
Prompt 变 → prompt regression + 相关 Eval 子集 + E2E smoke。模型变 → 全量 Eval + 性能基准 + 安全红队抽样。配置变（temperature、max_tokens）→ 受影响场景的 Eval + 流式/超时测试。纯 UI 文案不动模型 → 只跑 UI 层。
维护 change→stage 矩阵写进 pipeline 配置，MR 标签自动选 stage。

👔 Raina面试官： 怎么防止漏跑？

🙋 候选人：

文件路径触发规则 + required check 清单。
改 prompts/ 目录必须过 eval-prompt stage；改 model endpoint 必须过 eval-full。merge 前 bot 校验 checklist。

Playwright / Selenium 测 AI 对话界面要注意什么？

👔 Raina面试官： 用 Playwright 或 Selenium 测 AI 前端对话界面，有哪些特殊注意点？

🙋 候选人：

核心难点是异步流式输出和非确定性内容，不能像传统页面等固定元素出现就完事。
要等 streaming 结束信号（停止按钮消失、done 事件、最后一条 message 状态 settled）。超时设得比 REST 长很多。
测输入框、发送按钮、历史加载、错误 toast、重试按钮这些确定性 UI；回答正文尽量不测精确文本。

👔 Raina面试官： 流式过程中怎么断言？

🙋 候选人：

断言流式行为本身：首字出现时间、chunk 递增、最终 message 非空、无 JS 报错。
可 hook 前端 SSE/WebSocket 事件做观测，比纯 DOM 轮询更稳。

对话 UI 断言怎么写？固定文本够吗？

👔 Raina面试官： 对话 UI 的断言怎么写？固定文本匹配够用吗？

🙋 候选人：

不够。固定文本只适合模板化、确定性回复，LLM 自由生成几乎每次措辞不同。
分层断言：UI 层测元素状态、消息条数、角色标签、loading 态；内容层用关键词/正则/结构化字段（如 JSON 卡片）；质量层交给 Eval 或 API 层 judge，不在 UI 测全文。
若产品要求 citation 链接，断言 href 模式和 doc id，不断言 surrounding 文案。

👔 Raina面试官： 那怎么防止 UI 显示了乱码或空白？

🙋 候选人：

用结构 + 长度 + 禁止模式：message body length > N、不含 error placeholder、markdown 渲染后可见。
空白气泡、重复渲染、截断异常用 DOM 结构检查，比 match 某句话可靠。

快照测试在 AI 产品里适用吗？

👔 Raina面试官： 快照测试（Snapshot）在 AI 产品里适用吗？

🙋 候选人：

部分适用：测稳定 UI 骨架，不测 LLM 正文。
适合消息气泡布局、按钮组、空态页、设置面板——DOM 结构或 CSS snapshot。不适合 assistant 回复全文，模型一改就全红，维护成本爆炸。
若 snapshot 含动态区，用 placeholder 或 mask 掉 message content 再比。

👔 Raina面试官： 视觉快照（screenshot）呢？

🙋 候选人：

同样mask 动态文本区，只比 chrome 和排版。
或只对 mock 固定回复的 demo 模式做 visual regression，和生产 LLM 路径分开。

测试数据 PII 怎么脱敏？合规要求有哪些？

👔 Raina面试官： 测试数据里的 PII 怎么脱敏？合规上有哪些要求？

🙋 候选人：

原则：测试环境不用生产明文 PII，必须用时脱敏 + 最小权限 + 留存期限。
脱敏手段：替换、哈希、合成数据（Faker）、tokenization。日志和 Eval 导出同样脱敏，防止 judge 或截图外泄。
合规：GDPR/个保法要求目的限定、可删除、跨境传输评估；金融医疗还要审计谁访问了哪条测试数据。

👔 Raina面试官： 从线上 bad case 回流 Eval 怎么处理？

🙋 候选人：

走脱敏 pipeline：自动 NER 识别 + 人工复核 + 批准入库。
原始对话不进 git；Eval 里只留 sanitized 版本和 internal case id。

Feature Flag 和灰度发布时测试怎么配合？

👔 Raina面试官： Feature Flag 和灰度发布时，测试怎么配合？

🙋 候选人：

每个 flag 要有on/off 双路径测试矩阵，灰度期间两边都得能跑。
CI 默认跑 flag=on（新能力）+ flag=off（回归旧行为）。灰度用同一套 Eval，按 cohort 标签分桶看指标，不能只看全局平均。
kill switch 和 rollback 也要测——flag 关掉后旧路径仍 pass。

👔 Raina面试官： 灰度中发现问题怎么定位？

🙋 候选人：

日志带flag variant + model version + prompt hash，测试报告按 variant 拆分。
对比 canary 和 baseline 的 Eval diff，而不是混在一个 dashboard 里。

全量 Eval 和 PR 轻量 Eval 怎么分层？

👔 Raina面试官： nightly / weekly 全量 Eval 和 PR 门禁轻量 Eval，怎么分层？

🙋 候选人：

三层：PR smoke → nightly core → weekly/full 全量。
PR：50～100 条高价值 case，10 分钟内出分，卡明显退化。Nightly：核心 Eval 全集 + 采样多 seed，对比昨日基线。Weekly：全量 + 新 bad case + 安全/多语言等长尾集。
每层有独立阈值和 owner，PR 失败 block merge，nightly 失败 block release candidate。

👔 Raina面试官： 轻量集怎么选才不漏大问题？

🙋 候选人：

用分层抽样 + 历史高失败率 case 必含。
按场景 tag 保证覆盖：RAG、tool、拒答、安全各有一定比例。每月用 full Eval 校验 smoke 集代表性。