web测试流程

打开一个网页，测程输入用户名密码，试流点击登录，测程页面跳转成功——这背后可能藏着二十个你没想到的试流坑。Web测试就是测程把这些坑一个个找出来，填上，试流再踩一遍确认填实了。测程没有哪款软件是试流天生稳定的，稳定都是测程测出来的。

需求评审会开完，试流测试人员手里应该有一份东西：需求规格说明书。测程别急着写用例，试流先对着它把每个功能点拆开。测程比如“用户可修改头像”这句话，试流拆出来是测程：入口在哪、支持什么格式、文件大小限制、裁剪功能、上传失败怎么提示、修改后其他页面是否同步更新。我见过一个项目，测试只测了上传jpg，上线后用户传了张10MB的png，服务器直接超时。漏掉的不是技术，是拆解需求时的偷懒。

用例设计阶段最怕两种人：一种只写正常流程，一种把所有可能都写成用例。前者漏bug，后者跑断腿。实际工作中，等价类划分和边界值分析是性价比最高的方法。拿登录框来说，用户名长度限制6-18位，那你就测5位、6位、18位、19位，再补一个空值和中文字符。密码框的“显示明文”功能，点一下切换，再点一下切回来，输入框内容不能丢——这种细节用例，才是区分新手和老手的地方。

环境搭建经常被低估。测试环境跟开发环境差一个配置项，结果可能完全不同。数据库版本、缓存策略、第三方接口的mock数据，都得对齐。有次我们测一个支付流程，测试环境一直成功，预发布环境一直失败，查了两小时发现是预发布的回调地址白名单没加。这种问题不是代码bug，但用户会遇到，测试就得管。

执行阶段分两轮比较合理。第一轮叫“冒烟+主流程”，确认核心功能能跑通，别在打不开的页面上浪费时间。第二轮才是全面覆盖，包括异常场景：断网提交表单、重复点击按钮、并发修改同一条数据。我习惯在第二轮里加一个“捣乱测试”——随机点、快速切、乱填数据，经常能撞出一些开发没考虑到的状态问题。

Bug提交有讲究。标题写清楚“在XX页面XX操作下出现XX结果”，别写“有个问题”。描述里附上环境、账号、复现步骤、预期结果和实际结果，截图或录屏能省掉三轮沟通。严重级别要客观：页面错别字是低，数据丢失是高，别把个人情绪带进去。开发修完，一定要回归验证，而且不光验这一个bug，要把相关功能再跑一遍——改A坏B是常态。

回归测试结束后，出一份测试报告。不用长篇大论，说清楚测了什么、没测什么、遗留多少bug、风险在哪。比如“购物车结算功能已覆盖，但优惠券叠加场景因接口未就绪未测试”，这句话比“测试通过”有价值得多。

上线不是终点。灰度期间盯紧日志和监控，用户反馈的每一个“偶尔”都值得追。Web测试没有一劳永逸，只有持续迭代。你放过的每一个小问题，用户都会帮你找回来，而且带着脾气。