这篇文档不是单纯写“测试点清单”，而是按面试表达来组织。
目标是让你在面试里能把这个项目的测试方案讲清楚，既体现：
- 你知道项目怎么工作
- 你知道测试要分层
- 你能落到实际方法和指标
- 你不是只会点点点，而是真的有测试设计能力
这份话术适合你这个项目：
-
后端：
Spring Boot + Spring AI + PostgreSQL + PGVector -
前端：
Vue3 + Vite -
核心能力：
- 通用 AI 对话
- 对话记忆
- 联网搜索
- 基于 Markdown 知识库的智能客服
- RAG 检索增强
- 流式 SSE 输出
一、面试时先怎么开场
如果面试官问：
“你这个 AI 机器人项目怎么测？”
我建议你先用一句总述定住全局：
这个项目我会按前端、后端接口、RAG 知识库、模型回答质量、稳定性和自动化回归六个层面来设计测试，不会只测页面能不能打开，而是会把从文档入库、向量检索到最终回答生成的整条链路拆开验证。
这句话的作用是：
- 先让面试官觉得你有结构化思维
- 不是只会“功能测试”
- 你知道 AI 项目和普通 CRUD 项目的区别
然后你再展开讲。
二、这个项目我会怎么拆测试层次
我通常会拆成 6 层：
- 功能测试
- 接口测试
- RAG 知识库测试
- AI 输出质量测试
- 性能与稳定性测试
- 自动化回归测试
你可以直接这样说：
这个项目和普通后台系统不一样，除了传统功能和接口测试，我还会重点关注 RAG 检索准确性、模型回答可靠性、SSE 流式输出稳定性，以及知识库更新后是否会影响线上回答结果。
三、功能测试方案
这部分最容易讲，也最容易让面试官听懂。
1. 通用聊天功能
要测的点：
- 新建对话是否成功
- 输入消息后是否能正常发起请求
- AI 回答是否正常显示
- 历史对话是否能保存
- 刷新页面后历史消息是否还能展示
- 删除对话后是否真的删除
- 重命名对话是否生效
典型用例：
- 输入正常问题，是否能返回回答
- 输入空消息，前后端是否都拦截
- 长文本消息是否能正常发送
- 连续发送多轮消息，对话记忆是否正确
- 删除后再查询，数据是否已经不存在
2. 智能客服功能
这个项目另一条核心链路是知识库问答。
要测的点：
- 客服问答页面能不能正常进入
- 输入问题后能不能返回答案
- 返回内容是否来自知识库
- 删除知识文件后，答案是否还会命中旧内容
- 修改知识库文件备注是否生效
3. Markdown 文件管理功能
要测的点：
- 文件上传
- 分片上传
- 合并分片
- 文件分页查询
- 编辑备注
- 删除文件
典型场景：
- 正常上传一个 Markdown 文件
- 上传空文件
- 上传非 Markdown 文件
- 上传大文件
- 中途断点续传
- 重复上传同一文件
- 文件已存在时是否支持秒传
四、接口测试方案
如果你是测试开发岗位，面试官通常会更关注你有没有接口测试思维。
你可以这样讲：
我会把前端功能背后的核心接口单独拿出来测，因为 AI 项目很多问题其实不是前端展示错，而是接口参数、流式返回、数据库写入或者异步处理出了问题。
1. 普通聊天接口
后端核心接口大致包括：
/chat/new/chat/completion/chat/list/chat/message/list/chat/delete/chat/summary/rename
重点测试：
- 参数校验是否完整
- 空消息是否拦截
chatId不存在时怎么处理- 模型名称为空是否报错
networkSearch=true/false两条分支是否都正常
/chat/completion 这类流式接口怎么测
这是面试里可以加分的一点。
你可以说：
这个接口是 SSE 流式返回，所以我不会只测最终有没有答案，还会测返回流是否是分块输出、前端是否能持续消费、流结束时是否正常关闭，以及异常中断时有没有兜底提示。
重点检查：
- 是否返回
text/event-stream - 前端是否持续收到 chunk
- 是否出现半截响应
- 异常时连接是否正常中断
- 最终消息是否完整入库
2. 知识库管理接口
重点接口包括：
/customer-service/file/check/customer-service/file/upload-chunk/customer-service/file/merge-chunk/customer-service/file/list/customer-service/file/update/customer-service/file/delete/customer-service/completion
重点测试：
- 文件 MD5 检查逻辑是否正确
- 已上传分片是否能正确返回
- 分片缺失时是否阻止合并
- 合并成功后是否触发向量化
- 删除文件时是否同步删掉向量数据
3. 接口测试方法
你可以说你会用：
- Postman / Apifox 做基础接口调试
- 自动化脚本做回归
- 直接查数据库辅助校验
尤其是这个项目，可以重点说：
对于知识库上传和 RAG 问答，我不会只看接口返回 success，还会去查 PostgreSQL 和 PGVector 对应的数据是否真的落库。
五、RAG 知识库测试方案
这部分是这个项目最有区分度的地方，也是面试最值得展开讲的。
你可以把 RAG 测试拆成 4 层。
1. 入库测试
先测知识库文档能不能正确进入系统。
重点看：
- Markdown 是否成功解析
- 文档是否被切片
- embedding 是否生成成功
- 向量是否写入 PGVector
- metadata 是否完整
你这个项目里尤其要关注：
- Markdown 结构切分是否符合预期
- 水平线
---是否真的切成多个文档 - 代码块和引用块是否被排除
面试里可以这样说：
我会先验证知识文件从上传、分片合并、文档解析到向量入库整条链路是否正确，因为如果这一层错了，后面的检索和回答都不可信。
2. 检索测试
这一层是 RAG 的核心。
重点测试：
- 问题是否能召回正确 chunk
- TopK 里有没有正确知识片段
- 检索结果排序是否合理
- 同义表达能不能命中
- 无关文档会不会误召回
典型问法设计：
- 直接问法
- 同义改写
- 口语化问法
- 带噪音问法
- 容易混淆的问法
举例：
假设知识库里写了“退款 3 个工作日到账”，我会设计：
- 退款多久到账
- 钱什么时候退回来
- 订单取消以后多久能收到退款
- 退款规则是什么
然后重点看：
- 检索出的上下文里有没有“3 个工作日到账”
3. 生成测试
检索对了，不代表回答一定对。
重点测试：
- 答案是否基于知识库
- 是否有幻觉
- 是否遗漏关键约束条件
- 是否把多个文档拼错
- 没有答案时会不会乱编
建议设计这几类问题：
- 知识库中明确有答案的问题
- 多文档综合问题
- 知识库没有答案的问题
- 边界条件问题
- 模棱两可的问题
你可以这样回答：
对于生成层，我会特别关注模型是不是“检索到了也答偏了”，或者“没检索到还硬答”，因为 AI 项目最怕的不是不答，而是看起来很像对、但其实答错。
4. 知识更新一致性测试
这是很多人会漏掉，但你讲出来会加分。
重点看：
- 新文档上传后，问答结果多久生效
- 删除文档后，旧答案是否还会被召回
- 更新同一份知识文件后，旧向量是否被清理
- 重复上传同一份文档会不会出现重复召回
六、AI 输出质量测试方案
AI 项目不能只看接口通不通，还要测回答质量。
1. 我会关注的质量维度
- 准确性
- 完整性
- 一致性
- 可解释性
- 幻觉率
- 稳定性
2. 质量测试怎么做
方法一：构造标准问答集
准备一批固定问题，每个问题有：
- 标准答案
- 允许范围
- 核心关键词
- 对应知识来源
然后发版后固定回归一遍。
方法二：人工评审 + 半自动校验
因为生成式回答不一定逐字一致，所以不能完全按传统接口断言。
我会结合：
- 关键词命中
- 是否包含核心结论
- 是否引用正确信息
- 是否出现明显错误
方法三：分类问题集
按场景分组测试：
- 闲聊类
- 项目问答类
- 知识库问答类
- 联网搜索类
- 时间类 / 无知识类 / 越权类问题
这里你还可以顺手提一下：
比如问“现在几点”这种问题，我会重点关注模型是否编造时间，所以这类问题通常需要产品或后端兜底，而不是单纯依赖大模型自由生成。
七、性能与稳定性测试方案
这部分是测试开发岗位很喜欢问的。
1. 接口性能测试
重点测：
- 普通聊天接口响应时间
- SSE 首包时间
- 整体回答完成时间
- 知识库问答接口响应时间
- 文件上传和合并耗时
常用指标：
- 平均响应时间
- P95 / P99
- 首字节时间
- 错误率
- 超时率
2. 并发测试
重点场景：
- 多用户同时聊天
- 多人同时上传知识文件
- 同时进行问答和知识库维护
- 高并发下 SSE 是否稳定
你可以说：
对 AI 项目来说，并发时不仅要关注接口能不能返回，还要看流式输出会不会串流、截断、乱序，或者数据库消息写入不完整。
3. 稳定性测试
重点看：
- 长时间运行后是否内存增长明显
- 向量化异步任务是否会堆积
- 大文档上传后是否容易失败
- 搜索接口超时后系统如何降级
- 模型调用失败时前后端是否有兜底提示
4. 异常场景测试
非常适合面试展开。
我会设计：
- PostgreSQL 不可用
- PGVector 检索失败
- embedding 接口超时
- 大模型接口报错
- SearXNG 不可用
- 网页抓取超时
看系统是否：
- 正确报错
- 有可理解提示
- 不影响其他模块
- 日志里能快速定位问题
八、安全与兼容性测试方案
虽然这个项目不是纯安全岗，但面试时提一下会显得更完整。
1. 输入安全
重点测试：
- 特殊字符
- 超长输入
- Markdown / HTML 注入
- SQL 注入类 payload
- prompt injection
尤其对于 AI 项目，你可以补一句：
我会专门测 prompt injection，比如用户试图让模型忽略系统规则、泄露系统提示词、伪造知识来源，这类在 AI 项目里比普通 Web 项目更值得关注。
2. 文件上传安全
重点测试：
- 非 Markdown 文件伪装上传
- 超大文件
- 空文件
- 重复上传
- 文件名异常字符
3. 前后端兼容性
重点看：
- Chrome 常用版本
- 不同分辨率下聊天页展示
- 流式输出时滚动和渲染是否正常
九、自动化测试方案
这部分要体现你是测试开发，而不是只会手工测。
1. 自动化分层
我会分成三层：
第一层：接口自动化
覆盖：
- 普通聊天非流式基础接口
- 历史消息查询
- 对话管理
- 知识库文件管理
适合稳定回归。
第二层：RAG 回归集
准备一批固定问题，做自动回归：
- 知识库命中问题
- 未命中问题
- 同义问法问题
- 删除/更新文档后的回归问题
第三层：端到端自动化
如果有时间，我会补 E2E：
- 从前端上传知识文件
- 等待入库
- 发起提问
- 校验页面回答和后台结果
2. 自动化工具思路
你面试时不一定要说死工具名，但可以这样说：
- 接口自动化：Python + requests / pytest
- UI 自动化：Playwright
- 性能测试：JMeter / Locust
- 数据校验：直接查 PostgreSQL
3. 持续回归思路
发版前至少跑：
- 核心接口 smoke
- RAG 标准问答集
- 文件上传 / 删除 / 更新回归
- 聊天主流程回归
十、测试数据怎么设计
这部分说出来也很加分。
1. 普通聊天数据
- 正常问题
- 空问题
- 超长问题
- 多轮上下文问题
- 联网搜索问题
2. 知识库数据
我会准备不同类型的 Markdown：
- 结构清晰文档
- 结构混乱文档
- 很短文档
- 很长文档
- 多个相似知识点文档
- 带代码块和引用块的文档
3. RAG 问题集
按标签分类：
- 精准命中
- 同义改写
- 模糊提问
- 干扰问题
- 无答案问题
十一、面试时怎么讲“我真正做了什么”
如果面试官不想听太理论的，你可以这样收敛成一段实战话术：
这个项目我如果从测试角度来落地，我会先把主链路拆成普通聊天和知识库问答两条线。普通聊天这边重点测对话创建、历史消息、SSE 流式输出和联网搜索。知识库问答这边重点测 Markdown 上传、切片入库、向量检索和最终回答准确性。
在方法上我不会只做页面点点点，而是会结合接口测试、数据库校验、日志分析和标准问答集回归。尤其 RAG 部分，我会把测试拆成入库、检索、生成和知识更新四层，因为很多问题表面上看是模型答错，实际上可能是文档没切好、向量没入库或者检索没命中。
如果要进一步工程化，我会补一套自动化回归集，把核心问题和知识库样本固定下来，发版前自动跑，保证回答质量不会回退。
这段话非常适合面试直接讲。
十二、如果面试官追问“你怎么评估效果”
你可以答：
我会看两类指标：
1. 功能和系统指标
- 接口成功率
- 响应时间
- SSE 中断率
- 文件上传成功率
- 向量化成功率
2. AI 和 RAG 指标
- 检索命中率
- Recall@K
- 答案准确率
- 幻觉率
- 知识更新后生效准确率
十三、面试时的精简版答案
如果现场时间很短，你可以直接说这一版：
这个项目我会从六个方面测：功能、接口、RAG 知识库、AI 输出质量、性能稳定性和自动化回归。
普通聊天我会重点测对话创建、历史消息、联网搜索和 SSE 流式输出；知识库问答我会重点测 Markdown 上传、切片入库、向量检索和最终回答是否基于知识库生成。
对 RAG 我会拆成入库、检索、生成、知识更新四层来测，因为 AI 项目最怕的不是报错，而是看起来答了、其实答错了。
最后我会准备一批标准问答集做自动化回归，结合接口测试、数据库校验和日志分析，保证每次发版核心能力不回退。
十四、你这个项目最值得强调的测试亮点
最后你可以把你这个项目的亮点总结成这 5 个关键词：
SSE 流式输出测试RAG 四层测试模型知识库上传到向量入库的全链路校验AI 幻觉与无答案场景测试标准问答集自动化回归
这 5 个点讲出来，已经比普通“增删改查怎么测”有区分度很多了。
十五、总结
如果只用一句话总结这个项目的测试方案：
我不是把它当成普通 Web 项目来测，而是把它拆成“传统系统测试 + AI/RAG 质量测试 + 稳定性测试”三部分一起做。
这样回答，面试官会更容易觉得你是：
- 懂项目架构的
- 懂测试方法的
- 懂 AI 项目特殊性的
- 有测试开发思维的
