网页代码测试

打开浏览器，网页按下F12，代码你看到的测试那个花花绿绿的代码面板，才是网页网页真正的样子。右键“查看网页源代码”拿到的代码是原始HTML，而开发者工具里显示的测试，是网页浏览器解析、执行JavaScript、代码应用CSS之后最终渲染出来的测试结构。这两者经常不一样。网页我见过一个电商页面，代码源代码里商品价格写的测试是199，开发者工具里显示的网页是149——因为JS在加载后改写了DOM。如果你只测源代码，代码这个bug永远抓不到。测试

网页代码测试这件事，很多人第一反应是“写个测试脚本跑一遍”。但实际情况比这麻烦得多。一个页面在不同浏览器里的行为可能完全不同。Chrome跑得好好的动画，到了Safari上直接卡死；Firefox里正常提交的表单，Edge里报跨域错误。这不是玄学，是各家用的是不同渲染引擎——Blink、WebKit、Gecko。你没法只测一个浏览器就宣布“没问题”。

我自己的习惯是，拿到一个页面先做三件事。

第一，断网。把Network面板调到Offline，刷新页面。很多页面在断网后直接白屏，因为所有内容都依赖接口返回。这不是说不能依赖接口，但至少得有个降级方案——缓存、骨架屏、错误提示，随便什么都行。我见过一个新闻网站断网后整个页面空白，连logo都不显示，因为logo也是通过接口拿的base64。这就属于测试没做到位。

第二，把JavaScript禁掉。Chrome设置里能关，或者用开发者工具的Disable JavaScript。页面还能不能看？内容还在不在？导航还能不能用？如果一个页面的核心内容完全依赖JS渲染，那搜索引擎爬虫大概率也抓不到。这不是SEO的问题，是可用性的问题。有些政府网站、银行页面到现在还在用纯服务端渲染，不是技术落后，是稳。

第三，改窗口大小。从320px拉到2560px，看布局什么时候崩。媒体查询写得好不好，一拉就知道。我遇到过一个后台管理系统，在1920px下完美，在1366px下侧边栏直接盖住主内容区。原因是用了固定宽度加绝对定位，没写flex或者grid。这种问题在开发者的宽屏显示器上永远发现不了。

说到具体工具，Selenium和Puppeteer是绕不开的。Selenium老牌，支持多语言，但跑起来慢，配置也烦。Puppeteer只支持Chrome和Firefox，但API干净，跑得快。Playwright是后来者，微软出的，支持Chromium、Firefox、WebKit三家，还能模拟移动设备。我现在基本只用Playwright。写个脚本，让它自动打开页面、点击按钮、填表单、截图对比，比手动测快得多。但工具只是工具，关键是测什么。自动化能覆盖回归测试，但发现不了“这个按钮颜色看起来不对劲”这种问题。视觉回归测试工具比如Percy、Applitools能帮上忙，但也要人去看报告。

还有一个容易被忽略的点：控制台报错。很多人打开页面，功能正常就不管了。但Console面板里一堆红色报错，可能不影响当前功能，但说明代码里有问题。比如一个未捕获的Promise rejection，现在没事，等用户操作到某个边缘路径就炸了。我养成的习惯是，每次打开页面先看Console，有红色就记下来，不管功能是否正常。

网页代码测试没有“测完了”这一说。浏览器在更新，依赖库在更新，用户环境千奇百怪。你能做的，是在每次上线前，把关键路径跑一遍，把边界情况想一想。剩下的，靠监控和用户反馈兜底。这不是完美的方案，但比什么都不测强。