性能测试概述

• 什么是性能测试

  • 定义：性能测试也是软件测试的一种，它的主要方向是测试系统在一定的负荷压力下，系统的响应时间，吞吐量，稳定性，系统的可扩展性等性能指标，并结合应用的架构和实现细节找出问题，并最终确认问题得到解决的过程

  • 目标：验证当前系统能否支持现有用户的访问，弄清楚会有多少用户会在同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出于系统的访问用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现

  • 树立正确的性能测试观念

    • 学习性能测试思维方法和分析方法
    • 学习性能测试整个过程的重要性远大于学习某种性能测试工具的使用

  • 日常生活/工作当中的性能需求

    • 要求系统对用户的操作能快速反应
    • 要求系统能够在大量用户同时使用时保持稳定运行

  • 用户视角的软件性能

    • 从用户的角度来说，软件性能就是软件对用户操作的响应时间
    • 响应时间是用户最关注的性能指标

  • 管理员视角的软件性能

    • 系统的响应时间

    • 系统的状态：资源使用率

    • 系统的可扩展性、处理并发的能力

    • 系统的最大容量

    • 系统可能的性能瓶颈

    • 通过更换哪些设备或扩展可以提高性能

    • 系统在长时间的运行中的稳定性

    • 是否可以不间断地提高业务服务

    • 管理员关心的问题	软件性能描述
      服务器的资源使用状态是否合理	资源利用率
      应用服务器和数据库的资源使用是否合理	资源利用率
      系统是否能够实现扩展	系统可扩展性
      系统最多能支持多少用户的访问？系统最大的业务处理量多少	系统容量
      系统性能可能的瓶颈在哪里	系统可扩展性
      更换哪些设备能够提高系统性能	系统可扩展性
      系统能否支持7*24小时的业务访问	系统稳定性

  • 开发视角的软件性能

    • 基于普通用户和系统管理员

    • 如何通过调整设计和代码实现、系统设置等方法提高软件的性能表现

    • 如何发现并解决软件设计和开发过程中由于多用户访问引起的缺陷

    • 开发人员关心的问题	问题所属层次
      架构设计是否合理	系统架构
      数据库设计是否存在问题	数据库设计
      代码是否存在性能方面的问题	代码
      系统中是否有不合理的内存使用方式	代码
      系统中是否存在不合理的线程同步方式	设计与代码
      系统是否存在不合理的资源竞争	设计与代码
      系统默认参数设置是否合理	系统配置

  • 性能测试完成的事项

    • 评定系统的可行性
    • 评估系统的性能指标
    • 比较多个不同系统或是不同系统配置时的性能特征
    • 找出系统性能问题并确定问题根源
    • 做系统性能调优
    • 找出系统吞吐量的不同等级

  • 为什么要进行性能测试

    • 主要原因：做性能测试的目的主要用于识别系统瓶颈，为将来的测试建立一个基准，并为系统性能调优提供支持，以及能够确定系统性能的目标和需求，并且还能够收集其他的性能相关的数据，能够让决策层做出关于产品总体质量的合理决定。除此之外，性能测试结果和分析也能帮助我们估计当产品上线时需要配置多少硬件来支持相应的业务
    • 其他一些原因：1、评估系统是否可行 2、评估系统结构上的缺陷 3、评定软件性能方面的缺陷 4、改善性能调优的效率

  • 性能测试与项目

    • 性能测试与项目的关系：性能测试做的成功与否，与测试方法和测试自身所关联的项目背景都有关系，若不理解项目背景，测试人员仅仅靠直觉来猜想哪些是重要的，这样很容易造成背离重要的测试点，浪费大量的时间和精力在其他方面上，从而导致项目失败
    • 项目背景包含的一些方面
      • 项目的总体愿景或者目的是什么
      • 性能测试的目标是什么
      • 性能成功遵循的标准是什么
      • 产品开发的生命周期
      • 项目进度规划
      • 项目预算
      • 项目中可用的工具和环境
      • 测试人员和团队的技能
      • 对性能方面，我们所担心的一些点的优先级
      • 部署性能差的系统带来的商业影响
      • 项目流程

• 性能关键指标与计算

  • 响应时间
    • 对请求做出响应所需要的时间，是用户感知软件性能的主要指标
    • 响应时间包括
      • 用户客户端呈现时间
      • 请求/响应数据网络传输时间
      • 应用服务器处理时间
      • 数据库系统处理时间
    • 响应时间多少合理
      • 对于一个web系统，普遍接受的响应时间标准为2/5/10秒
      • 在2秒钟之内响应客户是非常好的
      • 在5秒钟之内响应客户是可以接受的
      • 10秒钟是客户能接受的响应的上限
  • 并发数
    • 并发：用于从业务的角度模拟真实用户访问同时访问
    • 并发数：同时访问系统的用户数
    • 在C/S或B/S结构的应用，系统的性能主要有服务器决定，服务器在大量用户同时访问时，压力最大
    • 并发分为：严格并发和广义并发
    • 如何确定并发数：并发用户数决定于具体的业务场景，在确定并发用户数之前，必须先对用户的业务进行分解，分析出其中的典型业务场景（用户最常用、最关注的业务操作），然后基于场景获得其并发用户数
    • 平均并发用户数的计算：C=nL/T
      • C是平均的并发用户数
      • n是平均每天访问用户数（login session）
      • L是一天内用户从登录到退出的平均时间（login session的平均时间）
      • T是考察时间长度（一天内多长时间有用户使用系统）
    • 并发用户数峰值计算：C^约等于C+3*根号C
      • C^是并发用户峰值
      • C是平均并发用户数
    • 并发用户数计算示例
      • 一个OA系统，该系统有3000个用户，平均每天大约有400个用户访问该系统，对一个典型用户来说，一天只在8小数内使用该系统，且从登录到退出该系统的平均时间为4小时
      • C=400*4/8=200
      • C^=C+3*sqrt(C) =200+3*sqrt(200)=242
  • 吞吐量
    • 指单位时间内系统处理用户的请求数
    • 从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量，用请求数/秒或页面数/秒来衡量
    • 从网络角度看，吞吐量可以用：字节/秒来衡量
    • 对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力
    • TPS:每秒钟request/事务 数量
    • 吞吐量建模
      • 以不同方式表达的吞吐量可以说明不同层次的问题
      • 以字节数/秒方式可以表示主要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈
      • 已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈
    • 吞吐量计算
      • 当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU*R/T
      • 其中F为吞吐量。VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间
  • 系统性能计数器
    • 性能计数器是描述服务器或操作系统性能的一些数据指标
    • 比如：内存、进程、资源使用率等
  • 思考时间
    • Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做性能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作
    • 思考时间-计算方法
      • 首先计算出系统的并发用户数
        • C=nL/T
        • F=R*C
      • 统计出系统平均的吞吐量
        • F=VU*R/T
        • R*C=VU*R/T
      • 统计出平均每个用户发出的请求数量
        • R=u*C*T/VU
      • 根据公式计算出思考时间
        • TS=T/R
  • 网站访问量评估工具
    • http://www.alexa.cn
    • 提供Alexa中文排名官方数据查询，网站访问量查询，网站浏览量查询，排名变化趋势数据查询
    • Alexa是免费提供网站流量信息的公司，创建于1996年，一直致力于开发网页抓取和网站流量计算的工具

• 性能测试方法与流程

  • 基础

    • 性能测试方法概述
      • 性能测试方法是整个性能测试行为的指导
      • 没有合适的方法指导，性能测试很容易成为一种随意的测试行为
      • 使用合适的方法可以更好地保障性能测试取得预期的作用和效果
    • SEI负载测试计划过程
      • 将目标、用户、用例、生产环境、测试环境和测试场景6个区域作为负载测试计划需要重点关注和考虑的内容，重点关注以下几个方面的内容：
        • 生产环境和测试环境的不同
          • 由于负载测试环境与实际的生产环境存在一定的差异，测试环境上对应用系统进行的负载测试结果很可能不能准确反映该系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境
        • 用户分析
          • 通过对用户行为进行分析，依据用户行为模拟建立用例和场景
        • 用例
          • 用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等
        • SEI负载测试计划过程
          • 对负载测试需要关注的具体内容上提供了参考
          • 没有形式实际的可操作的过程
          • 因此并不是一个完整的测试过程
    • RBI方法
      • RBI - Rapid Bottleneck Identify
      • 是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法，该方法基于以下一些事务
        1. 80%的系统性能瓶颈由吞吐量制约
        2. 并发用户数和吞吐量瓶颈之间存在关联
        3. 采用吞吐量测试能够更快速的定位问题
      • RBI方法-策略
        • 先访问“小页面”和“简单应用”，从应用服务器、网络等基础层次上去了解系统吞吐量表现
        • 再选择不同场景、设定不同的并发数，使吞吐量保持趋势增长，通过不断增加并发用户数和吞吐量，观察系统的性能表现
      • 系统瓶颈确定
        • 按照“自上而下”的方式进行分析，首先确定是并发还是吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器、代码自身4个环境确定系统性能具体的瓶颈
      • RBI方法 - 总结
        • RBI方法在性能瓶颈定位过程中能发挥良好的作用
        • 对性能分析和瓶颈定位值得借鉴
        • 但也不是完整的性能测试过程
    • 性能下降曲线分析法
      • 描述性能随用户数增加而出现下降的曲线
      • 该描述中性能可以是
        • 响应时间（主要）
        • 吞吐量
        • 点击率
      • 曲线分析法 - 响应时间曲线
        • 单用户区域 - 性能平坦区 - 压力区域 - 性能拐点
      • 响应时间性能下降曲线包括以下几个区域
        • 单用户区域：一个单用户的响应时间，对建立性能的参考值很有帮助
        • 性能平坦区：系统性能最优秀的区间，该区域可被用作基线
        • 压力区域：应用轻微下降的区域，典型的、最大的建议用户负载是压力区域的开始
        • 拐点：性能开始急剧下降的点
      • 小结
        • 这些区域明确标识了系统性能最优秀的区间、性能开始变坏的区间、性能出现急剧下降的点
        • 对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方
        • 总结：主要关注性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，为性能瓶颈识别和调优提供依据
      • 考题
        • 性能下降曲线的分析中，主要针对的性能指标是：响应时间和吞吐量
        • 分析性能下降曲线时会把曲线划分为几个区间，那么对于分析性能瓶颈有很大作用的是哪一个区间：性能急剧下降区

  • 高级

    • LoadRunner的性能测试过程

      • 第1步	计划测试	测试需求收集、典型场景确定
        第2步	测试设计	测试用例设计
        第3步	创建VU脚本	根据用例创建脚本
        第4步	创建测试场景	测试场景设计和设置，包括监控指标设定
        第5步	运行测试场景	执行测试场景，收集相应数据
        第6步	分析结果	结果分析和报告工作

      • 总结

        • 覆盖了性能测试工作的大部分内容
        • 紧密地与LR工具集成
        • 没有兼顾其他工具或用户自定义工具的需求
        • 没有对测试计划阶段、测试设计阶段的具体行为、方法和目的进行详细描述

    • Segue提供的性能测试过程

      • 通过单用户对系统的访问获取性能取值的基线
      • 设定可接受的性能目标
      • 用不同的并发用户数重复进行测试
      • 该方法非常适合性能调优和优化，通过不断重复的try-check过程，逐一找到可能导致性能瓶颈的地方并进行优化
      • 总结
        • 该过程模拟缺乏对计划】设计阶段的明确划分
        • 没有给出具体的活动和目标

    • 敏捷性能测试

      • 将开发定义为短时间段内的迭代，在每个迭代周期中定义迭代目标，通过轻微级的管理方式管理迭代目标的完成
      • 以迭代为单位组织和管理性能测试，在每个迭代目标中明确定义迭代结束时可被验证的性能目标
      • 示例
        • 在吞吐量为40QPS的情况下，X页面的服务响应时间小于5秒
        • 模块B能够每秒处理来自模块A的1000个请求
        • A类从服务器获取给定A信息的方法耗时不超过100ms
      • 特点
        • 每个迭代目标中包含明确的性能目标
        • 建立不同层次的性能测试
        • 完全或接近完全自动化的性能测试
        • 使用测试驱动方法保证性能与优化性能

    • 性能测试通用模型 - PTGM

      • PTGM（Performance Testing General Model）分为
        1. 测试前期准备
        2. 测试工具引入
        3. 测试计划
        4. 测试设计与开发
        5. 测试执行与管理
        6. 测试分析

  • 一些思考

    • 什么时候可以开始执行性能测试
      • 功能/模块完成并稳定之后开展性能测试
    • RBI认定的（）系统性能瓶颈由吞吐量造成
      • 80%
    • 如何得到性能测试需求，怎么针对需求设计、分析是否达到需求
      • 在查看需求文档，从中提取性能测试需求，与用户交流，了解实际使用情况
      • 结合业务信息设计操作场景总结出需测试的性能关键指标
      • 执行用例后根据提取关键性能指标来分析是否满足性能需求

• 性能测试应用领域

  • 能力验证

    • 能力验证的问题会采用这样的描述方式：系统能否在A条件下具备B能力
    • 应用：为客户进行系统上线后的验收测试，或作为第三方对一个已经部署系统的性能验证
    • 特点
      • 要求在已确定的环境下运行
      • 需要根据典型场景设计测试方案和用例，一个典型场景包括操作序列和并发用户数量条件等
      • 能力验证应用领域，通常采用的测试方法包括：负载测试、可靠性测试、压力测试和失效恢复测试方法

  • 规划能力

    • 规划能力验证应用领域关心的是在给定条件下，系统能否具有预期的表现能力
    • 规划能力应用领域关心的是应该如何使系统具有我们要求的性能能力，或在某种可能发生的条件下，系统具有如何的性能能力
    • 常描述为：系统能否支持未来一段时间内的用户增长，或应该如何调整系统配置，使系统能够满足增长的用户数的需求
    • 特点
      • 是一种探索性的测试：重点是规划，测试不依赖于预先设定的用于比较的目标，而是要求在测试过程中了解系统本身的能力
      • 用于了解系统的性能以及获得扩展性能的方法
      • 常用的测试方法包括：负载测试、配置测试和压力测试

  • 性能调优

    • 对系统性能进行调优
    • 包括：服务器的调整、数据库参数的调整、应用服务器参数的调整、算法的调整、代码优化等
    • 性能调优过程
      • 确定基准环境、基准负载和基准性能指标
        • 基准负载：一种可以被用来衡量和比较性能调优测试结果的标准的应用运行环境、测试脚本和可被用来衡量调优效果的性能指标
      • 调整系统运行环境和实现方法，执行测试包括
        • 硬件环境调整
        • 系统设置调整
        • 应用级别调整
      • 记录测试结果，进行分析
        • 必须为性能调优设定一个可接受的性能调优测试目标，否则，调优过程将会一直持续下去，因为系统始终都不会处于一个最优的状态

  • 缺陷发现

    • 通过性能测试来发现系统中存在的缺陷
    • 主要目的是发现缺陷，并没有可以参照的性能指标或是需要达到的性能目标
    • 通常采用：负载测试、压力测试和失效恢复测试方法

  • 性能基准比较

    • 在不设定明确的性能目标情况下，通过比较得到每次迭代中的性能表现，根据这些变化决定迭代是否到达了预期

  • 性能测试应用领域与测试方法关联

    • 	能力验证	规划能力	性能调优	缺陷发现	性能基准比较
      性能测试	⭐
      负载测试	⭐	⭐	⭐
      压力测试	⭐	⭐	⭐	⭐	⭐
      配置测试		⭐	⭐
      并发测试				⭐	⭐
      可靠性测试	⭐
      失效恢复测试	⭐		⭐	⭐

  • 总结

    • 项目性能测试中通常包括了几个领域的性能测试目标，可以利用性能测试应用领域的方法，将其分解为多个不同的性能测试应用领域，并为其规划不同的测试方法

• 性能测试计划

  • 性能测试计划
    • 性能测试计划概述
      • 通过对性能的需求进行分析，知道了测试对象，了解了测试需求
      • 为了使你对性能测试计划更清晰明白，这里以测试计划的格式来描述
      • 指定一份详细的计划，来规划和指导性能测试工作的进行
    • 性能测试流程
      • 需求评估 - 逻辑了解 - 测试计划 - 环境搭建 - 数据准备 - 脚本开发 - 打压过程 - 问题定位 - 测试报告
    • 测试计划规划测试行为
      • 收集需求 - 分析需求 - 设计方案 - 设计用例 - 搭建环境 - 构造数据 - 配置监控 - 运行负载 - 记录结果 - 分析问题 - 给出调优建议 - 多次测试完成调优 - 生成报告
      • 需求分析
        • 客户交流
          • 响应时间
          • 处理能力
          • 资源占用率
          • 负载量
        • 历史日志
          • 最大峰值访问量
          • 负载特性
          • 行业规则
        • 同类产品
          • 物理特征
          • 最大负载量
          • 系统性能状态
        • 80/20
          • 核心业务
          • 核心负载时间
          • 经验
    • 测试计划内容
    • 测试评审
      • 流程
        • 入口准则 - 计划阶段 - 介绍会议 - 准备阶段 - review会议 - 第三小时会议 - 返工阶段 - 跟踪阶段
      • 如何做好评审
        • 没有评审计划
        • 专家选择不合适
        • 没有充分准备
        • 评审会议偏离主题和重点
        • 评审会议中过多争论占用大量时间
        • 问题修改后跟踪不力
        • 没有使用checklist作为指导
    • 测试环境准备
      • 物理环境
      • 软件环境
      • 测试数据