一、AI主导API测试思路
1.1 API测试的特点与问题
API测试的优势：
理想场景： OpenAPI → 导入工具/生成代码 → 构造参数 → 发送请求 → 断言响应
现实问题：
| 问题 | 说明 |
|---|---|
| 文档不标准 | 项目没有OpenAPI，只有Word/Markdown/网页文档或口头说明 |
| 业务流程复杂 | 多个接口如何组成业务流程？ |
| 数据依赖 | 上一个接口产出的字段如何传给下一个接口？ |
| 业务断言 | 响应结果是否真的符合业务预期？ |
| 运行时验证 | 哪些接口事实已经经过运行时验证？ |
核心观点： 围绕单个接口生成请求不难，真正复杂的是业务路径级API测试。
1.2 行业前沿研究参考
| 研究 | 核心思想 |
|---|---|
| RESTSpecIT | 接口文档不是唯一事实来源，运行时请求和响应也可以反哺接口知识 |
| AutoRestTest | API测试不能孤立处理接口、参数和值，还要关注接口之间的数据依赖和调用关系 |
| LogiAgent | 关注业务逻辑问题，而不仅是状态码、5xx错误或接口崩溃 |
| ARMeta | 关注问题，用变形测试描述多次API调用之间应保持的关系 |
共同趋势： 从"生成单接口请求"走向探索接口依赖、验证业务逻辑。
⚠️ 如果只是根据OpenAPI生成测试代码，还停留在传统自动化范畴（2016年已有自研工具）。AI的真正价值在于：面向业务场景理解接口关系、生成断言，并且持续维护测试资产。
1.3 我们采用的API测试方案
五步思路：
采集接口事实 → 建立接口关系 → 沉淀可信依据 → 设计和执行测试 → 自动化回归
↓ ↓ ↓ ↓ ↓
文档+录制 参数/响应/ 接口实测文档 用例设计+执行 pytest高效回归
+CLI验证 数据依赖人机分工：
| 角色 | 职责 |
|---|---|
| 人 | 指定业务目标和风险边界、提供测试账号和操作范围、评审接口实测文档、判断业务价值问题 |
| Agent | 阅读资料提取接口线索、按业务路径录制/整理请求、用curl验证关键请求、整理接口实测文档、标记冲突/阻塞/待确认、维护和执行测试用例、维护和执行自动化回归脚本 |
二、API01 接口事实收集
2.1 核心概念：接口实测文档
目的： 区分传统接口文档------把真正验证过的接口信息整理成文档，作为接口测试依据。
三个步骤： 采集接口线索 → 验证接口线索 → 整理接口实测文档
2.2 采集接口线索
| 信息来源 | 能告诉我们什么 | 不能直接证明什么 |
|---|---|---|
| OpenAPI/接口文档 | 候选method/path、参数和响应结构 | 当前环境一定按文档运行 |
| 页面请求与网络流量 | 真实客户端调用了什么、参数放哪里 | 所有参数规则和异常行为已验证 |
| 已有代码或历史脚本 | 过去怎样调用、可能有哪些依赖 | 当前版本仍然保持相同行为 |
信息来源越多，信息密度越低。但没关系，经过验证步骤会把有用的筛选出来。
2.3 验证接口线索
目的： 验证接口线索是否真实可靠（如浏览器录制的请求离开浏览器后能否成功，文档是否和实际系统一致）
至少记录：
| 要素 | 内容 |
|---|---|
| 请求要素 | 方法、地址、鉴权、参数 |
| 响应要素 | 状态码、关键字段 |
| 接口报文 | 请求和响应的真实内容 |
| 业务结果 | 成功还是失败还是没有结果 |
| 后续依赖 | 响应中哪些字段可以给后续步骤使用 |
验证工具： httpie、httpX、cURL
2.4 整理接口实测文档
来源多方面，内容经过验证，包含接口请求/响应 + 接口关系（谁依赖谁、谁输出什么、需要传递什么数据）
⚠️ Agent生成的文档需要评审后使用。
2.5 提示词模板
请围绕<本轮业务目标>收集API事实，暂不设计测试用例，也不生成自动化代码。
可使用的线索包括：<接口文档/OpenAPI>、<页面请求或录制结果>、<现有业务资料>。
测试环境：<环境与BaseURL>。
允许使用的角色和账号：<角色/账号来源>。
允许的数据操作：<可创建、修改、取消或清理的测试数据>。
禁止操作：<生产支付、真实用户数据、不可逆操作等>。
先按业务路径建立候选接口地图，再使用HTTP客户端请求验证核心接口。
每条事实记录业务用途、method/path、认证、参数位置和类型、
响应状态与业务语义、动态字段的来源和消费者、数据副作用、证据位置和当前状态。
文档声明、页面流量和本轮实测分别记录：只有本轮证据充分的内容才能标记为已验证。
文档与运行不一致时保留差异，无法验证的内容标记为候选、阻塞或冲突。
写作必须继续查询真实数据状态，并说明本轮数据的所有权和清理结果。
最终输出接口实测文档、完整业务请求链、动态字段链、文档差异、未决问题，
以及当前可以交给用例设计的事实范围。2.6 内容评审
| 评审项 | 检查重点 | 处理方式 |
|---|---|---|
| 路径覆盖 | 目标业务路径是否覆盖；实际链路是否偏离 | 偏离退回补测；替代路径单独记录 |
| 每条记录 | 是否有可执行请求、响应文件、验证状态 | 补充curl验证或降级为candidate |
| 依赖 | 前置条件、传递条件、上下游字段是否说明清楚 | 补充字段路径和固定数据来源 |
| 正常断言 | 是否包含结构判断和业务结果判断 | 补充业务断言 |
| 候选异常线索 | 已实测异常、边界和缺口是否明确标注 | 关键缺口退回补测，其余带入下一环节 |
⚠️ 绝对禁止： 仅靠HTTP 200就认为业务成功。
三、API02 用例设计
复用Web03的方法，额外强调：
| 要点 | 说明 |
|---|---|
| 不机械认为"一个接口=一条用例" | 业务场景通常由多个接口组成 |
| 单接口用例 | 验证参数、鉴权、非法值、健壮性 |
| 业务场景 | 明确接口顺序和字段传递 |
| 预期 | 包含响应结果 + 状态变化 + 数据结果 |
| 未验证行为 | 保留为探索性用例 |
四、API03 用例评审
复用Web04的方法，额外关注：
⚠️ AI产物必须持久化、可审计，以文件形式保存在目录中。
五、API04 执行用例
复用Web05的方法，用cURL等工具真实执行接口测试用例。
六、API05 自动化就绪评估 ⭐核心
6.1 md用例与py代码之间的鸿沟
误解： 既然用例已执行通过，让AI按用例生成pytest代码即可。
问题： Markdown用例是面向人的表达，人理解省略信息；自动化代码没有天然补全能力。
示例鸿沟：
| 信息 | 人在执行时可能怎样处理 | 自动化必须明确什么 |
|---|---|---|
| 动态数据 | 从响应中找到像订单编号的字段 | 从哪个响应、用什么路径提取，交给哪个后续请求 |
| 请求语义 | 根据工具习惯补充请求头、Cookie | Method、URL、Content-Type、认证方式必须与实测一致 |
| 金额比较 | 看到99.0和99.00会认为相等 | 字符串完全相等还是按数值语义比较 |
| 集合定位 | 翻页或搜索直到找到刚创建的订单 | 用什么稳定条件定位，预期匹配几条 |
| 数据生命周期 | 记得在适当时删除测试数据 | 谁创建、谁使用、谁清理，断言失败时是否仍清理 |
常见风险：
核心结论： API自动化真正困难的不是把请求写成Python，而是把人的隐含判断变成确定、可追溯、可重复执行的规则。
6.2 从测试用例到自动化交接
两个核心问题：
| 判断 | 要回答的问题 |
|---|---|
| 自动化价值 | 这个场景是否值得长期、重复地执行 |
| 交接状态 | 当前事实和证据是否足以让下游忠实实现 |
桥接过程：
Markdown用例 + 执行记录 + 原始证据
↓
复核测试意图与真实执行是否一致
↓
重建请求链、数据链、判断语义和生命周期
↓
全量分类与缺口回流
↓
可以直接消费的自动化交接五项具体工作：
| 步骤 | 内容 |
|---|---|
| 1. 复核用例与证据 | 用例中的请求、预期和执行结论必须能追溯到真实证据 |
| 2. 重建完整业务场景 | 多接口顺序、会话、字段传递和状态变化构成可重复执行的场景 |
| 3. 隐含判断变明确语义 | 动态值来源/条数/传递方式；字段判断语义（精确/数值/模式/非空） |
| 4. 闭合依赖与生命周期 | 前置生产者、消费者、上游失败后哪些步骤不能继续、清理责任 |
| 5. 每个来源用例明确去向 | 能忠实实现→直接交接；事实不足→返回事实收集/执行；用例问题→返回设计/评审 |
两类结果：
| 产物 | 作用 |
|---|---|
| 自动化就绪度评审报告 | 全量对账：每条用例的价值、交接状态、问题和回流方向 |
| 直接交接表 | 只保留事实充分、证据充分、依赖闭合的场景 |
评审报告负责"不遗漏"，直接交接表负责"不猜测"。
6.3 提示词模板
请基于本轮API测试的全部Markdown用例、评审结果、执行记录和确切请求响应证据，进行自动化就绪评估。
这一步不是生成pytest代码，而是审视来源用例，并建立从测试用例到自动化实现之间的精确交接。
请分别判断：
1. 每个场景是否具有长期自动化价值；
2. 当前事实和证据是否足以忠实实现。
逐条复核：
- 测试意图、接口事实和真实执行是否一致；
- 请求顺序、认证方式和会话范围；
- 动态字段的来源、提取条件、类型、期望数量和后续消费者；
- 结构断言、业务断言、状态变化和比较语义；
- 数据所有权、前置依赖、失败传播和清理责任；
- PASS、FAIL、BLOCKED或需要修订的结论是否有证据支持。
每个来源用例必须有且只有一个去向。
证据不足时指出应回到事实收集、用例设计、用例评审还是实际执行，不要根据经验补写尚未验证的事实。
输出：
1. 全量自动化就绪度评审报告；
2. 只包含可直接交接场景的自动化交接内容。
交接内容应使下游不需要重新猜测请求链、动态数据、判断语义、依赖和清理。6.4 内容评审
全量对账检查：
反向核对路径：
Markdown用例 → 执行记录 → 原始证据 → 自动化交接重点检查：
重要参考数据： 按项目经验，90%以上API用例 通常具备自动化条件；传统UI自动化率约40%，引入智能体后实测可达60%以上。若评估结论于此不符，要引起注意并重新评审。
七、API06 pytest自动化
7.1 创建测试框架模板
Agent能快速生成pytest代码，但每次都从零决定目录/配置/HTTP客户端/日志，结果波动大，不利于长期维护。
框架组成：
| 组成 | 主要职责 |
|---|---|
| 配置 | 测试环境、Base URL、超时、账号和环境变量覆盖 |
| HTTP客户端 | 会话保持、请求发送、统一日志、超时控制和敏感信息脱敏 |
| fixture | 与测试目标无关的稳定前置、角色认证和失败后的兜底恢复 |
| 测试函数 | 真实业务请求链、动态字段传递和关键业务判断 |
| 日志与报告 | 请求响应证据、来源标识、执行结果和失败定位信息 |
工程化目的： 减少选择，增加确定性。提前创建成熟模板，把已验证的工程经验固化下来，让Agent专注业务场景。
💡 进阶提示： Skills中不只有提示词，还可以有脚本、文档、模板等资产文件。
7.2 落地和验证pytest脚本
Agent的"搬砖模式"：
注意事项：
| 要点 | 说明 |
|---|---|
| 内容结构遵循框架模板 | 不重新发明结构 |
| py代码必须忠于md用例 | 不擅自修改意图 |
| 用例必须有断言 | 不只有请求无验证 |
| 执行必须有产物 | 日志、报告、证据 |
| 运行过的自动化才可交付 | 真实执行验证 |
| 分辨通过和失败的原因 | 不盲目接受结果 |
7.3 提示词模板
请仅消费API05已经确认的直接交接内容，把冻结范围忠实实现为原生pytest API回归工程，并完成真实运行验证。
开始前：
1. 确认目标为已授权测试环境；
2. 建立"来源用例→交接场景→测试函数→测试文件"的完整映射；
3. 优先复用项目已有pytest工程、HTTP客户端和配置。
实现时必须保留：
- 已验证的请求顺序、认证方式、会话范围、请求头和参数编码；
- 动态字段的提取条件、数据类型和后续消费者；
- 稳定的集合定位方式和期望匹配数量；
- 结构断言、业务断言、状态变化及副作用检查；
- 数据所有权、依赖关系和失败后的清理责任；
- 来源标识、脱敏日志和可复核报告。
不要扩大到未交接场景，不要重新设计业务预期，
不要为了让测试通过而删除步骤、使用固定动态ID、选择列表第一项或放宽关键断言。
先完成静态检查和collect-only，再进行小批真实执行。
失败时区分产品、环境、上游事实或用例、测试资产四类来源：
只修复测试资产问题；新的事实冲突应返回相应阶段并保留证据。
所有代码和配置冻结后，清理旧报告，执行一次完整回归。
最后对账来源范围、pytest item、执行结果、日志、报告、来源标识和脱敏情况，
并说明每个来源用例是否已经忠实落地。7.4 内容评审
不逐行评审Python语法和代码风格（交给lint和静态检查工具）。
人工评审重点：
| 检查项 | 说明 |
|---|---|
| 测试用例全部覆盖 | 交接场景是否完整落地 |
| 测试步骤、断言和md用例一致 | 代码是否忠实于原意图 |
| 用例执行结果和md用例一致 | 执行结论是否匹配 |
| 日志、报告完整齐全 | 证据是否可追溯 |
信任链条：
md用例意图准确 → py代码遵循md意图 → py产生过程文件和结果 → 执行结果反映业务事实八、回顾与进阶
8.1 三节课完成了什么
| 课程 | 内容 |
|---|---|
| 第一课 | 搭建AI测试工作台（Claude Code + DeepSeek + Skills） |
| 第二课 | AI主导Web测试（探索→梳理→设计→评审→执行） |
| 第三课 | AI主导API测试（事实收集→设计→评审→执行→就绪评估→pytest自动化） |
时间分配变化：
分工本质： 人负责目标、边界、判断和验收；Agent负责推进流程、执行任务并生产测试资产。
8.2 完整学习路线
1. AI与Agent基础
-
理解大模型适合做什么、不适合做什么
-
理解上下文、提示词、工具调用和Agent基本原理
-
学会控制权限、任务边界、执行过程和交付结果
-
识别AI生成内容中的猜测、遗漏和不可靠结论
2. AI主导测试实战
-
使用AI理解需求、梳理业务并读写项目知识文档
-
完成Web测试的分析、设计、执行和自动化落地
-
完成API测试的事实收集、设计、执行和自动化落地
-
处理多角色、动态数据、认证、依赖、清理和复杂失败
-
将测试过程沉淀为可复用和维护的项目资产
3. 测试工程化与质量评估
-
建立稳定的测试框架、项目模板、日志和报告
-
将自动化测试接入定时任务或持续集成流程
-
评估AI生成的用例、代码和执行结论是否忠实可靠
-
管理测试资产的更新、失败回流和长期维护
-
扩展到App测试、性能测试和大模型应用质量评估
📊 全课知识图谱
API测试六阶段：
API01 接口事实收集 → API02 用例设计 → API03 用例评审 → API04 执行用例 → API05 自动化就绪评估 → API06 pytest自动化
↓ ↓ ↓ ↓ ↓ ↓
采集线索+验证 复用Web03 复用Web04 复用Web05 md→py鸿沟桥接 忠实落地+回归
→接口实测文档 +多接口场景 +动态字段 +真实执行 +全量分类+交接 +框架模板
核心概念速记：
├── 接口事实收集：采集线索(文档/流量/代码) → 验证(cURL/httpie) → 接口实测文档(评审后使用)
├── 用例设计：单接口(参数/鉴权) + 业务场景(多接口顺序/字段传递)
├── 自动化就绪评估：MD用例 → 复核证据 → 重建请求链/数据链 → 全量分类 → 直接交接表
├── pytest落地：框架模板(配置/客户端/fixture/函数/日志) → 忠实实现 → 真实运行验证
└── 信任链条：md意图准确 → py遵循意图 → 过程文件+结果 → 反映业务事实
分工：人(目标/边界/判断/验收) + Agent(推进/执行/生产)🎯 一句话总结
API测试 = 接口事实收集(文档+录制+验证→实测文档) → 用例设计(单接口+多接口业务场景) → 评审 → 执行 → 自动化就绪评估(填平md→py鸿沟，全量分类产出直接交接表) → pytest忠实落地 + 框架模板固化。核心是"先验证再依赖，先桥接再编码"，杜绝仅凭HTTP200断言业务成功。