AutoMeter-功能，性能一体化API自动化测试平台-架构设计

首先系统的架构设计是基于业务的需求出发，脱离需求谈架构都是耍流氓，那针对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的架构上有如下设计

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

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

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

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

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