10.性能测试

性能测试

1.为什么要进行性能测试？

• 应用程序是否能够很快的响应用户的要求？
• 应用程序是否能处理预期的用户负载并有盈余能力？
• 应用程序是否能处理业务所需要的事务数量？
• 在预期和非预期的用户负载下，应用程序是否稳定？
• 是否能确保用户在真正使用软件时获得舒服的体验？

问题的根源是什么？

• 在多种平台上的数百个服务器
• 异构系统、多种应用
• 数千个工作站
• 局域网、广域网和其他分类型的分布式网络体系结构
• 交错的故障点

2.性能测试关注什么？

（1）关注点

• 并发用户数/吞吐量
• 平均响应时间
• 服务器资源占用情况
• 可靠性、可扩展性
• 发现引起系统问题的原因,关注采用何种技术提高系统性能
• 软、硬件配置是否合适（容量规划/硬件选型）

（2）不同人群关注点

1）开发人员

• 系统架构：架构设计是否合理？
• 数据库设计：数据库设计是否存在问题？
• 代码：代码是否存在性能问题？系统中是否存在不合理的内存使用方式？
• 设计和代码：系统中是否存在不合理的线程同步方式和不合理的资源竞争？

2）系统管理人员（操作系统、网络、服务器等等）

• 资源利用率：应用服务器和数据库资源使用状况合理吗？
• 系统容量：系统最多能支持多少用户的访问？系统最大的业务处理量是多少？
• 系统稳定性：系统是否能支持7X24小时的业务访问？
• 系统可扩展性：系统是否能够实现扩展？系统性能可能的瓶颈在哪里？更换哪些设备能够提高系统性能？

3）用户

• 响应时间：过长时间的等待会让使用者烦躁不安；
  对于一般的web网站来说，在欧美国家普遍的标准为原则3/5/8(2/5/10)：
  3: 3秒钟用户会觉得是一个很好的体验。
  5: 5秒钟用户可能会觉得差了一点，还行，比较好。
  8: 8秒钟是用户所能承受的最大极限
• 系统稳定性：出现HTTP500错误或数据库崩溃会让用户对系统失去信心

4）业务人员

• 参数：如何向用户提供参数，例如支持多少用户使用？响应时间是多少？

5）测试人员

• 以上所有层面都需要关注：
  是否能够发现系统中存在的瓶颈？
  是否真实有效的评估系统性能能力？

3.概念和术语

（1）并发数

狭义：同一时刻访问同一个系统的同一个功能的用户数量

广义：同一时刻向系统的服务器发送请求（可以是不同的功能）的用户数量

系统与用户数：注册了该系统的用户数量

在线用户数：同一时刻登录系统的用户数量

并发数：给服务器发送请求（产生压力）的用户数量

（2）响应时间（3、5、8原则）

响应时间 =2* 网络传输时间+2* 服务器处理时间（包含数据库）+人的反应时间

（3）事务响应时间（TRT）

事务：一组原子性操作集合。

事务响应时间：作为事务的一组操作所需要的响应时间。

（4）每秒事务通过数（TPS）

每秒系统能够处理的事务数。是衡量系统性能的重要指标。

（5）点击率

点击率：每秒用户向web服务器提交的HTTP请求数（即一次点击不止一个请求），点击率越大，服务器压力越大。

（6）吞吐量

吞吐量：一段时间服务器处理的信息量

（7）吞吐率

吞吐率：单位时间服务器处理的信息量

理发店模型：当超过吞吐率时，单位响应时间会增加。

（8）思考时间

思考时间：用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实的模拟用户操作的场景。

（9）资源利用率

不同系统资源的使用情况。CPU,Memory，磁盘，网络。

3.性能测试模型

（1）性能测试分类

• 基准测试：有基础的标准，这样能通过对比发现系统的不同点与变化。（该系统从未做过性能测试，对系统初始性能做一个记录）

• 狭义性能测试：以下测试都属于狭义的性能测试

• 负载测试：负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，这种测试方法可以找到系统的处理极限，为系统调优提供数据。

  • 并发量测试：增加用户量。系统在一定的软硬件环境下，其他指标不变，向系统中不断的增加用户数量，查看系统在各个用户数量级别下系统性能指标的表现。

  • 容量测试：增加数据库数据量。系统在一定的软硬件环境下，其他指标不变，向系统的数据库中不断的增加数据量，查看系统在各个数据量级别下系统性能指标的表现。

    拐点：响应时间。358原则。

• 压力测试： 高于系统负载情况下，测试系统的表现（性能、稳定性）。压力测试是测试系统在一定饱和状态下，例如CPU、内存等在饱和使用状态下，系统能够处理的会话能力，以及系统能否会出现错误。

• ==并发测试：==并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁或者其他性能问题。

• 配置测试：配置测试方法是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则

• 可靠性测试：可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。（低于最高负载）

• 失效恢复测试：

  1. 失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障，用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。
  2. 一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出现问题，应用系统仍然可以正常执行业务**。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常发挥作用**
  3. 不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统

• 大数据量测试：

  1. 独立的数据量测试
     针对某些系统存储、传输、统计、查询等业务进行大数据量测试
  2. 综合数据量测试
     和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案，尤其是并没有明确给出系统需要持续运行指标的系统

• 大数据量测试：

  1. 独立的数据量测试
     针对某些系统存储、传输、统计、查询等业务进行大数据量测试
  2. 综合数据量测试
     和压力测试、负载测试、并发测试、可靠性测试相结合的综合测试方案