神马文学网基础篇二
来源：百度文库 编辑：神马文学网 时间：2024/04/28 15:25:27
第一部分 基础篇
第1章 软件性能测试基本概念
1.1什么是软件性能
性能是一种指标,表明软件系统或构件对于其及时性要求的符合程度;其次,性能是软件产品的一种特性,可以用时间来进行度量.
性能的及时性用响应时间或者吞吐量来衡量.
对于交互式应用(例如典型的web应用)来说,我们一般以用户感受到的响应时间来描述系统的性能,而对于非交互式应用(嵌入式系统或者银行等的业务处理系统)而言,响应时间是指系统对事件产生响应所需要的时间.
软件对用户操作的响应时间.分客观和主观两种情况.
系统的响应时间+系统状态的相关信息.(系统的可扩展性\并发能力等指标)
响应时间+性能瓶颈.
如何通过调整设计和代码实现,或是如何通过调整系统设置等方法提高软件的性能表现.
对软件性能问题进行定位,了解性能的制约因素和引起性能问题的关键原因.
1.2软件性能的几个主要术语
1.2.1响应时间
对请求做出响应需要的时间.
合理的响应时间取决于实际的用户需求.
1)业务角度 业务并发数
2)服务端承受的压力 并发数
吞吐量是指”单位时间内系统处理的客户请求的数量”,直接体现软件系统的性能承载能力.一般来说,吞吐量用请求数/秒或者是页面数/秒来衡量,从业务的角度,吞吐量也可以用访问人数/天或者是处理的业务数/小时等单位来衡量.当然,从网络的角度来说,也可以从字节数/天来考察网络流量.
不同的并发用户数,对同一个系统施加相同的吞吐量压力,很可能得到不同的测试结果.
吞吐量本身是个直观的指标,两个不同系统可能具有不同的用户数和用户使用模式,但如果具有基本一直的吞吐量,则可以说,他们具有基本相同的平均处理能力.
性能计数器(Counter)是描述服务器或者操作系统性能的一些数据指标.例如,对于windows系统来说,使用内存数(Memory In Usage),进程时间(Total Process Time)等都是常见的计数器.
在性能测试中常用资源利用率进行横向的对比.e.g.在进行测试时发现,资源A的使用率达到了接近100%的数值,而其他资源利用率都处于比较低的水平,则可以很清楚地知道,资源A就很有可能是系统的一个性能瓶颈.
业务角度:这个时间指的是用户在进行操作时,每个请求之间的间隔时间.
如果测试的目的是为了”验证应用系统具有预期的能力”(也就是所说的”能力验证”的应用领域),就应该尽量模仿用户在使用业务时的真实思考时间;如果目的是进行更一般的研究,例如”了解系统在压力下的性能水平”或者”了解系统承受压力的能力”(也就是所说的”规划能力”的应用领域),则可以采用0思考时间.
1.3软件性能测试方法论
关注于负载测试计划的方法,其目标是产生”清晰,易理解,可验证的负载测试计划”.过程包括6个区域:目标,用户,用例,生产环境,测试环境和测试场景.
RBI(Rapid Bottleneck Identify)方法是一种用于快速识别系统性能瓶颈的方法.给方法基于以下一些事实:
1.发现的80%系统的性能瓶颈都有吞吐量制约.
2,并发用户数和吞吐量瓶颈之间存在一定的关联;
3.采用吞吐量测试可以更快速定位问题.
性能下降曲线实际上描述的是性能随用户数增长而出现下降趋势的曲线.这里所说的性能可以是响应时间,也可以是吞吐量或者点击数/秒的数据.一般主要指响应时间.
这种分析法主要关注性能下降曲线上的各个区间和响应的拐点,通过识别不同的区间和拐点,从而为性能瓶颈识别和性能调优提供依据.
计划测试,测试设计,创建VU脚本,创建测试场景,运行测试场景和分析结果6个步骤.
从确定性能基线开始,通过单用户对应用的访问获取性能取值的基线,然后设定克接受的性能目标(响应时间),用不同的并发用户数等重复进行测试.适合性能调优和性能优化.
过程分为测试前期准备,测试工具引入,测试计划,测试设计与开发,测试执行和管理以及测试分析等6个步骤.
1.4本章小结
第2章 性能测试的应用领域
2.1性能测试的方法
2.1.1 性能测试
通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。
特点：
（1）：主要目的是验证系统是否有系统宣称具有的能力。
（2）：需要事先了解被测试系统典型场景，并具有确定的性能目标。
（3）：这种方法要求在已确定的环境下运行。
通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。 这种方法可以找到系统的处理极限，为系统调优提供数据。又称“可量性测试”。
特点：
（1）：主要目的是找到系统处理能力的极限。
（2）：需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。
（3）：一般用来了解系统的性能容量，或者是配合性能调优来使用。
测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
特点：
（1）：主要目的是检查系统处于压力情况下时，应用的表现。
（2）：一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
（3）：一般用于测试系统的稳定性。
通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
（1）：主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
（2）：一般在对系统性能状况有初步了解后进行。
（3）：一般用于用户性能调优和规划能力。
通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
特点：
（1） 主要目的是发现系统中可能隐藏的并发访问时的问题。
（2） 主要关注系统可能存在的并发问题，例如系统中的内存泄露、线程锁和资源争用方面的问题。
（3） 可以在开发的各个阶段使用，需要相关的测试工具的配合和支持。
一般来说，并发测试出了需要性能测试工具进行并发负载的产生外，还需要一些其他工具进行代码级别的检查和定位。
通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行。一般用“平均无故障时间”（MTBF）或是“失效率”来衡量。
特点：
（1）：主要目的是验证系统是否支持长期稳定的运行。
（2）：需要在压力下持续一段时间的运行。
（3）：需要关注系统的运行状况。
针对有冗余备份和负载均衡的系统设计。
特点：
（1）：主要目的是验证在局部故障情况下，系统能否继续使用。
（2）：这种性能测试方法还需要指出，当问题发生时“能支持多少用户访问”的结论和“采用何种应急措施”的方案。
（3）：一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。
2.2性能测试应用领域分析
描述方式：系统能否在A条件下具有B能力？
特点：
（1）：要求在已确定的环境下运行。
（2）：需要根据典型场景设计测试方案和用例。
描述方式：“某系统能否支持未来一段时间内的用户增长”或是“应该如何调整系统配置，使系统能够满足增长的用户数的需要”
特点：
（1）：是一种探索性的测试
（2）：可被用来了解系统的性能以及扩展性能的方法
一个标准的系统性能调优过程：
（1）确定基准环境、基准负载和基准性能指标
所谓的标准是指每次执行性能测试时的环境严格保持一致。
（2）调整系统运行环境和实现方法，执行测试
3个方面的调整：硬件环境，系统设置，应用级别
（3）记录测试结果，进行分析
2.2.5总结
2.3本章小结
第3章 性能计数器及性能分析方法
3.1操作系统计数器及分析
3.1.2UNIX操作系统的主要计数器
3.1.3内存分析方法
内存分析用于判断系统有无内存瓶颈，是否需要通过增加内存等手段提高系统性能表现。
3.1.5磁盘I／O分析方法
3.1.6进程分析方法
3.1.7网络分析方法
3.2应用服务器计数器
3.2.1IIS应用服务器计数器
3.2.2J2EE应用服务器计数器
3.3数据库计数器
3.4本章小结
第4章 性能测试工具原理
4.1性能测试工具模型
性能测试工具包括以下部件：
虚拟用户脚本产生器：截获数据流-〉根据录制时选择的协议类型，对数据流进行分析-〉用脚本函数将客户端和服务端之间的数据流交互过程体现为脚本的语句。
压力产生器：根据脚本内容，产生实际的负载。
用户代理：运行在负载机上的进程，该进程与产生负载压力的进程或者线程协作，接受调度系统的命令，调度产生负载压力的进程或者线程。从这个意义上来说，用户代理也可以是被看作是压力产生器的组成部分。用户代理一般以后台方式在负载机上运行。
压力调度和监控系统：性能测试工具中直接与用户交互的主要内容。是否具有强大的性能计数器监控能力通常也是衡量性能测试工具的功能是否完备的指标之一。
压力结果分析工具：不能代替分析者进行性能结果的范喜，最多只是提供多种不同的数据揭示和呈现方法而已。对这些数据进行分析必然要依靠测试工程师对系统性能分析的经验和知识。
4.2性能测试脚本录制时的协议类型
4.3性能测试工具的选择与评估
4.4本章小结
第5章 性能测试的组织
5.1性能测试团队的人员构成
角色：项目测试经理，测试设计，测试开发，测试执行，测试分析，支持
5.2性能测试的过程模型
（1）：系统计出功能验证
（2）：组建测试团队
（3）：测试工具需求确认
（4）：性能预备测试（可选活动）
工具选择-〉工具应用技能培训-〉确定工具应用过程
性能测试领域分析-〉用户活动剖析与业务建模-〉确定性能目标-〉确定测试时间计划
测试环境设计-〉测试场景设计-〉测试用例设计
建立测试环境->部署测试脚本和测试环境->执行测试和记录结果
性能分析的通用方法之一就是“拐点分析”的方法。“拐点分析”方法是一种利用性能计数器曲线图上的拐点进行性能分析的方法，该方法的基本思想是基于这个事实：性能产生瓶颈是由于某个资源的使用达到了极限，此时的表现是随着压力增大系统性能表现急剧下降，因此，只要关注性能表现上的“拐点”，获得“拐点”附近的资源使用情况，就能够定位出系统的性能瓶颈。“拐点分析”的方法在确定引起系统瓶颈的系统资源方面能发挥一定作用，但由于其只能定位到岛资源上的制约，而不能直接定位到引起制约的原因，因此，该方法还必须配合其他方法使用，才能最终确定引起性能瓶颈的最根本原因。可用于“拐点分析”的图表包括“负载--响应时间曲线”、“负载—吞吐量曲线”等。