| name | api-test-optimizer |
| description | 接口自动化脚本质量检查与优化增强技能。对AI生成的原始接口自动化脚本做自动化检查、问题诊断、规范对齐、缺陷修复与代码优化、场景补齐,确保脚本语法合法、规范统一、逻辑完整、场景全覆盖。支持4类校验(语法/规范/健壮性/逻辑)+10维度场景补齐(正向/必填校验/参数合法性/边界值/异常处理/业务规则/安全风险/接口依赖/兼容性/断言完整性),输出脚本校验报告+优化后可执行脚本。 |
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_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 - 断言完整性
- 是否有三层断言(状态码+业务码+业务数据)
- 业务数据断言是否覆盖关键字段
- 错误响应是否有完整断言
- 断言信息是否包含实际值便于排查
场景补齐输出:
对每个接口,生成遗漏场景的测试用例代码,按维度分类追加到对应测试文件:
@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
自动优化策略和代码修复模式参考文档,包含:
- 语法修复模式
- 规范对齐模式
- 健壮性增强模式
- 逻辑修复模式
- 代码精简模式
- 场景补齐模板