概念:经过技术的手段模拟大量用户同时访问被测应用,观察、记录和分析系统的各项性能指标的过程。数据库
目标:评估系统的性能瓶颈,预测系统的最大用户负载能力安全
性能测试的意义:架构
1)可以有效评估系统的性能指标,用于系统的性能评估2)可以识别系统的性能瓶颈,协助性能调优3)可以指导突发流量承载方案的制定4)可以用于系统运维成本的预算并发
测试:根据业务提出性能测试来规避风险运维
开发:以为某些页面加载慢性能
运维:对某个系统的服务能力提出性能评估测试
产品:线上性能问题反馈优化
用户:提出某些硬性的性能要求spa
关键性评估:有一下一项就要进行性能测试架构设计
涉及财产、生命、安全的系统。如:支付系统、电商系统、金融业务系统、医疗健康评估系统
首次投产的大型系统、具备大量用户使用的核心业务(如:查票、抢票、支付)
系统核心数据库、业务逻辑、软硬件升级
历史版本存在重大非功能缺陷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)业务复杂度高
每每说来业务逻辑复杂度的都具有一、2点的要素,可能其功能使用的人数较少可是对系统有很严重影响:这些功能因为其业务逻辑具备的复杂度,每每出错的可能性也比较高,因此这些功能也是必需要进行测试的
下一篇:性能测试方案