其实自动化测试很好理解，由两部分组成，“自动化”和“测试”，所以我们要理解自动化测试，就必须理解“自动化”和“测试”，只有理解了这些概念，才能更轻松的做好的自动化测试。其中“自动化”可以想象成通过各种编程技术实现程序对被测系统可操控的行为，重点在于对“测试”的理解。
1.1 关于测试的理解所以首先作为一个测试人员，先应该思考测试的本质是什么？
大多数从事自动化测试的人都是从手工测试转型过来的，所以对于测试都不会太陌生，那么对于测试工作我们可以简单的认为两种情况：
1,验证被测系统是正确的（即程序按照预期运行，认为做了正确的事情）
2,寻找错误（即程序没有做错误的事情）
我们知道大概所有的测试用例都是按照情况1在编写测试用例，执行，而同样在做着情况2的事情，其中验证正确比较简单，只需要将实际结果和预期结果做比较，
一般只有一件正确的事会发生就只需要验证这件事发生了即可,而寻找错误就比较困难,因为太多不可预知或者偶然性的错误会发生。
所以测试最终的结果就是期望结果，我们可以尝试回顾一下我们平时的日常工作流程
1．分到任务拿到需求,开始理解需求,那么分析需求的目的是什么？
2．学习并了解相关业务知识与工作流程，那么搞清业务流程的目的是什么？
3．当上面的工作完成后，开始设计并编写测试用例，那么设计测试用例的目的是什么？
4．开发完成后开始执行测试用例，那么判断测试用例fail/pass的标准是什么？
所以最后的我们测试目的就是：找出期望结果与实际结果不符的场景
如果理解了这个概念，那么单纯从技术角度上来说，我们的测试要做的最重要的工作就是搞清楚一个软件的功能块的期望结果是什么，
不管用什么方法(UI/API/UT自动化 等等)，只要能把期望结果理解清楚，我们的测试便成功了一大半。
1.2 关于自动化测试的理解我对于自动化测试理解就是测试方法+测试目的(验证结果)，并不局限你使用了什么技术或者框架，但是自动化测试要做的事情与功能测试是一致。
先来看看功能测试如何进行的：
编写测试用例，测试用例当中最主要的是测试步骤和预期结果；测试人员根据测试用例执行操作步骤，然后通过眼睛和思考判断实际结果与预期结果是否相等。如果相等，测试通过；如果不相等，测试失败。
自动化测试本质就是基于功能测试的实现，自动化测试常见主要包含三个层面的自动化，单元测试自动化，接口测试自动化和UI测试自动化。当然，不同层面的自动化关注点是不一样的。
单元测试自动化，调用被测试的类或方法，根据类或方法的参数，传入相应的数据。然后，得到一个返回结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，这里单元测试关注的是代码的实现与逻辑。当然根据不同的测试系统或者软件架构单元测试方法以及技术都不一样，比如我曾经经历过前端js/后台springmvc/oracle数据库层不同层面的单元测试工作
接口测试自动化，根据接口文档，到底是传get请求呢？还是post请呢？调用被测试的接口，构造相应的数据（id=1,name=zhangsan），得到返回值，是200成功，并返回查询结果。还是500，用户名不能为空。不管输入的参数是怎样的，我们都将得到一个结果。最终断言返回的结果是否等于预期结果。如果相等，测试通过；如果不相等，测试失败。所以，接口测试关注的是数据。只要数据正确了，功能就做成大半，剩下的无非是如何把这些数据展示在页面上。
UI测试的自动化，这种测试更贴近用户的行为，模拟用户点击了某个按钮，向个输入框里输入了什么。但是用户可以看到登录成功了，但UI自动化并不知道它刚才的点击有没有生效。所以，要找“证据”，比如，登录成功后页面右上角会显示“欢迎，xxx”。这就是登录成功的有力“证据”。于是，当web自动化登录成功后，就去获取这个数据进行断言。断言如果相等，测试通过；如果不相等，测试失败。所以，web自动化的关注点用户操作形为，页面上真正的按钮和输入框是否可用。
1.3 如何实现自动化测试刚才提到自动化测试本质就是基于功能测试的实现，都是比较实际结果和预期结果是否相符。
其实大概可以分为三个部分：
实际结果：就是我们通过操作获取的实际执行结果，通常所讲的自动化测试的难度，大部分指就是指通过自动化获取实际结果的难度。因为UI层更贴近用户层，所以不管是视觉还是业务处理都相对于其他层更负责，所以往往实施起来难度验证结果很负责，成本更高