mcpField
Q
qa-split-testing-levels-pyramid

qa-split-testing-levels-pyramid

github.com/testomatio测试与质量1678 次安装6 天前更新
代码仓库

关于 qa-split-testing-levels-pyramid

QA Split Testing Levels — Test Pyramid 是一项测试技能，将功能场景分配到能够发现相应故障的最低成本测试层级。它盘点项目现有测试，并按层级和测试类型提出覆盖建议。

主要功能

  1. 01盘点现有测试及测试层级
  2. 02将场景分配到合适的最低层级
  3. 03按层级和测试类型建议覆盖
  4. 04说明场景为何需要更高层级测试
  5. 05必要时提供手动验证步骤

适用场景

  1. 01根据风险场景规划功能测试
  2. 02避免对自动化已覆盖的场景进行手动检查
  3. 03判断场景应归入 API、web 还是 mobile 端到端测试

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/testomatio/skills --skill qa-split-testing-levels-pyramid

安装后在 Claude Code 中输入/qa-split-testing-levels-pyramid确认已加载。

详细介绍

QA 拆分测试层级 — 测试金字塔

将测试金字塔应用于某项功能：每个场景都分配到仍能捕获其故障的最低成本层级。 输入：功能描述，或先前 QA 分析得出的风险场景。

测试层级

默认层级，从底层到顶层：

  • 单元 + 集成
  • 端到端
  • 手动

一个层级可以包含由不同运行器执行的多种测试：e2e api / e2e web / e2e mobile。 项目也可能使用其他测试层级：组件、功能、契约、视觉。 采用项目现有的测试层级和测试类型；只有在扫描未发现任何内容时，才使用默认值。

工作流

  1. 使用 scan-automation-project 技能盘点现有测试。
  2. 检测项目的测试层级及其中的测试类型。
  3. 将每个场景分配到能够捕获其故障的最低层级，以及该层级中的一种测试类型。
  4. 按层级和测试类型推荐覆盖比例。

规则

  • 对已由自动化测试覆盖的场景，不要建议手动验证。
  • 将场景分配到更高层级时，说明为什么不能放在更低层级。
  • 一种测试类型永远不能覆盖同一层级的另一种类型：e2e web 不覆盖 e2e api。
  • 将现有自动化场景归纳为通用场景；只有用户提出要求时才扩展。

输出

  • 📐 Testing levels 部分：当使用的层级和测试类型与默认值不同时，列出实际采用的层级和测试类型。
  • ☑️ What is already tested 部分：按层级和测试类型列出已有测试的数量和范围。
  • 🧪 Testing plan 部分：场景 → 层级和测试类型（e2e / api），并说明理由。
  • 当环境支持渲染图表时，添加饼图或测试金字塔：按层级和测试类型展示测试数量及占比。纯终端输出时跳过图表。
  • 对于手动测试项：说明验证方式（操作 → 预期结果）。

后续操作

提供计划后，推荐以下操作：

  • 编写手动测试用例或检查清单 → qa-write-test-cases 技能。
  • 将手动用例自动化为自动化测试 → automate-manual-test-cases 技能。
  • 将测试映射到源文件，以支持基于变更的运行 → qa-test-code-coverage 技能。

评论

支持 Markdown