打开一个网页，网页三秒内没加载出内容，测试用户就走了。网页这不是测试猜测，是网页Google和Akamai都验证过的数据。网页测试要解决的测试第一个问题，就是网页这个“三秒”。

我见过一个电商项目，测试开发环境跑得飞快，网页上线后首页白屏率高达12%。测试查了两天才发现，网页测试环境用的测试是内网CDN，生产环境走的网页是公共节点，某个地区的测试DNS解析出了问题。这种问题，网页功能测试用例覆盖不到。所以网页测试的第一步，不是点按钮，而是把网络链路摸清楚。

功能测试：别只测“正常路径”

表单提交、链接跳转、登录登出——这些谁都会测。真正容易漏的是边界和异常。比如一个输入框限制50个字，你输入49个、50个、51个，再试试粘贴一段带换行符的文本。我遇到过前端校验通过、后端没校验的情况，用户绕过JS直接发请求，数据库里塞进了一堆脏数据。

还有Cookie和Session。禁用Cookie后页面还能正常用吗？Session过期后点击“返回”会不会报错？这些场景在真实用户那里天天发生，但测试用例里经常缺席。

兼容性：不是装个Chrome就行

浏览器差异到今天依然存在。Safari对日期格式的解析就跟Chrome不一样，`new Date("2024-01-01")`在Safari里可能返回Invalid Date。CSS的`gap`属性在旧版Edge上直接失效。更麻烦的是移动端——同一款手机，微信内置浏览器和系统浏览器渲染结果可能不同。

我的做法是：先看用户数据，确定Top 5浏览器和机型，优先覆盖。剩下的用BrowserStack或Sauce Labs跑一轮。没必要追求100%覆盖，但主流必须过。

性能：数字比感觉可靠

“感觉有点慢”不是测试结论。用Lighthouse跑一遍，看FCP、LCP、CLS三个指标。FCP超过1.8秒就要警惕，LCP超过2.5秒算不及格。我见过一个页面，首屏图片没做懒加载，一张2MB的Banner图拖垮了整个LCP。

另一个常被忽略的是接口响应。前端渲染再快，后端接口返回要3秒，用户照样等。用Chrome DevTools的Network面板看Waterfall，找出哪个请求在拖后腿。有时候不是接口慢，是请求串行了——A接口等B接口，B接口等C接口，明明可以并行的。

安全：别等上线了再补

XSS和CSRF是网页测试的老话题，但依然有人栽。测试时在输入框里填`<script>alert(1)</script>`，看页面会不会弹窗。检查Cookie有没有设HttpOnly和Secure。表单提交有没有CSRF Token。

还有一个容易漏的：敏感信息泄露。打开DevTools的Sources面板，看看JS文件里有没有硬编码的API Key。我就见过前端代码里直接写着数据库密码的，注释还写着“TODO: 移到环境变量”。

自动化：该用，但别迷信

Selenium、Playwright、Cypress，工具选哪个看团队习惯。自动化适合回归测试——每次发版跑一遍核心流程。但UI自动化很脆，页面改个class名就可能挂掉。我的经验是：接口自动化优先，UI自动化只覆盖最关键的10%路径。剩下的靠手工探索，测试人员的直觉和好奇心，脚本替代不了。

网页测试没有银弹。每个项目踩的坑不一样，唯一不变的是：多站在用户角度想一步，多问一句“如果这里出问题会怎样”。