GitHub collection
fishzjp/qa-skills
Imported from GitHub — is this yours?
11 skills imported from this repository.
api-testing
接口级测试时使用——从 OpenAPI/Swagger 文档或用例 Schema 中可自动化的接口用例出发，覆盖参数、边界、鉴权、幂等、并发、错误响应与数据一致性，产出可执行的 API 测试脚本与运行结果；含接口压测承接（k6，类型矩阵轴 1 执行层）。不用于：Web UI 流程（automated-e2e-testing）、手动用例编写（test-case-writing）。
automated-e2e-testing
将手动测试用例转为 Playwright E2E 测试并执行时使用；含写自动化前的业务熟悉踩点、Page Object/Helper 编写、执行中的 Bug 证据收集与报告条目记录。不用于：纯 API 接口测试（api-testing）、以理解系统为目的的独立探索会话（exploratory-testing）、已确认 Bug 的根因分析（bug-analysis）。
bug-analysis
对已确认的 Bug 做根因定位、影响分析、回归建议时使用——复现 → 读代码定位根因 → 影响五面分析 → 回归建议，条目（根因/影响/Severity 依据/修复建议）追加进测试报告。不用于：仅收集 Bug 证据（automated-e2e-testing / api-testing）、疑似未定性缺陷（test-case-writing 的 Cx 记录）。
exploratory-testing
需求不完整、系统陌生、文档不足时，发起以理解系统/发现风险为目的的独立探索式测试会话时使用——charter 驱动（目标 → 探索 → 记录），产出探索笔记（系统理解/风险清单/测试想法）作为需求建模输入或独立交付。不用于：为写自动化踩点的小规模探索（automated-e2e-testing 工作流零）、按既有用例执行（执行类 skill）。
regression-testing
代码变更（diff/Bug 修复/需求变更）后判断应回归哪些测试时使用——沿"改动文件 → 改动函数 → 受影响功能 → 受影响用例"分析链，基于用例 Schema 的追溯映射产出分级回归清单。不用于：用例文件本身的增量修改（test-case-writing）、长期回归策略（test-strategy）。
requirement-analysis
系统性建模某个需求/系统时使用——从 PRD、设计/API 文档、Bug、Issue、代码中提炼目标、范围、角色、规则、异常、依赖与不明确项，产出结构化需求模型（含澄清记录与用户裁决）。不用于：已有需求模型直接写用例（test-case-writing）、"怎么测"的策略决策（test-strategy）、端到端流水线（qa）。
test-case-review
审查已有测试用例（存量资产、他人编写、AI 产出）的覆盖与可执行性时使用——先建可测点基准，再独立评估覆盖、可执行性与正确性，直接修订用例文件并留审查记录。不用于：从零写用例（test-case-writing）、写时自审（其阶段四）、端到端流水线（qa）。
test-case-writing
从需求文档、API 文档、Bug 报告或代码仓库产出可执行的手动测试用例（markmap）时使用——代码优先：索取仓库、先代码审查找潜在 bug 再写用例，并抽取机器可读 Schema。不用于：需求建模（requirement-analysis）、测试策略（test-strategy）、独立审查（test-case-review）、自动化脚本（automated-e2e-testing / api-testing）。
test-strategy
回答"这个功能应该怎么测"时使用——风险评级挂证据（Risk Map），翻译成功能域+类型域两域范围与深度：类型域十轴全轴必答（脚本扫描信号+预填修订），include挂信号、exclude挂理由、full有预算上限。不用于：已有策略直接写用例（test-case-writing）、需求建模（requirement-analysis）、端到端流水线（qa）。