测试老鸟总结，性能测试需求分析-性能必要性，一篇打通...

---

前言

性能测试需求分析

性能测试需求分析，与传统的功能测试需求分析有所不同，功能测试需求分析重点在于从用户层面分析被测对象的功能性、易用性等质量特性，性能测试则需要从终端用户应用，系统架构设计，硬件配置等多个维度分析可能存在的性能瓶颈的业务。

性能测试必要性评估

任何项目在开始性能测试之前，都需要进行必要性评估，通过必要性评估活动，确认被测对象是否有必要实施性能测试活动，千万不可为了性能而性能。

通常情况下，必要性评估可以设定不同条件，不同权重进行分析，将评估项分为关键评估项和一般评估项。

关键项评估，只要有一项符合，则必须开展性能测试，而一般评估项，可通过加权计算，超过60分，则需要开始性能测试；

根据测试要求可分为功能测试和非功能测试。

非功能测试，通常指的是性能测试。 当然，具体情况具体分析。

常见的性能测试关键评估项如下：
1、被测对象需经过主管部门或监管单位审查，认可，需要提供性能测试报告。目前，很多企业的软件产品在正式上市对外销售、应用时，政府机关，主管部门或监管单位，可能需要出具功能测试报告、性能测试报告，甚至是第三方测试报告，这种情况下，必须进行性能测试。

2、涉及财产生命安全的系统，通常情况，电商系统、金融业务系统，医疗健康评估，涉及用户或行方资金安全，生命安全类的，需要进行性能测试；

3、首次投产的大型系统，具有大量用户使用的核心业务；
4、系统核心数据库、业务逻辑、软硬件升级。与历史系统对比，系统核心数据库、业务逻辑调整、软件硬件设备升级，同样需要实施性能测试；
5、历史版本存在重大非功能缺陷或风险较大的未评估项；

6、业务量、用户量、节点增长30%以上。系统升级后，业务量、用户量、应用节点，增长量在30%以上的，具体数值可根据实际情况调整。应用节点增长一般指甲方因业务需求，增加应用节点，银行拓展分行、分中心、分公司、营业网点等；

7、系统架构发生重大变化。不同的系统架构可能存在较大的性能差异，因此在系统架构发生变化后，必须实施性能测试，并且在此过程中，无法通过类推的思路

8、生产环境非功能严重缺陷修复后。生产环境在使用过程中产生重大非功能性缺陷成功修复后，需重新开展性能测试活动，以验证修复活动是否对生产环境造成不良影响。

常见的性能测试一般评估项，主要从单次版本考虑，如果是平台性的，则为关键评估项，如果是单次版本，单个组件或业务，则从以下几个一般评估项评估权重：
是否在平台中处于核心位置（15分）；
是否有升级，且升级内容中包含了外部系统对接接口、支付接口、Web Service调用接口等与其他系统关联接口（20分）；
是否存在部署方式调整或优化（15分）；
是否增加了性能风险较高的调整（20分）；
是否存在客户要求必须测试的组件或业务流程（20分）；
是否涉及多个功能缺陷的修复，且流程发生较大变化（10分）。
如果上述一般评估项，总计分值超过60分，则需进行性能测试。

性能测试工具选型

通过测试必要性评估，确定了需要对被测对象实施性能测试后，则需要考虑采用哪种性能测试方式。

根据被测对象的业务特性和架构设计，可以采用以下两种方式开展有效的性能测试活动。

如果被测对象为批处理方式实现，并且在数据库中设立起始与终止标识字段，则可以利用存储过程或发起批处理的方式进行。

资源监控可以利用监控脚本如python脚本、shell脚本或其他监控工具，最终统计时，以结束时间减去开始时间，则可获得交易时间，并可根据每笔交易获得平均交易时间，相对来说较为方便。

如果被测对象不是批处理模式，且可能存在大量数据交互，则可能需要采用专业的性能测试工具来实现。一般而言，业内常用的性能测试工具主要要开源的Jmeter和商用的HP公司的LoadRunner。

Jmeter是个开源的性能测试工具，目前在市场中的热度很高，不依赖于界面，功能测试的脚本同样可以作为性能测试脚本运行，对测试工程师技术技能要求不高，而且提供了参数化、函数、关联等功能便于脚本的优化与扩展。

LoadRunner在商用领域一枝独秀，很多年保持排前的市场占有率，与Jmeter相比，LoadRunner具有强大的脚本开发功能、完善的函数库及结果分析功能。

对测试工程师技术要求相对较高，但因其在业内流行很多年，LoadRunner应用的资料相对于Jmeter较多，便于学习与应用。

企业在选择性能测试工具时，如有条件可以自己根据实际测试需求自定义开发测试工具，也可以选择市场上常用的测试工具，通常选择时需考虑以下几个问题：
能否自定义开发，更符合实际测试需求；
商用的测试工具所需的成本，企业能否承受；
采购的测试工具是否提供了完善的服务、细致的培训；
团队人员能否掌握测试活动所需的工具技能。

性能测试需求分析

与功能测试需求分析一样，性能测试同样需要针对被测对象进行需求分析。一般而言，用户或产品团队设定性能测试需求时，仅会表述字面意义上需求，如“系统TPS需达到300以上，单笔交易时间不超过3秒”等。

需要性能测试工程师结合用户需求及性能测试活动本身需求进行显性与隐性性能测试需求的分解与提取。

随着互联网技术的飞速发展，互联网应用架构越来越复杂，运营系统涉及的利益相关方越来越多，因此，在性能测试工作实施过程中，需从不同的用户层面分析待测需求。

确定性能测试的必要性后，性能测试工程师主要从以下两个用户方确定性能测试需求：

业务用户
1、用户频繁使用，且存在大量用户使用的业务流程；
2、交易占比较高，日常占比在80%以上甚至更高的业务流程；
3、特殊交易日或峰值交易占比80%以上甚至更高的业务流程；
4、性能较差且有过调整的业务流程；
5、特殊业务场景；
6、核心业务发生重大流程调整的业务流程。

以上从业务用户层面，考虑的可能需要进行性能测试的点。实际实施过程中，如果可能，可向终端用户调研。

性能测试的常规流程

第1步：确认需求并分析业务场景
第2步：设计测试方案(模板)，测试脚本
第3步：准备测试数据并执行测试脚本
第4步：监控资源消耗
第5步：瓶颈定位和性能调优验证
第6步：输出报告(模板)和跟踪

流程通常不能如你所愿
案例一：测试环境和实际环境的配置不一致
案例二：没有明确目标的需求

性能测试的分类

压力测试；
负载测试；
容量测试；
可靠测试；

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

心怀勇气，挫折不惧。奋斗之路如登山攀岩，艰难不退缩。积极向上，不停努力，只有拼搏才能闪耀光芒。坚持信念，超越极限，创造属于自己的辉煌人生！

奋斗如同航行，不畏波涛。坚忍不拔，勇往直前，用毅力书写壮丽篇章。困难是助力，挑战是机遇，只有奋斗才能创造辉煌。燃烧激情，追逐梦想，成就自己的绝世传世！奋斗不息，无限可能！

拒绝平庸，追求卓越；奋发图强，创造传奇。勇往直前，不畏艰险；拼搏奋斗，成就辉煌。每一次努力都离目标更近一步，坚持到底才能看到辉煌的曙光！奋斗不止，成就无限！