读书笔记：《高效自动化测试平台：设计与开发实战》2021.03.12_高效自动化测试平台:设计与开发实战-CSDN博客

本文链接：https://blog.csdn.net/weixin_47369432/article/details/114840901

作者：徐德晨，茹炳晟

简介：高效测试平台的建设对软件自动化测试的效率有重大的意义。本书总结了高效测试平台的基本设计方法，包括面向对象设计思想、模块化设计、可扩展的弹性设计、测试设备的驱动设计、与CI/CD的结合，以及平台的部署。介绍了如何进行测试工具的选型、测试引擎的灵活配置，如何开发高复用性的测试用例，如何进行测试用例的生命周期管理等。此外，与平台相结合，深入探讨了数据驱动测试、事件驱动测试等测试脚本的设计模式、代码自动生成的实现、第三方工具的封装。更难得的是，结合真实的大型电商案例，介绍了微服务、中台等一些前沿技术与自动化测试结合的方法与实践经验。本书基于Python，是搭建高效自动化测试平台的指南，适合所有测试开发、测试平台优化等相关人员入门及进阶学习

全书分块：

前言~第一章：分析现状与挑战，提出需求
第2~第7章：案例分析+实际代码，实现基础功能
第8~第11章：改进方案
第12~第13章：与前沿技术的结合 + 真实案例

GitHub地址：https://github.com/dechenx83/automation_test

读书理由：工作需求

读书渠道：实体书+微信读书

今日目标：第四章，这一部分是对测试的配置模块的设计与实现

第四章模块化的测试配置

4.1 配置分类

静态配置：

基本配置，将一些配置选项参数化，保存在一个外部资源（比如文本文件或数据库）中
测试执行者在测试执行前修改并保存这些配置项，让测试系统能够读取相应的值
不依赖于平台，每个模块自己管理自己的配置，最终汇总到配置管理模块进行统一管理
配置和具体业务并没有联系，是模块的通用配置项
应该能够被方便地扩展

动态配置：

配置文件并不是固定不变的，它会随着业务变化（并非跨团队的业务变化）而增加或减少
配置并不是应用于整个平台或者某次执行中，而可能是作用于某个测试平台的对象，比如测试列表和测试用例
没有特定的定义对象，需要在某些逻辑操作之后才能生成
配置的时间点可能在测试执行之前，也可能在测试执行过程中

带有逻辑功能的配置：

测试平台根据相应的配置规则能在测试用例执行过程中执行相应的逻辑

4.2 静态配置

**特点：**不同的模块有不同的配置文件，所以需要可扩展，然后由平台统一注册管理

配置功能设计：

常使用键值对模式进行配置
方便地扩展和定义：能在一个基类上通过继承来实现对配置的扩展，比如不同模块的不同配置项
实现保存和读取功能：能够将配置类中所有的字段保存到文件，同时能够通过读取方法来装载配置

配置的注册方法：

作用：对配置进行统一管理
思路：模块在引用的时候会执行其中的所有代码，可以把配置管理对象作为一个单例，其他模块在被引用的时候，将配置类添加到配置管理对象中
创建配置管理类，所有的模块将自己实现的配置添加到该类中进行统一管理，包括：
- 所有配置类的路径管理
- 统一的读取和存储

4.3 动态配置

动态配置将一些运行期间需要持久化或可配置的对象，即将运行时的一些状态保存成配置文件，以方便在下一次运行时将这些配置读取出来
配置是针对特定的类的，设计者在设计类的时候要考虑哪些东西是需要持久化的，并且是外部可以配置的。
动态配置读取文件时所需要的文件名也可以通过外部来进行配置
类被实例化之后，相应的配置应该被加载，并且生成配置属性字段

综上，动态配置需要：

• 配置是针对特定的类生效的。
• 配置文件和路径是可以通过外部传入来设置的
• 类实例化的过程中，要生成相应的字段（比如settings）来保存配置类

实现方式：

类中类：在类中定义一个继承自SettingBase的类，来保证配置类的唯一性，这样定义的好处是，在定义类的同时，将相应的配置项清晰地定义出来，比较直观。另外，不同的类的配置类可以定义成相同的名字，不会冲突
通过装饰器初始化配置：定义好类的配置类之后，就希望在类的实例化过程中，能够将配置类进行初始化并装载，提供给开发者使用

4.4 带逻辑配置

主要用于测试用例执行前后或者执行时所需要的配置，或者执行的过程
带有逻辑功能的配置并不属于常规类型的配置，但是在使用的时候类似于“配置”，即通过外部设置来决定是否执行某些逻辑。

换句话说，用户增加逻辑配置项，并不会增加外部的任何操作，所有的操作都在逻辑配置中实现

逻辑配置可以被描述成一种模块，通过统一的输入参数实现自己的业务逻辑，然后通过统一的管理工具来管理其装载，提供给测试引擎统一调用

利用抽象类来定义逻辑配置模块的基类，并且提供抽象方法给不同的配置功能来实现

使用场景，如：

**设备版本检测模块：**检测某些测试设备的版本是否满足测试的需要，如果不满足可以对其进行一些操作，比如从测试资源池中挪去该设备
**控制口错误监测模块：**在测试的执行过程中，对被测设备的控制口（比如命令行口）进行监控，检查控制口的输出是否包含某些特定的错误关键词信息，以此来判断执行过程中是否有测试用例不能抓到的错误存在
**服务器资源监测模块：**在测试过程中监测服务器的资源状态，比如CPU占用率、内存使用量等
**测试设备重启模块：**在测试用例结束后，对设备进行重启操作

对于带有逻辑功能的模块的使用场景，其设计目的都是使测试用例变得更加灵活，在不修改测试用例或测试资源配置的情况下，可以方便地增加测试用例的覆盖度，或者对某些缺陷进行一些临时的修改（Workaround）

逻辑配置模块提供基类，可根据需求扩展。所以这些逻辑配置模块并不一定被放在特定的模块内，大部分情况下需要根据具体业务来进行设计

逻辑配置模块的配置：

针对逻辑配置模块，不同的功能也需要不同的参数，这些参数并不能被统一提供

比如控制口监控模块所监控的错误关键字、版本检查模块的版本、服务器监控模块的资源告警阈值等

因此，可以利用动态配置为逻辑配置模块添加动态配置功能，这样在装载逻辑模块的时候，带上逻辑配置模块的配置文件，就可以灵活地配置所需参数

逻辑配置模块管理器：

定义逻辑配置模块后，需要有一个统一的管理器通过配置文件来装载逻辑配置模块，并将其加以实例化，供测试执行模块调用