性能测试第一步--性能需求分析

性能测试的意义：

• 能够有效评估系统的性能指标，用于系统的性能评估
• 能够识别系统的性能瓶颈，协助性能调优
• 能够指导突发流量承载方案的制定
• 能够用于系统运维成本的预算

需求来源

测试：根据业务提出性能测试来规避风险

开发：觉得某些页面加载慢

运维：对某个系统的服务能力提出性能评估

产品：线上性能问题反馈

用户：提出某些硬性的性能要求

需求评估

关键性评估:有以下一项就要进行性能测试

涉及财产、生命、安全的系统。如：支付系统、电商系统、金融业务系统、医疗健康评估系统

首次投产的大型系统、具有大量用户使用的核心业务（如：查票、抢票、支付）

系统核心数据库、业务逻辑、软硬件升级

历史版本存在重大非功能缺陷or风险较大的未评估项

系统升级后，业务量、用户量、节点增长30%以上

系统架构发生重大变化的场景

性能严重Bug修复后，是否会对正式环境造成不利

常见性能需求

1. 接口的响应速度达到300ms以下。
2. 系统服务支持50万个在线用户
3. 接口成功率达到99.5%以上。
4. 在100个并发用户的高峰期，系统的基本功能，处理能力至少达到10TPS
5. 这个系统能否支撑200万的vu（每天登录系统的人次） vu----Virtual user(虚拟用户)

"不成文"的性能需求指标：

80/20原则：又称帕累托效应，比如，某一些系统一天中80%的访问量集中在20%的时间内。

下面来分析某移动支付的需求：

按照2018年日交易笔数的目标为1000万笔：

如何得到每秒的交易笔数？

一： 严格的根据2/8原则 ，80%的订单集中在20%的时间生成。

集中订单交易数： 10000000*80%=8000000笔

集中发送的时间：24*20%=4.8小时=17280秒

每秒生成的订单数：8000000/17280=462.9笔/秒

二：另外的200W交易笔数请求分布在另外的23个小时内，因为考虑到半夜之后基本没什么请求量，假设另外的200W次请求分布在10:00-24:00，那么我们另外一个指标是 2000000/14/3600 = 39.68 （稳定支持这样的TPS）

性能测试场景设计

峰值场景设计： 设计符合业务场景的高压力场景，比如大量并发集中在半小时-1小时内

稳定场景设计: 8-10小时的长时间稳定压力场景

性能瓶颈压测场景： 逐步增加压力，寻找业务请求瓶颈（适用于没有业务指标，技术优化类）

秒杀类超大并发场景设计: 测试秒杀场景

要测试的对象不是凭空想象出来，而是经过分析与系统数据收集得到。以下取几个典型的压力点:

• 登录：对于一般的系统来说，登录是用户操作系统的前提，如果用户根本就登录不了，那么其它功能将毫无用处。例如网游戏，开新服的时候，玩家挤破了脑袋只为登录。

• 查询：查询一般比较消耗系统和数据库资源。搜索引擎的查询功能就是典型，如果你在输入框内输入内容，很久就得不到结果。我想被称为“互联网入口”的搜索引擎就不会存在。

• 交易：对于一些电子商务系统来说，交易过程的性能要求是很高的，如果交易过程消耗用户很长时间的话，用户可能会转投其它平台。当然，除了交易速度外，对交易的成功率要求也是非常高的。不然，造成的损失也是不可估量的。

被测的系统应该是最重要的最基本的功能，也是用户使用最频繁的功能。

注意

测试用例的产生需要考虑以下几方面：

1.测试页面和业务逻辑，也就是业务对应的功能点

注意，性能测试的测试用例也需要专一性，也就是对应单个测试功能点。

因为我们监控的是每个事物的响应时间，功能点需要单一。

为排除网络原因，请在局域网进行性能测试。

2.压力持续时间

压力持续时间指的是给服务器施加多长时间的压力。

这个时间，我们会结合测试场景，对压力时间做一定的控制。

如果测试的是高峰场景，时间一般最少为1个小时；

如果测试的是稳定性场景，时间一般最少要求8小时；

3.并发数

不要混淆并发和TPS的关系。

并发数指的是同时有多少用户（线程）在对服务器施加压力，是量化的给服务器的压力；而TPS指的是服务器每秒钟能够处理的事物数，是服务器处理能力的体现。即施加的并发数服务器并不一定一秒响应完，两者定义不同。

扩展：jmeter Thread Properties

Number of Threads(users)：用于设置线程数，即用户数

Ram-Up Period(in seconds)：用于告知JMeter要在多长时间内建立全部的线程。Ramp-Up的值默认为0，代表立即建立所有线程，即同时并发。

Loop Count：用于设置循环次数