更多内容，请前往知识星球APP，搜索：测试开发之路（AI测试俱乐部）
对我们来说，提效最重要的一个步骤
用AI把需求或者手工测试用例翻译成可执行的自动化测试代码
测试场景：
默认知识库文档导入还原与检索验证
测试步骤：
1. 创建Agent模式应用
2. 上传默认知识库文档
（产品介绍.docx）
3. 等待文档解析完成
4. 导出应用包
5. 导入应用包到新应用
6. 等待导入应用的文档解析完成
7. 在评测端对话验证命中文档：
"检索产品介绍"
预期：知识检索插件被调用，
且返回文档引用
8. 清理源应用、导入应用、导出文件把上面的用例，让AI生成下面的测试代码：
class AgentAppImportKBDocRestoreTest(
AgentCaseBase):
owner = 'test_owner'; timeout = 25
tags = [CaseTag.AgentModel,
CaseTag.Private, CaseTag.PublicCloud]
def run_test(self):
# 1.创建应用
self.app_id = AppService \
.re_create_app_if_exist("文档导入")
# 2.上传文档（云存储+产品接口+轮询）
KBService.do_import_doc(
self.app_id, doc_path)
KBService.check_doc_status(self.app_id)
# 3.导出应用（发布+异步导出+下载）
export_result = AppService \
.do_export_app(app_id=self.app_id)
# 4.导入应用（上传+异步导入+轮询）
import_result = AppService \
.do_import_app(
local_file=export_result["local_file"],
space_id="default_space")
self.import_app_id = \
import_result["import_app_id"]
# 5.等待导入应用文档解析
KBService.check_doc_status(
self.import_app_id)
# 6.对话验证命中（SSE/WS多协议）
self.do_chat_with_options(
app_id=self.import_app_id,
content="检索产品介绍",
check_agent_invoke=True,
agent_name="KnowledgeRetrieval",
check_references=True,
expect_have_references=True)要让大模型能精准的实现这一点并不容易，因为这样看上去简单的case，下面实际上是40+接口调用的复杂度。下面我列出接口的调用链。
接口调用总账
| 步骤 | 操作 | 产品接口数 | 关键接口 |
|---|---|---|---|
| 1 | 创建应用 | 6 | ListApp → DeleteApp → CreateApp → ListModel → DescribeAppAgentList → ModifyAgent |
| 2 | 上传文档 | 4+存储 | DescribeStorageCredential → [云存储/Minio/OBS直传] → SaveDoc → DescribeDocStatus×N |
| 3 | 导出应用 | 7+轮询 | CreateRelease → DescribeRelease×N → DescribeExportAppTaskConfig → CreateExportAppTask → DescribeExportAppTask×N → DescribeStorageCredential → [云存储/Minio下载] |
| 4 | 导入应用 | 4+轮询 | DescribeStorageCredential → [云存储/Minio上传] → CreateImportAppTask → ListApp×N |
| 5 | 等待文档解析 | 轮询 | DescribeDocStatus×N |
| 6 | 对话验证 | ~10 | GetAppSecret×2 → POST /v1/chat → POST /v2/chat → GetSharePageUrl×2 → GetSharePageWsToken×2 → WebSocket×2 |
| 7 | 清理资源 | 2 | DeleteApp×2 |
| 合计 | ≈40+次产品接口调用 | 涉及30+种不同的APIAction |
一条测试用例背后≈40次产品接口调用、30+种不同API、2种存储协议（云存储/Minio）、4种对话协议（SSEV1/V2+WSV1/V2）、4次异步轮询（应用发布/应用导出/应用导入/文档解析）
所以大家看， 这么复杂的接口调用形式，如果只是把接口文档和产品需求文档给大模型，它生成的准确率是非常低的。 所以我们需要抽象一个service层，封装复杂的产品逻辑， 而在skill里，只记录service这一层的知识，这样就大大减少了大模型的理解成本。
大多数测试用例 = 用现有接口串联不同流程，所以我们封装一个个可复用的业务流程（每个业务流程是很多个接口组合的），让skill学习这层的知识
┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐┌──────┐┌───────┐┌────────┐┌────────┐
│创建应用 ││配置Agent││上传文档 ││导入知识库││发布应用 ││WS对话 ││SSE对话 ││验证结果 ││清理资源 │
└────────┘└────────┘└────────┘└────────┘└────────┘└──────┘└───────┘└────────┘└────────┘
用例A：创建应用 → 配置 → 上传 → 导入 → 发布
用例B：发布应用 → WS对话 → SSE对话 → 验证 → 清理
用例C：创建应用 → 上传文档 → 发布 → 导出 → 导入 → 对话验证Service 层：封装复杂接口调用， SKILL只记录上层接口知识
产品业务过于复杂，原始 API 文档无法让大模型推理出完整业务流程（如文档上传需要云存储/Minio 凭证获取 + 直传 + 注册 + 轮询，对话需要鉴权 + 多协议 + 流式解析）。因此我们专门抽象了一个Service层 ，将复杂业务逻辑和接口实现细节封装为简洁的方法调用，再在 Skill 中写入这些 Service 层的使用知识。
┌─────────────────────────────────────────────────────────────────────────┐
│ 原始知识（大模型难以直接使用） │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────────────────────────┐ │
│ │ API 接口文档 │ │ 产品需求文档 │ │ 底层实现细节 │ │
│ │ │ │ │ │ │ │
│ │ 37个接口分类 │ │ 45+功能模块 │ │ 云存储/Minio签名上传 │ │
│ │ 参数/返回定义 │ │ 业务流程描述 │ │ HMAC鉴权 │ │
│ │ 错误码说明 │ │ 用户故事 │ │ SSE/WS流式解析 │ │
│ │ │ │ │ │ 异步轮询状态机 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────────────┬────────────────┘ │
│ │ │ │ │
└─────────┼─────────────────┼──────────────────────────┼───────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Service 层抽象（我们封装的中间层） │
│ │
│ 将 N 个原始接口 + 复杂协议 + 业务流程 封装为 1 个语义明确的方法调用 │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────┐ │
│ │ KBService │ │ AppService │ │ ReleaseService │ │
│ │ │ │ │ │ │ │
│ │ .do_import_doc() │ │ .re_create_app() │ │ .release_and_ │ │
│ │ = 凭证+上传+注册 │ │ = 查+删+建+配模型 │ │ wait_success() │ │
│ │ +轮询解析 │ │ │ │ = 发布+轮询 │ │
│ │ │ │ .add_plugin() │ │ 状态机 │ │
│ │ .check_doc_status() │ │ = 查模板+改配置 │ │ │ │
│ │ = 轮询直到完成 │ │ │ │ │ │
│ └─────────────────────┘ └─────────────────────┘ └─────────────────┘ │
│ │
│ ChatService │
│ .do_chat_with_options() = 鉴权 + 4协议并行(SSE V1/V2 + WS V1/V2) │
│ + 流式解析6种事件 + 答案/插件/引用校验 │
└─────────────────────────────────────────────────────────────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Skill 定制知识（大模型直接消费） │
│ │
│ 不同 Skill 针对不同测试领域，注入各自的专属知识： │
│ │
│ ┌─ test-case-writing Skill ──────────────────────────────────────────┐ │
│ │ · 用例结构规范: pre_test → run_test → post_test │ │
│ │ · 对话必须用 do_chat_with_options，禁止直接调 SSE/WS │ │
│ │ · 双环境验证: experience(评测端) + send(用户端) │ │
│ │ · Service 层优先: KBService / AppService / ReleaseService │ │
│ │ · 资源清理: post_test 中按依赖反序清理 │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─ perf-test Skill ─────────────────────────────────────────────────┐ │
│ │ · Locust 压测框架规范: Task 编排 / headless 执行 / 环境变量驱动 │ │
│ │ · 压测策略: Queue消耗模式(耗尽停止) / 循环读取模式(按时停止) │ │
│ │ · 指标统计: TTFT / P50/P95/P99 / tokens/s / 分步上报 │ │
│ │ · 数据准备: batch_runner 批量创建 + asset_store JSON 持久化 │ │
│ │ · 脚本独立性: 不依赖项目内部模块，可在客户环境独立运行 │ │
│ │ · cookbook: HMAC签名 / SSE解析 / TTFT计算 等9章可复用代码片段 │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─ ha-test Skill ───────────────────────────────────────────────────┐ │
│ │ · 故障注入流程: 收集节点 → 检查状态 → 注入 → 验证 → 恢复 → 循环 │ │
│ │ · 故障类型: 单节点 / 多节点 / 全节点 │ │
│ │ · 执行方式: 堡垒机跳转 + nohup 后台执行 │ │
│ │ · 结果追踪: ha_fault_test_results.json 结构化记录 │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ 每个 Skill = 该领域的「专家手册」，大模型读完即具备该领域的测试能力 │
└─────────────────────────────────────────────────────────────────────────┘知识库驱动三条测试提效方向
┌────────────┐
│ 知识库 │
│ │ Line 1 · 功能测试
│ 需求文档 │ ──→ AI生成手工用例 → 人工Review → AI生成自动化用例 → 人工Review → 推送测试平台
│ API文档 │
│ 项目代码 │ Line 2 · 性能测试
│ Skill │ ──→ AI动态生成压测脚本 → 数据准备 → 执行压测 → 汇总报告
│ │
│ │ Line 3 · 高可用测试
└────────────┘ ──→ AI生成故障注入 → AI生成业务验证脚本 → 故障注入&验证 → 恢复&循环Skill 中的复杂场景封装示例 --- 以下片段摘自 Skill 文件：
示例：知识检索插件配置与验证 --- 涉及创建共享知识库、上传文档、插件替换、知识库绑定、双环境对话验证
python
#### 完整示例（同时验证答案和Agent调用）
```python
# 同时验证答案内容和Agent调用情况
res = self.do_chat_with_options(
self.app_id,
content="查询数据库中的用户信息",
chat_location="experience",
check_answer=True,
expect_answer="查询成功",
check_agent_invoke=True,
agent_name="SQLExecutor"
)
```
#### 主要参数说明
| 参数 | 类型 | 说明 | 默认值 |
|---|---|---|-----|
| `app_id` | str | 应用ID | 必填 |
| `content` | str | 对话内容 | 必填 |
| `use_ws` | bool | 是否使用WebSocket | True（推荐） |
| `chat_location` | str | 对话环境："experience"（评测端）或"send"（用户端） | "send" |
| `check_answer` | bool | 是否验证答案内容 | False |
| `expect_answer` | str | 期望的答案内容（部分匹配） | "" |
| `check_agent_invoke` | bool | 是否验证Agent调用 | False |
| `agent_name` | str/list | 期望被调用的Agent名称，支持单个或多个 | None |
| `expect_agent_invoked` | bool | 期望Agent是否被调用 | True |
| `check_references` | bool | 是否检查知识库引用 | False |
| `expect_have_references` | bool | 是否期望有引用 | True |
| `session_id` | str | 会话ID（用于多轮对话） | None |
| `reset_session` | bool | 是否重置会话 | True |
| `only_websocket` | bool | 是否只使用WebSocket对话 | True |
| `custom_variables` | dict | 自定义变量（用于传递API变量值） | None |
| `in_query_doc_path_list` | list | 输入文档路径列表（用于多模态对话） | [] |
| `in_query_img_path_list` | list | 输入图片路径列表（用于多模态对话） | [] |性能测试 Skill
核心理念
客户需求每次都不一样，但底层积木（接口、指标、压测策略）是固定的
用户需求（变化） ⚡ perf-test Skill ⚡ 生成结果
（AI 智能组装引擎）
┌──────────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐
│ 大量用户查询 │ │ 压测策略 │ │ 接口积木 │ │ 完整Locust脚本│
│ 全流程压测 │ → │ 数据准备 │ │ 指标统计 │ → │ 数据准备脚本 │
│ 知识库对话 │ │ (固定层) │ │ (固定层) │ │ 指标采集&上报 │
│ 海量文档导入 │ └──────────┘ └──────────┘ │ 一键headless │
└──────────────┘ └──────────────┘知识的构建
| 接口层（固定） | 指标层（固定） | 策略层（固定） |
|---|---|---|
| 创建/删除应用 · 空间/用户管理 | TTFT 首Token · P50/P95/P99 | Queue消耗(耗尽停止) |
| 文档上传 · 应用发布(异步) | Tokens/s 吐字率 · 成功率 | 循环读取(按时停止) |
| SSE V2 对话 · API鉴权(HMAC) | Input/Output Token · 全流程耗时 | headless · 并发/孵化率控制 |
变化的只是业务组合方式 。
功能测试：智能生成全流程 
分模块知识加载：按需注入，降低理解成本
核心思路：不同模块只加载该模块需要的知识，避免将全部知识塞入上下文，减少 Token 消耗和模型理解成本
模块知识路由表：
| 功能领域 | 加载的知识文件 | 用例目录 |
|---|---|---|
| Agent模式 | references/multi-agent.md |
cases/app_dev/multi_agent_model/ |
| 插件广场 | references/plugin-market.md |
cases/plugin_marketplace/ |
| 模型广场 | references/model-market.md |
cases/model_marketplace/ |
| 权限管理 | references/auth.md |
cases/platform_management/auth/ |
| 计费 | references/billing.md |
cases/platform_management/price/ |
| 提示词模板 | references/prompt-tpl.md |
cases/prompt_templates/ |
效果： 写 Agent 用例时只加载 Agent 知识（~400 行），而非全部 6 个模块知识（~1500+ 行），模块间知识互不干扰，上下文窗口利用率更高，生成准确率显著提升。
总结
本篇是对之前的性能测试skill和AI生成测试用例的补充。 因为skill设计中最重要的，我认为是知识的设计，如何降低大模型的理解成本是重中之重。