Jmeter性能测试系列-性能测试需求分析-编程知识

性能测试需求分析

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

性能测试必要性评估

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

通常情况下，必要性评估可以通过设定不同条件、不同权重进行分析，将评估项分为关键评估项和一般评估项两种。关键评估项，只要有一项符合，则必须开展性能测试，而一般评估项，可通过加权计算，超过60分，则需开展性能测试。

软件测试活动中，根据测试要求可分为功能测试与非功能测试。非功能测试，通常指的即是性能测试。当然，具体情况具体分析。

常见性能测试关键评估项如下：

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

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

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

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

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

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

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

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

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

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

1. 是否在平台中处于核心位置（15分）；

2. 是否有升级，且升级内容中包含了外部系统对接接口、支付接口、Web Service调用接口等与其他系统关联接口（20分）；

3. 是否存在部署方式调整或优化（15分）；

4. 是否增加了性能风险较高的调整（20分）；

5. 是否存在客户要求必须测试的组件或业务流程（20分）；

6. 是否涉及多个功能缺陷的修复，且流程发生较大变化（10分）。

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

以本ECShop平台为例，通过针对上述关键评估项及一般评估项的评估，满足关键评估项中的第三条：首次投产的大型系统，具有大量用户使用的核心业务”，因此本ECShop平台的性能测试活动必须开展。

性能测试工具选型

通过测试必要性评估，确定了需要对被测对象实施性能测试后，则需要考虑采用哪种性能测试方式。根据被测对象的业务特性和架构设计，可以采用以下两种方式开展有效的性能测试活动。

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

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

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

LoadRunner在商用领域一枝独秀，很多年保持排前的市场占有率，与Jmeter相比，LoadRunner具有强大的脚本开发功能、完善的函数库及结果分析功能。对测试工程师技术要求相对较高，但因其在业内流行很多年，LoadRunner应用的资料相对于Jmeter较多，便于学习与应用。

企业在选择性能测试工具时，如有条件可以自己根据实际测试需求自定义开发测试工具，也可以选择市场上常用的测试工具，通常选择时需考虑以下几个问题：

1. 能否自定义开发，更符合实际测试需求；

2. 商用的测试工具所需的成本，企业能否承受；

3. 采购的测试工具是否提供了完善的服务、细致的培训；

4. 团队人员能否掌握测试活动所需的工具技能。

开源是行业趋势，本书案例项目用开源性能工具Jmeter实施性能测试。

性能测试需求分析

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

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

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

业务用户

1. 用户频繁使用，且存在大量用户使用的业务流程；

2. 交易占比较高，日常占比在80%以上甚至更高的业务流程；

3. 特殊交易日或峰值交易占比80%以上甚至更高的业务流程；

4. 性能较差且有过调整的业务流程；

5. 特殊业务场景；

6. 核心业务发生重大流程调整的业务流程。

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

项目团队

1. 曾经测过性能后调整了架构设计的业务；

2. 逻辑复杂，关键的业务；

3. 可能消耗大量资源的业务；

4. 与外部系统存在接口调用，且有大量数据交互的业务；

5. 调用第三方业务组件，逻辑复杂的业务。

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

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

性能测试需求评审

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

可测性

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

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

性能测试活动与功能测试活动有个显著的特点是被测对象运行环境要求不同。实施功能测试时，只要被测对象能够在合理的运行环境中正常运行即可，即使测试环境与生产环境可能存在较大的差异，性能测试则不同，一定需模拟尽可能真实的运行环境。当测试环境与实际生产环境差异较大时，性能测试结果往往不被接受，如果在性能测试实施过程中，无法搭建相对真实的测试环境，即可认为被测对象不具备性能的可测性。