| name | api-test-executor |
| description | 接口自动化测试智能执行调度引擎。当用户需要触发执行 pytest 接口测试、按范围/模块/标签筛选测试用例、用自然语言描述执行意图、收集结构化测试结果时使用此技能。支持三种筛选模式（标签索引/文件路径/自然语言），输出标准化 JSON 和 Markdown 执行报告。典型触发：跑一下冒烟测试、执行登录模块的P0用例、在test环境跑回归、模拟执行看看有哪些用例。 |
| agent_created | true |
api-test-executor — 接口测试执行调度引擎
概述
接口自动化测试的智能执行调度引擎，核心定位是"测试执行闭环的发动机"。聚焦三大基础能力：触发执行、范围筛选、结果收集，同时支持用户通过自然语言智能选择执行范围。
只做三件事：
- 触发执行：一键触发 pytest，自动加载环境配置、测试数据
- 范围筛选：标签索引 + 文件路径 + 自然语言三模式，精准圈定执行范围
- 结果收集：结构化采集每条用例执行状态、耗时、错误信息，输出 JSON 和 Markdown
明确不做： 环境深度巡检、分布式调度、实时监控告警、失败根因分析（交给下游 api-failure-diagnoser）。
触发条件
当用户表述包含以下意图时触发：
- "跑一下XX测试" / "执行XX用例" / "运行测试"
- "在XX环境跑" / "冒烟测试" / "回归测试"
- "只跑登录模块" / "执行P0用例" / "跑正向场景"
- "模拟执行" / "预览用例" / "看看有哪些用例"
- 提供项目目录路径并要求执行测试
工作流
Step 1: 确认执行参数
若用户以自然语言描述执行意图，先解析为结构化参数，再向用户确认。
解析规则详见 references/nlp_mapping.md。
确认格式示例：
将执行：test 环境，冒烟测试，登录模块，P0 优先级，4 线程并发，确认吗？
若用户已提供明确参数（CLI 形式），跳过此步。
Step 2: 基础环境检查（轻量级）
执行 scripts/test_executor.py，自动完成以下检查：
- 验证
testcases/ 目录存在且含测试文件
- 检查
config/{env}.yaml 环境配置是否存在
- 检查
tag_index.json 标签索引是否存在
- 尝试 HTTP GET 请求 BaseURL（超时 5s，失败不终止，仅 WARNING）
不做深度巡检（数据库/Redis 状态等由用户自行确认）。
Step 3: 执行范围解析
根据项目状态自动选择筛选模式：
模式 A — 标签索引模式（推荐）：
tag_index.json 存在时启用- 根据
--scope、--module、--priority、--tag、--exclude-tag 组合筛选
- 标签结构规范详见
references/tag_index_schema.md
模式 B — pytest marker 模式（常用）：
tag_index.json 不存在，但项目 pytest.ini 中定义了标准化 markers 时启用- 使用
-m "marker_expression" 精确筛选（如 -m "smoke and module_auth"）
- 优先检查项目
conftest.py / pytest.ini 中的 marker 定义
模式 C — 文件路径回退模式：
- 既无
tag_index.json 也无标准化 markers 时启用
- 按
--module 匹配文件名（如 test_auth.py → module:auth）
- 打印 WARNING 提示建议先运行
api-test-tagger
模式 D — 自然语言解析模式：
- 用户输入为自然语言时启用
- 提取关键词映射为 CLI 参数
- 向用户确认解析结果后执行
Step 4: 执行触发
优先直接组装 pytest 命令执行，而非依赖 scripts/test_executor.py 脚本（更灵活、兼容性更好）。
典型执行命令：
API_TEST_ENV={env} python3 -m pytest {testcases_dir} \
-m "{marker_expression}" \
-v \
--timeout={seconds} \
--junitxml={output_dir}/junit.xml \
--alluredir={output_dir}/allure-results \
--html={output_dir}/html-report/report.html \
--self-contained-html \
-p no:xdist \
--tb=short
关键注意事项：
- 使用
-p no:xdist 禁用并发（避免 fixture/session 级别共享问题），除非用例间完全独立
- 项目
pytest.ini 中的 addopts 可能与命令行冲突，需先检查并临时移除（如 --alluredir、--reruns）
-m 表达式根据项目 marker 定义构建（如 "smoke and module_auth"、"P0 or P1"）--output 目录必须指向当前 workspace 内，避免沙箱写入限制- 若项目不在当前 workspace，需先
cp -r 复制到当前 workspace
Step 5: 结果收集与输出
从 junit.xml 解析结构化结果，手动生成以下文件：
1. execution_results.json — 结构化执行结果（供下游 Skill 消费）：
- execution_id、环境、范围、筛选条件
- 每条用例状态(PASS/FAIL/SKIP)、耗时、错误信息
- 总通过率统计
2. execution_summary.md — 执行摘要（供人工浏览）：
- 执行概览表（环境/范围/用例数/通过率/耗时）
- 失败用例清单（用例名/错误类型/错误摘要）
3. pytest 原生报告：
allure-results/：Allure 原始数据html-report/report.html：HTML 测试报告junit.xml：JUnit XML 格式
Step 6: 结果呈现
向用户展示：
- 执行概要统计（总计/通过/失败/跳过/通过率）
- 失败用例清单（如有）
- 报告文件路径
- 后续建议（如"建议运行 api-failure-diagnoser 诊断失败用例"）
前置依赖
- Python 环境：Python 3.8+
- pytest 插件：pytest-xdist、pytest-rerunfailures、pytest-timeout、pytest-html、allure-pytest
- 标签索引（可选）：由
api-test-tagger 生成的 tag_index.json，提升筛选精度
- 项目结构：目标项目须包含
testcases/ 目录
注意事项
- 轻量设计：聚焦"触发 + 筛选 + 收集"，不做环境巡检、分布式调度、实时监控
- 标签依赖：建议先运行
api-test-tagger 生成标准化标签，否则范围筛选精度下降
- 自然语言确认：解析后必须向用户确认，避免误执行
- 重试策略：
--retry 仅对非断言类失败生效（网络超时等），断言失败重试无意义
- 并发安全：确保测试数据隔离（建议上游 Skill 处理）
- Token 传递：登录类用例优先执行，Token 通过 pytest fixture 共享
- 沙箱限制：若项目目录在当前 workspace 之外，managed Python 可能无法写入日志/报告文件，需将项目复制到当前 workspace 或使用
--output 指向当前 workspace
- allure-pytest 兼容性：allure-pytest 2.x 已移除
allure.environment() 方法，若项目 conftest.py 使用了此方法，需改为写入 environment.properties 文件
- pytest.ini addopts 冲突：项目 pytest.ini 中的
addopts 可能与命令行参数冲突（如 --alluredir、--reruns），执行前需检查并临时清理
与上下游 Skill 的关系
- 上游：
api-test-tagger（生成标签索引）→ 本 Skill 使用标签筛选
- 下游：
api-failure-diagnoser（失败根因分析）→ 本 Skill 提供结构化失败数据
