做接口测试这些年，最磨人的往往不是接口本身有多复杂，而是大量重复劳动：拿到接口文档、按字段造数据、手写断言、跑完再看日志猜失败原因。最近看到不少 B 站教程都在讲用 AI 来改造这套流程，标题很吸引人，但多数视频停留在“让 AI 写一段脚本”的演示层面，离真实项目落地还有一段距离。

这篇文章不重复那种演示，而是走一条更接近工程实践的完整路线：从接口文档结构化、到 AI 生成测试用例、再到自动生成 pytest 脚本并执行、最后用 AI 分析失败原因。整套流程按一小时可跑通的标准来组织，新手能看懂原理，有测试开发经验的读者也能直接照搬思路。

1. AI 接口自动化测试：到底解决了什么问题

1.1 传统接口自动化测试的重复劳动

先看一个常见场景：后端新上线了一个用户登录接口，测试同学拿到接口文档后要做的事情通常包括：

• 阅读接口定义，确认请求方法、路径、请求头、参数类型。
• 根据参数边界手工设计用例，如正常登录、密码错误、用户不存在、参数缺失、参数类型错误。
• 用 Postman、Apifox 或代码框架编写请求脚本。
• 为每个用例写断言，不仅断言 HTTP 状态码，还要断言业务字段。
• 运行测试，分析失败结果，再排查是脚本问题、环境问题还是接口 bug。

这套流程一天重复几次还能接受，当接口数量达到几十上百个，手工维护的成本会迅速上升。更难受的是接口文档更新后，测试脚本和用例需要同步调整，这一步很容易遗漏。

AI 接口自动化测试的核心思路，不是完全取代测试工程师，而是把上面这些“从文档到脚本”的重复翻译工作交给大模型，测试人员把精力放到评审用例合理性、维护 Schema 约束和分析复杂问题上去。

1.2 AI 在接口测试流程中能承担的四件事

目前比较成熟、也最容易落地的是以下四类任务：

第一，接口文档结构化。把自然语言写的接口说明或者 JSON 示例，转换成程序可以处理的 Schema。这一步是后续所有步骤的基础。

第二，测试用例生成。基于接口参数约束，枚举正常、异常、边界等场景，生成用例清单。AI 的优势是速度快、覆盖面较广，尤其适合参数较多的接口。

第三，测试脚本生成。把测试用例转换成实际的 pytest 函数或 requests 请求代码，这一步能省掉大量手写时间。

第四，失败结果初步分析。测试运行后，AI 可以读取日志和响应报文，给出失败原因的可能方向，帮助测试人员快速定位。

1.3 需要提前明确的边界

AI 目前还不能完全替测试人员做判断。比如某个响应里的 code 字段是否符合业务预期，AI 只能根据文档推断；接口的权限设计、业务规则、数据一致性这类隐含约束，AI 往往看不到。所以在流程中，Schema 校验和人工评审仍然是不可省略的环节，AI 负责提效，测试人员负责兜底。

2. 环境准备与整体设计

2.1 运行环境与依赖

本文示例以常见环境为例，具体版本按你自己的项目实际情况调整。核心依赖包括：

• Python 3.10 及以上。
• pytest：用于组织和管理测试用例。
• requests：发送 HTTP 请求。
• pydantic：做数据结构校验，过滤 AI 生成内容中的无效字段。
• 一个支持 OpenAI 兼容接口的大模型服务，可以是你自己的本地模型，也可以是云服务商提供的 API。

先创建项目目录并准备虚拟环境：

mkdir ai-api-testing
cd ai-api-testing
python -m venv venv
source venv/bin/activate  # Windows 使用 venv\Scripts\activate

安装依赖：

pip install pytest requests pydantic python-dotenv

用 python-dotenv 是为了方便管理环境变量，避免把 API Key 直接写进代码。

2.2 大模型 API 接入方式

为了不绑定具体厂商，这里使用兼容 OpenAI 的 /v1/chat/completions 接口格式。不管你用的是本地部署的模型服务，还是云厂商的 API，只要支持这个协议，代码都可以直接复用。

项目根目录下创建 .env 文件：

LLM_API_URL=http://localhost:8000/v1/chat/completions
LLM_API_KEY=sk-your-key
LLM_MODEL=local-model

在代码中这样读取：

import os
from dotenv import load_dotenv

load_dotenv()

LLM_API_URL = os.getenv("LLM_API_URL")
LLM_API_KEY = os.getenv("LLM_API_KEY")
LLM_MODEL = os.getenv("LLM_MODEL")

如果你的模型服务不在本地，把 LLM_API_URL 换成实际服务地址即可。接口路径需要验证是否带 /v1/chat/completions 后缀，有些网关会省略 /v1 。

2.3 整体流程设计

整个 AI 接口自动化测试流程可以拆成以下六步，这也是后续实战章节的展开顺序：

1. 准备接口定义：把被测接口的请求路径、方法、参数、响应示例整理出来。
2. 编写 Schema：用 pydantic 定义请求和响应的结构约束。
3. AI 生成用例：让大模型基于 Schema 和接口说明输出 JSON 格式的测试用例。
4. 生成测试脚本：将 JSON 用例转换成 pytest 函数。
5. 执行测试：运行 pytest 并收集结果。
6. 失败分析：把失败信息交给大模型辅助排查。

这个流程的优点在于，每一步的产物都是可见、可评审的，不是黑盒操作。AI 生成的用例和脚本如果出现问题，测试人员可以直接修改对应的 JSON 或 Python 文件，再重新执行。

3. 核心原理解析

3.1 为什么提示词设计比选择模型更重要

很多初学者以为 AI 测试的效果取决于模型强弱，其实在接口测试这个场景里，提示词的作用往往更大。因为接口测试用例生成是一项规则性很强的任务，你只要把接口的参数约束、业务规则、输出格式描述清楚，模型的表现通常会很稳定。

一个合格的提示词至少需要包含四部分：

• 角色定义：告诉模型它是一个资深测试工程师。
• 输入信息：给模型接口文档、字段说明、Schema 定义。
• 输出格式要求：要求它只输出 JSON，并给出 JSON 结构示例。
• 约束条件：要求它覆盖正常、异常、边界场景，并遵守参数类型和长度限制。

下面是一个最简提示词模板：

你是一名资深接口测试工程师。请根据接口文档生成测试用例。
接口文档如下：
{api_document}

字段约束：
{field_constraints}

要求：
1. 输出 JSON 数组，每个元素包含 case_id、name、priority、request、expected 字段。
2. request 中是请求参数，expected 中是预期状态码、业务 code 和关键响应字段。
3. 必须包含正常用例、参数缺失、参数类型错误、边界值用例。
4. 不要输出任何解释文字，只输出 JSON。

这里的关键是“只输出 JSON”这个约束。大模型直接生成 pytest 代码时容易混入解释性文本，而先生成用例 JSON、再转成脚本，出错率会低很多。

3.2 用 Pydantic 过滤无效字段

模型生成的 JSON 偶尔会出现字段名拼写错误、类型不对、超出枚举范围的情况。与其让这些问题流到测试脚本里，不如在中间层用 pydantic 做一次强校验。

例如模型生成了一个用例，但把 username 写成了 userName ，或者 password 字段缺失，pydantic 会在第一时间抛出校验错误，提示你检查生成结果，而不是最后一个奇怪的脚本错误。

这个思路直接影响工程稳定性。测试脚本本身不应该依赖“运气”，AI 生成的内容也必须经过结构化校验才能进入执行阶段。

4. 完整实战：从接口文档到 AI 测试脚本

接下来用一个实际的用户登录接口和一个商品查询接口，完整跑一遍流程。代码比较多，建议按文件路径逐个创建。

4.1 接口定义示例

假设被测系统提供以下两个接口：

用户登录接口：

• 路径： POST /api/user/login
• 请求参数： username 字符串，3 到 32 个字符； password 字符串，6 到 64 个字符。
• 响应示例：

{
  "code": 0,
  "message": "success",
  "data": {
    "token": "abc123"
  }
}

商品查询接口：

• 路径： GET /api/product/detail
• 请求参数： product_id 整数，大于 0； with_stock 布尔值，可选。
• 响应示例：

{
  "code": 0,
  "message": "success",
  "data": {
    "product_id": 1,
    "name": "测试商品",
    "price": 99.9
  }
}

为了演示，这里不要求被测服务真实存在，你可以在本地用 Flask 或者 Mock 服务模拟。重点看整个 AI 生成与执行流程。

4.2 项目结构

ai-api-testing/
├── .env
├── requirements.txt
├── schemas.py
├── llm_client.py
├── case_generator.py
├── script_generator.py
├── run_tests.py
└── generated/
    ├── test_cases.json
    └── test_api.py

generated 目录用来存放 AI 生成的用例和脚本，每次生成前建议清空，避免旧文件干扰。

4.3 定义 Schema 校验

文件路径： schemas.py

from typing import Optional
from pydantic import BaseModel, Field


class LoginRequest(BaseModel):
    username: str = Field(..., min_length=3, max_length=32)
    password: str = Field(..., min_length=6, max_length=64)


class LoginResponse(BaseModel):
    code: int
    message: str
    data: dict


class ProductQueryRequest(BaseModel):
    product_id: int = Field(..., gt=0)
    with_stock: Optional[bool] = None


class ProductResponse(BaseModel):
    code: int
    message: str
    data: dict


class TestCase(BaseModel):
    case_id: str
    name: str
    priority: str = Field(..., pattern="^(P0|P1|P2)$")
    method: str = Field(..., pattern="^(GET|POST)$")
    path: str
    request: dict
    expected: dict

TestCase 是 AI 生成结果的结构约束。要求 case_id 非空、 priority 只能是 P0/P1/P2、 method 只能是 GET/POST，这样能提前过滤掉模型输出中的很多无效内容。

4.4 封装大模型调用

文件路径： llm_client.py

import os
import json
import requests
from dotenv import load_dotenv

load_dotenv()

LLM_API_URL = os.getenv("LLM_API_URL")
LLM_API_KEY = os.getenv("LLM_API_KEY")
LLM_MODEL = os.getenv("LLM_MODEL")


def chat_once(prompt: str, system: str = "", temperature: float = 0.2) -> str:
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {LLM_API_KEY}"
    }
    payload = {
        "model": LLM_MODEL,
        "messages": [
            {"role": "system", "content": system},
            {"role": "user", "content": prompt}
        ],
        "temperature": temperature
    }
    resp = requests.post(LLM_API_URL, headers=headers, json=payload, timeout=180)
    resp.raise_for_status()
    data = resp.json()
    return data["choices"][0]["message"]["content"]


def chat_json(prompt: str, system: str = "", temperature: float = 0.2):
    """调用模型并尝试把输出解析成 JSON"""
    content = chat_once(prompt, system, temperature)
    try:
        return json.loads(content)
    except json.JSONDecodeError:
        # 部分模型会在 JSON 前后加 ```json 标记，尝试清洗
        content = content.strip().removeprefix("```json").removeprefix("```").removesuffix("```")
        return json.loads(content)

这里需要注意两点：第一，超时时间设置得比较长，因为大模型接口在生成长内容时响应可能较慢；第二， chat_json 里做了 JSON 解析的容错处理，很多模型会在输出前后添加 Markdown 代码块标记，需要先去清洗再解析。

4.5 生成测试用例

文件路径： case_generator.py

import json
from schemas import TestCase
from llm_client import chat_json

API_DOCS = [
    {
        "name": "用户登录",
        "method": "POST",
        "path": "/api/user/login",
        "params": {
            "username": {"type": "string", "min_length": 3, "max_length": 32, "required": True},
            "password": {"type": "string", "min_length": 6, "max_length": 64, "required": True}
        },
        "response_example": {
            "code": 0,
            "message": "success",
            "data": {"token": "abc123"}
        }
    },
    {
        "name": "商品详情",
        "method": "GET",
        "path": "/api/product/detail",
        "params": {
            "product_id": {"type": "integer", "gt": 0, "required": True},
            "with_stock": {"type": "boolean", "required": False}
        },
        "response_example": {
            "code": 0,
            "message": "success",
            "data": {"product_id": 1, "name": "测试商品", "price": 99.9}
        }
    }
]


def build_prompt_for_api(api: dict) -> str:
    return f"""
请为以下接口生成测试用例。

接口名称：{api['name']}
请求方法：{api['method']}
请求路径：{api['path']}
请求参数定义：{json.dumps(api['params'], ensure_ascii=False)}
响应示例：{json.dumps(api['response_example'], ensure_ascii=False)}

要求：
1. 输出一个 JSON 数组，每个元素包含 case_id、name、priority、method、path、request、expected 字段。
2. 必须覆盖正常场景、必填参数缺失、参数类型错误、边界值场景。
3. expected 中必须包含 http_code，并且尽量包含响应中的业务 code。
4. 只输出 JSON，不要输出解释文字。

示例格式：
[
  {{
    "case_id": "T01",
    "name": "正确参数登录成功",
    "priority": "P0",
    "method": "POST",
    "path": "/api/user/login",
    "request": {{"username": "test01", "password": "123456"}},
    "expected": {{"http_code": 200, "code": 0}}
  }}
]
"""


def generate_all_cases():
    all_cases = []
    for api in API_DOCS:
        prompt = build_prompt_for_api(api)
        result = chat_json(prompt, system="你是一名经验丰富的接口测试工程师。", temperature=0.2)
        if isinstance(result, dict):
            result = result.get("test_cases", [])
        for item in result:
            all_cases.append(TestCase(**item))
    return [case.model_dump() for case in all_cases]


if __name__ == "__main__":
    cases = generate_all_cases()
    with open("generated/test_cases.json", "w", encoding="utf-8") as f:
        json.dump(cases, f, ensure_ascii=False, indent=2)
    print(f"生成用例数：{len(cases)}")

这里特别强调 TestCase(**item) 这一步。通过 pydantic 校验，模型输出中如果有字段缺失或类型错误，程序会直接报错并停止，方便你检查是哪一组参数导致的问题。实际项目中你可能更希望跳过错误数据并继续，那可以用异常捕获处理，并把失败数据单独存到一个文件里。

4.6 生成 pytest 脚本

文件路径： script_generator.py

这一步是流程中比较关键的部分。把 JSON 用例转换成可执行的 pytest 函数，不需要 AI 逐行生成代码，而是用一个普通脚本完成模板渲染，这样生成的脚本更稳定。

import json

PYTEST_TEMPLATE = '''
import pytest
import requests

BASE_URL = "http://localhost:8000"

@pytest.mark.parametrize("case", {cases})
def test_api_case(case):
    method = case["method"]
    path = case["path"]
    request_data = case["request"]
    expected = case["expected"]

    url = BASE_URL + path

    if method == "GET":
        resp = requests.get(url, params=request_data, timeout=10)
    else:
        resp = requests.post(url, json=request_data, timeout=10)

    assert resp.status_code == expected.get("http_code", 200), f"HTTP状态码不匹配: {{resp.status_code}}, body={{resp.text}}"

    try:
        body = resp.json()
    except Exception:
        raise AssertionError(f"响应不是合法JSON: {{resp.text}}")

    if "code" in expected:
        assert body.get("code") == expected["code"], f"业务code不匹配: {{body}}"
'''


def load_cases():
    with open("generated/test_cases.json", "r", encoding="utf-8") as f:
        return json.load(f)


def generate_script():
    cases = load_cases()
    content = PYTEST_TEMPLATE.format(cases=json.dumps(cases, ensure_ascii=False))
    with open("generated/test_api.py", "w", encoding="utf-8") as f:
        f.write(content)
    print("脚本已生成：generated/test_api.py")


if __name__ == "__main__":
    generate_script()

生成的脚本会在 generated/test_api.py 中。由于用例是通过 pytest.mark.parametrize 传入的，之后你只需要维护 test_cases.json ，不需要频繁改动 Python 脚本本身。这是接口自动化测试里很常用的一种设计：数据与代码分离。

4.7 运行与验证

文件路径： run_tests.py

import subprocess
import sys


def main():
    proc = subprocess.run(
        [sys.executable, "-m", "pytest", "generated/test_api.py", "-v"],
        capture_output=True,
        text=True
    )
    print(proc.stdout)
    if proc.stderr:
        print(proc.stderr)
    return proc.returncode


if __name__ == "__main__":
    sys.exit(main())

先启动一个本地 Mock 服务，或者直接运行你的被测系统。然后执行：

python case_generator.py
python script_generator.py
python run_tests.py

正常情况下的输出类似：

生成的用例数量请以实际接口为准
脚本已生成：generated/test_api.py
============================= test session starts ==============================
collected 12 items

generated/test_api.py::test_api_case[T01] PASSED
generated/test_api.py::test_api_case[T02] PASSED
...
============================== 12 passed ==================================

到这里，一条 AI 接口自动化测试的最小闭环已经跑通了。

4.8 失败用例的 AI 辅助分析

测试跑完后，你可能会遇到失败用例。传统的做法是人肉去看日志，但可以再让 AI 帮忙做一次初步分析。

思路是：把失败用例的请求参数、响应内容、预期值拼接成一个文本，发送给大模型，让它给出失败原因和排查建议。

# 文件路径：analyze_failure.py
from llm_client import chat_once


def analyze(case_name, request_data, response_text, expected):
    prompt = f"""
接口测试用例执行失败，以下是相关信息：

用例名称：{case_name}
请求参数：{request_data}
响应原文：{response_text}
预期结果：{expected}

请分析可能的原因，并给出排查建议。
输出格式：
1. 最可能的原因
2. 排查步骤
3. 如果是接口bug，说明证据；如果是测试数据问题，给出修改建议
"""
    return chat_once(prompt, system="你是资深测试开发工程师。", temperature=0.3)


if __name__ == "__main__":
    result = analyze(
        "正确参数登录成功",
        '{"username":"test01","password":"123456"}',
        '{"code":-1,"message":"user not found","data":null}',
        '{"http_code":200,"code":0}'
    )
    print(result)

这里的价值在于缩小排查范围。比如它可能指出：“用户不存在，需要先造数”或者“接口返回结构变化，可能是响应字段命名调整”。具体结论仍需测试人员验证，但定位速度能明显提升。

5. 常见问题与排查思路

问题现象	常见原因	解决思路
模型返回内容无法解析为 JSON	模型输出了解释性文字，或添加了 Markdown 标记	在提示词中强调只输出 JSON；在解析时做清洗，去掉 ```json 前缀后缀
生成的用例字段与接口不一致	接口文档描述不完整，或模型理解偏差	加强 pydantic 校验；在提示词中给出字段约束表格；人工评审用例 JSON
测试脚本运行报错：requests.exceptions.ConnectionError	被测服务未启动，或 BASE_URL 配置错误	先确认被测服务可用；检查 generated/test_api.py 中的 BASE_URL
生成脚本后 pytest 收集不到用例	用例 JSON 为空，或脚本文件语法错误	查看 generated/test_cases.json 是否生成成功；检查模板字符串缩进
AI 生成测试用例耗时过长	模型服务响应慢，或一次请求包含过多内容	缩短接口文档；按接口逐个生成；适当减少 prompt 中的示例数量
校验时报 pydantic ValidationError	模型生成的字段类型或枚举不符合约束	定位具体错误字段，补充到提示词的约束描述中；必要时对 AI 输出做二次修正

一个额外的建议：所有 AI 生成的用例和脚本，第一次执行时不要直接当成最终结果。跑通之后，花几分钟浏览一遍用例 JSON，重点看边界值和异常场景是否合理，这能省去后续排错的很多时间。

6. 最佳实践与工程建议

6.1 提示词模板化

不要把提示词散落在各个脚本里。项目稍微变大之后，建议单独建一个 prompts.py 文件，把所有模板集中管理。后续调整模型输出格式时，只改一个文件，经济和维护成本都更低。

格式上，建议优先让模型输出 JSON 而非代码。因为 JSON 结构稳定、容易校验，也方便后续用 pytest 参数化执行。直接生成代码虽然看着省事，但代码的可控性和可维护性会差很多。

6.2 关注 API Key 与数据安全

大模型调用涉及 API Key，必须通过环境变量或密钥管理平台注入，不能提交到 Git 仓库。如果你使用的是外部模型 API，还要注意不要把生产环境的真实用户数据、完整数据库结构、内部 IP 等信息直接拼进提示词。测试环境的数据相对安全，但养成脱敏习惯更稳妥。

6.3 测试数据管理

AI 生成的接口测试用例通常包含写死的测试数据，例如用户名、密码、商品 ID。这些数据在测试环境可能不存在，导致用例执行失败。建议增加一个数据准备步骤，在前置逻辑中通过 SQL 或接口动态创建测试数据，或者至少把常用测试数据提取到一个 test_data.py 文件里统一管理。

6.4 保留人工评审环节

AI 生成用例的覆盖率和使用价值，取决于输入质量。接口文档写得模糊，AI 再强也生不成有效用例。因此整个流程中，测试人员的角色已经转变为“评审者”：

• 评审 Schema 是否有遗漏。
• 评审 AI 生成的用例是否有逻辑错误。
• 评审断言是否符合业务预期。
• 评审失败分析结论是否可信。

这比纯手工写脚本要高效，但也不是完全放飞。

6.5 接入 CI 的思路

当流程稳定后，可以考虑接入 CI。基本思路是：

• 代码提交或接口文档变更时，触发用例生成任务。
• 生成后自动执行 pytest。
• 将失败结果、AI 失败分析一起发送到企业微信、钉钉或飞书机器人。
• 测试人员只处理被标记为“需要人工确认”的失败用例。

CI 的触发频率要控制好，不建议每个 commit 都跑全量，尤其是调用大模型生成用例的步骤比较耗时，更适合在文档变更或定期回归时执行。

7. 一小时学习路线

如果你完全照着上面做，一小时可以这样分配：

• 前 15 分钟：搭建环境，理解 Schema 校验和模型调用的结构。
• 中间 20 分钟：跑通 case_generator.py -> script_generator.py -> run_tests.py 的主流程，重点关注提示词和 JSON 输出。
• 后 15 分钟：把示例接口换成你自己项目里的一个真实接口，观察生成用例的覆盖情况和失败点。
• 最后 10 分钟：用失败分析脚本复盘执行结果，总结哪些用例是 AI 生成的 bug、哪些是测试数据问题。

这套流程跑通之后，你会发现接口测试的日常工作中，最耗时的“文档翻译成脚本”环节已经被显著压缩。接下来值得深入研究的方向包括：多接口关联场景的用例生成、基于流量录制的接口自动建模、以及让 AI 根据 Git 提交信息自动定位受影响接口并生成回归用例。

AI 接口自动化测试的本质，是用大模型替代那些确定性的、重复性的翻译和编码工作，同时保留测试人员对质量和业务逻辑的判断权。照着上面的流程做一遍，再逐步调整成适合自己的节奏，会比单纯收藏一堆视频教程更有收获。