认识达内从这里开始

我们在前几期的文章中给大家简单介绍了软件测试的一些基础知识等内容，而本文我们就继续来学习一下，软件测试都有哪些测试流程。

需求分析

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

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

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

需求评审

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

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

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

测试人员如何在需求评审中发挥价值，参考往期文章「需求评审，测试人员应该发挥怎样的价值?两分钟让你不再懵逼」

测试计划

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

测试用例设计

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

测试用例评审

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

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

开发自测

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

开发自测其实是属于测试左移的部分，关于什么是测试左移可参考往期文章「测试左移和测试右移，我们为何要“上下求索”?」。

提测

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

测试环境部署

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

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

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

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。