★ 这是一本自动化测试平台搭建及优化的实战指南
★ 读者将掌握高效测试平台的核心设计思想：面向对象、模块化设计、可扩展的弹性设计、测试设备的驱动设计、与CI/CD的结合
★ 了解数据驱动测试、事件驱动测试等测试脚本的设计模式
★ 学会自动生成的实现、第三方工具的封装以及平台的部署
★ 解读真实的大型电商案例
★ 获取微服务、中台等前沿技术与自动化测试结合的方法和实战经验
本书从软件自动化测试的发展历史和趋势出发，总结了当前软件自动化测试的需求和挑战，比如:
1. 测试对象功能复杂化，被测对象的功能越来越多，越来越全面。
2. 迭代快速化，软件从设计到交付的时间周期越来越短。
3. 测试环境规模不断增加，被测试对象的系统规模越来越庞大。
在此基础上，本书以实战的方法，深入浅出地分析和介绍了一种模块化平台的设计方案来应对这些挑战，逐一介绍了每个模块的设计思路。这种自动化测试平台具有良好的测试用例的复用能力和功能的扩展能力，并且对于测试工程师用户来说有比较低的学习成本，能快速对测试用例开发进行上手。同时，该平台的设计能够很好的解决部署和执行问题，在CI/CD并且融入了数据驱动，事件驱动等先进的设计思想和理念。
本书还结合了当下软件企业比较重视的CI/CD流程，云端部署等热门话题， 介绍了如何将自动化测试平台集成到CI/CD的工作流程以及如何将测试平台进行云部署的转变。最后介绍了几个大型企业的经典案例。
除了设计思路和方案以外，本书会给出部分的代码实现（主要适用面向对象脚本语言Python）。本书的所有代码均已开源至GitHub。
第12章微服务化的测试平台
最近几年什么架构模式最火爆？很多人会说是微服务，因为不少互联网企业使用微服务架构创建了不少成功案例。微服务伴随着各种新技术的诞生，也为测试本身提供了很大的挑战。当然，测试平台本身也在不断进化，它也可以进化为基于微服务的平台。
微服务架构的概念是，将功能分割成一个一个可以自治管理的模块，模块通过REST API或RPC对外提供服务，它隔离了功能模块，极大地解耦了模块之间的数据，并且可以通过负载均衡技术增加单个服务的性能，从而提高整个系统的扩展能力。
在一些大型企业，自动化测试工具不再是每个部门自己的事情，而是会有专门的开发团队提供自动化测试平台的基本套件，比如某国际通信产品企业就有专门的团队提供了基于Python的自动化测试平台，并且提供了统一的部署和安装方式，以及公共的代码库，方便不同团队之间共享代码，并且整个平台是基于网络运行的，测试者如果需要执行一个新的测试平台，则只需启动一个新的Docker容器，然后在里面执行测试用例。
在互联网时代，各种大型产品不断被开发，这对测试平台本身的功能和性能也是极大的挑战，可能传统的基于网络的共享自动化测试平台也会因为单体架构而导致出现性能和维护上的问题。传统的单体架构的最大问题是可用性低，大家肯定有所体会，即便是商业版本的一些缺陷管理工具或WIKI工具，也会时常出现问题导致无法访问，并且伴随着版本的升级，服务停止的时间增多。如果是共享的自动化测试平台，这种服务停止状态是无法被接受的，因为IT部门无法协调公司内所有部门的测试任务，这种无法提供服务的状态会对一些部门的测试计划产生极大的影响。
本章我们将探索性地讨论和思考，对微服务化的自动化测试平台进行一些初探，通过一些简单的设计概念，逐渐将测试平台向微服务转化。
当然，本书不是介绍微服务及如何建立微服务的书，所以对于如何使用流行的微服务框架来建设微服务的基础设施，不在本章的探讨范围之内，读者可以自行查找一些书籍对微服务本身进行更深入的理解和学习。
通过本章你将基本了解：
· 什么是微服务，以及为什么要使用微服务架构。
· 如何将测试平台转化为微服务平台。
在讲微服务架构的概念之前，我们先回顾一下软件架构发展的历史，了解一下各种架构模式的特点及痛点。这样，我们可以更好地了解微服务产生的背景，以及所能解决的问题。
软件从计算机诞生到现在，基本上经历了如下几个阶段。
12.1.1 Monolith单体架构
在2.2.1节中，我们介绍了一些基本的Monolith架构的情况，下面来回顾一下，如图2-1所示。
早期的软件运行于单系统中，功能比较单一，所有代码都放在一个项目中，功能上没有明确的边界定义，可能会出现模块之间直接进行函数调用的情况。这种情况当然在现代软件设计中是完全不被允许的，这样会破坏封装性。不过在早期的软件设计中，或者在现代软件制作的PoC阶段，这种从0到1的模式可以很快地将软件的功能展现出来，并且方便调试。
传统的单体架构中，所有功能都在一个服务内，功能模块之间通过代码级别的引用建立依赖关系。
如果我们需要修改其中一个模块的功能，就要考虑此模块的依赖关系，以防对其他功能产生影响。而且随着功能越来越多，整个系统会越来越庞大，最终发展到难以维护的地步。随着业务的发展，系统的访问量增加，系统性能和并发能力就会受到考验。
单体架构的缺点主要体现在以下几方面：
第一，扩展能力有限。比如我们在实现一个单体的管理系统的时候，一开始用户不多，进行的操作也不复杂，一台计算机就能满足其性能需求，但是随着用户增加，功能也越来越多，原来的计算机性能就不够用了。此时我们就要通过对计算机进行升级来满足其性能需求，但是到了后期，可能升级计算机硬件也无法进一步提升性能。
第二，有很强的耦合逻辑，修改系统代码要极其小心，我们经常会看到或听到一些人说，某个组织的系统，没有人敢对代码进行升级，因为谁都不知道，修改了这一块代码会影响多少其他代码，其实这并不是笑话。
第三，系统的升级非常麻烦。对于小型软件，重新安装就可以，但是大型的企业平台，整个平台下线就会有非常大的效率问题，这与高可用性是背道而驰的。并且一旦有一个问题需要被修复，整个项目就要被重新打包。
当然并不是说单体架构就一定不好，因为单体架构也在不断发展，比如单体架构中的分层架构、前后端分离等，都是非常好的架构模式，甚至不管是分布式架构、SOA，还是微服务，都还有单体架构的思想在其中，甚至是这些方法的延续。
12.1.2 分布式架构和SOA
说到分布式我们不得不提SOA，Service-Oriented Architecture，其基本概念是通过代码功能的分离，使得每个功能都可以作为一个服务单独部署。并且服务和服务之间进行了充分的解耦，每个服务都有其明确的功能边界，服务之间的相互调用则通过中立的契约来描述。
这样，不同的服务可以由不同的平台进行实现，比如对于需要高性能的服务可以使用C++来开发，而对于需要高速开发和快速功能迭代的，可以使用Python或Java。
分布式架构基于网络的服务器架构集群，可以方便地进行流量负载均衡操作，并且当一个服务所部署的服务器出现性能瓶颈时，我们可以通过升级该服务器或者增加服务器集群来提升服务的性能。
12.1.3 微服务
其实微服务和SOA有类似之处，都是将模块组件服务化，每个服务通过API对外提供特定的服务。但是微服务有其自身的特点，相较于SOA，它更加组件化，从而会生成更多的自治服务模块。James Lewis和Martin Fowler对微服务架构的定义如下：
“微服务架构风格，简单地说，是以实现一组微服务的方式来开发一个独立的应用系统的方法。其中每个小微服务都运行在自己的进程中，一般采用基于HTTP协议的资源 API这样轻量的机制进行通信。
微服务围绕业务功能进行构建，通过全自动化的方式进行独立部署。可以使用不同的编程语言来编写，也可以使用不同的数据存储技术，并且进行最低限度的集中管理。也就是说，微服务的特点是每个服务需要运行在独立的进程中，比如容器化的Docker，通过一系列手段来进行管理。在服务崩溃的时候，可以通过重启服务或分流将调用重定向到其他服务。
我们可以看到微服务所带来的一些优点：
（1）微服务可以让开发团队分割成一个一个的小团队（1 pizza team，一个pizza可以喂饱的人数的团队），每个团队负责自己微服务的开发，小团队一般更便于管理，并具有更高的执行力。
（2）服务是高可用的，一个服务可以发起多个进程提供同样的服务，并通过负载均衡算法决定调用哪个进程的服务，这样在一个进程崩溃的时候，还有其他进程可以提供服务，从而不影响服务。
（3）横向扩展能力强，一个服务如果遇到性能瓶颈，可以通过启用更多的服务进程来达到提高并发的能力。
（4）灰度发布，微服务架构下的缺陷修复不再需要统一的版本控制，如果一个问题可以很简单地修复，并且这个服务在系统中运行了100个进程，那么我们就可以先给10个进程做升级，然后看看实际运行过程中有没有问题，即便产生了问题，也只是影响了10%的流量，可以回退版本继续修复。如果没有问题我们可以再对另外90个进程作升级。这样就可以对一些缺陷做到快速响应。
但是微服务也带来了一些显而易见的缺点：
（1）过于自治的服务导致联调会产生巨大的沟通成本，特别是对于接口的定义如果频繁变动，则会对系统的整体功能影响比较大。
（2）数据一致性问题。在微服务的架构中，服务被拆成了一小块一小块，但是有些操作需要有事务的概念，在单体系统中，我们可以通过事务锁来解决数据的竞争，但是在微服务系统中，由于服务不允许存在状态，而一个事务包含多个微服务的调用又不可避免，所以就要花更多的力气去解决数据一致性的问题。
（3）运维难度增加，在单体系统或简单的SOA系统中，代码集成和发布会比较容易。但是在微服务系统中，一旦微服务展开太多，有些大型系统甚至有成百上千的微服务需要部署，如何保证整个代码集成（CI）到自动化部署（CD）也是一个巨大的挑战。
但是无论如何，微服务依旧是大系统中被证明有着相当潜力的架构模式。
第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
温馨提示：请使用泸西县图书馆的读者帐号和密码进行登录
本书是两位作者十几年测试工具开发经验的分享，向我们全方位展示了如何构建一个灵活、高效且智能的测试平台。这类图书在市场上很少见，是我乐意推荐的一项理由。其次，它不局限于测试资源和配置管理、数据驱动、用例执行、测试报告等功能，而是扩展到微服务测试，具有灵活配置的测试引擎、测试代码和用例的自动生成等，使平台更具智能性、普适性和先进性。但让我乐意推荐本书之更强壮的理由是“得到成功案例的验证”和“已在Github上开源”。
朱少民 《全程软件测试》和《高效敏捷测试49讲》作者
在软件吞噬世界的时代，具备高效、高质量、可持续地交付客户需求的能力成为企业的核心竞争力。那么如何设计和实现一套实用的软件自动化测试平台，让质量和效率可以兼得，就显得愈发重要。本书的两位作者在自动化测试领域有很深的造诣，在多年的一线实践中积累了大量宝贵经验，通过抽象和提炼形成了一套面向实战、切实可行的自动化测试框架设计和落地方法。更难能可贵的是，本书提供了大量示例代码并开源至GitHub，让读者可以更容易地理解作者想要表达的设计思路，并且能够快速进入实战状态，从理念到落地一气呵成，是一本不可多得的测试开发的技术参考书籍。
张乐 京东 DevOps与研发效能资深专家
在现代越来越复杂的软件系统开发中，自动化测试的地位越来越重要了，系统地学习自动化测试对于测试人员来说逐渐成为一门必修课。本书通过实例的方法系统地讲解了一个自动化测试平台的各种基本模块、架构设计、编码实现等，以及两位作者多年对于自动化测试的经验和思考。我相信这些内容一定能让读者系统地学习到一个自动化测试平台的各个方面，从而帮助读者写出更好的自动化测试，或者开发出属于自己的自动化测试工具或者平台。
刘冉 ThoughtWorks首席软件测试和质量咨询师
谈到自动化测试平台，很多书都是围绕现成的测试平台的具体使用（比如数据驱动、可视化、关键字驱动等）来展开讨论的，这在测试平台产品化的层面来看是属于外行凑热闹的做法。本书从产品的角度探讨了测试平台设计和开发的各个方面，从架构师的角度介绍了平台设计和开发的过程。通过简单质朴的一行行代码，将一个个实用模块逐渐展开，简约而不简单，大繁至简。
陈霁 TestOps架构师
随着信息化的快速发展，人们对软件的需求越来越多，研发迭代的速度越来越快，因此自动化测试成为软件研发过程中必不可少的一部分。工欲善其事，必先利其器，一个高效的软件自动化测试平台尤其重要。本书从自动化测试的基本应用场景谈起，到自动化工具的设计要求，非常全面地介绍了自动化测试工具的关键要素，使读者对自动化测试有了一个基本的了解。继而又详尽地介绍了一个高效的自动化测试平台的设计和开发的方方面面，并且通过大量的实例让读者加深印象，真正做到授人以渔，是一本诚意满满的好书。
方亮 腾讯WeTest负责人