Button Check

Button Check Skill

Systematically test every interactive element on the page:

• Clickables (button / link / tab / checkbox / radio / switch / menuitem) — click and verify
• Inputs (textbox / searchbox / combobox / slider) — fill with sample data and verify

After each test, return to the baseline page so the next element is tested from the same starting state.

Important: Before each tool call, output a short one-line description of what you are about to do (e.g. "Filling the search box with 'hello'"). This helps generate readable step-by-step reports.

When to Use

• Task mentions "遍历所有按钮/链接/输入", "comprehensive UI testing", or "regression testing"
• You need to verify no broken links / dead buttons / unresponsive inputs exist
• Smoke testing a page before a release

Skip for single-element tests — use click or fill directly instead.

Phase 1: Collect Interactive Elements

Call take_snapshot to get the accessibility tree. Group elements into two buckets by role:

Clickable bucket — driven by click:

• button, link, tab
• checkbox, radio, switch
• menuitem

Input bucket — driven by fill (or type_text / press_key for keyboard-only widgets):

• textbox, searchbox
• combobox (treat as click-to-open if no editable affordance is visible, then fill if a textbox appears)
• slider (fill with a numeric mid-range value)

Each element has a uid (e.g. uid=1_5), a role, and a label. Record {uid, role, label, bucket} for every element.

Cap at 50 elements total. If more exist, prioritize:

1. Inputs (form fields) — these often gate downstream behavior
2. button and link (core interactive)
3. tab, menuitem (navigation)
4. Other ARIA roles

Snapshot misses some elements? Icon-only buttons without ARIA attributes are invisible to take_snapshot. Mention in the report instead of erroring.

Phase 2: Baseline

Record the baseline state before testing:

• Call take_screenshot with fullPage: true to capture the entire page
• Note the current URL — this is the baseline URL you MUST return to after every test that navigates away

Phase 3: Test Each Element

CRITICAL RULE: One element per turn. Do NOT batch multiple click / fill calls in a single turn. Each element must follow the full cycle below before moving to the next. Batching loses the ability to attribute errors to specific elements.

For each element in the list:

3a. Drive the Element (one element per turn)

Pick the action by bucket:

Clickable bucket — call exactly these together in one turn:

1. click with includeSnapshot: true — clicks the element and returns the post-click snapshot
2. take_screenshot with fullPage: true

// Tool 1: click
{ "uid": "<element_uid>", "includeSnapshot": true }
// Tool 2: take_screenshot (same turn)
{ "fullPage": true }

Input bucket — call exactly these together in one turn:

1. fill with a representative sample value (see below)
2. take_screenshot with fullPage: true

// Tool 1: fill
{ "uid": "<element_uid>", "value": "<sample>" }
// Tool 2: take_screenshot (same turn)
{ "fullPage": true }

Pick the <sample> value by label / placeholder / role context:

• Generic textbox / searchbox → 测试输入 (or any short Chinese/English string that obviously isn't real data)
• Email-looking field (label/placeholder contains "邮箱" / "email" / "@") → test@example.com
• Number-looking field (label contains "金额" / "数量" / "phone" / slider) → 123
• Password field (type=password or label "密码" / "password") → Test1234!
• combobox with no visible textbox → use click first to open the popup, then in the next turn click an option uid

For widgets that don't accept fill (custom rich editors, contenteditable blocks, sliders with no value attr), fall back to type_text after focusing via click.

The fullPage: true parameter is required — default viewport-only screenshots miss changes below the fold (form validation errors, expanded sections, content loaded at the bottom).

3b. Verify (same turn as 3a, or next turn)

Check for errors using:

• list_console_messages — new JS errors since last check
• list_network_requests — failed requests (4xx/5xx)

These are read-only and can be batched with the screenshot in 3a.

3c. Evaluate Result

Pass criteria: No new JS errors, no failed network requests, the page responds as expected:

• For clicks: new page / modal opens / tab switched / state toggled
• For fills: input value visible in snapshot, no validation error toast appears unexpectedly

Fail criteria: JS error appears, network request returns 4xx/5xx, page crashes, validation message says the input is invalid for a sample that should be accepted.