13年测试整理，性能测试-从需求分析到实战详细，一篇概全...

---

前言

1、性能测试需求分析

性能测试需求分析，与传统的功能测试需求分析有所不同，功能测试需求分析重点在于从用户层面分析被测对象的功能性、易用性等质量特性。

性能测试则需要从终端用户应用，系统架构设计，硬件配置等多个维度分析可能存在的性能瓶颈的业务。

2、性能测试必要性评估

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

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

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

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

非功能测试，通常指的是性能测试。 当然，具体情况具体分析。
常见的性能测试关键评估项如下：

1）被测对象需经过主管部门或监管单位审查，认可，需要提供性能测试报告。

目前，很多企业的软件产品在正式上市对外销售、应用时，政府机关，主管部门或监管单位，可能需要出具功能测试报告、性能测试报告，甚至是第三方测试报告，这种情况下，必须进行性能测试。

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

3）首次投产的大型系统，具有大量用户使用的核心业务；

4）系统核心数据库、业务逻辑、软硬件升级。与历史系统对比，系统核心数据库、业务逻辑调整、软件硬件设备升级，同样需要实施性能测试；

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

6）业务量、用户量、节点增长30%以上。系统升级后，业务量、用户量、应用节点，增长量在30%以上的，具体数值可根据实际情况调整。

应用节点增长一般指甲方因业务需求，增加应用节点，银行拓展分行、分中心、分公司、营业网点等；

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

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

以上仅仅列出笔者在日常性能测试活动参考的关键评估项，对于不同行业，不同测试对象可能存在的不同的关键评估项，读者可自行增减。

常见的性能测试一般评估项，主要从单次版本考虑，如果是平台性的，则为关键评估项，如果是单次版本，单个组件或业务，则从以下几个一般评估项评估权重：

是否在平台中处于核心位置（15分）；
是否有升级，且升级内容中包含了外部系统对接接口、支付接口、Web Service调用接口等与其他系统关联接口（20分）；
是否存在部署方式调整或优化（15分）；
是否增加了性能风险较高的调整（20分）；
是否存在客户要求必须测试的组件或业务流程（20分）；
是否涉及多个功能缺陷的修复，且流程发生较大变化（10分）。

如果上述一般评估项，总计分值超过60分，则需进行性能测试。

4、性能测试工具选型

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

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

如果被测对象为批处理方式实现，并且在数据库中设立起始与终止标识字段，则可以利用存储过程或发起批处理的方式进行，资源监控可以利用监控脚本如python脚本、shell脚本或其他监控工具，最终统计时，以结束时间减去开始时间，则可获得交易时间，并可根据每笔交易获得平均交易时间，相对来说较为方便。

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

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

5、性能测试需求分析

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

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

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

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

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

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

项目团队：
1）曾经测过性能后调整了架构设计的业务；
2）逻辑复杂，关键的业务；
3）可能消耗大量资源的业务；
4）与外部系统存在接口调用，且有大量数据交互的业务；
5）调用第三方业务组件，逻辑复杂的业务。

以上从项目开发角度考虑可能需要进行性能测试业务流程，性能测试工程师需对被测对象深入了解，并且需要研发团队配合。

除上述两种用户，还可能包括运营团队，调研未来业务发展规划，系统需满足未来业务需求的可能性。

6、性能测试需求评审

确定性能测试需求后，如有必要，需进行某种程度的测试需求评审活动。性能测试需求评审与功能测试需求评审类似，都需关注需求本身的可测性、一致性及正确性。

可测性：

软件可测性，通常理解为软件本身是否具备实施测试的条件，是否便于发现缺陷及定位缺陷。

在一定的时间及成本范围内，构建测试环境，设计及执行测试用例，测试工程师能够相对便捷的发现、定位缺陷，从而协助研发人员解决对应的缺陷，无论是功能测试，还是性能测试，都需要被测对象具备上述的可测试特性。

性能测试活动与功能测试活动有个显著的特点是被测对象运行环境要求不同。

实施功能测试时，只要被测对象能够在合理的运行环境中正常运行即可，即使测试环境与生产环境可能存在较大的差异，性能测试则不同，一定需模拟尽可能真实的运行环境。

当测试环境与实际生产环境差异较大时，性能测试结果往往不被接受，如果在性能测试实施过程中，无法搭建相对真实的测试环境，即可认为被测对象不具备性能的可测性。

一致性：

性能测试需求一致性，主要关注用户需求、生产需求、运营需求几个方面。通过对性能测试需求的分析，判断本次测试需求是否满足用户需求规格说明书中明确列出的性能需求项。

生产需求，则是关注被测对象运行的真实性，从而在测试结束后能够提供相对准确的数据依据。

运营需求，需以历史数据或者现今运营数据为基础，规划未来业务发展的可能性，从而使得被测对象性能指标具有一定的冗余度。

通过性能测试需求评审活动，确定本次性能需求与上述的关注点一致。

正确性：

在可测性与一致性得到保证的基础上，需针对性能测试指标进行验证，从而保证后续实施活动中所关注的各个项目需求、场景及指标的正确性，从而尽量减少返工、重新设计的风险。

通过可测性、一致性及正确性的评估，最终确定本轮性能测试需求，并以此作为后续测试实施活动的输入。

7、性能测试的常规流程

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

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

性能测试的分类：
压力测试
负载测试
容量测试
可靠测试

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

每一次的奋斗都是为了让自己更好，只要不停地前行，用心与汗水浇灌梦想，坚持到最后，我们就能看到属于自己的辉煌。

在追逐梦想的路上，不要畏惧失败与困难，将每一次挫折化为前进的动力，相信自己的能力，坚持不懈地奋斗，终将获得辉煌的胜利。

只有敢于冒险，才能收获成长；只有勇于拼搏，才能创造奇迹。让我们用信念与勇气，书写自己人生的传奇，用行动和汗水，铸就属于自己的辉煌。