关键在于围绕触发条件、约束类型、浏览器差异和绕过路径设计用例，验证前端拦截、提示合理性和后端防护三者缺一不可。
要覆盖 HTML5 表单校验的所有异常输入场景，关键不是“穷举所有输入”，而是围绕校验机制的**触发条件、约束类型、浏览器行为差异和绕过路径**设计测试用例。测试目标是验证：前端是否按预期拦截非法输入、提示是否合理、后端是否不被绕过——三者缺一不可。
聚焦校验触发时机与边界条件
HTML5 校验只在特定时机自动触发（如表单 submit、input 调用 reportValidity()），不会实时监听每个 keystroke。测试需覆盖这些临界点：
- 用户点击提交按钮时：检查 required 字段为空、type="email" 输入 "abc"、pattern 正则不匹配等是否阻断提交并显示默认提示
- 用户按回车键提交：尤其注意非 button 触发的 form 提交（如 input 内回车），容易遗漏
- 调用
form.checkValidity()或input.reportValidity()时：验证返回值与 UI 反馈是否一致（如 :invalid 伪类、validationMessage 内容） - 动态修改属性后：比如 JS 移除 required，再提交，确认校验确实失效；或运行时添加 pattern，验证是否立即生效
覆盖每类验证属性的典型异常值
不同属性对应不同校验逻辑，需分别构造“刚好踩线”和“明显越界”的输入：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
required：输入空格、制表符、零宽字符（
）、仅 placeholder 文本 —— 浏览器是否视为“已填写”？ -
type="email"：输入
user@、@domain.com、user@@domain.com、含中文域名（张三@例子.中国）—— 注意部分浏览器对 IDN 支持不一 -
pattern：用正则
[a-z]{3}时，输入 "ab"（短1位）、"abcd"（长1位）、"ABc"（大小写混用，看是否加i标志） -
min/max（number/date）：输入
9.999（超 max 但为浮点）、2026-13-01（非法日期）、""（空字符串，此时 min/max 不触发，但 required 会） - minlength/maxlength：输入 Unicode 组合字符（如带重音的 é）、emoji（某些计数方式不同）、全角空格 —— 验证的是码点长度还是视觉长度？
模拟真实绕过手段，验证前端不可信性
任何客户端校验都可被绕过。测试必须主动尝试以下操作，并观察后端响应：
立即学习“前端免费学习笔记（深入）”；
- 禁用 JavaScript 后提交：确认 novalidate 是否被忽略，原生校验是否仍起作用（它不依赖 JS）
- 用 DevTools 删除 input 的 required / pattern / type 属性，再输入非法内容提交
- 修改 form 的
novalidate属性为 false 或移除它，看是否意外启用校验 - 用 Burp Suite 或 curl 构造请求：跳过前端，直接 POST
{"email": "not-an-email"}，后端必须拒绝并返回明确错误 - 移动端特殊场景：iOS 键盘自动大写首字母导致邮箱小写规则失效、中文输入法下 pattern 匹配延迟
跨浏览器与渲染上下文验证
同一份 HTML 在不同环境表现可能不同：
- 在 Chrome、Firefox、Safari（尤其是 iOS）、Edge 中分别测试默认提示文案、气泡位置、:valid/:invalid 样式应用时机
- 动态渲染场景：Vue/React 组件中 v-if 或 useEffect 插入表单时，确保 novalidate 已存在，且 required 等属性在 DOM 初始挂载时就位
- Shadow DOM 内的表单：原生校验在部分浏览器中可能不穿透，需单独验证
- iframe 嵌入的表单：检查跨域限制是否影响 reportValidity() 调用
