web测试

web测试这活儿，干久了会让人产生一种错觉——觉得自己像个质检员，又像个侦探。白天盯着浏览器里跳动的像素，晚上做梦都在复现bug。但真正干明白的人都知道，这行当的门道不在"点按钮"上，而在"猜人心"。

我见过最离谱的bug，是用户用触屏笔点了一下页面右下角的空白区域，结果整个购物车清了空。代码查了三天，最后发现是某个隐藏的透明图层在作祟——它原本是给未来功能预留的占位符，测试环境里没启用，可偏偏在某个安卓版本上，它的点击事件穿透了。这种问题，你写一百条自动化用例也发现不了，非得靠真人拿真设备去戳。

所以别迷信测试覆盖率。覆盖率百分之九十听着唬人，可剩下那百分之十，往往就是用户最常走的那条路。我有个习惯，测新功能前先自己当半小时"暴躁用户"——乱点、连点、狂点，甚至把手机倒过来晃。真实用户不会按你的测试用例来，他们会把键盘拍得啪啪响，会一边打电话一边单手操作，会在地铁隧道里信号忽明忽暗时刷页面。这些场景，测试环境里永远模拟不出来。

说到环境，web测试最头疼的就是"在我这儿好的呀"。开发说本地跑得飞快，测试说预发布环境一切正常，结果上线第二天用户投诉白屏。最后查出来，是用户用的老版本浏览器不支持某个新的CSS属性。这事儿没法全怪开发，毕竟Chrome都更新到一百多版本了，可总有人还守着五年前的IE。做web测试的，心里得装着一张兼容性地图，哪些系统配哪些浏览器容易出幺蛾子，得门儿清。我自己的做法是，每次发版前，拿虚拟机跑一遍最老的那几个浏览器，哪怕丑点，但至少别让用户开不了门。

性能测试也藏着猫腻。用工具压测，每秒一万个请求，服务器稳如老狗。可真实用户不会这么齐刷刷地来，他们是一阵一阵的——早上十点抢优惠券，晚上八点刷视频，周末下午逛商城。峰值流量像潮水，涨的时候服务器得扛得住，退的时候也不能把连接池拽崩了。有回我们做秒杀活动，压测全过，结果活动开始五分钟，数据库连接池先满了，因为用户点完"立即购买"发现页面没反应，就拼命刷新，每个刷新都带着一个新的数据库连接请求。最后靠临时加连接数才救回来，但那次教训让我明白，性能测试得模拟"用户急了"的状态，而不是模拟"用户有耐心"的状态。

安全测试更是玄学。你以为SQL注入、XSS脚本这些漏洞早就被堵死了，可黑客的思路永远比你歪。有次我们收到漏洞报告，说某个搜索框能注入恶意代码。开发不信，说参数都转义了。后来一查，是某个第三方统计脚本把搜索词拼进了URL，而那个脚本没做过滤。web测试的边界从来不是自己那摊代码，整个页面加载的东西，包括外部引用的JS、CSS、图片，都可能成为攻击入口。所以我现在看页面，习惯性地按F12打开开发者工具，看看网络请求里都跟谁在通信。

做了这些年web测试，我越发觉得，这活儿最核心的能力其实是"怀疑"。怀疑每个输入框，怀疑每个按钮，怀疑每个跳转逻辑，甚至怀疑自己昨天刚测过的功能今天会不会突然抽风。因为web应用是活的，后端改个配置，前端发个新版本，第三方服务升级个API，都可能引发连锁反应。所以真正的web测试不是某个阶段的动作，而是贯穿整个产品生命周期的习惯——发布后盯着监控数据看半小时，第二天早上再看一眼用户反馈，这比什么测试报告都管用。

说到底，web测试测的不是网页，是人和机器之间的那层薄薄的信任。用户点下去，页面得给他反应；用户填了表单，数据得安全送到服务器；用户收藏了页面，明天打开还得是他要的内容。这信任一旦崩了，想重建可难了。所以啊，干这行，得有点强迫症，还得有点敬畏心——知道每个像素背后都有人在等着，那就不敢糊弄了。

最新评论