软件测试真实企业测试流程-编程知识

最近收到不少准备转行软件测试的小伙伴私信问真实企业里面软件测试流程是什么样子的？

对于这个问题，在面试的时候也是经常会被问到。

关于测试流程，100家公司可能有100套测试流程，但是基本上都是大同小异，完全可以将测试流程形成一套可复用的SOP。

所以，今天我们就来聊聊软件测试的流程。

测试流程

需求分析

产品经理根据用户需求，梳理出需求文档，文档内容包括用户背景、用户需求、产品方案、需求原型、UI设计图（UI设计师填写）、技术方案（开发经理填写）、接口文档（开发人员填写）等信息。

我们需要提前阅读相关文档，深刻理解需求，对于有疑问的点提前进行标注，以便于在之后的需求评审会议上抛出疑问点。

阅读需求文档的时候，除了关注功能要求之外，还需要关注用户背景，站在用户的角度思考问题，以判断需求是否真正符合用户需求，避免交付到用户手上时发现不是用户想要的效果，还需要关注数据类型、接口定义、性能要求、安全性等，根据具体业务进行评估即可，同时还需要考虑一些隐性需求。

需求评审

产品经理给到需求文档后，会召集一个需求评审会议，参加评审的一般有产品经理、开发人员、测试leader或对应需求的测试人员。

在需求评审时不仅要了解需求，还要评估需求的质量，分析需求的完整性以及合理性，及时发现需求和设计中的问题，抛出疑问给产品经理，并得到相应的解决。

思考需求中的测试点、测试场景等，便于之后测试用例的设计和编写。

测试人员如何在需求评审中发挥价值

测试计划

需求评审完成之后，大家都没什么问题了，测试Leader会给出测试计划，测试计划主要叙述了预定的测试活动范围（哪些模块）、测试人员、测试资源（软件、硬件）、进度安排（预计提测时间、测试用例所需工作日、一轮测试所需时间、二轮测试所需时间、预计测试完成时间）以及风险时间（提测质量低或其他因素引起测试时间增加）等。

测试用例设计

测试人员根据需求文档和原型图等进行测试用例的设计和编写，用例格式有很多种，比如：Excel、XMind、Testlink等。有的要求完整的测试用例，有的只需要列出测试点即可，根据公司实际要求进行即可。

测试用例评审

测试用例编写完成之后，会进行用例的评审，主要是检查里面有没有什么问题，或者跟需求文档有误的点，以及是否有未考虑到的测试点。

整个到这个阶段，开发人员也差不多开发完成了。

开发自测

让开发加强单元测试，测试人员通过提供测试用例或自动化测试脚本的方式给开发，让开发在设计时考虑更全面，同时方便开发自测，有助于提高产品质量，避免在收到提测包时冒烟测试主流程都没通过，导致测试效率低下。

开发自测其实是属于测试左移的部分，关于什么是测试左移可参考往期文章

提测

开发自测完成后正式提测，由开发人员将代码推到相应的Git分支。

测试环境部署

测试环境部署可能是运维人员、开发人员、或测试人员。

操作系统一般是Linux或Windows；用到的一些容器技术，例如：Docker、Kubernetes；数据库可能是MySQL、SqlServer、Oracle、人大金仓数据库、达梦数据库、神通数据库、Redis缓存等，其中可能还有用到一些中间件，例如：Web中间件Nginx、消息队列MQ、Kafka等。

不过现在很多公司都有一套持续集成和持续部署平台，只需开发人员将代码提交到相应的分支，就能触发其自动部署更新。

冒烟测试

测试环境部署完成之后，需要先进行冒烟测试。

冒烟测试就是针对每次版本或每次需求变更之后，在正式测试之前，对产品或系统的一次简单验证性测试。验证产品或系统的基本功能、主流程是否正常。可以将冒烟测试理解为是在执行正式测试之前的“预测试”，目的是确认软件的基本功能正常，可以进行后续的测试工作。如果这个版本的冒烟测试都没通过，后面就不用继续测试了，直接打回给开发人员，待冒烟能通过后再提测。

需关注的点：