大家可以根据自己的项目去定制的，写完实现的方法后，要去实现对应的api。
@GetMapping("/make") public ResultVO make(@Valid PerTestParamForm perTestParamForm, BindingResult bindingResult) { if (bindingResult.hasErrors()) { throw new PanExection(ResultEmus.PARM_ERROR.getCode(), bindingResult.getFieldError().getDefaultMessage()); } String interfacecase = interfaceCaseService.makePerTest(perTestParamForm); return ResultVOUntils.success(interfacecase); } @GetMapping("/runPerServer") public ResultVO runPerServer(@Valid RunServerFrom perTestParamForm, BindingResult bindingResult) { if (bindingResult.hasErrors()) { throw new PanExection(ResultEmus.PARM_ERROR.getCode(), bindingResult.getFieldError().getDefaultMessage()); } boolean reslut = interfaceCaseService.runPerServer(perTestParamForm); if (reslut){ return ResultVOUntils.success(); } return ResultVOUntils.error("执行失败"); }
实现了两个的api。然后我们可以启动本地的代码去调试对应的程序。如果大家没有那么多的服务器可以测试的，可以参考我之前写的一篇文章。测开必杀技--docker安装Ubuntu系统实战 。
可以利用docker 虚拟化几台服务器做测试用，特别简单的。我们可以用Jmeter去打开我们的实现的脚本代码的。
最后写入还是返回我们的监控的平台
说一下这个demo的缺点。因为是一个demo，它肯定有缺点的，缺点如下。
1.数据库设计，没有前瞻性，数据库设计只是为了满足当前的开发需要，不利于后续的变更。
2.功能的实现 中。
2.1 参数是固定的。
2.2 没有参数化
2.3没有兼容到csv的大数据
2.4依赖登录没有处理
2.5断言不灵活
2.6 缺乏数据的对比
2.7 适配业务场景测试不足。
大概我现在想到的有以上的不足，当然了，这是一个需要慢慢优化的，在后续的持续迭代中，我会将上面的不足补充。
上述的就是一个大致的demo版本，大致的流程就是这样实现的，因为这是一个完整的平台，所以很多的代码的实现 都是复用原有的，大致的功能都已经能够实现的。关于整个测试平台的开发，后续有机会可以在群里给大家开放系列的课程的，目前的python版本的测试平台已经开源。放在了https://github.com/liwanlei/FXTest， 欢迎大家star，后续等这个功能 完美后，我会在维护开源的平台的时候，作为一个版本的迭代功能 坐上去。欢迎大家持续关注。
