analyze_url
Analyze a webpage's DOM and network calls to extract testable modules, API endpoints, and layout warnings for generating targeted test cases.
Instructions
Probe a live web page in headless Chromium and return a structured map of testable modules plus the API endpoints the page actually called. The web counterpart of analyze_screen.
Behavior:
page.goto(url) with DOMContentLoaded + 5s networkidle wait
DOM probe extracts five module kinds: form (with fields[] + required flags), nav (link lists), dialog (modal containers), section (labeled regions), cta (action buttons matching action keywords like 登入/送出/ Login/Submit)
Each module gets a candidate_tcs[] — domain-aware test case strings ready to paste into generate_test
Records every fetch/XHR the page issues, dedupes by (method, path), adds endpoint-specific candidate TCs (401, 404, 4xx, payload-too-large…)
Layout overflow scan flags visible elements whose content escapes its container by >2 px horizontal / >10 px vertical (跑版 / text-overflow) Returns: {url, page_title, scanned_at, modules[], api_endpoints[], layout_warnings[]}
When to use:
User wants tests for a specific URL or page
Designing regression coverage from real user-facing behavior
Need backend API coverage hints (api_endpoints[] gives methods + paths)
Investigating layout bugs at the current viewport
Pair with generate_test(module=…) for one runnable test per module
When NOT to use:
Mobile apps (no DOM) → use analyze_screen
Want analysis + immediate test generation → use auto_generate_tests (one-shot version)
Looking for existing tests → use list_tests
Single-page testing prototype → use codegen instead
Edge cases:
URL unreachable / timeout → returns {error: 「打開頁面失敗…」, url}
Page has 0 forms / 0 ctas → modules[] is empty but the call succeeds
Login-walled URL with no auth_cookie → analyzes the login page (less useful) — pass auth_cookie to reach post-login pages
SPA with delayed hydration → bump timeout_ms to 30000+
Plan bookend (v0.10.0): pass plan_id from a prior qa_plan call and the response auto-attaches plan_verification. Each discovered module is passed as an evidence row with its kind field intact (form / nav / cta / dialog / section / tab_bar). CPs author verification_hint against the module kind / name / selector. Source URL is tacked onto each row for scoping context.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 要分析的網頁 URL，需含 protocol（http:// 或 https://）。 | |
| timeout_ms | No | 選填，page.goto 等待 DOMContentLoaded 的逾時毫秒數。之後額外 wait 5 秒讓 networkidle（XHR 載入）穩定。預設 15000。慢站 / 需要 SSR / 重 JS hydration 的網站可拉到 30000+。 | |
| auth_cookie | No | 選填，預先注入登入 cookie，格式：`name1=value1; name2=value2`（一行 cookie header）。用法：先在瀏覽器 DevTools / Application / Cookies 複製值再貼進來。用於分析需要登入後才看得到的頁面。 | |
| plan_id | No | 選填，v0.10.0+. Plan id returned by qa_plan. When supplied, the response gains a `plan_verification` envelope that checks every critical point against the discovered modules. Each module is passed as evidence with its `kind` field (form / cta / nav / etc.) preserved; CPs target the kind/name/selector to assert module discovery. |