软件性能测试 - 基础与方法

基本概念

Web前端性能

Web应用的前端响应时间指浏览器的页面加载时间。一般而言，浏览器的页面加载时间包括对HTML的解析、对页面上的图片及CSS等文件的获取和加载、客户端脚本（JavaScript）的执行时间以及对页面进行展现所花费的时间，这部分性能体现就被称为前端性能。

前端性能与并发用户量的大小无直接的关系，主要考察浏览器的展现和脚本之心时间。

故主要关注：

• 浏览器展示页面的方式
• 浏览器各种机制的合理应用
• 脚本的合理性

主要术语

响应时间

【概念】对请求做出响应需要的时间。

• 呈现时间：客户端收到数据后呈现给用户所消耗的时间
• 服务端响应时间：系统从请求发出到客户端接收到数据所消耗的时间
  • 通常由网络传输时间+应用延迟时间（数据库延迟时间、应用服务器延迟时间）

并发用户数

【概念】在同一个时间段内访问系统的用户数量。

• 服务端承受的最大并发访问数：不从业务角度出发，而从服务端承受的压力出发，描述同时向客户端发送请求的客户数量。
• 系统用户数：使用该系统的用户总数
• 平均并发用户数：

C = \frac{nL}{T}

login session: 用户从登录进入系统到退出系统之间的时间段（A login session is a time interval defined by a start time and end time. Take any web application that requires user authntication as an example,a login session starts from the time the user logs on to the system and ends when the users logs out.）

n: login session 的数量

L: login session 的平均长度

T: 考察的时间段长度

• 并发用户数峰值：

C_1 = C+3\sqrt{C}

• 系统总的吞吐量

u·C

u：平均每个用户发出的请求数

• 通过日志分析法log analyzer了解系统用户的使用状态，从日志中计算得出服务器承受的最大并发用户访问数。

吞吐量

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

• 衡量单位
  • 一般：请求数（单击数）/秒 or 页面数/秒
  • 业务角度：访问人数/天 or 处理的业务会数/小时
  • 网络角度：字节数/天

单击数Hits: 指客户端发出的http请求的数量而非html页面上的单击事件。（一次单击事件可以请求多个资源，产生多个Hits）

• 吞吐量计算
  • 在没有遇到性能瓶颈时，吞吐量可以采用以下公式计算

F = \frac{N_(vu)·R}{T}

F：吞吐量

Nvu：vu的个数

R：每个vu发出的请求（单击）数量

T：性能测试所用的时间

• 吞吐量往往在VU数量增长到一定程度时会产生性能瓶颈

性能计数器

Counter是描述服务器或操作系统性能的一些数据指标，在性能测试中发挥监控和分析的作用。

Think Time

思考时间，也称为休眠时间。

R = \frac{T}{T_s}

R：每个vu发出的请求（单击）数量

T：性能测试所用的时间

Ts:思考时间

软件性能测试方法论

SEI Load Testing Planning Process

关注于负载测试计划的方法，目标是产生清晰、易理解、可验证的负债测试计划。
关注点：

• 目标
• 用户
  • 必须对用户行为进行分析，依据用户行为模型建立用例和场景。
• 用例
  • 用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说主要在于分析和分解出关键的业务 -> 判断每个业务发生的频度、业务出现性能问题的风险等。
• 生产环境
• 测试环境
  • 由于负载测试环境与实际的生产环境存在一定的差异，很大概率不能准确反映该应用系统在生产环境上的实际性能表现，故须仔细设计测试环境。
• 测试场景

RBI(Rapid Bottleneck Identify)

关注快速识别系统性能瓶颈的方法，此方法基于以下事实：

• 发现的80%系统到性能瓶颈都由吞吐量制约
• 并发用户数和吞吐量瓶颈之间存在一定关联
• 采用吞吐量测试可以更快速地定位问题

分析方法(自上而下)：

• 首先分析由并发还是吞吐量引发的性能表现限制
• 从网络、数据库、应用服务器和代码本身确定系统性能具体的瓶颈

性能下降曲线分析

性能下降曲线是描述性能（响应时间、吞吐量、单击数/秒）随用户数增加而出现下降趋势的曲线。

曲线阶段

• 单用户区域： 对系统的一个单用户的响应时间
• 性能平坦区：在不进行更多性能调优的情况下所能期望达到的最佳性能。此区域被用作基线或benchmark
• 压力区：性能轻微下降的区域。典型的、最大的建议用户负载时压力区域的开始。
• 拐点：性能开始急剧下降的点

敏捷性能测试

特点：

1. 在每个迭代目标中包含明确的性能目标
   
   
   迭代目标中的性能目标可能是基于端到端的，也可能是基于接口的，甚至可能是面向具体的函数的。例如：
   • 在吞吐量为40 QPS的情况下，X页面的服务端响应时间小于5秒。
   • 模块B能够每秒处理来自模块A的1000个请求。
   • Employee类从服务端获取给定Employee信息的方法耗时不超过100毫秒。
2. 建立不同层次的性能测试
   • 面向函数的性能：
     • 通过Junit 4 或 TestNG中的@Test 来设置验证标准。
     • 函数级别的性能测试对环境的依赖性小，对其他模块和函数也不存在很强的依赖性，因此可以很容易地放置在持续集成中与其他单元测试一同运行。
   • 面向接口的性能：
     • 通过Junit 4等工具进行接口级别的性能测试。
     • 要求将模块或子系统运行起来，并设置好测试的支撑环境。
   • 面向端到端的性能：
     • 端到端的性能结果与所在环境存在极大的依赖性，需要在严格定义的环境上运行。
     • 需要为被测应用准备号一键部署脚本
     • 使用合适的工具和脚本进行性能测试。
3. 完全或接近完全自动化的性能测试
   • 性能测试工具
     • HP LoadRunner
     • Jmeter
     • Junit
   • 设置环境的脚本
   • 性能压测脚本
4. 使用测试驱动的犯法保证性能于优化性能
   
   
   TDD , 需要在编写代码前设置测试。一旦测试通过，意味着代码实现完成。

性能测试模型

PTGM Performance Testing General Model

• 测试过程
  • 测试前期准备
  • 测试工具引入
  • 测试计划
  • 测试涉及与开发
  • 测试执行与管理
  • 测试分析

APTM Agile Performance Testing Model

• 主要构成
  • 检查表
  • 活动
  • 建议工具

性能测试应用

性能测试方法

Performance Testing includes these:

• 验收性能测试 Acceptance Performance Testing
• 负载测试 Load Testing
• 压力测试 Stress Testing
• 配置测试 Configuration Testing
• 并发测试 Concurrency Testing
• 可靠性测试 Reliability Testing
• 失败恢复测试 Failover Testing