“阅读本文大概需要6分钟。
你好，我是测试蔡坨坨。
最近收到不少准备转行软件测试的小伙伴私信问真实企业里面软件测试流程是什么样子的？
对于这个问题，在面试的时候也是经常会被问到。
关于测试流程，100家公司可能有100套测试流程，但是基本上都是大同小异，完全可以将测试流程形成一套可复用的SOP。
所以，今天我们就来聊聊软件测试的流程。
测试流程
需求分析
产品经理根据用户需求，梳理出需求文档，文档内容包括用户背景、用户需求、产品方案、需求原型、UI设计图（UI设计师填写）、技术方案（开发经理填写）、接口文档（开发人员填写）等信息。
我们需要提前阅读相关文档，深刻理解需求，对于有疑问的点提前进行标注，以便于在之后的需求评审会议上抛出疑问点。
阅读需求文档的时候，除了关注功能要求之外，还需要关注用户背景，站在用户的角度思考问题，以判断需求是否真正符合用户需求，避免交付到用户手上时发现不是用户想要的效果，还需要关注数据类型、接口定义、性能要求、安全性等，根据具体业务进行评估即可，同时还需要考虑一些隐性需求。
需求评审
产品经理给到需求文档后，会召集一个需求评审会议，参加评审的一般有产品经理、开发人员、测试leader或对应需求的测试人员。
在需求评审时不仅要了解需求，还要评估需求的质量，分析需求的完整性以及合理性，及时发现需求和设计中的问题，抛出疑问给产品经理，并得到相应的解决。
思考需求中的测试点、测试场景等，便于之后测试用例的设计和编写。
测试人员如何在需求评审中发挥价值，参考往期文章「需求评审，测试人员应该发挥怎样的价值？两分钟让你不再懵逼」
测试计划
需求评审完成之后，大家都没什么问题了，测试Leader会给出测试计划，测试计划主要叙述了预定的测试活动范围（哪些模块）、测试人员、测试资源（软件、硬件）、进度安排（预计提测时间、测试用例所需工作日、一轮测试所需时间、二轮测试所需时间、预计测试完成时间）以及风险时间（提测质量低或其他因素引起测试时间增加）等。
测试用例设计
测试人员根据需求文档和原型图等进行测试用例的设计和编写，用例格式有很多种，比如：Excel、XMind、Testlink等。有的要求完整的测试用例，有的只需要列出测试点即可，根据公司实际要求进行即可。
测试用例评审
测试用例编写完成之后，会进行用例的评审，主要是检查里面有没有什么问题，或者跟需求文档有误的点，以及是否有未考虑到的测试点。
整个到这个阶段，开发人员也差不多开发完成了。
开发自测
让开发加强单元测试，测试人员通过提供测试用例或自动化测试脚本的方式给开发，让开发在设计时考虑更全面，同时方便开发自测，有助于提高产品质量，避免在收到提测包时冒烟测试主流程都没通过，导致测试效率低下。
开发自测其实是属于测试左移的部分，关于什么是测试左移可参考往期文章「测试左移和测试右移，我们为何要“上下求索”？」。
提测
开发自测完成后正式提测，由开发人员将代码推到相应的Git分支。
测试环境部署
测试环境部署可能是运维人员、开发人员、或测试人员。
操作系统一般是Linux或Windows；用到的一些容器技术，例如：Docker、Kubernetes；数据库可能是MySQL、SqlServer、Oracle、人大金仓数据库、达梦数据库、神通数据库、Redis缓存等，其中可能还有用到一些中间件，例如：Web中间件Nginx、消息队列MQ、Kafka等。
不过现在很多公司都有一套持续集成和持续部署平台，只需开发人员将代码提交到相应的分支，就能触发其自动部署更新。
冒烟测试
测试环境部署完成之后，需要先进行冒烟测试。
冒烟测试就是针对每次版本或每次需求变更之后，在正式测试之前，对产品或系统的一次简单验证性测试。验证产品或系统的基本功能、主流程是否正常。可以将冒烟测试理解为是在执行正式测试之前的“预测试”，目的是确认软件的基本功能正常，可以进行后续的测试工作。如果这个版本的冒烟测试都没通过，后面就不用继续测试了，直接打回给开发人员，待冒烟能通过后再提测。
需关注的点：
- 系统的基本功能可以正常使用，避免新功能导致系统原本功能无法使用
- 本次迭代需求的主流程可以跑通
前面开发自测是目的也是为了更快地通过冒烟测试，有了开发自测，提测的质量会大大提高，原本可能需要花费一天时间冒烟的功能很快就能通过。
执行测试
按照之前编写的测试用例进行测试，测试过程中可能会发现之前遗漏的场景，这时需要补充完善测试点。还可能发现一些实际效果与产品原型不一致的地方，这时就需要跟开发、产品等人员进行沟通。
提交Bug并跟踪
测试过程中发现软件的缺陷，提交到相应的缺陷管理平台并指派给对应的开发人员，例如：Jira、禅道等。
对Bug进行跟进，若开发人员未及时修复，应适当催促，避免项目都要上线了，还有很多Bug未修复，影响交付，甚至延期。
待开发修复完Bug并提交新代码后，对Bug进行回归验证，若测试通过则将Bug关闭，若测试未通过则重新打开。
二轮测试、N轮测试
对新功能进行多轮测试。
回归测试
对旧功能进行回归测试，保证旧功能不被新功能影响而出现严重的Bug。
这个阶段就可以用到自动化测试，实现快速回归。
例如：结合公司业务实现一套覆盖公司系统绝大部分接口的接口自动化测试框架，在上线前跑一遍，以便于测试人员第一时间发现问题，并提交给开发人员进行修复解决，减少线上Bug率；对于有些功能是在前端做校验，无法通过接口进行回归，又是主功能，就可以将其实现UI自动化。
接口自动化框架和UI自动化框架框架搭建可参考往期文章：
「五分钟学会接口自动化测试框架」
「五分钟搞懂POM设计模式」
测试报告
输出测试报告，测试报告内容包括测试范围、测试人员、时间、功能、测试环境（服务端硬件环境、客户端软件环境）；测试过程评估，测试总体评估、用例统计、测试用例执行情况分析、测试对象质量评估；项目测试总结及建议。
产品经理验收
产品经理对测试完成的软件系统进行验收。
项目上线
发布上线。
上线之后可能需要对线上环境进行跟踪，属于测试右移的内容，关于什么是测试右移参考往期文章「测试左移和测试右移，我们为何要“上下求索”？」。
以上，完。
脚踏实地，仰望星空，和坨坨一起学习软件测试，升职加薪！
