性能测试基础理论

性能测试基础理论

引用

CSDN

1.

https://m.blog.csdn.net/qq_64743563/article/details/146060293

性能测试基础

1.1 什么是性能？

性能：就是软件质量属性中的“效率”特性

效率特性：

• 时间特性：表示系统处理用户请求的响应时间（时间效率高：不卡；时间效率低：卡）
• 资源特性：表示系统运行过程中，系统资源的消耗情况（包括CPU、内存、磁盘等）

1.2 什么是性能测试？

性能测试概念：使用自动化测试工具，模拟不同场景，对软件各项性能指标进行测试和评估的过程

性能测试主要测试的点为：

• 1.后台处理程序的性能（代码性能）
• 2.应用服务器、数据库、架构设计等是否存在瓶颈
• 3.服务器资源消耗（CPU、内存、磁盘、网络）

1.3 性能测试的目的是什么？

1. 评估当前系统能力

• 例如：验收第三方提供的产品
• 例如：获取关键的性能指标，与其他类似产品进行比较

2. 寻找性能瓶颈，优化性能
3. 评估软件是否能够满足未来的需要

二、策略

2.1 基准测试

为什么要进行基准测试？
1.单用户性能不达标，有必要进行多用户性能测试吗？
2.影响性能的因素（如服务器配置、资源、代码效率等）有很多，如何判断谁在导致性能变好/变坏？

狭义上讲：就是单用户测试。测试环境确定后，对业务模型中的重要业务做单独的测试，获取单用户运行时的各项性能指标。

广义上讲：是一种测量和评估软件性能指标的活动。你可以在某个时刻通过基准测试建立一个已知的性能基准线，当系统的软硬件环境发生变化之后再进行一次基准测试以确定变化对性能的影响。

2.2 负载测试

负载测试：通过逐步增加系统负载，确定在满足系统的性能指标情况下，找出系统所能够承受的最大负载量的测试。

如上述电梯案例，在满足电梯的性能指标（不超过24s）的前提下，最大负载量为13人。

2.3 稳定性测试

概念：在服务器稳定运行（用户正常的业务负载下）的情况下进行长时间测试（1天-1周等），并最终保证服务器能满足线上业务需求。

作用：系统在用户要求的业务负载下运行达到规定的时间时，系统才能正式上线使用。

• 例如：前面电梯案例中，实际测试的最大负载为：13人

• 场景1：如果甲方要求用户正常的负载人数为15人，稳定运行的负载量为多少？

• 场景2：如果甲方要求用户正常的负载人数为10人，稳定运行的负载量为多少？

针对场景1，实际测试的最大负载不满足用户要求的负载，这时说明系统存在bug，不能进行稳定性测试，需要将系统修复为满足最大负载为用户要求的负载才能进行稳定性测试。

针对场景2：可以设置稳定运行的负载量为10或13，因为用户要求正常的负载人数为10人，设置为13时肯定满足。

2.4 压力测试

在强负载下的测试，查看系统在峰值情况下是否功能隐患、系统是否具有良好的容错能力和可恢复能力。

1.极限负载情况下导致系统崩溃的破坏性压力测试

2.高负载下的长时间的稳定性压力测试

2.5 并发测试

并发测试（绝对并发）：是指在极短的时间内，发送多个请求，来验证服务器对并发的处理能力。

生活中的案例：

悬赏任务：做菜一西红柿炒鸡蛋（但是只有一个鸡蛋和一个西红柿）

A和B同时接收任务，A炒西红柿B炒鸡蛋，两人同时进行，那么最后两人都完不成西红柿炒鸡蛋，原因是资源是有限的。

三、指标

3.1 响应时间

响应时间：指用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的结果，整个过程所耗费的时间。

注意：

• 通过HTTP接口请求消息来测试
• 不包括发消息时前端页面的处理时间和收到消息后前端页面的渲染显示时间

3.2 并发数

并发（用户）数：某一时刻同时向服务器发送请求的用户数。

3.3 吞吐量

吞吐量(Throughput)：指的是单位时间内处理的客户端请求数量，直接体现软件系统的性能承载能力。

QPS(Query Per Second)每秒查询数：即控制服务器每秒处理的指定请求的数量。

TPS(Transactions Per Second)每秒事务数：即控制服务器每秒处理的事务请求的数量。

事务：即业务，页面上的一次操作，可能对应一个请求/多个请求。

3.4 点击数

点击数：指客户端向服务端发送请求时，所有的页面资源元素（如：图片、链接、框架css、js等)的请求总数量。

注意：

• 只有web项目才有此指标
• 点击数不是页面上的一次点击

3.5 错误率

错误率：指系统在负载情况下，失败业务的概率。错误率 =（失败业务数/业务总数)*100%。

注意：

• 大多系统都会要求错误率无限接近于0
• 错误率是一个性能指标，不是功能上的随机bug

3.6 资源使用率

资源使用率：是指系统各种资源的使用情况，一般用
资源的使用量/总的资源可用量×100%
形成资源利用率的数据。

根据经验，资源指标通常要求：
(1)CPU不高于75%-85%
(2)内存不高于80%
(3)磁盘IO不高于90%
(4)网络不高于80%

四、流程

4.1 性能测试需求分析

1. 明确被测系统：

• 熟悉被测系统的业务功能
• 熟悉被测系统的技术架构

1. 明确测试内容

• 业务角度：
• 用户使用频率较高的关键业务功能
• 技术角度：
• 逻辑复杂度高的业务
• 数据量大的业务

1. 明确测试策略（负载测试、稳定性测试、并发测试等）
2. 明确测试指标

• 有明确需求指标：
• 执行结果与预期指标进行对北比
• 无明确需求指标（分析指标）：
• 查找资料
• 类似的系统对比
• 对未来流量的预估

4.2 性能测试计划和方案

1. 测什么

• 项目背景
• 测试目的
• 测试范围

1. 谁来测

• 进度与分工
• 交付清单

1. 怎么测

• 测试策略

4.3 性能测试执行

1. 建立测试环境

• 搭建性能测试环境，包括硬件环境、软件环境、网络环境
• 提示：一般情况下可以要求运维和开发工程师协助完成

1. 编写测试脚本

• 按照性能测试用例的需要，使用性能测试工具进行编写测试脚本
• 提示：脚本可以自己编写，也可以使用工具来录制

1. 性能测试监控

• 在脚本执行前，配置各项性能的监控指标。
• 如：响应时间、TPS、错误率、资源使用率(CPU、内存、磁盘等)

1. 执行测试脚本

• 设置性能运行场景，执行性能测试，并同步收集各项性能指标
• 提示：执行性能测试脚本前，保证脚本都调试通过

4.4 性能分析和调优

说明：性能测试分析人员经过对结果的分析以后，如果不符合性能需求，则会提出性能bug,然后由开发人员进行后续的调优。

提示：

• 调优
  － 开发人员为主导，数据库管理员、系统管理员、网络管理员、性能测试分析人员配合进行
• 验证
  －性能测试人员继续进行第二轮、第三轮…的测试，与以前的测试结果进行对比，从而确定经过调整以后系统的性能是否有提升

4.5 性能测试报告总结

测试报告是对性能测试工作的总结，为软件后续验收和交付打下基础。

测试报告的主要内容：

• 测试工作的经过回顾
• 缺陷分析和调优
• 风险评估
• 性能测试结果
• 测试工作总结与改进