qa-test-script-generator

Solid

在用户确认用例之后,把已确认的业务用例展开为可执行的 spec-task 和测试脚本。你产出的是 test-spec-tasks.json——后续执行阶段通过它逐条运行并收集证据。 你只负责"生成可执行的东西",不负责"执行"。pass/fail/ready 的判断由后续的执行阶段来做。 不适用:执行测试、标记 pass/fail、就绪判定。

Testing & QA 29 stars 9 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 83/100

Stars 20%
49
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# QA Test Script Generator — 脚本生成 > **CLI 调用约定**:本工具包的 CLI 是 `quality-assurance-agent/scripts/qa_agent.py`。 > 它**不以 PATH 命令的形式分发**——命令由你(agent)执行,人不必手敲。 > 开工前解析一次 skill 目录,之后所有命令一律写成 > `python "$QA_AGENT_DIR/scripts/qa_agent.py" <cmd>`: > > QA_AGENT_DIR="${QA_AGENT_CLI:-$(dirname "$(find ~/.claude/skills ~/.agents/skills ~/.codex/skills .claude/skills .agents/skills .codex/skills -maxdepth 2 -name SKILL.md -path '*quality-assurance-agent/*' 2>/dev/null | head -1)")}" > > 运行环境若已告知本 skill 目录(Claude Code 会),直接用,不必跑上面的查找。 > 完整命令语法见 `$QA_AGENT_DIR/references/cli-reference.md`。 ## 你的定位 你是用例到执行之间的转换层。`qa-testcase-designer` 产出的是人在看的用例,你产出的是执行阶段在跑的 task。 你的 spec-task 写得不精确,后面的执行阶段就没法可靠地判断 pass/fail。 你**不执行**任务、**不标记 pass/fail**、**不判断就绪**。实现状态只到 `implemented`,执行状态留 `not-run`。 ## CLI 命令 本阶段所有命令的完整语法、参数说明见**主 skill(quality-assurance-agent)→ CLI 命令参考 → 阶段 3**。这里不重复维护命令语法。 ## 生成层级约定 脚本层走**完整测试金字塔**(`generate-spec-tasks` 默认行为,不带 `--acceptance-mode`):每条用例按「单元 > 集成 > API > E2E」逐级递减拆解。不区分「开发/验收模式」——验收同样要有单元测试(测资金计算、状态机、校验逻辑等白盒行为)。 默认最小 task 数:P0=8、P1=5、P2=3、P3=1;默认比例 unit 60% / integration 20% / api 15% / e2e 5%。纯后端 scope(无前端 UI)自动跳过 E2E。 ## 工作流 ### 1. 校验用例 先跑 `validate-cases` 确保用例本身没有 schema 问题。只有 `confirmed` 状态的用例才生成 task。 ### 2. 生成 spec-task 先读取 `$QA_AGENT_DIR/references/spec-task-planning.md` 了解 spec-task 的字段契约、覆盖规则和 completion 门禁规则。 运行 `generate-spec-tasks`。确保: - 每条 task 有 `oracle.ui/api/db/sideEffects/negativeAssertions` 字段 - 每条 P0/P1 风险(来自 risk-analysis.json)出现在对应 tas...

Details

Author
mingdui
Repository
mingdui/ming-qa
Created
1 weeks ago
Last Updated
5 days ago
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Testing & QA Solid

qa-test-runner

在 spec-task 和测试脚本就绪后,逐条执行、分类失败、修最小根因、收集证据、跑 completion 门禁。 你只负责"跑"——不生成报告、不审查代码、不判 Ready。审查留给 qa-code-reviewer,报告与判定留给 qa-report-generator。 不适用:报告生成、代码审查、用例设计。

29 Updated 5 days ago
mingdui
Testing & QA Solid

qa-testcase-designer

在风险分析完成后、写测试代码之前,生成中文业务用例并等待用户确认。这是整个 QA 流程中唯一的强制人工门禁——确认后不可回头改用例。 从 context、risk-analysis、已有用例索引出发,生成只含业务行为的 test-cases.json(不含技术检查如 Maven/build/安装), 渲染 test-cases.html 供用户审阅,运行三模型交叉审查,合成反馈修改后提交确认。确认后 promote 到长期 knowledge base。 不适用:写测试代码、执行测试、代码审查。

29 Updated 5 days ago
mingdui
Testing & QA Solid

qa-risk-analyzer

在测试用例设计之前,先识别高风险业务路径和必需的验证断言(oracle)。分析需求文档、代码 diff、已有用例和上下文, 找出资金/权限/状态机/并发/异步/数据一致性等高危区域,输出每条风险的 businessPath、requiredAssertions、suggestedTestLayers, 以及覆盖率缺口。不要在风险未明确前写业务用例。 不适用:写业务用例、写测试代码、修改产品代码。

29 Updated 5 days ago
mingdui