메뉴
执行已有的框架原生 API spec，并返回明确的通过、失败和归因证据。只要用户已经有 cases.yaml、cases.json、Excel 或 CSV 用例，并且当前主要目标是运行、看 pass/fail、看失败原因、生成 allure-results 或结构化 JSON 结果，都应优先使用这个 skill。当用户说"跑一下""执行测试""看看哪些 case 挂了""直接跑别重写"时务必使用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
TestSpec 需求分析和梳理（流程第 2 步）- 对需求做深度测试分析，运用等价类、边界值、状态迁移等方法，产出 requirements-analysis.md。当用户要「分析需求」「梳理测试点」「做需求分析」「拆解可测项」或执行 testspec-analysis / testspec analysis 时使用。也适用于用户说「这个 PRD 有哪些要测的」「帮我分析一下测试范围」「需求评审准备」的场景。注意：如果用户要的是简短的测试点清单而非深度分析，应使用 testspec-points。
TestSpec 生成测试用例（流程第 4 步）- 根据测试点（specs/*.md）生成完整测试用例并导出 Excel (.xlsx) 或 XMind (.xmind) 格式。当用户要「生成用例」「写测试用例」「导出 Excel」「导出 XMind」「生成测试用例表格」或执行 testspec-generate / testspec generate 时使用。也适用于用户说「把测试点展开成用例」「帮我出一份测试用例表」「生成 Excel 测试文档」的场景。使用内置 Python 脚本完成 Excel/XMind 文件生成，不依赖外部技能。
TestSpec 新建测试工作（流程第 1 步）- 创建测试变更目录，编写 proposal.md，并在用户提供已有 PRD/需求片段时净化成可验收的 requirements.md。当用户要「新建测试」「开始测试」「创建测试变更」「建一个测试项目」或执行 testspec-new / testspec new 时使用。也适用于用户说「我要测 XXX 功能」「帮我准备测试」「有个新需求要测」「帮我整理/审查 PRD」的场景——如果尚无 testspec/changes/ 目录，这是流程的起点。产出 testspec/changes/<name>/ 目录结构、proposal.md，必要时产出 requirements.md。
TestSpec 测试点（流程第 3 步）- 从需求分析中提炼「要测什么」的简短要点清单，产出 specs/testpoints.md。当用户要「写测试点」「提取测试要点」「列出要验证的内容」或执行 testspec-points / testspec points 时使用。也适用于用户说「这个功能要测哪些点」「帮我列测试清单」的场景。与测试用例区分：测试点只列验证目标（What），不写操作步骤（How）。产出供 testspec-generate 展开为完整测试用例。
TestSpec 用例评审（流程第 5 步）- 对生成的测试用例做 14 维度交叉验证（R1-R6 规则检查 + H1-H8 启发式检查），产出 review-report.md 评审报告。当用户要「评审用例」「检查用例质量」「审查测试用例」或执行 testspec-review / testspec review 时使用。也适用于用户说「用例写完了帮我看看」「检查一下覆盖度」「用例有没有问题」的场景。支持默认模式和 --deep 深度模式。
TestSpec 需求源更新与口径收敛（可重复执行的轻量 rebaseline）- 当已有 testspec/changes/<name>/ 后，用户补充、修改、删除、澄清、替换 PRD、接口文档、UI 图、原型图、产品回答、验收规则、权限规则、时间口径、收益映射、字段说明或需求范围时使用。适用于「产品改需求了」「补充接口文档」「新增 UI 图」「删掉这个需求」「同步最新 PRD」「口径收敛」「更新 requirements」「标记旧 analysis 过期」「用例写完后需求变了」「testspec-update / testspec update」。产出更新后的上游需求源、变更影响摘要、blocking_open_questions/dynamic_followups 分类，并标记 stale 下游产物。
SOC 직업 분류 기준
| name | apitestspec-scenario-runner |
| description | 执行已有的框架原生 API spec，并返回明确的通过、失败和归因证据。只要用户已经有 cases.yaml、cases.json、Excel 或 CSV 用例，并且当前主要目标是运行、看 pass/fail、看失败原因、生成 allure-results 或结构化 JSON 结果，都应优先使用这个 skill。当用户说"跑一下""执行测试""看看哪些 case 挂了""直接跑别重写"时务必使用。 |
读取已有 API spec 并执行测试，产出 pass/fail、Allure 和结构化 JSON 结果。
当前阶段只负责执行和归因，不负责设计 spec 或补 flow。
.yaml、.yml、.json、.xlsx、.csv 用例文件allure-results、结果 JSON 或静态报告前置产物apitestspec-composerproject.yaml、环境变量。这属于 apitestspec-flow-configuratorapitestspec-result-viewerapitestspec-surface-scanapitestspec-composerapitestspec-flow-configuratorapitestspec-result-viewer详见 套件路由表。本 skill 对应阶段 4（有 spec 且执行条件已具备，要运行）。本 skill 不能越界回头做前置阶段，只能明确指出缺什么并交接。
目标是自动决定“现在该怎么测”，真正执行，并把失败归因拆成可操作的类别，而不是只给一条命令，也不是把任务扩展成 case 设计或 flow 生成。
.xlsx / .csv：可进入本 skillproject.yaml、config/.env、结果产物allure-resultsproject.yamlCLI 入口：
python skills/apitestspec-scenario-runner/scripts/run_tests.py \
--project <project.yaml> \
[--case <single-case-file>] \
[--tag <tag>] \
[--output results.json]
pytest 方式（支持 Allure）：
cd skills/apitestspec-scenario-runner/scripts && \
pytest test_api.py --project <project.yaml> [--tag <tag>] --alluredir=allure-results
project.yamlBASE_URL 可来自 --base-url 或环境变量config/.env.exampleconfig/.env.example，缺失时只诊断并交接apitestspec-composerapitestspec-flow-configuratorproject.yaml 是否存在BASE_URLconfig/.env 是否存在--serve--case-id 或 --tagapitestspec-flow-configuratorapitestspec-result-viewerproject.yamlconfig/.env执行结束后，回答必须覆盖：
allure-results/ 或结构化 JSON 结果