api-test-optimizer
Skill0 starsChanged 5 months agoMITView on GitHub
接口自动化脚本质量检查与优化增强技能。对AI生成的原始接口自动化脚本做自动化检查、问题诊断、规范对齐、缺陷修复与代码优化、场景补齐,确保脚本语法合法、规范统一、逻辑完整、场景全覆盖。支持4类校验(语法/规范/健壮性/逻辑)+10维度场景补齐(正向/必填校验/参数合法性/边界值/异常处理/业务规则/安全风险/接口依赖/兼容性/断言完整性),输出脚本校验报告+优化后可执行脚本。
- Installs packages
In this repository19 other files it gives its agents.
- api-failure-diagnoserSkill
- api-pipeline-schedulerSkill
- api-report-generatorSkill
- api-schema-parserSkill
- api-testdata-cleanerSkill
- api-testdata-generatorSkill
- api-test-executorSkill
- api-testscript-generatorSkill
- api-test-taggerSkill
- generator-testcase-excelSkill
- generator-testcase-xmindSkill
- req-to-user-storySkill
- review-testcaseSkill
- review-user-storiesSkill
- safe-testcaseSkill
- ui-page-parserSkill
- ui-testscript-enhancerSkill
- ui-testscript-generatorSkill
- ui-visual-assertSkill
The file
Files
API Test Optimizer - 接口自动化脚本质量检查与优化增强
概述
本技能扮演接口自动化测试架构师 + 资深质量工程师角色,核心能力是对 AI 生成的原始接口自动化脚本做 自动化检查、问题诊断、规范对齐、缺陷修复与代码优化、场景补齐,确保脚本 语法合法、规范统一、逻辑完整、场景全覆盖。
核心流程:
输入目录(接口测试脚本工程)
↓
Step 1: 扫描与解析脚本结构
↓
Step 2: 语法校验(语法错误 / 依赖缺失 / 变量未定义)
↓
Step 3: 规范校验(命名规则 / 注释完整性 / 目录结构)
↓
Step 4: 健壮性校验(等待机制 / 异常捕获 / 鉴权逻辑)
↓
Step 5: 逻辑校验(断言覆盖 / 接口依赖 / 业务规则)
↓
Step 6: 自动优化(修复错误 / 补充缺失 / 精简冗余)
↓
Step 7: 10维度场景补齐(全面检查遗漏场景)
↓
Step 8: 输出校验报告 + 优化后可执行脚本6大检查优化逻辑 + 10维度场景补齐:
| 能力 | 说明 |
| 1. 语法校验 | 检查代码语法错误、依赖缺失、变量未定义 |
| 2. 规范校验 | 检查命名规则、注释完整性、目录结构是否符合团队要求 |
| 3. 健壮性校验 | 检查是否缺失等待机制、异常捕获、鉴权逻辑 |
| 4. 逻辑校验 | 检查断言是否覆盖核心业务规则、接口依赖是否处理 |
| 5. 自动优化 | 修复语法错误、补充缺失的注释/异常处理、精简冗余代码 |
| 6. 场景补齐 | 从10个维度全面检查,确保接口测试场景全覆盖 |
10维度场景补齐体系:
| 序号 | 维度 | 说明 |
| D1 | 正向场景 | 核心业务流程是否全部覆盖 |
| D2 | 必填校验 | 每个必填参数是否有空值/缺失用例 |
| D3 | 参数合法性 | 类型、格式、长度、枚举值合法性校验 |
| D4 | 边界值 | 边界内/外值、极值、空值/null |
| D5 | 异常处理 | 网络异常、服务异常、数据异常、并发异常 |
| D6 | 业务规则 | 业务互斥、状态约束、权限控制 |
| D7 | 安全风险 | SQL注入、XSS、越权、敏感数据 |
| D8 | 接口依赖 | 前置接口失败、依赖数据缺失、顺序异常 |
| D9 | 兼容性 | 不同版本、编码、Content-Type |
| D10 | 断言完整性 | 状态码+业务码+业务数据三层断言 |
触发条件
以下场景自动触发本技能:
- 用户提供接口自动化测试脚本目录,要求"检查脚本质量""优化测试脚本""脚本代码审查"
- 用户要求"修复接口脚本问题""补全测试场景""优化接口自动化代码"
- 用户要求"对AI生成的脚本做质量检查""脚本规范校验""场景覆盖率检查"
- 用户提及"api-test-optimizer""/api_test_optimizer"
- 用户提供了
api-testscript-generator的输出目录,要求进一步检查和优化 - 用户要求"接口脚本场景补齐""接口测试遗漏检查"
输入
必需输入
- 接口测试脚本目录:包含接口自动化测试脚本的项目根目录
- 典型结构为
api-testscript-generator输出的工程:api_auto_project/ ├── config/ ├── api/ ├── testcases/ ├── data/ ├── utils/ ├── conftest.py └── pytest.ini - 也支持其他 Python + Pytest 风格的接口自动化项目
- 典型结构为
可选输入
- 接口定义文件:
api_definitions.json/yaml(如有,用于场景补齐时校验参数覆盖) - PRD/需求文档:用于校验业务规则覆盖度
- 目标模块/接口筛选(选填):仅检查优化指定模块或接口的脚本
- 自定义输出路径(选填):指定优化后脚本的输出目录,默认在原目录同级生成
api_auto_project_optimized/
执行流程
Step 1: 扫描与解析脚本结构
- 递归扫描输入目录,识别脚本工程结构
- 解析各层文件:
config/:环境配置、全局常量api/:接口请求层封装testcases/:测试用例层data/:测试数据文件utils/:工具类conftest.py:全局钩子pytest.ini:Pytest 配置
- 提取每个接口的脚本信息:API封装方法、测试用例类、断言内容、数据文件
- 构建 接口→脚本映射表,记录每个接口对应的文件路径、类名、方法列表
扫描输出:
========================================
脚本结构扫描结果
========================================
项目路径:api_auto_project/
脚本文件总数:32
- config/ 3 文件
- api/ 15 文件
- testcases/ 15 文件
- data/ 15 文件
- utils/ 4 文件
- 其他 2 文件(conftest.py + pytest.ini)
接口覆盖:
- 已覆盖接口:15
- 缺少API封装:0
- 缺少测试用例:0
- 缺少数据文件:0(内联数据模式)
========================================Step 2: 语法校验
对每个 .py 文件执行语法校验,检查项目参考 references/check-rules.md 中的「语法校验」部分:
| 检查项 | 检查方式 | 严重级别 |
| Python 语法错误 | compile() 编译检查 | 🔴 致命 |
| 缩进错误 | AST 解析检查 | 🔴 致命 |
| 导入缺失 | 分析 import 语句与项目结构 | 🟡 警告 |
| 变量未定义 | 静态分析引用链 | 🟡 警告 |
| 函数签名不匹配 | 参数传递分析 | 🟡 警告 |
| 类型不兼容 | 类型注解检查 | 🔵 建议 |
| 依赖包未声明 | 与 requirements.txt 比对 | 🟡 警告 |
语法校验结果格式:
文件:api/user_api.py
🔴 L42: SyntaxError: invalid syntax(缺少冒号)
🟡 L15: ImportWarning: 'utils.logger' 未在 utils/__init__.py 中导出
🔵 L28: TypeHint: 参数 'user_id' 缺少类型注解
文件:testcases/test_user_login.py
🟡 L35: NameError: 变量 'auth_headers' 可能未定义(缺少 fixture 注入)
✅ 无语法错误Step 3: 规范校验
按照团队编码规范逐文件检查,检查项目参考 references/check-rules.md 中的「规范校验」部分:
| 检查项 | 规范要求 | 严重级别 |
| 文件命名 | 小写字母+下划线,一个接口一个文件 | 🟡 警告 |
| 类名规范 | 大驼峰命名法 | 🟡 警告 |
| 方法名规范 | 小写字母+下划线 | 🟡 警告 |
| 测试方法前缀 | 必须以 test_ 开头 | 🔴 致命 |
| 模块注释 | 每个文件必须有模块级 docstring | 🟡 警告 |
| 方法注释 | 每个公开方法必须有 docstring | 🔵 建议 |
| 硬编码检查 | URL/超时/重试次数不应硬编码 | 🟡 警告 |
| 分层检查 | 接口封装在 api/,用例在 testcases/,工具在 utils/ | 🔴 致命 |
| 常量命名 | 全大写+下划线 | 🟡 警告 |
| 目录结构 | 符合团队分层架构 | 🟡 警告 |
规范校验结果格式:
文件:api/user_api.py
🟡 类名 'userAPI' 不符合大驼峰命名法,应为 'UserAPI'
🟡 方法 'Login' 不符合小写+下划线命名法,应为 'login'
🟡 缺少模块级 docstring
🟡 L45: URL 硬编码 'https://api.example.com/users',应使用 config.BASE_URL
文件:testcases/test_user_login.py
✅ 命名规范全部通过
🟡 缺少 @allure.feature 装饰器
🟡 缺少 @allure.story 装饰器Step 4: 健壮性校验
检查脚本是否具备企业级健壮能力,检查项目参考 references/check-rules.md 中的「健壮性校验」部分:
| 检查项 | 检查内容 | 严重级别 |
| 超时配置 | 请求是否有统一超时设置 | 🟡 警告 |
| 重试机制 | 请求是否有自动重试逻辑 | 🟡 警告 |
| 异常捕获 | 是否捕获网络异常(超时/连接/代理) | 🔴 致命 |
| 鉴权逻辑 | 需要鉴权的接口是否自动注入 Token | 🟡 警告 |
| Token 刷新 | 是否有 Token 过期自动刷新机制 | 🟡 警告 |
| 日志记录 | 关键操作是否有日志记录 | 🔵 建议 |
| 环境隔离 | 是否支持多环境切换 | 🔵 建议 |
| 失败重跑 | 是否配置 pytest-rerunfailures | 🔵 建议 |
| 数据清理 | 测试前后是否有数据清理/回滚机制 | 🟡 警告 |
| 并发安全 | 共享资源是否有并发保护 | 🟡 警告 |
健壮性校验结果格式:
文件:api/user_api.py
🟡 请求方法缺少超时配置(未使用统一 RequestUtil)
🟡 缺少异常捕获(直接调用 requests.post 无 try/except)
🟡 未使用 TokenUtil 注入鉴权 Headers
✅ 有日志记录
文件:utils/request_util.py
✅ 超时统一配置
✅ 重试机制完善
✅ 异常捕获覆盖 5 类异常
✅ 日志记录完整Step 5: 逻辑校验
检查断言逻辑和业务规则覆盖,检查项目参考 references/check-rules.md 中的「逻辑校验」部分:
| 检查项 | 检查内容 | 严重级别 |
| 三层断言 | 是否包含状态码+业务码+业务数据断言 | 🔴 致命 |
| 断言有效性 | 是否存在无效断言(assert True / assert 1==1) | 🔴 致命 |
| 业务码断言 | 是否断言业务状态码 | 🟡 警告 |
| 业务数据断言 | 是否断言关键字段值 | 🟡 警告 |
| 接口依赖 | 前置接口数据是否正确传递 | 🟡 警告 |
| 业务规则 | 是否覆盖接口定义中的 business_rules | 🟡 警告 |
| 参数完整性 | API封装是否覆盖所有参数 | 🟡 警告 |
| 路径参数替换 | 路径参数是否正确替换 | 🔴 致命 |
| 响应结构校验 | 是否校验响应结构是否符合定义 | 🔵 建议 |
| 幂等性处理 | 幂等接口是否有重试保护 | 🔵 建议 |
逻辑校验结果格式:
文件:testcases/test_user_login.py
🔴 缺少业务码断言(仅断言 status_code)
🟡 缺少业务数据断言(未验证 data.token 非空)
✅ 无无效断言
🟡 接口依赖:登录接口返回的 token 未在后续用例中复用
文件:api/order_api.py
🔴 路径参数 '{order_id}' 未在请求前替换
🟡 缺少参数 'coupon_id' 的传递(接口定义中存在该参数)
✅ 三层断言覆盖完整Step 6: 自动优化
根据 Step 2-5 的校验结果,自动执行以下优化操作:
6.1 语法修复
| 问题 | 自动优化策略 |
| 语法错误 | 修复缩进、补全冒号、修正括号匹配 |
| 导入缺失 | 根据引用分析自动补充 import 语句 |
| 变量未定义 | 分析上下文补充变量定义或参数传递 |
| 函数签名不匹配 | 修正参数列表使其与定义一致 |
6.2 规范对齐
| 问题 | 自动优化策略 |
| 命名不规范 | 自动重命名(类名大驼峰、方法名小写+下划线、常量全大写) |
| 缺少注释 | 自动生成模块 docstring 和方法 docstring |
| 硬编码 | 提取硬编码值为配置常量 |
| 缺少 Allure 标记 | 自动补充 @allure.feature / @allure.story |
| 分层违规 | 将混层的代码迁移到正确层 |
6.3 健壮性增强
| 问题 | 自动优化策略 |
| 缺少异常捕获 | 注入统一异常捕获(超时/连接/代理/JSON解析) |
| 缺少超时配置 | 注入统一超时常量引用 |
| 缺少鉴权 | 注入 TokenUtil.get_headers() |
| 缺少日志 | 注入 logger 调用 |
| 缺少重试 | 引用统一 RequestUtil(已内置重试) |
6.4 逻辑修复
| 问题 | 自动优化策略 |
| 缺少三层断言 | 补充业务码断言和业务数据断言 |
| 无效断言 | 替换为有效的三层断言 |
| 路径参数未替换 | 注入 str.format() 或 replace() 替换逻辑 |
| 参数遗漏 | 根据接口定义补充缺失参数 |
| 接口依赖未处理 | 注入 fixture 传递或 conftest 依赖管理 |
6.5 代码精简
| 问题 | 自动优化策略 |
| 重复代码 | 提取公共方法到 utils/ |
| 冗余断言 | 合并重复断言,保持三层即可 |
| 过长方法 | 拆分为多个独立测试方法 |
| 魔法数字 | 提取为命名常量 |
| 死代码 | 删除未引用的变量和方法 |
Step 7: 10维度场景补齐
对每个接口的测试用例进行10维度遗漏场景检查,检查项参考 references/scenario-checklist.md:
D1 - 正向场景
- 核心业务流程是否覆盖
- 多种合法输入组合是否覆盖
- 不同用户角色/权限下的正常流程
D2 - 必填校验
- 每个必填参数是否有空值用例
- 必填参数缺失时是否返回正确错误码
- 多个必填参数组合缺失的场景
D3 - 参数合法性
- 类型不匹配(字符串传数字、数字传字符串)
- 格式不合法(邮箱格式、手机号格式、日期格式)
- 长度超限(超长字符串、极短输入)
- 枚举值不合法(不在枚举范围内的值)
D4 - 边界值
- 边界内最小值、最大值
- 边界外值(最小值-1、最大值+1)
- 空字符串、null/None
- 零值、负值
D5 - 异常处理
- 网络超时/连接异常
- 服务端 500/502/503 错误
- 数据不存在/已删除
- 并发请求冲突
D6 - 业务规则
- 业务互斥条件(如优惠不可叠加)
- 状态约束(如已取消订单不可支付)
- 权限控制(普通用户不可访问管理接口)
- 数据一致性(扣款金额=订单金额)
D7 - 安全风险
- SQL注入(如
' OR 1=1 --) - XSS攻击(如
<script>alert(1)</script>) - 越权访问(无Token/他人Token)
- 敏感数据明文传输
- 批量数据遍历
D8 - 接口依赖
- 前置接口失败时的降级处理
- 依赖数据不存在时的处理
- 接口调用顺序异常
- 依赖接口返回数据格式变化
D9 - 兼容性
- 不同 API 版本兼容
- 不同 Content-Type(JSON/Form/Data)
- 不同编码(UTF-8/GBK)
- 分页参数不同组合
D10 - 断言完整性
- 是否有三层断言(状态码+业务码+业务数据)
- 业务数据断言是否覆盖关键字段
- 错误响应是否有完整断言
- 断言信息是否包含实际值便于排查
场景补齐输出:
对每个接口,生成遗漏场景的测试用例代码,按维度分类追加到对应测试文件:
# ===== [优化器补齐] D2-必填校验 =====
@pytest.mark.p0
@allure.title("用户登录 - 用户名为空")
@allure.feature("认证管理")
@allure.story("必填校验")
def test_login_username_empty(self, request_util, auth_headers):
"""测试必填参数用户名为空"""
api = UserAPI(request_util)
response = api.login(username="", password="Test@1234", headers=auth_headers)
AssertUtil.assert_status_code(response, 400)
AssertUtil.assert_business_code(response, 40001)Step 8: 输出校验报告与优化脚本
8A: 脚本校验报告
生成 Markdown 格式的校验报告,包含以下内容:
# 接口自动化脚本校验报告
## 一、总体概况
- 项目路径:api_auto_project/
- 脚本文件总数:XX
- 接口覆盖数:XX
- 问题总数:XX(🔴 致命 XX / 🟡 警告 XX / 🔵 建议 XX)
## 二、校验结果汇总
### 2.1 语法校验
| 严重级别 | 数量 | 占比 |
|---------|------|------|
| 🔴 致命 | XX | XX% |
| 🟡 警告 | XX | XX% |
| 🔵 建议 | XX | XX% |
### 2.2 规范校验
(同上格式)
### 2.3 健壮性校验
(同上格式)
### 2.4 逻辑校验
(同上格式)
## 三、逐文件问题清单
### api/user_api.py
| 行号 | 级别 | 类别 | 问题描述 | 修复方式 | 状态 |
|------|------|------|---------|---------|------|
| L42 | 🔴 | 语法 | 缺少冒号 | 已自动修复 | ✅ |
| L15 | 🟡 | 规范 | 类名不符合大驼峰 | 已自动修复 | ✅ |
| L28 | 🟡 | 健壮 | 缺少异常捕获 | 已注入 try/except | ✅ |
| L56 | 🔴 | 逻辑 | 缺少业务码断言 | 已补充断言 | ✅ |
### testcases/test_user_login.py
(同上格式)
## 四、10维度场景补齐统计
| 维度 | 原有用例数 | 补齐用例数 | 补齐率 | 优先级分布 |
|------|-----------|-----------|--------|-----------|
| D1 正向场景 | 5 | 2 | +40% | P0:1 P1:1 |
| D2 必填校验 | 1 | 3 | +300% | P0:2 P1:1 |
| D3 参数合法性 | 0 | 4 | 新增 | P0:1 P1:2 P2:1 |
| D4 边界值 | 1 | 3 | +300% | P0:1 P1:2 |
| D5 异常处理 | 2 | 2 | +100% | P0:1 P1:1 |
| D6 业务规则 | 1 | 3 | +300% | P0:2 P1:1 |
| D7 安全风险 | 0 | 3 | 新增 | P0:1 P1:2 |
| D8 接口依赖 | 0 | 2 | 新增 | P0:1 P1:1 |
| D9 兼容性 | 0 | 1 | 新增 | P2:1 |
| D10 断言完整性 | 3 | 1 | +33% | P0:1 |
| **合计** | **13** | **24** | **+185%** | **P0:11 P1:12 P2:2** |
## 五、优化操作汇总
| 优化类型 | 操作数 | 详情 |
|---------|--------|------|
| 语法修复 | XX | 修复缩进错误X处、补全冒号X处... |
| 规范对齐 | XX | 重命名类X个、补充注释X处... |
| 健壮性增强 | XX | 注入异常捕获X处、注入鉴权X处... |
| 逻辑修复 | XX | 补充断言X处、修复路径参数X处... |
| 代码精简 | XX | 提取公共方法X个、删除死代码X处... |
| 场景补齐 | XX | 新增用例方法XX个... |
## 六、优化前后对比
| 指标 | 优化前 | 优化后 | 变化 |
|------|--------|--------|------|
| 语法错误数 | XX | 0 | -100% |
| 规范违规数 | XX | 0 | -100% |
| 健壮性缺失 | XX | 0 | -100% |
| 断言完整性 | XX% | 100% | +XX% |
| 测试用例总数 | XX | XX | +XX% |
| 场景覆盖维度 | XX/10 | 10/10 | +XX |
## 七、运行验证建议
1. 执行 `pip install -r requirements.txt` 安装依赖
2. 执行 `pytest testcases/ -v --alluredir=reports/allure-results` 运行全量用例
3. 执行 `pytest testcases/ -m p0 -v` 运行 P0 优先级用例
4. 对比优化前后的 Allure 报告,确认新增用例全部通过8B: 优化后脚本
在输出目录生成完整的优化后脚本工程:
api_auto_project_optimized/
├── config/ # 优化后的环境配置
├── api/ # 优化后的接口封装
├── testcases/ # 优化后的测试用例(含补齐场景)
├── data/ # 优化后的测试数据
├── utils/ # 优化后的工具类
├── conftest.py # 优化后的全局钩子
├── pytest.ini # 优化后的 Pytest 配置
├── requirements.txt # 优化后的依赖清单
└── 校验报告.md # 脚本校验报告优化标识规范:
在优化后的脚本中,对自动修改和补齐的内容添加标识注释:
| 标识 | 说明 | 示例 |
# [优化器修复] | 自动修复的代码 | # [优化器修复] 补充异常捕获 |
# [优化器补齐] | 自动补齐的用例 | # [优化器补齐] D2-必填校验 |
# [优化器重构] | 自动重构的代码 | # [优化器重构] 提取公共方法 |
# [优化器对齐] | 规范对齐修改 | # [优化器对齐] 类名大驼峰 |
输入模式
模式一:目录模式(默认)
用户直接提供脚本目录路径,自动扫描并检查优化全部脚本。
# 检查优化整个项目
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/
# 指定输出路径
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --output /path/to/optimized/
# 仅检查不优化(只输出报告)
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --check-only
# 仅执行指定类型的校验
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --checks syntax,standard
# 仅对指定模块的脚本进行优化
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --module "认证管理"
# 仅对指定接口的脚本进行优化
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --api "POST_/api/auth/login"
# 结合接口定义文件进行场景补齐
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --api-def /path/to/api_definitions.json
# 跳过场景补齐(仅做检查和修复)
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --skip-scenario
# 指定检查的严重级别阈值
python3 <skill_path>/scripts/script_optimizer.py /path/to/api_auto_project/ --severity warning模式二:单文件模式
用户提供单个脚本文件,仅检查优化该文件。
python3 <skill_path>/scripts/script_optimizer.py /path/to/test_user_login.py --single-file校验严重级别与处理策略
| 级别 | 图标 | 处理策略 |
| 致命 | 🔴 | 必须修复,脚本无法运行或结果不可信,自动修复 |
| 警告 | 🟡 | 建议修复,影响可维护性或可靠性,自动修复 |
| 建议 | 🔵 | 可选优化,提升代码质量,自动优化 |
与其他技能的协作
api-schema-parser ──→ 标准化接口数据 (api_definitions.json)
│
├──→ api-testdata-generator ──→ 测试数据文件 (data/)
│
└──→ api-testscript-generator ──→ 接口自动化脚本工程
│ (api/ + testcases/ + data/ + utils/ + config/)
│
└──→ api-test-optimizer ──→ 脚本校验报告 + 优化后可执行脚本
│
└──→ 可直接运行:pytest testcases/建议使用流程:
- 使用
api-schema-parser将接口文档标准化为api_definitions.json - 使用
api-testdata-generator生成全场景测试数据(可选) - 使用
api-testscript-generator生成接口自动化脚本工程 - 使用本技能
api-test-optimizer对生成的脚本做质量检查、修复优化、场景补齐 - 配置环境地址和账号后直接运行优化后的脚本
pytest testcases/
与 review-testcase 的关系:
review-testcase:评审测试用例的质量(Excel/XMind 格式)api-test-optimizer:检查优化接口自动化脚本的质量(Python 代码)- 两者作用于不同阶段:先设计用例 → 评审用例质量 → 生成脚本 → 优化脚本质量
注意事项
- 非破坏性优化:优化操作在输出目录生成新文件,不修改原始脚本
- 标识可追溯:所有自动修改和补齐的内容添加
[优化器XXX]标识注释,便于 Code Review - 三层断言底线:每个测试方法至少包含状态码+业务码+业务数据三层断言
- 场景补齐优先级:P0 为必补场景(安全/数据风险),P1 为重要场景(边界/异常),P2 为建议场景(兼容/性能)
- 接口覆盖完整性:
api_definitions.json中定义的每个接口都应有对应的 API 封装和测试用例 - 参数覆盖完整性:每个接口的所有参数都应在 API 封装方法中体现
- 运行验证:优化后的脚本应可直接运行(需先配置环境地址和账号)
- UTF-8 编码:所有文件使用 UTF-8 编码
- 增量优化:支持对已有项目做增量优化,不覆盖已有修改
Resources
scripts/script_optimizer.py
Python 脚本,核心脚本优化引擎,支持:
- 递归扫描项目目录,解析脚本结构
- 4 类校验(语法/规范/健壮性/逻辑)逐文件检查
- 10 维度场景遗漏分析
- 自动修复语法错误、规范对齐、健壮性增强、逻辑修复
- 代码精简(提取公共方法、删除死代码、消除重复)
- 生成 Markdown 格式校验报告
- 输出优化后的完整脚本工程
- CLI 用法:
- 基本用法:
python3 script_optimizer.py <project_dir> [--output <dir>] [--check-only] [--checks <types>] [--module <name>] [--api <api_id>] [--api-def <file>] [--skip-scenario] [--severity <level>] [--single-file]
- 基本用法:
references/check-rules.md
4 类校验的详细规则参考文档,包含:
- 语法校验规则:语法错误、缩进错误、导入缺失、变量未定义、函数签名不匹配等
- 规范校验规则:命名规则、注释完整性、目录结构、分层检查、硬编码禁止等
- 健壮性校验规则:超时配置、重试机制、异常捕获、鉴权逻辑、Token 刷新等
- 逻辑校验规则:三层断言、断言有效性、接口依赖、业务规则、参数完整性等
references/scenario-checklist.md
10 维度场景补齐的详细检查清单,包含:
- 每个维度的具体检查项
- 常见遗漏场景示例
- 补齐用例的代码模板
- 优先级评定规则
references/optimization-patterns.md
自动优化策略和代码修复模式参考文档,包含:
- 语法修复模式
- 规范对齐模式
- 健壮性增强模式
- 逻辑修复模式
- 代码精简模式
- 场景补齐模板
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

