TAC 自动化测试集管理系统

GitHub 传送门

前言

分享一个最近实现的一个自动化测试管理系统

• 为什么做这个东西：市面上 API 的管理和执行系统非常多，测试用例管理的系统也很多，但是管理和执行测试集的系统不多，github 上没有找到合适的，加上公司需要这么个东西。
• 为什么这么设计：想做一套基于 TestNG framework 深度定制的自动化测试管理平台
• 开发的难易程度: 前后端分离, 后端写逻辑提供接口和服务，前端通过开源工具快速构建。
• 为什么要写个分布式 Case 执行器不用 Jenkins 执行调度: 因为通过 消息队列三种模式 可以间接满足各种复杂的执行情况。
• 目前还有很多设想的功能还没实现，期望各位大佬一起 PR

一、简介

1.1 概述

TAC 是应对与 TestNG 的自动化测试用例管理系统，以 TestNG package 出的 jar 和 TestNG 的 xml 文件来驱动执行测试集。
目的在于对测试集进行管理和回归，分布式的 Case 执行器可以 应对以后大量 Case 并发执行的需求，加速回归时间。

1.2 工程介绍

• TACase 是前端项目 技术栈:React, IceWork, IceDesign
• TACase_Server 是后端项目 技术栈: Mybatis, Dubbo, SpringBoot, Thymeleaf
• TACase_Executor 是 case 执行器项目 技术栈: XXL-MQ SpringBoot

1.3 特性

• 分布式 Case 执行器: 加速执行大量回归测试集的时间
• DashBoard: 测试集，执行，浏览 数据的统计
• 简单全面： 对于测试集的管理，执行，和报告的查看
• 与 TestNG 解耦：跟 TestNG 库的关联 通过 Listener, 即对 TestNG 测试用例代码无侵入.(后期还需要继续解耦,或者合并 TestNG)
• 执行钩子: 提供相应测试集的 执行钩子 ，方便 CI

1.4 背景

Why TAC

TAC 是 TA Case 简写，在将来测试集数量多，总类多的时候，如何筛选回归用例，如果管理回归用例以及非测试开发人员还需要搭建环境来进行回归会成为一个问题

• 管理用例： 系统上对每个测试集设置了项目的字段，及搜索的功能
• 筛选用例： 每个测试集对应一个 TestNG xml 文件，使用自带的 group，及选择 package 功能进行筛选
• 执行用例： 将执行 Case 托付给 Case 执行器，可以随时对期望回归的测试集进行回归。

Why XXL-MQ

执行器用到了 XXL-MQ，是因为 XXL-MQ 是一款轻量级分布式消息队列，支持串行、并行和广播等多种消息模型，且开源

• 目前流行的 ActiveMQ、RabbitMQ 和 ZeroMQ 等消息队列的软件中，大多为了实现 AMQP，STOMP，XMPP 之类的协议，变得极其重量级 (如新版本 Activemq 建议分配内存达 1G+)，但在很多 Web 应用中的实际情况是：我们只是想找到一个缓解高并发请求的解决方案，一个轻量级的消息队列实现方式才是我们真正需要的

1.5 环境

• Zookeeper3.4+
• Jdk1.8+
• Mysql5.5+

二、系统设计

2.1 系统框架图

2.2 名词解释

• Icework: 阿里开源工具，通过 GUI 工具极速构建中后台前端应用
• QUEUE：点对点模式, 消息进去队列之后, 只会被消费一次。同一 Topic 下的多个 Consumer 并行消费消息, 吞吐量较大
• SERIAL_QUEUE：点对点模式, 消息进去队列之后, 只会被消费一次。 但是,同一个 Topic 下只会有一个 Consumer 串行消费消息, 适用于严格限制并发的场景

三、安装部署

请按照下面顺序进行安装部署

3.1 安装部署 TAC

• XXL-MQ xxl-MQ 进行消息队列来分发消息，安装 broker 即可，阅读 3.2, 3.3, 3.4 然后打出 war 包 部署在 tomcat 上 正常访问到管理平台 标识安装成功
• TAC_Server 安装
• TAC_Executor 安装

四、更新日志

v1.0.0

• TestCase 增加/管理/执行

v1.1.0

• 增加定时任务功能
• springboot 升级到 2.0.0
• 修复 case 执行状态更新 bug
• 版本升级需要 执行 TACase_Server/tac-web/resource/quartzDB.sql 和 TACase_Server/README.md 中 cron_task 建表语句

快照