打开Chrome的测试开发者工具，切到Network面板，测试刷新页面——这是测试我每次接手一个新Web项目时做的第一件事。不是测试为了看代码写得多漂亮，而是测试想看看请求发了多少条，哪些是测试同步阻塞的，有没有404的测试资源在拖后腿。一个页面加载超过3秒，测试用户流失率能涨到40%以上，测试这不是测试我编的数据，是测试Google爬虫团队几年前就公开过的结论。Web端测试，测试说到底就是测试跟这些看不见的细节较劲。
功能测试谁都会做。测试点按钮，测试填表单，看跳转对不对。但真正让人头疼的是那些“偶发”的问题。上周我遇到一个bug：用户上传头像后，偶尔会显示成上一张图片。复现了十几次才抓到规律——只有在网络延迟超过800毫秒时才会出现，因为前端用了同一个URL做缓存，后端返回新图片时浏览器直接读了本地缓存。这种问题你写一百条测试用例都覆盖不到，得靠手动模拟弱网环境，或者用Charles把带宽限制到2G水平。
兼容性测试是个无底洞。Chrome、Firefox、Safari、Edge，每个内核渲染同一段CSS都可能不一样。更别说还有各种国产浏览器，双核切换时JavaScript的执行顺序都能变。我的做法是先用Can I Use查API支持度，再用BrowserStack跑一轮截图对比。但机器终究代替不了人眼，有些布局错位得在真实设备上划一划才能发现。比如iOS的Safari，输入框聚焦时键盘弹起会把整个页面顶上去，安卓上却不会。这种差异文档里不会写，得自己踩坑。
性能测试别只盯着首页加载时间。用户真正在意的是交互响应。比如一个列表页，滚动到第五屏时开始卡顿，你测首屏加载再快也没用。我习惯用Lighthouse跑分，但更信Chrome Performance面板里的火焰图。看看长任务在哪里，有没有强制同步布局，内存是不是只涨不跌。有一次发现一个定时器每500毫秒触发一次DOM查询，页面开了半小时后内存涨到800MB，用户不崩才怪。
安全测试容易被忽略，但Web端尤其重要。XSS和CSRF是老生常谈，可很多项目连基本的输入过滤都没做。我试过在一个搜索框里输入<img src=x onerror=alert(1)>，直接弹窗。开发还一脸无辜：“我们用了React啊。” React确实默认转义，但如果你用了dangerouslySetInnerHTML，照样中招。还有接口越权，把用户ID从1改成2就能看到别人的订单，这种漏洞在测试环境里一抓一个准。
自动化测试能省时间，但别指望它发现所有问题。Selenium写出来的脚本很脆弱，页面结构一改就全红。我一般只把回归测试交给它，比如登录、下单这些核心链路。探索性测试还得靠人，带着怀疑去点每一个按钮，看每一个报错。有次我故意在日期选择器里输入“2024-02-30”，后端直接返回500，日志里连个错误堆栈都没有。这种边界情况，自动化脚本根本不会去试。
Web端测试没有银弹。工具再多，也替代不了对业务的理解。你得知道用户会怎么用，更要清楚他们可能会怎么“乱用”。每次上线前，我都会问自己一句：如果我是那个最没耐心的用户，我会在哪个环节骂人？答案往往就是下一个要测的地方。