之前写过很多自动化测试相关的文章,后台有同学留言:希望写一篇自动化测试平台的文章。他的原话是这样:目前市场上开源或者商业的自动化测试平台很多,但试用下来总感觉有些地方不太融洽,想自己落地一个适合自己团队和项目的自动化测试平台。
这种想法在我看来很正常,商业平台要考虑普适性,会大而全,也会存在客制化的诉求;而开源平台更多的是作者结合自己的经验做出来的,个人风格较为强烈。且每个团队的技术建设、项目迭代、流程规范以及人员各有区别,很难有完全适配的自动化测试平台。
这篇文章,我会以自己的实践经验结合业内部分优秀平台的设计理念,聊聊我对于设计自动化测试平台的一些想法。
平台解决了什么问题
去年曾写过一篇文章专门聊过测试平台的作用和价值。以此为例,先聊聊自动化测试平台的作用和价值。
一般在企业内,技术团队如果规模比较小,很少会专门投入资源去做平台化的事情,特别是测试团队,无论是成本预算还是技术能力,先天技术能力不足,后天可投入的资源缺乏。而平台的特点在于:通过平台将操作流程标准化,抹平不同个体间的认知和技术差异,减少重复造轮子带来的的资源浪费以及排查和解决问题的成本,进一步提高人效比。
大白话来说,就是人太多了,理解能力和技术差异太大,没那么多时间和资源浪费在不断造轮子和来回对比扯皮上,直接平台化,标准化,通过权限管理来标注操作的边界,保证大家按照同一个方向和目标甚至度量标准去做事情。
技术本身的实践、迭代和演进是一个过程,从软件工程的角度来说,测试平台就是“只做刚刚好的设计”、“先做MVP方案然后不断迭代小步快跑”这些很好的软件工程实践理念某个阶段的产物。当然,言必称平台,动则撸代码的方式,也有企业发展和个人职场生存之间的博弈成分在内。
测试平台的功能架构
回到本文的正题,要设计一个自动化测试平台,最基本也是最核心的功能有如下几点:
-
文件管理:脚本、数据的上传/下载、格式校验等功能;
-
任务管理:测试任务创建、更新、删除、批次管理
-
任务调度:测试任务执行,定时/触发等灵活的调度策略;
-
报表统计:主要包括场景、用例、任务、报告、状态等维度的数据汇总;
-
监控日志:包含测试任务的执行状态、时间、异常以及告警通知等功能;
-
节点管理:执行器(node节点)的调度、配置、状态、插件、验签等功能;
-
系统设置:用户权限、项目权限、插件管理等;
-
mock功能:隔离上下游依赖,确保任务执行的可靠性,避免外部影响;
当然,上述的功能模块是相对比较通用的,在团队内部落地时,可以根据自身具体情况进行扩展。综合上述的功能模块,自动化测试平台的功能架构,可以用下面一张图来概括(仅做示意和参考):
测试平台的技术架构
聊完了功能架构,接下来聊聊技术架构。
在我看来功能架构的设计和功能模块的划分其实是很抽象的一件事,相比于技术架构,功能架构其实更为重要。好比于一个产品的好坏其实更多的取决于如何设计,而不是用了java还是PHP。
自动化测试平台的技术架构,大致可用下图来概括(仅做示意和参考):
技术架构大致的调用关系和组件作用如下:
-
通过UI界面进行编辑和下发任务执行消息,一般采用http协议通信;
-
执行引擎支持多协议和规则格式等校验,将任务信息推送给node集群;
-
从gitlab中获取对应的自动化脚本,并推送到具体的node节点来执行任务;
-
从 S3 或其他文件管理组件中获取对应测试数据文件,并推送到node节点;
-
通过任务调度组件比如 xxjob 来进行具体的任务分配执行,以及状态管理;
-
任务执行过程产生的日志存储于es中,通过集成elk组件来做日志管理和展示;
-
任务执行完成后产生的报告数据,以及项目/场景/用例/配置等冷数据存储于mysql;
-
node内置listener,负责将任务状态和资源耗用等数据通过kafka推送到工作台展示;
上图所展示的技术架构和相关组件,仅做参考。
在实际的技术选型过程中,还是需要根据团队自身的技术栈以及需求灵活选择合适的方案。相比于自动化测试平台,我们常说的自动化测试框架,就显得很简单了。只需要编程语言+测试框架+持续集成工具+测试报告工具,就能完成基本的自动化测试工作。
平台并不是万能的,平台相比于最基本的自动化测试框架,也并没有什么优越性。根据团队的需求,技术能力以及资源预算选择合适的解决方案,才是最优解。
自动化测试的重点并不是平台,也不是选择什么高大上的框架。重点是,先让测试任务本身run起来,能快速验证和反馈结果,才是最重要的。
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。