[JPT_01]性能测试-需求分析 & 需求评审

目录结构

一、性能测试的概念&意义
    1.性能测试的概念、目标
    2.性能测试的意义
二、性能测试必要性评估
    1.常见的关键评估项
    2.常见的一般评估项
三、性能测试工具选型
    1.性能测试方式
        a.批处理方式
        b.大量数据交互方式
    2.性能测试工具选取
四、性能测试需求分析
    1.业务用户视角
    2.项目团队视角
五、性能测试需求评审
    1.可测性
    2.一致性
    3.正确性

一、性能测试的概念&意义

1.性能测试的概念、目标

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

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

2.性能测试的意义

1）能够有效评估系统的性能指标，用于系统的性能评估
2）能够识别系统的性能瓶颈，协助性能调优
3）能够指导突发流量承载方案的制定
4）能够用于系统运维成本的预算

二、性能测试必要性评估

项目在开展性能测试之前，需要进行必要性评估，确认被测对象是否有必要实施性能测试活动。

将性能测试评估项分为关键评估项和一般评估项：
1）关键评估项，只要有一项符合，则有必要进行性能测试
2）一般评估项，通过加权计算，超过60分，则有必要进行性能测试

1.常见的关键评估项

1. 被测对象需要经过主管部门or监管单位审查、认可的场景
2. 涉及财产、生命、安全的系统。如：支付系统、电商系统、金融业务系统、医疗健康评估系统
3. 首次投产的大型系统、具有大量用户使用的核心业务（如：查票、抢票、支付）
4. 系统核心数据库、业务逻辑、软硬件升级
5. 历史版本存在重大非功能缺陷or风险较大的未评估项
6. 系统升级后，业务量、用户量、节点增长30%以上
7. 系统架构发生重大变化的场景
8. 非功能性（性能、安全）严重Bug修复后，验证是否会对正式环境造成不利

2.常见的一般评估项

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

若上述一般评估项，总计分值≥60分，则需进行性能测试

三、性能测试工具选型

1.性能测试方式

通过以上必要性评估，若确定了需要进行性能测试后，则需要考虑性能测试方式：

a.批处理方式

若被测对象为批处理方式实现，且在数据库中设立起始与终止标识字段，则可以利用存储过程or发起批处理的方式进行。
资源监控可以利用监控脚本，如：python脚本、shell脚本or其他监控工具。

b.大量数据交互方式

若存在大量数据交互，则需要采用专业的性能测试工具来实现，如：开源的JMeter、商用的LoadRunner。

JMeter与LR比较：

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

JMeter工作原理：JMeter用于模拟成千上万的用户向服务器发送请求，检测响应返回的情况，如响应时间。
①JMeter每发送1个请求，相当于是1个线程（Thread），模拟1个虚拟用户；②JMeter每发1次请求，就到服务器采样1次，对应1个Sampler（采样）。

• LoadRunner
  LoadRunner在商用领域保持有排前的市场占有率，具有强大的脚本开发功能、完善的函数库及结果分析功能。因其在业内流行很多年，LoadRunner应用的资料相对比JMeter更多，便于学习与应用。

2.性能测试工具选取

若条件允许，则可根据实际测试需求自定义开发测试工具，也可选择市面上常用的测试工具。需要考虑：
1）能否自定义开发，更符合实际测试需求
2）商用的测试工具所需的成本，企业能否承受
3）采购的测试工具是否提供了完善的服务、详细的培训
4）团队人员能否掌握测试活动所需的工具技能

四、性能测试需求分析

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

主要从以下两个用户方确定性能测试需求：

1.业务用户视角

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

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

2.项目团队视角

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

以上从项目开发角度考虑可能需要进行性能测试业务流程，性能测试工程师需对被测对象深入了解，并且需要研发团队配合；除上述两种角度，还可能包括运营团队，需要调研未来业务发展规划，系统需满足未来业务需求的可能性

五、性能测试需求评审

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

1.可测性

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

在一定的时间及成本范围内，构建测试环境，设计、执行测试用例，测试工程师能够相对便捷的发现、定位缺陷，从而协助研发人员修复对应的缺陷。

性能测试 VS 功能测试：

A-相同点：都需要被测对象具备上述的可测性

B-差异点：被测对象运行环境要求不同

• 功能测试：只要被测对象能够在合理的运行环境中正常运行即可，即使测试环境与生产环境可能存在较大的差异
• 性能测试：一定需要尽可能模拟真实的运行环境。当测试环境与实际生产环境差异较大时，性能测试的结果往往不具实际意义；若在性能测试实施过程中，无法搭建相对真实的测试环境，即可认为被测对象不具备性能的可测性。

2.一致性

性能测试需求一致性，主要关注用户需求、生产需求、运营需求几个方面。

• 用户需求：通过对性能测试需求的分析，判断本次测试需求是否满足用户需求规格说明书中明确列出的性能需求项
• 生产需求：关注被测对象运行的真实性，从而在测试结束后能够提供相对准确的数据依据
• 运营需求：需以历史数据or当前运营数据为基础，规划未来业务发展的可能性，从而使得被测对象性能指标具有一定的冗余度

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

3.正确性

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

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