每次新人问我软件测试包括哪些步骤的时候，我都懒得搬教科书上死板的定义，毕竟书本知识和实际职场操作，压根就是两码事，去年接手公司内部后台管理系统迭代测试项目时，才算彻底摸透一线测试完整的实操流程。
最开始接手这个需求，脑子压根没有清晰的规划，直接等开发写完代码，就急匆匆打开页面随便点点测功能。现在回想起来，这个做法蠢得离谱，白白浪费大把工作时间，还经常漏测核心功能，被产品和开发反复追责。
前期准备从来都不是可有可无的环节。拿到产品需求文档后，第一件事就是通读全部内容，抠清楚每一个功能的细节、业务逻辑还有边界条件。差不多花半天时间梳理出测试点，再根据测试点编写对应的测试用例，小到输入框的字符限制，大到整体业务流转链路，全部都要覆盖到。
然后就是评审环节。很多初级测试都会忽略这一步，反正我之前做项目时，总觉得写好用例就万事大吉，没必要浪费时间开会评审。直到一次因为需求理解偏差，写的用例和产品预想完全不符，后续全部推翻重写，折腾整整一天才补救回来。后来才反应过来，用例评审能同步产品、开发、测试三方的想法，提前化解需求分歧，能省下后续超多无效工作量。
开发完成代码开发，并且完成自测之后，版本才会提测。这里要提一嘴，之前吃过大亏，接收过未做自测的半成品版本，里面全是低级语法bug、页面空白问题，连基础登录功能都没法正常使用，根本没办法开展正式测试。
提测通过后，就进入正式测试阶段。这个阶段也是整个测试工作里耗时最长的部分，按照之前编写好的测试用例，逐条执行，校验正向流程、反向异常流程以及各类极端场景。
偶尔也会脱离用例，做一些随机性的探索测试。说白了就是抛开固定模板，以普通用户的操作习惯胡乱操作，排查用例之外的隐性bug。发现问题之后，立刻整理bug详情，同步到缺陷管理平台，标注清楚复现步骤、预期结果和实际结果，分配给对应的开发人员修复。
很短的一段话。
等待开发修复完毕，发布新的测试版本后，就要进行回归测试。这一步很多新人容易简化，只复测已经修复的缺陷，忽略原有功能。之前我就因为偷懒，只校验修复的bug，没检查关联模块，最后出现旧功能集体失效的问题，上线前紧急通宵整改。慢慢就养成习惯，每次回归不仅复测已修复问题，还要抽检关联功能、核心基础功能，防止修复旧bug的同时衍生出新问题。
所有缺陷闭环、多轮回归测试没有异常之后，就能编写测试报告，给到项目组所有人。报告会简单记录本次迭代的测试范围、用例执行率、缺陷分布情况以及遗留问题，明确给出版本是否具备上线条件的主观判断。
上线当天也不能直接撒手不管。线上环境和测试环境配置不一样，哪怕测试阶段做的再细致，也有可能出现突发问题。所以版本更新完成后，必须快速完成线上核心链路的巡检，保障用户常用的功能可以正常运行。
忙完整套流程，那天晚上下班，瘫在办公椅上，盯着电脑屏幕里最终的线上系统页面，指尖无意识摩挲着鼠标侧边磨损的纹路，脑子里什么都不想，只想安安静静待一会儿。