高效自动化测试平台：设计与开发实战

本书从软件自动化测试的发展历史和趋势出发，总结了当前软件自动化测试的需求和挑战，比如:

1. 测试对象功能复杂化，被测对象的功能越来越多，越来越全面。

2. 迭代快速化，软件从设计到交付的时间周期越来越短。

3. 测试环境规模不断增加，被测试对象的系统规模越来越庞大。

在此基础上，本书以实战的方法，深入浅出地分析和介绍了一种模块化平台的设计方案来应对这些挑战，逐一介绍了每个模块的设计思路。这种自动化测试平台具有良好的测试用例的复用能力和功能的扩展能力，并且对于测试工程师用户来说有比较低的学习成本，能快速对测试用例开发进行上手。同时，该平台的设计能够很好的解决部署和执行问题，在CI/CD并且融入了数据驱动，事件驱动等先进的设计思想和理念。

本书还结合了当下软件企业比较重视的CI/CD流程，云端部署等热门话题， 介绍了如何将自动化测试平台集成到CI/CD的工作流程以及如何将测试平台进行云部署的转变。最后介绍了几个大型企业的经典案例。

除了设计思路和方案以外，本书会给出部分的代码实现（主要适用面向对象脚本语言Python）。本书的所有代码均已开源至GitHub。

徐德晨 毕业于中国科技大学自动化系软件工程专业，硕士。先后任职于智邦科技、Tellabs、Broadcom、Cisco，从事自动化测试平台开发工作，在Cisco任职期间申请通过三项专利，现在Dell EMC负责自动化测试平台的设计与开发。

茹炳晟 业界知名的实战派软件质量和研发工程效能专家，测试基础架构的布道者，腾讯云专家TVP，阿里云专家MVP，中国商业联合会互联网应用技术委员会的智库专家，国内外技术峰会的技术委员会成员和专题出品人。

适读人群 ：软件企业测试开发人员，对软件测试感兴趣的爱好者，软件开发从业人员。

★ 这是一本自动化测试平台搭建及优化的实战指南

★ 读者将掌握高效测试平台的核心设计思想：面向对象、模块化设计、可扩展的弹性设计、测试设备的驱动设计、与CI/CD的结合

★ 了解数据驱动测试、事件驱动测试等测试脚本的设计模式

★ 学会自动生成的实现、第三方工具的封装以及平台的部署

★ 解读真实的大型电商案例

★ 获取微服务、中台等前沿技术与自动化测试结合的方法和实战经验

前　　言

软件自动化测试的意义

随着计算机技术的发展，计算机的计算能力和存储能力不断提高，计算机软件的复杂程度也不断地增加，近几十年互联网飞速发展，网络可以将计算机连接起来，突破硬件能力的限制，形成规模更为庞大、功能更为复杂的软件系统。可以看到，在这样的背景下，要保证软件的质量已经成为每一个企业的巨大挑战。

在几十年前，受限于计算机硬件的限制，软件的规模比较小，比如一张或几张磁片就能容下一个系统，所以不管从软件的代码量还是从功能来说，都是比较少的，要保证软件的质量，可以通过常规的测试手段来进行测试，测试人员根据软件设计人员定义的操作，设计测试用例，并且手动地执行测试用例便可基本保证软件的质量。

不过随着软件规模的增大，软件的速度开始提升，特性也越来越丰富，测试的要求就逐渐变得高了起来。

特别是随着软件质量的提高，公司对企业的测试人员提出了更高的要求。传统的测试人员需要设计更多的测试用例，这意味着测试人员需要执行更多的测试用例，渐渐地，纯手工测试已经不可能满足软件质量的要求了。

自动化测试是将传统人工执行的测试用例转换成程序，让机器去执行。机器不仅可以24小时工作，并且对于每一次执行都不会“偷懒”。这里笔者并不需要列举具体的数据来说明自动化的测试用例可以提高多少测试效率，只需要通过一些简单的例子，就可以看到自动化测试带来的巨大的效率提升。

比如，对于传统的交换机测试，一个经典的测试用例就是数据报文的转发，我们可能需要在交换机上先做一些配置，接着在测试仪表上做一些配置，然后使用测试仪表发送测试流量，再对结果进行分析。这个过程如果用纯手工，可能需要两分钟，如果使用脚本来配置交换机并且用脚本控制测试仪表，可能只需要几秒钟。这还不是关键，关键在于，如果这个端口支持不同的工作模式，比如十兆位、百兆位、千兆位模式，那么就需要做三次同样的测试。

软件行业的统计会带来一些有趣的结论。比如一个公司基于缺陷的统计，每千行代码的缺陷数量为两个，在下一个版本发布时，每千行代码的缺陷数量只有1.5个。这并不是说明软件质量提高了，而是有缺陷没有被找到。这看上去似乎有点不合乎逻辑，但事实就是，功能和性能的增加会导致测试的复杂性以几何的方式提升，所以缺陷和代码量并不呈线性的正比。

所以软件自动化测试的重要性不言而喻，我们不仅需要软件自动化测试，还需要高效的软件自动化测试，以应对日益增加的代码量。

软件自动化测试的发展

早期脚本录制回放，或者简单的单元测试脚本，可以说是自动化测试的雏形。比如开发人员会写一些单元测试函数，来对一些模块进行输入/输出测试。黑盒测试人员会将软件的配置过程及检查过程使用工具进行记录和回放。比如Pro Comm、SecureCRT等终端软件就支持用户输入的记录，并且生成脚本，然后用户可以对整个配置过程和结果进行自动化处理。

在这个阶段，自动化测试没有统一的自动化测试管理工具，脚本也没有统一的版本管理，所以维护起来也比较麻烦，不过作为手工测试的辅助，已经能够大大提高测试的效率。

之后，很多企业逐渐意识到自动化测试管理的重要性，有些企业的团队就开始把自动化测试作为一个项目来对待，有专门负责自动化测试工具开发的人员，形成了比较规范的自动化测试开发团队，这些团队根据项目的需求来建立专门的自动化测试工具，以帮助测试人员开发自动化测试用例，统一进行管理和运行，并且可以生成规范的报告。

在这个阶段，许多团队的自动化测试工具往往针对性非常强，这里的“针对性”指的是，可能每个自动化工具只能应用于某种产品系统的测试，甚至对产品的配置都是有要求的。笔者认为，出现这一情况的原因是，在当时，测试人员的代码和设计能力不是很强，企业很少将专门的开发人员派去参与测试系统的开发，并且在当时，自动化测试工具即便是完善的，也依然处于辅助的地位。因为自动化工具本身也是软件，过于复杂的功能会提高开发的成本，也会导致工具缺陷带来的产品缺陷无法发现或自动化测试不能顺利执行的问题。所以，有针对性的测试工具，开发和维护起来都比较容易。

随着软件发展越来越快，企业的产品周期也变得越来越快，需求变更，新产品迭代，针对性强的自动化测试工具反而变得更不容易维护，要么需要重新开发对应的自动化测试工具，要么需要对原来的工具进行改造。

在这种背景下，出现了一些开源的或者商业的自动化测试框架或者工具，来针对某些领域的软件进行测试。比如Rational Functional Test是IBM推出的一款自动化测试工具，可以用来测试Web自动化及基于Java的Swing或AWT的GUI的自动化测试，它本身提供了控件抓取的功能和不错的执行报告生成的功能，并且还有很丰富的示例文档。

测试团队选择适合他们的框架或工具，可以更多地关注测试业务本身，将有限的资源集中在测试用例的开发和执行上。但是随着软件规模的进一步增大，迭代周期进一步缩短，通用的框架也会有一定的局限性，比如，通用框架的功能无法满足实际需求。

测试框架开始逐渐向平台化发展，不仅是简单地执行测试用例并输出报告，还能够进行测试用例的复杂管理，以及测试执行的复杂管理，并且更进一步地，进入持续集成/持续交付或部署（CI/CD）的环节，使得整个软件的开发和测试流程形成一个完整的自动化闭环，企业逐渐开始增加测试开发人员的配比。

而如今，随着人工智能的引入，自动化测试又开始向人工智能方向发展。人们正在研究利用人工智能技术进行自动生成自动化测试用例的技术，这无疑又会将自动化测试提到一个新的高度。

关于本书

即便自动化测试技术在今天已经发展到人工智能的阶段，但是很多企业和团队由于成本或者其他一些因素，依旧在自动化测试工具、平台的选择和开发上苦苦摸索和前进。

这本书是笔者对从事了十几年的自动化测试开发工作的一个阶段性总结。笔者曾经任职于几家通信企业，也在创业公司带领过测试开发团队，现在依旧在软件企业中从事自动化测试平台的建设和优化。

在这本书中，笔者根据所在的公司所面临过的一些挑战，分析一个自动化测试平台所需要的或者可能需要的相关特性，并且用Python语言来实现这样一个平台，因为Python是现今流行的脚本语言之一，很多企业都在使用Python进行软件开发。不过使用何种语言只是一种工具，笔者有很长一段时间使用C#进行软件开发。

编程语言是实现设计的途径，甚至一个功能强大的平台，可以匹配多种语言工具开发的库，比如最近流行的微服务架构，就可以使开发者选择自己熟悉的语言来进行开发。关于Python的版本，本书在编写阶段经历了3.5版本到3.7版本的一次升级，所以有些代码可能需要Python 3.7以上的版本才能执行。比如字符串格式化方法，f“{var}”这样的格式是3.7版本以后的新特性，如果读者还在使用3.5版本的Python，可以自行替换成类似str.format或者%的字符串格式化方式。

在大多数情况下，笔者希望平台是足够通用的。其实在前几年，笔者一直认为，足够通用的测试平台在企业内部更容易推广，并且能够更好地满足变化需求快的项目，这样可以在新产品到来之后，不需要做太多的测试平台的重构。不过最近几年笔者才发现，过高的通用性会提高测试平台开发的难度，有时候舍弃通用性是提高效率的好办法，当然这些都需要团队去权衡。

本书的读者对象是在软件测试领域有一定的经验，对自动化测试开发没有太多的经验，但是希望在自动化测试上进一步发展的工程师。笔者希望，这本书能够给这样的读者带来一些软件自动化测试平台的设计思路，并且使读者能够根据所在团队的特点进行进一的步扩展。当然，如果你是一位希望从事软件自动化测试开发的技术人员，相信这本书也会给你带来不错的启发与帮助。

本书主要分为四个部分：

第一部分包括前言和第1章，主要分析和介绍当前软件测试领域中自动化测试开发的现状，以及所面临的一些挑战，并且通过这些分析，提出了自动化测试的需求。

第二部分包括第2章到第7章，通过案例分析及实际的代码，实现一个可执行的自动化平台的基础功能。

第三部分包括第8章到第11章，主要介绍对传统自动化测试的改进方案，包括数据驱动、测试代码的自动生成、模块化的事件驱动模式，以及第三方测试工具的封装。

第四部分包括第12章和第13章，主要介绍一些前沿技术和自动化测试的结合方法，以及自动化测试的真实企业案例。

本书的所有代码均已开源至GitHub，书中的代码可能会有一些改动，主要是为了以更简单的代码来说明笔者想要表达的概念，代码的功能是一致的。读者可以访问GitHub网址https://github.com/dechenx83/automation_test进行学习，甚至分享自己的代码，一起进步。

第1章 软件自动化测试面临的挑战 1

1.1 软件测试各个阶段的自动化需求 2

1.1.1 单元测试 2

1.1.2 功能测试 4

1.1.3 回归测试 6

1.1.4 可用性测试及冒烟测试 6

1.1.5 系统测试 7

1.2 软件自动化测试工具的挑战 8

1.2.1 测试用例的复用能力 8

1.2.2 测试用例的扩展能力 9

1.2.3 测试工具的扩展能力 10

1.2.4 灵活的测试调度能力 11

1.2.5 测试结果和报告 12

1.2.6 与CI/CD的集成能力 14

1.2.7 快速部署和较低的学习成本 15

1.3 基于面向对象的平台化设计思想 16

1.3.1 面向对象设计思想 16

1.3.2 模块化设计 25

1.4 总结 27

??

第2章 高效测试平台的基本设计 28

2.1 编程语言和开源框架 29

2.1.1 编程语言的选择 29

2.1.2 从零开发还是使用现有框架 30

2.1.3 跨越平台和编程语言的限制 31

2.2 模块化测试平台的设计方法 33

2.2.1 什么是模块化 33

2.2.2 核心功能和业务分离 36

2.2.3 分层设计思想 36

2.2.4 前后端分离 38

2.3 自动化测试平台的基本设计 41

2.3.1 自动化测试平台的基本模块 41

2.3.2 测试资源管理模块 42

2.3.3 测试配置管理模块 43

2.3.4 测试用例执行模块 44

2.3.5 测试报告和日志模块 45

2.4 总结 46

第3章 可扩展的测试资源管理模块 47

3.1 测试资源 48

3.1.1 测试资源和抽象 49

3.1.2 测试资源的序列化和反序列化 53

3.1.3 测试资源池 61

3.2 资源选择器 67

3.2.1 设计资源选择器的目的 68

3.2.2 资源限制条件机制 71

3.2.3 资源获取路由 81

3.3 从资源类对象获取资源配置接口 87

3.3.1 资源类对象和配置接口分离 87

3.3.2 配置接口实例化方法的注册 89

3.4 总结 93

??

第4章 模块化的测试配置 94

4.1 测试配置基本分类 96

4.1.1 静态配置 96

4.1.2 动态配置 97

4.1.3 带有逻辑功能的配置 99

4.2 可扩展的静态配置 100

4.2.1 基本配置的设计 100

4.2.2 配置的注册方法 103

4.3 灵活的动态配置 106

4.3.1 类中类 107

4.3.2 通过装饰器来初始化配置 108

4.4 带逻辑功能的配置 109

4.4.1 带逻辑功能配置模块的使用场景 109

4.4.2 逻辑功能模块的实现 111

4.4.3 逻辑配置模块管理器 114

4.5 总结 117

第5章 友善的测试报告和日志 119

5.1 我们需要什么样的测试结果 120

5.1.1 测试步骤和日志分离 121

5.1.2 仪表板 122

5.1.3 清晰的测试步骤 122

5.1.4 分类的运行日志 124

5.2 树形显示的测试步骤 124

5.2.1 树形测试步骤输出的实现 125

5.2.2 巧用Python的with语句 138

5.3 日志管理 148

5.3.1 日志注册 148

5.3.2 平台模块的日志注册 150

5.3.3 测试用例的日志注册 155

5.4 总结 158

第6章 灵活配置的测试引擎 159

6.1 测试引擎的职责 160

6.1.1 测试用例的装载 161

6.1.2 测试列表和配置需求满足分析 162

6.1.3 测试资源获取 162

6.1.4 配置的装载 163

6.1.5 测试用例的执行及生命周期管理 163

6.2 测试用例 165

6.2.1 四步测试 165

6.2.2 测试用例的属性 167

6.2.3 测试用例参数 168

6.2.4 测试用例的优先级及依赖关系 171

6.2.5 测试列表 174

6.3 测试引擎的初始化设计 178

6.3.1 静态配置的读取和实例化 179

6.3.2 测试资源的获取 180

6.3.3 测试列表及测试用例的装载 181

6.4 测试用例的生命周期管理及运行 184

6.4.1 测试用例的执行流程 184

6.4.2 测试用例的流程控制设计 185

6.4.3 测试用例的异常管理 191

6.4.4 测试用例的中断控制 194

6.4.5 测试引擎的运行 195

6.5 总结 197

第7章 友善的管理平台 199

7.1 命令行模式 200

7.1.1 命令行模式的优缺点 201

7.1.2 展示层设计 202

7.1.3 命令行功能的实现 205

7.1.4 执行测试用例 207

7.2 RESTful API的管理模式 210

7.2.1 RESTful API的特点 210

7.2.2 测试平台RESTful API的设计实现 211

7.2.3 GUI界面管理模式 219

7.3 测试用例的管理 219

7.3.1 测试用例的自动发现 220

7.3.2 测试用例的进一步管理 227

7.4 平台的安装及发布 228

7.4.1 平台核心功能的发布 229

7.4.2 测试用例及业务代码管理 236

7.5 总结 241

第8章 测试数据及数据驱动测试 242

8.1 测试数据的准备与生成 243

8.1.1 常见的测试数据生成方法 243

8.1.2 测试数据生成的时机 248

8.1.3 统一测试数据平台 252

8.2 数据驱动的测试用例 259

8.2.1 测试过程复用和数据替换 260

8.2.2 适宜的数据驱动策略 265

8.3 测试用例参数的传递设计 266

8.3.1 测试数据的传递 266

8.3.2 数据驱动装饰器的实现 268

8.3.3 测试数据的变量化 271

8.4 总结 277

第9章 代码自动生成 278

9.1 重复劳动的封装作业 279

9.1.1 协议验证测试和数据报文分析 280

9.1.2 RESTful API测试 285

9.2 文档和元数据驱动 287

9.2.1 元数据 288

9.2.2 手工开发代码的实现 296

9.3 代码自动生成的实现 302

9.3.1 自动生成代码的工具 302

9.3.2 中间对象的定义 311

9.3.3 代码的自动生成 326

9.4 测试用例的自动生成 337

9.4.1 技术代码和业务数据的分离 337

9.4.2 API接口测试 340

9.5 总结 342

第10章 测试工具和设备的驱动设计 343

10.1 命令行工具 344

10.1.1 命令行接口类的实现 345

10.1.2 接口的实例化 351

10.2 Selenium的二次封装 353

10.2.1 浏览器的二次封装 353

10.2.2 页面元素封装 358

10.3 技术代码下沉和测试业务封装 364

10.3.1 网络设备流量测试的典型场景 365

10.3.2 网络设备流量测试过程的抽象 367

10.4 总结 372

第11章 事件驱动测试模式 373

11.1 传统测试用例的挑战 374

11.1.1 固定的测试步骤和覆盖率 374

11.1.2 客户问题的复现 375

11.1.3 大系统和长时间的测试挑战 376

11.2 何为事件驱动 377

11.2.1 事件驱动的特点 377

11.2.2 事件驱动的一些问题 381

11.3 事件驱动引擎的设计 385

11.3.1 事件驱动的基本流程 385

11.3.2 事件的设计和实现 386

11.3.3 与现有平台相结合 399

11.4 总结 400

第12章 微服务化的测试平台 401

12.1 软件架构的演进 402

12.1.1 Monolith单体架构 402

12.1.2 分布式架构和SOA 403

12.1.3 微服务 404

12.2 微服务的基本形态 405

12.3 测试平台的微服务化 407

12.3.1 统一的测试平台 407

12.3.2 服务边界 409

12.3.3 基本服务的设计 411

12.3.4 消息队列 414

12.4 总结 414

第13章 实战成功案例介绍 416

13.1 四两拨千斤的自动化测试平台 416

13.1.1 初期阶段—产品测试模式和自动化测试平台的建立 417

13.1.2 扩展阶段—更智能的测试平台 421

13.1.3 推广阶段—公司的明星级测试平台 423

13.2 全球大型电商的自动化测试中台 424

13.2.1 测试中台的全局架构 424

13.2.2 统一测试执行服务 426

13.2.3 统一测试数据服务 426

13.2.4 统一测试执行环境服务 427

13.2.5 被测系统部署服务 429

13.2.6 测试报告服务 429

13.2.7 全局测试配置服务 430

13.2.8 GUI自动化测试服务 432

13.2.9 API自动化测试服务 432

13.2.10 统一Mock服务 433

13.2.11 工程效率工具链仓库 433