自动化软件测试，和功能测试相同的地方在于，我们同样需要先分析项目的需求，编写对应的对应的测试用例（符合自动化测试需求的测试用例条件）。

两者的不同点在于自动化测试，需要根据测试需求搭建对应的自动化软件测试框架，再设计出详细的自动化测试执行脚本（也就是通过测试开发工程师开发出来的自动化测试工具和框架），然后输入我们预先设计好的测试用例，有自动化测试框架和脚本完成对程序的各项测试项目的检测。接下来，测试猿课堂就为大家详细介绍一下自动化软件测试的基本流程。

▶ PS：300G软测学习资料包，点击免费领取

分享一波：测试猿课堂为大家准备了一份总量达300G左右的【软件测试全套自学教程】
包含了完整的课件 PPT 实战项目源码 千套测试模板，内容极其珍贵，千万不要错过：

https://pan.baidu.com/s/10nqKV0Vp23BSgCiCt9EqNA

提取码：3mkj

什么是测试计划？说白了就是在测试项目开始之前，我们根据初步的测试方向、测试规模等情况，做出一个详细的测试计划。比如测试项目、测试的具体内容、需要使用到哪些测试方法、配备多少人力等等。设计测试计划的主要目的就是为了后续的测试流程能够更系统化的进行，提高测试部门的工作效率。

分析项目需求的主要目的在于掌握软件测试的设计初衷。通过分析项目需求，我们能掌握最终的测试点、测试方向等。项目需求的分析，需要我们设计"需求树"，根据需求树，我们设计出的测试用例才能够更好的全面覆盖项目的所有需求。举个例子，根据WebUI界面方面的测试，我们一般会从以下几个点出发来分析项目的需求：

1、界面的超链接测试，测试页面中各个跳转链接，能否正常抵达对象页面；

2、界面的各项控件测试，测试页面中各个控件能否正常运行，运行后是否能达到预期效果；

3、界面的各项功能测试，测试页面中常见的功能是否正常，比如交互功能、留言咨询功能、登录注册功能等；

4、界面的数据处理测试，测试页面中需要调用后台接口数据的地方是否精确可靠、显示的数据内容是否准确无误；

测试用例是软件测试的所有流程中比较重要的环节，测试用例的设计因人而异，当然经验更丰富一些的测试工程师，自然能设计出覆盖需求更完善的测试用例。执行自动化软件测试，并非所有的测试用例都能通过自动化执行，所以对于能够通过自动化执行测试的用例，我们需要做相应的用例归类和汇总，再根据测试系统的复杂程度，将系统中可能存在的关键信息（用户名、密码、客户数据、交易数据、后台数据等等）

测试环境指的是一套完整的系统构成，包括软件和硬件，两者相结合才能执行自动化测试。例如Web自动化测试环境，就需服务器、Python、Selnium框架以及浏览器等。常见的测试环境部署模式以LNMT为例，需要Linux系统 Nginx环境 Mysql数据库 Tomcat集群。

对于软件测试工程师来说，必须要掌握完整的测试环境搭建方法，并且要明白各个工具的具体作用，各个模块之间的联系是怎样的。

我们会根据前面设计的自动化测试用例和测试项目的难易程度，开发对应的自动化测试脚本。可以采用录制的方法获取执行测试需要的页面控件，最后通过结构化语句，实现自动化测试脚本的运行，插入相应的测试数据和异常判定的反馈通道，将一些可通用的测试功能设计为可共享使用的通用脚本。

脚本编写完毕后，测试工程师需要反复校验和调试脚本的运营情况，对一些不完善的点重新编写或设计，直到整个脚本能完成全部测试需求为止。

为了能尽早的发现软件缺陷，测试工程师需要每天定时对测试结果进行分析，并且对自动化测试平台反馈出的异常数据进行特定的分析，找出真正的程序缺陷并予以记录。判定缺陷的类型，并交予开发人员修复和完善。如果异常数据不是缺陷，就要考虑是否自动化测试脚本的设计或运行有问题，或者是搭建的测试环境不完善导出出现异常测试结果，并修复对应的漏洞。

关于测试平台这一块，很多企业使用的测试平台都是市面上的开源自动化工具。而作为高级测试工程师，我们的职责就是对开源工具进行二次开发，根据我们企业的项目特性对开源工具进行整改、完善和拓展，使其更适合我们产品的测试。

这一步其实就是软件测试中的回归测试。当我们通过以上步骤检测到程序中的缺陷，并交由开发人员进行修复，但并不代表这一缺陷已经彻底修复。我们依然需要针对该缺陷进行二次甚至多次重复测试。如果该缺陷依然存在，或者因为该缺陷的修复引发了其他的BUG，则要交由开发人员继续修复。

一般情况下，如果我们的项目需求一直很稳定，就不需要对自动化测试脚本进行改动。但如果项目有功能的迭代和系统更新，就需要根据系统新增功能的特点考虑是否要针对该功能进行深度的功能需求分析、设计对应的自动化测试用例、开发和完善特定的测试脚本。