自动化测试
自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
个人认为，只要能服务于我们，能够帮助我们提升工作效率的，不管是所谓的自动化工具，还是写个sql脚本、写个批处理、做个小工具等等，都属于自动化范畴。自动化是一个思想，而不是工具。
自动化并非万能，人工测试还是必须的。自动化的目的是验证问题，手工测试的目的是发现问题。完全自动化，抛弃手工测试，这种想法是存在误区的，重复也是一种极致，当你在重复里面找到灵感了，找到快乐了，你就比别人高一个境界。手工测试，自动化测试，业务逻辑能力，测试技术存在一个平衡点。
为什么引入自动测试
直接一点的：就是为了节省人力、时间或硬件资源，提高测试效率，满足版本需求的快速迭代，提升产品测试质量。
自动化测试前提
- 软件需求变动不频繁，相对稳定的功能模块或接口
- 项目周期足够长
- 自动化脚本可重复使用
- 手工测试无法完成的，或者需要投入较大时间人力的
自动化测试的适用性
切入时机
以基本完成软件的程序界面开发、页面控件相对稳定为宜。
适用场景
- 测试时间相对长，且存在大量重复性、机械性手工测试的项目
- 产品型软件，每发布一个新的版本或打补丁都需要对其他模块执行相同的测试
- 项目型软件，需求变更频繁，每变更一次，需要对原有的无争议的功能做测试
- 经常需要更换应用程序部署站点的软件，每更换一次需要对所有功能做验证测试
- 测试时间相对长，且存在大量需要执行回归测试的软件项目
- 系统界面稳定，需要对业务流程进行验证测试的软件
- 采用增量开发持续集成的项目，需要对频繁更新的程序执行验证测试
- 软件项目采用主流开发平台技术，且不存在物理交互的测试
（项目周期长，产品稳定，回归需求量大，手工可替代性强....）
不适用场景
- 项目工期紧、测试周期短的项目不应采取自动化测试
- 界面的美观、产品易用性，兼容性测试不应采取自动化测试
自动化测试过程
自动化测试需求分析》自动化测试框架选型、搭建》自动化测试用例、脚本编写》自动化测试结果分析》版本更新迭代维护、持续集成
自动化分类
UI自动化
维护成本高，受益最小。当然不是说UI自动化没有价值，适当的界面自动化还是有用的。
目前应用较多的场景是在版本发布，可对功能稳定、基本无改动的模块开展UI自动化，从而缩短版本发布周期。
间接的，也让人工测试把重心放在产品的核心业务场景以及改动较大的功能模块上。
接口自动化
维护成本适中，受益适中，可以考虑覆盖大部分业务流程。
现在很多系统前后端架构是分离，后端接口服务开发是先行的，接口层发现问题，可预防和减少UI层的问题。
单元测试
维护成本低，受益最大，价值最大。但是目前基本是开发在做，测试人员参与较少，而且对测试人员要求较高。
自动化的利弊陈述
正如制造工业的情形一样，大家都知道流水线和先进设备有助于提升生产力，但是为什么绝大多数制造工厂又不这么做呢？原因很简单：
- 首次投入成本过于昂贵
- 后期还存在巨大的生产设备维护成本
- 人员素质要求过高
在软件工业的测试行业也同样存在同样的问题，自动化的测试实际上是相当于在功能代码之上，还要投入开发另外一个项目并维护，这样也无法避免的需要耗费宝贵的开发资源。
现在的情形说极端一点就是：
- 做 ”自动化“ 是找死
- 不做 ”自动化“ 是等死
现实一点解读就是：”找死“的不一定死，”等死“的则必然死。 ”找死“ 虽然说是主动寻死，但是这样的人至少还是在想办法求生路，存在成功的可能，”等死“ 则是在消磨和透支自己的时间和机会，只能被动受死。
综上：如果有长远的产品线和长远的眼光，决策者都应该花一定的精力来做 ”自动化“。这里所说的 ”长远“ 是指生产过程需要有足够的量或者时间来收回自动化投入上产生的首次成本