上周帮朋友查一个线上故障，应用软页面在iOS Safari上白屏，测试Chrome里却跑得好好的应用软。查了两小时，测试发现是应用软一个CSS Grid的兼容写法在WebKit内核下直接崩了。这种事在Web应用测试里太常见了——你永远不知道下一个坑埋在哪。测试
功能测试是应用软最基础的那层。按钮点下去有没有反应，测试表单提交后数据有没有落库，应用软登录态过期后跳转是测试否正确。听起来简单，应用软但边界条件才是测试真正吃时间的地方。比如一个输入框限制200字，应用软你输入199、测试200、应用软201分别什么表现？粘贴超长文本呢？输入emoji呢？我见过一个系统，前端限制200字，后端限制100字，用户输入150字前端放行，后端直接500错误。这种问题不测边界根本发现不了。
兼容性测试是另一个重灾区。浏览器版本、操作系统、屏幕分辨率、设备型号，组合起来能让你头皮发麻。Chrome 120上正常的flex布局，到了某些国产浏览器里直接错位。更别提微信内置浏览器、钉钉内置浏览器这些魔改内核，它们对API的支持完全是另一套逻辑。我的做法是维护一个设备矩阵，至少覆盖主流机型的最近两个大版本，每次发版前跑一遍核心流程。
性能测试不只是看首页加载时间。你要关注首屏渲染、可交互时间、接口响应延迟、内存泄漏。有个项目上线三个月后越来越慢，排查发现是一个定时器没清理，每次路由切换都新建一个，累积了几百个。这种问题在功能测试阶段完全看不出来，只有长时间运行或者频繁操作才会暴露。Lighthouse跑分可以参考，但真实用户场景下的表现才是关键。
安全测试经常被忽略，直到出事。XSS、CSRF、SQL注入这些老生常谈的东西，实际开发中照样有人踩。我遇到过搜索框直接拼接SQL的，也见过用户输入直接innerHTML渲染的。还有权限校验——前端隐藏了按钮，但接口没做鉴权，改个请求参数就能越权操作。这类问题测试用例里必须覆盖，不能只靠开发自觉。
接口测试是性价比最高的一环。前端页面可能改版十次，但接口契约相对稳定。用Postman或者写自动化脚本，把核心接口的正常、异常、边界情况都跑一遍，能拦住大部分回归问题。特别是微服务架构下，一个接口挂了可能影响好几个页面，接口测试比UI测试更快更准。
用户体验测试听起来虚，但很实际。加载状态有没有骨架屏，错误提示是不是人话，表单校验的时机是否合理。我见过一个注册页面，密码强度校验在输入框失焦后才触发，用户输完密码点提交，突然弹出一堆红字，体验极差。这种问题不需要什么高深技术，但需要测试人员把自己当成真实用户去走一遍流程。
自动化测试要分清场景。UI自动化适合稳定的核心流程，比如登录、下单、支付。频繁改动的页面别做UI自动化，维护成本比收益高。接口自动化可以覆盖得更广，单元测试交给开发自己保证。别为了KPI堆自动化覆盖率，跑得慢、经常误报的自动化脚本还不如没有。
测试这件事，工具和方法论都在其次，关键是有没有把用户可能遇到的场景真正走一遍。代码不会骗人，但人会忽略细节。多问一句“如果这里出错了会怎样”，往往就能提前拦住一个线上事故。