性能测试的概念&意义

概念

通过技术的手段模拟大量用户同时访问被测应用,观察、记录和分析系统的各项性能指标的过程。

目标

评估系统的性能瓶颈,预测系统的最大用户负载能力

性能测试的意义:

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

性能需求分析

需求来源

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

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

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

产品:线上性能问题反馈

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

需求评估

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

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

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

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

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

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

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

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

一般性评估:超过 60 分,则有必要进行性能测试

是否有升级,且升级内容中包含了外部系统对接接口、支付接口、Web Service 调用接口等与其他系统关联接口(20 分)

是否增加了性能风险较高的调整(20 分)

是否存在客户要求必须测试的组件 or 业务流程(20 分)

是否在平台中处于核心位置(15 分)

是否存在部署方式调整 or 优化(15 分)

是否涉及多个功能 Bug 的修复,且流程发生较大变化(10 分)

需求调研

用户视角:

1)频繁使用,且存在大量用户使用的场景

2)交易占比较高,日常占比 ≥80% 的场景

3)特殊交易日或峰值交易占比 ≥80% 的场景

4)性能较差且有过调整的场景

项目团队视角:

1)调整了架构设计的业务

2)逻辑复杂,比较关键的业务

3)可能消耗大量资源的业务

4)与外部系统存在接口调用,且有大量数据交互的业务

5)调用第三方业务组件,逻辑复杂的业务

运营视角:

1)满足未来业务发展规划

2)系统需满足未来业务需求

需求分析

需求一:用户数信息

1)调查系统当前和未来使用的用户数

系统用户数=系统目前注册的用户数,注册用户数并不代表他会每天并且无时无刻的使用。

在线用户数=同时在线对系统进行操作的用户数量(相当于混合场景)

并发用户数=同时在线并且同时操作同一个功能(单场景添加集合点)

2)调查系统当前和未来的每日、月活跃用户数

当前活跃用户数,即某天大概有多少用户使用本系统:那么这部分数据就是当前真正对系统构成压力的数据

需求二:业务数据量

1)调查当前和未来背景数据量

因为从 100 条数据中查 10 条也许很快,但是未来数据量变成 100w。。。

2)调查当前和未来业务每天使用的总笔数

每个用户每天可能下多少笔单,平均需要多少次来执行这个操作?那么根据用户数,我们就可以确定每天下单的笔数。如 50 人,平均每人每天下 10 次,每次下 100 笔,那么总笔数就是 50*10*100=50000 笔。注意此数据根据 TPS 换算后,我们可以换算出系统的业务总处理量是否能达到这个数据,这也是一个很重要的指标。

3)调查当前和未来高峰时业务的总笔数

需求三:场景业务的调查

1)系统最关键、最核心的业务

从系统出发,以主要的业务逻辑点为第一核心:这些功能对系统或公司来说往往具有举足轻重的地位,无论怎样都必须要优先执行满足这些功能的性能测试

2) 高访问量的功能,经常承受压力的功能点

系统中表现在系统关键、核心业务前面必须要经过的地方:比如对于百度搜索来说,其核心业务是搜索功能,但是首先要面对的其高访问量对是搜索输入框加载的首页,百度首页加载即高访问量的请求

3) 业务复杂度高

往往说来业务逻辑复杂度的都具备 1、2 点的要素,可能其功能使用的人数较少但是对系统有很严重影响:这些功能由于其业务逻辑具有的复杂度,往往出错的可能性也比较高,所以这些功能也是必须要进行测试的


↙↙↙阅读原文可查看相关链接,并与作者交流