作者：董树杰

团队：腾讯移动品质中心 TMQ

导语

UTP 自动化测试平台是 TMQ 的一个联合项目，目的是方便各项目测试人员更好地开展自动化测试建设工作，减少重复平台建设的成本，提高产品的自动化测试效率。

该平台可以提供通用的自动化执行环境和丰富的安卓云手机资源（包含安卓云模拟器），用户可以方便的把本地的自动化测试迁移到平台统一管理和调度，平台还可以通过用例拆分并发执行为自动化的执行加速，并提供丰富的报表功能。

本文主要介绍平台的架构和如何进行一步步优化的。该系列后续几篇文章，会分别对任务管理、用例管理、前段等进行详细的展开介绍和心得输出。

1 UTP 初设计

UTP 在设计之处就把系统划分为了任务管理、用例管理、资源管理和报表管理四个子系统，各个子系统由不同的开发人员负责开发，能独立运作提供不同类型的服务，也可以提供组合的服务，或者与其他系统对接组合服务。

UTP 在初期是基于传统的 web 服务的模式快速搭建了整个系统，所以这些子系统各自都是部署在一个 web 容器中的 web 服务。在功能上划分，任务管理系统，主要做自动化测试任务的配置和调度，还要做构建平台（如 RDM）的关联，是用户交互的核心，web 端用 php 实现、后台逻辑用 python。其他几个子系统都是 java 的 web，用例系统主要负责用例的解析和配置，并发执行的时候也通过用例系统拆分；资源系统负责对接和管理优测的云手机资源以及本地手机资源，并负责封装自动化测试任务到 jenkins 系统；报表系统负责测试结果的上报和展示；jenkins 主要是负责测试任务的执行和测试执行集群的管理。测试执行集群初期是 2 台实体机。

基于此种架构和实现，系统初期是遇到了很多问题，尤其是自动化的执行数量上来之后，系统可用性很差。

（1）系统整体异常，常见有由某个子系统引起的 oom，另外个别子服务发布重启的相互影响；

（2）单个子系统故障传递，导致其他子系统调用异常；

（3）单个自动化测试任务执行过程中异常情况很多，包括由网络波动引起的云手机断线、云手机适配、执行机资源不足 oom 等；

（4）执行机资源隔离不足，容易相互影响，比如 adb 挂了该执行机上所有的任务都不能正常执行；

（5）jenkins 二次开发带来的 bug，之前各个测试团队也经常用 jenkins 作为持续集成或者测试的驱动平台，很方便，但做二次开发的时候没有足够的预研和经验，一是容易自己带来很多 bug，二是使用各种插件的过程中也容易遇到很多 bug；

（6）第三方平台依赖问题，对第三方服务异常没有做隔离，导致整体服务异常。

2 架构优化之服务隔离和能力提升

基于当前的服务现状，首先要解决的是服务的可用性和稳定性问题，让服务自身能稳定的提供服务。首先要解决的问题是服务隔离，各个子系统的服务，首先要独立运行在独立的环境中，互不影响，利用公司的现有的隔离平台很方便的就能实现服务隔离的目的，而且能根据业务的发展动态的扩容各个子服务。执行机并行执行任务的时候也存在相互影响的情况，所以执行机集群也要迁移，而且通过隔离平台动态创建实例可以更合理的增减执行集群的资源，每个执行机实例只负责一个任务的执行，这就做到了自动化任务执行的隔离，而且出现单台机器 adb 故障对其他任务的影响极大减小了。

通过隔离平台扩容服务的实例，再通过负载均衡和错误重试的基础能力，去掉了各个子系统服务的单点状态，进一步提升了服务的可用性，基本消减了单个子服务异常或者子服务的发布造成的短期不可用的影响，并且可以在单个节点出现异常或者超时的时候自动进行重试。

基于隔离平台的分区域部署能力，调整了执行机的部署配置，通过就近原则（部署位置离优测云服务最近的 idc），之前执行任务的时候出现的云手机断线情况也得到了明显的改善。

3 架构优化之服务拆分

在整体子系统隔离后，又进一步在各个子系统内部做了逻辑划分，朝着微服务又进了一步，比如报表管理模块，经常出现用户上报的测试结果内容太大导致整体服务挂掉的情况，连带影响了报表系统的其他对外接口和 web 服务，这样报表系统就专门划分除了一个结果上报的服务，只提供结果上报的服务，其他的作为另外一个独立的服务；资源系统也把手机资源的管理独立成一个服务，与 jenkins 的对接也做成一个独立的服务。

4 架构优化之服务容错 #

在服务隔离和划分的情况下，涉及的服务越来越多，调用链越来越长，另外服务实例的增长也带来了更多的单点故障风险，从而使得整体流程可能因为一个服务节点故障而中断。这就要做好服务容错，前面提到了已经处理了子服务的单点故障，另外加上了在子服务间的接口调用的逻辑重试，基本保证了偶发的异常情况。

另外一个需要做好服务容错的是第三方服务的容错，之前主要碰到的问题是内部的云存储平台的故障，而 UTP 把自动化执行的任务、资源、结果等文件都存储在那里，当云存储平台偶发严重故障的时候，UTP 也连带不可用。在容错方面，UTP 专门剥离出来了一个文件服务，通过本地文件和网络文件双源共存的方式，使得在云存储平台故障或者有波动的情况下，UTP 仍旧能够使用本地文件执行自动化测试。当然本地文件有个问题就是需要定期清理以避免磁盘空间的持续上涨，这可能导致部分资源本地缺损的，但基本上近期的任务资源等文件都能命中本地资源。通过这种方法做到了的服务降级，在有损的情况下保证了服务的可用性。另外通过本地资源的命中，做到了热点数据本地化，减轻了与云存储平台交互的网络负担，也优化了任务资源文件下载的网络延时。

5 总结和心得

经过一系列的优化，UTP 的整体服务的稳定性终于提升上来可以提供稳定的自动化服务了，而这些处理也基本上是本着微服务的架构思想不断优化。UTP 虽然不属于大请求量的服务，但是本身的业务逻辑比较复杂，涉及的子系统比较多，一个良好的架构能快速支撑服务的不断发展，如果一开始没做好架构设计，可能就会陷入各种问题中难以提升。

如果你来设计一个自动化测试平台系统，你觉得最需要考虑的是哪些点呢？架构怎么设计呢？

版权所属，禁止转载

扫描下方二维码，关注微信公众号：腾讯移动品质中心 TMQ，获取更多测试干货！