一、开源项目简介

AutoMeter-API是一款针对分布式服务，微服务API功能和性能一体的自动化测试平台，一站式解决应用，服务，API，环境管理，用例，条件，测试场景，计划，测试报告，功能/性能测试兼容支持的一体化工作平台。

二、界面展示

1.AutoMeter是一款针对分布式服务，微服务API做功能和性能一体化的自动化测试平台,一站式提供发布单元，API，环境，用例，前置条件，场景，计划，报告等管理

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图 在项目开发，迭代交付过程中开发人员，测试人员需要针对系统提供的API做调试，回归测试，性能测试。自动化测试，一个好的平台本质上需要解决API测试的5大基本问题：

1.支持不同的角色，技术人员多人协作
2.支持定义多个不同的测试环境
3.支持定义各种被测系统，API
4.支持功能，性能，回归，自动化测试
5.功能/性能明细报告，统计报告

1.运行测试的环境如何定义？

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图1

一般个人，公司在使用分布式，微服务架构，从开发到发布上线可能会经过多套环境测试验证，比如开发环境，测试环境，准生产环境，生产环境，其中测试环境又可能分为多套功能测试环境和性能测试环境，多套环境分开管理，可以有序而不相互干扰进行测试工作 每套环境由开发的发布单元(服务，站点，应用各个公司叫法不一样)，即提供api服务能力的实体，中间件(数据库，nosql，web服务器等等)这些元素组成 对于测试来说以上的元素我们需要部署到指定的服务器或者容器中整体来作为一套环境做测试工作

2.针对什么来做测试？

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图2

针对具体开发的服务(发布单元，应用，站点)，既提供API的实体，这边我们命名为发布单元，可以定义访问此服务的协议，端口。 此发布单元包含了若干个API，每个API会有对应的参数需要维护，这其实也是个人或者公司提供对内对外api能力的定义

3.设计测试用例

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图3

从个人或者公司的角度看，用例的数量和类型来决定需要做怎么样的执行，如果用例数量庞大，并且需要快速得到结果，本质上我们需要拆分用例由多机并行执行满足需求，也就是多点执行，如果需要性能的测试，执行性能的机器我们可以是低性能的多台机器发起或者是高性能的少量机器发起，所以说怎么运行是根据需要来定制执行用例的类型和机器数量

4.运行用例

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图4

根据测试业务需要，定义成多个测试集合来满足不同的测试需要，功能测试，性能测试，回归测试，CI对接自动化测试

5.获得什么样的反馈报告？

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图5

对于用例执行完，我们希望看到什么反馈，对于开发，测试，或者其他技术人员，我们希望看到运行的用例详细信息：结果状态，运行时间，请求数据，API的具体响应，我的期望，断言的详细信息，以及用例运行时的信息，对应性能来说，我们还希望能得到统计的信息，比如整体性能的时间，tps，响应时间，99%pct等，以及性能结果的多次对比

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图6

四、技术选型

架构

首先系统的架构设计是基于业务的需求出发，脱离需求谈架构都是耍流氓，那针对API的测试业务需求是什么呢？

看下现有的API，服务的测试现状：

1.使用测试工具Postman，Jmeter，完成API的功能接口测试，或者使用Testng，Junit，等其他类库，再配合读取数据，展示结果等组件搭建框架
2.针对API，服务的性能测试，使用Jmeter，Loadrunner等工具完成多次性能测试验证

上述这些传统的方式都可以完成各自的需要，但是问题是API，用例数据分散管理，功能和性能的执行使用不同的工具，站在全局的角度我们可以统一到一个平台上来完成这些工作

1.技术人员可以有统一的地方管理测试服务器，环境，API
2.然后针对API设计测试用例以及对用例数据统一维护管理
3.不同的人员可以选择不同的用例集合在不同的环境执行
4.API的测试用例在同一平台既支持功能，又支持性能的测试需求
5.用例的执行效率可以通过机器资源并行执行提升和横向扩展
6.计划，用例的执行前后支持接口，数据库，脚本等条件的运行
7.API的性能测试我们需要看到历史多次优化后的数据结果对比

基于以上这些需求，AutoMeter的架构上有如下设计

一款针对分布式服务，微服务API功能和性能一体的自动化测试平台插图7
1.后台App，管理系统前端页面的展示--Vue，打包后部署在nginx中提供访问

2.测试中心服务-TestCenterService，管理后台页面数据的接口支持，也支持从CI(Jenkins完成打包部署后)触发测试计划的执行

3.调度服务-DispathService，测试中心服务提交测试计划，调度服务将测试计划中的用例，根据规则分配给多个不同的Slaver，比如平均分配到多个测试执行机，或者指定测试执行机分配，然后定时将分配好的用例推送给不同的slaver测试执行机执行，在推送前会调用ConditionService检查是否有条件需要执行

4.条件服务-ConditionService，专门用来处理计划或者用例执行测试前后各种不同类型的条件处理，例如执行测试前需要做数据库准备，调用某些接口获取中间变量，缓存处理，返回某些数据，执行测试后处理某些操作也是同理

5.测试执行机--SlaverService，作为运行用例的实体，支持自定义功能，性能类型，支持横向扩展，启动后会注册到系统中，SlaverService会根据获取的用例去调用Jmeter执行功能或者性能测试，在Jmeter内部会调用api-jmeter-autotest的java工程，处理功能和性能的执行，以及结果的收集

五、开源协议

使用MIT开源协议

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。