用 Harness 思维搭建接口知识库：让 AI 精准生成功能测试用例

沈宥

发布于 2026-04-14 18:14:28

摘要你是否遇到过：

开发改了接口，QA 却不知道影响了哪些功能？
AI 生成的测试用例“看起来合理”，但业务上完全错误？

根本原因：AI 缺少对“接口业务语义”的理解。本文教你用 Harness 工程思想，从零搭建一个 结构化接口知识库，并将其融入测试流程。 ✅ 不依赖商业工具 ✅ 所有数据可本地管理 ✅ 支持自动生成精准的功能测试用例 ✅ 与 MR（代码合并请求）联动，实现智能回归 **让你的 AI 测试助手，真正“懂业务”**。

一、为什么需要“接口知识库”？

很多团队以为 Swagger 就是接口文档——但它只回答了 **“怎么调”，没回答 “为什么这样设计”**。

而 QA 需要知道的是：

这个字段为 null 时，前端应该显示什么？
如果用户是 VIP，这个接口会跳过哪些校验？
哪些老接口会因为这个修改而行为改变？

💡 接口知识库 = Swagger + 业务规则 + 调用关系 + 影响范围 它是 **AI 理解业务逻辑的“燃料”**。

没有它，AI 再聪明，也只能“照猫画虎”；有了它，AI 才能“举一反三”。

二、Harness 思维：知识库不是文档，而是“可执行的上下文”

在 Harness 工程中，知识库不是静态 Wiki，而是：

结构化（机器可读）
关联化（知道谁调谁）
可查询（支持按变更自动检索）
可验证（能和实际流量比对）

我们用一个真实例子说明。

🌰 场景：福利卡接口新增“会员免验证码”逻辑

被修改接口： com.test.wallet.order.controller.WelfareCardCtrl#info

MR 新增代码：

java编辑

MemberDto member = memberRpcService.getMemberByPhoneNo(phone);
if (member != null) {
    offsitePhoneInfo.setNeedCaptcha(false);
}

传统方式：QA 手动问开发：“这个改了会影响哪些页面？”

Harness 方式：系统自动查询知识库，输出：

新场景：已注册会员 → needCaptcha=false
回归场景：非会员 / 空号 → needCaptcha=true 必须仍成立
影响页面：H5 福利卡页、小程序 card-detail 组件
依赖服务：memberRpcService.getMemberByPhoneNo（需 mock）

这一切，都来自提前建好的知识库。

三、动手搭建：四步构建你的接口知识库

步骤 1：定义标准元数据格式（YAML）

为每个核心接口创建一个 .yaml 文件，例如 welfare_card_info.yaml：

yaml编辑

# 接口基本信息
interface:
  full_name: com.test.wallet.order.controller.WelfareCardCtrl#info
  name: 福利卡详情查询
  description: 用户进入福利卡页面时返回卡信息及验证码策略

# 输入参数
input:
  phoneNo:
    type: string
    required: true
    rules:
      - "必须为 11 位中国大陆手机号"
      - "若为空或格式错误，返回 400"

# 输出字段
output:
  needCaptcha:
    type: boolean
    business_rules:
      - "若用户是已注册会员（通过 memberRpcService 查询存在），则为 false"
      - "否则为 true"
  cardList:
    type: array
    description: 用户可领取的福利卡列表

# 依赖的下游服务
upstream_calls:
  - service: memberRpcService
    method: getMemberByPhoneNo
    purpose: "判断用户是否为注册会员"
  - service: cardRuleService
    method: getRules
    purpose: "获取卡使用规则"

# 被哪些前端调用
downstream_consumers:
  - type: H5
    page: /welfare/card
    usage: "展示福利卡并决定是否弹验证码"
  - type: MiniProgram
    component: card-detail
    usage: "同上"

✅ 关键：用 business_rules 字段描述业务逻辑，而非技术实现。

步骤 2：建立调用关系图（用 Neo4j 或 CSV）

除了单个接口，还需知道 谁调谁。可用简单 CSV 表示：

csv编辑

caller, callee, scenario
WelfareCardCtrl#info, memberRpcService#getMemberByPhoneNo, "判断是否免验证码"
ProfileController#update, WelfareCardCtrl#info, "用户编辑资料时预加载福利卡"

未来可导入 Neo4j，实现可视化影响分析。

步骤 3：与 Git MR 联动（自动化触发）

在 CI 中加入脚本，当 MR 提交时：

解析 git diff，提取修改的类和方法
匹配知识库中的 full_name
自动输出：
- 需补充的测试场景
- 需回归的上下游接口
- 廍议的 mock 策略

示例输出（可直接评论到 MR）：

🔍 检测到 WelfareCardCtrl#info 修改 ✅ 新增场景：已注册会员应免验证码 🔄 需回归：非会员路径、空手机号路径 🧪 建议测试：mock memberRpcService 返回 null / MemberDto 🌐 影响前端：H5 /welfare/card 页面

步骤 4：集成 LLM，生成精准测试用例

将知识库内容注入 Prompt，让 LLM 生成业务正确的测试：

python编辑

prompt = f"""
你是一名资深 QA，请基于以下接口知识生成功能测试用例：

【接口】{meta['name']}
【业务规则】{meta['output']['needCaptcha']['business_rules']}
【依赖服务】{meta['upstream_calls']}

请输出：
1. 新增分支的正向/异常用例
2. 老路径的回归用例
3. 前端验证步骤（如适用）
"""
test_cases = llm.ask(prompt)