1、把人的操作转化成脚本或机器执行，通过一套流程性的测试用例，由脚本或机器按照测试用例的执行步骤对其进行自动操作，输出结果，然后进行结果分析。
2、自动化测试往往通过一些测试工具或框架，来自动执行的，编写自动化测试用例，来模拟手工测试。
3、自动化测试能极大的节省人力、时间和硬件资源，提高测试效率。
1、自动化测试工具可以根据你要测试的需要，准备测试用例。
2、节约成本，进行版本功能回归测试。
3、测试结果通过自动化对比，可以自动进行结果校验，人工干预只要看那些错误的结果。
4、可以对大量数据或数据格式进行快速比对。
1、相比手工测试，自动化测试对测试人员的能力要求相对较高。
2、自动化测试用例需要根据版本迭代进行更新，有一定维护成本。
3、不要指望自动化测试去发现更多新的BUG，自动化测试能发现的缺陷远远比手工测试的少。。
4、自动化测试并不能完全代替手工，其实很多的业务逻辑测试都需要手工。
5、自动化测试不能提高测试的有效性，只能用于提高测试的效率。
1、自动化测试对有些测试比如：本地化测试、用户体验测试、探索性测试，测试环境搭建方面并不能完全代替手工测试。
2、需要我们对产品需求、功能点、测试点要很熟悉，要有一定的手工测试基础，自动化测试和手动测试相辅相成。
3、自动化测试并不仅指自动化运行测试产品，还包括参数化、数据准备、结果自动校验环节。
1、测试需求分析：总体把握系统架构和设计，分析出系统的测试需求。
2、设计：设计测试用例(包括数据准备、预期结果等)，并且挑选出需要自动化实现的测试用例。
3、实现：编写、调试和实现测试脚本，生成报告。
4、执行：执行脚本的过程，需要不断分析执行过程中的异常。
5、测试结果分析：分析哪些是Bug，哪些是运行过程中出现的问题。
6、维护：自动化测试脚本维护是一个难以解决又必须要解决的问题。
7、总结：在自动化测试过程中总结自动化实践的投入产出比。
自动化测试工具开发语言：Java、Python、Golang等
基础测试工具
（1）单元测试：junit（java）、unittest（python）、pytest（python）
（2）接口测试：httpclient（java）、restassured（java）、request（python）
（3）UI测试：selenium （ web ）、appium（app）、uiautomator（app）
常见自动化测试工具
（1）接口测试：Jmeter、soapui、postman
（2）UI测试：katalon、Robotframework、appium、atx
自动化测试脚本技术
1、线性脚本：录制、回放
2、结构化脚本：含有控制脚本执行的指令，支持顺序、选择和循环。共享脚本：可以被多个测试用例使用，脚本之间可以互相调用
3、数据驱动脚本：数据驱动脚本是将测试输入存储在独立的文件中，脚本中只存放控制信息
4、关键字驱动脚本：关键字驱动脚本实际上是较重复的数据驱动技术的逻辑扩展 ，即测试用例的执行步骤（操作，操作对象，操作值）存放在文件中，直接执行。
1、在PO模式中抽象封装成一个BasePage类，该基类拥有一个只实现webdriver实例的属性
2、每一个page都继承BasePage，通过driver来管理本page中元素，将page中的操作封装成一个个的方法TestCase依赖page类，实现相应的测试步骤。
1、关键字驱动
（1）将测试用例分成四个不同的部分。首先是测试步骤（Test Step），二是测试步骤中的对象（Test Object），三是测试对象执行的动作(Action)，四是测试对象需要的数据（Test Data）。
（2）将数据与关键字结合来描述如何执行测试。也就是将测试用例脚本中的步骤提取出来，放在独立的数据文件中，变成简单编写的方式。这种方法具备数据驱动的优势，同时非编程人员也能建立测试。
（3）关键字驱动的模式是建立在数据驱动手段之上，关键字驱动文件包含指令 (关键词)，而不只是数据。
（4）这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。
2、数据驱动
（1）从某个数据文件(例如Excel文件、Xml文件、Json文件、数据库等)中读取输入测试数据，然后通过变量传入编写的测试脚本中。
（2）数据文件的读取、测试状态和所有测试步骤都被编写进测试脚本里；测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数据的机制。
（3）数据驱动的方法主要用于需要通过不同数据来保证测试覆盖率的场景，比如被测系统业务逻辑固定不变或变动较小，即测试用例步骤是固定的，但是所需要的测试数据是变化的情况，通常来说，数据都是保存在外面文件或数据库中，运行时自动获取。即测试框架中要支持数，据与脚本分离，一个测试脚本可以驱动执行多个相似测试场景。
（4）这个框架意图减少需要执行所有测试用例所需要的总的测试脚本数，数据驱动需要很少的代码来产生大量的测试用例。
（1）选择测试模块
（2）选择自动化的用例（主流程用例）
（3）按页面编写操作方法
（4）按用例编写用例流程脚本
（5）按用例编写数据查询方法
（6）执行用例
（7）输出报告（后期扩展，增加执行日志和异常截图以便跟踪缺陷）。
综上，当脚本内容编写结束并且业务需求和测试需求均无更改的时候，执行后两步操作即可。查看报告内容，如发现缺陷，需按用例内容重现缺陷并提交至禅道管理系统。
（1）业务需求变更
当业务需求变更时，应在执行用例时越过变更内容用例，变更内容上线后按需求变更内容对脚本及用例进行相应调整。调整结束，需再次执行确保用例稳定。
（2）被测模块重构
当被测模块重构完成时，需执行该模块自动化测试用例，查看是否正常执行，若无问题出现则不需调整，若出现问题需及时调试解决。
（3）技术变更
随着自动化测试框架的不断调优、扩展功能，基础模块和封装的页面等也会随之变化。进而，自动化测试需要定期执行，以保证调优、扩展后框架的稳定性，从而达到保障回归测试的正常进行。
1、搭建基础版框架，完成一个模块的自动化测试demo
采用Page Object设计模式，对页面元素，用例流程，数据进行封装隔离，在通用模块或基础模块中对webdriver进行二次封装，自动生成测试报告以便分析自动化测试执行结果。
2、按基础版框架，扩展测试范围
选取适合做自动化测试的功能模块，按基础框架思路编写脚本、用例等，然后对框架做扩展，实现数据驱动、定时执行测试，发送报告邮件等便于使用的非核心功能。
3、覆盖大多数模块的回归测试
根据人员等资源的协调情况，将自动化测试用例扩展至覆盖大部分模块回归测试的程度。由执行自动化测试完成回归测试，以达到提高回归测试的效率，降低回归测试人力要求的目的。
自动化测试技术现在是做测试的必备技能了，现在越来越卷的互联网行业，只有不断的学习才能让我们立于不败之地。
别在最好的年纪选择了懒惰。
我的自动化测试开发之路，一路走来都离不每个阶段的计划，因为自己喜欢规划和总结，想要学习交流的同学，+Q群612756061、、