如何设计一个自动化测试平台

之前写过很多自动化测试相关的文章，后台有同学留言：希望写一篇自动化测试平台的文章。

他的原话是这样：目前市场上开源或者商业的自动化测试平台很多，但试用下来总感觉有些地方不太融洽，想自己落地一个适合自己团队和项目的自动化测试平台。

这种想法在我看来很正常，商业平台要考虑普适性，会大而全，也会存在客制化的诉求；而开源平台更多的是作者结合自己的经验做出来的，个人风格较为强烈。且每个团队的技术建设、项目迭代、流程规范以及人员各有区别，很难有完全适配的自动化测试平台。

这篇文章，我会以自己的实践经验结合业内部分优秀平台的设计理念，聊聊我对于设计自动化测试平台的一些想法。

平台解决了什么问题

去年曾写过一篇文章专门聊过测试平台的作用和价值，详情见：《测试平台解决了什么问题》。以此为例，先聊聊自动化测试平台的作用和价值。

一般在企业内，技术团队如果规模比较小，很少会专门投入资源去做平台化的事情，特别是测试团队，无论是成本预算还是技术能力，先天技术能力不足，后天可投入的资源缺乏。而平台的特点在于：通过平台将操作流程标准化，抹平不同个体间的认知和技术差异，减少重复造轮子带来的的资源浪费以及排查和解决问题的成本，进一步提高人效比。

大白话来说，就是人太多了，理解能力和技术差异太大，没那么多时间和资源浪费在不断造轮子和来回对比扯皮上，直接平台化，标准化，通过权限管理来标注操作的边界，保证大家按照同一个方向和目标甚至度量标准去做事情。

技术本身的实践、迭代和演进是一个过程，从软件工程的角度来说，测试平台就是“只做刚刚好的设计”、“先做 MVP 方案然后不断迭代小步快跑”这些很好的软件工程实践理念某个阶段的产物。当然，言必称平台，动则撸代码的方式，也有企业发展和个人职场生存之间的博弈成分在内。

测试平台的功能架构

回到本文的正题，要设计一个自动化测试平台，最基本也是最核心的功能有如下几点：

• 文件管理：脚本、数据的上传/下载、格式校验等功能；

• 任务管理：测试任务创建、更新、删除、批次管理

• 任务调度：测试任务执行，定时/触发等灵活的调度策略；

• 报表统计：主要包括场景、用例、任务、报告、状态等维度的数据汇总；

• 监控日志：包含测试任务的执行状态、时间、异常以及告警通知等功能；

• 节点管理：执行器(node 节点)的调度、配置、状态、插件、验签等功能；

• 系统设置：用户权限、项目权限、插件管理等；

• mock 功能：隔离上下游依赖，确保任务执行的可靠性，避免外部影响；

当然，上述的功能模块是相对比较通用的，在团队内部落地时，可以根据自身具体情况进行扩展。综合上述的功能模块，自动化测试平台的功能架构，可以用下面一张图来概括（仅做示意和参考）：

测试平台的技术架构

聊完了功能架构，接下来聊聊技术架构。

在我看来功能架构的设计和功能模块的划分其实是很抽象的一件事，相比于技术架构，功能架构其实更为重要。好比与一个产品的好坏其实更多的取决于如何设计，而不是用了 java 还是 PHP。

自动化测试平台的技术架构，大致可用下图来概括（仅做示意和参考）：

技术架构大致的调用关系和组件作用如下：

• 通过 UI 界面进行编辑和下发任务执行消息，一般采用 http 协议通信；

• 执行引擎支持多协议和规则格式等校验，将任务信息推送给 node 集群；

• 从 gitlab 中获取对应的自动化脚本，并推送到具体的 node 节点来执行任务；

• 从 S3 或其他文件管理组件中获取对应测试数据文件，并推送到 node 节点；

• 通过任务调度组件比如 xxjob 来进行具体的任务分配执行，以及状态管理；

• 任务执行过程产生的日志存储于 es 中，通过集成 elk 组件来做日志管理和展示；

• 任务执行完成后产生的报告数据，以及项目/场景/用例/配置等冷数据存储于 mysql；

• node 节点内置 listener，负责将任务状态和资源耗用等数据通过 kafka 推送到工作台展示；

上图所展示的技术架构和相关组件，仅做参考。

在实际的技术选型过程中，还是需要根据团队自身的技术栈以及需求灵活选择合适的方案。相比于自动化测试平台，我们常说的自动化测试框架，就显得很简单了。只需要编程语言+测试框架+持续集成工具+测试报告工具，就能完成基本的自动化测试工作。

平台并不是万能的，平台相比于最基本的自动化测试框架，也并没有什么优越性。根据团队的需求，技术能力以及资源预算选择合适的解决方案，才是最优解。

自动化测试的重点并不是平台，也不是选择什么高大上的框架。重点是，先让测试任务本身 run 起来，能快速的验证和反馈结果，才是最重要的。