全国计算机技术与软件专业技术资格（水平）考试软件评测师-考试内容总结（十四）性能测试

Posted 2020-08-21 林猪猪的部落格

全国计算机技术与软件专业技术资格（水平）考试【软件评测师】-考试内容总结（十四）性能测试

14.性能测试

14.1性能测试的定义

性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来度量。性能的及时性用响应时间或者吞吐量来衡量。而响应时间是对请求做出响应所需要的时间。

14.1.1用户角度的性能测试

比如一个典型的Web应用：用户关注的是软件对用户操作的响应时间。

此响应时间=呈现时间+系统响应时间。

 

14.1.2管理员角度的性能测试

关注系统的响应时间。对于系统管理员来说，用户客户端所消耗的时间是不考虑的。

重点就考虑系统响应时间，包括网络耗时、各服务器耗时等。还会关注系统状态，比如资源利用率、系统可扩展性、系统容量、系统稳定性。

 

14.1.3开发角度的性能测试

关注于如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现。和如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷。会从系统架构、数据库设计、代码质量等方面考虑性能。

 

14.2性能测试的主要术语

14.2.1响应时间

对请求做出响应所需要的时间。响应时间=呈现时间+系统响应时间。

其中：

(1)呈现时间：取决于数据在被客户端收到响应数据后呈现页面所消耗的时间。

(2)系统响应时间：应用系统从请求发出开始到客户端接收到数据所消耗的时间。

 

从设计角度考虑，更好的用户体验是，前端在等待数据结果时，提供进度条或逐步显示数据。

进一步分解响应时间：网络传输时间+应用延迟时间（Web服务器延迟时间+DB延迟时间）。

对于响应时间，其标准不一。一般页面的响应时间，2秒是非常有吸引力，5秒是比较不错的，10秒则是忍受的极限。视具体情况具体设置。

 

14.2.2并发用户数

系统并发用户数：同一时间内访问系统的用户数。针对的是服务器最大承载量。关注的是瞬间最大访问量。

业务并发用户数：从用户角度来说，在相当长的一段时间内，都会有基本固定数量的用户访问系统。

其中：

(1)系统用户数：使用该系统的用户总数。

(2)在线用户数：同时在线的用户数。

 

在做并发测试的时候，一般会采取两种方法：

(1)是在并发数一定的情况下，按业务不同进行测试（业务一，多少人一起使用，什么时候开始使用，使用多长时间）。这种方式更多的是业务并发测试。

(2)是在并发数一定的情况下，只做单纯一样的操作（查询、修改、添加、删除）。这种方式更多的是系统并发测试。

估算并发用户的公式：C=nL/T

其中：C为平均并发用户数；n为login session的数量；L为login session的平均时间长度；T为考察的时间段长度。

峰值并发数： m=C+3*

 

假设login session符合泊松分布。

比如：OA系统，共3000个用户，每天大约有400个用户访问，对一个用户来说，每天在线时间为4小时，而每天工作时间为8小时。则平均的并发用户为C=400*4/8=200，并发用户峰值为242。

实际应用过程中，要考虑时间的细粒度或结合业务峰值和谷值来更精确的估算并发用户。

更一般的公式是：C=n/10，即以每天访问系统用户数的10%作为平均的并发用户数

                Cm=r*C  r为调整因子，取值一般为2~3

对web服务器的日志分析，能得到更为精确的最大并发用户访问数。

 

14.2.3吞吐量

单位时间内系统处理的客户请求的数量。体现软件系统的性能承载能力。

一般描述：请求数/秒或页面数/秒。

业务角度来说，访问人数/天或处理的业务数/小时。

网络角度：字节数/天==网络流量。

 

作用：

(1)用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标；

(2)用于协助分析性能瓶颈。比如以字节数/秒主要反映受网络基础设施、服务器架构、应用服务器制约；以单击数/秒表示主要受应用服务器和应用代码的制约。

 

在未遇到性能瓶颈时，计算公式：F=Nvu*R/T。

Nvu表示虚拟用户的个数(Virtual Users)；R表示每个VU发出的请求(单击)数量；T表示测试时间。

 

14.2.4性能计算器

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

资源利用率：系统各种资源的使用状况。

 

14.2.5思考时间

思考时间Think Time：从业务角度来说，指用户在进行操作时，每个请求之间的间隔时间。

思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关系。

 

计算公式：R=T/Tt

R：每个用户发出的请求数；T为测试时间；Tt为思考时间。

 

计算思考时间的一般步骤：

(1)首先计算出系统的并发用户数；

(2)统计出系统平均的吞吐量

(3)统计出平均每个用户发出的请求数量

(4)根据上面公式计算出思考时间。

 

如果测试目的是为了验证应用系统具有预期的能力，即能力验证，则尽量模拟用户真实的思考时间；如果是更一般的研究，了解系统在压力下的性能水平或了解系统承受压力的能力，即规划能力，则可考虑0思考时间。

 

14.3性能测试方法

14.3.1性能测试(Performance Testing)

模拟生产运行压力量和使用场景组合，测试系统的性能是否满足生产性能要求。在特定的运行条件下验证系统的能力状况。

确定用户场景、给出需要关注的性能指标、测试执行和测试分析。

性能目标描述：系统在100个并发用户下进行某种业务操作，响应时间不超过5秒。

 

14.3.2负载测试(Load Testing)

通过在被测系统上不断增加压力，直到性能指标。找到系统的处理极限，为系统调优提供数据。亦称为可量性测试(Scalability Testing)。

极限描述：在给定条件下最多允许120个并发用户访问 或 在给定条件下最多在1小时内处理2100笔业务。

预期的性能指标：响应时间不超过10S 或 服务器平均CPU利用率低于65%。

 

14.3.3压力测试(Stress Testing)

测试系统在一定饱和状态下，如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。

(1)主要目的是检察系统处于压力情况下时，应用的表现。通过增加访问压力，如增加并发用户，使应用系统的资源使用保持在一定的水平。检测此时的表现，有无错误信息，响应时间等。

(2)通过模拟负载等方法，使系统的资源使用达到较高的水平。比如设定为“CPU 75%，内存70%”情况下，有无错误、系统响应时间。其他，如JVM内存、DB连接数、DB的CPU等。

(3)测试系统的稳定性。如果一个系统能够在压力环境下稳定运行一段时间，那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度。

 

14.3.4配置测试(Configuration Testing)

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

(1)了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。

(2)规划领域内评估该如何调整才能实现系统的扩展性。

 

14.3.5并发测试(Concurrency Testing)

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

(1)发现系统中可能隐藏的并发访问时的问题。

(2)关注某些性能指标，如内存泄露、死锁、长事务、线程/进程同步失败等。

并发测试可验证某种架构或设计的合理性，可作代码级别的检查和定位。如Jprofile、JProbe工具。

 

14.3.6可靠性测试(Reliablity Testing)

通过给系统加载一定的业务压力(如资源在70-90%的使用率)的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。

(1)验证系统是否能够支持长期稳定的运行

(2)需要在压力下持续一段时间的运行。

(3)关注系统的运行状况。关注内存、CPU、系统响应时间有无明显变化。

 

14.3.7失效恢复测试(Failover Testing)

针对有冗余备份和负载均衡的系统设计的。用来检验如果系统局部发生故障，用户能否继续使用系统；以及如果发生，用户将受到多大程度的影响。还关注问题发生时，能支持多少用户访问和采取何种应急措施。一般说来，只有对系统持续运行指标有明确要求的系统才需要进行此类测试。

 

14.4性能测试分析方法

14.4.1性能测试的一般步骤

性能测试的一般步骤如下：

(1)制定目标和分析系统

(2)选择测试度量的方法

(3)学习的相关技术和工具

(4)制定评估标准

(5)设计测试的场景和用例

(6)运行测试用例

(7)分析测试结果

 

14.4.2性能测试的估算方法

14.4.2.1性能80-20原理方法

用以下例子来说明。

有200个用户使用客户端软件进行业务处理（并发度至少要达到200并发），每年通过软件进行处理的总业务量为：2000万笔业务/年。

测试强度估算时采用如下假设前提：

全年的业务量集中在10个月完成，每个月20个工作日，每个工作日8个小时；

采用80-20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；

 

测试压力的估算结果：

去年全年处理业务约2000万笔，其中15%的业务处理每笔业务需对应用服务器提交3次请求；70%的业务处理每笔业务需对应用服务器提交2次请求；其余15%的业务每笔业务向应用服务器提交1次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需要，测试需按现有业务量的2倍进行。

每年总的请求数量为：（2000*15%*3+2000*70%*2+2000*15%*1）*2="8000万次/年。

每天的请求数量为：8000/200="40万次/天。

每秒的请求数量为：（400000*80%）/（8*3600*20%）=55.6次/秒。

正常情况下，应用服务器处理请求的能力至少应达到：56次/秒。

 

14.4.2.2性能下降曲线分析法

性能下降曲线实际上描述的是性能随用户数增长而出现下降趋势的曲线。而这里所说的“性能”可以是响应时间，也可以是吞吐量或是单击数/秒的数据。当然，一般来说，“性能”主要是指响应时间。

 

下图给出了一个“响应时间下降曲线”的示例。

从图1.6可以看到，一条曲线可以分为以下几个部分：

(1)单用户区域：对系统的一个单用户的响应时间。这对建立性能的参考值很有作用。

(2)性能平坦区：在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。

(3)压力区域：应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域的开始。

(4)性能拐点：性能开始“急剧下降”的点。

 

这几个区域实际上明确标识了系统性能最优秀的区间，系统性能开始变坏的区间，以及系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方。

 

因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。

 

14.4.3性能测试LoadRunner测试过程

下图给出了LoadRunner的性能测试过程。LoadRunner将性能测试过程分为计划测试、测试设计、创建VU脚本、创建测试场景、运行测试场景和分析结果6个步骤。

测试过程如下：

(1)计划测试阶段

主要进行测试需求的收集、典型场景的确定；

 

(2)测试设计阶段

主要进行测试用例的设计；

 

(3)创建VU脚本阶段

主要根据设计的用例创建脚本；

 

(4)创建测试场景阶段

主要进行测试场景的设计和设置，包括监控指标的设定；

 

(5)运行测试场景阶段

对已创建的测试场景进行执行，收集相应数据；

 

(6)分析结果阶段

主要进行结果分析和报告工作。

 

14.5性能测试模型PTGM

性能测试模型PTGM（Performance Testing General Model），该性能测试模型将性能测试过程分为测试前期准备、测试工具引入、测试计划、测试设计与开发、测试执行和管理以及测试分析等6个步骤，

性能测试模型PTGM如下图所示。

 

 

 

在PTGM模型的描述中，作者为每个步骤设计了相应的活动，囊括了从“测试团队组建”到“测试分析”的全部过程，每个活动都有详细的活动指引和参考模板。