自动化测试框架该是个什么样子-理论篇

  看了蔡超老师测试开发相关的资料内容，针对自动化测试框架相关基本内容做以下总结。

一. 为什么引入测试框架

  测试框架可以帮助产品的测试工作便捷、高效的完成。好的测试框架不是一蹴而就设计出来的，而是在不断实践过程中逐渐完善、优化演化而来的。

二.自动化测试框架的构成

1. 基础模块

• 底层核心驱动库：如Web端的Selenium/WebDriver
• 可重用的组件：降低开发成本，如时间处理模块、登录模块等
• 对象库：将页面进行分组，将一个页面上的所有对象放到一个类中，Page Object模式。
• 配置文件：
  测试环境配置：减少环境的切换成本。
  应用程序配置：不更改代码的情况下覆盖相同程序的不同程序的配置。

2. 管理模块

• 测试数据管理：
  实时创建：是在测试代码运行时才生成的测试数据。其好处有：测试数据是和测试代码耦合的，测试人员不需要关心其创建过程和业务调用链，通常用在测试的公用功能上。
  事先创建：是指测试代码运行前就准备好数据文件。其好处是数据拿来即用，几乎不耗费时间，由于没有业务调用，所以这在一定程度上减少了调用失败的风险；坏处则是数据文件本身需要维护，以保持可用性和正确性。
• 测试文件管理
  测试框架的文件结构应该清晰有序、一目了然。一个测试用例应该对应建立三个文件，分别是：Page 类文件（xxxPage，根据 PO 模型）、测试类文件（testxxxPage）和对象库文件（xxxPageYml）。这三个文件共同描述了一个完整的测试用例，当你看到一个 Page 类时，就应该做到它还有一个对应的测试类。
  测试文件的结构清晰有助于他人理解测试框架的设计思想，更有利于测试框架的维护和推广。

3. 运行模块

• **测试用例调度，驱动机制。**测试框架应能按需组织，调度测试用例生成、执行。可根据给定的tag挑选要执行的用例，可顺序执行、并发执行、远程执行
• **错误恢复机制。**由于测试环境、测试程序、测试代码存在各种不确定因素，测试框架应该具备一定的错误恢复机制。一般可分为代码/运行导致的错误和环境/依赖导致的错误。
• **持续集成支持。**测试框架应该能够和 CI 系统低成本集成，包括通过用户输入参数指定运行环境、测试结束后自动生成测试报告等。

4. 统计模块

• 测试报告。 测试报告应该全面，包括测试用例条数统计、测试用例成功/失败百分比、测试用例总执行时间等总体信息。其中，对于单条测试用例，还应该包括测试用例 ID、测试用例运行结果、测试用例运行时间、测试用例所属模块、测试失败时刻系统截图、测试的日志等信息。
• 日志模块。方便出错时进行排查和定位。

三. 常用的测试框架类型

1. 模块化测试框架
  模块化测试框架是利用 OOP 思想和 PO 模式改造而来的框架。
  模块化测试框架把整个测试分为多个模块，模块化有以下几个特征：

• 我们将一个业务或者一个页面成为一个 Page 对象；
• 这个 Page 对象，我们以一个 Page 类来表示它；
• 这个 Page 类里存放有所有这个 Page所属的页面对象、元素操作；
• 页面对象和元素操作组成一个个的测试类方法，供测试用例层调用。
  使用了 PO 模式的框架就可以叫作模块化测试框架。
• 模块化测试框架的好处在于方便维护，你的测试用例可以由不同模块的不同对象组成；
• 坏处在于你需要非常了解你的系统及这些模块是如何划分的，才能在测试脚本里自如地使用，否则你就会陷入重复定义模块对象的循环里。

2. 数据驱动框架
  数据驱动框架主要解决了测试数据的问题。数据驱动框架的精髓在于，输入 M 组数据，框架会自动构造出 M 个测试用例，并在测试结果中把每一个测试用例的运行结果独立展示出来。
3. 关键字驱动框架
  关键字驱动其实就是把一系列代码操作封装成一个关键字（这个关键字其实是函数名），在测试里，可以通过使用组合关键字的方式来生成测试用例，而不去关心这个关键字是如何运作的。
关键字驱动的框架的基本工作是将测试用例分成四个不同的部分。首先是测试步骤（Test Step），二是测试步骤中的对象（Test Object），三是测试对象执行的动作(Action)，四是测试对象需要的数据（Test Data）。
关键字的一个典型应用是将登录操作封装为关键字 Login，之后在后续代码里，有关 Login的操作，就仅需调用这个关键字 Login，而不必又重新进行一次登录操作。
关键字在领域里的最佳应用典范我认为是BDD（行为驱动开发），它甚至被当成一种独立的敏捷软件开发技术来使用。
4.混合模型
  没有任何规定要求你的测试框架要属于以上某种类型，因为测试框架的存在不是为了分类型，而是为了更好地测试。
  所以在工作中，我们常常需要糅合不同框架模型，我们将这种模式的测试框架称为混合模型。混合模型可以包含模块化框架，也可以使用数据驱动，或者使用 BDD 模式。

四.测试框架设计的原则

（一）清晰明了，学习成本低
1.代码规范
测试框架随着业务推进，必然会涉及代码的二次开发，所以代码编写应符合通用规范，代码命名符合业界标准，并且代码层次清晰。
以 Python 为例，我们一般以 PEP 8 为准，具体请参考 Python Software Foundation 官网。
2.模块清晰明确
模块化是将测试框架从逻辑上分为几个不同的模块，使用者可以根据实际情况自行裁剪。
模块化的好处是可重用，并且便于替换修改。
（二）通用性强、可维护、可扩展
1. 通用性强
通用于不同的操作系统。比如，测试框架不仅适用在 Windows 操作系统上，还要适用在 MacOS、Linux 系统上，越通用，测试框架的受众就会越多。
能解决同一类通用问题。比如，测试框架有个底层方法是用来操作弹出框的，那么无论是 Alert 框、确认框，还是一个允许用户输入的交互框，测试框架应该都能识别并操作。
2. 可维护、可扩展
测试框架要做到容易维护，就一定要代码规范，模块清晰，除此之外整个测试框架代码风格还应该统一、易读、易懂。总之，要做到框架出问题时能容易定位并修改；更要做到，即使多人合作这个框架，这个框架代码要看起来是出自同一人之手。
可维护性无法用具体的指标衡量，也没有标准的实现方式。
但不可维护性是可以感知的，因为不可维护性常常以代码逻辑混乱，不遵循编码规则等特征出现。所以一般通过消除不可维护性来证明测试框架是可维护的。不可维护的典型例子便是代码逻辑，比如一部分判断逻辑嵌套了非常多层的 if…else，就像上面的反例代码一样，这样的代码不易理解，改起来容易出错，这是你必须要避免的。
可扩展性指当需求变化时框架容易扩展。如果测试框架不能扩展，就无法解决业务发展带来的新问题，也就意味着测试框架的寿命会很短。
下面我举例说明下什么是可扩展性，假设测试框架运行测试的流程是：查找测试文件夹下的所有用例 → 判断该用例是否要运行 → 加入用例到待运行用例集 → 顺序运行测试用例 → 输出测试报告。
比如现在随着业务发展，我有了新需求： 需要按照一定的规则将“顺序运行”改为“并发运行”，即将带有特定标签的测试用例改为“并发运行”，而将没带有特定标签的测试用例继续保持“顺序运行”。
如果我们的测试框架可扩展，那么我仅需简单更改“顺序运行测试用例”这个模块的相关代码即可；反之，我则需要将测试流程重新设置甚至改造，所以我说可扩展性是测试框架的一个重点。
（三） 对错误的处理能力强
1.错误处理机制，高效解决
在测试运行中，难免由于种种原因运行错误，这时测试框架就必须具备处理错误的能力。错误处理机制一般分为停止运行和错误恢复两种。

• 停止运行是指发现错误后直接停止本次测试，在实践中一般在测试框架本身出现错误的时候才会使用。

• 针对具体的测试用例执行，错误恢复这种方式比较常见。其步骤通常是标记当前用例为“失败”，清理失败数据，恢复测试环境，然后再运行下一条测试。
  其中，根据错误恢复的时机又可以分为事先恢复（当前用例运行前，将环境和数据恢复为初始状态）和事后恢复（当前用例执行完成后，将环境和数据恢复为初始状态）两种。
  事先恢复现在是比较常用的，因为事后恢复可能会因为用例执行失败而永远执行不到。

2.系统日志清晰，方便调用
除了错误处理机制外，系统的操作日志也能帮你快速排查问题根源，所以平时的日志一定要清晰详细，最好具备上下文，这样才能根据日志进行有效调试，快速定位错误发生的原因。
对于测试框架来说，系统日志除了要按等级 DEBUG、INFO、WARN、ERROR 划分外，最好包括以下内容：

• 记录测试用例的开始和结束时间；
• 记录测试人员的关键操作（如写文件、连接 DB、更改 DB 等）；
• 关键方法的异常信息（如 run 模块出错部分的上下文信息等）。

（四）运行效率高且功能强大
1.支持测试环境切换
一个产品从开发到上线，会经历几个测试环境的测试，比如 dev 环境， 集成测试环境，预生产环境，生成环境等。所以测试框架要能做到，一套脚本多环境运行，支持环境切换，并且能根据环境进行自动化的配置（包括系统配置、测试数据配置等）。

2.支持外部数据驱动
根据外部输入数据，动态生成测试用例，并在测试报告中单独展示。测试框架会把这些只有数据不同，步骤和操作都相同的测试用例，在运行中解析成一个个不同的独立测试用例，并在测试运行结束后，全部逐一展示到测试报告里。

根据外部输入数据，动态切换运行用例。测试目的不同，其需要采用的测试用例也会不同，所以自动化测试框架会给各个测试用例打上标签，再根据需要，自动选择具备特定标签的测试用例进行运行。

3.支持顺序、并发、远程运行
当你的测试用例有上千条，甚至上万条时，顺序测试会花费大量的时间。为了快速得到测试结果，测试框架应该支持顺序、并发、远程执行，这样能够缩短测试用例的整体执行时间。

4.报告完备详尽
测试报告是 QA 工作中的重要一环，通常在一个项目结束或者一个 sprint 结束时发出。

5.解决当前没有解决的问题
“不要重复造轮子”是工具创造的首要原则。从功能角度看，框架得到认可，要么是解决了当前无法解决的问题，要么是解决方案比当下的更好。
（五）支持版本控制和持续集成

1. 版本控制，回溯复盘
2. 持续集成，全局出发