[JPT_02]性能测试-性能指标的分析 & 定义

2018-09-05 本文已影响48人 Fighting_001

目录结构

一、性能测试需求分析与定义
    1.性能需求关注的常规量化指标项
    2.分析确定业务测试点，提取性能指标的策略
二、性能指标分析与定义
    1.并发数
    2.响应时间
    3.吞吐量
    4.系统资源耗用
    5.业务成功率
    6.TPS
三、综合分析：测试需求&指标分析

一、性能测试需求分析与定义

通过前文[JPT_01]性能测试需求分析对性能测试的必要性评估之后，敏捷开发团队确定利用开源工具JMeter实施性能测试工作。根据被测对象的应用特性，首先需要获取具体的性能测试需求。

1.性能需求关注的常规量化指标项

一般而言，被测对象的性能需求，会在用户SRS（需求规格说明书）中给出，如：单位时间内的访问量需达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，性能指标以量化形式给出。

对于相对规范的产品，产品团队一般会给出相对明确量化的性能测试要求，如下表所示：

测试项	响应时间	业务成功率	并发数	CPU使用率	内存使用率
随机购买商品	≤5s	100%	100	≤80%	≤80%

可以看出，上表给出的性能指标比较明确。性能测试活动实施过程中，测试工程师只需收集随机购买商品的 [响应时间、访问成功率、并发数、CPU使用率、内存使用率] 等相关指标的监测数据，与表中的量化指标比对即可。满足相关指标，则测试通过；若未满足，则需要进行问题分析定位，最终进行调优与回归，直至达到性能测试需求。

2.分析确定业务测试点，提取性能指标的策略

在有明确性能需求时，测试活动相对来说较为容易开展，但实际工作中，经常会碰到没有明确的性能需求的测试要求。因此，测试工程师需要具备根据不同输入（业务用户视角、终端用户调研、项目团队视角、运营团队视角、公司未来发展视角）分析，获取性能需求的能力。

以本次项目为例，产品团队并未指明性能测试需求，那么测试工程师如何分析提取量化的性能指标呢？
从用户应用角度考虑，若被测对象常用的业务的性能存在瓶颈，则很可能引起客户的反感。以登录功能为例，输入用户名和密码，点击登录按钮到显示成功登录信息，若耗时1min，用户绝对无法忍受。用户不常用的功能，如年度报表汇总功能，一个季度甚至是一年才使用一次，等几分钟or更长时间也有可能被接受。

So，不同的应用频率，决定了用户的使用感受，也决定了测试的需求。

针对本次ECShop电商系统而言，商城用户经常使用的功能，且存在大量用户使用的业务有：用户注册、登录、随机浏览商品、购买业务等，而其他功能则相对用户较少。若电商系统已经正式运营，则可从系统运营日志中分析具体的数据。若尚未上线运营，则需要调研用户or根据自身经验进行分析获取。
根据[JPT_01]性能测试需求分析中的描述，分析哪些是用户常用or交易占比超过80%的业务；从运营及项目组角度分析，哪些业务相对重要，然后确定为业务测试点。

综合分析，本次项目实践以用户登录、随机浏览并购买商品为测试点。确定业务测试点后，即可进行详细的业务需求分析，从而明确性能测试指标。

二、性能指标分析与定义

通常情况下，性能测试关注被测对象的时间特性、资源利用特性、稳定性。

时间特性：被测对象实现业务交易过程中所需的处理时间。从用户角度来说，越短越好
资源利用特性：被测对象的系统资源占用情况。一般Web系统不关注客户端的资源占用情况，仅关注服务器端，①通常为 服务端 的CPU、内存、网络带宽、磁盘等。根据被测对象架构设计，②还可分为 Web服务器、中间件、数据库、负载均衡...
稳定性：关注被测对象在一定负载情况下，持续稳定提供服务的能力

不同的被测对象，不同的业务需求，可能有不同的指标需求，但大多数测试需求中都包含以下几种性能指标：

1.并发数

并发数：①广义而言，是单位时间内同时发送给服务器的业务请求数，不限定具体业务类型；②狭义而言，是单位时间内同时发送给服务器的相同的业务请求数，需限定具体的业务类型。（在性能测试过程中需要区分二者）

服务端视角
并发，即同时出发，从应用系统架构层面来看，并发数为单位时间内服务端接收到的请求数。
客户端视角
客户端的某个具体业务行为包括多个请求，并发数可被抽象理解为客户端单位时间内发送给服务器端的请求数。
用户行为视角
客户端的业务请求一般为用户操作行为，并发数也可理解为并发用户数，而这些用户是虚拟的，又可称为虚拟用户数。

2.响应时间

目前，大多数软件系统客户端与服务器交互的过程，如下：

	过程	处理时间
①	用户通过客户端向服务端发出业务请求	t1
②	服务端接收到请求，处理该请求	t2
③	服务端根据处理模型返回数据给客户端	t3
④	客户端接收到响应数据，处理数据呈现给用户	t4

系统视角
在整个处理流程中，系统的响应时间：T_s = t1+t2+t3。该时间没有包括客户端对数据处理并呈现的时间t4。
用户视角
从用户角度看，用户通过客户端发出业务请求，到客户端展现相应的请求结果，这个过程的时间越短越好。此时用户视角的响应时间：T_u = t1+t2+t3+t4。
服务器视角
从服务器角度看，服务器接收到客户端发送的请求，并给出结果的响应，这个过程所消耗的时间，记录为响应时间，即服务器仅关注t2的处理时间。

因此，不同的视角，衡量的响应时间指标也各不相同。实际测试过程中，需明确以什么视角验证被测对象的性能。
大多数情况下，性能测试响应时间主要以客户端发出请求，直至接收到服务端的响应数据过程中所消耗的时间作为参考。

严格来讲：响应时间=呈现时间+网络传输时间+服务器端响应时间+应用延时时间

Tips：
不建议尝试在公网进行性能测试，原因如下：
①可能影响现网用户。实施性能测试过程中，可能产生大量压力与垃圾数据，从而破坏生产环境，导致缺陷的产生，影响实际的业务。
②压力模拟可能无法体现真实场景。实施性能测试时，利用压测工具模拟大并发数，会产生大量业务数据。因负载生成器与服务器所在的网络不同，or服务器特定的网络安全设置，导致压力数据无法达到被测服务器，整个网络环境不可控，从而导致测试失败。
有一种情况除外，模拟固定带宽网络访问的场景，可在局域网中使用限制带宽的手段进行测试。

总之，需要遵循一个原则：在测试过程中，任何资源都必须可控。

3.吞吐量

吞吐量：单位时间内系统处理用户请求的数量。吞吐量指标直接体现了软件系统的业务处理能力，尤其适用于系统架构选型时做对比测试。

衡量方式：

请求数 / 单位时间
点击数 / 单位时间
字节数 / 单位时间

其中，[字节数 / 单位时间] 的计算方式，与当前的网络带宽比较，可找出网络方面的问题。

吞吐量计算：例如1分钟内系统可以处理1000次转账交易，则吞吐量为1000/60=16.7 (次/秒)

4.系统资源耗用

系统资源耗用：客户端与服务端系统各项硬件资源的耗用情况，如CPU使用率、内存使用率、网络带宽占用率、磁盘I/0输入输出量等。

一个系统的高效运行，除了软件性能要求外，还需要对硬件资源进行监控。若用户需求、项目组or其他利益相关方均未提出性能指标要求，则可参考行业经验，CPU使用率≤80%、内存使用率≤80%、网络带宽占用≤50% ...

CPU使用率
1）当CPU使用率超过80%时，表明CPU应用繁忙，如果持续维持在90%甚至更高，很可能导致机器响应慢、死机等问题
2）当CPU使用率过低时，说明CPU比较空闲，可能存在资源浪费的问题
内存使用率
对于内存，同样存在类似以上的问题

PS：
80%只是作为一个经验参考值，最终的性能测试指标需要经过项目相关各方评审才能确定

通过上述业务数据分析，最终得到本次项目测试的性能需求指标，如下：

测试项	响应时间	业务成功率	业务量	并发数	CPU使用率	内存使用率
登录	≤5s	100%	50000次/2h	100	≤80%	≤80%
随机购买商品	≤5s	100%	50000次/2h	100	≤80%	≤80%

5.业务成功率

业务成功率：用户发起了多笔业务请求中，成功笔数所占的比率。业务成功率展示了在特定压力or负载情况下，服务器正确、稳定处理业务请求的能力。

例如，测试银行营业系统的并发处理性能，有100个网点，上午10:00-11:00的一个小时高峰期里，要求能支持50000笔开户业务，其中成功率不低于98%，也就是需要成功开户49000笔，其他的1000笔可能是超时，或者其他错误导致未能开户成功。

6.TPS

单位时间内服务器处理的事务数。该指标值越大越好。一般情况下，用户业务操作过程可能细分为若干个事务，单位时间处理的事务数越多，说明服务器的处理能力越强。

三、综合分析：测试需求&指标分析

根据上述各指标，结合被测对象本身的业务情况，进行测试需求及指标分析：

ECShop是一个面向广大网络用户的电子商务系统，大部分用户会在某个时间段对平台访问、网购。
确定用户访问的峰值时间段：若新系统没有上线，没有历史数据可以依据，可通过竞品分析，获取友商系统的运营数据作为参考。
如业务峰值时间段：15:00-17:00、21:00-23:00，业务峰值期持续2h。若要测试稳定性，则需根据实际业务情况模拟用户应用场景。

确定在业务峰值时间段完成的业务量：需要统计有多少人在峰值时间段使用ECShop电商系统。
根据产品团队的业务规划、产品设计给出一个参考值，比如系统初期设计规模在单天15w业务量，峰值交易5000笔，最高并发100用户（如秒杀业务）。

通过对预设业务目标的分析，可得出以下数据：

-峰值持续时间：2h
-单天访问业务量：15w
-峰值交易笔数：5000
-最高并发数：100

在满足以上需求的同时，还需要考虑业务的响应时间。被测对象的响应时间，作为一个很直观的用户体验数据，可很好的衡量被测对象是否让用户体验良好，当然还需要把“体验良好”转换为量化的指标。

Apdex联盟-响应时间经验值
响应时间在业内的一个经验值，采用Apdex联盟的建议值：3s、3-12s，12s以上。0-3s的业务处理响应时间是非常理想的，而3-12s则是普遍可容忍的时间，但超过12s的响应时间，用户一般不会接受，可能选择刷新，甚至放弃操作。
“258原则”-响应时间参考值
1）当用户能够在2s以内得到响应时，会感觉系统的响应很快
2）当用户在2-5s内得到响应时，会感觉系统的响应速度还可以
3）当用户在5-8s内得到响应时，会感觉系统的响应速度很慢，但还可以接受
4）当用户在超过8s后仍然无法得到响应时，会感觉系统糟透了，or认为系统已经失去响应，而选择离开这个Web站点，or发起第二次请求

响应时间还应该根据业务类型确定，而不能仅从用户的主观感觉考虑。本次项目测试采用常规的5s为目标，也就是说ECShop平台处理登录、商品随机浏览购买等业务的服务器响应时间均不超过5s。
单天15w业务量，表明在一天内的总业务量为15w，但未明确是哪些业务的数据量叠加，还是每项业务都是此要求（假定单项业务每天都有15w的业务量）。
从上图 [访问时间-访问用户量] 坐标图中可以看出，用户访问并非是均分在24h内。在没有历史数据可依据的情况下，可利用经济学中的“28原则”进行分析，即80%的业务量集中在20%的时间段内完成。而单天峰值时间段共有2个：15:00-17:00、21:00-23:00。

计算业务量的分解数据：

80%的业务量：15w*80% = 12w
20%的时间段：24h*20% = 4.8h
单天峰值时间：2+2 = 4h
全天峰值时间 / 20%时间：4h/4.8h = 83.3%

以15:00-17:00、21:00-23:00为考察时间段，则预期业务量为：
12w*(4h/4.8h) = 10w

以15:00-17:00为考察时间段，则预期业务量为：
12w*(2/4.8) = 5w

综上，需要测试ECShop电商平台在2h内支持5w用户登录、随机浏览商品进行购买的业务。