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

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

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

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

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

平台解决了什么问题

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

一般在企业内，技术团队如果规模比较小，很少会专门投入资源去做平台化的事情，特别是测试团队，无论是成本预算还是技术能力，先天技术能力不足，后天可投入的资源缺乏。

而平台的特点在于：通过平台将操作流程标准化，抹平不同个体间的认知和技术差异，减少重复造轮子带来的的资源浪费以及排查和解决问题的成本，进一步提高人效比。

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

技术本身的实践、迭代和演进是一个过程，从软件工程的角度来说，测试平台就是“只做刚刚好的设计”、“先做MVP方案然后不断迭代小步快跑”这些很好的软件工程实践理念某个阶段的产物。

当然，言必称平台，动则撸代码的方式，也有企业发展和个人职场生存之间的博弈成分在内。

测试平台的功能架构

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

• 文件管理：脚本、数据的上传/下载、格式校验等功能；
• 任务管理：测试任务创建、更新、删除、批次管理
• 任务调度：测试任务执行，定时/触发等灵活的调度策略；
• 报表统计：主要包括场景、用例、任务、报告、状态等维度的数据汇总；
• 监控日志：包含测试任务的执行状态、时间、异常以及告警通知等功能；
• 节点管理：执行器(node节点)的调度、配置、状态、插件、验签等功能；
• 系统设置：用户权限、项目权限、插件管理等；
• mock功能：隔离上下游依赖，确保任务执行的可靠性，避免外部影响；

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

测试平台的技术架构

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

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

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

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

• 通过UI界面进行编辑和下发任务执行消息，一般采用http协议通信；
• 执行引擎支持多协议和规则格式等校验，将任务信息推送给node集群；
• 从gitlab中获取对应的自动化脚本，并推送到具体的node节点来执行任务；
• 从 S3 或其他文件管理组件中获取对应测试数据文件，并推送到node节点；
• 通过任务调度组件比如 xxjob 来进行具体的任务分配执行，以及状态管理；
• 任务执行过程产生的日志存储于es中，通过集成elk组件来做日志管理和展示；
• 任务执行完成后产生的报告数据，以及项目/场景/用例/配置等冷数据存储于mysql；
• node节点内置listener，负责将任务状态和资源耗用等数据通过kafka推送到工作台展示；

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

在实际的技术选型过程中，还是需要根据团队自身的技术栈以及需求灵活选择合适的方案。

相比于自动化测试平台，我们常说的自动化测试框架，就显得很简单了。只需要编程语言+测试框架+持续集成工具+测试报告工具，就能完成基本的自动化测试工作。

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

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