en un clic
en un clic
| name | button-check |
| description | Traverse all interactive elements on the page — click clickables, |
Systematically test every interactive element on the page:
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.
Skip for single-element tests — use click or fill directly instead.
Call take_snapshot to get the accessibility tree. Group elements into two buckets by role:
Clickable bucket — driven by click:
button, link, tabcheckbox, radio, switchmenuitemInput bucket — driven by fill (or type_text / press_key for keyboard-only widgets):
textbox, searchboxcombobox (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:
button and link (core interactive)tab, menuitem (navigation)Snapshot misses some elements? Icon-only buttons without ARIA attributes are invisible to take_snapshot. Mention in the report instead of erroring.
Record the baseline state before testing:
take_screenshot with fullPage: true to capture the entire pageCRITICAL 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:
Pick the action by bucket:
Clickable bucket — call exactly these together in one turn:
click with includeSnapshot: true — clicks the element and returns the post-click snapshottake_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:
fill with a representative sample value (see below)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:
textbox / searchbox → 测试输入 (or any short Chinese/English string that obviously isn't real data)test@example.comslider) → 123type=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 uidFor 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).
Check for errors using:
list_console_messages — new JS errors since last checklist_network_requests — failed requests (4xx/5xx)These are read-only and can be batched with the screenshot in 3a.
Pass criteria: No new JS errors, no failed network requests, the page responds as expected:
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.
After every element test, compare the current URL to the baseline URL recorded in Phase 2.
If the URL changed (clicked a link, form submission redirected, etc.), restore the baseline before continuing — otherwise subsequent uids belong to a different page and you'll click the wrong things:
navigate_page with type: "back". This preserves session state and the back-stack.take_snapshot. If still not on the baseline URL, go to step 3.navigate_page with url: "<baseline_url>". This is the fallback for SPAs that swallow the back action.take_snapshot after returning. The element ids from the original snapshot are now stale; you need fresh ones to keep iterating.If the URL did NOT change (in-page modal opened, input filled, tab switched, etc.):
press_key with key: "Escape" or click the dismiss buttonfill setting value: "" so the next test starts from a clean fieldtake_snapshot (uids are still valid)If you can't return after 2 attempts, stop testing the rest of the list and record:
⚠️ Lost baseline at element <uid> "<label>"; remaining N elements skipped because navigation could not be restored.
Then jump to Phase 4.
After all elements are tested (or the lost-baseline abort triggered), compile results:
遍历测试完成:共检测 N 个交互元素 (M 个点击 / K 个输入),X 个正常,Y 个发现问题,Z 个跳过。
发现的问题:
● 网络请求失败 (2 个):
- Button "提交" (uid=1_12) — POST /api/submit 返回 500
- Link "下载报告" (uid=1_25) — GET /report.pdf 返回 404
● JS 控制台报错 (1 个):
- Button "删除" (uid=1_8) — TypeError: cannot read property 'id' of undefined
● 输入校验异常 (1 个):
- Textbox "邮箱" (uid=1_30) — 接受非邮箱字符串而未提示
● 跳过 (1 个):
- Combobox "城市" (uid=1_15) — 弹层未出现,无可选项
Include a final take_screenshot with fullPage: true in your closing message.
Set overall status:
failed if any element caused JS errors / 4xx-5xx / lost-baseline abortwarning if elements were skipped (not visible, popup didn't open, lost baseline mid-run)passed if all elements tested without issuesclicks, two fills, or a click+fill. Each element needs its own action → screenshot → verify cycle.take_screenshot(fullPage: true) after every action — viewport-only screenshots miss off-screen changes.list_console_messages + list_network_requests + take_screenshot can run in the same turn.take_snapshot to save tokens.<a href> pointing to external domains, verify the href value from the snapshot rather than navigating away.cdp_upload_file directly if a separate task requires it).Use WebQA to test websites, web pages, URLs, login flows, search flows, forms, navigation, and core user journeys with an AI browser QA agent.
Run a Nuclei security scan against the target URL and report
Decompose a task into steps with completion checkpoints.
Structured error recovery for failed or ineffective browser
UI audit for hierarchy, accessibility, and UX.