|
导语：有些Bug，功能上没问题，性能上没问题，但在真实用户环境中却暴露了问题。本文分享几个”看起来没问题”的Web Bug，以及如何发现它们 |
做Web测试久了，你会发现一个现象：有些Bug在测试环境”一切正常”，到了生产环境却出问题了。不是功能Bug，不是性能Bug，而是那些“看起来没问题”的隐蔽Bug。
这篇文章，我分享几个真实遇到的案例。
一、跨浏览器兼容：你的页面在Safari上崩了
|
|
案例1：日期选择器在Safari上无法使用场景：用户反馈在iPhone上无法选择日期，点击日期选择器没反应。 排查过程：
为什么漏测：测试同学主要用Chrome测试，没有覆盖Safari。而Safari在移动端（iPhone）占有率很高 |
兼容性测试建议：
ChromeFirefoxSafariEdgeIE11（如需支持）
尤其注意Safari（Mac和iOS），很多JavaScript API在Safari上的行为与其他浏览器不同。
二、缓存问题：数据”脏”了
|
|
案例2：用户看到的是”旧数据”场景：用户修改了个人信息，刷新页面后，显示的还是修改前的信息。 排查过程：
为什么漏测：测试时每次都强制刷新（Ctrl+F5），绕过了缓存。真实用户是普通刷新，触发了缓存 |
缓存测试要点：
-
普通刷新（F5）vs 强制刷新（Ctrl+F5） -
后退前进时，数据是否刷新 -
修改数据后，列表页是否同步更新 -
接口是否正确设置了缓存策略（Cache-Control、ETag等）
三、前端校验绕过：后端没防住
|
|
案例3：前端限制被绕过，后端没校验场景：表单限制用户名只能输入字母和数字，但有用户创建了含特殊字符的用户名。 排查过程：
为什么漏测：只测了前端校验，没有验证后端是否也有校验 |
校验测试原则：
前端校验是用户体验，后端校验是安全保障。两者缺一不可。测试时，要分别验证前端校验和后端校验。
测试方法：
-
前端校验：在页面上输入各种非法值，验证是否被拦截 -
后端校验：通过接口工具（Postman、curl）直接发请求，绕过前端，验证后端是否拦截
四、时区问题：你的时间”对不上”
|
|
案例4：海外用户看到的时间不对场景：系统部署在国内，海外用户反馈显示的时间与实际时间差了几个小时。 排查过程：
为什么漏测：测试同学的电脑时区与服务器时区一致，没有发现问题 |
时区测试要点：
-
修改本机时区，验证时间显示是否正确 -
跨时区场景：用户在不同时区登录，时间是否一致 -
夏令时：涉及夏令时的地区，时间切换是否正确
五、并发操作：两个人同时改一条数据
|
|
案例5：两个人的修改互相覆盖场景：两个运营人员同时编辑同一篇文章，A先保存，B后保存，A的修改被B的覆盖了。 排查过程：
为什么漏测：单用户测试，没有模拟多用户并发操作的场景 |
并发测试方法：
-
两个浏览器窗口，同时编辑同一数据 -
两个用户账号，同时操作同一资源 -
使用工具模拟并发请求（JMeter、Postman Runner）
六、如何发现”隐蔽Bug”
这些Bug有个共同特点：在常规测试中很难发现。那如何提高发现率呢？
1. 扩大测试环境
-
多浏览器测试：至少覆盖Chrome、Firefox、Safari -
多设备测试：PC、手机、平板 -
多网络环境：正常网络、弱网、断网重连
2. 模拟真实用户行为
-
不要总是强制刷新，试试普通刷新 -
不要总是用管理员账号，试试普通用户 -
不要总是从首页进入，试试直接访问内页
3. 绕过前端直接测后端
-
用接口工具直接发请求，验证后端校验 -
修改请求参数，测试各种边界情况 -
绕过前端逻辑，测试后端容错性
4. 探索性测试
-
不按套路出牌：乱点、快点、来回切换 -
制造异常：断网、关机、清除缓存 -
组合操作：同时打开多个窗口、同时操作多个功能
七、写在最后
“看起来没问题”的Bug，往往是最难发现的Bug。它们不在功能路径上，而在各种边界条件、异常场景、环境差异中。
作为测试工程师，我们需要：
- 跳出常规：
不要只测”正常路径”，多测”异常路径” - 模拟真实：
尽量模拟用户的真实环境和使用习惯 - 保持敏感：
对任何”奇怪”的现象保持警觉
总结：Web测试不只是测功能，还要测兼容、测缓存、测并发、测时区、测各种”没想到”的场景。Bug往往就藏在这些”看起来没问题”的地方
