公開網頁本身揭示的 20 類測試案例

Before anyone writes a single automated test, a public page has already told you a lot: what it answers over https, which links it exposes, whether its fields have labels, which headers it sends, how long the document takes to arrive.

Most first test plans stop at "the happy path works". Here is the list I use instead when I read a page for the first time. Each kind has one example case, written the way I would hand it to a team.

• Functional (FN-01): The reviewed URL answers over https
• Content (CT-01): The meta description is present and short enough to read
• Links (LK-01): Same-host links discovered from the start page resolve
• Forms (FM-01): Visible fields have labels
• Accessibility (A11Y-01): Images expose a text alternative
• Security (SEC-01): HTTPS is the only way in
• Privacy (PR-01): A privacy notice is linked from the page
• SEO (SEO-01): Title, description, canonical, and social tags agree
• Performance (PF-01): The HTML document arrives inside a stated budget
• Load (LD-01): An authorised baseline could repeat the document fetch
• Mobile (MB-01): The layout holds at a phone width
• Internationalization (I18N-01): The lang attribute matches the copy a person reads
• Resilience (RS-01): A missing path returns a deliberate not-found page
• Compatibility (CMP-01): The page still explains itself when scripts do not run
• Media (MED-01): Video exposes captions or a transcript path
• Analytics (AN-01): Analytics tags wait for a recorded choice when the page asks for consent
• Commerce (CM-01): A catalog or payment marker is covered without placing an order
• Visual (VIS-01): Images reserve their box before they paint
• Platform (PLAT-01): The public Salesforce path stays available without an org login
• API (API-01): A public API description is listed without calling the API

How to use the list

1. Read the public response first: status, headers, the HTML that arrives before any script runs.
2. Follow the same-host links you can see, a couple of levels deep, and note what each one answers.
3. Keep only the kinds you will actually run. A list nobody runs is worse than a short one.
4. Name the tool for each case (Playwright, Cypress, Robot, Selenium, WebdriverIO, Appium, JMeter, Gatling, axe-core, Lighthouse, k6) so the case is ready to become code.
5. Treat security headers as signals, not proof. A missing header is a question for the owner, not a finding of a break-in.

What this list is not

It is not a certification and not a penetration test. Reading a public page does not sign in, submit forms, or generate load, so anything behind a login or under real traffic still needs its own plan.

This article was created with the help of AI and checked for accuracy before publishing.