前段时间接手一个内部管理系统的接口回归测试接口数量不算夸张几十个但问题在于文档不完整有些字段只在前端代码里出现有些错误码只在历史 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 怎么处理pageNo0是报错还是自动修正列表排序规则是什么是否存在跨组织数据泄露风险这些才是测试设计的重点。核心模块一先让 AI 找“文档缺口”不要直接生成用例第一步我不再让 AI 写用例而是让它检查接口文档缺失了哪些测试关键信息。Prompt 示例你是接口测试分析助手。请阅读下面的接口文档不要生成测试用例。 任务 找出这份接口文档中会影响测试设计的信息缺口。 要求 1. 只基于文档内容分析不要猜测系统行为。 2. 按参数校验、权限、返回结构、分页排序、数据安全、错误码、测试数据准备分类。 3. 每个缺口说明为什么会影响测试。 4. 对每个缺口给出需要向研发或产品确认的问题。 5. 不要编造默认规则。输出会更接近测试人员真正需要的内容分类信息缺口影响需要确认参数校验pageSize 未说明最大值无法设计上限边界用例pageSize 最大允许多少超过后返回错误还是截断权限未说明非管理员返回格式无法断言错误码和提示信息非管理员访问时 HTTP 状态码和业务码分别是什么数据安全手机号脱敏规则未定义无法验证返回字段是否合规脱敏格式是 138****1234 还是其他规则分页排序未说明默认排序无法验证列表顺序稳定性默认按 createdAt 倒序吗错误码未提供错误码表自动化断言缺少依据参数错误、未登录、无权限分别对应什么错误码这一步非常关键。很多接口测试质量低不是因为测试不会写用例而是因为文档缺口被忽略了。AI 在这里的价值是帮你把“隐性问题”显性化。核心模块二基于已确认规则生成用例矩阵等研发或产品补充规则后再让 AI 生成测试用例。此时 Prompt 要加约束不能写没有依据的预期结果。假设补充规则如下补充规则 1. pageNo 必须 1否则返回 PARAM_ERROR。 2. pageSize 范围 1100否则返回 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正向管理员查询第一页用户pageNo1pageSize20返回成功HTTP 200、列表字段完整是USER_002边界pageSize100pageNo1pageSize100返回成功返回数量不超过 100是USER_003异常pageSize101pageNo1pageSize101PARAM_ERROR业务码、错误提示是USER_004权限未登录访问无登录态HTTP 401状态码、响应结构是USER_005数据安全手机号脱敏管理员查询存在手机号用户手机号中间四位为星号正则校验是USER_006排序默认按创建时间倒序pageNo1pageSize20createdAt 倒序相邻记录时间比较是这里要注意一点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(paramsNone, tokenNone): headers {} if token: headers[Authorization] fBearer {token} return requests.get( f{BASE_URL}/api/users, paramsparams or {}, headersheaders, timeout5 ) def test_admin_query_user_list_success(): resp get_users( params{pageNo: 1, pageSize: 20}, tokenADMIN_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}, tokenADMIN_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}, tokenADMIN_TOKEN ) body resp.json() assert body.get(code) PARAM_ERROR def test_unauthorized_access(): resp get_users( params{pageNo: 1, pageSize: 20}, tokenNone ) assert resp.status_code 401 def test_forbidden_for_non_admin(): resp get_users( params{pageNo: 1, pageSize: 20}, tokenUSER_TOKEN ) assert resp.status_code 403 def test_phone_mask_format(): resp get_users( params{pageNo: 1, pageSize: 20}, tokenADMIN_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 状态码业务 codemessagedata 结构list 是否数组total 是否为整数分页数量是否正确字段类型手机号脱敏格式排序是否稳定权限数据是否隔离响应时间是否超过阈值。Prompt请为这些接口测试用例补充断言清单。 要求 1. 按基础断言、业务断言、安全断言、性能观察项分类。 2. 每个断言说明验证目的。 3. 标注哪些断言适合自动化哪些需要人工辅助。这样生成的内容更容易转成自动化代码也方便 Code Review。辅助模块三用验收表检查 AI 生成结果AI 生成的测试用例进入团队之前我建议至少做一张验收表验收项检查问题规则依据每条预期结果是否来自文档或已确认规则错误码是否编造了不存在的错误码数据准备是否说明前置数据如何构造权限场景是否覆盖未登录、无权限、越权访问边界条件是否覆盖最小值、最大值、越界值断言完整性是否包含状态码、业务码、结构、字段、安全断言自动化可行性是否区分可自动化和暂不适合自动化安全合规是否移除了真实用户信息、Token、内部地址可维护性用例 ID、优先级、模块归属是否清晰只要发现 AI 编造规则就应该回到文档确认阶段而不是在生成结果上继续修修补补。数据安全接口文档和日志要先脱敏测试过程中很容易把以下内容贴给 AI内部域名真实 Token用户手机号订单号数据库表名生产日志客户反馈原文内部错误堆栈。这些内容不应该原样输入。最基本的处理方式是替换成占位符原始 GET https://internal.xxx.com/api/users?phone13812345678 Authorization: Bearer eyJhbGci... 脱敏 GET {BASE_URL}/api/users?phonePHONE_A Authorization: Bearer TOKEN_MASKED如果要保留字段关系可以使用USER_A、ORDER_A、ORG_A这类一致性标识既能让 AI 理解上下文又不会暴露真实数据。常见误区1. 让 AI 一次性生成“完整测试用例”这种输出通常看起来很全但里面可能混着猜测、模板化场景和不可执行用例。更好的方式是先找文档缺口再补规则再生成矩阵。2. 只关注正向和参数异常接口测试还要关注权限、越权、数据脱敏、分页排序、幂等性、历史 Bug 回归等场景。3. AI 生成代码后直接接入 CI不建议。至少要本地运行、校正断言、准备测试数据并让测试或研发 Review 一轮。4. Prompt 写得越长越好不是。关键是明确边界不能编造规则、必须引用依据、要区分自动化和手工测试。结语把 AI 放在“测试设计助手”的位置这次实践后我对 AI 辅助接口测试的定位更清楚了它不适合直接替代测试工程师但很适合做三件事从接口文档里找缺口根据确认规则生成用例矩阵把用例转成自动化测试骨架和断言清单。如果团队想低门槛尝试可以先选一个中等复杂度接口不要从支付、权限中心、生产数据修复这类高风险模块开始。把文档脱敏后交给 AI先让它提问题再让研发补规则最后由测试人员确认用例和脚本。AI 能提高测试设计的起步速度但测试质量仍然来自明确的规则、稳定的数据、可执行的断言和人工 Review。对接口测试来说这个边界比“生成了多少条用例”更重要。