性能测试是软件测试中的重要一环，今天给大家介绍性能测试及如何使用 RunnerGo 完成性能测试任务。
一句话概括：不断地通过不同场景的系统表现去探究系统设计与资源消耗之间的平衡，为开发人员提供消除瓶颈所需的诊断信息。
测试类型：
性能测试中常用的性能有：负载测试、压力测试两种。
负载测试（ Load Testing ）主要是通过逐渐增加系统负载，如并发用户数、数据量等，来测试系统的性能变化。测试的目的是确定在满足性能指标的情况下，系统所能承受的最大负载量。负载测试通常从较小的负载开始，逐渐增加并发数和数据量，观察并记录不同负载下系统的各项指标，直至系统无法承受而崩溃或服务不可用。
压力测试（ Stress Testing ）则更侧重于测试系统的限制和故障恢复能力，通常是在超强的、近乎会导致系统崩溃的负荷（如大数据量、大量并发用户等）下进行。这种测试方法旨在观察系统在极限负荷下的性能变化，如 CPU 利用率、内存使用率、磁盘 I/O 吞吐率、网络吞吐量等，以及系统是否会出现内存泄漏、功能性故障等问题。压力测试包括稳定性压力测试和破坏性压力测试。稳定性压力测试是在选定的压力值下长时间持续运行，以考察各项性能指标是否在指定范围内；而破坏性压力测试则是通过继续加压的手段，使系统迅速崩溃，以暴露潜在的问题。
不同的测试类型需要配置不同的测试脚本，如我们常用的阶梯压测、高并发的压力测试等等。通过 RunnerGo 内置的六种压测模式可以满足多种性能测试类型。
常见的测试指标：
确定测试指标：** **
实际我们在测试时，只要不报错我们关注吞吐量、响应时间就可以了。测试指标需要根据以下两点进行确定：
并发压力测试 tps 计算：
在开始计算前需要了解三个概念：
TPS 计算公式为：tps=持续时长/总请求数
秒杀活动压测数据计算
假如平台总注册用户数有 100w ，有 10w 用户约定好同时对某一接口进行访问，比如 1 分钟，陆续来访 10w 用户，那么我们系统并发用户是比实际的 10w 要小的
那一个秒杀活动开始时，10w 用户在 10 秒内重复请求多次，平均 3 次每个人，那么 tps=100000/10=10000tps ，表明我们目标的 tps 应达到 10000 才能抗住 100000 用户的同时请求
领券活动压测
平台注册用户数 100w ，用 10w 用户准备抢券，即 10w 人同时在 10 秒内访问抢券接口，在过程中每个用户可能会多次点击抢券，估算每个用户点击 3 次抢券接口，那么
tps=100000*3/10=30000tps ，系统的目标 tps 需达到 30000 才抗住 10w 用户的并发访问压力
RunnerGo 支持单接口压测和场景压测。并且使用 RunnerGo 做性能时只需简单几个操作：
单接口压测：
每个接口在测试完成后可以在一键压测处进行单接口压测，同样支持测试模式选择：
场景压测：
RunnerGo 可以创建测试场景，在场景的基础上进行场景性能测试，在右侧任务配置栏，根据需求配置控制模式、压测模式并配置并发数即可开始测试。
开始测试：
这里我们使用 RunnerGo 对单个商品评论接口进行一次阶梯模式的压力测试：
配置如下图：（配置完成后会显示加压梯度图）
测试完成后 RunnerGo 会提供可视化图形测试报告，测试人员根据预定的测试指标进行多次调节从而得到 API 请求的实际 TPS 和 RT 再与理想中 TPS 和 RT 做对比，来确定当前 API 性能情况。
还可查看 debug 日志和压力机情况对测试结果进行分析：
除此之外，RunnerGo 在进行性能测试时还支持分布式服务器部署、接口权重、服务器权重配置，更好地满足性能测试需求。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.