大型全球化电商网站的全局测试基础架构设计
该测试基础架构,包括了 6 种不同的测试服务,分别是:统一测试执行服务、统一测试数据服务、全局测试配置服务、测试报告服务、测试执行环境准备服务,以及被测系统部署服务。
统一测试执行服务
以 Restful API 的形式对外提供测试执行服务的方式,兼具了测试版本管理、Jenkins 测试 Job 管理,以及测试执行结果管理的能力。
统一测试数据服务
凡需要准备测试数据的,都可以通过 Restful API 调用统一测试数据服务,然后由它在被测系统中实际创建或者搜索符合要求的测试数据。
测试执行环境准备服务
指具体执行测试的测试执行机器集群:对于 GUI 自动化测试来说,指的就是 Selenium Grid;对于 API 测试来说,指的就是实际发起 API 调用的测试执行机器集群。
测试执行环境准备服务的使用方式,一般有两种:
- 一种是,由统一测试执行服务根据测试负载情况,主动调用测试执行环境准备服务来完成测试执行机的准备,比如启动并挂载更多的 Node 到 Selenium Grid 中;
- 另一种是,测试执行环境准备服务不直接和统一测试执行服务打交道,而是由它自己根据测试负载来动态计算测试集群的规模,并完成测试执行集群的扩容与收缩。
被测系统部署服务
被测系统部署服务,主要被用来安装部署被测系统和软件。其实现原理是,调用 DevOps 团队的软件安装和部署脚本。
- 对于那些可以直接用命名行安装和部署的软件来说很简单,一般只需要把人工安装步骤的命名行组织成脚本文件,并加入必要的日志输出和错误处理即可。
- 对于那些通过图形界面安装的软件,一般需要找出静默(Silent)模式的安装方式,然后通过命令行安装。
测试报告服务
测试报告服务的实现中引入了一个 NoSQL 数据库,用于存储结构各异的测试报告元数据。
全局测试配置服务
根据配置文件动态获取配置值
大型全球化电商网站测试基础架构的使用实例
首先,CI/CD 流水线脚本会以异步或者同步的方式调用被测系统部署服务,安装部署被测软件的正确版本。这里,被测系统部署服务会访问对应软件安装包的存储位置,并将安装包下载到被测环境中,然后调用对应的部署脚本完成被测软件的安装。之后,CI/CD 脚本中会启动被测软件,并验证新安装的软件是否可以正常启动,如果这些都没问题的话,被测系统部署服务就完成了任务。
这里需要注意的是:
- 如果之前的 CI/CD 脚本是以同步方式调用的被测系统部署服务,那么只有当部署、启动和验证全部通过后,被测系统部署服务才会返回,然后 CI/CD 脚本才能继续执行;
- 如果之前的 CI/CD 脚本是以异步方式调用的被测系统部署服务,那么被测系统部署服务会立即返回,然后等部署、启动和验证全部通过后,才会以回调的形式通知 CI/CD 脚本。因此,CI/CD 脚本也要为此做特殊处理。
被测系统部署完成后,CI/CD 脚本就会调用统一测试执行服务。统一测试执行服务会根据之前部署的被测软件版本选择对应的测试用例版本,然后从代码仓库中下载测试用例的 Jar 包。
接下来,统一测试执行服务会将测试用例的数量、浏览器的要求,以及需要执行完成的时间作为参数,调用测试执行环境准备服务。
测试执行环境准备服务会根据传过来的参数,动态计算所需的 Node 类型和数量,然后根据计算结果动态加载更多的基于 Docker 的 Selenium Node 到测试执行集群中。此时,动态 Node 加载是基于轻量级的 Docker 技术实现的,所以 Node 的启动与挂载速度都非常快。
因此,统一测试执行服务通常以同步的方式调用测试执行环境准备服务。
测试执行环境准备好之后,统一测试执行服务就会通过 Jenkins Job 发起测试的执行。测试用例执行过程中,会依赖统一测试数据服务来准备测试需要用到的数据,并通过全局测试配置服务获取测试相关的配置与参数。
同时,在测试执行结束后,还会自动将测试报告以及测试报告的元数据发送给测试报告服务进行统一管理。