用 AI 辅助生成接口测试用例：一次从“看起来很全”到“可落地执行”的改造

2601_96268328

211人浏览 · 2026-06-29 16:00:08

2601_96268328 · 2026-06-29 16:00:08 发布

前段时间接手一个内部管理系统的接口回归测试，接口数量不算夸张，几十个，但问题在于文档不完整：有些字段只在前端代码里出现，有些错误码只在历史 Bug 单里出现，还有几个接口的分页、排序、权限规则写得很含糊。测试同事的第一反应是：让 AI 直接根据接口文档生成测试用例，应该能省不少时间。

我一开始也是这么想的。为了观察不同模型在“接口理解、边界条件补全、测试用例结构化”上的差异，我把同一份脱敏后的接口说明放进一个多模型聚合环境里做了几轮对照，在同一个测试环境中、在同一界面切换 ChatGPT、Claude、Gemini、Grok 等模型，把同一任务交给不同模型复跑，看输出差异。

但实际跑下来发现，AI 生成测试用例这件事，真正的难点不是“能不能写出一堆用例”，而是：这些用例能不能被测试人员执行、能不能映射到接口规则、能不能转成自动化脚本、能不能减少误判。

第一次翻车：AI 生成了 80 条用例，但一半不能直接用

最开始我给 AI 的 Prompt 很简单：

请根据下面的接口文档生成完整的接口测试用例，包括正常场景、异常场景和边界场景。

它很快生成了一个表格，包含：

正常查询；
参数为空；
参数类型错误；
分页参数越界；
未登录访问；
权限不足；
数据不存在；
服务器异常。

看上去很完整，甚至有点像测试用例模板。但真正检查时，问题就出来了：

它假设了接口行为
文档没写 pageSize 最大值，它直接写了“pageSize 大于 100 返回错误”。
它编造了错误码
输出里出现了 40001、40301、50001，但系统实际错误码不是这样定义的。
它把 HTTP 状态码和业务错误码混在一起
比如权限不足到底是 HTTP 403，还是 HTTP 200 + 业务码，需要看系统约定。
它生成了无法准备数据的用例
例如“用户拥有部分组织权限”，但没有说明测试数据怎么构造。
它没有区分手工测试和自动化测试
有些场景适合自动化，有些涉及权限审批或复杂数据准备，更适合手工验证。

这次之后我调整了思路：不要让 AI 一次性生成“完整用例”，而是把任务拆成三个阶段。

场景设定：一个用户列表查询接口

下面用一个简化后的接口说明举例。

接口：GET /api/users

功能：查询用户列表

请求参数：
- keyword：字符串，可选，按姓名或手机号模糊搜索
- status：整数，可选，0 禁用，1 启用
- pageNo：整数，必填，从 1 开始
- pageSize：整数，必填，默认 20

返回字段：
- id：用户 ID
- name：姓名
- phone：手机号脱敏展示
- status：用户状态
- createdAt：创建时间

权限：
- 需要登录
- 仅管理员可访问

文档看起来够用了，但测试人员会立刻追问：

pageSize 最大值是多少？
keyword 支持空格吗？
手机号脱敏规则是什么？
非管理员访问返回什么？
status 传 2 怎么处理？
pageNo=0 是报错还是自动修正？
列表排序规则是什么？
是否存在跨组织数据泄露风险？

这些才是测试设计的重点。

核心模块一：先让 AI 找“文档缺口”，不要直接生成用例

第一步，我不再让 AI 写用例，而是让它检查接口文档缺失了哪些测试关键信息。

Prompt 示例：

你是接口测试分析助手。请阅读下面的接口文档，不要生成测试用例。

任务：
找出这份接口文档中会影响测试设计的信息缺口。

要求：
1. 只基于文档内容分析，不要猜测系统行为。
2. 按参数校验、权限、返回结构、分页排序、数据安全、错误码、测试数据准备分类。
3. 每个缺口说明为什么会影响测试。
4. 对每个缺口给出需要向研发或产品确认的问题。
5. 不要编造默认规则。

输出会更接近测试人员真正需要的内容：

分类	信息缺口	影响	需要确认
参数校验	pageSize 未说明最大值	无法设计上限边界用例	pageSize 最大允许多少？超过后返回错误还是截断？
权限	未说明非管理员返回格式	无法断言错误码和提示信息	非管理员访问时 HTTP 状态码和业务码分别是什么？
数据安全	手机号脱敏规则未定义	无法验证返回字段是否合规	脱敏格式是 138****1234 还是其他规则？
分页排序	未说明默认排序	无法验证列表顺序稳定性	默认按 createdAt 倒序吗？
错误码	未提供错误码表	自动化断言缺少依据	参数错误、未登录、无权限分别对应什么错误码？

这一步非常关键。
很多接口测试质量低，不是因为测试不会写用例，而是因为文档缺口被忽略了。AI 在这里的价值是帮你把“隐性问题”显性化。

核心模块二：基于已确认规则生成用例矩阵

等研发或产品补充规则后，再让 AI 生成测试用例。此时 Prompt 要加约束：不能写没有依据的预期结果。

假设补充规则如下：

补充规则：
1. pageNo 必须 >= 1，否则返回 PARAM_ERROR。
2. pageSize 范围 1～100，否则返回 PARAM_ERROR。
3. status 只能为 0 或 1，否则返回 PARAM_ERROR。
4. keyword 前后空格会 trim，空字符串等同于未传。
5. 未登录返回 HTTP 401。
6. 已登录但非管理员返回 HTTP 403。
7. 手机号返回格式为前三后四，中间四位星号。
8. 默认按 createdAt 倒序。

Prompt：

请根据接口文档和补充规则，生成接口测试用例矩阵。

要求：
1. 每条用例必须引用对应规则编号。
2. 不要添加规则中没有说明的预期行为。
3. 字段包括：用例ID、测试目标、前置条件、请求参数、测试数据、预期结果、断言点、优先级、适合自动化。
4. 区分正向、异常、边界、权限、数据安全场景。
5. 对测试数据难以构造的用例，在备注中说明。

输出结构可以是：

用例ID	类型	测试目标	请求参数	预期结果	断言点	自动化
USER_001	正向	管理员查询第一页用户	pageNo=1&pageSize=20	返回成功	HTTP 200、列表字段完整	是
USER_002	边界	pageSize=100	pageNo=1&pageSize=100	返回成功	返回数量不超过 100	是
USER_003	异常	pageSize=101	pageNo=1&pageSize=101	PARAM_ERROR	业务码、错误提示	是
USER_004	权限	未登录访问	无登录态	HTTP 401	状态码、响应结构	是
USER_005	数据安全	手机号脱敏	管理员查询存在手机号用户	手机号中间四位为星号	正则校验	是
USER_006	排序	默认按创建时间倒序	pageNo=1&pageSize=20	createdAt 倒序	相邻记录时间比较	是

这里要注意一点：AI 生成的是“用例草稿”，不是最终测试资产。测试人员还需要根据真实数据、环境限制、历史缺陷和业务优先级做调整。

核心模块三：把用例转成自动化测试骨架

对 CSDN 读者来说，只停留在表格不够。更实用的是让 AI 根据用例矩阵生成自动化测试骨架。

例如我们使用 Python + pytest + requests，可以这样要求：

请根据上面的接口测试用例矩阵，生成 pytest 测试代码骨架。

要求：
1. 只生成测试结构和断言示例，不要写死真实域名、Token、账号密码。
2. 使用环境变量读取 BASE_URL 和 TOKEN。
3. 将请求方法封装为函数。
4. 对手机号脱敏使用正则断言。
5. 对需要测试数据准备的地方用 TODO 标注。
6. 不要编造未提供的接口。

示例代码：

import os
import re
import requests

BASE_URL = os.getenv("BASE_URL", "http://localhost:8080")
ADMIN_TOKEN = os.getenv("ADMIN_TOKEN", "")
USER_TOKEN = os.getenv("USER_TOKEN", "")

def get_users(params=None, token=None):
    headers = {}
    if token:
        headers["Authorization"] = f"Bearer {token}"

    return requests.get(
        f"{BASE_URL}/api/users",
        params=params or {},
        headers=headers,
        timeout=5
    )

def test_admin_query_user_list_success():
    resp = get_users(
        params={"pageNo": 1, "pageSize": 20},
        token=ADMIN_TOKEN
    )

    assert resp.status_code == 200
    body = resp.json()
    assert "data" in body

    # TODO: 根据实际响应结构调整
    rows = body["data"].get("list", [])
    for item in rows:
        assert "id" in item
        assert "name" in item
        assert "phone" in item
        assert "status" in item
        assert "createdAt" in item

def test_page_size_upper_boundary():
    resp = get_users(
        params={"pageNo": 1, "pageSize": 100},
        token=ADMIN_TOKEN
    )

    assert resp.status_code == 200
    rows = resp.json()["data"].get("list", [])
    assert len(rows) <= 100

def test_page_size_exceed_limit():
    resp = get_users(
        params={"pageNo": 1, "pageSize": 101},
        token=ADMIN_TOKEN
    )

    body = resp.json()
    assert body.get("code") == "PARAM_ERROR"

def test_unauthorized_access():
    resp = get_users(
        params={"pageNo": 1, "pageSize": 20},
        token=None
    )

    assert resp.status_code == 401

def test_forbidden_for_non_admin():
    resp = get_users(
        params={"pageNo": 1, "pageSize": 20},
        token=USER_TOKEN
    )

    assert resp.status_code == 403

def test_phone_mask_format():
    resp = get_users(
        params={"pageNo": 1, "pageSize": 20},
        token=ADMIN_TOKEN
    )

    assert resp.status_code == 200
    rows = resp.json()["data"].get("list", [])

    # TODO: 确保测试环境存在带手机号的用户数据
    for item in rows:
        phone = item.get("phone")
        if phone:
            assert re.match(r"^\d{3}\*{4}\d{4}$", phone)

这段代码不能直接上线到 CI，但它已经把框架搭起来了。测试人员要做的是：

校正响应 JSON 路径；
替换真实错误码字段；
准备测试账号和数据；
加入 fixture；
接入测试报告；
放进 CI 流水线。

AI 负责起草，工程化仍然要靠人。

辅助模块一：让 AI 反查“不可自动化”的部分

不是所有测试都适合自动化。尤其是权限链路、审批流程、跨系统数据同步，有些用例自动化成本很高。

可以追加一个 Prompt：

请检查上面的测试用例矩阵，标出不适合第一阶段自动化的用例。

要求：
1. 给出原因：数据难准备、依赖外部系统、状态不可控、断言不稳定、风险较高。
2. 给出替代方案：手工验证、Mock、预置数据、后续自动化。
3. 不要删除用例，只调整执行策略。

这一步能避免一个常见问题：团队为了“自动化率”把复杂场景硬塞进脚本，最后脚本频繁失败，反而没人信测试结果。

辅助模块二：让 AI 做断言清单，而不是只写步骤

很多 AI 生成的测试用例只有“输入”和“预期”，但断言点很粗。接口自动化真正要稳定，断言需要拆细。

例如用户列表接口，断言可以分为：

HTTP 状态码；
业务 code；
message；
data 结构；
list 是否数组；
total 是否为整数；
分页数量是否正确；
字段类型；
手机号脱敏格式；
排序是否稳定；
权限数据是否隔离；
响应时间是否超过阈值。

Prompt：

请为这些接口测试用例补充断言清单。

要求：
1. 按基础断言、业务断言、安全断言、性能观察项分类。
2. 每个断言说明验证目的。
3. 标注哪些断言适合自动化，哪些需要人工辅助。

这样生成的内容更容易转成自动化代码，也方便 Code Review。

辅助模块三：用验收表检查 AI 生成结果

AI 生成的测试用例进入团队之前，我建议至少做一张验收表：

验收项	检查问题
规则依据	每条预期结果是否来自文档或已确认规则
错误码	是否编造了不存在的错误码
数据准备	是否说明前置数据如何构造
权限场景	是否覆盖未登录、无权限、越权访问
边界条件	是否覆盖最小值、最大值、越界值
断言完整性	是否包含状态码、业务码、结构、字段、安全断言
自动化可行性	是否区分可自动化和暂不适合自动化
安全合规	是否移除了真实用户信息、Token、内部地址
可维护性	用例 ID、优先级、模块归属是否清晰

只要发现 AI 编造规则，就应该回到文档确认阶段，而不是在生成结果上继续修修补补。

数据安全：接口文档和日志要先脱敏

测试过程中很容易把以下内容贴给 AI：

内部域名；
真实 Token；
用户手机号；
订单号；
数据库表名；
生产日志；
客户反馈原文；
内部错误堆栈。

这些内容不应该原样输入。最基本的处理方式是替换成占位符：

原始：
GET https://internal.xxx.com/api/users?phone=13812345678
Authorization: Bearer eyJhbGci...

脱敏：
GET {BASE_URL}/api/users?phone=PHONE_A
Authorization: Bearer TOKEN_MASKED

如果要保留字段关系，可以使用 USER_A、ORDER_A、ORG_A 这类一致性标识，既能让 AI 理解上下文，又不会暴露真实数据。