打开浏览器按F12，网页这个动作我每天至少重复二十次。测试很多人以为网页测试就是工具点点按钮看能不能跳转，实际上远不止如此。网页拿Chrome DevTools来说，测试Network面板能告诉你哪个接口慢了300毫秒，工具Lighthouse跑一遍直接甩出性能评分——这些数据比“页面能打开”有用得多。网页

我见过一个电商项目，测试首页加载要8秒。工具开发团队说服务器没问题，网页结果用WebPageTest一测，测试发现是工具某张轮播图没压缩，原图4.2MB。网页换掉之后直接降到2.3秒。测试工具不会替你写代码，工具但它能把问题从“感觉慢”变成“这里慢了，因为这张图”。

几种顺手的选择

Selenium算老牌了。写Python脚本控制浏览器，适合回归测试。但它的API有点啰嗦，定位一个按钮可能要写三行。后来Playwright出来了，微软做的，支持多浏览器，自动等待元素出现，代码量少一半。我最近做表单验证测试基本都用它。

Puppeteer是Chrome团队维护的，只针对Chromium内核。如果你不关心Firefox和Safari，它够快够直接。有个坑：无头模式下某些CSS动画不触发，测视觉回归时得注意。

还有个叫Cypress的，跑在浏览器里而不是外面。调试体验好，时间旅行能回看每一步快照。缺点是跨域测试麻烦，多标签页支持弱。选哪个取决于你在测什么——简单页面用Cypress舒服，复杂场景Playwright更稳。

性能测试别只看分数

Lighthouse给分很直观，但别被绿字骗了。它跑的是模拟环境，真实用户可能在3G网络下打开。有个项目Lighthouse性能92分，结果用Chrome User Experience Report一看，实际用户有15%的首次输入延迟超过500毫秒。工具给的是参考，不是结论。

WebPageTest能选真实设备、真实网速。我习惯用“Dulles, VA - Moto G4 - 3G”这个组合，基本能模拟最差情况。测试结果里有个“Start Render”和“Speed Index”，比单纯的加载时间更有意义——用户看到内容的时间才是关键。

可访问性测试常被忽略

axe DevTools插件装一个，点一下就能扫出对比度不足、缺少alt标签、表单没有label这些问题。有次我帮朋友改个人博客，扫出来17个问题，其中3个是按钮没有可访问名称。屏幕阅读器用户根本不知道那按钮干什么的。修起来不麻烦，但没人提醒就永远想不到。

WAVE是另一个在线工具，直接输入网址就能出报告。它会把问题按严重程度标出来，红色是错误，黄色是警告。我一般先用axe扫，再用WAVE复查，两个结果交叉看。

移动端测试的坑

Chrome DevTools的设备模拟够用，但触摸事件模拟不了真实手指。比如滑动删除，鼠标拖拽和手指滑动触发的事件序列不一样。真要测移动端，连真机调试。Android用chrome://inspect，iOS用Safari的开发菜单。麻烦，但准确。

还有响应式断点。别只测375px和414px，试试320px——iPhone SE第一代那个宽度。很多导航栏在那时候会挤成一团。我习惯把浏览器窗口慢慢拉窄，看什么时候布局崩掉，那个宽度就是需要加媒体查询的地方。

工具终究是工具。用WebPageTest测出首屏慢了，你得去翻代码找原因。用axe扫出对比度问题，你得去调色板重新选颜色。测试工具的价值在于把模糊的“感觉不对”变成具体的“这里不对”，剩下的还得靠人。