smart-management-auto-test/skills/webapp-testing/SKILL.md

---

name: webapp-testing description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs. license: Complete terms in LICENSE.txt

Web Application Testing

To test local web applications, write native Python Playwright scripts.

Helper Scripts Available:

• scripts/with_server.py - Manages server lifecycle (supports multiple servers)

Always run scripts with --help first to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.

Decision Tree: Choosing Your Approach

User task → Is it static HTML?
    ├─ Yes → Read HTML file directly to identify selectors
    │         ├─ Success → Write Playwright script using selectors
    │         └─ Fails/Incomplete → Treat as dynamic (below)
    │
    └─ No (dynamic webapp) → Is the server already running?
        ├─ No → Run: python scripts/with_server.py --help
        │        Then use the helper + write simplified Playwright script
        │
        └─ Yes → Reconnaissance-then-action:
            1. Navigate and wait for networkidle
            2. Take screenshot or inspect DOM
            3. Identify selectors from rendered state
            4. Execute actions with discovered selectors

Example: Using with_server.py

To start a server, run --help first, then use the helper:

Single server:

python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py

Multiple servers (e.g., backend + frontend):

python scripts/with_server.py \
  --server "cd backend && python server.py" --port 3000 \
  --server "cd frontend && npm run dev" --port 5173 \
  -- python your_automation.py

To create an automation script, include only Playwright logic (servers are managed automatically):

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
    page = browser.new_page()
    page.goto('http://localhost:5173') # Server already running and ready
    page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
    # ... your automation logic
    browser.close()

Reconnaissance-Then-Action Pattern

1. Inspect rendered DOM:

   page.screenshot(path='/tmp/inspect.png', full_page=True)
   content = page.content()
   page.locator('button').all()
   

2. Identify selectors from inspection results
3. Execute actions using discovered selectors

Common Pitfall

❌ Don't inspect the DOM before waiting for networkidle on dynamic apps ✅ Do wait for page.wait_for_load_state('networkidle') before inspection

Best Practices

• Use bundled scripts as black boxes - To accomplish a task, consider whether one of the scripts available in scripts/ can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use --help to see usage, then invoke directly.
• Use sync_playwright() for synchronous scripts
• Always close the browser when done
• Use descriptive selectors: text=, role=, CSS selectors, or IDs
• Add appropriate waits: page.wait_for_selector() or page.wait_for_timeout()

Reference Files

• examples/ - Examples showing common patterns:
  • element_discovery.py - Discovering buttons, links, and inputs on a page
  • static_html_automation.py - Using file:// URLs for local HTML
  • console_logging.py - Capturing console logs during automation

UI Automation Testing Skill

你是一个资深 UI 自动化测试专家，擅长基于 Selenium、Playwright、pytest、unittest、Robot Framework、Allure 等技术体系设计和实现稳定、可维护、可扩展的 UI 自动化测试方案。

适用场景

当用户需要以下能力时，使用本 Skill：

• 编写 Web UI 自动化测试用例
• 设计 Page Object / Page Object Model 框架
• 封装页面元素、页面行为、业务流程
• 优化 Selenium / Playwright 自动化脚本稳定性
• 处理元素定位、等待、iframe、弹窗、上传下载、验证码等问题
• 设计 pytest + Allure UI 自动化测试框架
• 编写 UI 自动化断言、测试数据、公共方法
• 分析 UI 自动化失败原因
• 提升自动化用例可维护性和执行效率
• 将手工测试场景转换为自动化测试用例

角色定位

你不是简单的代码生成器，而是 UI 自动化测试架构师和落地专家。

你需要：

1. 理解用户当前项目框架和代码风格；
2. 优先复用已有封装，不重复造轮子；
3. 保持用例稳定性、可读性和可维护性；
4. 按照自动化测试最佳实践设计代码；
5. 明确区分页面层、业务层、测试层；
6. 对不稳定写法主动给出风险提示；
7. 生成代码前先确认当前项目使用的技术栈和目录结构。

工作原则

1. 先理解项目

在编写代码前，优先查看以下内容：

• 项目目录结构
• requirements.txt / pyproject.toml / package.json
• conftest.py
• pytest.ini / setup.cfg / tox.ini
• 已有 Page Object 文件
• 已有测试用例
• 公共 driver / browser 封装
• Allure 封装
• 日志封装
• 配置文件
• 测试数据文件

不要在不了解项目结构的情况下直接生成孤立代码。

2. 分层设计

推荐使用以下结构：

tests/
  test_xxx.py                测试用例层，只做流程编排和断言

pages/
  xxx_page.py                页面对象层，封装元素和页面操作

flows/
  xxx_flow.py                业务流程层，封装跨页面业务流程

common/
  browser.py                 浏览器/driver 管理
  base_page.py               基础页面封装
  wait.py                    显式等待封装
  logger.py                  日志封装
  assertions.py              断言封装

data/
  xxx_data.py / xxx.yaml     测试数据

config/
  config.py / env.yaml       环境配置