AI辅助软件测试提效：7大Skill让SQL检测与用例生成自动化

测试群里最常出现的求助是：“这条 SQL 线上为什么慢，帮我看看？”以前的做法是把 SQL 粘到数据库看执行计划，再对着表结构一条条排查有没有SELECT *、大偏移深分页、隐式类型转换。查 10 条还能忍，查 50 条就会出现人眼扫描容易漏的问题，更不要说要补接口断言、造测试数据、整理回归范围这些事情。软件测试真正耗时间的，往往不是“执行”，而是把这些输入一次次念给不同工具听。

这篇文章不打算讲“怎么让 AI 帮你写一条 SQL”，而是讲一套可以反复使用的思路：把 SQL 质量检测、数据一致性核对、接口用例生成、UI 自动化脚本辅助、测试数据构造、缺陷回归筛选、巡检冒烟这些高频动作封装成 Skill（技能包）。搭好之后，以后遇到同类任务只需要一句话触发，不用每次把背景、规则、输出格式重新描述一遍。

标题里的“效率提升 200 倍”，我的理解更务实：当任务可以批量执行、判断规则又足够明确时，自动化和人工逐条处理的差距确实可能到两个数量级。它不是一个适合所有场景的指标，但 SQL 检测这类“规则型任务”天然适合先自动化。这套 7 大 Skills 也不是独家压箱底方案，而是建议你按下面的模板，在自己的测试岗位搭一套能跑的版本。

如果你是下面这几类人，这篇会比较有用：已经用过 AI 工具写脚本，但发现每次都要从头描述需求的测试工程师；经常处理 SQL 数据查验或性能判断的技术人员；写接口用例或 UI 自动脚本耗时较长的人；想把自己的测试工作流从“零散提问”升级为“标准化产物”的人。

1. 核心能力速览：这套 Skill 方案解决什么问题

先给一张速览表。注意这不是一个下载即用的“测试平台”，而是一套组织 AI 工具协作方式的方法。

为什么我把范围控制在“规则明确的场景”？

因为 Skill 的工作机制是：把人对某类任务的经验沉淀成“规则 + 示例 + 输出格式”，再让 AI 按固定路径执行。SQL 静态检查非常适合，因为怀疑点无非是SELECT *、条件列没有索引、JOIN 类型异常、深分页、类型转换。接口用例生成也适合，因为方法论基本固定：正常参数、缺参、类型错误、边界值、鉴权失败、SQL 层面的数据断言。反而是“探索性测试”或“完全没标准的业务判断”不适合做 Skill，AI 输出会变成看起来认真的空话。

真实的高效来源是工作流压缩。比如一条一条 SQL 人工看到 200 条，就算每条只看 2 分钟，也要接近 7 小时；如果规则文件写清，脚本批量跑一遍生成报告，再由人工抽检高风险项，时间会降到十几分钟到半小时。这才是“200 倍”的合理含义，不是说模型生成单个结果变快了，而是整体流程变短了。

2. Skill 机制：为什么它比“每次都写 Prompt”更适合测试

很多人用 AI 工具的第一步是复制一段 Prompt，比如“帮我检查这段 SQL 有没有问题”。第一次有效，第二次要重新贴一遍背景，第三次还要解释什么是高风险。这个问题的本质是经验没有沉淀，而 Skill 正好解决这个沉淀问题。

可以把 Skill 理解为“一个带规则和示例的专用任务包”。它不再是一条随时会被聊天记录冲走的 Prompt，而是一个目录，里面包含：任务说明、判断规则、输入格式要求、输出报告模板、正反示例。测试工程师对这套结构应该很熟，因为测试工作本身就需要把“验收清单”写清楚，Skill 等于把验收清单喂给了 AI，让它在执行前就知道要按什么标准交付。

一个典型的 Skill 目录长这样：

sql-review/ ├── SKILL.md # 技能说明：用途、触发方式、输入输出 ├── rules/ │ └── sql_static_rules.md # 规则库：静态检查要命中哪些风险点 ├── templates/ │ ├── input_prompt.md # 输入模板：待检测 SQL 要怎么格式化 │ └── output_report.md # 输出模板：检测报告结构 └── examples/ ├── high_risk_query.sql # 反例：包含多种风险的 SQL └── ok_query.sql # 正例：可接受的 SQL

这个目录不绑定具体平台。很多 AI 工具会在对话中自动读取 Skill 目录，或要求你先安装到指定目录。如果你的工具没有“Skill”按钮，也可以退而求其次：把规则文件内容复制到系统提示词里。区别在于维护性差一点，但思路一致。

触发时，最理想的交互是直接写：

/skill sql-review 检测 sql_case/high_risk.sql，并输出 Markdown 报告

如果不支持“/skill”语法，就改成一条完整指令：

请读取 sql-review/skills 下的规则文件，再检测 sql_case/high_risk.sql， 输出格式按 templates/output_report.md 执行。

真正值钱的不是“AI 能回答”，而是这套文件可以被 Git 管理、多人协作改规则、后续批量跑。测试团队如果能沉淀出这样的规则资产，换个新人也只需要把同一个 Skill 目录丢过去，产出的报告风格还是统一的。

3. 7 大 Skills：覆盖软件测试常见场景

下面这套 7 个 Skill 的设计，覆盖了日常测试中比较常见的重复劳动。你不用照搬，先看我为什么要这样切分，再结合实际岗位调整。

3.1 SQL 静态质量检测

这个 Skill 放在第一位，因为收益最直接。很多测试团队会收到开发提测的建表脚本、数据订正脚本、统计报表 SQL，但测试人员自己未必会逐条看执行计划。规则型技能最适合先做。

输入建议固定为：待检测 SQL + 相关表结构 DDL + 数据库类型。没有 DDL 时，AI 可以推断一部分风险，但要明确告诉它“没有表结构只能做启发式分析，不要假装知道索引”。输出要覆盖风险等级、命中规则、修复建议，并且优先用“是否可以执行计划验证”作为后续人工复核的入口。

建议用 Git 保存一份sql_static_rules.md规则库，团队评审过的规则才加进去。不要今天让 AI 按 8 条规则查，明天又变成 3 条，否则报告会不稳定。

3.2 数据一致性核对

数据核对是测试里少见的“开发不一定会写”的任务。比如订单表和订单明细表的总金额对不上，你要自己拼 SQL 查差异。如果你让 AI 每次现写，太浪费；设计成 Skill 之后，输入“哪两张表、什么时间范围、哪个键关联”，就可以生成对账 SQL。

对账 SQL 的基本模式是：两边先按维度汇总，再用LEFT JOIN做差值计算。示意如下：

-- 订单表与订单明细的金额汇总核对（测试环境执行） SELECT a.order_date, a.order_total - b.detail_total AS diff_amount FROM ( SELECT order_date, SUM(amount) AS order_total FROM orders WHERE order_date = '2025-03-01' GROUP BY order_date ) a LEFT JOIN ( SELECT order_date, SUM(detail_amount * quantity) AS detail_total FROM order_items WHERE order_date = '2025-03-01' GROUP BY order_date ) b ON a.order_date = b.order_date;

运行这个脚本只能在有授权的测试环境或数据快照上执行。如果差异值不等于 0，再让 AI 往下拆，比如按渠道、支付状态、商品分类分组，缩小范围。这个 Skill 的难点不是生成 SQL，而是让 AI 先弄清楚两张表的粒度差异，避免无效对账。

3.3 接口测试用例生成

接口测试最怕的不是不会写代码，而是用例没有覆盖到“数据正确性”。很多用例只断言了 HTTP 200，一旦接口返回 200 但数据少了两条，测试依然会漏。这个 Skill 可以要求 AI 输出两层断言：第一层是响应状态码和结构，第二层是 SQL 或查询接口里的数据结果是否符合预期。

输入推荐使用 OpenAPI/Swagger 或者一段真实请求的 JSON。AI 可以解析出参数、必填项、枚举值，然后生成 pytest 风格用例。它还可以针对每个参数生成缺省、空字符串、非法类型、超长、越权访问等用例，测试人员拿到后补上鉴权信息就能跑。

这个 Skill 的边界是不要直接拿生产流量自动生成攻击性用例。涉及权限类测试时，要在已授权的测试环境，并确认你不是在扫描他人系统。

3.4 UI 自动化脚本生成

UI 自动化的痛点不是语法，而是“操作步骤和选择器不稳定”。这个 Skill 吃进的是测试人员写的自然语言操作流程，输出 Playwright 或 Selenium 脚本骨架。AI 最大的帮助是帮你把“点击登录、输入账号、等待列表加载”这类描述翻译成可执行的步骤。

生成之后应重点做两件事：检查元素定位是否写死，检查等待方式是否容易产生随机失败。如果测试网页经常改版，建议让 AI 为关键元素生成>1. 禁止 SELECT *，只允许查询需要的列 2. 大表查询必须有 WHERE 条件或合适的扫描范围 3. WHERE 条件列要尽量匹配索引，避免对索引列做函数运算 4. JOIN 条件避免隐式类型转换 5. 深分页风险：LIMIT offset 过大时建议改游标分页或二次查询 6. UPDATE / DELETE 必须带 WHERE，不允许全表更新 7. 排序字段需要考虑是否与索引一致 8. 插入前应判断是否需要去重，避免重复脏数据 9. 关联表数量过多时建议人工走执行计划确认 10. 对未确定大表行数时，COUNT(*) 和 COUNT(列名) 含义不同，要结合业务确认

这份规则必须放到 Skill 目录里的rules/sql_static_rules.md。放进规则库的前提是“静态可推断”，如果某条规则需要真实执行计划才能判断，就写成“提示需要执行计划验证”，而不是让 AI 假装判断。

4.2 设计 Skill 目录与描述卡片

接下来创建一个sql-review目录。描述卡片建议使用 Markdown，因为它便于阅读，也便于大多数 AI 工具理解。参考结构如下：

sql-review/ ├── SKILL.md ├── rules/ │ └── sql_static_rules.md ├── templates/ │ ├── input_prompt.md │ └── output_report.md └── examples/ ├── high_risk.sql └── ok.sql

SKILL.md的简化内容可以是：

--- 名称: sql-review 用途: 对 SQL 做静态质量检测，输出风险清单与修复建议 输入: - 待检测 SQL 或 SQL 文件目录 - 相关表结构 DDL（可选，最好提供） 数据库: MySQL / PostgreSQL / 其他（按实际环境写） 输出: - 风险等级 - 命中规则 - 修复建议 - 重写后的示例 SQL（可选） 不适用: - 不做真实性能基准测试 - 不连接生产库执行 --- 按 rules/sql_static_rules.md 中的规则逐条检查。 输出格式按 templates/output_report.md 执行。

这段内容不是官方规范，更像一个通用说明卡片。不同 AI 工具的 Skill 机制字段不同，实际路径和字段名要按官方文档调整，但“任务边界 + 输入输出 + 规则引用”的思路是通用的。

4.3 写一个可复用的输入模板

输入模板解决的核心问题是格式不统一。建议固定为“三段式”：数据库类型 + 表结构 DDL + 待检测 SQL。示例 prompt：

你是 SQL 审查员。现在有一批新增或修改的 SQL 需要做静态质量检测。 请先读取 rules/sql_static_rules.md 中的规则，再逐条检查下面的 SQL。 数据库类型：MySQL 8.0 表结构 DDL： {粘贴 DDL} 待检测 SQL： {粘贴 SQL} 输出要求： 1. 先写风险等级：高 / 中 / 低 / 提示 2. 再写命中的规则编号和具体原因 3. 给出可执行的修复建议 4. 如果修复后的 SQL 会改变结果语义，务必说明

把这段内容存成templates/input_prompt.md。每次调用 Skill 时只替换大括号里的内容，避免临时组织语言导致漏信息。

4.4 用高风险 SQL 做验证

Skill 是否有效，要用真实案例验证。下面是一条适合做反例的 SQL：

SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id LEFT JOIN products p ON o.product_code = p.code WHERE o.created_at BETWEEN '2025-01-01' AND '2025-03-01' ORDER BY o.created_at DESC LIMIT 0, 5000;

如果让这个 Skill 检查，应该能发现几个明显问题：SELECT *；订单和用户、商品多表关联但缺少 where 过滤用户维度的条件；深分页偏移量 5000；是否缺索引，取决于 DDL，但在无 DDL 情况下 AI 应输出“提示需要人工确认索引”而不是强行断言。

AI 给出的修复建议可能是：

SELECT o.order_id, o.order_no, o.user_id, u.name AS user_name, p.name AS product_name FROM orders o LEFT JOIN users u ON o.user_id = u.id LEFT JOIN products p ON o.product_code = p.code WHERE o.created_at >= '2025-01-01' AND o.created_at < '2025-04-01' ORDER BY o.created_at DESC LIMIT 5000 OFFSET 0;

注意这不是标准模板，MySQL 各版本对LIMIT offset, rows和LIMIT rows OFFSET offset的写法略有差异，最终以目标库版本为准。Skill 的价值是输出“减少 SELECT *，改为明确字段列表；深分页改为游标或二次查询”这类可执行建议，而不是直接替你在生产库执行。

4.5 怎么判断这个 Skill 是否成功

判断标准不是“AI 说了一堆规则”，而是三个条件：

1. 对单条 SQL，AI 能不遗漏地命中已定义规则。
2. 对没有表结构 DDL 的情况，AI 能主动降低置信度，而不是乱猜。
3. 输出报告的格式稳定，可以作为后续批量报告的同一模板。

如果第一遍验证不通过，通常原因是：规则文件写得太抽象、没有给正反示例、输入模板里没有说明数据库类型。修规则或补充示例后重跑，不要靠现场改 prompt 来迁就。

5. 批量任务与 API 接口接入

单条测试跑通后，下一步是批量。如果把几十条 SQL 手动复制到网页对话框，每执行一次都要等待、复制结果，体验很差。更稳妥的方式是让脚本读取目录中的 SQL 文件，逐条调用模型 API 或命令行接口，把结果写进固定目录。

批量处理前一定要确认：你使用的是自己的模型服务 API，且接口 URL、密钥等环境变量不要写死在脚本里。下面给一套通用 Python 批量调用模板，结构可以复用到大部分 OpenAI-compatible 接口。

import os import json import time from pathlib import Path import requests API_URL = os.getenv("AI_API_URL", "https://your-gateway.example.com/v1/chat/completions") API_KEY = os.getenv("AI_API_KEY", "") HEADERS = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } def load_rules(rule_path: str) -> str: return Path(rule_path).read_text(encoding="utf-8") def check_one_sql(sql_path: Path, ddl_path: Path, rule_text: str) -> dict: sql_text = sql_path.read_text(encoding="utf-8") ddl_text = ddl_path.read_text(encoding="utf-8") if ddl_path.exists() else "" user_content = ( f"数据库类型：MySQL 8.0\n\n" f"相关表结构 DDL：\n{ddl_text}\n\n" f"待检测 SQL：\n{sql_text}\n\n" f"请按规则文件输出检测报告，并给出风险等级和修复建议。" ) payload = { "model": os.getenv("AI_MODEL", "your-model-name"), "messages": [ { "role": "system", "content": "你是 SQL 静态审查员，输出必须按规则文件执行。", }, {"role": "user", "content": user_content}, ], "temperature": 0.2, } for attempt in range(3): try: resp = requests.post(API_URL, headers=HEADERS, json=payload, timeout=180) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] return {"file": sql_path.name, "status": "ok", "report": content} except Exception as exc: if attempt == 2: return {"file": sql_path.name, "status": "error", "message": str(exc)} time.sleep(5 * (attempt + 1))

def batch_check(input_dir: Path, output_dir: Path, rule_path: str) -> None: output_dir.mkdir(parents=True, exist_ok=True) rule_text = load_rules(rule_path) for sql_path in input_dir.glob("*.sql"): ddl_path = sql_path.with_suffix(".ddl.sql") # 同目录下的 DDL 文件按命名约定匹配 result = check_one_sql(sql_path, ddl_path, rule_text) out_file = output_dir / f"{sql_path.stem}_report.json" out_file.write_text(json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8") print(f"processed: {sql_path.name}, status: {result['status']}") if __name__ == "__main__": batch_check( input_dir=Path("./sql_case"), output_dir=Path("./output"), rule_path="./rules/sql_static_rules.md", )

这段脚本有几个工程点值得学习。第一，它把失败任务记录成 JSON，而不是让异常中断全部任务。第二，采用同目录下.ddl.sql的命名约定来匹配表结构。第三，设置了超时和重试，降低偶发网络波动的影响。

批量任务建议先跑 3 条实验，确认输出格式稳定后再跑全量。输出目录里放 JSON 可以方便后续 diff，因为回归测试最怕“这次报告和上次报告不一致，但没人知道是哪条规则变了”。

接口接入还有一个关键点：不要把批量任务直接连到生产数据库执行。如果 SQL 文件本身来自生产库提取，仍然有数据泄露风险。安全做法是只上传经过脱敏或模拟的表结构和 SQL 模板，连接串只出现在受保护的测试环境脚本中。

6. 资源占用与性能观察方法

这类“测试提效 Skill”和图像模型部署不同，不需要关注显存，但还是要观察几个指标，否则批量跑到一半会卡死或成本失控。

最直接的费用指标是 token 消耗。一条很长、带大量 DDL 的 SQL 可能消耗几千 token，批量几十条就是几十万 token，这对 API 调用成本影响很大。建议观察每次请求返回的usage字段，看prompt_tokens和completion_tokens各占多少。如果 DDL 太长，可以只保留相关表的建表语句，不要每次把整个库结构都塞进去。

响应时间方面，网页版对话通常以秒到十秒计，API 接口可能更稳定。批量脚本里要记录每个文件的开始时间、结束时间、成功或失败原因。如果单个请求超过 180 秒，通常不是模型慢，而是上传内容过大或接口限流，要拆分输入。

内存占用和磁盘占用通常不会成为瓶颈。普通办公电脑跑一个批量请求脚本，主要的资源消耗在进程和日志记录。建议先规划好输出目录大小，因为大量 JSON 报告虽然单个很小，但累积多了会占空间，而且不便于搜索。按日期建目录是一种不错的选择。

更加务实的观察方式是把“单条处理耗时”“平均耗时”“失败重试次数”输出成表格。这样你能判断到底是模型服务慢了，还是规则文件太长导致每轮请求都在反复加载。

7. 常见问题与排查方法

下面是这套玩法里最常见的 8 类问题，按实际排查顺序整理成表。

如果遇到“报告结果忽好忽坏”，尤其要检查规则库和输入模板是不是被聊天上下文覆盖了。Skill 的意义就在于所有内容都从固定文件读取，避免这次用的规则和上次不一样。人工在对话里补充临时意见也要谨慎，因为那份补充内容可能不会被记录到规则库里。

SQL 类任务还有一个隐性坑：AI 输出“建议增加索引”时，并没有建索引的能力，也不会告诉你建索引后对写入性能的影响。测试人员要把这些建议当成探索线索，不要直接在生产库执行。最稳妥的验证方式是拿到测试库执行EXPLAIN，观察实际执行计划。

8. 最佳实践：从“能用 AI 写脚本”到“把测试动作自动化”

不是所有测试任务都需要做成 Skill，也不是做出来的 Skill 都要立刻推广。我的建议是先挑一个最高频