什么是自动化测试
通过将测试执行部分或者全部交由程序执行的一种测试，叫做自动化测试。自动化测试不需要人的实时参与。对于控制成本，保障质量和缩短测试周期都有积极影响。同时，自动化测试在小规模应用时会比手动测试昂贵很多。
自动化测试从来都不是用来发现问题的，它更多的是用来验证原有功能是没问题的，新的修改对原有代码逻辑没有影响。所以，当一个项目相对稳定之后，以后的项目都是基于原有代码进行迭代，这个时候自动化的介入是非常有效的。
自动化测试是为了让测试人员从繁琐重复的机械式测试过程中解脱出来，把时间和精力投入到自动化难以覆盖的地方，从而发现更多的产品缺陷。例如某个用例需要有大量的输入项，做手工测试比较繁琐，我们就可以引入自动化的手段做局部的自动化。再比如，验证某个用户登录1000次是否能够登录成功，这种情况使用手工的方式基本是不可能的。
目前自动化测试更多的是定位在冒烟测试和回归测试，冒烟测试执行的是主要功能点的用例。回归测试执行全部或部分的测试用例。它的主要目的在于验证问题，而不是发现问题。所以对于自动化测试的设计，主要集中在功能正确性方面。
自动化测试面临的最大挑战就是变化，因为变化会导致测试用例运行失败，所以需要对自动化脚本不断debug，如何控制成本、降低成本是对自动化测试人员能力的挑战。
什么是自动化测试工程师
自动化测试工程师要有一定的开发能力，要能写一些独立的测试脚本甚至测试工具。并能在实际工作中紧密结合起来，解决工作中遇到的问题。只会使用自动化测试工具不能够称之为完全的自动化测试人员。
自动化测试工程师会从成本的角度去考虑问题。他所做的一切是为了减少自己或者团队的工作量，尽可能的将重复的，有规律可循的工作自动化。
没有开发能力的测试人员虽然也可以做一些所谓的自动化，但是仅仅是一些皮毛，没有办法做到活学活用。根据某机构的调查数据，目前所有从事测试工作的人中，90%的人都没有任何开发能力。根据目前的市场行情，如果在精通一门开发语言，能够从纯手工测试转型为自动化测试工程师，月薪至少增加3~5k。
手工测试与自动化测试的区别
1、手工测试
a、能通过人为的逻辑判断校验当前步骤的功能实现是否正确，能较好的处理异常场景。
b、执行测试用例具备一定的跳跃能力。
c、手工测试可以步步跟踪分析，能够细致的定位问题。
d、手工测试主要用来发现产品缺陷。
2、自动化测试
a、所有的判断校验都需要编写脚本来实现。
b、测试用例步骤之间需要关联关系。
c、主要用来保证产品主体功能正确完整和让测试人员从繁琐重复的工作中解脱出来。
d、目前自动化测试阶段定位在冒烟测试和回归测试。
自动化测试的优点
1、通过自动化测试脚本执行测试，减少回归测试时间；
2、执行手工测试困难，或不可能做的测试，（模拟多个用户并发测试）；
3、更好的利用资源（将繁琐的任务自动化，可以利用非工作时间进行自动化测试）；
4、测试具有一致性和可重复性，（可以在不同的配置环境下重复多次相同的测试）；
5、缩短测试周期。
自动化测试的局限
1、自动化测试发现的bug较少，不能完全取代手工测试；
2、测试脚本本身不具有想象力；
3、自动化测试只能检查一些比较主要的问题，如崩溃、死机，有些错误通过人眼很容易找到，但机器却往往找不到；
4、自动化测试中编写测试脚本工作量也很大，有时候该工作量甚至超过了手工测试的时间；
5、对产品开发质量的依赖性极大。
自动化测试准则
并不是将测试用例代码化了，就可以称之为自动化测试了。自动化代码有很多的要求，概括出以下几点；
第一就是测试覆盖面要够广，个位数用例的自动化意义不大；
第二就是测试用例必须要能够复用，软件每天都在变，如果测试用例要天天跟着软件变，那这个测试用例是完全不合格的；
第三就是测试的规模要够大：要么时间长（用例多或者是压力测试），要么测试产品多，这样才能体现出来自动化测试的优势。
第四就是要提高测试质量，不仅仅包括测试执行的质量，还包括测试的统计质量，数据回溯质量，等等。这些质量的提高可以帮助测试团队修正他们的测试方法，而不是每天将精力铺在无止境的数据收集和分析中。
第五就是要抢出时间，某一项工作自动化后的时间，要么比人手做时间短，要么可以在非工作时间以定时任务的方法进行。
第六就是不要盲目追求自动化，要在自动化测试和手工测试之间找到平衡点，互补完成任务，根据产品目标按时保证质量才是关键。
自动化测试项目的流程
（1）需求概述
（2）制定自动化测试计划
（3）自动化测试方案设计
（4）自动化测试用例设计
（5）自动化测试脚本开发
（6）自动化测试执行和生成报告
自动化测试条件
如上图所示，真正工作中无法全部满足以上条件，所以需要作权衡考虑，一般来说，只需要满足以下几点，就可以对项目开展自动化测试（图中红色框标注的选项）：
①需求稳定，不会频繁变更
自动化测试最大的挑战就是需求的变化，而自动化脚本本身就需要修改、扩展、debug，去适应新的功能，如果投入产出比太低，那么自动化测试也失去了其价值和意义；
折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分用手工测试；
②多平台运行，组合遍历型、大量的重复任务
测试数据、测试用例、自动化脚本的复用性和移植性较强，降低成本，提高效率和价值；
③软件维护周期长，有生命力
自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了；
④被测系统开发较为规范，可测试性强
主要出于这几点考虑：被测试系统的架构差异、测试技术和工具的适应性、测试人员的能力能否设计开发出适应差异的自动化测试框架；
自动化测试分类
一般来说，自动化测试有三个层级分类：单元测试、接口测试和UI测试，这三层成一个金字塔形状分布。最底层是单元测试，接口测试在中间，UI测试在最上层，如下图所示。
下面通过一个表格来对比这三层自动化测试。
性价比：按照测试金字塔模型以及投入/产出比，越向下，回报率越高，最适合做自动化的是单元测试层，而UI层则不是十分适合进行自动化。
Google的自动化分层投入占比
小测试（Unit）：占比70%；
中测试（Service）：占比20%；
大测试（UI）：占比10%；
单元测试
单元测试的收益最高，大多数单元测试都是由研发人员自己完成。单元测试的代码行覆盖率能够达到70%，就是一个非常不错的程度了。测试人员不做单元测试，但是可以尝试推动研发人员来编写单元测试用例。
单元自动化测试（数据处理层）：指对软件中最小的可测试单元进行检查和验证，一般需要借助单元测试框架，单元测试常用的框架：XUnit，比如Java的JUnit，PHP的PHPUnit，Python的unittest等等。
一个测试用例通常由三部分组成：setUp，测试逻辑，tearDown。setUp用于准备测试数据，tearDown用于清理数据。
一般单元测试框架都支持装饰器设计模式的注解，比如跳过执行，测试套件的组织，测试用例依赖管理等等。
接口测试
接口自动化测试是目前最适合测试工程师进行自动化的一层。接口不但变化小，运行速度快，可测试的代码覆盖率高，维护成本低，高收益，还有着出现问题后能够快速定位的优点。
接口自动化测试（业务逻辑层）：主要检查验证模块间的调用返回以及不同系统、服务间的数据交换，常见的接口测试工具有jmeter、postman；
UI测试
UI自动化执行效率低，并且容易受其他原因（电脑卡顿，浏览器卡顿，网速等）影响导致脚本执行失败，覆盖率难以提升，维护成本较高，属于高投入低收益的类型。但它的优点就是可以完全模拟用户行为，更贴近真实。常见的测试工具有Selenium、Appium等；
业务成熟，界面较稳定的时候会考虑UI自动化，(通常只实现业务主流程，不会全流程覆盖)
做UI自动化测试的步骤:
1、整理出需要实现的UI自动化的场景和业务流程
2、搭建UI自动化环境（第一次做要这样，后续不用只是集成到之前的项目里）
3、编写正常流的测试脚本
4、添加断言
5、增加异常流程的分支判断及脚本编写
6、提取脚本中的变量参数
7、使用xlrd+parametrize实现数据驱动测试
8、优化并重构脚本（例如提取业务中常用的界面元素；封装业务中的阶段流程，使之可以复用，完成业务驱动测试等）
自动化的三大入手点
多沟通多交流，抓住测试工作中的痛点，优先解决基层的工作痛点，磨刀不误砍柴工，进行技术选型和方案可行性调研，如果一开始的方向错了，最终会得不偿失。 如果是比较复杂的解决方案，尽量前后端分离、保证各模块的独立性、可融合性、解耦不解体，做到灵活可扩展。
资源是有限的，自动化测试需要在时间/成本/质量三个维度寻找平衡点。
1. 成本：自动化并不一定围绕测试执行，还可以包括测试的准备，log的提取，数据分析等等。将所有的与测试有关的工作逐一列出，然后找到重复的，可以被代码化的部分，评估现有工作成本和自动化成本，寻找到收益最大的工作块并顺序将其代码化。
2. 质量：在评估的时候需要评估该工作块现有的质量状况和需求质量间的差异，寻找到差异最多的那个模块，并将所有质量差的模块逐一进行自动化。
3. 时间：寻找到与测试有关的所有步骤和工作块，在其中关键路径上，动作最慢，耗时最大的部分进行自动化。
自动化测试用例设计
在自动化测试的流程中，其关键点在于自动化测试设计，包括测试用例设计、测试脚本设计及测试报告。自动化测试用例设计直接决定自动化测试质量，下面主要讲自动化测试用例的设计。
1、两点不可取设计
① 不编写测试用例直接编写测试脚本。
② 直接拿手工测试用例来编写自动化测试脚本。
2、设计原则
a、测试用例可以按照一个功能点或者一个完整的场景来设计。
b、测试用例尽量只做功能正常性的逻辑验证，异常性逻辑的情况很多，验证比较复杂，需要编写大量的脚本，投入成本比较高，资源是有限的，需要在时间/成本/质量三个维度寻找平衡点。
c、测试用例之间不要产生关联，也就是说每个测试用例是独立，不能依赖或影响其他测试用例，要求高内聚低耦合。
d、测试用例的上下文必须有一定的顺序性，要能够互相连接起来；并且前置条件要清楚, 错了，脚本要抛出异常。
e、测试用例中检查点的设置（设置检测点要全面和灵活）。
f、测试用例要对修改的数据进行还原操作。
g、测试用例必须是可回归的。
h、开门记得要关门，配置信息要回归原点，否则脚本要迷路。
