性能测试顾名思义指的是应用软件中各项指标的负载情况。

根据百度百科的释义，性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。

性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

简而言之，性能测试目标就是为了识别并消除应用程序中的性能瓶颈。

今天，我们就以博睿数据的个别产品为例，讲讲性能测试的那些事儿。

性能测试的基本常识

首先，要想全面的认识性能测试，就要对性能测试的基本常识、术语以及性能测试的基本方法论有基本的认识。

性能测试的概念前文已经陈述，在这里我们就不再赘述。

我们来看下什么是软件性能。

软件测试是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性。

一般而言，性能测试主要包含以下5个术语：

² 响应时间：对请求做出响应需要的时间。

² 并发用户数：在同一时间段内访问系统的用户数量。

² 吞吐量：单位时间内系统处理的客户请求的数量。

² 性能计数器：描述服务器或操作系统性能的一些数据指标。

² 思考时间：休眠时间。

按照类型来划分，性能测试又分为六大类型：

l 负载测试：负载测试用于测试应用程序在正常和峰值情况下的性能。在负载测试中，我们对应用程序性能好坏的判定依据主要源于该应用程序对用户请求的响应情况，以及它在不同负载变化下（可接受的程度内）一致响应的能力来检测的。

负载测试中的核心关注点：

在应用程序出现异常情况前，该应用程序所能容纳的最大负载量是多少？

在系统变慢或出现崩溃之前，数据库所能处理的数据量有多少？

是否有任何与网络相关的问题需要解决？

l 验收性能测试：通过模拟生产运行的业务压力量和使用场景组合，测试系统性能是否满足生产性能要求。

l 压力测试：压力测试旨在寻找破坏系统的方法。该测试同时还能为我们找到系统可以承受的最大负载范围。

通常，压力测试采用增量方法，通过逐步增加负载来观察系统各项性能指标的变化情况。

首先，我们可以从应用程序已经测试过的负载开始（例如当前用户数 100 个）；然后慢慢地增加更多的负载来给系统增加压力（例如从 100 个用户数逐步增加到 10000）。

当我们发现服务器没有响应请求的那个点开始，这个点就被认为是断点（在一些性能测试报告图表中，往往也视为性能拐点）。

在压力测试过程中，我们需要关注的问题有：

系统在崩溃前能承受的最大负载是多少？

在实施压力测试过程中，系统是如何崩溃的？系统能否在崩溃后自行恢复？

被测系统/应用程序在处理异常负载时，有哪几种中断方式？

l 配置测试：通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能的影响程度，从而找到系统各项资源的最优分配原则。

l 可靠性/可恢复测试：可靠性测试或恢复测试用于验证应用程序在出现故障或异常行为后，是否能够恢复到正常状态，以及恢复阶段需要经过多长时间。

例如在某线交易站点出现故障，致使用户不能在一天的某个点（高峰时间）买卖股票，但在一两个小时后用户能够进行在线股票交易，我们就可以说该应用程序是可靠的，即有能力从异常行为中自行恢复。

l 并发测试：模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时，是否存在死锁或者其他性能问题。

了解了这些基本信息后，一个很重要的问题是如何测试性能？

博睿数据为大家整理了7个方法论：

ü SEI负载测试计划过程：关注负载测试计划的方法，包括6个关注区域：目标、用户、用例、生成环境、测试环境、测试场景。

ü RBI方法：是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法。

RBI方法基于以下事实：

1、发现的80%系统的性能瓶颈都由吞吐量制约；

2、并发用户数和吞吐量瓶颈之间存在一定的关联；

3、采用吞吐量测试可以更快速的定位问题。

需要注意的是RBI的分析方法是自上而下的：即首先确定是由并发还是吞吐量引发的性能表现限制；然后从网络、数据库、应用服务器和代码4个环节确定系统性能具体瓶颈。

ü 性能下降曲线分析：描述的是性能随用户数增加而出现下降趋势的曲线。

性能下降曲线可以分为以下几个部分：

单用户区域——对系统的单用户响应时间；对建立性能的参考值有帮助；

性能平坦区域——在不进行更多性能调优的情况下所能期望达到的最佳性能；该区域可被用作基线。

压力区域——应用轻微下降的区域；典型的、最大的建议用户负载，是压力区域的开始。

拐点——性能开始急剧下降的点。

ü LoarRunner性能测试过程：计划测试、测试设计、创建VU脚本、创建测试场景、运行测试场景、分析结果。

ü Segue提供的性能测试过程：是Segue公司Silk Performer提供的性能测试过程；适合性能调优和优化。

ü 敏捷性能测试：是随着敏捷技术发展而来的一种行的性能测试方法。

敏捷性能测试包括如下特点：

在每个迭代目标中包含明确的性能目标；

建立不同层次的性能测试——端到端、基于接口、面向具体函数；

完全或接近完全自动化的性能测试——LoadRunner、JMeter、JUnit；

使用测试驱动的方法保证性能与优化性能。

ü PTGM模型：应用于非敏捷过程的性能测试模型；分测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行与管理、测试分析6个步骤。

此外，在应用领域方面，性能测试又可细分为5个领域：

u 能力验证——在给定条件下，系统能否具有预期的能力表现。

u 规划能力——应该如何使系统具有我们要求的性能能力；如：应该如何调整，使系统能够满足增长的用户数的需要。

u 性能调优——主要应用于对系统性能进行调优。

u 发现缺陷——主要时通过性能测试的手段发现系统种存在的缺陷。

u 性能基准比较——通常应用在敏捷开发过程，是在不设定明确目标的情况下，通过比较得到每次迭代中的性能表现的变化，根据这些变化决定迭代是否达到了预期的目标。

性能测试怎么做？

那么，了解了性能测试的基本常识后，我们接下来就要了解性能测试要怎么做？

一般而言，性能测试的流程分为需求分析——测试准备——执行测试——结果分析与调优——报告与总结五个阶段。

接下来，我们具体来看下。

(1) 需求分析：

首先需要明确性能需求分析是整个性能测试工作开展的基础，如果连性能的需求都没弄清楚，后面的性能测试执行其实是没有任何意义的，而且性能需求分析做的好不好直接影响到性能测试的结果。

需求分析需要明确倒底要不要做性能测试？性能测试的目的是什么？明确被测系统是什么？被测试系统的相关技术信息如：架构、平台、协议等？明确被测系统的基本业务、关键业务，用户行为？明确性能测试点是什么？哪些需要测，为什么？哪些不需要测，又是为什么？

一般而言，需求分析可以从系统信息调研、业务信息调研、性能需求评估、性能测试点、性能指标等五方面入手。

以博睿数据的SDK 产品为例。

我们在分析需求时首先会从其架构入手分析，然后从业务层面进行分析，例如新增、活跃用户数，第一次使用和启动app（config请求）、启动以后每一分钟上报一次数据（upload请求）、controller接收请求，简单解析封装，发送到kafka、ETL从kafka上获取controller存储的数据，进行解析（解析成不同表数据，封装）、ETL解析数据后，将封装好的数据，再次上传到kafka、druid从kafka获取数据入到库中、web页面从druid中查询数据展示等等业务信息情况，最终从性能测试和性能指标入手，确定性能需求。

(2) 性能测试准备：

性能测试准备阶段又分为6个阶段：

环境准备：

a）系统运行环境：这个通常指的是我们的测试环境，有些时候需求比较多，做性能测试担心把环境搞跨了影响其它的功能测试，可能需要重新搭建一套专门用来做性能测试的环境。

b）执行机环境：这个就是用来生成负载的执行机，我们每次做性能测试都需要提前准备好执行机环境，建议执行机使用liunx系统，不要使用windows系统。

（3）场景设计：

根据性能需求分析来设计符合用户使用习惯的场景，场景设计的好不好直接影响到性能测试的效果。

（4）工具准备：

a）负载工具：根据需求分析和系统特点选择合适的负载工具，比如LR、Jmeter或galting等。

b）监控工具：准备性能测试时的服务器资源、JVM、数据库监控工具，以便进行后续的性能测试分析与调优、redis状态监控、kafka消费情况监控。

测试脚本：

如果性能测试工具不能满足被测系统的要求或只能满足部分要求时，需要我们自己开发脚本配合工具进行性能测试。

（5）测试数据：

a）用例数据。

b）负载测试数据。

其他：如果需要其它关联系统或专业人士，如DBA配合的，也需要提前进行沟通。

（6）性能结果分析：

性能结果分析则主要从两个层面出发：即性能指标与负载的简单关系和结果分析。

其中，性能指标与负载的简单关系又可分为响应时间、吞吐量、资源利用率三个层面。

首先来看响应时间。

响应时间对应的负载的关系从函数的角度理解，可以简单理解为负载随着响应时间的增加而增加的正向关系。

也就是说，响应时间突然增加，意味着系统的一种或多种资源利用可能达到的极限。通常可以利用拐点来进行性能测试分析与定位。

再来看下吞吐量。

吞吐量逐渐达到饱和意味着系统的一种或多种资源利用达到的极限。

最后说到资源利用率。

与负载对应关系可以理解为服务器某荐资源使用逐渐达到饱和。

结果分析需具体问题具体分析，一般是多项指标结合分析，通过单个指标一般得不出结论。

结果可以从以下几个方面分析：

v 执行发压机器性能是否正常。

v 被压测程序所在机器，资源是否正常。

v 依赖组件是否正常。

v 依赖组件所在机器资源是否正常。

v 宿主机机器资源是否正常。

最后需要注意的是，完整的性能测试报告以简洁为主，不需要任何推导，开发团队需要更多关于分析、比较结果的信息，以及如何获得结果的细节。

总结

不难发现要成功完成一个性能测试项目，我们需要确保性能测试计划阶段各方面的准确性。

即计划、基于测试需求分析的用例开发、场景设计、测试执行和结果分析，这些关键点都必须按照正确的方式进行，加上合理的风险预估及缓解策略。