飞猪测试开发一面：RAG 测试用例检索与知识库可靠性

《面试题目》

1. 自我介绍与学校介绍。
2. base 地怎么考虑？
3. 实习期间五次发版的测试节奏是怎样的？每次发版的流程和工作内容是什么？
4. 测试用例的 RAG 检索是怎么做的？用例是 AI 生成的吗？
5. 测试知识库平台是自己构建的吗？怎么构建的？
6. 知识怎么做？如何存储？
7. 怎么评估测试用例的可靠性？
8. 准确率 70%，召回情况和人工测试集不符合，可能有哪些原因？
9. 新需求进来后，知识库如何更新？
10. AI 辅助代码有哪些技巧？
11. AI coding 题：生成测试用例及代码。

《参考解析》

测试知识库与 RAG：先把历史用例、需求文档、接口文档、缺陷记录按项目/模块/版本打标签，清洗后切块，块要保留“用例标题、前置条件、步骤、预期、所属需求”这些结构，不能只切纯文本。向量化后用混合检索（向量 + 关键词/BM25）召回相似用例，再用重排模型筛 top-k，最后交给模型做“参考生成”而不是直接抄。生成的新用例要过规则校验（步骤可执行、预期可判定、覆盖到需求点）和人工抽检，避免把历史错误带进新用例。

可靠性评估：分三层：检索层看召回率、MRR、top-k 命中；生成层看用例可执行率、步骤完整性、预期可判定性、重复率；业务层看新用例能否发现注入缺陷（mutation testing）或覆盖需求矩阵。人工测试集要按模块分层抽样，标注“必须覆盖”的关键场景，不能只随机抽。评估结果要能追溯到具体 bad case，修完回流成回归集。

准确率 70% 与人工集不符：先分清是“检索没召回”还是“召回但生成错”。常见原因：切块破坏了用例结构、embedding 模型与业务语料不匹配、查询改写不足、top-k 太小或太大、知识库版本过期、标注口径不一致、人工集本身有错、以及评测只算整体均值掩盖了长尾模块。排查时按模块和问题类型分层看指标，抽 20 条失败样本逐条归因，再决定是调切分、换模型、加关键词召回还是补数据。不要一上来就调 prompt。

知识更新：新需求进来先更新需求文档和接口契约，再增量切块、增量嵌入，用文档 ID + 内容哈希做幂等，旧版本标记失效而不是直接删；建别名切换索引，灰度验证后再全量。变更要触发回归：受影响模块的用例集重跑，观察召回和生成指标是否下降。知识库要有负责人和过期清理机制，否则会越堆越脏。

AI 辅助代码：有效技巧包括：把任务拆小、给足上下文（接口定义、数据样例、失败日志）、明确约束（语言版本、异常处理、不要引入新依赖）、先让它写测试再写实现、要求解释改动、对生成结果跑静态检查和单测。AI coding 题先写清测试点和预期，再让模型生成用例代码，最后自己补边界（空值、超时、并发、幂等），并说明哪些是自动生成、哪些是人工校验。

发版测试节奏：五次发版说明迭代快，测试要左移：需求评审时介入、开发提测前做冒烟、回归按影响面选而不是全量、线上灰度观察核心指标。每次发版记录准入准出标准、缺陷收敛曲线和回滚预案，面试时用一次具体发版讲清楚“你做了什么、发现了什么、怎么挡住的”。