5.4 测试中台
测试中台的设计思路可以总结为“测试服务化”。也就是说，测试过程中需要使用的任何 功能都通过服务的形式提供，每类服务完成一类特定功能，这些服务可以采用最适合自身的技 术栈，独立开发、独立部署。至于需要哪些测试服务，则是在理解测试基础架构的内涵并高度 抽象后得到的。从本质上看，这种设计思路和微服务不谋而合。
根据业内的大量实践与经验总结，我们把理想中的测试中台的顶层设计概括为图 5-17 所 示的形式。
我们理想中的测试中台包括 6 种不同的测试服务，分别是统一测试执行服务、统一测试数 据服务、全局测试配置服务、测试报告服务、测试执行环境准备服务以及被测系统部署服务。 接下来，我们一起看看这 6 种测试服务具体是什么。
图 5-17 测试中台的顶层设计
5.4.1 统一测试执行服务
统一测试执行服务其实和统一测试执行平台是同一个概念，只不过统一测试执行服务强调 的是服务，也就是强调测试执行的发起是通过 Restful API 调用完成的。以 Restful API 的形式 对外提供测试执行服务的方式，兼具测试版本管理、Jenkins Job 管理以及测试执行结果管理的 能力。
统一测试执行服务的主要原理是，通过 Spring Boot 框架提供 Restful API，在内部实现通 过调度 Jenkins Job 发起测试，这也是前面测试基础架构中的内容。还记得前面提到的将测试 发起与 CI/CD 流水线集成的内容吗？统一测试执行服务采用的 Restful API 调用，我们可以通 过统一的 Restful API 来发起测试。
5.4.2 统一测试数据服务
统一测试数据服务其实就是统一测试数据平台。对于需要准备测试数据的任何测试，都可 以通过 Restful API 调用统一测试数据服务，然后由统一测试数据服务在被测系统中实际创建 或搜索符合要求的测试数据。而对于测试数据的使用者来说，具体的测试数据创建或搜索的细 节是不需要知道的。也就是说，统一测试数据服务会帮助我们隐藏测试数据准备的所有相关细 节。同时，在统一测试数据服务内部，通常会引入内部数据库管理测试元数据，并提供有效测 试数据数量自动补全、测试数据质量监控等高级功能。
在实际项目中，测试数据的创建通常是通过调用测试数据准备函数来完成的，而这些函数 内部主要通过 API 和数据库操作相结合的方式，实际创建测试数据。
5.4.3 测试执行环境准备服务
这里的“测试执行环境”是一个狭义的概念，指具体执行测试的测试执行集群：对于 GUI 自动化测试来说，指的是 Selenium Grid ；对于 API 测试来说，指的是实际发起 API 调用的测 试执行集群。
测试执行环境准备服务的使用方式一般有如下两种。
·根据测试负载情况，由统一测试执行服务主动调用测试执行环境准备服务来完成测试 执行机的准备，比如启动并挂载更多的 Node 到 Selenium Grid 中。
· 测试执行环境准备服务不直接和统一测试执行服务打交道，而是自行根据测试负载动 态计算测试执行集群的规模，并完成测试执行集群的扩容与收缩。
5.4.4 被测系统部署服务
被测系统部署服务主要用来安装与部署被测系统和软件，实现原理是调用 DevOps 团队的 软件安装和部署脚本。
· 对于那些可以直接用命令行安装的软件来说，一般只需要把安装步骤的命令行组织成 脚本文件，并加入必要的日志输出和错误处理即可安装。
· 对于那些通过图形界面安装的软件，一般需要找出静默（silent）安装模式，然后通过 命令行安装。
如果被测软件安装包本身不支持静默安装模式，那么强烈建议给软件发布工程师提需求， 要求他们加入对静默安装模式的支持。
被测系统部署服务一般由 CI/CD 流水线脚本来调用。在没有被测系统部署服务之前，我 们在 CI/CD 流水线脚本中一般直接调用软件安装和部署脚本；而在引入被测系统部署服务后， 就可以在 CI/CD 流水线脚本中直接以 Restful API 的形式调用标准化的被测系统部署服务，这 样做的好处是可以实现 CI/CD 流水线脚本与具体的软件安装和部署脚本的解耦。
5.4.5 测试报告服务
测试报告服务也是测试基础架构的重要组成部分，主要作用是为测试提供详细的报告。测 试报告服务的实现原理和传统测试报告的区别较大。
传统的测试报告（比如 TestNG 执行结束后的测试报告以及 HttpRunner 执行结束后的测试 报告等）通常直接由测试框架产生。也就是说，测试报告和测试框架绑定在一起。
对于大型软件项目而言，因为各个阶段都会有不同类型的测试，所以测试框架本身就具有 多样性，对应的测试报告也多种多样。而测试报告服务的设计初衷，就是希望统一管理这些格 式各异、形式多样的测试报告，同时希望从这些测试报告中总结出面向管理层的统计数据。
为此，我们在测试报告服务的实现中引入了 NoSQL 数据库，用于存储结构各异的测试报 告元数据。在实际项目中，我们会改造每个需要使用测试报告服务的测试框架，使其在执行完 测试后将测试报告的元数据存入测试报告服务的 NoSQL 数据库中。这样在需要访问测试报告 的时候，直接从测试报告服务中提取即可。
同时，由于各种测试报告的元数据都存放在一个 NoSQL 数据库中，因此我们可以开发一 些用于统计分析的 SQL 脚本，以帮助我们获得与软件质量相关的统计数据。
测试报告服务的主要使用者是统一测试执行服务和测试工程师。对于统一测试执行服务来 说，它会调用测试报告服务以获取测试报告，并将其与测试执行记录绑定，然后进行显示。测 试工程师则可以通过测试报告服务这个入口，获取自己想要的测试报告。
5.4.6 全局测试配置服务
全局测试配置服务用于解决测试配置和测试代码的耦合问题。这个概念有点抽象，下面让 我们一起来看一个例子。
大型全球化电商网站在全球很多地区都有站点，这些站点的基本功能是相同的，只是某些 小的功能点会有地域差异。
假设在测试过程中需要设计一个 getCurrencyCode() 函数来获取货币符号，那么这个函数 中势必会有很多 if-else 语句，用于根据不同国家或地区返回不同的货币符号。图5-18 所示的 代码展示了全局测试配置服务的基本原理。
图 5-18 关于全局测试配置服务的示例代码
比如，“Before”代码段中有 4 个条件分支。如果当前国家（地区）是德国（isDESite）或 法国（isFRSite），那么货币符号应该是“EUR”；如果当前国家（地区）是英国（isUKSite）， 那么货币符号应该是“GBP”；如果当前国家（地区）是美国（isUSSite）或墨西哥（isMXSite）， 那么货币符号应该是“USD”；如果当前国家（地区）不在上述范围内，就抛出异常。
getCurrencyCode() 函数的实现逻辑比较简单，但是当需要添加新的国家（地区）和货币符 号时，就需要添加更多的 if-else 分支。当if-else 分支较多的时候，代码的分支也会很多。更 糟糕的是，当添加新的国家（地区）时，你会发现很多地方的代码需要加入分支处理，很不方便。
