先抄一段话，来说什么是自动化测试：Test automation
In software testing,test automationis the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.
本篇文章也不打算总结有多少种测试，他们怎么分类，我们只讲自动化测试…… 上边一段话也讲了什么是自动化测试，简单来讲就是一个操作软件的软件，然后可以对操作的结果进行验证。这里的定义是跟被测软件分离，这个我不是很同意这句话，有些自动化测试是进程内的，需要inject代码来运行测试代码，甚至有些直接类似病毒附加二进制代码并且运行在被测程序的进程内（确实见过一个软件是这么做的，直接改二进制代码然后在进程内运行一个socket server来执行测试）。
既然是一种软件，那我们就简单按照有没有UI，分为非UI和UI的自动化测试程序：
常见的非UI自动化
大部分的Unit Test
API test
Integration Test
...
常见的UI自动化
带UI的Unit Test，比如mock掉底层代码，仅仅测试UI逻辑
带UI的API Test，比如我以前工作过的一个Team是做UI的component的，大部分的API都是跟UI相关的
功能测试。大部分的UI自动化测试是功能测试。或者说是Regression Test（应该是翻译成回归测试吧）
....
我们来看看这两种测试各自的优点：
非UI
简单。测试代码相对容易写，容易调试
运行稳定。除非代码逻辑变化，一般不需要改测试代码。而且不容易受到外在因素影响
好维护。运行稳定，就不需要经常去更新测试代码
运行速度快。一般执行速度比UI的测试要快很多
容易模拟出错情况。构造错误情况比UI操作容易的多
UI
覆盖范围广。简单说，就是不挑食，只要是有UI的程序，只要是支持Accessibility的程序都可以做。
不需要被测程序源代码。比如前边一篇文章的计算器
最大程度模拟用户操作 （有些操作比如用InvokePattern，还是跟用户点击鼠标不太一样，但是我们可以通过模拟鼠标事件来达到完全一样的效果）。这个就浅显易懂了，毕竟用户是用鼠标键盘操作的，不是写代码来用的……
那一般我们怎么去选择用非UI还是UI呢？重要的话说三遍：
能不用UI自动化测试就不用，能不用UI自动化测试就不用，能不用UI自动化测试就不用
这样好像有点自黑，我就是做UI自动化测试和工具的……，那为什么还要黑它呢，主要是UI自动化测试有以下显著缺点：
大部分写UI自动化测试的人员没有丰富的代码经验，甚至有些UI的自动化测试是通过录制回放脚本来完成的。自动化测试代码也是软件代码，应该遵循软件开发从设计开始的所有流程（不仅仅是UI自动化测试代码），这里还是赞同微软的SDET的说法
在整个软件开发过程中，越是底层的代码变动的频率越低。比如底层类的实现和用户界面相比，显然UI变化最频繁，并且最晚稳定下来
为了满足设计的要求，很多程序的UI大量使用了自定义控件，但是又没有遵循微软的Accessibility标准（甚至根本不知道有这个东西）。导致没有任何的自动化测试工具可以操作和获取信息进行测试验证……
UI在Windows各个版本中，显示并不完全一样（从UI自动化测试工具的角度看）
但是，什么东西都是有两面的，虽然有很多的显著缺点，但是也有很多上边列的优点，怎么取舍，怎么样发挥UI自动化测试的优势，我们后边有几篇文章会分别做一些介绍：
反对盲目的UI自动化测试
UI自动化测试开始的时机
反对录制回放脚本
需要考虑UI自动化的投入产出比
UI自动化测试不只是脚本，也需要设计
自动化测试应该从软件设计开始
软件设计需要考虑可测试性(testability)
程序设计需要考虑UI框架
程序设计需要考虑非UI自动化测试
团队需要重视Automation Bug
自动化测试脚本也有维护周期
同步和Sleep的选择
什么是一个好的UI自动化测试用例
尽量不用Sleep
单个验证点和功能封装
除了Pass和Fail，也需要有Error
UI自动化测试并不是只能用UI状态来做验证
自定义控件支持Windows automation api
(海量免费学习资料，软件测试交流：1140267353，还会有同行一起技术交流)
以上仅供参考和借鉴，希望对你有所帮助！
点个关注不迷路
小枫文章整理不易，欢迎各位朋友点赞关注