mcpField
U
ui-test-playwright

ui-test-playwright

github.com/naodeng测试与质量28553 次安装今天更新
代码仓库

关于 ui-test-playwright

面向 Playwright UI 自动化测试方案与设计的技能，适用于已有相关工具链或需要可落地测试规划的项目。它强调稳定定位器、业务状态断言、并行数据隔离，以及保留失败证据。

主要功能

  1. 01沿用项目 Playwright 配置与入口
  2. 02优先使用稳定语义定位器
  3. 03通过重试断言核对业务状态
  4. 04隔离并行测试的账号与数据
  5. 05保留失败轨迹、截图和日志

适用场景

  1. 01为 Playwright 项目设计 UI 测试
  2. 02规划订单或账务状态验证
  3. 03检查并行测试的数据隔离方案

安装

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

$npx skills add https://github.com/naodeng/awesome-qa-skills --skill ui-test-playwright

安装后在 Claude Code 中输入/ui-test-playwright确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

README.md
agents/
openai.yaml
evals/
eval.yaml
evals/cases/
basic-script-artifact.yaml
basic-success.yaml
domain-method-regression.yaml
edge-incomplete-input.yaml
edge-scope-boundary.yaml
evals/fixtures/
check_domain_decisions.py
check-domain-decisions.sh
domain-oracle.json
evals/fixtures/checkout-app/
checkout.spec.cjs
index.html
playwright.config.cjs
README.md
receipt.html
server.mjs
evals/fixtures/scripts/
check_playwright_output.sh
examples/
sample-context.md
output-templates/
template-markdown.md
prompts/
ui-test-playwright.md
references/
domain-decision-example.md
framework-spec.md
setup-and-ci.md
scripts/
run-tests.sh

详细介绍

原文在翻译后有更新，译文可能不是最新。

Playwright UI 测试（EN）

中文版： 请参阅对应的中文技能。

何时使用

  • 需要生成可用于 Playwright UI 测试工作流的输出。
  • 项目已使用 Playwright，或希望获得可直接用于 Playwright 的规划。

输出格式选项

默认使用 Markdown，除非请求明确要求其他格式。

使用方法

  1. 打开 prompts/ui-test-playwright.md，并将其用作主要提示词。
  2. 补充真实的项目背景：范围、环境、约束、风险、依赖项和预期交付内容。
  3. 如果输入不完整，请先提供可用的初版，并标明缺失信息和假设。

参考文件

  • 在校准领域结果、有效控件或证据缺口时，请阅读 references/domain-decision-example.md，其中包含经过脱敏的输入、逐项判定标准和可复现的计算。

  • prompts/ui-test-playwright.md：此技能的主要提示词。

  • references/framework-spec.md：特定工具的结构和覆盖范围说明。

  • references/setup-and-ci.md：设置、执行和 CI 说明。

  • examples/sample-context.md：示例请求背景。

  • scripts/run-tests.sh：轻量级本地执行入口。

领域执行要点

  1. 固定项目的 Playwright、Node 和浏览器版本、项目、fixtures 与配置。保留带有测试 ID、提交、worker/项目和环境信息的入口；诊断不兼容的配置，但不要切换技术栈。
  2. 优先使用稳定的 role/name/testid 定位器，以及可自动重试的业务断言来验证订单/账本/状态/主体。标题/URL 检查只能保护导航，不能证明支付成功。
  3. 为每个 worker 分配独立的浏览器上下文、storage state/账户和业务键。上下文隔离仍需服务端账户隔离；清理时应遵循依赖关系的逆序。
  4. 配合错误业务状态和并行 A/B 对照来测试断言的灵敏度。保留 trace/截图/日志和非零的 runner/CI 状态，包括首次重试失败。区分生成的资源、真实浏览器运行和验收。

常见问题

  • 不要在范围含糊且缺少背景信息时使用。
  • 不要将所有领域都视为同等重要。
  • 不要遗漏假设和缺失信息。

最佳实践

  • 从提示词文件开始，然后只补充关键背景信息。

  • 确保输出由风险驱动且可执行。

  • 如果请求不完整，请先提供可用的初版，并标明缺口。

  • 若要验证生成的业务断言、失败传播或隔离，请阅读 evals/fixtures/checkout-app/README.md 及其本地 good/bug/timeout 控件；仅在请求执行时才运行。

评论

支持 Markdown