软件测试之性能测试

软件测试之性能测试

性能测试是与时间相关的

主要内容

  1. 性能测试基础
  2. 概念和术语介绍
  3. 性能测试模型
  4. 性能测试分类介绍
  5. 性能测试实施与管理

性能测试基础

为什么要进行性能测试(WHY)(最重要)

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

    问题的根源一般是
    在多种平台上的数百个服务器;异构系统、多种应用;数千个工作站;局域网、广域网和 其它分类型的分布式网络体系机构;交错的故障点。

    误区:提高一下硬件配置就可以提高性能了,因此性能测试不重要?
    该说法是错误的。只能是临时解决问题,而不能从根本上解决问题。

进行性能测试时,要关注什么?(WHAT)

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

谁来关注?(WHO)

  • 开发人员
    • 系统架构:架构是否合理?
    • 数据库设计:数据库设计是否存在问题?
    • 代码:代码是否存在性能问题?系统中是否存在不合理的内存使用方式?
    • 设计和代码:系统中是否存在不合理的线程同步方式和不合理的资源竞争?
  • 系统管理人员
    • 资源利用率:应用服务器和数据库使用状况合理吗?
    • 系统容量:系统最多能支持多少用户的访问?最大的业务处理量是多少?
    • 系统稳定性:系统能否支持7*24小时的业务访问?
    • 系统可拓展性:系统能否实现拓展?系统性能可能的瓶颈在哪?
  • 用户
    • 响应时间过长会是用户烦躁不安(3/5/8)。
    • 系统稳定性:出现HTTP 500 错误或数据库崩溃会让用户对系统失去信心。
  • 业务人员
    • 参数:如何向用户提供参数,例如:支持多少用户使用?响应时间是多少?
  • 测试人员
    • 以上都要关注
    • 能否发现系统中出现的瓶颈?
    • 能否真实有效的评估系统性能能力?

关注的领域主要是?(WHERE)

  • 能力验证
    • 性能测试中最简单也是最常用的一种。主要关心:在给定的条件下,系统能否具有预期的表现?
  • 规划能力
    • 主要关心:应该如何才能使系统具有我们要求的性能能力?
  • 性能调优
    • 性能调优活动回合其他领域的活动交杂在一起。是一种在开发阶段和测试阶段都可能会涉及到的性能测试应用领域。
  • 发现缺陷

    • 主要目的是:通过性能测试的手段来发现系统中存在的缺陷。

    误区:
    性能测试独立于功能测试 。
    此说法是不对的。性能测试是依赖于功能测试。

何时进行性能测试?(WHEN)

  • 一般在功能测试的中后期进行。

概念和术语介绍

性能测试是通过自动化的测试工具模拟各种正常、峰值以及异常负载条件来对系统的各项性能指标的测试。

做性能测试一般关注的性能指标是什么?

并发数

  • 系统用户数:该系统的注册用户数。例如,QQ有100个注册用户。
  • 在线用户数:即登录的用户数。例如,100个人里面有60个人为在线状态。
  • 并发用户数:是对服务器产生压力的用户。例如,这60个人里面只有20个人在进行通信或其他操作。这20个人就是并发用户数。

    并发用户数:同一时间进行同一操作的用户数。

响应时间
又叫请求响应时间:TTLB
对请求做出响应所需要的时间一般为:

 网络请求的时间 + 服务器处理的时间 + 网络响应的时间

事务响应时间
事务是一组密切相关的操作组合。登录就是一个事务。

每秒事务通过数
TPS是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。
当压力加大时,TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈了。如果环境没有大的变化,对于同一系统会存在一个最大处理事务能力,它并不随着并发用户数的增减而改变。

点击率
每秒点击数代表用户每秒向Web服务器提交的HTTP请求数。
点击率越大,服务器压力越大。

吞吐量
单位时间内系统处理的客户请求的数量。(根据业务来说的)直接体现软件系统的性能承载能力,一般来说用请求数或页面数来衡量。

从业务角度,吞吐量也可以用访问人数/天或是处理的业务数/小时来衡量;
从网络角度,吞吐量可以用字节/天来衡量。

思考时间
就是用户两个执行动作之间停留的时间。

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

性能测试模型

曲线拐点模型

图片

总结:随着并发用户数的增加,吞吐量与资源利用率增加,说明系统在积极处理,所以响应时间增加的并不明显,处于比较好的状态。但随着并发用户数的持续增加,压力也在持续加大,吞吐量与资源利用率都达到了饱和,随后吞吐量急剧下降,造成响应时间急剧增长。轻压力区与重压力区的交界点是系统的最佳并发用户数,因为各种资源都利用充分,响应也很快;而重压力区与拐点区的交界点就是系统的最大并发用户数,因为超过这个点,系统性能将会急剧下降甚至崩溃。

性能测试分类

基准测试、性能测试、负载测试、压力测试、配置测试、并发测试、可靠性测试、失效恢复测试、大数据量测试

基准测试
有基础的标准,这样能通过对比发现系统的不同点与变化。
应用场景:

  1. 可以在制定的标准下通过基准测试建立一个性能基准,这样以后当系统的环境、参数发生变化之后,再进行一次相同标准下的测试,即可看出变化对性能的影响。
  2. 系统进行基准测试可以在较早的阶段发现性能问题。
  3. 某系统从来没有进行任何性能测试,需要对该系统做一次性能评估作为后续开发调优的参考。

狭义性能测试
通过模拟生产运行的业务压力和使用场景组合,测试系统的性能能否满足生产系统要求。是一种常见的测试方法。

负载测试
负载测试是在被测系统上不断增加压力,直到性能极致。例如:响应时间已经超过预定指标或者某种资源使用已将达到饱和状态。
主要目的是:找系统的负载极限,为系统调优提供数据。

压力测试
压力测试的目的是:找出高负载下系统的问题,例如资源竞争、同步问题、内存泄露等。

负载测试和压力测试两者可以结合进行。
负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加是,系统各项性能指标的变化情况。
压力测试,是通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试。

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

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

并发用户数和并发数是不一样的。

可靠性测试
是通过给系统加载一定的业务压力的情况下,让应用系统持续运行一段时间,测试系统在这种条件下是否能够稳定运行。

失效恢复测试

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

大数据量测试
有两种类型:

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

各个测试类型的测试目的

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

性能测试实施

性能测试的实施:

  • 前期准备(功能稳定、组件团队)
  • 选择工具(进行对于工具的培训)
  • 性能测试方案(需求、计划、方案、策略、资源)
  • 性能测试设计(准备环境—设计场景—编写脚本—辅助工具)
  • 性能测试执行(执行脚本—记录结果)
  • 性能调优与分析
  • 性能测试报告

性能测试前期准备

  1. 系统基础功能验证
    确保当前需要进行测试的应用系统具备了进行性能测试的条件。
    确保当前进行性能测试的应用系统版本已经稳定。
  2. 组建测试团队
    确定团队内角色的构成,以及确定人员的技能。

测试工具

  1. 工具选择
    选择项目适合的性能测试工具。Loadrunner。
  2. 工具应用技能培训
    为项目组的相关参与者进行测试工具的应用技能培训,以使参与者能够具备测试需要的技能 。
  3. 确认工具应用过程
    确定测试工具在测试中的具体应用范围,并不是“工具无所不能”,哪些工作使用工具完成,哪些无法使用工具完成 。

性能测试方案

  • 调研测试需求
    • 测试业务范围
    • 测试环境:硬件环境、软件环境、网络环境
    • 测试目的
    • 性能指标:业务性能指标、系统性能指标
  • 测试策略和测试资源需求
    • 测试策略:测试工具、测试方式、测试执行
  • 性能测试计划:即是如何实施性能测试,概括为以下5点:
  1. 编写性能测试方案
  2. 测试环境准备:
    应用软件部署、检查
    数据库基础数据导入
  3. 测试脚本、测试数据
    脚本参数化
    脚本调试
  4. 测试执行
    压力测试、系统调优
    负载测试
  5. 编写性能测试报告

各种测试通用的实施步骤:需求—方案—代码实现—执行—产出报告

性能测试设计

  1. 测试环境设计
    性能测试的结果与测试环境之间的关联性非常大,无论那种性能测试,都必须首先确定测试的环境,包括系统的 软/硬件环境、数据库环境等等 。
  2. 测试场景设计
    测试场景模拟的一般是实际业务进行的一个剖面,其包括业务、业务比例、测试指标的目标、测试过程中需要监控 的性能计数器 。
  3. 测试用例的设计
    对测试场景近一步细化,一般包括:测试类型、测试内容描述、前置条件、业务操作序列、参数化需求。验证点等。
  4. 脚本和辅助工具开发

性能测试执行

  1. 建立测试环境
  2. 部署测试脚本和测试场景
  3. 执行测试和记录结果

性能测试分析与调优

测试结果分析是最难的部分。是一个灵活的过程,每次性能测试结果的分析都需要测试分析人员具有相当程度的对 软件性能、软件架构和各种性能测试指标的了解,性能测试分析需要借助各种图表。 通用方法:拐点分析法。

性能测试报告

  1. 要测试的目标
    本次性能测试预期要达到的性能要求。
  2. 测试概要描述
    结构、时间、地点、人员、工具、环境、测试过程简介
  3. 测试结果和数据
  4. 测试结论

猜你喜欢

转载自blog.csdn.net/bit666888/article/details/81746538