吐血整理，性能测试-项目需求分析详细，看这篇就够了...

前言

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

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

性能测试的意义：
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笔，那么总笔数就是5010100=50000笔。

注意此数据根据TPS换算后，我们可以换算出系统的业务总处理量是否能达到这个数据，这也是一个很重要的指标。

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

需求三：场景业务的调查

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

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

2）高访问量的功能，经常承受压力的功能点

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

3）业务复杂度高

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最动人的风景，往往藏在最难攀爬的高处。当你觉得力竭时，请记住：每一次坚持都在雕刻更强大的自己。别问路有多远，只管迈步向前；别怕山有多高，向上攀登就是答案！

你体内沉睡着改变世界的力量！每个清晨都是改写命运的新机会，每次挫折都是精心包装的礼物。当全世界都在说"不可能"时，正是你证明"可能"的最好时机！