性能测试实例.docx
《性能测试实例.docx》由会员分享，可在线阅读，更多相关《性能测试实例.docx（18页珍藏版）》请在冰豆网上搜索。
性能测试实例
性能测试开展指导
项目测试组
<文档编号>
❑Version1.55
2005-6-15
INTERNALUSEONLY
©Copyright2005
文档信息
1.标题（TitleandSubtitle）
性能测试指导书
2.文档编号
3.作者（Author（s））
Hzg1126
4.最后发布时间
2005-6-15
5.概述
6.关键字（keywords）
7.总页数
共144页
修改历史
日期
版本
作者
修改内容
评审号
更改请求号
2005-6-15
1.0
Hzg1126
2005-6-15
1.05
Hzg1126
修改2.3.3产品部署阶段的性能测试目标
2005-6-16
1.1
Hzg1126
修改11响应时间的定义
2005-6-20
1.55
Hzg1126
新增2.2.2确定性能测试目标的方法
新增14确定最小用户负载
新增15性能测试的两个基本类别
新增16性能测试生存周期
2005-6-21
1.85
Hzg1126
新增17后台活动分析
新增18关键性能尺度标准
新增19镜像生产环境
2005-6-24
2.15
Hzg1126
新增20用户思考时间的问题
新增21
摘要
本摘要提出了各位teamleader需要关注的问题：
目录
关注问题
相关人员
2.1.2
确定性能需求的解决方法
Leader、业务人员、DBA、系统部人员、性能测试工程师
2.2.1
确立性能测试目标的原则
Leader
2.3
不同阶段的性能测试目标
Leader
3.1
性能测试方案的确立
性能测试工程师
3.2
用例和场景设计
性能测试工程师
3.3
设定需要监控的资源
性能测试工程师
4
性能测试的应用领域
Leader、性能测试工程师
5.1
分析影响性能因素的步骤
设计人员、DBA、性能测试工程师
5.2
开发角度性能问题的原因
开发人员、设计人员、DBA、leader
6
产品部署阶段
leader
7
维护阶段
leader
8
性能测试的策略
性能测试工程师
9
各阶段所要进行的性能测试
设计人员、开发人员、Leader、性能测试工程师
10
系统的稳定性度量
Leader、性能测试工程师
11
性能测试的基本概念
性能测试工程师
12
响应时间的分解
性能测试工程师
13
在性能测试中需要注意的问题
性能测试工程师
目录
1编写目的3
2需求阶段3
2.1性能测试需求的确立3
2.1.1性能测试需求的来源3
2.1.2确定性能测试需求的解决方法3
2.2确立性能测试目标3
2.2.1确立性能测试目标的原则3
2.2.2确定性能测试目标的方法3
2.3不同阶段的性能测试目标3
2.3.1设计阶段的性能测试目标3
2.3.2开发阶段的性能测试目标3
2.3.3产品部署阶段的性能测试目标3
2.3.4系统维护阶段的性能测试目标3
3设计阶段3
3.1性能测试方案的确立3
3.2用例和场景设计3
3.3设定需要监控的资源3
4性能测试的应用领域3
5实施阶段3
5.1分析影响性能因素的步骤3
5.2开发角度性能问题的原因3
6产品部署阶段3
7维护阶段3
8性能测试的策略3
9各阶段所要进行的性能测试3
9.1设计阶段的性能测试3
9.2实施阶段的性能测试3
9.3产品部署阶段的性能测试3
9.4维护阶段的性能测试3
10系统稳定性的度量3
11性能测试的基本概念3
12响应时间的分解3
13在性能测试中需要注意的问题3
13.1环境设计的问题3
13.2其他需要注意的地方3
14确定最小用户负载3
14.1确定最小用户负载的目的3
14.2确定最小用户负载的方法3
15性能测试的两个基本类别3
15.1预备测试3
15.2正式测试3
16性能测试生存周期3
17后台活动分析3
17.1分析Web应用程序的用户活动3
17.2分析Web应用程序的后台性能瓶颈3
18关键性能尺度标准3
19镜像生产环境3
20用户思考时间的问题3
21确定负载增加的标准3
22性能参数介绍3
22.1处理器性能参数3
22.2处理器瓶颈的解决办法3
22.3内存性能参数3
1编写目的
本文档从性能工程的角度提出开展性能测试工作的流程，和进行性能测试工作的策略，下面我们讨论性能工程的需求阶段、设计阶段、实施阶段、产品部署阶段、维护阶段所要开展的工作，和相应要采取的策略。
2需求阶段
性能测试需求的确立
性能测试需求的来源
性能测试需求的来源有三个方面：
1、需求文档
2、设计文档
3、客户备忘录
确定性能测试需求的解决方法
在没有需求文档和设计文档的情况下，我们需要对TSP系统上的客户业务使用情况进行分析，提出我们所关注的性能测试需求，并告知业务人员。
让业务人员来判断我们的性能需求是否能满足客户的真实要求。
在通过TSP系统分析业务使用状况时，我们可以从以下方面来关注：
1、确定当前系统的业务使用状况：
通过TSP的日志记录－客户端模块使用情况了解在某个时间段内，客户执行某个操作的具体情况。
2、了解不同视角的用户性能：
ⅰ）用户视角：
响应时间：
用户所能感受到的响应时间，也是用户最重视的性能体验。
确立响应时间的原则：
2/5/10原则
2：
2秒钟用户会觉得是一个很好的体验。
5：
5秒钟用户可能会觉得差了一点，还行，比较好。
10：
10秒钟是用户所能承受的最大极限。
鉴于不同地区的网络环境，将用户所能承受的响应时间极限定为12～15秒。
此部分需与业务人员讨论。
稳定性：
系统长时间运行不会出现错误的能力。
验证方法：
系统在满负载的运行8小时，系统是否会出现服务不可用，ConnectionRefused
HTTP404,500错误。
ⅱ）系统视角：
延迟，系统资源使用状况
延迟：
包括数据库延迟和网络延迟
此部分需与DBA及系统部人员讨论。
系统资源使用状况：
服务器的CPU使用率是否长期高于80％，达到90％，100％的程度，整个磁盘的I/O是否达到极限。
内存的使用数是否只剩下极少的几兆，几十兆。
ⅲ）开发者视角：
从代码实现和数据库实现来考虑性能。
看看这两方面得到实现是否足够好。
3、了解真正的性能测试需求
方法：
ⅰ）识别项目干系人：
指的是和项目相关的人，开发人员，设计人员，需求人员，业务人员，上层领导，了解他们对性能测试的考虑。
ⅱ）隐藏在“性能测试”之后的实际想法，比如：
是因为开发人员对所完成的代码没有信心，又不愿意做修改，要求我们对其所作的程序进行性能测试，还是设计人员使用了一项新技术，心里没低，所要求作的性能测试，等等。
确立性能测试目标
确立性能测试目标的原则
1、以“需求”为本
考虑系统需不需要作性能测试，性能测试的内容和范围。
2、测试目标确定的经济性考虑
ⅰ）投入到性能测试的人员是多少？
ⅱ）具备可以确定性能测试需求，制定性能测试方案的人员是多少？
可以执行性能测试的人员是多少？
ⅲ）这些人员需要投入多长时间？
ⅳ）所要开发系统的运行环境和设备，这些设备的配置对于性能测试的影响，比如说：
tomcat4.1的应用服务器，它的配置文件缺省的jvm的使用空间是64M，一个机器的内存为1G，我们将jvm的使用空间设置为512M对性能测试的影响。
ⅴ）内部的人员无法满足性能测试的要求，通过外聘，采用外聘的方式，公司所能承受的成本是多高。
3、基于风险的测试目标确定
ⅰ）系统如果不做性能测试，会有多大的风险，如果在性能指标上达不到用户的要求会有多大的风险。
需要进行评估。
ⅱ）如果做性能测试会有多大的风险，性能测试的投入会有多大，会有多大的风险需要进行评估。
确定性能测试目标的方法
我们要确定系统的吞吐量和并发用户数的设计目标可以采用以下三种方式：
●确定在某个特定时间端内，估计系统会有多少用户同时访问
●在某个特定的时间端内，正在访问系统的用户的典型操作是什么？
哪个页面的访问量最大？
●在某个特定的时间端内，系统需要处理多少种用户场景
这些数据可以在系统服务器的日志文件、TSP监视数据种找到，也可以通过监视数据库的活动情况来获得。
不同阶段的性能测试目标
设计阶段的性能测试目标
设计阶段的性能测试目标为考察系统是否满足预期的性能要求。
开发阶段的性能测试目标
ⅰ）将开发阶段的性能测试目标作为对系统进行调优的参考：
考虑在每个开发阶段，性能是否能够达到标准，考虑当前阶段的性能瓶颈，及其性能瓶颈出现的原因是在于数据库访问（SQL语句或者存储过程写的不够好）还是其他的原因。
ⅱ）用性能测试手段发现系统存在的问题：
通过模拟真实场景，发现在现场测试中可能存在的问题，比如说：
用户数的突然增加，导致的应用程序崩溃，服务器崩溃的问题。
产品部署阶段的性能测试目标
提供部署方案的参考，确定合适的硬件设备，虽然更高的设备可以获取商业上的利益，但应考虑客户的具体情况。
系统维护阶段的性能测试目标
考察系统的可扩展性：
从系统的视角考虑,在用户数扩大，在业务量增大的情况下，是一个怎样的表现。
3设计阶段
性能测试方案的确立
在确立性能测试方案之前，需要作的工作
1、确定测试目标和需求
这里的灵活性比较大，与性能测试成败有很大的关系。
2、了解现状
ⅰ）业务使用状况
通过日志记录，在某个时间段内，用户的操作。
ⅱ）了解环境：
包括网络条件，服务器条件，软硬件条件，应用服务器环境及各种配置信息。
3、确定需要监控的指标：
ⅰ）CPU使用率
ⅱ）内存使用情况
在此应优先监控应用服务器的性能指标。
对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。
对于数据库来说监控cache的命中率，索引的使用状况，数据库的连接数。
用例和场景设计
用例和场景设计的步骤：
1、对业务的分析和分解
2、根据业务确定用例
3、不同用例按照不同的发生比例组成场景
4、了解每个场景的实际意义（对场景执行测试，收集结果）
了解业务的分布情况，根据业务确定用例，在设计用例的时候，根据前期收集的数据，设计不同的场景来组成用例，并了解每个场景的实际意义，执行场景，收集结果数据。
场景设计的例子（主要是根据业务的使用状况）：
●场景1：
10％登录，10％入库，30％订单，20％出库，30％查询（1000用户）——日常
●场景2：
10％登录，90％查询（400用户）——周末盘点
设定需要监控的资源
设定需要监控的资源主要有一下几个方面：
1、CPU利用率
2、内存使用情况
3、数据库监控
4、JVM使用状况监控
应优先监控应用服务器的性能指标。
对于Tomcat或者Weblogic来说，监控他的JVM使用状况，连接池的连接数量，内存使用状况等信息。
对于数据库来说，cache的命中率，索引的使用状况，数据库的连接数，具体的监控指标请性能测试工程师，根据性能需求确定。
4性能测试的应用领域
4．0系统性能测试的主要应用领域是验证能力、性能调优。
1、验证能力包括
ⅰ）验证新的系统，新的架构能否满足用户的需求。
ⅱ）向用户提供性能测试报告，说明系统的性能达到了预期设计的标准。
ⅲ）确定新平台的产品架构，假设以前用ASP，现在用.net，或者换到j2ee平台上，验证新系统架构是否满足性能要求，这个要求不是用户提出来的，也不是直接用户体验的，而是在架构设计过程中要确定的指标。
2、性能调优
在系统开发过程中，通过性能测试，了解当前系统瓶颈（比如说在于数据库访问，SQL语句或者存储过程写的不够好，或者说数据库设计的问题，索引做的不够好），所选择的应用服务器有问题，或者说代码这一层，业务逻辑实现的不够好，导致它性能的缺陷。
以确定问题出现在应用层，数据库层，代码层。
5实施阶段
分析影响性能因素的步骤
将影响性能的因素按照以下顺序进行判断：
1、网络状况
2、硬件设备
3、系统/应用服务器/数据库配置
4、数据库设计和数据库访问实现（SQL和SP）
5、业务的程序实现
但是在开发阶段做性能调优时关注的顺序：
请更多的关注SQL一级和代码一级。
若是对于一个实际在线上运行的系统，请直接按照以上5点的顺序。
注：
很多的性能问题，是由于应用服务器的配置完全不合理，比如：
tomcat4.1的应用服务器，没有修改它的配置文件中缺省的jvm的使用空间。
开发角度性能问题的原因
1、对所使用的技术不熟悉
这是影响最大的因素。
对于.net平台，j2ee平台的架构不熟悉，开发人员对于有哪些架构和哪些模式对于性能会有影响不了解，建议开发部门做一下调研。
对于性能测试工程师来说，应多了解一些平台的知识，平台的性能。
J2ee的平台和它的性能问题是怎么产生的，如何来调整它的性能。
2、系统架构设计的不合理
3、程序员的实现错误
6产品部署阶段
产品部署阶段的性能测试主要用来确立客户需要什么样的硬件配置。
7维护阶段
维护阶段的性能测试主要在于考察系统的可扩展性：
从系统的视角考虑,在用户数扩大，在业务量增大的情况下，系统是一个怎样的表现。
8性能测试的策略
鉴于我们当前的性能测试工作开展情况，先对3.0系统进行一个容量测试，确定现有系统所能承受的最大用户数及最大业务处理能力。
并将这个结果告知用户，让用户了解当前系统条件下的运行水平，系统所能支撑的最大用户数，每个用户的响应时间是多长。
并将结果作为以后进行4.0系统制定性能测试目标的一个参照标准。
9各阶段所要进行的性能测试
除了需求阶段都需要进行性能测试。
其他阶段的性能测试需要依据你的性能测试目标：
设计阶段的性能测试
在设计阶段的性能测试主要的目的是验证你的架构。
验证的方式有两种：
1、在对于系统架构有一个预期的性能目标的情况下，去验证当前架构能否满足预期的性能目标。
2、系统架构是基于以前的架构修改过来的，对于两者进行一个对比测试，了解两种架构各有什么优势。
实施阶段的性能测试
在实施阶段进行性能测试的目的是为了阶段性的验证系统性能，进行性能调优，并通过系统调优发现系统缺陷。
产品部署阶段的性能测试
在产品部署阶段，将性能测试作为验收测试的一部分。
维护阶段的性能测试
在维护阶段——考察系统的可扩充性/定位系统缺陷，考察系统的可扩充性用来定位系统的缺陷。
10系统稳定性的度量
为了验证系统的稳定性，我们需要对系统进行一个可靠性度量，在目前没有一个行业或者国际标准进行可靠性度量的前提下，我们又无法获得确切的用户需求（用户提不出系统稳定性的量化标准），我们可以采用如下方式来验证系统的稳定性。
通过在做性能测试的过程中得到系统稳定性数据的方式来验证系统的稳定性
手段：
对一个系统进行一个长时间的运行，观察它的可用内存，cpu使用率有无显著的变化，如果在长时间使用的情况下，cpu，内存无显著变化，则可以认为系统具有稳定性。
11性能测试的基本概念
1、响应时间：
客户端从发送请求的那一刻起到收到应用程序响应的最后一个字节时止而不
得不等待的时间长度。
2、点击数：
对每一个对象的请求，比如说：
一个页面有五个部分组成，一个框架，四张图片，这样算做5个点击数。
3、页面请求：
请求了一个页面，不管这个页面包括了多少对象。
4、吞吐量：
i）按照流量来计算的吞吐量，用来衡量网络状况或者应用服务器的处理能力，在指定的时间内，每秒钟字节的出入.
ii）用点击数来衡量吞吐量，每个固定的时间段内有多少点击数，用于银行系统。
5、并发用户：
从业务上的并发：
200人同时在线。
从服务器上的并发：
200人同时向服务器发出请求。
200人同时做一个提交的操作，服务器接受到多少请求。
6、资源利用率：
cpu利用率，内存利用率，磁盘I/O状况等
12响应时间的分解
响应时间＝网络响应时间＋应用程序响应时间
＝网络延迟N1（数据在网络上传输的时间）＋web服务器请求被处理的时间A1
＋web服务器到database服务器的传输时间N2（如果两台服务器在同一台机器上传输时间就会很短）＋数据库服务器处理数据库请求所耗的时间A2＋database服务器返回请求到web服务器的传输时间N3＋web服务器请求被处理的时间A3＋网络延迟N4
因此，性能的相关性大概为三个部分：
网络的延迟、应用服务器处理的延迟、数据库处理的延迟。
所以，在开发阶段做性能调优的时候，针对这三个方面进行。
响应时间的获得：
用lr可以获得一个完整的响应时间，有两种办法可以获得各部分的数据，
i）自己做一些日志，应用服务器可以接受到的，应用服务器可以接受到的，打开这个日志可以看到他什么时候接受到请求的，来判断网络的延迟是多少，数据库的延迟也可以用同样的方法来做。
这种方法的资源消耗比较大，只用于验证已确定的系统中的问题在哪里。
ii）通过各种工具慢慢来做：
比如：
做某个业务的时候响应速度很慢，可以用排除法来做：
第一，猜测是网络的问题，在两个网络之间使用网络测试工具sniffer测试网络延迟，或者用windows操作系统，在windows2000，advancedserver也有相应的工具测点对点的延迟。
数据库的延迟可以采用将影响性能的SQL语句摘出来，直接在环境下实际运行一下，看实际的处理时间是多少，对于应用服务器的延迟，通过应用服务器本身的日志，或者在应用实现的代码里加一些日志输出来实现。
13在性能测试中需要注意的问题
环境设计的问题
1、网络环境
2、软硬件环境
3、环境的维护方案
4、时间同步问题
5、“镜像”环境
时间同步问题：
各种服务器部署在不同的机器上，在进行性能测试分析响应时间的时候就需要进行时间同步，通过日志来对比时间，但日志上记录的是本地时间，让日志记录的时间有可比性，需要做时间同步。
同步的方法：
在UNIX操作系统上用NTP协议可以做时间同步，在windows系统上可以通过加入域来时间同步，
“镜像”环境的问题：
做能力验证的测试的时候，一般要求在现场做，因为这种测试结果和应用服务器网络环境本身会有很大的关系，如果不能做现场测试，
采用的两个解决办法：
i）尽可能的模拟出用户环境：
包括网络状况，服务器状况，
ii）和用户去协商：
去做现场测试。
其他需要注意的地方
1、应用服务器的Warmup问题
J2ee应用或者.net应用现在都会涉及本地编译的过程，在第一次做运行的时候，在第一次访问的时候速度会很慢，第二次访问才会快起来，因为从本地Cache中读取信息，所以在应用服务器重启了以后，都必须多测几次，等服务器Warmup后再测试，否则的话，前面的结果没有有效性。
整个的结果还会有误差。
2、应用服务器的Cache
在多次测试的过程中，把Cache功能给去掉，或者把cache给清空。
3、浏览器或客户端应用的Cache
客户端和浏览器的cache在录制脚本的时候都应该去掉。
14确定最小用户负载
确定最小用户负载的目的
为了全面掌握应用程序的性能――不仅是重压条件下，而且是在更为理想的条件下。
这是很重要的，因为应用程序通常将大部分的时间花费在这些低负载条件下。
峰值操作通常很少发生。
确定最小用户负载的方法
从需求上解决，了解业务分布情况，将业务分布情况划分成不同的场景，确定一个负载使用状况最小的场景。
执行此场景，观察系统在此场景下的运行状况。
15性能测试的两个基本类别
预备测试
预备测试：
最初的试探性测试，让我们能够感受一下应用程序的性能并优化测试环境。
正式测试
有四个正式的性能测度，我们的分析就建立在这些测度上。
可以将这些正式测试按照类型分成如下几个子类：
单实例压力测试、持久测试、体系结构测试一旦按照初步测试结果设置好了环境和测试参数（测试脚本、思考时间、采样方法等等），这些因素就必须对任何特定的性能测试都保持不变。
如果在某个特定的性能测试中修改任何参数，那么我们就破坏了结果的可比较性，将不得不重新执行测试。
16性能测试生存周期
●规划性能分析
●创建有效的压力脚本
●执行压力测试
●分析性能测试数据来确定和解决性能瓶颈
规划性能分析阶段的工作包括收集重要的原始数据，然后根据这些信息制订测试方案。
规划阶段收集到的信息至少应该描述两个方面的内容：
●用来复制一个接近生产环境的测试环境的细节。
●对该应用程序的使用方式的理解，以及临界性能表现的迹象等。
这些信息可以来源于市场预测报告、站点的IIS日志、站点的性能日志和站点功能说明等。
创建高效的压力测试脚本在收集了所需信息并搭建了测试环境后，下一步就是创建测试脚本，它应该能够准确地模拟站点期望地流量。
最有效地方式是根据实况网站中的历史数据结合市场调查或商业分析而得到这些期望数据。
执行压力测试创建可以模拟最大用户负载的压力测试脚本。
分析性能测试结果
（i）确定性能瓶颈
影响终端用户响应时间的瓶颈包括应用程序和服务器的吞吐量、终端到终端的Internet连接速度以及网络涌塞等。
（ii）检验性能优化结果
分析结果了解系统的性能状况并能够对性能进行提高。
17后台活动分析
后台活动分析可以用来分析再Web应用程序数据库层上的用户活动情况和性能瓶颈。
使用这些信息有助于获得精确的性能测试结果。
分析Web应用程序的用户活动
用户在Web应用程序中的详细活动信息是记录在数据库中的。
我们可以根据自己的业务需求到数据库中去查询用户活动的处理情况。
比如：
有多少订单被处理、有多少登陆行为发生，以及用户进行了多少次搜索。
通过这些简单的查询就可以将这些信息从数据库里提取出来，这些信息将用来帮助制定用户场景（userscenarios）、用户场景比率或其他营销方面的情报。
分析Web应用程序的后台性能瓶颈
对于现有系统的Web应用程序进行性能测试，可以检查数据库服务器，找出那些花费长时间运行、引起死锁或占用了大量系统资源的SQL语句，从而判断出当前性能的瓶颈在哪里。
方法为使用包括SQL分析器工具跟踪SQL语句的执行情况以及对Web应用程序中的Windows和SQLServer等对象进行监视产生性能监视日志。
由SQL语句造成对性能的影响，主要的原因包括：
阻塞、索、死锁、有问题的查询以及需要花费大量时间执行的存储过程等。
18关键性能尺度标准
性能测试的关键尺度包括以下几点：
●服务器错误的可接受性压力测试过程中经常会发生服务器错误，在压力测试刚刚开始或正在结束时，错误往往会产生，这是因为发生了大量的突发负荷和未完成的页面请求。
这些错误时由于压力测试而造成的，不大可能在生产环境中发生，因此可以忽略这些错误。
●服务器利用的可接受性确定服务器所能承受的最大负荷程度。
制定出度量标准，并将这些度量标准形成文档，发布给开发组，支持组，管理组的人员，以后可以根据这个度量标准监视生产环境中的Web服务器，看哪些需求超过了Web服务器的性能要求，然后就可以想办法提高Web应用程序的性能来处理更高的流量。
●内存泄漏和其他稳定性问
升级会员 