自动化测试基础简介（本质）
目录
前言
1.自动化基础
2.分层的自动化测试
2.1 单元自动化测试
2.2 接口自动化测试
2.3 UI自动化测试
3.适合自动化的项目
4.自动化测试模型
4.1线性测试
4.2模块化与类库
4.3数据驱动测试
4.4关键字驱动测试
5.POM设计模式
总结
前言
随着软件系统规模的日益扩大，以及应用领域的不断拓展，对软件系统的测试也变得更加困难和复杂，传统的人工测试的局限性也越来越明显。
自动化软件测试技术可以克服传统测试技术的许多问题。自动化测试所依据的是一套严密的测试法则和评估标准，具有完整的自动测试过程。
因此，它可以避免测试人员惯性思维所导致的测试疏漏，也可减少由于手工测试中繁复的重复工作所导致的人为差错。
1.自动化基础
定义：把人对软件的测试行为转化为由机器执行测试行为的一种实践。对于最常见的 GUI自动化测试来讲，就是由自动化测试工具模拟之前需要人工在软件界面上的各种操作，并且自动验证其结果是否符合预期。
自动化测试的本质是先写一段代码，然后去测试另一段代码，所以实现自动化测试用例本身属于开发工作，需要投入大量的时间和精力，并且已经开发完成的用例还必须随着被测对象的改变而不断更新，你还需要为此付出维护测试用例的成本。
注意：当你发现自动化测试用例的维护成本高于其节省的测试成本时，自动化测试就失去了价值与意义，你也就需要在是否使用自动化测试上权衡取舍了。
自动化的优势
- 自动化测试可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上；
- 自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程；
- 自动化测试可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式；
- 自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务 7×24 小时持续运行的系统稳定性测试和高并发场景的压力测试等；
- 自动化测试还可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽。
自动化的劣势
- 自动化测试并不能取代手工测试，它只能替代手工测试中执行频率高、机械化的重复步骤。你千万不要奢望所有的测试都自动化，否则一定会得不偿失。
- 自动测试远比手动测试脆弱，无法应对被测系统的变化，业界一直有句玩笑话“开发手一抖，自动化测试忙一宿”，这也从侧面反映了自动化测试用例的维护成本一直居高不下的事实。
- 自动化测试用例的开发工作量远大于单次的手工测试，所以只有当开发完成的测试用例的有效执行次数大于等于 5 次时，才能收回自动化测试的成本。
- 手工测试发现的缺陷数量通常比自动化测试要更多，并且自动化测试仅仅能发现回归测试范围的缺陷。
- 测试的效率很大程度上依赖自动化测试用例的设计以及实现质量，不稳定的自动化测试用例实现比没有自动化更糟糕。
- 实行自动化测试的初期，用例开发效率通常都很低，大量初期开发的用例通常会在整个自动化测试体系成熟，和测试工程师全面掌握测试工具后，需要重构。
- 业务测试专家和自动化测试专家通常是两批人，前者懂业务不懂自动化技术，后者懂自动化技术但不懂业务，只有二者紧密合作，才能高效开展自动化测试。
- 自动化测试开发人员必须具备一定的编程能力，这对传统的手工测试工程师会是一个挑战。
2.分层的自动化测试
2.1 单元自动化测试
定位：对软件中最小可测试单元进行检查和验证
谁做：由开发做更合适
- 测试人员做的优化是具备测试思维，在设计用例时考虑的更加全面，劣势是不熟悉被测代码
- 开发做的优势是熟悉自己的代码，只需要掌握单元测试框架的使用和一些常用的测试方法，即可写单元测试，而且定位BUG时更加方便
2.2 接口自动化测试
web应用的接口自动化测试大体分为两类：模块接口测试和协议接口测试。
- 模块接口测试，主要测试程序模块之间的调用与返回。它主要强调对一个可实现完整功能的类、方法或函数的调用的测试。
- 协议接口测试，主要测试对网络传输协议的调用，如HTTP/SOAP等，一般应用在前端和后端开发之间，以及不同项目之间。
谁做：模块接口测试由开发去做。协议接口测试既可以开发也可以测试。
2.3 UI自动化测试
UI自动化以实现手动测试用例为主，可降低系统功能回归测试的成本
谁做：由测试做更合适
Google把产品测试类型划分为：小测试、中测试、大测试。采用70%、20%、10%的比例，分别对应Unit层、Service层、UI层
3.适合自动化的项目
- 需求稳定，不会频繁变更
- 软件维护周期长
- 比较频繁的回归测试
- 需要在多个平台上运行相同测试案例，大量重复的任务
- 通过手工测试无法实现，或者手工成本太高
- 被测软件系统开发较为规范，能够保证系统的可测试性
- 测试人员具备较强的编程能力
- 每日构建后的测试验证
- 软件系统界面稳定，变动少
- 项目进度压力不太大，资源充足
- 具备大量的自动化测试平台
一般满足以下三点即可做 - 软件需求变动不频繁
- 项目周期长
- 自动化测试脚本可重复使用
4.自动化测试模型
自动化测试模型可分为线性测试、模块化与类库、数据驱动测试、关键字驱动测试
4.1线性测试
这是早期自动化测试的一种形式，通过录制或编写对应用程序的操作步骤来产生相应的线性脚本，每个线性脚本相对独立，且不产生依赖与调用，只是单纯地模拟用户完整的操作场景
4.2模块化与类库
线性测试的缺点是不易维护，所以采用模块化思想，将重复的操作单独封装成公共模块。当需要用到该模块时，只需要对其进行调用。消除了代码重复，从而提高测试用例的可维护性。
4.3数据驱动测试
在有些场景中，测试步骤一致，但数据不一致，比如测试不同用户登录。模块化测试并不能解决这类问题。于是有了数据驱动测试。
数据驱动测试就是，数据的改变驱动自动化测试的执行，最终引起测试结果的改变。简单说就是把数据驱动所用到的测试数据参数化，可以用多种方式来存储和管理这些参数化的数据。
可将测试数据放到数据文件中，如txt文件、Excel、CSV、JSon、Yaml、Xml。测试用例脚本中直接调用文件中的数据
4.4关键字驱动测试
关键字驱动测试又被称为表驱动测试或基于动作字测试。这类框架会把自动化操作封装成“关键字”，避免测试人员直接接触代码，多以填表格的形式降低脚本的编写难度
Robot Framework 是主流的关键字驱动测试框架之一
这几种测试模型并非后者淘汰前者的关系，在实际过程中，需要相互结合使用。
5.POM设计模式
POM(Page Object Model):页面对象模型，是一种设计模式，用来管理维护一组web元素集的对象库。使用POM设计模式最终的目的是为了程序松耦合。
设计思想：把元素定位和元素操作进行分层，好处是当元素发生变化时，只需要维护page层的元素定位，不需要关心哪些测试用例中使用了哪些元素，在编写测试用例时，也不需要关心元素是如何定位的。
- 在POM下，应用程序的每一个页面都有一个对应的page class
- 每个page class都维护着该web页面的元素集和操作这些元素的方法
三层模型
第一层，Base基础页面层：抽取每个页面的相同方法、相同属性（即公共方法、公共属性）到一个基础类BasePage。例如：元素定位方法封装
第二层，PO页面层：每个页面定义其自己的page Object类，定义该页面的元素定位、封装页面功能的方法
第三层，测试用例层：用例操作流程
三层之间的关系：第二层继承第一层，第三层调用第二层里面的方法
当元素发生变化时，只需要修改第二层的元素定位。
总结
自动化的前景完全不必担忧，且不说人类社会发展的大方向就是自动化，难道我们如今不是把很多很多的工作都交给了各种工具么？
市场有没有前景是一回事，自己能否把握住，是另一回事。测试自动化是一定是未来的方向。
————————————
这篇贴子到这里就结束了，最后，希望看这篇帖子的朋友能够有所收获。欢迎留言，或是关注我的专栏和我交流。