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

目录结构

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

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

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

以本次项目为例，产品团队并未指明性能测试需求，那么测试工程师如何分析提取量化的性能指标呢？

从用户应用角度考虑，若被测对象 常用的业务 的性能存在瓶颈，则很可能引起客户的反感。以登录功能为例，输入用户名和密码，点击登录按钮到显示成功登录信息，若耗时1min，用户绝对无法忍受。用户 不常用的功能 ，如年度报表汇总功能，一个季度甚至是一年才使用一次，等几分钟or更长时间也有可能被接受。

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

针对本次ECShop电商系统而言，商城用户经常使用的功能，且存在大量用户使用的业务有：用户注册、登录、随机浏览商品、购买业务等，而其他功能则相对用户较少。若电商系统已经正式运营，则可从系统 运营日志 中分析具体的数据。若尚未上线运营，则需要 调研用户 or根据 自身经验 进行分析获取。

根据 [JPT_01]性能测试需求分析 中的描述，分析哪些是用户常用or交易占比超过80%的业务；从运营及项目组角度分析，哪些业务相对重要，然后确定为 业务测试点 。

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

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

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

因此，不同的视角，衡量的响应时间指标也各不相同。实际测试过程中，需明确以什么视角验证被测对象的性能。

大多数情况下，性能测试响应时间主要以客户端发出请求，直至接收到服务端的响应数据过程中所消耗的时间作为参考。

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

Tips：

不建议尝试在公网进行性能测试，原因如下：

① 可能影响现网用户 。实施性能测试过程中，可能产生大量压力与垃圾数据，从而破坏生产环境，导致缺陷的产生，影响实际的业务。

② 压力模拟可能无法体现真实场景 。实施性能测试时，利用压测工具模拟大并发数，会产生大量业务数据。因负载生成器与服务器所在的网络不同，or服务器特定的网络安全设置，导致压力数据无法达到被测服务器，整个网络环境不可控，从而导致测试失败。

有一种情况除外，模拟固定带宽网络访问的场景，可在局域网中使用限制带宽的手段进行测试。

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

衡量方式：

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

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

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

PS：

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

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

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

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

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

计算业务量的分解数据：

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

微型计算机的主要性能指标有：计算机的运算速度是指计算机每秒钟执行的指令数。单位为每秒百万条指令）简称MIPS＊或者每秒百万条浮点指令）简称MFPOPS）。它们都是用基准程序来测试的。影响运算速度的有如下几个主要因素