1 为什么设计自动化测试架构
1.1 企业现状分析
- 压力大：产品需求不明确，上线时间确定，压力山大。
- 混乱：未立项，开发时间已过半，前期无控制，后期无保障。
- 疲于应付：开发人员交付的文件质量差，测试跟着做集成，上线交付质量无底线。
- 遗漏率高：为什么 Bug 测试不出来，在用户使用中或在合作伙伴那里反而被测试出 来 Bug。
1.2 提高测试效率的疑问
- 如何在短时间和资源不足的情况下，尽可能测试出多的 Bug？
- 如何减少重复工作的工作量？
- 如何更好地对组员的测试质量进行监控？
- 测试文档很多，如何保证测试文档的质量？
- 如何衡量测试的效率，及人员绩效考核？
- 如何改进测试过程？
测试效率低下的主要原因：
2 认识自动化测试
2.1 明确几点问题
- 自动化测试永远不可能完全替代手工测试。
- 手工测试发现的缺陷远比自动化多。
- 项目周期长、需求变更少且不存在大量不可识别的第三方控件可以进行自动化测试设计。
- 对可靠性和性能测试要求高以及反复进行的测试，建议使用自动化。
2.2 什么是自动化测试
- 需要工具，但不应仅仅是测试工具
- 软件控制，做实际结果与预期结果的比较
- 可重复性，且有必要的测试流程可以自动化
- 手工测试难以达到的要点
狭义来讲，自动化测试指的是基于GUI的自动化测试，自动化测试是一种自动测试思想，应该包括工具、方法、规程和沟通等内容，是测试工程师手的延伸。
2.3 自动化测试框架具备的要素
测试体系与测试平台整合：
测试用例标准化整合：
回归测试自动化执行：
最终目标：
自动化测试平台最终图谱：
3 自动化测试的设计模式
自动化测试模型主要包括几个阶段：线性测试、模块驱动测试、数据驱动测试、关键字驱动测试.
数据驱动测试与关键字驱动测试的区别：
数据驱动原理：数据与脚本分离，实现了参数化，通过数据的改变引起测试结果的改变。数据驱动从数据文件读取输入数据，通过变量的参数化将测试数据传入测试脚本，不同的数据文件对应不同的测试用例，数据和脚本分离。数据来控制测试的业务流。
关键字驱动原理：关键字与脚本分离，通过关键字的改变引起测试的改变 。关键字驱动将测试逻辑按照关键字进行分解，关键字对应封装的逻辑业务。主要关键字包括三类：被操作对象（Item）、操作（operation）和值（value），利用面向对象的方式可以将其表现为Item.Operation（value）。
自动化测试模型阶段依次如下：
4 自动化测试的实施策略
- 推动开发人员实施单元测试
- 接口层尽量进行自动化全量测试，关键字模式实现
- 在UI测试时，使用数据驱动设计模式，解决重复步骤繁琐测试难题
- UI层在需求稳定的时期，在进行实施，主要回归主要流为主
- 在线监控：引入自动化脚本监控生成系统的业务流程
- 抽调精兵强将（编程能力强），针对业务系统那个设计测试框架，实现测试人员不需要写代码，也可以实现自动化
- 小项目开始逐步推广，初期不要太高期望，有效衡量投入产出比，获得中高层的支持。
5 自动化持续集成测试实战
持续集成（Continuous Integration,CI），是一种软件开发自动化实战。
5.1 自动化持续集成测试任务的提出
自动化持续集成测试任务的提出，主要包括3个部分：任务目标、工具准备、环境说明。
任务目标：
- 研发用 GIT 提交代码到 Gitlab 服务器。
- Jenkins 检测到 Gitlab 上有代码更新，自动触发测试。
- 禅道检测到 Gitlab 上有代码更新，自动将 Bug 状态改为已解决。
- 测试通过，将代码打包并部署到外部 Tomcat 中。
- 测试未通过，自动发邮件给相关负责人。
- 精准测试 ThreadingTest 进行测试实施与回归测试任务。
工具准备：
环境说明：
5.2 服务器集群搭建
服务器集群搭建：gitlab服务搭建、禅道服务搭建。
6 单元测试框架
单元测试：测试类、方法或者函数
单元测试框架可以完成的测试类型：
1、单元测试
2、UI自动化测试
3、接口自动化测试
文件级别setup方法：当前文件第一个测试开始之前只执行一次。
多个测试类：
测试类A：
类setup方法：在当前类中的第一个测试方法调用前执行，只执行一次。
setup方法：在执行测试方法前的一些环境或者数据相关的准备。
测试的方法：每个测试方法执行前，都会执行setup方法，执行后执行teardown方法。
teardown方法：在执行测试方法前的一些环境或者数据相关的清理。
类teardown方法：在当前类的最后一个测试方法调用完成后，只执行一次。
文件级别teardown方法：所有的测试结束之后只执行一次。