web测试和普通软件测试看着像，试点实则差得远。试点你测一个桌面计算器，试点输入输出全在本地，试点逻辑对了就行。试点但web应用活在浏览器里，试点背后还挂着一大堆服务器、试点数据库、试点第三方接口。试点任何一个环节抖动，试点用户看到的试点可能就是白屏或者转圈圈。

功能测试只是试点底线，真正的试点坑往往藏在别处。我见过一个团队，试点功能测了三轮，试点上线当天用户一多，页面直接卡死——他们压根没做并发测试。web测试的第一要义是：别只盯着“能不能用”，要盯“多少人同时用还能不能用”。这跟线下店一样，一个人试衣服和一百个人抢试衣间，完全是两码事。

浏览器兼容性也是老生常谈，但很多人测得太敷衍。Chrome没问题就以为万事大吉，结果用户用Safari打开，布局全乱。别光测最新版，旧版Edge、国产浏览器内核、手机自带浏览器，都得跑一遍。有个偷懒的法子：用云测平台跑自动化截图对比，比手动一个个开省力得多。

网络环境更是个隐形炸弹。办公室内网测得好好的，用户在地铁里用4G打开，图片加载一半就挂了。你得模拟弱网、断网重连、慢速3G这些场景。Chrome开发者工具里能直接调网络速度，别嫌麻烦，这一步能筛掉不少“网络差就白屏”的烂体验。

还有状态管理，web应用尤其容易在这翻车。用户点了后退按钮，页面数据还是旧的；刷新一下，登录状态丢了；开两个标签页操作同一个表单，提交时互相覆盖。这些都得专门测。记住一个原则：任何用户操作路径，都要考虑“刷新、后退、关闭、重复点击”的后果。

安全测试别全指望安全团队，基础的自测得做。比如URL里直接传参数改ID就能看别人订单，这种越权漏洞，开发经常漏。你用两个账号交叉测一下，一个改数据，另一个看是否受影响，很快就能暴露问题。SQL注入、XSS脚本这些，至少得知道怎么用工具扫一遍。

性能测试不是等快上线才做。开发过程中就该时不时压一下接口，看看响应时间有没有恶化。我习惯用JMeter写个简单的并发脚本，跑50个线程看错误率，超过1%就得回去查代码。别等到全做完了再查，那时候定位问题成本高得离谱。

最后说点别人很少提的——cookie和session的时效性。用户登录后放着不动半小时，再操作时session过期了，你的应用是提示重新登录还是直接报500？很多web应用挂在这。测试时要故意等session超时再操作，看看提示是否友好，数据是否还在。

web测试说白了就是“多环境、多用户、多状态”的排列组合。别想一口气全覆盖，用优先级思维：核心流程、高并发入口、弱网场景、安全边界，先搞定这四个，剩下的边角料慢慢补。记住，用户不会按你的测试用例操作，他们总会有你意想不到的姿势点坏你的页面。