一、项目简介

AutoMeter-API 是一款的自动化测试平台，专为分布式服务和微服务架构下的 API 接口设计，提供功能测试、性能测试与自动化测试的一体化解决方案。它通过项目管理、环境配置、测试用例设计、变量管理、测试计划执行、Mock 服务模拟及多维度测试报告等功能，实现从测试设计到结果分析的全流程覆盖。基于 Java 和 Vue 技术栈构建，支持分布式执行和多协议（HTTP/HTTPS、TCP 等），兼容 Jenkins 等 CI 工具，适用于微服务测试、持续集成、企业级测试管理等场景，代码开源且可灵活扩展，是测试人员高效管理接口与性能测试的综合工具。

二、项目优势

1. 多角色协作与多项目管理

支持多项目、多角色协作：开发、测试、运维等角色可协同工作，权限分离，提升团队效率。

灵活的项目管理：适配不同业务需求，支持多人同时维护测试用例、环境配置和测试计划。

2. 环境与系统定义灵活

多环境管理：支持开发、测试、准生产、生产等多套环境，环境隔离管理，避免干扰。

3. 测试用例设计高效

用例灵活定义：通过 YAML/JSON 配置文件定义 API 参数、断言规则，支持快速调试与批量复制。

4. 全面的测试类型覆盖

多功能测试：支持功能测试、性能测试、回归测试、自动化测试，满足全生命周期需求。

5. 可视化报告与通知

详细报告：功能测试展示用例状态、请求/响应数据、断言详情；性能测试统计 TPS、响应时间、99% 分位数等。

三、系统架构

3.1 技术架构

首先系统的架构设计是基于业务的需求出发，脱离需求谈架构都是耍流氓，那针对API的测试业务需求是什么呢？
看下现有的API，服务的测试现状：
1.使用测试工具Postman，Jmeter，完成API的功能接口测试，或者使用Testng，Junit，等其他类库，再配合读取数据，展示结果等组件搭建框架
2.针对API，服务的性能测试，使用Jmeter，Loadrunner等工具完成多次性能测试验证
上述这些传统的方式都可以完成各自的需要，但是问题是API，用例数据分散管理，功能和性能的执行使用不同的工具，站在全局的角度我们可以统一到一个平台上来完成这些工作
1.技术人员可以有统一的地方管理测试服务器，环境，API
2.然后针对API设计测试用例以及对用例数据统一维护管理
3.不同的人员可以选择不同的用例集合在不同的环境执行
4.API的测试用例在同一平台既支持功能，又支持性能的测试需求
5.用例的执行效率可以通过机器资源并行执行提升和横向扩展
6.计划，用例的执行前后支持接口，数据库，脚本等条件的运行
7.API的性能测试我们需要看到历史多次优化后的数据结果对比

基于以上这些需求，架构设计如下：


1.后台App，管理系统前端页面的展示–Vue，打包后部署在nginx中提供访问

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

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

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

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

3.2 开发语言与组件

前端开发：Vue+ElementUI
后端开发：SpringBoot，Redis，Mysql
测试引擎：JMeter
四、应用场景

1. 微服务架构测试

在分布式系统中，多个微服务通过 API 交互，需验证服务间接口的稳定性、功能正确性和性能指标。

2. 持续集成/持续交付（CI/CD）

在敏捷开发中，需快速验证代码变更后的 API 功能与性能，避免引入缺陷。

3. 企业级测试管理

企业需统一管理多项目、多团队的测试资源，减少工具碎片化。

4. 性能瓶颈分析与优化

需评估系统在高并发、大数据量下的性能表现（如 TPS、响应时间）。

5. 回归测试与版本迭代

在版本迭代中，需快速验证历史功能是否因新代码引入缺陷。

五、针对什么来测试

针对采用分布式服务，微服务架构开发的服务实体，我们可以定义此服务的访问协议，端口。 这些服务包含了若干个API接口，对外提供了不同的功能，每个API会有对应的参数，我们可以定义这些API接口，参数来进行自动化测试

六、设计测试用例

 设计API接口用例基础要素：用例数据，用例的断言，快捷调试等基础，支持复制，批量复制，后续支持自动生成基础用例 从个人或者公司的角度看，用例的数量和类型来决定需要做怎么样的执行，如果用例数量庞大，并且需要快速得到结果，本质上我们需要拆分用例由多机并行执行满足需求，也就是多点执行，如果需要性能的测试，执行性能的机器我们可以是低性能的多台机器发起或者是高性能的少量机器发起，所以说怎么运行是根据需要来定制执行用例的类型和机器数量
七、运行用例

根据测试业务需要，定义成多个测试集合来满足不同的测试需要，功能测试，性能测试，回归测试，CI对接自动化测试 支持立即执行，定时执行，某天执行等多种方式
八、测试报告

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

九、UI展示
 
版权声明：
1、本网站名称：帝企吧
2、本站永久网址：https://www.diqiba.com
3、本网站的文章部分内容可能来源于网络及作者投稿，仅供大家学习与参考，如有侵权，请联系站长进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报。
6、本站资源大多存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。
7、本站所有资源来源于互联网，仅用于学习及参考使用，切勿用于商业用途，如产生法律纠纷本站概不负责！ 8、资源除标明原创外均来自网络转载，版权归原作者所有，若侵犯到您权益请联系我们删除，我们将及时处理！ 9、若您需使用非免费的软件或服务，请购买正版授权并合法使用！