智能体助手项目测试报告-171主机测评

一、项目背景

本项目是一个面向程序员学习、知识沉淀与智能问答场景的 AI 智能体助手系统，主要支持普通聊天、RAG 知识库问答、工具调用、MCP 工具注册、ReAct 多步推理、记忆系统、沙箱命令执行等能力。

项目整体由前端页面、后端 API 服务和多种基础设施组件组成。后端基于 FastAPI 实现，前端提供聊天输入、知识库开关、工具选择、文档上传、MCP 工具注册等操作入口。系统底层结合向量检索、BM25 检索、图关系检索、数据库存储、消息流转和工具编排，形成从用户输入到智能回答生成的完整链路。

本次测试工作的目标不是简单验证接口是否可用，而是围绕智能体项目的核心链路，建立一套较完整的测试开发体系，包括：

功能测试设计
接口自动化测试
UI 自动化测试
RAG 质量评测
Allure 可视化报告
问题发现与修复
测试报告沉淀

通过本次测试，项目形成了从需求理解、测试点拆分、测试用例设计、自动化执行、质量评测到报告输出的完整闭环。

二、项目测试目标

本次测试主要目标如下：

验证智能体助手核心功能是否符合预期，包括普通聊天、知识库问答、工具调用、记忆系统、MCP 工具注册和沙箱执行等功能。

验证后端 API 在正常参数、异常参数、边界输入和依赖降级场景下的稳定性。

验证前端页面在浏览器中的核心交互链路是否正常，包括输入、发送、上传、工具选择、RAG 开关、异常提示等。

验证 RAG 检索链路的召回质量，而不仅仅是验证 RAG 接口是否返回 200。

通过 Allure 报告提升自动化测试结果的可视化展示能力。

输出可复用的测试文档、测试用例、自动化脚本和测试报告。

三、测试范围

本次测试范围包括功能测试、接口自动化测试、UI 自动化测试和 RAG 质量评测四部分。

测试类型测试目标数量执行方式

功能测试	从用户视角验证业务功能是否可用	84 条	测试设计文档 + 冒烟验证
接口自动化测试	验证后端 API 参数、响应、异常和降级能力	50 条	pytest + requests + YAML
UI 自动化测试	验证浏览器页面交互和 DOM 渲染	24 条	pytest + Playwright + YAML
RAG 质量评测	验证检索结果是否准确、排序是否合理	5 项指标检查	Golden Queries + Benchmark
项目原有 pytest 测试	验证项目已有单元/集成逻辑	23 条	pytest

本地全量自动化执行结果为：

102/102 passed

其中：

102 passed = 23 条项目原有 pytest + 50 条接口自动化 + 24 条 UI 自动化 + 5 条 RAG 质量评测检查项

需要特别说明：

84 条功能测试用例属于功能测试设计和冒烟验证依据，不计入 102 条 pytest 自动化执行结果。

因此，项目当前测试成果可以准确表述为：

本项目完成 84 条功能测试设计用例，落地 79 条新增自动化测试与质量检查项，结合项目原有 23 条 pytest 测试，本地全量自动化执行结果为 102/102 passed。

四、测试环境

4.1 软件环境

环境项内容

操作系统	Windows / 本地开发环境
后端语言	Python
后端框架	FastAPI
自动化测试框架	pytest
接口测试工具	requests
UI 自动化工具	Playwright
测试数据管理	YAML
测试报告	Markdown + Allure
容器化环境	Docker / Docker Compose
数据库与中间件	PostgreSQL、Kafka 等
检索组件	Milvus、Elasticsearch BM25、Neo4j
版本管理	Git

4.2 测试执行方式

测试主要在本地环境执行，执行方式包括：

pytest
pytest tests/api -v
pytest tests/ui -v
pytest tests/rag_eval -v
pytest –alluredir=reports/allure-results

当前测试结果均来自本地 pytest 执行结果。

五、测试策略

本项目采用分层测试策略，将测试工作拆分为四个层次。

5.1 功能测试层

功能测试主要从用户视角出发，验证用户能否完成核心操作，操作结果是否符合预期。

重点覆盖：

普通聊天
RAG 知识库问答
工具调用
MCP 工具注册
ReAct 多步推理
记忆系统
沙箱命令执行
前端页面交互
配置与降级

功能测试更适合用于梳理业务场景、发现需求遗漏和验证整体功能闭环。

5.2 接口自动化层

接口自动化主要验证后端 API 的稳定性，重点覆盖：

状态码
响应字段
JSON 结构
异常参数
边界输入
依赖降级
接口返回一致性

接口自动化稳定性较高，适合作为本地回归测试的核心部分。

5.3 UI 自动化层

UI 自动化主要验证浏览器中的真实用户操作链路，例如：

页面加载
输入消息
点击发送
Enter 快捷发送
上传文件
切换 RAG 开关
选择工具
注册 MCP 工具
异常提示展示
移动端输入可用性

由于 UI 自动化维护成本较高，因此本项目只覆盖关键路径，不盲目追求用例数量。

5.4 RAG 质量评测层

RAG 质量评测单独设计，不与普通接口测试混在一起。

普通接口测试只能说明：

/api/rag/query 是否能返回响应

但 RAG 质量评测要回答的是：

检索结果是否命中标准证据？
正确 chunk 是否排在前面？
Dense、BM25、Hybrid 哪种检索策略效果更好？

因此，本项目单独构建 Golden Queries 和标准证据 Chunk，对 RAG 检索质量进行量化评估。

六、测试方法

本次测试设计使用了以下测试方法：

测试方法在项目中的应用

等价类划分	将聊天输入分为中文、英文、长文本、空输入、特殊字符输入等
边界值分析	覆盖空消息、空文件、缺少参数、最小合法参数、超长输入等
场景法	设计“上传文档 -> 开启知识库 -> 发起 RAG 查询 -> 展示回答”的完整链路
状态迁移法	验证 RAG 开关、工具选择、会话状态、记忆状态的变化
错误推测法	覆盖 MCP 缺少 name、endpoint 为空、文件字段错误、未知工具等
数据驱动	接口和 UI 用例使用 YAML 统一管理测试数据
Mock 技术	UI 自动化 mock /api/* 响应，避免依赖真实 LLM 和数据库
分层断言	分别断言状态码、字段、文本、非空值、降级状态和页面 DOM
基准评测	使用 Golden Queries 对 RAG 检索质量进行可重复评估

七、功能测试设计

7.1 功能测试总体说明

功能测试主要站在用户视角设计，重点验证：

用户是否能完成操作
页面是否给出正确反馈
后端是否返回符合预期的数据
异常场景是否有合理提示
依赖缺失时系统是否能够降级运行

本次共设计 84 条功能测试用例，覆盖智能体项目的主要功能模块。

7.2 功能测试模块划分

模块测试重点

服务启动与状态	健康检查、系统运行状态、依赖降级状态
普通聊天	中文聊天、英文聊天、长文本、多轮对话、空输入
RAG 知识库	文档上传、知识库查询、空知识库提示、上传后查询
工具调用	时间、天气、搜索、知识库检索等工具调用
ReAct 多步推理	多意图问题是否进入多步工具编排
MCP 工具注册	注册工具、参数缺失、工具列表变化
记忆系统	短期记忆、长期记忆、偏好信息展示
沙箱执行	命令执行、mock 降级、安全命令验证
前端页面	页面布局、输入框、按钮、状态提示、响应式布局
配置与降级	外部服务缺失时系统是否仍可用

7.3 功能测试用例编号规范

功能测试用例按照模块进行编号：

编号前缀模块

FT_STATUS	服务状态
FT_CHAT	普通聊天
FT_RAG	RAG 知识库
FT_TOOL	工具调用
FT_REACT	ReAct 多步推理
FT_MCP	MCP 工具注册
FT_MEMORY	记忆系统
FT_SANDBOX	沙箱执行
FT_UI	前端页面
FT_DEGRADE	配置与降级

7.4 功能测试用例示例

用例编号模块测试点前置条件操作步骤预期结果

FT_CHAT_001	普通聊天	中文消息发送	服务正常启动	输入中文问题并点击发送	页面展示用户消息和助手回复
FT_CHAT_002	普通聊天	空输入发送	页面已加载	输入框为空时点击发送	不发送请求或展示空输入提示
FT_RAG_001	RAG 知识库	上传文档后查询	已上传有效文档	开启知识库并输入相关问题	返回与文档相关的回答
FT_RAG_002	RAG 知识库	空知识库查询	未上传文档	开启知识库并发起查询	返回请先上传文档或无知识库提示
FT_TOOL_001	工具调用	选择工具后发送	工具列表正常返回	选择工具并发送问题	回复中展示工具调用结果
FT_MCP_001	MCP 工具注册	正常注册工具	MCP 表单可用	输入 name、endpoint 等信息并提交	工具注册成功，工具列表刷新
FT_MCP_002	MCP 工具注册	缺少 name 参数	MCP 表单可用	name 为空并提交	返回参数缺失提示
FT_MEMORY_001	记忆系统	短期记忆展示	已进行多轮对话	查询当前会话记忆	返回当前会话上下文
FT_SANDBOX_001	沙箱执行	安全命令执行	沙箱服务可用	执行安全命令	返回命令执行结果
FT_DEGRADE_001	配置与降级	外部依赖缺失	部分组件未启动	查询系统状态	返回 disconnected 或 memory-mode 等降级状态

7.5 功能测试交付物

功能测试阶段输出以下文档：

function_test_cases_user_view.md
function_test_execution_report.md
function_test_smoke_results.md
function_test_mindmap.md

其中，功能测试思维导图按照以下结构组织：

模块
-> 功能点
-> 正向场景
-> 逆向场景
-> 边界值场景
-> 状态流转场景
-> 输入条件
-> 预期结果

功能测试共设计 84 条用例，主要用于功能梳理和手工冒烟验证，不全部计入 pytest 自动化执行结果。

八、接口自动化测试

8.1 接口自动化技术栈

接口自动化基于以下技术实现：

Python + pytest + requests + YAML + Markdown 报告 + Allure

8.2 接口自动化执行流程

接口自动化整体流程如下：

接口文档梳理
-> 测试点拆分
-> YAML 编写测试数据
-> pytest 参数化执行
-> requests 发送 HTTP 请求
-> 统一断言
-> 日志记录
-> Markdown / Allure 报告输出

8.3 接口覆盖范围

本次接口自动化覆盖 11 个核心接口。

方法接口测试重点

GET	/health	服务健康状态
GET	/api/status	系统运行状态、模型配置、依赖降级
POST	/api/chat	普通聊天、工具调用、RAG、ReAct
POST	/api/chat/cancel	取消当前任务
POST	/api/upload	文档上传
POST	/api/rag/query	RAG 知识库查询
POST	/api/docs/delete	文档删除
POST	/api/tools/mcp	MCP 工具注册
GET	/api/tools	工具列表
GET	/api/memory	记忆状态
GET	/api/snapshots	快照查询

8.4 接口自动化用例分布

模块用例数量

服务状态、系统状态、工具列表	9
普通聊天	8
工具调用	6
ReAct 多步推理	2
RAG 查询、文档上传	8
文档删除、取消任务	5
MCP 工具注册	6
记忆、快照	4
合计	50

8.5 接口断言设计

接口断言不是只判断状态码，而是分层断言。

断言类型示例

HTTP 状态码断言	判断接口返回 200、400、422、500 等
必填字段断言	判断 response 中是否包含 code、message、data 等字段
JSON 字段值断言	判断 status、mode、tools 等字段是否符合预期
文本包含断言	判断返回内容是否包含指定关键词
非空字段断言	判断 answer、session_id、tool_name 等字段不为空
降级状态断言	判断 disconnected、memory-mode 等降级状态是否合理
异常响应断言	判断缺少参数、非法输入时是否返回错误信息

例如，在外部服务未启动时，不强制要求所有依赖状态都是 connected，而是允许出现：

disconnected
memory-mode
mock-mode
fallback

这样可以避免由于本地环境差异导致自动化测试误报失败。

8.6 接口自动化执行结果

接口自动化共 50 条用例，本地执行结果为：

50 passed

九、UI 自动化测试

9.1 UI 自动化技术栈

UI 自动化基于以下技术实现：

Python + pytest + Playwright + YAML + Markdown 报告 + Allure

9.2 UI 自动化测试思路

UI 自动化主要模拟用户在浏览器中的真实操作行为，包括点击、输入、上传、切换开关等，然后断言页面 DOM 是否出现预期结果。

UI 自动化关注点包括：

页面是否正常加载
输入框是否可用
按钮点击是否生效
发送消息后是否渲染回复
RAG 开关状态是否变化
工具选择器是否正常展示
上传文件后是否有状态提示
接口异常时是否出现错误提示
移动端布局是否可用

9.3 UI 自动化 Mock 设计

为了提升 UI 自动化稳定性，本项目对部分后端接口进行了 mock：

/api/tools
/api/chat
/api/upload
/api/tools/mcp

这样设计的原因是：

UI 自动化重点验证前端交互和页面渲染，不应该强依赖真实 LLM、数据库、向量库和网络环境。

后端接口正确性已经由接口自动化测试覆盖。

Mock 可以减少测试执行时间，提高回归稳定性。

当后端服务不可用时，仍然可以验证前端页面逻辑。

9.4 UI 自动化用例分布

模块数量测试重点

首页加载	3	输入框、发送按钮、RAG 开关、工具按钮、上传区
聊天功能	5	点击发送、Enter 发送、空输入、换行、快捷提示词
会话管理	3	新建会话、localStorage 持久化、欢迎态恢复
RAG 模式	3	RAG 开关、RAG 回复、知识检索结构
工具调用	4	工具选择器、工具计数、工具结果渲染、取消选择
MCP 工具	2	MCP 表单打开、注册后刷新工具列表
文档上传	2	txt 上传、空文件展示
异常与响应式	2	网络失败提示、移动端输入可用
合计	24	–

9.5 UI 自动化用例示例

用例编号模块测试点操作步骤预期结果

UI_HOME_001	首页加载	页面基础元素展示	打开首页	输入框、发送按钮、RAG 开关正常展示
UI_CHAT_001	聊天功能	点击发送	输入消息并点击发送按钮	页面展示用户消息和助手回复
UI_CHAT_002	聊天功能	Enter 发送	输入消息后按 Enter	消息成功发送
UI_RAG_001	RAG 模式	开启 RAG	点击知识库开关	RAG 状态变为开启
UI_TOOL_001	工具调用	工具选择	打开工具选择器并选择工具	工具计数和选中状态正确展示
UI_MCP_001	MCP 工具	注册工具表单	打开 MCP 注册表单	表单字段正常展示
UI_UPLOAD_001	文档上传	上传 txt 文件	选择 txt 文件上传	页面展示上传成功提示
UI_ERROR_001	异常提示	网络失败	mock 接口失败	页面展示网络错误提示

9.6 UI 自动化执行结果

UI 自动化共 24 条用例，本地执行结果为：

24 passed

十、RAG 质量评测

10.1 RAG 质量评测背景

RAG 知识库问答不能只通过接口测试来判断质量。

接口自动化只能验证：

接口是否可访问
参数是否正确
响应结构是否符合预期
异常场景是否有提示

但它无法回答以下问题：

检索结果是否准确？
标准答案所在 chunk 是否被召回？
正确结果是否排在 Top-K 前列？
Dense、BM25、Hybrid 哪种检索策略更好？

因此，本项目单独设计了 RAG Retrieval Evaluation 模块，对检索质量进行量化评测。

10.2 RAG 基准数据设计

本地构造了可复现的技术基准语料：

数据项数量

技术文档	1250 篇
文档 Chunk	10000 个
Golden Queries	50 条
每条 Query 标准证据 Chunk	3 个

说明：

1250 篇文档是本地可复现的技术基准语料，不是线上真实生产文档。

每条 Golden Query 包含：

id
question
expected_chunk_ids
expected_doc_ids
expected_keywords
category
difficulty

示例结构如下：

– id: RAG_Q001
question: "系统支持哪些工具调用能力？"
expected_doc_ids:
– "doc_tools_intro"
expected_chunk_ids:
– "chunk_tools_001"
– "chunk_tools_002"
– "chunk_tools_003"
expected_keywords:
– "工具调用"
– "搜索"
– "知识库检索"
category: "工具调用"
difficulty: "easy"

10.3 检索策略对比

本次 RAG 质量评测对比三种检索策略：

策略说明

Dense Retrieval	基于 Embedding 的语义向量召回
BM25 Retrieval	基于关键词匹配的稀疏检索
Hybrid Retrieval	融合 Dense、BM25 等多路检索结果
RRF 排序	对多路召回结果进行融合排序

Dense Retrieval 更适合语义相近但关键词不完全一致的问题；BM25 更适合关键词明确的问题；Hybrid Retrieval 则结合两者优势，通过融合排序提高整体召回稳定性。

10.4 评测指标

本次使用以下指标衡量 RAG 检索质量：

指标含义

Hit@K	Top-K 中是否命中至少一个标准证据 Chunk
Recall@K	Top-K 中召回的标准证据 Chunk 占全部标准证据 Chunk 的比例
Precision@K	Top-K 中相关 Chunk 占比
MRR@10	第一个正确结果出现得越靠前，指标越高
nDCG@10	综合考虑相关性和排序位置的指标

10.5 RAG 评测结果

在本地技术基准数据集上，评测结果如下：

检索策略Recall@5

Dense Retrieval	84.00%
Hybrid Retrieval	100.00%

从结果可以看出，在当前构造的 Golden Queries 和标准证据 Chunk 上，Hybrid Retrieval 的 Recall@5 高于 Dense Retrieval，说明混合检索策略在标准证据召回方面更稳定。

需要注意：

RAG 质量评测结果依赖测试集构造、Chunk 切分方式、标准证据标注和检索参数配置。
当前结果用于本地基准评测和项目展示，不代表生产环境下的绝对效果。

10.6 RAG 质量评测结论

通过 RAG Retrieval Evaluation，本项目将知识库问答测试从“接口可用性验证”扩展到了“检索质量评估”。

该模块的价值在于：

可以量化比较不同检索策略
可以回归验证 RAG 检索效果是否退化
可以为后续优化 Chunk 切分、Embedding 模型、RRF 参数提供依据
可以在简历和项目展示中体现 AI 应用测试能力

十一、Allure 可视化报告

11.1 接入 Allure 的原因

原始 Markdown 报告适合归档，但展示效果有限。为了更直观地展示自动化测试结果，本项目接入 Allure 报告。

Allure 报告主要用于展示：

测试用例分类
测试执行结果
接口请求与响应
UI 操作步骤
失败截图
错误日志
RAG 评测指标摘要

11.2 Allure 报告生成流程

Allure 报告生成流程如下：

pytest 执行测试
-> allure-pytest 生成 allure-results
-> Allure CLI 生成 HTML 报告
-> 浏览器打开报告页面查看结果

常用命令示例：

pytest –alluredir=reports/allure-results
allure generate reports/allure-results -o reports/allure-report –clean
allure open reports/allure-report

11.3 Allure 报告价值

Allure 报告对测试开发项目展示有明显帮助：

比纯控制台输出更直观。

可以展示接口自动化、UI 自动化和 RAG 评测的分类结果。

失败时可以快速定位失败用例、错误日志和截图。

面试时可以作为测试工程化能力的补充材料。

十二、问题发现与修复

12.1 问题描述

在 UI 自动化测试过程中，发现工具列表接口的返回结构与前端处理逻辑存在兼容问题。

后端 /api/tools 返回结构为：

{
"tools": []
}

但前端原本按照数组结构处理返回数据，可能导致工具选择器渲染异常。

12.2 问题影响

该问题可能导致：

工具列表无法正常展示
工具选择器渲染异常
工具计数错误
用户无法选择工具
UI 自动化断言失败

12.3 修复方案

修复后，前端兼容两种返回结构：

const payload = await fetch('/api/tools').then(r => r.json()) || [];
availableTools = Array.isArray(payload) ? payload : (payload.tools || []);

12.4 修复结果

修复后，工具选择器可以兼容以下两种结构：

[]

以及：

{
"tools": []
}

UI 自动化相关用例重新执行通过。

12.5 问题总结

该问题说明 UI 自动化不仅可以验证页面操作流程，也能够发现前后端联调中常见的数据结构不一致问题。

从测试开发角度看，这类问题比较有价值，因为它同时涉及：

接口返回结构
前端数据处理
页面 DOM 渲染
自动化断言
回归验证

十三、测试结果汇总

13.1 测试资产汇总

测试内容数量说明

功能测试用例	84 条	测试设计和冒烟验证依据
接口自动化用例	50 条	pytest + requests 自动化执行
UI 自动化用例	24 条	pytest + Playwright 自动化执行
RAG 质量评测检查项	5 项	Hit@K、Recall@K、Precision@K、MRR@10、nDCG@10
项目原有单元/集成测试	23 条	项目已有 pytest
累计测试资产与检查项	186 条	包含功能设计、自动化用例和质量检查项

13.2 自动化执行结果

自动化测试内容数量执行结果

项目原有 pytest 测试	23	23 passed
接口自动化测试	50	50 passed
UI 自动化测试	24	24 passed
RAG 质量评测检查项	5	5 passed
本地全量自动化测试	102	102/102 passed

说明：

102/102 passed 是本地自动化执行结果。
84 条功能测试用例是测试设计和冒烟验证依据，不计入 pytest 自动化执行结果。

13.3 RAG 评测结果摘要

检索策略关键结果

Dense Retrieval	Recall@5 = 84.00%
Hybrid Retrieval	Recall@5 = 100.00%

说明：

该结果基于本地技术基准语料和 Golden Queries 评测得到，用于项目质量评估和回归对比。

十四、测试结论

本次测试围绕智能体助手项目，完成了功能测试设计、接口自动化测试、UI 自动化测试、RAG 质量评测和 Allure 报告建设。

主要成果如下：

完成 84 条功能测试设计用例
落地 50 条接口自动化用例
落地 24 条 UI 自动化用例
构建 RAG Retrieval Evaluation 模块
基于 50 条 Golden Queries 对检索质量进行评测
本地全量自动化执行结果为 102/102 passed
接入 Allure 可视化报告
发现并修复 /api/tools 返回结构兼容问题

从测试开发角度看，本项目的价值不只是写了接口测试或 UI 测试，而是把一个 AI 智能体项目拆解成了可测试、可回归、可评测的质量体系。

测试闭环可以概括为：

业务链路理解
-> 测试范围拆分
-> 功能用例设计
-> 接口自动化落地
-> UI 自动化落地
-> RAG 质量评测
-> Allure 报告展示
-> 问题发现与修复
-> 测试报告沉淀

整体来看，项目核心功能具备较好的可测性，接口层、UI 层和 RAG 检索层均已建立基础质量保障能力。后续可以继续扩展性能测试、安全测试和生成质量评测。

十五、后续优化方向

15.1 扩展 RAG 生成质量评测

当前 RAG 质量评测重点是检索质量，后续可以继续扩展生成质量指标，例如：

Faithfulness
Answer Relevancy
Context Relevancy
Answer Correctness

用于评估最终回答是否忠实于上下文、是否真正回答用户问题、是否存在幻觉。

15.2 增加性能测试

后续可以使用 JMeter 或 Locust 对核心接口进行并发压测，例如：

/api/chat
/api/rag/query
/api/upload
/api/tools/mcp

重点关注：

平均响应时间
P95 响应时间
吞吐量
错误率
并发稳定性
资源占用

15.3 增加安全测试

智能体项目涉及工具调用、沙箱执行和文件上传，后续需要重点补充安全测试，例如：

危险命令拦截
路径穿越
非法文件上传
超大文件上传
Prompt Injection
越权访问
敏感信息泄露

15.4 完善 UI 截图对比

当前 UI 自动化主要验证 DOM 和文本结果，后续可以增加截图对比能力，用于发现：

页面布局错位
按钮遮挡
移动端适配异常
弹窗显示异常
主题样式异常

十六、项目测试总结

本次测试实践完成了从功能测试到自动化测试，再到 RAG 质量评测和测试报告建设的完整流程。

对于测试开发实习项目来说，本项目可以体现以下能力：

测试需求分析能力
功能测试用例设计能力
接口自动化框架搭建能力
UI 自动化测试落地能力
YAML 数据驱动能力
Mock 测试能力
RAG 质量评测能力
Allure 报告建设能力
问题定位与修复能力
测试报告沉淀能力

最终可以总结为：

基于智能体助手系统，完成 84 条功能测试设计用例，使用 pytest + requests + YAML 落地 50 条接口自动化测试，使用 pytest + Playwright + YAML 落地 24 条 UI 自动化测试，构建 RAG Retrieval Evaluation 模块并基于 50 条 Golden Queries 评估 Dense 与 Hybrid 检索效果。结合项目原有 23 条 pytest 测试，本地全量自动化执行结果为 102/102 passed。同时接入 Allure 可视化报告，并通过 UI 自动化发现和修复前后端返回结构兼容问题。

该项目已经形成较完整的测试开发闭环，适合作为测试开发实习、AI 应用测试、Agent 项目测试实践的展示材料。