测试流程步骤

打开测试用例管理工具，测试新建一个文件夹，流程命名规则按“项目名_模块_版本号”来。步骤这一步别偷懒，测试我见过太多人直接扔个“test1”进去，流程两周后自己都找不到。步骤

需求评审会结束那一刻，测试测试就开始了。流程不是步骤等开发提测才动手。拿到PRD文档，测试先通读一遍，流程把模糊的步骤地方标黄。比如“系统应快速响应”这种描述，测试得追着产品经理问清楚：快速是流程500毫秒还是2秒？并发量多少？

写用例的时候，别只写正向流程。步骤登录功能，除了输对账号密码，还得考虑：密码错误三次锁定吗？账号带空格怎么处理？验证码过期后点击刷新，旧验证码还能用吗？这些边界情况才是bug的重灾区。我习惯用Excel画个表格，左边写操作步骤，右边写预期结果，中间留一列记实际结果。执行的时候，通过标绿，失败标红，阻塞标黄。一目了然。

环境准备经常被低估。测试服数据库里没数据，你测个寂寞。提前找运维要权限，自己写SQL造几条脏数据进去。比如用户表里插一个昵称叫“”的记录，看看前端会不会弹窗。这种XSS漏洞，等安全扫描报告出来就晚了。

执行用例不是机械点击。点到第三个步骤发现页面卡住，别急着提bug。先按F12打开控制台，看Network请求返回什么。如果是500错误，截图带上请求参数和响应体。如果是前端报错，把Console的堆栈信息复制下来。开发最烦“点击没反应”这种描述，你给足信息，他改得也快。

缺陷跟踪有个小技巧：标题写清楚“模块_操作_现象”。比如“订单模块_提交订单_点击后按钮置灰但接口未调用”。严重程度别乱标，把“按钮颜色不对”标成致命，测试经理会找你喝茶。优先级看业务影响，支付流程崩溃和帮助页面文字错别字，不是一回事。

回归测试阶段，别只跑失败的那几条用例。修改一个底层工具类，可能影响十几个关联功能。我习惯用Git diff看看开发改了哪些文件，如果动了公共组件，就把相关模块的用例全跑一遍。时间紧的话，至少覆盖核心链路：登录、搜索、下单、支付。

验收测试前，自己先走一遍完整用户旅程。从注册开始，到浏览商品，加购物车，用优惠券，填地址，选支付方式，最后查看订单状态。中间任何一步卡住，都别急着叫产品经理来验。自己先复现三次，确认不是网络抖动或缓存问题。

上线后别关电脑就走。盯着监控面板看半小时。错误日志里有没有新增的Exception？接口平均响应时间有没有突增？数据库连接池是否正常？有一次我下班前扫了一眼，发现某个查询接口的QPS从200掉到20，赶紧回滚。后来查出来是索引没加对。

测试报告不用写太长。三部分够了：测了什么，没测什么，遗留风险是什么。别用“基本功能正常”这种废话。写“登录、下单、支付主流程通过，但优惠券叠加规则未覆盖，因为后端接口尚未就绪”。这样读的人知道边界在哪。

最后说个真事。之前有个项目赶进度，跳过冒烟测试直接跑全量用例。结果开发提测的包连数据库都连不上，三百条用例全阻塞。白白浪费一上午。从那以后，我坚持先花十分钟做冒烟：启动服务，登录，查一条数据。通过了再往下走。

流程是死的，人是活的。小需求可能半天走完，大版本迭代得折腾两周。关键是每一步都留下痕迹——用例、截图、日志、报告。出了问题能回溯，这才是测试流程存在的意义。