SuperAPI AI 工具集

Skill 广场

找到适合任务的 Agent Skill,阅读介绍并复制安装命令。

更新于 10-21 00:11

测试与质量

12,408 个结果

qa-team

QA Team 是一个用于外部视角(outside-in)验证的测试技能,基于 gadugi-agentic-test 框架,通过声明式 YAML 场景让 AI 智能体执行、观察并验证应用行为。它强调测试只描述“应该发生什么”,而不关心内部实现,因此适合冒烟测试、行为驱动测试、跨平台测试(CLI、TUI、Web、Electron)、重构安全验证以及可作为可执行规格的文档化测试。该技能还支持并排一致性(parity)与 A/B 行为对比,可用于旧实现与新实现、方案 A 与方案 B 的对比验证,支持在隔离沙箱中运行、比较 stdout/stderr/退出码/JSON 输出/文件系统副作用,并可通过 --observable 模式在配对虚拟 TTY 中调试,通过 --ssh-target 在远程环境运行,通过 --shadow-mode 记录发布分歧而不阻断执行。技能按四个渐进级别组织:基础、中级、高级、一致性与影子模式。

测试与质量53 次安装

visual-testing

Visual Testing 是一个视觉测试与 UI 验证技能,属于 browser-devtools-skills 技能集。它通过截图、响应式测试和 Figma 集成,帮助用户验证界面外观、与设计稿进行对比并检查视觉回归。该技能适用于需要确认页面实现与设计一致、排查样式问题、跨断点检查布局、或验证组件在各视口下的显示效果等场景。它依赖 browser-devtools-cli 命令行工具执行截图捕获、视口调整、DOM 检查及 Figma 设计对比等操作。

测试与质量53 次安装

testing-with-espresso-interop

该技能用于在同一 Android 测试中混合使用 Compose 查找器与 Espresso onView,适用于操作 Android Dialog 窗口、验证 IME(软键盘)状态、以及测试同时包含 Android View 层级与 ComposeView 的混合 Activity。技能说明 Compose 与 Espresso 通过名为 EspressoLink 的内部 IdlingResource 桥接,无需手动注册空闲资源,但 Espresso.onView 必须在测试线程调用,不能包在 runOnIdle 或 runOnUiThread 内。内容涵盖适用与不适用场景、前置依赖、工作流示例代码、常见错误模式以及验证清单,并强调纯 Compose 测试或 Compose Dialog 不应使用此技能。

测试与质量53 次安装

playwright-test-architecture

Playwright Test Architecture 是面向 Playwright 测试项目的组织、配置与结构最佳实践技能,用于搭建可扩展、易维护的测试套件。它涵盖安装与更新、项目基础与高级配置、测试目录与文件组织模式、并行执行与分片、重试策略、报告器配置、多环境配置、Trace/视频/截图录制、全局 setup 与 teardown,以及测试分组与标签等主题。适合需要在多浏览器、多设备与多环境下统一管理端到端测试的团队参考使用。

测试与质量53 次安装

syncable-entity-testing

该技能文档是 Twenty 代码库(twentyhq/twenty 服务端内部)可同步实体(syncable entity)开发流程中的第 6 步(共 6 步,为强制步骤),用于编写完整的集成测试套件。它面向参与 Twenty 本体代码贡献的开发者,而非基于 Twenty 构建应用的开发者。文档要求在完成前置 5 个步骤后,为可同步实体创建覆盖失败场景(所有校验器异常与输入转译错误)和成功场景(全部 CRUD 操作与边界情况)的集成测试,并配套可复用的查询工厂与包装工具函数。文档给出了测试工具的命名与文件路径约定、两文件模式(查询工厂 + 包装器)的示例代码、失败创建测试与成功创建测试的完整示例、更新与删除测试的文件清单,以及测试最佳实践(清理、类型安全输入、快照测试)、运行命令、完整的测试清单与成功标准(测试工具至少 6 个文件、快照生成并提交、测试稳定通过、覆盖率满足要求大于 80% 等)。

测试与质量53 次安装

verify-changes

verify-changes 是一个强调“通过执行来验证代码”的技能,核心理念是“代码存在”不等于“代码可用”。它要求开发者不要只靠检查代码或假设类型正确来判断改动是否有效,而必须实际运行代码并给出证据。该技能用可复用的验证协议指导流程:先识别改动了哪些文件、期望行为有何变化、原始缺陷或需求是什么;再按变更类型选择验证方式,如缺陷修复需复现原场景、新功能需运行并确认输出、重构需跑既有测试、API 变更需调用端点、UI 变更需渲染组件、配置变更需加载配置、构建/基础设施变更需执行构建命令。随后实际执行验证命令,例如 npm run build、npm run test、npm run dev、node 加载模块、curl 调用接口、python 脚本测试等。最后输出验证报告,包含改动内容、验证方式、证据(构建、测试、运行时、边界情况)以及尚未验证的部分,并针对 Web 应用、API/后端、CLI/脚本等不同项目类型提供检查清单,同时列出常见反模式及修复方式。

测试与质量53 次安装

qa-only

qa-only 是一个仅生成报告的浏览器 QA 技能,用于对指定 Web 应用进行测试并输出可复现的发现与覆盖证据。它允许在需要时只读地查看源码,以将请求的 diff 映射到路由或理解复现路径,包括影响用户流程的后端改动,但绝不编辑应用文件、测试或配置,也不提交、推送或合并。该技能遵循选定的 quick、diff-aware、full 或 regression 范围,报告真实发现(证据支持零发现时也如实报告),不强制配额,也不给未测试类别打满分。不可用的浏览器、角色、数据或检查会被记录为覆盖不完整。最终在指定位置生成 qa-report-<domain>-<date>.md,包含范围、已测试覆盖、问题、复现步骤、证据和限制,并可提出修正建议但不实际应用。

测试与质量52 次安装