什么是性能测试
性能测试是一种软件测试形式，重点关注运行系统的系统在特定负载下的性能。这与查找软件错误或缺陷无关。不同的性能测试类型根据基准和标准进行测量。性能测试为开发人员提供消除瓶颈所需的诊断信息。
性能测试的类型
主要的两种性能测试方法：负载测试和压力测试。但是，还有其他类型的测试方法可用于确定性能。一些例子如下：
负载测试：通常进行负载测试是为了了解系统在特定预期负载下的行为表现。此负载可以是应用程序上的预期并发用户数，该应用程序在设定的持续时间内执行特定数量的事务。该测试将给出所有重要业务关键事务的响应时间。测试期间还会监控数据库、应用服务器等，这将有助于识别应用软件和安装软件的硬件中的瓶颈。
压力测试：通常用于了解系统内的容量上限。进行这种测试是为了确定系统在极端负载方面的稳健性，并帮助应用程序管理员确定如果当前负载远高于预期的最大值，系统是否能够充分运行。
浸泡测试：也称为耐久性测试，通常用于确定系统是否能够承受持续的预期负载。在浸泡测试期间，会监控内存利用率以检测潜在的泄漏。同样重要但经常被忽视的是性能下降，即确保在长时间持续活动之后的吞吐量和响应时间与测试开始时一样好或更好。它本质上涉及在很长一段时间内向系统施加大量负载。目标是发现系统在持续使用下的行为方式。
尖峰测试：通过突然增加或减少大量用户产生的负载，并观察系统的行为来完成的。目标是确定性能是否会受到影响，系统会失败，还是能够处理负载的剧烈变化。
断点测试：断点测试类似于压力测试。随着时间的推移施加增量负载，同时监控系统的预定故障条件。断点测试有时被称为容量测试，因为可以说它确定了系统将按照其要求的规范或服务水平协议执行的最大容量。应用于固定环境的断点分析结果可用于根据所需的硬件或应触发云环境中的横向扩展事件的条件来确定最佳扩展策略。
配置测试：不是从负载角度测试性能，而是创建测试以确定系统组件的配置更改对系统性能和行为的影响。一个常见的例子是尝试不同的负载均衡方法。
隔离测试：隔离测试并不是性能测试所独有的，而是涉及重复执行导致系统问题的测试。这样的测试通常可以隔离和确认故障域。
而我们本次的测试实践采用的是负载测试。
性能测试基本流程
测试环境是设置软件、硬件和网络以执行性能测试的地方。要使用测试环境进行性能测试，开发人员可以使用以下七个步骤：
1、确定测试环境：通过识别可用的硬件、软件、网络配置和工具，测试团队可以设计测试并尽早识别性能测试挑战。性能测试环境选项包括：
·生产系统的子集，具有较少的低规格服务器
· 具有相同规格的较少服务器的生产系统子集
· 生产系统副本
· 实际生产系统
2、确定性能指标：除了确定响应时间、吞吐量和约束等指标外，还要确定性能测试的成功标准是什么，具体根据项目内团队规定。
3、计划和设计性能测试：考虑到用户可变性、测试数据和目标度量的性能测试场景，可以创建一个或两个模型。
4、配置测试环境：准备监控资源所需的测试环境机器和工具。
5、开发测试脚本
6、执行测试计划：运行性能测试，监控和捕获生成的数据。
7、分析、报告、重新测试：分析数据并分享得到的性能结论。使用相同的参数和不同的参数再次运行性能测试。
我们在后续的实践中基本会遵循这个基本流程来开发。
性能测试工具
IT 团队可以使用各种性能测试工具，具体取决于其需求和偏好。性能测试工具的一些示例包括：
JMeter：是一个 Apache 性能测试工具，可以对 Web 和应用程序服务进行负载测试。 JMeter 插件在负载测试中提供了灵活性，并涵盖了图形、线程组、计时器、函数和逻辑控制器等领域。 JMeter 支持集成开发环境 (IDE)，用于对浏览器或 Web 应用程序进行测试记录，以及用于负载测试基于 Java 的操作系统的命令行模式。
LoadRunner：由 Micro Focus 开发，用于测试和测量应用程序在负载下的性能。 LoadRunner 可以模拟成千上万的最终用户，并记录和分析负载测试。作为模拟的一部分，该软件会在应用程序组件和最终用户操作之间生成消息，类似于按键点击或鼠标移动。 LoadRunner 还包括面向云使用的版本。
NeoLoad：由 Neotys 开发，为 Web 和移动应用程序提供负载和压力测试，专门用于在发布前测试应用程序以实现 DevOps 和持续交付 IT 团队可以使用该程序来监控 Web、数据库和应用程序服务器。 NeoLoad 可以模拟数百万用户，并在内部或通过云执行测试。
本次 PingCode 负载测试用到的测试工具就是 Jmeter。
性能测试指标
许多性能指标或关键性能指标可以帮助IT团段评估当前系统的性能状况。 性能指标通常包括：
· 吞吐量：系统在指定时间内处理多少个信息单元。
· 响应时间：从用户输入的请求到系统开始响应该请求之间经过的时间量。
· 带宽：每秒可以在工作负载之间移动的数据量，通常是指通过网络。
· 每秒 CPU 中断次数：取的是平均值。指处理器每秒接收和处理的硬件中断数。
· 内存使用：计算机上进程可用的物理内存量。
· 磁盘使用：磁盘忙于执行读取或写入请求的时间量
这些指标以及其他指标可以帮助IT团队执行多种类型的性能测试。
本次负载测试实践中我们主要关注的是：吞吐量、响应时间、内存使用以及磁盘使用情况。
一次非系统性的性能测试实践
测试类型
负载测试：测试某个具体API在最大并发用户数，持续服务的5Min，得出在基准环境下的TPS和RT值。
测试范围
由于我们的API很多，在短时间无法全部测试完毕，我们采取优先测试 「访问度」高的API。
最终决定将API服务近6个月访问数量倒序排列取10个：
· 涉及的子产品： Project , Testhub , Wiki , Insight , Goals , Flow 6个子产品。
· 基础服务：Typhon 服务
测试目的
作为Pingcode项目首次性能测试，本轮测试的目的定义如下：
· 保障系统多用户情况下系统的可靠性：通过实施不同的性能测试场景，评估并验证系统在高负载下核心功能的可靠性。
· 提供一轮系统性能测试情况，为下一轮生产环境的性能测试提供基线数据。
· 评估系统部署资源的合理性：不断搜集和分析性能测试过程数据，对接下来的系统部署所需的系统资源进行评估和建议。
· 优化和解决系统性能问题：在测试过程中，优化系统各项参数和解决发现的系统性能问题。
测试指标标准
根据运维提供的在线用户数，来计算生产环境的用户 TPS，通过基准环境的测试，来验证真实的 TPS 是否满足生产环境的 TPS 需求，以及我们的运维架构和资源使用是否合理。
保证在 CPU 利用率小于80%,内存小于80%，并且没有错误的 Http 请求。
编写 API 测试
由于目前规定同一个子应用的不同api在同一个测试计划下进行，所以确保测试计划的线程组执行方式为串行：
根据实际的 API 信息修改线程组A信息，依次创建不同的线程组来完成子应用的其他 API 测试。
通过 Non-GUI 方式执行所有测试计划
命令行用法：
jmeter -n -t <testfile> -l <logfile>
示例：jmeter -n -t test.jmx -l test.jtl
讲解：以命令行的方式运行test.jmx脚本并生成test.jtl的日志报告。
-h 打印使用信息并退出
-n 非GUI模式 -> 在非GUI模式下运行JMeter
-t 测试文件<参数> ->要运行的jmeter测试(.jmx)文件。
-l 日志文件<参数> ->生成的日志文件
-H 设置要使用的JMeter代理服务器
-P 设置要使用的JMeter代理服务器端口
执行结果如下：
执行完所有测试计划后，通过 Grafana 查看 API 请求情况，根据 Influxdb 数据，统计所有 API的实际 TPS 和 RT 数据。
到这里，我们整个负载测试就完成了。接下来只需要将每个产品的 API 的实际 TPS 和 RT 情况统计下来，然后对这些数据进行分析，我们就可以得到这些 API 中哪些是需要优化的，从而达到我们本次负载测试的目的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
