文章适用于想RunnerGo入门的同学，本人主要是后端，这里做一个入门的学习记录。想深入适用RunnerGo的同学可以参考官网文档： https://wiki.runnergo.cn/docs/
这里我测试的代码是之前搭建的一个前后端分离小demo，代码地址是https://gitee.com/lihao2/error-demo.git
安装
RunnerGo是一款全栈式测试平台，目前实现了接口测试、场景自动化测试、性能测试等测试能力。
我的安装环境的虚拟机下Linux centos7，注意内存需要8G，在Linux下创建终端运行下面命令
wget https://img.cdn.apipost.cn/running_go/img/wiki/runnergo.tar && tar xf runnergo.tar && bash install.sh
出现以下内容表示安装完成
++ '[' 0 -eq 0 ']'
++ echo 'RunnerGo 启动完成'
RunnerGo 启动完成
++ break
++ echo ---------------------------------------------------------------------
---------------------------------------------------------------------
++ echo 'RunnerGo安装完成 浏览器访问IP+端口 默认端口号9998'
RunnerGo安装完成 浏览器访问IP+端口 默认端口号9998在安装的时候可能会卡住，这时候可以使用ls命令查看相关组件是下载完毕，就是runnergo.tar包，如果没有下载好则执行最开始的命令，如果下载完可以运行命令bash install.sh或者./install.sh命令重新走下安装。如果有其他问题可以参考官方文档：https://wiki.runnergo.cn/docs/zd2
安装完毕后注意开放下端口，我这里由于是本地Linux环境，所以直接关闭的防火墙
sudo systemctl stop firewalld
sudo systemctl disable firewalld
在浏览器访问对应账号http://系统IP:9998，即可进入
默认超管账号runnergo 密码runnergo
使用
安装完成后进入首先需要创建一个团队，然后点击进入团队就可以进行API的测试了
首先可以点击环境管理创建环境，这里的环境其实就是你要测试的API地址，定义好后方便后期测试接口，当然不定义每次写测试对象的时候直接写入全部地址也行，就是有些麻烦。
注意因为runnergo是在Linux下，不是在本地这里，所以如果要测试本地接口，需要接口测试时写入本地IP，不能是localhost和127.0.0.1，除非代码和runnergo是在一个Linux上
测试对象
定义好后创建点击测试对象创建测试用的接口，这里用于填写要测试的后台接口，整体内容有点像postMain，按照需求写入就好。我的后端接口如下
@RestController
@RequestMapping("item")
public class ItemController {@Autowiredprivate ItemService itemService;@PostMapping("page")public PageInfo<ItemResult> page(@RequestBody ItemParam param){Integer pageNum = param.getPageNum();Integer pageSize = param.getPageSize();PageHelper.startPage(pageNum, pageSize);List<ItemResult> list = itemService.page();return new PageInfo<>(list);}}
根据接口创建测试对象，这里的关联提取用于提取响应参数的值，主要是在场景里面使用
场景管理
场景用于多个接口的综合处理，根据业务可以定义多个接口进行统一调用测试，并且可以设置控制器在测试时进行逻辑判断。
点击 引入测试对象 就可以导入刚才创建的测试接口，这里也可以直接定义
点击接口可以选择多种不同的模式
错误率模式：如果场景中某一接口超过设置的错误率阈值，则计划自动停止；如到达最大并发数后，错误率仍没有超过错误率阈值，则继续运行稳定持续时长所设置的时长运行后结束该计划
响应时间模式：响应时间为准，如果其中有一个接口达到大于设定的阈值后则并发数不再增加，并运行稳定持续时长所设置的时长运行后结束该计划；如果到达最大并发数后仍未达到设定的阈值，则继续运行稳定持续时长所设置的时长运行后结束该计划
每秒应答模式：每秒钟发送并响应的接口数量（RPS），计算方式：RPS=接口的总请求数*接口的并发数/响应总耗时，约等于：接口的并发数/平均响应时间（s）。如果RPS大于所设阈值时，并发数会增加到最大并发数，小于阈值时，会根据设置逐渐增加
测试接口时有些参数不想设置成固定的可以定义成文档传入runnerGo，读取数据进行测试
文档可以是csv文件或者txt文件，第一行为标题，每行作为一个数据，多个数据之间逗号隔开，txt文件可以直接创建笔记本去写，如果比较多最好使用csv文件，可以通过创建一个Excel文件然后另存为csv文件。
我需要的参数是pageNum，所以创建的文件内容如下。
点击添加文件即可，在需要使用参数的位置使用双括号声明 例如{{pageNum}}
计划管理
计划其实就是场景的集合，主要就是批量的运行场景。和前面的差不多，可以直接导入场景，然后在任务配置中可以线程等相关配置。
其中控制模式分为单独模式和集中模式，两者都会先启动所有并发，不同的是单独模式是一个线程走完后立即启动一个新的，集中模式是等待设置的线程数全结束后，再启动设置的进行触发，两者就是看小说，单独是作者更了一章就看了一章，集中是养一养再一起看完。
测压模式共有6种。时间单位为秒
**并发模式：**模拟多个并发用户同时发送请求，适用于需要评估系统并发处理能力的场景
参数
持续时长：模拟并发用户操作的持续时间
并发数：发送请求的并发用户数量
**阶梯模式：**逐渐增加并发用户数量，模拟系统负载逐渐增加的情况
参数
起始并发数：开始时的用户数量
并发数步长：每个阶梯增加的并发用户数量
步长持续时长：每个阶梯增加并发用户数量所持续的时间，期间负载不断增加直到下一阶梯
最大并发数：允许的最大并发用户数量，当压测达到最大并发数后，不再增加并发用户数量
持续时长：压测过程的时间长度
**错误率模式：**用于测试系统在高错误率下的性能和稳定性。系统发送一定比例的错误请求，以场景中单个接口的错误率为测试目标，可自定义错误率，如果场景中某一接口超过设置的错误率阈值，则计划自动停止。
需要设置接口为错误率模式。参数和阶梯模式一样
**响应时间模式：**用于测量系统对请求的响应时间，该模式下，测试工具会记录每个请求的响应时间，并生成相应的统计数据和报告，以评估系统的性能和响应能力。
每个接口的响应时间和设定的阀值相比。如果其中有一个接口达到大于设定的阈值后则并发数不再增加，并运行稳定持续时长所设置的时长运行后结束该计划；如果到达最大并发数后仍未达到设定的阈值，则继续运行稳定持续时长所设置的时长运行后结束该计划。
需要设置接口模式为响应时间模式。参数和阶梯模式一样
**每秒应答数模式：**用于测试系统在单位时间内能够处理的请求数量，根据预设的每秒请求数量发送请求，以评估系统的负载能力和吞吐量。适用于需要测试系统在高负载下的性能和承载能力的场景
**轮次模式：**模拟多个测试轮次或迭代的情况，适用于需要进行持久性能测试、负载测试和压力测试的场景
参数
轮次：执行的迭代次数
并发数：同时发送请求的并发用户数量
报告列表
开始测试后就会在报告列表中显示本次的测试报告，点击即可查看详情信息
每秒应答数：系统在单位时间内处理请求并返回响应的能力，衡量了系统每秒钟能够成功处理并响应的客户端请求数量。
每秒应答成功数：系统在单位时间内成功处理并返回响应的客户端请求数量。关联到用户体验和系统稳定性
吞吐量：实际传输数据的速率，每秒完成的事务数
成功数吞吐量：单位时间内成功处理并响应的请求数量。这个指标不仅考虑了接口处理请求的速度，还强调了请求的成功率
除此之外runnerGO提供线形图显示各个数据
50%响应时间线：表示有一半的请求在这个时间或更短的时间内得到了响应，用于了解API的基础性能
90%响应时间线：表示90%的请求在这个时间或更短的时间内得到了响应，用于评估API在大多数情况下的性能表现
95%响应时间线：用于评估API在极端情况下的性能表现，如果95%的响应时间过高，那么可能意味着有少量请求遇到了严重的性能问题或延迟，这可能会影响到用户体验或系统稳定性
disk_io：磁盘的输入和输出
mem：内存，常会关注内存的读写速度、稳定性以及是否存在内存泄漏
net_io：网络输入输出，也就是网络上的发送和接收情况
响应时间过高，那么可能意味着有少量请求遇到了严重的性能问题或延迟，这可能会影响到用户体验或系统稳定性
disk_io：磁盘的输入和输出
mem：内存，常会关注内存的读写速度、稳定性以及是否存在内存泄漏
net_io：网络输入输出，也就是网络上的发送和接收情况
