性能测试连载 (1)-需求分析

性能测试的概念&意义

概念

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

目标

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

性能测试的意义：

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 点的要素，可能其功能使用的人数较少但是对系统有很严重影响：这些功能由于其业务逻辑具有的复杂度，往往出错的可能性也比较高，所以这些功能也是必须要进行测试的

标签：场景,连载,性能,系统,业务,测试,用户数
来源： https://www.cnblogs.com/minfanblog/p/14754855.html