关注 霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集

当企业开始尝试把 AI 接入测试体系时，真正的问题不是“模型够不够强”，而是：

如何在不改动现有系统架构的前提下，让 AI 进入生产流程？

本文拆解一个真实工程实践方案：

• 需求已在数据库

• 不推翻管理系统

• 通过 SQL Agent 精确读取需求

• 通过用例生成 Agent 批量输出结构化测试用例

• 以 API 形式嵌入现有平台

这不是 Demo，而是可落地架构。

---

目录

1. 企业真实问题与技术误区

2. 整体架构设计：数据库 + 双 Agent

3. SQL Agent 的工程实现逻辑

4. 用例生成 Agent 的结构化约束

5. 生产环境必须补上的三块能力

6. 为什么它比“纯 RAG 方案”更稳

7. 测试工程师能力边界的变化

---

一、企业真实问题与技术误区

企业现状通常是：

• 需求在关系型数据库

• 用例编写人工密集

• 格式固定

• 每周批量生成

直觉方案是：

需求文本 → RAG → 生成用例

但会遇到：

• 召回噪声

• 数据覆盖不全

• 无法条件筛选

• 无法自动批量执行

• 不可审计

问题不在模型，而在数据入口。

如果数据本来就在数据库，为什么要退化成纯文本再让模型猜？

---

二、整体架构设计

架构分层

关键原则：

• 数据访问由 SQL Agent 控制

• 生成逻辑由用例 Agent 控制

• 系统接入通过 API 完成

• 原有平台不改

这是低成本改造路径。

---

三、SQL Agent 的工程逻辑

SQL Agent 不是简单 Text2SQL。

它应该具备：

1. 表结构感知

2. SQL 生成

3. 结果验证

4. 执行与解释

5. 错误回退

表结构处理建议

不要依赖模型记忆。

应：

• 明确提供 schema

• 明确字段注释

• 可选：schema 向量化存储 + RAG 召回

这一步决定 SQL 成功率。

---

四、用例生成 Agent 的结构化约束

第二个 Agent 只做一件事：

把“结构化需求”变成“结构化测试用例”

不要让它做数据检索。

输出必须强制 JSON 结构，例如：

{
  "title": "",
  "precondition": "",
  "steps": [],
  "expected_result": ""
}

同时建议增加：

• 字段数量约束

• 步骤数量上限

• 禁止解释性废话

如果数据量大，可采用分批策略：

---

五、生产环境必须补上的三块能力

1. 权限与安全隔离

SQL Agent 绝不能直接暴露数据库 root 权限。

建议：

• 只读账号

• 指定可访问表

• 禁止 DDL / DELETE / UPDATE

• 加 SQL 白名单校验

否则 Agent 一次 hallucination 就可能删库。

---

2. 可观测性与日志追踪

需要记录：

• 输入提示词

• 生成 SQL

• 执行结果

• 生成用例

• 重试次数

建议增加 Trace ID。

没有可观测性，生产环境无法调试。

---

3. 用例质量评估体系

生成 ≠ 合格。

应设计自动评估：

• 是否覆盖关键字段

• 是否存在逻辑冲突

• 是否缺少前置条件

• 是否步骤过少

• 是否期望结果为空

可以构建“二次评估 Agent”或规则校验器。

否则 80% 自动生成也可能是 80% 垃圾。

---

六、为什么它比“纯 RAG”更稳？

RAG 适合：

• 文档问答

• 知识召回

• FAQ

但结构化数据场景下：

数据库才是权威来源。

SQL Agent 的优势：

• 精准筛选

• 可排序

• 可分页

• 可条件过滤

• 可审计

RAG 在这里的作用是补充 schema 说明，而不是替代数据库。

---

七、测试工程师能力边界的变化

当 70%~80% 用例可以自动生成时，测试工程师的角色开始转移：

从：

• 编写用例

转向：

• 设计生成规则

• 控制输出质量

• 构建验证机制

• 设计风险模型

这不是替代，而是升级。

---

写在最后

这个方案的核心思想并不复杂：

• 数据由数据库保证

• 执行由 Agent 控制

• 正确性由 Validator 保证

• 接入通过 API 完成

• 安全通过权限隔离控制

• 质量通过评估机制保证

模型会变。

框架会变。

但工程思维不会变。

真正拉开差距的，不是“谁会用模型”，而是：

谁能把模型嵌入生产系统，并保证它可控、可审计、可维护。

当 AI 开始参与测试流程时， 架构能力才是测试工程师新的护城河。

---

关于我们

霍格沃兹测试开发学社，隶属于 测吧（北京）科技有限公司，是一个面向软件测试爱好者的技术交流社区。

学社围绕现代软件测试工程体系展开，内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试，以及人工智能测试与 AI 在测试工程中的应用实践。

我们关注测试工程能力的系统化建设，包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设，同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法，沉淀可复用、可落地的测试开发工程经验。

在技术社区与工程实践之外，学社还参与测试工程人才培养体系建设，面向高校提供测试实训平台与实践支持，组织开展 “火焰杯” 软件测试相关技术赛事，并探索以能力为导向的人才培养模式，包括高校学员先学习、就业后付款的实践路径。

同时，学社结合真实行业需求，为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务，用于个性化能力提升与工程实践指导。