目录
《性能测试培训》2012-8-25 .......................................................................................................... 2
一、 性能测试活动开展 ................................................................................................... 2
1．性能测试概念阶段 ..................................................................................................... 2 2．性能测试方案阶段 ..................................................................................................... 3 3．性能测试实施阶段 ..................................................................................................... 4 4．性能测试验证阶段 ..................................................................................................... 4 5．性能测试试运行阶段 ................................................................................................. 5 6．项目关闭阶段 ............................................................................................................. 5 二、 性能知识普及 ........................................................................................................... 5
业务性能指标 ................................................................................................................... 6 资源状态指标 ................................................................................................................... 6 应用稳定运行指标 ........................................................................................................... 6 业务模型 ........................................................................................................................... 6 测试模型 ........................................................................................................................... 7 数据模型 ........................................................................................................................... 7 测试环境 ........................................................................................................................... 7 性能测试分析 ................................................................................................................... 8 三、 工具LR使用 ............................................................................................................. 8
脚本录制： ....................................................................................................................... 9 脚本增强： ....................................................................................................................... 9 场景设置及运行： ........................................................................................................... 9 四、 其他注意事项 ........................................................................................................... 9 【性能测试基础学习】 ................................................................................................................... 9 【性能测试过程模型PTGM】 ...................................................................................................... 10 【性能测试过程】 ......................................................................................................................... 11
一．性能测试计划和策略 ..................................................................................................... 11
1.性能测试计划的制定 .................................................................................................. 11 2.性能测试计划模版要点 .............................................................................................. 12 3.性能测试策略对比 ...................................................................................................... 15 二．性能测试场景用例分析 ................................................................................................. 19
1.性能测试业务场景及并发用户数分析 ...................................................................... 19 2.性能测试—并发用户数的估算 .................................................................................. 19 3.根据性能需求设计性能测试用例 .............................................................................. 20 4.微软提供的性能测试用例模版 .................................................................................. 22 5.WEB性能测试用例设计 ............................................................................................. 24 三．性能测试场景监控分析 ................................................................................................. 27
1.性能计数器及性能分析方法 ...................................................................................... 27 2.LR性能监控指标 ......................................................................................................... 35 3.LR的Apache的监控配置 ........................................................................................... 35 4.性能测试服务器分析指标 .......................................................................................... 36 5.如何手动重新生成性能计数器库值 .......................................................................... 38
四．性能测试结果分析 ......................................................................................................... 39
性能瓶颈分析方法 ......................................................................................................... 39 分析原则： ..................................................................................................................... 40 分析的信息来源： ......................................................................................................... 40 五．【性能测试的具体案例分析】 ....................................................................................... 43
1．确定明确的测试目标 ............................................................................................... 43 2．测试需求分析 ........................................................................................................... 43 3．测试用例设计 ........................................................................................................... 44 4．脚本开发数据的准备以及测试执行与监控 ........................................................... 44 5．测试分析 ................................................................................................................... 45 6．系统调优与验证 ....................................................................................................... 46
【一个性能测试实例】B/S体系结构 .......................................................................................... 46 【理发店模型】 ............................................................................................................................. 52
《性能测试培训》2012-8-25
背景：
1.性能投诉问题增多。 2.客户关注。
3.性能问题影响大过功能测试。
性能问题：系统稳定性差，响应速度慢。
培训内容：
1. 性能测试活动开展
2. 性能测试知识普及：业务指标，资源监控指标，业务模型，测试模型，数据模型，测试
环境，性能分析。
3. 工具LR使用：脚本录制，增强脚本，场景设计，结果分析。 PerformanceCenter：
一、 性能测试活动开展 1．性能测试概念阶段
性能活动： （1）概要计划
（2）需求分析：1、需求调研2、可行性分析
需求分析是将来源于用户的原始需求转换为项目的量化需求。 量化需求：
A. 并发用户要求
B. 每秒通过事务数TPS要求
C. 系统稳定性：持续响应要求
D. 响应时间要求：B/S架构：3s好/5s正常/8s慢/20s非常慢
TPS估算：二八原则（80%业务量/20%用户运行时间） 并发用户计算：
正常并发用户：用户数*在线时间/上班时间
最大并发用户：正常并发用户+3*（√根号）正常并发用户
需求调研关注点： 性能指标
系统架构，环境，配置 系统用户特征
需求调研目标：
1.系统目标。了解被测对象：被测系统的基本框架，功能，通信协议，拓扑，部署配置等。
2.基本性能要求。被测系统的性能指标。
3.使用对象：系统用户。规模，分布，使用习惯，性能的直观要求。
需求调研手段：测试工具适用性（是否支持）；开发难度。 需求调研资源：环境；软件；人员。
环境包括：测试环境；测试开发环境；压力环境。 需求调研模版：
可行性分析关注：工具支持，资源时间投入评估（目标、代价）。 可行性分析：考虑并发场景可行性。
客户关注的性能点---->关心程度高低--->优先级 技术验证：开发框架，原型系统，同类系统。
关注：脚本录制、回放、测试、开发。可使用脚本试开发。 资源及时间评估：
（3）签署需求分析报告
2．性能测试方案阶段
基于统计数据分析---->建立业务模型---->生成测试模型
编写测试计划： 建立业务模型；
目的：了解用户使用系统的业务行为习惯。
80%的用户使用系统20%的功能模块；
20%的功能模块占用了系统80%的业务场景。 方法：
1. 用户行为调查
2. 统计数据分析：历史数据、调查数据
3. 同类系统调研 4. 业务需求分析
建立测试模型； 方法：
1. 正向计算法
脚本运算能力-------->预计目标值 2. 发射控制法
设计测试方案；
内容：测试策略、数据需求（基础数据、使用数据）、时间计划安排。
3．性能测试实施阶段
工作内容： 测试用例 数据准备 工具准备 环境准备 脚本增强 外联系统准备
测试用例：反映业务操作步骤。 设计实现：
1) 外联系统准备：接口确认可用。可单独开发模拟器。 2) 工具准备：测试工具、监控工具。 3) 脚本开发，增强： 4) 环境准备：
脚本分类： 录制脚本：
可回放脚本：验证之后才成为可运行脚本(程序运行成功；业务调用成功)。 已增强脚本：6件事。
4．性能测试验证阶段
又称用户验收测试。 步骤：
1、 基准测试：单用户性能---标尺
2、 单交易负载测试：交易并发处理正确 3、 组合场景测试：模拟真实场景
4、 其他测试：稳定性测试、扩展性测试
5、 监控：
业务性能监控； 服务器性能监控； 数据库，中间件，
网络监控；应用系统监控，应用日志监控。 6、 支持：开发人员、运维人员、BA等 支持问题：
脚本异常中断；
应用大量报错或出现非预期错误。 网络服务器出错。
服务器资源急剧上升或应用性能急剧下降。 测试数据不可用。
7、 分析报告：性能瓶颈分析：现场决策分析和事后分析。 事后分析总结：
1. 关联曲线进行拐点分析 2. 对响应时间进行分段分析 3. 结合系统日志进行分析
4. 结合应用，数据库，网络，中间件等监控数据分析。
5．性能测试试运行阶段
试运行报告。
6．项目关闭阶段
项目总结报告。
二、 性能知识普及
性能：物质的功用，特性。
影响软件（并发类软件系统）服务性能的要素：内在属性、使用方、动态配置、环境。
软件系统服务性能=（固有性能）
基础软件环境*硬件环境*使用模式*动态参数配置
人为可控：基础软件环境；硬件环境。 人为不可控：使用模式；动态参数配置。
如何评价软件系统服务性能？
主观维度：可用性、成本、可靠性。
客观维度：业务性能指标；资源状态指标；应用稳定性指标。
业务性能指标
1、 系统处理能力----TPS：多个因素决定。
2、 交易响应时间---不包含本地客户端处理时间。 3、 并发用户数量
4、 交易成功率----系统稳定性反映。
LR偏重于网络通信，服务器响应时间。 QTP偏重于本地操作响应时间。
交易响应时间指标： 平均响应时间 90%平均响应时间 最大响应时间 最小响应时间
并发用户：
并发在线用户 并发交易用户 绝对并发交易用户
用户模式：注册、在线、交易、登录、退出。 并发用户模式：长连接、短连接、无连接。
异常业务逻辑：考虑方向。例如：异常日志。
资源状态指标
系统资源 网络
中间件：瓶颈问题少，配置问题多
数据库：40%瓶颈问题：SQL性能差（全表查询）、锁表过频繁、I/O性能。
应用稳定运行指标
系统资源使用稳定性 临界时间波动 业务指标稳定性
业务模型
业务模型：基于测试成本和资源，选取重要的、访问量较大的交易来产生系统压力，获得系统的性能指标，并用这个指标来近似地描述真实系统被访问的性能表现。
特点：
1. 通过业务模型产生的压力应与真实系统真实访问的压力规模相当。 2. 业务模型中应包含了系统中最常用，最重要的任务。 3. 业务模型可以根据测试成本和时间大小而细化和精简。
统计数据分析：典型交易、典型场景。
正常业务场景---抽出典型交易---高峰日交易量分布---抽出---交易量排行–-生成---完整业务模型
完整业务模型业务特点： 交易量大
重要、关键交易 覆盖度原则 怀疑原则
测试模型
测试模型是一种实现模型，它是根据业务模型映射到性能测试方案和工具的结果。
数据模型
关注：数据规模、分布规律。 1. 基础数据：
数据一致性：等量、同规模原则：生产环境、测试环境一致性。 时间原则：软件生命周期至少20%。例如10年取2年。 量级原则：软件生命周期顶点预计数据规模的至少10% 数据有效性：真实存量数据，屏蔽数据
2. 使用数据：
特点：1、充分性（正常使用量3-5倍准备）；2、有效性；时效性。
测试环境
1. 有效性
与生产环境一致：1、模拟环境。2、开天窗：特殊账号。3、扩展性测试。 被测试环境。
测试环境：压力发起环境。 外联系统薄弱
传输路径无障碍：内网、不同。 2. 性：单独使用测试周期
3. 稳定性：测试周期内配置：软件、硬件等。
性能测试分析
1. 曲线分析
TPS：TransactionPerSecond每秒通过事务数
响应时间
资源利用率
拐点处是可以处理事务的最大值。 分析：
资源（CPU、内存、I/O）出现瓶颈。 代码并发处理问题
服务器监控资源要考虑服务器本身性能影响，不能因为不合适的监控影响服务器本身性能。
2. 路径分析：分段测试：终端<---->服务器 3. 日志分析：
三、 工具LR使用
脚本录制：
Generator---控制台
协议分析：应用层协议-----探测器应用 录制选项：Record----HTML（优先）/URL
脚本增强：
1、 参数化：去哪取；怎么取；何时取； 2、 关联：动态数据匹配：服务器返回包 3、 检查点：文本、图片 4、 定义事务：
5、 思考时间：减小时间，会提高交易频率，减小虚拟用户数。 6、 集合点：正常情况下不需要使用此项。
场景设置及运行：
设置方式：手工模式（首选）、目标引导模式。
场景设置：
加压方式：不大于1小时；不小于5-10分钟； 减压方式：不少于5-10分钟
四、 其他注意事项
事务失败率可接受范围取决于对应业务的重要程度。一般失败率不超过0.5%。 CPU、内存使用率低于60%：可接受。 集群测试：负载均衡是否有效。
缓存命中：
1、服务器缓存：处理很麻烦。
2、 客户端：LR工具可以设置清除。
【性能测试基础学习】
好的性能需求： （1）、需求性：量化 （2）、代表性：性能指标能够衡量系统真实性能。 （3）、可用性：
性能测试关注内容：
（1） 是否满足用户需求：并发用户数、吞吐量、TPS、平均响应时间、服务器资源占用情
况
（2） 故障定位、潜在瓶颈、调优建议。
性能测试所需技术：
测试技术、编程技术、操作系统、网络技术、数据库、各种应用中间件、硬件。
【性能测试类型及关注问题类型】 并发测试：死锁、资源竞争。
负载测试：稳定性、服务器处理效率。 压力测试：最大服务级别。 大数据量测试：强度测试。
疲劳测试：最大工作量下稳定运行能力。 可靠性测试：功能，疲劳，容灾。 基准测试：资源分配，调优。
配置测试：性能优化，环境规划，软硬件，网络。 失效测试：负载均衡，局部故障运行。
性能测试关注功能点：查询；保存；统计；刷新；显示；传输；响应；下载。 并发测试关注功能点：登录；提交保存；对数据处理。
容错测试关注：断网；断电；死机；服务器Down，客户端处理。
极限压力测试场景：
1. 接受大数据量的数据文件时间 2. 大数据量恢复时间 3. 大数据量导入导出时间 4. 大批量录入数据时间 5. 大数据量的计算时间 6. 大数据量的查询统计时间
7. 多客户机同时进行某一提交动作 8. 采用测试工具软件 9. 编写测试脚本程序
【性能测试过程模型PTGM】
1. 测试前期准备：系统功能稳定，测试团队组建 2. 测试工具引入：工具选择，工具应用技能 3. 测试计划：目标，内容，时间计划 4. 测试设计与开发：环境，场景，用例 5. 测试执行与管理 6. 测试分析
（1） 测试准备：环境/工具/数据/人员、组织。
（2） （3） （4） （5） （6） （7） （8）
需求分析：测试强度/业务分布/混合业务/用户分析/未来发展/系统网络容量规划。 方案制定：策略/案例/周期/人员/环境。 脚本开发：录制，编写，调试。 测试过程：场景制定
测试执行：运行/Vuser执行监控/场景监视。 结果分析： 报告：
性能测试计划体现：5W1H Why：目的，目标
When：时间，进度安排
Who：人，角色，组织（PM项目经理、性能测试需求分析工程师、架构设计师、开发
工程师、测试经理、高级性能测试工程师、性能测试工程师） Where：环境 What：场景
How：流程，过程，方法，工具环境。
【性能测试过程】 一．性能测试计划和策略 1.性能测试计划的制定
压力/负载测试计划是成功进行性能测试的关键。 一：分析应用程序 二：制定测试目标 三：设计执行过程
一：分析应用程序
（1）捕捉系统配置 1，连接到系统的用户数 2，客户机的配置情况
3，服务器数据库类型及配置
4，通讯装置的吞吐量和处理的并发用户 5，分析其他影响性能组件 （2）描述系统功能 1，划分系统功能模块 2，分析系统的用户角色 3，确定模块测试的优先级 4，预测负载高峰
二：制定测试目标
（1）确定测试目标 1，获得操作响应时间 2，确定系统最优配置 3，检查系统可靠性
4，检查软硬件更新对系统的影响 5，确定系统容量 6，确定系统性能瓶颈 （2）确定测试环境 1，测试环境
2，被测试环境：硬件配置，软件配置
三：设计执行过程
1，软件安装与配置 2，定义关键流程和事务 3，定义任务配置 4，测试数据的准备
5，测试功能配置：IPSpoofer;安装LoadGenerator调用 6，脚本录制和调试
7，场景方案的设定和调试 8，测试执行
9，测试结果的收集和分析：测试人员，开发人员共同参与 10，给出测试结论：分析测试结果，制定结论，提交报告
2.性能测试计划模版要点
本文是列举一个在软件系统测试阶段进行的压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统（客户端/应用服务器/数据库管），中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB（对象请求代理）软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。
--------------------------------------------------------------------------------- 压力测试的详细计划如下：
---------------------------------------------------------------------------------
《压力测试计划》 1、测试计划名称
XXX系统压力测试计划。 2、测试内容 2.1背景
本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间运行测试软件来测试被测系统的可靠性，同时还要测试被测系统的响应时间。
用户的实际使用环境：
◇由两台IBMXSeries250PCServer组成的MicrosoftCluster； ◇数据库管理系统采用Oracle8.1.6；
◇应用服务器程序和数据库管理系统同时运行在MicrosoftCluster上。
◇有200个用户使用客户端软件进行业务处理，每年通过软件进行处理的总业务量为：150万笔业务/年。 2.2测试项
应用服务器的压力测试； 2.3不被测试的特性
◇系统的客户端应用程序的内部功能； ◇数据库中的数据量对程序性能的影响。
3、测试计划
3.1测试强度估算
测试压力估算时采用如下原则：
◇全年的业务量集中在8个月完成，每个月20个工作日，每个工作日8个小时；
◇采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；
测试压力的估算结果：
去年全年处理业务约100万笔，其中15%的业务处理每笔业务需对应用服务器提交7次请求； 70%的业务处理每笔业务需对应用服务器提交5次请求；其余15%的业务每笔业务向应用服务器提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需要，测试需按现有业务量的2倍进行。 每年总的请求数量为：（100*15%*7+100*70%*5+100*15%*3）*2=300万次/年。 每天的请求数量为：300/160=1.875万次/天。 每秒的请求数量为：（18750*80%）/（8*20%*3600）=2.60次/秒。 正常情况下，应用服务器处理请求的能力应达到：3次/秒。
3.2测试环境准备
3.2.1基本硬件及软件环境的准备
1)网络环境：公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。
2)使用两台IBMXSeries250（1G内存）PCServer作MicrosoftCluster，安装系统软件Windows2000AdvanceServer及MicrosoftClusterServer（MSCS）。
3)数据库管理系统的安装及配置：在测试用的IBMXSeries服务器上安装Oracle8.1.6，数据库采用OracleFailSafe（ofs）的Active/Passive配置。安装数据库管理系统及支撑软件（包括VisiBroker和BDEAdministrator）。 4)安装被测的应用服务器程序。
5)客户端的PC机：10台（PⅢ600/128MRAM）。
3.2.2系统客户端测试程序的编写系统客户端测试程序使用Delphi编写，要求测试程序实现如下功能：
1)模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况：第一种，发送的请求至少包括10个参数，参数类型涵盖字符、日期、数字种类型；接收的响应信息不少于1个参数；第二种，发送的请求不少于1个参数；接收的响应信息至少包括
10个参数，参数类型涵盖字符、日期、数字种类型。
2)必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔（单位：毫秒）、运行时间（单位：小时）。
3)在数据库中建立测试记录表，生成测试记录，向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括：发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名：TEST_LOG，字段名：MACHINE、ID、START_TIME、END_TIME、FLAG。
3.2.3系统本底数据的准备
为考察系统运行一段时间后系统的响应性能，参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求，数据有效性的具体要求参见数据库设计及系统设计文档。
3.3破坏性测试
按照设计连接的客户端连接数量进行测试，把应用服务器处理请求的设计频度增加1－10倍，分别测试出现错误的状态和和出现错误的比率，考察是否出现不可恢复错误，系统设计要考虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。
计划时间：2天；这个时间包括破坏性的修复和自动恢复的实现需要的时间。
在测试过程中每10分钟记录一次IBMXseriesPCServer的内存及CPU使用情况，包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。
3.4强度稳定性测试
选择一种负荷比设计负荷重的情况（应用服务器处理请求的频度为应用服务器处理请求的设计频度的1.5倍），进行24小时稳定性测试。
3.5测试方法和工具 黑盒测试
测试工具：无外购的测试工具，自己编制的测试工具。
3.6测试时间计划
3.6.1环境准备：2天。
其中：基本硬件、软件环境及系统本底数据的准备：1天， 系统客户端测试程序的编写及测试：1天。 3.6.2破环性测试：2天。 3.6.3强度稳定性测试：1天。 3.7测试中的问题及处理 3.7.1暂停标准和再启动要求
暂停标准：被测试软件在强度稳定性测试中频繁出现异常（每小时出现1次以上）时。用户或公司要求暂停测试时。
再启动要求：通过调试后，预计被测试软件的可靠性有所提高时，可再次启动测试。 3.7.2不可预见问题 不可预见问题包括：
◇测试环境被破坏而导致测试无法进行；
◇当出现上述不可预见问题时，测试终止，就已完成的测试内容编制测试总结报告，并在报告中说明测试终止的原因。
3.8测试报告2002.06.21
测试总结报告提交日期：2002.06.21。 3.8.1应生成的测试文件
测试记录（测试负责人和参与测试的人员签字）； 测试总结报告。
3.8.2测试总结报告中必须包含的内容 被测试软件名称、测试项、测试环境；
被测试软件的压力测试结论：响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系。
4、人员和职责 4.1职责
测试工程师：负责编写测试计划，组织测试，对测试过程进行记录，收集、整理测试记录数据，对测试结果进行分析，编写测试总结报告。
软件工程师：负责编写、调试客户端测试软件；数据库管理系统的安装、ofs配置及系统的本底数据准备。
系统工程师：负责测试用的硬件维护及操作系统安装、MSCS配置。 总工程师：负责对测试计划及测试总结报告进行批准。
用户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试。 4.2人员和训练要求
本次测试无特别的人员及培训要求。 5、批准
本测试计划必须经过总工程师批准后才能开始实施。
3.性能测试策略对比
性能测试（或称多用户并发性能测试）、压力测试、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。下面将几个概念进行介绍。
【性能测试】（PerformanceTest）：
通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。 关注点：howmuch和howfast
【压力测试】:
在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。【在性能可以接受的前提下，测试系统可以支持的最大负载。】
【负载测试】（LoadTest）：
负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。【目标是在不
同的负载下的系统处理能力。】 关注点：howmuch
【强度测试】（StressTest）：
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。【核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。】包括 Spiketesting：短时间的极端负载测试
Extremetesting：在过量用户下的负载测试 Hammertesting：连续执行所有能做的操作
【容量测试】(VolumeTest)：
通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定的程度上，就完成了负载测试和容量测试。容量还可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。【确定系统可处理同时在线的最大用户数】 关注点：howmuch（而不是howfast）
【容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。】
【容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。】
容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。
软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。
其中，容量测试、负载测试、强度测试的英文解释为： VolumeTesting=Largeamountsofdata LoadTesting=Largeamountofusers
StressTesting=Toomanyusers,toomuchdata,toolittletimeandtoolittleroom
负载测试和强度测试，都属于性能测试的子集。
下面举个跑步的例子进行解释。
性能测试，表示在一个给定的基准下，能执行的最好情况。例如，在没有负重的情况下，你跑100米需要花多少时间（这边，没有负重是基准）？
负载测试，也是性能测试，但是他是在不同的负载下的。对于刚才那个例子，如果扩展为：在50公斤、100公斤„„等情况下，你跑100米需要花多少时间？
强度测试，是在强度情况下的性能测试。对于刚才那个例子，如果改为：在一阵强风的情况下，你在负重或没有负重的情况下，跑100米需要花多少时间？
【压力测试和性能测试的区别】
性能测试就是用来测试软件在系统中的运行性能的。性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。
性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。外部的测试设备可以监测测试执行，当出现情况（如中断）时记录下来。通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。 压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。
性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该于性能测试一同进行。
举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。
性能测试(Performance)正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了.如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题
压力测试(Stress)多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).
【压力测试和性能的测试的区别是在于他们不同的测试目的】 压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应；所以一句话概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。
性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。
概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；比如我们说某个网站的性能差，严格上应该说‘在N人同时在线情况下，这个站点性能很差）
总之，就像一个方程式：综合性能=压力数*性能指数， 综合性能是固定的：
压力测试是为了得到性能指数最小时候（可以接受的最小指数）最大的压力数。 性能测试是为了得到压力数确定下的性能指数。
【关于性能测试模型的探讨】
随着单位时间流量的不断增长，被测系统的压力不断增大，服务器资源会不断被消耗，TPS值会因为这些因素而发生变化，而且符合通常情况下的规律。以下是一个性能测试压力变化模型图：
说明：
a点：性能期望值
b点：高于期望，系统资源处于临界点 c点：高于期望，性能处于拐点
d点：超过负载，资源不够用，系统处于崩溃
通过如上模型图中的情况，我们大致可以将当前性能测试分成如下4类： 1、性能测试 2、负载测试 3、压力测试 4、稳定性测试 》性能测试
以上模型图为准则，在a点与b点之间的系统性能，表示以性能目标预期为前提，对系统进行施压，验证系统在资源可用范围内，是否能达到性能预期的目标。 》负载测试
b点的系统性能，表示在系统在一定的压力下持续一段时间，直到系统的某项或多项指标达到极限，比如系统资源CPU、Memory或者IO等达到饱和状态。 》压力测试
b点到d点的系统性能，表示在超过安全负载的条件下，不断对系统进行加压，直到系统不能再接受请求，并可以确定一个系统瓶颈的情况下，目的是为了找出系统的瓶颈，需要对系统进行调优。 》稳定性测试
a点到b点的系统性能，表示被测试系统在特定硬件、软件、网络环境条件下，给系统加载一定业务压力，使系统运行一段较长时间，以此检测系统是否稳定，一般稳定性测试时间为n*12小时。
二．性能测试场景用例分析
1.性能测试业务场景及并发用户数分析
一、确定核心模块：使用频繁的模块（针对用户而言）、业务比较复杂的模块（针对开发而言）
二、确定模块间的集成关系：模拟真实并发，确定并发的业务逻辑正确 三、分析系统的压力点：从全局角度分析系统可能产生瓶颈的功能点。 方法：经验+业务+直觉
四、进行用户场景分析及用户并发数的设计 用户场景分析：确定系统每类用户的数量、每天用户的大概数量及不同时间段的各类用户数量
常见的场景：
1、一天不同时间段的使用场景-----关注：压力大的时间段；混合场景； 2、系统运行不同时期的场景-----关注：大数据量 3、不同业务模式的场景
用户并发数的设计方法：
1、极限法：并发数为在线数的50% 2、用户趋势分析法 3、经验评估
例：某系统使用人数为600人，最大在线200人，通常并发数为在线的30%，最大并发数为使用的15%
通常并发数：600*15%=90人 最大并发数：200*30%=60人
当不同方法获取的并发数不同时，则取最大数。
【设计并发用户数的注意点】 1、不同场景用法用户数设计：
（1）选择典型场景：并发数多的场景 （2）覆盖全面：覆盖压力的时间段 2、业务模式用户数设计：
主要关注功能模块间的集成，主要用于系统瓶颈难以定位的测试。 3、不同时间段的场景用户设计：
当业务模式在某段时间段并发时，一般取两种模式：（一天不同时间段的使用场景、不同业务模式）中的最大数。
2.性能测试—并发用户数的估算
在实际的性能测试工作中，测试人员常常会关心到并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，以下是一个估算并发用户数的方法： （1）计算平均的并发用户数：C=n*L/T （2）并发用户数峰值：C’≈C+3*根号C
公式（1）中，C是平均的并发用户数；n是LoginSession的数量（平均每天访问用户数）；L是LoginSession的平均长度（一天内用户从登录到退出的平均时间（操作平均时间））；T指考察的时间段长度（一天内多长时间有用户使用系统）。
公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C
就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的loginsession产生符合泊松分布理论而估算得到的。
实例：
假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。 则根据公式（1）和公式（2），可以得到： C=400*4/8=200
C’≈200+3*根号200=242
-----------------------------------------------------------
系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是2000个，那么这个数量，就是系统用户数。
同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
3.根据性能需求设计性能测试用例
某网站提供会员模板下载、上传、购买、支付等功能，目前进入性能测试阶段，通过性能需求可以了解到主要有以下几个性能指标需要进行测试： 产品页面刷新性能 产品上传性能 产品下载性能 搜索性能
目前给出的指标为： 延迟：
测试项响应时间抖动备注 产品页面刷新<5秒<2秒 产品下载相应时间<4秒<2秒
吞吐量： 编号项吞吐量
Perf.T.1所有登录用户在线状态更改频率每10分钟1次 Perf.T.2每日页面平均访问量60000次 Perf.T.3每日下载量50000
Perf.T.4平均每日新增会员数量500
Perf.T.5高峰同一模板下载量100用户并发下载
Perf.T.6高峰不同模板下载量150用户并发下载
容量： 编号项容量
Perf.C.1用户数<=100万 Perf.C.2活动用户数10000
Perf.C.3模板中心总用户数<=25万
根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？
首先，我不去在乎它要求的性能是什么，我只需要去做在一定的测试环境下对系统进行压力测试，找到各个性能指标的临界点就好了，至于是否达到性能指标，在和性能需求对照编写测试报告即可。
所以，针对这几个需要进行性能测试的页面，我们做一下分析，如何设计场景才能尽可能准确地体现出系统的性能： 先说一下搜索页面
搜索页面根据对项目的了解，搜索后，将所有符合条件的结果遍历出来，显示在前台，每页的显示数量是一定的，超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面，对于页面显示对性能的消耗我们可以忽略不计，主要的压力来自数据的传输、sql的执行及应用服务器的处理过程，所以我可以从两个方面设计场景：
a、虚拟用户一定，不同数据库数量级的情况下，搜索的性能 如何确定虚拟用户的数量成为一个关键，我们可以让客户提供一个常规情况下每天访问用户数（如果没有实际数据可参考，可以根据产品方案中期望的用户数来代替），我们就用这个用户数来进行测试；再来分析一下不同的数据库数量级，如果系统运营1年的产品数据量是5万条，那么我们就根据这个值分别取1W条、3W条、5W条、10W条、20W条数据量来进行测试（具体的分法可以根据实际情况而定），所以对于这个测试目标，我们可以设计5个场景进行：
虚拟用户数数据库数量级录制页面并发用户数执行时间思考时间 10010000搜索页面随机产生30分钟加入思考时间 10030000搜索页面随机产生30分钟加入思考时间 10050000搜索页面随机产生30分钟加入思考时间 100100000搜索页面随机产生30分钟加入思考时间 100200000搜索页面随机产生30分钟加入思考时间
b、一定数据库数量级，不同量虚拟用户的情况下，搜索的性能
我们定下来一个常规的数据库数据量，在数据量不变的情况下逐步增加虚拟用户数，测试一下不同虚拟用户压力下系统的性能。
虚拟用户数数据库数量级录制页面并发用户数执行时间思考时间 5050000搜索页面随机产生30分钟加入思考时间 8050000搜索页面随机产生30分钟加入思考时间 10050000搜索页面随机产生30分钟加入思考时间 12050000搜索页面随机产生30分钟加入思考时间 15050000搜索页面随机产生30分钟加入思考时间
产品上传
影响上传性能的主要因素有上传文件的大小和上传的请求数，所以我们就从这两个方面设计用例。
a、虚拟用户数一定，上传不同大小的文件
虚拟用户数上传文件大小录制页面并发用户数执行时间思考时间 50100k上传页面随机产生30分钟取消思考时间 50300k上传页面随机产生30分钟取消思考时间 50500k上传页面随机产生30分钟取消思考时间 50800k上传页面随机产生30分钟取消思考时间 501M上传页面随机产生30分钟取消思考时间
b、上传文件大小一定，不同量的虚拟用户
虚拟用户数上传文件大小录制页面并发用户数执行时间思考时间 20300k上传页面随机产生30分钟取消思考时间 50300k上传页面随机产生30分钟取消思考时间 80300k上传页面随机产生30分钟取消思考时间 100300k上传页面随机产生30分钟取消思考时间 产品下载
影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例
a、虚拟用户数一定，下载不同大小的文件
虚拟用户数下载文件大小录制页面并发用户数执行时间思考时间 50100k下载页面随机产生30分钟取消思考时间 50300k下载页面随机产生30分钟取消思考时间 50500k下载页面随机产生30分钟取消思考时间 50800k下载页面随机产生30分钟取消思考时间 501M下载页面随机产生30分钟取消思考时间
b、下载文件大小一定，不同量的虚拟用户
虚拟用户数下载文件大小录制页面并发用户数执行时间思考时间 20300k下载页面随机产生30分钟取消思考时间 50300k下载页面随机产生30分钟取消思考时间 80300k下载页面随机产生30分钟取消思考时间 100300k下载页面随机产生30分钟取消思考时间
4.微软提供的性能测试用例模版
Englishversion(英文版) 测试用例(Testcase)
Title(用例名称): CaseID(用例编号): Level(重要程度):
Designer(用例设计人): Developer(代码负责人): Tester(测试人): Time(测试时间):
测试场景描述(Casescenario): 场景描述 子场景(可选)
子场景1例如，返回10条记录 子场景2例如，返回100条记录
测试流程(Testingprocess)
描述被测试应用场景的商业流程，流程必须在实际测试中发挥良好的导航作用，使不熟悉该系统的使用者能够对商业流程有清晰的了解。
(被测的商业流程应该事先通过检测，以确保功能的顺利运行。应用程序代码在测试阶段应该被冻结) 1． 2． 3．
测试条件和要求(Requirements) 环境要求 硬件要求：
WEB服务器-配置1.2(详细配置信息见测试计划文档，或附录) 软件要求： 补丁要求： 网络要求：
性能基线和衡量指标(Testingbaseline&metrics) 前提(测试结果有效的先决条件)
1.例如：无内存泄漏；HTTP错误个数为0 2.数据库数据要求
例如：流水表已有20万条记录 3.并发连接数要求 4.测试周期或测试次数 性能基线
1.例如：每秒钟完成XXX笔交易 2.3.
监视参数(详情见附录)
1.例如：PerformanceMonitor:PrivateByte 2. 3.
性能计算方式
1.例如：数据库交易表增加纪录数/总时间(秒) 2. 3.
测试数据和脚本(Testingdata,Scripts) 测试数据准备
包括登陆账号组，输入数据；可以事先保存在某个文本文件中 测试数据库
数据库、表、存储过程、视图、用户帐号、相关数据 测试脚本
根据测试工具编写相应脚本或编写手工测试脚本 forExample1LBrowser
1.NavigatetothehomepageoftheOnlineShoppingsite. 2.Click“Help.” 3.Click“FAQ.”
4.Click“Shopping”onFAQ.
5.Click“Shopping/OurProducts”onthemainmenu. 6.Click“ProductSearch.” 7.Click“SpecialOffers.” 8.Click“StoreFinder.”
9.ClickCentralScotlandtoviewshopaddresses. 10.Click“Edinburgh”toseedetails. 11.Click“AfterSales.” 12.Click“Basket.”
13.NavigatetothehomepageoftheOnlineShoppingsite. 14.ClickonAdvertatbottomofpage.
测试手段(Testinginstrument) 例如：编写自动测试工具 或使用专用测试工具。 备注(Remarks)
附录A–应用软件性能数据分类 4.1应用软件性能数据概述
在企业级应用的负载测试过程中，测试工具通过部署一整套性能监视器，来收集和显示各个架构层次、服务器和组件上的性能数据，包括网络、操作系统、应用服务器、中间件、应用程序、.NET服务器、Web服务器和数据库服务器。在进行负载测试时，这些数据用来精确测量系统各个方面的性能，从而用户可以快速、简便地定位问题和瓶颈的来源。最终，这些数据用来生成各种文档和图表，并判断出应用程序的性能是否满足业务的需要。
5.WEB性能测试用例设计
性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则；
一、WEB全面性能测试模型
Web性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1.预期指标的性能测试
系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过20秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 2.业务性能测试
业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。
用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。
3.组合业务性能测试
通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。 用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配； 4.疲劳强度性能测试
疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定； 5.大数据量性能测试
一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试； 第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。 第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试；
大数据量测试通常在投产环境下进行，并出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试； 6.网络性能测试
主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中
主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成；
7.服务器（操作系统，WEB服务器，数据库服务器）性能测试
初级服务器性能测试主要是指在业务系统工作或者进行前面其他种类性能测试的时候，监控
服务器的一些计数器信息，通过这些计数器对服务器进行综合性能分析，为调优或提高系统性能提供依据；
高级服务器性能测试一般由专门的系统管理员来进行如数据库服务器由专门的DBA来进行测试和调优； 8.一些特殊的测试
主要是指配置测试，内存泄露测试的一些特殊的WEB性能测试； 二、WEB性能测试策略
性能测试策略一般从需求设计阶段开始讨论如何定制，它决定着性能测试工作要投入多少资源，什么时间开始实施等后续工作的安排；其制定的主要依据是软件自身的特点和用户对性能的关注程度，其中软件自身的特点起决定性的作用； 软件按照用途的不同可以分为两大类，系统类软件和应用类软件。系统类软件通常对性能要求较高，因此性能测试应该尽早介入；应用类软件分为特殊类应用和一般类应用，特殊类应用主要有银行，电信，电力，保险，医疗，安全等领域软件，这类软件使用频繁，用户较多，也需要较早进行性能测试；一般类主要是指一些普通类应用如OA，MIS等一般类软件根据实际情况制定性能测试策略，受用户因素影响较大； 1.系统类软件
从设计阶段就开始针对系统架构，数据库设计等方面进行讨论，从根源来提高性能，系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法和模块；
2.应用类软件
特殊应用：从设计阶段就开始针对系统架构，数据库设计等方面进行讨论，从根源来提高性能，系统类软件一般从单元测试阶段开始性能测试实施工作，主要是测试一些和性能相关的算法和模块； 一般应用：与使用用户的重视程度有关，用户高度重视时，设计阶段开始进行一些讨论工作，主要在系统测试阶段开始进行性能测试实施；用户一般重视时，可以在系统测试阶段的功能测试结束后进行性能测试；用户不怎么重视时，可以在软件发布前进行性能测试，提交测试报告即可；
三、WEB性能测试用例设计模型
性能测试用例设计通常不会一次设计到位，是一个不断迭代完善的过程，即使在使用过程中，也不是完全按照设计好的测试用例来执行，需要根据需求的变化进行调整和修改；WEB性能测试用例设计模型是一个内容全面比较容易组织和调整的模型架构。 1.预期性能指标测试用例
指一些十分明确的，在系统需求设计阶段预先提出的，期望系统达到的，或者向用户保证的性能指标，针对每个指标都要编写一个或者多个测试用例来验证系统是否达到要求，预期性能指标测试用例主要参考需求和设计文档，把里面十分明确的性能要求提取出来，指标中通常以单用户为主；
如：对于普通的客户端，系统上传5MB以内的文件，速度不低于2MB/S； 输入动作：选择1-5MB的文件并上传，用秒表计时； 期望的性能：上传的时间小于等于2.5S 实际性能：上传的时间2.29秒； 这类用例通常以手工的方式执行；
三．性能测试场景监控分析 1.性能计数器及性能分析方法
性能计数器（Counter）通常被用来衡量被测系统当前的状况和进行性能测试结果分析。可以在操作系统级别、应用服务器级别和数据库级别上查看和记录性能计数器的数值，在性能测试分析结果对这些数据进行分析。
一：操作系统计数器及分析 (1)Windows操作系统的主要计数器
Memory:AvailableMbyte物理内存的可用数（至少要有10%的物理内存值）
如果Process/Privatebytes和Process/workingset这2个计数器升高，而AvailableMbyte降低，则可能是内存泄露.
Processor：ProcessorTimeCPU使用率（查看处理器饱和状态的最佳计数器）
显示CPU的线程处理时间，如果超过90%，则表示测试的负载对于目前的硬件过于沉重 DiskTime(Physical_disk_totol,DPCTime,ProcessorTime)如果这2个计数器均较大，则磁盘不是瓶颈，如果只有DiskTime较大，则IO（输入输出）可能为瓶颈.
Pageread/sec：页的硬故障，为了解析对内存的引用，必须读取页文件的次数，值>5,越低越好，大数值表示磁盘读而不是缓存读.
PageRead操作速度很低，DiskTime和Avg.DiskQueueLength的值很高，则可能有磁盘瓶颈. 如果DiskqueueLength增加的同时页面读取速率并为降低，则内存不足.
PagesInput/sec是为了解决硬错误页，从硬盘上读取的页数，而PageReads/sec是为了解决硬错误，从硬盘读取的次数。如果PageReads/Sec比率持续保持为5，表示可能内存不足。PagesInput/sec是指内存引用时页面不在内存，为解决这种情况而从磁盘读取的页面数量。此计数器包含页面流量，它代表为应用程序访问文件数据分配的系统缓存。如果您担心过量的内存压力（即，系统颠簸）以及可能造成的过量调页，那么这是个需要查看的重要计数器。 PageFaults/sec是指处理器中“页面错误”的数量。当一个进程引用不在主存储器“工作集”中的虚拟内存页时，就会发生页面错误。如果该页面在Standby列表上，因而已在主存储器中，或者如果另一个与其共享该页面的进程正在使用该页，那么发生“页面错误”时，不会从磁盘读取该页面。
PagesOutput/sec是指因主存储器中的页面已修改而写入磁盘的页面数量。
Pages/sec是指引用不在内存中的页面时，为解决这一问题，从磁盘读取或写入到磁盘的页面数量。它是PagesInput/sec与PagesOutput/sec之和。此计数器包含页面流量，它代表为应用程序访问文件数据分配的系统缓存。该值还包括取自或保存到非高速缓存的映射内存文件的那些页面。如果您担心过量的内存压力（即，系统颠簸），以及可能造成的过量调页，那么，这是个需要查看的主要计数器。在WTS测试中观察到的结果表明，内存瓶颈对系统性能的影响比CPU瓶颈的影响严重得多。出现CPU瓶颈时，仍会处理所有的客户请求，但处理速度变慢。受CPU的机器上的所有客户均可以继续操作，只是在处理过程中，会有
持续几秒的定期暂停。在受内存的WTS中，测试已表明，只要可用的物理系统RAM已达到某个水平，系统就会开始从转换文件读取页面和写入页面。在物理系统RAM的数量达到临界水平后，WTS就会充斥大量转换文件的调页信息。由于影响很大，所以应密切观察内存的使用情况。
最重要的两个性能计数器是AvailableBytes和PageInputs/sec。如果观察到PageOutputs/Sec和PageInputs/Sec有上升的趋势，则系统中可能存在内存瓶颈。当处理器向内存指定的位置请求一页（可能是数据或代码）出现错误时，这就构成一个PageFault。如果该页在内存的其他位置，该错误被称为软错误（用TransitionFault/sec计数器衡量）；如果该页必须从硬盘上重新读取时，被称为硬错误。许多处理器可以在有大量软错误的情况下继续操作。但是，硬错误可以导致明显的拖延。PageFaults/sec是处理器每秒钟处理的错误页（包括软错误和硬错误）。
(2)Unix操作系统的主要计数器 (3)内存分析法 (4)CPU处理器分析方法
值得注意的是，由于操作系统本身的特性，在某些多CPU系统中，该数据本身并不大，但此时CPU之间的负载状况极不平衡，此时也应该视作系统产生了处理器方面的瓶颈。
(5)磁盘I/O分析方法
如果分析的计数器指标来自于数据库服务器、文件服务器或是流媒体服务器，磁盘I/O对这些系统来说更容易成为瓶颈。
(6)进程分析方法 (7)网络分析方法
二：应用服务器计数器 内存：
1）UNIX资源监控中指标内存页交换速率（Pagingrate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2）Windows资源监控中，如果Process\\PrivateBytes计数器和Process\\WorkingSet计数器的值在长时间内持续升高，同时Memory\\Availablebytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(highpageoutrate); 进程进入不活动状态;
交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率;
内存不够出错(outofmemoryerrors)
CPU处理器：
1）UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPUutilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQLServer,可接受的最大上限是80-85%。 合理使用的范围在60%至70%。
2）Windows资源监控中，如果System\\ProcessorQueueLength大于2，而处理器利用率（ProcessorTime）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆:
很慢的响应时间(slowresponsetime) CPU空闲时间为零(zeropercentidleCPU)
过高的用户占用CPU时间(highpercentuserCPU) 过高的系统占用CPU时间(highpercentsystemCPU)
长时间的有很长的运行进程队列(largerunqueuesizesustainedovertime)
磁盘I/O：
1）UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Diskrate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。 2）Windows资源监控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec页面读取操作速率很低，则可能存在磁盘瓶径。 I/O资源成为系统性能的瓶颈的征兆:
过高的磁盘利用率(highdiskutilization)
太长的磁盘等待队列(largediskqueuelength)
等待磁盘I/O的时间所占的百分率太高(largepercentageoftimewaitingfordiskI/O) 太高的物理I/O速率:largephysicalI/Orate(notsufficientinitself) 过低的缓存命中率(lowbuffercachehitratio(notsufficientinitself)) 太长的运行进程队列，但CPU却空闲(largerunqueuewithidleCPU)
监视IIS需要的一些计数器
（1）InternetInformationServicesGlobal:
FileCacheHits%、FileCacheFlushes、FileCacheHits
FileCacheHits%是全部缓存请求中缓存命中次数所占的比例，反映了IIS的文件缓存设置的工作情况。对于一个大部分是静态网页组成的网站，该值应该保持在80%左右。而FileCacheHits是文件缓存命中的具体值，FileCacheFlushes是自服务器启动之后文件缓存刷新次数，如果刷新太慢，会浪费内存；如果刷新太快，缓存中的对象会太频繁的丢弃生成，起不到缓存的作用。通过比较FileCacheHits和FileCacheFlushes可得出缓存命中率对缓存清空率的比率。通过观察它两个的值，可以得到一个适当的刷新值（参考IIS的设置ObjectTTL、MemCacheSize、MaxCacheFileSize）
（2）WebService:
BytesTotal/sec:显示Web服务器发送和接受的总字节数。低数值表明该IIS正在以较低的速度进行数据传输。
ConnectionRefused：数值越低越好。高数值表明网络适配器或处理器存在瓶颈。
NotFoundErrors：显示由于被请求文件无法找到而无法由服务器满足的请求数（HTTP状态代码404）
（3）【Memory】
内存使用情况可能是系统性能中最重要的因素。如果系统“页交换”频繁，说明内存不足。“页交换”是使用称为“页面”的单位，将固定大小的代码和数据块从RAM移动到磁盘的过程，其目的是为了释放内存空间。尽管某些页交换使Windows2000能够使用比实际更多的内存，也是可以接受的，但频繁的页交换将降低系统性能。减少页交换将显著提高系统响应速度。要监视内存不足的状况，请从以下的对象计数器开始：
AvailableMbytes:可用物理内存数.如果AvailableMbytes的值很小（4MB或更小），则说明计算机上总的内存可能不足，或某程序没有释放内存。 page/sec:表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。一般如果pages/sec持续高于几百，那么您应该进一步研究页交换活动。有可能需要增加内存，以减少换页的需求（你可以把这个数字乘以4k就得到由此引起的硬盘数据流量）。Pages/sec的值很大不一定表明内存有问题，而可能是运行使用内存映射文件的程序所致。
pageread/sec:页的硬故障，page/sec的子集，为了解析对内存的引用，必须读取页文件的次数。阈值为>5.越低越好。大数值表示磁盘读而不是缓存读。 由于过多的页交换要使用大量的硬盘空间，因此有可能将导致将页交换内存不足与导致页交换的磁盘瓶径混淆。因此，在研究内存不足不太明显的页交换的原因时，您必须跟踪如下的磁盘使用情况计数器和内存计数器： 【PhysicalDisk\\%DiskTime】
PhysicalDisk\\Avg.DiskQueueLength
例如，包括PageReads/sec和%DiskTime及Avg.DiskQueueLength。如果页面读取操作速率很低，同时%DiskTime和Avg.DiskQueueLength的值很高，则可能有磁盘瓶径。但是，如果队列长度增加的同时页面读取速率并未降低，则内存不足。
要确定过多的页交换对磁盘活动的影响，请将PhysicalDisk\\Avg.Disksec/Transfer和Memory\\Pages/sec计数器的值增大数倍。如果这些计数器的计数结果超过了0.1，那么页交换将花费百分之十以上的磁盘访问时间。如果长时间发生这种情况，那么您可能需要更多的内存。
PageFaults/sec:每秒软性页面失效的数目（包括有些可以直接在内存中满足而有些需要从硬盘读取）较page/sec只表明数据不能在内存的指定工作集中立即使用。 CacheBytes：文件系统缓存（FileSystemCache），默认情况下为50%的可用物理内存。如IIS5.0运行内存不够时，它会自动整理缓存。需要关注该计数器的趋势变化
如果您怀疑有内存泄露，请监视Memory\\AvailableBytes和Memory\\CommittedBytes，以观察内存行为，并监视您认为可能在泄露内存的进程的Process\\PrivateBytes、Process\\WorkingSet和Process\\HandleCount。如果您怀疑是内核模式进程导致了泄露，则还应该监视Memory\\PoolNonpagedBytes、Memory\\PoolNonpagedAllocs和Process(process_name)\\PoolNonpagedBytes。
Pagespersecond:每秒钟检索的页数。该数字应少于每秒一页。
【Process】
%ProcessorTime:被处理器消耗的处理器时间数量。如果服务器专用于sqlserver,可接受的最大上限是80-85%
PageFaults/sec:将进程产生的页故障与系统产生的相比较，以判断这个进程对系统页故障产生的影响。
Workset:处理线程最近使用的内存页，反映了每一个进程使用的内存页的数量。如果服务器有足够的空闲内存，页就会被留在工作集中，当自由内存少于一个特定的阈值时，页就会被清除出工作集。
Inetinfo:PrivateBytes:此进程所分配的无法与其它进程共享的当前字节数量。如果系统性能随着时间而降低，则此计数器可以是内存泄漏的最佳指示器。
【PhysicalDisk】
%DiskTime%:指所选磁盘驱动器忙于为读或写入请求提供服务所用的时间的百分比。如果三个计数器都比较大，那么硬盘不是瓶颈。如果只有%DiskTime比较大，另外两个都比较适中，硬盘可能会是瓶颈。在记录该计数器之前，请在Windows2000的命令行窗口中运行diskperf-yD。若数值持续超过80%，则可能是内存泄漏。
Avg.DiskQueueLength:指读取和写入请求(为所选磁盘在实例间隔中列队的)的平均数。该值应不超过磁盘数的1.5~2倍。要提高性能，可增加磁盘。注意：一个RaidDisk实际有多个磁盘。 AverageDiskRead/WriteQueueLength:指读取(写入)请求(列队)的平均数。
DiskReads(Writes)/s:物理磁盘上每秒钟磁盘读、写的次数。两者相加，应小于磁盘设备最大容量。
AverageDisksec/Read:指以秒计算的在此盘上读取数据的所需平均时间。 AverageDisksec/Transfer:指以秒计算的在此盘上写入数据的所需平均时间。 NetworkInterface：
BytesTotal/sec:为发送和接收字节的速率，包括帧字符在内。判断网络连接速度是否是瓶颈，可以用该计数器的值和目前网络的带宽比较。
【Processor】
监视“处理器”和“系统”对象计数器可以提供关于处理器使用的有价值的信息，帮助您决定是否存在瓶颈。
%ProcessorTime:如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
%UserTime:表示耗费CPU的数据库操作，如排序，执行aggregatefunctions等。如果该值很高，可考虑增加索引，尽量使用简单的表联接，水平分割大表格等方法来降低该值。 %PrivilegedTime：（CPU内核时间）是在模式下处理线程执行代码所花时间的百分比。如果该参数值和\"PhysicalDisk\"参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。另外设置TempdbinRAM，减低\"maxasyncIO\"，\"maxlazywriterIO\"等措施都会降低该值。 此外，跟踪计算机的服务器工作队列当前长度的ServerWorkQueues\\QueueLength计数器会显示出处理器瓶颈。队列长度持续大于4则表示可能出现处理器拥塞。此计数器是特定时间的值，而不是一段时间的平均值。
%DPCTime:越低越好。在多处理器系统中，如果这个值大于50%并且Processor:%ProcessorTime非常高，加入一个网卡可能会提高性能，提供的网络已经不饱和。
三：数据库服务器计数器 SQLServer数据库
1）SQLServer资源监控中指标缓存点击率（CacheHitRatio），该值越高越好。如果持续低于80%，应考虑增加内存。
2）如果FullScans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3）NumberofDeadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4）LockRequests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
SQLServer性能计数器
AccessMethods(访问方法)用于监视访问数据库中的逻辑页的方法。
.FullScans/sec(全表扫描/秒)每秒不受限的完全扫描数。可以是基本表扫描或全索引扫描。如果这个计数器显示的值比1或2高，应该分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
.Pagesplits/sec(页分割/秒)由于数据更新操作引起的每秒页分割的数量。
BufferManager(缓冲器管理器)：监视Microsoft?SQLServer?如何使用：内存存储数据页、内部数据结构和过程高速缓存；计数器在SQLServer从磁盘读取数据库页和将数据库页写入磁盘时监视物理I/O。监视SQLServer所使用的内存和计数器有助于确定：是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQLServer必须从磁盘检索数据。是否可通过添加更多内存或使更多内存可用于数据高速缓存或SQLServer内部结构来提高查询性能。
SQLServer需要从磁盘读取数据的频率。与其它操作相比，例如内存访问，物理I/O会耗费大量时间。尽可能减少物理I/O可以提高查询性能。
.PageReads/sec：每秒发出的物理数据库页读取数。这一统计信息显示的是在所有数据库间的物理页读取总数。由于物理I/O的开销大，可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，使开销减到最小。 .PageWrites/sec(.写的页/秒)每秒执行的物理数据库写的页数。 .BufferCacheHitRatio.在“缓冲池”（BufferCache/BufferPool）中没有被读过的页占整个缓冲池中所有页的比率。可在高速缓存中找到而不需要从磁盘中读取的页的百分比。这一比率是高速缓存命中总数除以自SQLServer实例启动后对高速缓存的查找总数。经过很长时间后，这一比率的变化很小。由于从高速缓存中读数据比从磁盘中读数据的开销要小得多，一般希望这一数值高一些。通常，可以通过增加SQLServer可用的内存数量来提高高速缓存命中率。计数器值依应用程序而定，但比率最好为90%或更高。增加内存直到这一数值持续高于90%，表示90%以上的数据请求可以从数据缓冲区中获得所需数据。
.LazyWrites/sec(惰性写/秒)惰性写进程每秒写的缓冲区的数量。值最好为0。 CacheManager(高速缓存管理器)对象提供计数器，用于监视Microsoft?SQLServer?如何使用内存存储对象，如存储过程、特殊和准备好的Transact-SQL语句以及触发器。
.CacheHitRatio(高速缓存命中率，所有Cache”的命中率。在SQLServer中，Cache可以包括
LogCache，BufferCache以及ProcedureCache，是一个总体的比率。)高速缓存命中次数和查找次数的比率。对于查看SQLServer高速缓存对于你的系统如何有效，这是一个非常好的计数器。如果这个值很低，持续低于80%，就需要增加更多的内存。
Latches(闩)用于监视称为闩锁的内部SQLServer资源锁。监视闩锁以明确用户活动和资源使用情况，有助于查明性能瓶颈。
.AverageLatchWaitTime(ms)(平均闩等待时间(毫秒))一个SQLServer线程必须等待一个闩的平均时间，以毫秒为单位。如果这个值很高，你可能正经历严重的竞争问题。
.LatchWaits/sec(闩等待/秒)在闩上每秒的等待数量。如果这个值很高，表明你正经历对资源的大量竞争。
Locks(锁)提供有关个别资源类型上的SQLServer锁的信息。锁加在SQLServer资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。例如，如果一个排它(X)锁被一个事务加在某一表的某一行上，在这个锁被释放前，其它事务都不可以修改这一行。尽可能少使用锁可提高并发性，从而改善性能。可以同时监视Locks对象的多个实例，每个实例代表一个资源类型上的一个锁。
.NumberofDeadlocks/sec(死锁的数量/秒)导致死锁的锁请求的数量
.AverageWaitTime(ms)(平均等待时间(毫秒))线程等待某种类型的锁的平均等待时间 .LockRequests/sec(锁请求/秒)每秒钟某种类型的锁请求的数量。
Memorymanager:用于监视总体的服务器内存使用情况，以估计用户活动和资源使用，有助于查明性能瓶颈。监视SQLServer实例所使用的内存有助于确定：
是否由于缺少可用物理内存存储高速缓存中经常访问的数据而导致瓶颈存在。如果是这样，SQLServer必须从磁盘检索数据。
是否可以通过添加更多内存或使更多内存可用于数据高速缓存或SQLServer内部结构来提高查询性能。
Lockblocks:服务器上锁定块的数量，锁是在页、行或者表这样的资源上。不希望看到一个增长的值。
Totalservermemory：sqlserver服务器当前正在使用的动态内存总量.
Oracle数据库：
（1）如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率： select(sum(pins-reloads))/sum(pins)fromv$librarycache; select(sum(gets-getmisses))/sum(gets)fromv$rowcache; 自由内存：select*fromv$sgastatwherename=’freememory’;
（2）如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
缓冲区高速缓存命中率：
selectname,valuefromv$sysstatwherenamein(’dbblockgets’, ‘consistentgets’,'physicalreads’);
HitRatio=1-(physicalreads/(dbblockgets+consistentgets))
（3）如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
日志缓冲区的申请情况：
selectname,valuefromv$sysstatwherename=‘redologspacerequests’;
（4）如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。 内存排序命中率：
selectround((100*b.value)/decode((a.value+b.value),0,1,(a.value+b.value)),2)fromv$sysstata,v$sysstatbwherea.name=’sorts(disk)’andb.name=’sorts(memory)’
注：上述SQLServer和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。
LR中监控ORACLE数据库常用计数器
一、添加自定义计数器的方法
要创建自定义查询，请执行以下操作：
1.在安装路径的MercuryLoadRunner\\dat\\monitors找到vmon.cfg文件，打开。
2.在vmon.cfg文件的第三行中，CustomCounters=指出要创建的自定义计数器个数。 3.在vmon.cfg文件中为新计数器新建一节，每节都有以下格式： [Custom0]
Name=FiveHundred
Description=Thiscounteralwaysreturns500. Query=SELECT500FROMDUAL IsRate=0
4.在[Custom＃]行，将计数器顺序中的下一个数字分配给新的自定义计数器。 注意：自定义计数器必须是以数字0开始的联系顺序。 5.在Name行，输入新计数器的名称（可以输入中文）。
6.在Description行，输入对该计数器的描述或解释（可以输入中文）。
7.在Query行，输入恰好返回数据库一行的SQL查询的文本，该行必须包含一列数值。 注意：自定义查询文本不能够超过512字符。
8.在IsRate行，如果希望数据库将计数器报告为一个绝对值，请输入0；如果希望数 据库报告每单位时间计数器的更改，请输入1。 注意：自定义查询无法返回负值。 例：
[Custom0]
;Namemustbeunique
Name=库快存命中率
Description=该计数器返回当前库快存命中率
Query=SELECT100*((sum(pins-reloads))/sum(pins))fromv$librarycache IsRate=0
3配置文件示例对象
安装路径的MercuryLoadRunner\\dat\\monitors找到vmon.cfg文件： V$Monitor] Counters=150
CustomCounters=12
;Howmanysecondsforeachdatasample?
SamplingRate=10 [Custom0]
;Namemustbeunique Name=库快存命中率
Description=该计数器返回当前库快存命中率
Query=SELECT100*((sum(pins-reloads))/sum(pins))fromv$librarycache IsRate=0 [Custom1]
;Namemustbeunique
Name=高速缓存区命中率
二、如何在LoadRunner中监控Oracle数据库
如何在LoadRunner中监控Oracle数据库.d
2.LR性能监控指标
【监控关注点】
--并发数----->监控用户运行是否正常 --场景状态监控 --事务响应时间 --服务器状态 --操作系统 --LRAgent使用
---添加监控器-----计数器
【内存泄露】
Process/PrivateBytes计数器---升高 Process/Workingset计数器----升高 AvailablesBytes----降低
【Processor相关】
ProcessorQueueLength现实的队列长度保持不变（>=2）并且处理器的利用
率%ProcessorTime超过90%，那么很有可能存在处理器瓶颈。
如果队列长度>2，处理器的利用率一直很低，那么处理器有阻塞，这时，处理器不是瓶
颈。
【Throughput吞吐量】正常--曲线随着用户数的增加而增加。
3.LR的Apache的监控配置
具体配置如下：
配置LoadRunner监控Apache,LoadRunner监控Apache服务器是调用的Apache自身的模块进行监控的，所以需要配置Apache和LoadRunner
一.配置LoadRunner
1.在图树中单击Apache图，并将该图拖进“运行”视图的右窗格中。 2.右键单击该图，然后选择“添加度量”，或选择“监视器”>“添加联机度量”。 3.在“Apache”对话框的“监视的服务器计算机”部分，单击“添加”输入要监 视计算机的服务器名或IP地址。选择计算机运行的平台，单击“确定”。
4.在“Apache”对话框的“资源度量”部分中，单击“添加”选择要监视的度量。 将打开“Apache-添加度量”对话框，显示可用的度量和服务器属性。
5.在“服务器属性”部分，输入端口号和不带服务器名的URL，并单击“确定”。 默认的URL是/server-status?auto。 6.在“Apache”对话框中单击“确定”，激活监视器。 二.配置Apache
1.修改Apache中Httpd.conf文件，添加如下代码（该文件中都有，只要取消注释就好了） Allowfrom.localhost
2.添加ExtendedStatus 设置ExtendedStatusOn
3.取消注释LoadModulestatus_modulemodules/mod_status.so 加载该模块。
4.重新启动Apache
4.性能测试服务器分析指标
应用服务器 CPU% Mem—Realtotal(MB) PROC—RunQueue 数据库服务器 CPU% Mem—Realtotal(MB) PROC—RunQueue 分析 当CPU%较高时，需要分析当前的服务器进程，是否由于Oracle相关进程消耗所致 当物理可用内存较少时，需要关注Oracle用内存的情况 当RunQueue较大时，需关注CPU等待队列 分析 当CPU%较高时，需要分析当前的服务器进程，是否由于JVM消耗所致 当物理可用内存较少时，要关注JVM内存分配的情况及GC的情况 当RunQueue较大时，需关注CPU等待队列以及Webshepe当时HTTP已建立连接数等指标 其他Oracle分析
需要提供相关的TopSQL的分析、已建立Session的连接数、Oracle自身的Cache命中率等。 【Web服务器指标指标：】
*AvgRps:平均每秒钟响应次数＝总请求时间/秒数； *SuccessfulRounds：成功的请求； *FailedRounds：失败的请求；
*SuccessfulHits：成功的点击次数； *FailedHits：失败的点击次数； *HitsPerSecond：每秒点击次数；
*SuccessfulHitsPerSecond：每秒成功的点击次数； *FailedHitsPerSecond：每秒失败的点击次数； *AttemptedConnections：尝试链接数；
-----------------------------------------------------------------------
WEB性能测试的部分概念一般来说，一个web请求的处理包括以下步骤：
（1）客户发送请求；
（2）webserver接受到请求，进行处理； （3）webserver向DB获取数据；
（4）webserver生成用户请求的object（页面），返回给用户。从客户发送请求开始到客户接收到最后一个字节的时间成为响应时间（第三步不包括在每次请求处理中）。
1.事务（Transaction）
在web性能测试中，一个事务表示一个“从用户－》webServer－》DB－》webserver－》用户”的过程，一般的响应时间都是针对事务而言的。
2.响应时间
响应时间指的是从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，这个过程所耗费的时间。在某些工具中，响应时间通常会称为“TTLB”，即“timetolastbyte”，意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。响应时间的单位一般为“秒”或者“毫秒”。一个公式可以表示：响应时间=网络响应时间+应用程序响应时间
3.并发数
并发数是指同时进行请求的客户的数量，并发数用于模拟用户的真实负载情况（并发情况是对系统最大的考验），并发数≠同时使用系统的用户数。
4.吞吐量
吞吐量指的是单位时间内处理的客户端请求数量。通常情况下，吞吐量用请求数/秒或者页面数/秒来衡量。从业务角度看，吞吐量也可以用访问人数/天或者页面访问量/天来衡量。
5.资源利用率
资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU（s），内存，网络带宽等。资源利用率通常以占用最大值的百分比n%来衡量。
5.如何手动重新生成性能计数器库值
确保目标机器window系统的服务中开启了RemoteRegistry服务：在控制面板里管理工具的服务里面。
------------------------------------------------
现有一台服务器，window2000系统,重做系统前性能统计全部变成数字，以为是系统原因，重装系统后发现故障还是一样。问题特别奇怪。而导致这个问题的原因有两个方面，一个是主板上的计数传感器损坏或故障，第二个就是系统中注册表对于性能计数器的名称命名损坏。修复方法见下文。
本文介绍如何手动重新生成性能计数器库值。
重要说明：本文中的信息仅适用于英语版Windows2000。
本文包含有关修改注册表的信息。修改注册表之前，一定要先进行备份，并且一定要知道在发生问题时如何还原注册表。
警告：注册表编辑器使用不当可导致严重问题，可能需要重新安装操作系统。Microsoft不能保证您可以解决因注册表编辑器使用不当而导致的问题。使用注册表编辑器需要您自担风险。
当您使用系统监视器工具时，有些计数器可能丢失，或者其中未包含计数器数据。基本的性能计数器库集可能被损坏，并且可能需要和任何可扩展计数器一起重新生成。如果某些可扩展计数器损坏了注册表，或者某些基于WindowsManagementInstrumentation(WMI)的程序修改了注册表，就可能会发生此问题。
可扩展计数器信息存储在以下两个位置中： 以下注册表项：
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WindowsNT\\CurrentVersion\\Perflib\\009
%Systemroot%\\System32\\Perfc009.dat文件和%Systemroot%\\System32\\Perfh009.dat文件。 要手动重新生成基本的性能计数器库，请执行以下操作：
展开“Perfc009.dat”文件和“Perfh009.dat”文件。这些文件位于Windows2000光盘上。压缩文件位于DriveLetter:\\i386\\perfc009.da_和DriveLetter:\\i386\\perfh009.da_。替换%Systemroot%\\System32文件夹中的文件。有关EXPAND命令的其他信息，请单击下面的文章编号，以查看Microsoft知识库中相应的文章：
314958(http://support.microsoft.com/kb/314958/)如何在Windows2000中分别使用COMPRESS、COMPACT和EXPAND命令压缩和展开文件及文件夹 启动注册表编辑器，然后在注册表中查找以下项：
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\WindowsNT\\CurrentVersion\\Perflib 在注册表中，将“LastCounter”值更改为1846（十进制），并将“LastHelp”值更改为1847（十进制）。
查找以下注册表项，以搜索具有Performance子项的服务：
HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Services
从Performance子项（如果存在）删除以下值： FirstCounter FirstHelp LastCounter LastHelp
您还可以使用Exctrlst.exe工具来查找安装的性能计数器动态链接库文件(DLL)，然后访问注册表以删除DWORD值。现在您拥有了只包含系统基计数器的可以正常使用的性能注册表。 完成此过程后，必须从服务列表重新添加可扩展计数器。但是在执行此操作之前，必须确定用于加载计数器的.ini文件： 打开一个命令提示符窗口。
在命令提示符处，键入cd%Systemroot%\\System32，然后按Enter。 在命令提示符处，键入findstrdrivername*.ini，然后按Enter。 注意列表中每个驱动程序名称所对应的.ini文件名。 在命令提示符处，键入下面一行，然后按Enter： lodctrinifile
其中，inifile是对应您要重新加载的驱动程序的.ini文件名。 例如，如果打算重新加载ASP驱动程序，则第4步中出现的列表将显示Axperf.ini是用于ASP驱动程序的.ini文件(axperf.ini:drivername=ASP)。因此，要重新加载ASP驱动程序，请在命令提示符处键入lodctraxperf.ini，然后按Enter。 为列表中的所有.ini文件重复第5步。 重新启动计算机。
要在WindowsServer2003重新生成所有的性能计数器（包括扩展的和第三方计数器），请在命令提示符处键入以下命令。在输入每个命令后按Enter。 cd\\windows\\system32 lodctr/R
注意：/R是大写。
WindowsServer2003重新生成了所有的计数器，因为它读取了英文操作系统的C:\\Windows\\inf\\009文件夹中所有的.ini文件。 注意：如果您正在运行群集或数据中心产品，则在对基本计数器和可扩展计数器执行上述步骤后，必须故障转移节点以刷新计数器列表。
注意：在运行添加其自身的性能计数器的应用程序的系统上，例如在MicrosoftExchange或SQLServer上，用于加载性能计数器的.ini文件可能不在%systemroot\\system32中。通常可以在应用程序文件夹结构下找到这些.ini文件。 注意：在使用上述步骤时，如果收到有关性能库的错误消息，则可能必须卸载并重新加载IIS性能动态链接库(DLL)。
四．性能测试结果分析 性能瓶颈分析方法
同一场景
小用户量的情况下测试 大用户量情况下的测试
分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析windowresource图表，查看cpu。
使用下列计数器标识cpu瓶颈 Processor\\Interrupts/sec Processor\\%ProcessorTime
Process(process)\\%ProcessorTime System\\ProcessorQueueLength
通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高。 下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）。
性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。
分析原则：
具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点） 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 ?分段排除法：很有效
分析的信息来源：
1根据场景运行过程中的错误提示信息 2根据测试结果收集到的监控指标数据
一．错误提示分析
分析实例：
1?Error:Failedtoconnecttoserver\"10.10.10.30:8080\":[10060]Connection
?Error:timedoutError:Server\"10.10.10.30\"hasshutdowntheconnectionprematurely
分析：
?A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题） ?B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connectionrefused消息，说明应提高该值，每次增加25％ ?C、数据库的连接
(1、在应用服务的性能参数可能太小了2、数据库启动的最大连接数（跟硬件的内存有关）)
2Error:Pagedownloadtimeout(120seconds)hasexpired
分析：可能是以下原因造成
?A、应用服务参数设置太大导致服务器的瓶颈 ?B、页面中图片太多
?C、在程序处理表的时候检查字段太大多
二．监控指标数据分析
1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。 如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。
2．业务操作响应时间：
?分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
?细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
?如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题 3．服务器资源监控指标： 内存：
1UNIX资源监控中指标内存页交换速率（Pagingrate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2Windows资源监控中，如果Process\\PrivateBytes计数器和Process\\WorkingSet计数器的值在长时间内持续升高，同时Memory\\Availablebytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆:
很高的换页率(highpageoutrate); 进程进入不活动状态;
交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率;
内存不够出错(outofmemoryerrors)
处理器：
1UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPUutilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQLServer,可接受的最大上限是80-85% 合理使用的范围在60%至70%。
2Windows资源监控中，如果System\\ProcessorQueueLength大于2，而处理器利用率（ProcessorTime）一直很低，则存在着处理器阻塞。
CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slowresponsetime) CPU空闲时间为零(zeropercentidleCPU)
过高的用户占用CPU时间(highpercentuserCPU) 过高的系统占用CPU时间(highpercentsystemCPU)
长时间的有很长的运行进程队列(largerunqueuesizesustainedovertime)
磁盘I/O：
1UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Diskrate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2Windows资源监控中，如果DiskTime和Avg.DiskQueueLength的值很高，而PageReads/sec页面读取操作速率很低，则可能存在磁盘瓶径。
I/O资源成为系统性能的瓶颈的征兆: 过高的磁盘利用率(highdiskutilization)
太长的磁盘等待队列(largediskqueuelength)
等待磁盘I/O的时间所占的百分率太高(largepercentageoftimewaitingfordiskI/O) 太高的物理I/O速率:largephysicalI/Orate(notsufficientinitself) 过低的缓存命中率(lowbuffercachehitratio(notsufficientinitself)) 太长的运行进程队列，但CPU却空闲(largerunqueuewithidleCPU)
4．数据库服务器： SQLServer数据库：
1SQLServer资源监控中指标缓存点击率（CacheHitRatio），该值越高越好。如果持续低于80%，应考虑增加内存。
2如果FullScans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3NumberofDeadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导
致恶劣的用户体验。该计数器的值必须为0。
4LockRequests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率： select(sum(pins-reloads))/sum(pins)fromv$librarycache; select(sum(gets-getmisses))/sum(gets)fromv$rowcache;
自由内存：select*fromv$sgastatwherename=’freememory’; 2如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。 缓冲区高速缓存命中率：
selectname,valuefromv$sysstatwherenamein('dbblockgets’, 'consistentgets','physicalreads');
HitRatio=1-(physicalreads/(dbblockgets+consistentgets))
3如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。 日志缓冲区的申请情况：
selectname,valuefromv$sysstatwherename='redologspacerequests';
4如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。 内存排序命中率：
selectround((100*b.value)/decode((a.value+b.value),0,1,(a.value+b.value)),2)fromv$sysstata,v$sysstatbwherea.name='sorts(disk)'andb.name='sorts(memory)'
五．【性能测试的具体案例分析】
在本文介绍的这个案例中，被测应用系统是一家公司的客户信息系统，它主要用来录入、修改以及查询全球客户的信息，并将客户信息转入到业务系统。但是，在应用过程中，客户经常投诉在某个时刻新建或者修改一个客户信息非常慢，正常情况下完成该操作只需要1～5秒，而异常时却需要10分钟左右，而且系统管理员发现系统资源使用率都比较低，这种情况的出现并没有规律性。
在这个案例中我们发现了系统存在性能问题，下一步工作就是要在性能测试过程中查找形成系统瓶颈和故障的根本原因，在此项工作中我们应该按照如下几个步骤进行。
1．确定明确的测试目标
性能调优是是无止境的，所以在测试之前应确定一个明确性能调优目标，这也是后面“评估性能验证”的一个基准，也是测试终止的一个基准。在本案例中目标设定为：在相同系统环境配置下30个并发用户在1～5秒钟内完成各类在线操作。
2．测试需求分析
性能调优的测试分析主要目的是要挖掘出可能造成系统瓶颈的因素，并为后面的测试用例设计提供保证。影响系统性能有很多种原因，在此应关注如下几个关键点:
●应用配置需求:例如应用整体框架、涉及到哪些第三方的组件、应用层与数据库层的接口、使用了什么数据库等。
●系统配置需求:例如用户客户端配置、客户端与服务器端的网络配置、应用服务器或数据库服务器操作系统等。
●用户使用情况需求:例如用户分布情况;哪些模块用户使用比较频繁;在用户操作的数据有哪些特点等。
这方面工作是非常繁杂的，而且要求测试人员具有挖掘可能造成系统瓶颈因素的洞察力和敏锐感，但是很多测试人员在接手测试之后，很快进入到测试用例设计阶段。实践证明，这样做往往都适得其反，要么工期延期，要么项目开发失败。这个过程在测试整体过程中是非常关键的一环。性能测试分析有个特点:它关注的是应用的整体，或者会仔细分析围绕着应用的各种外部因素，比如说它所涉及到的硬件、第三方软件，而不会深入到项目具体的内部。这是因为性能测试关注的是项目整体、是一种黑盒测试方法，我们关心一个项目的整体在运行时所暴露出来的问题。在此案例中我们获取到如表所示需求。
3．测试用例设计
此过程主要目的是设计出一些合理的场景去验证在需求分析阶段获得的可能影响性能的因素是否是造成系统瓶颈的因素。测试用例设计一般包括测试策略、测试案例、测试内容。 测试策略一般包括对比测试环境与真实的业务操作环境，真实业务操作环境又可能涉及局域网测试环境与机房测试环境等
测试案例主要是根据测试需求分析的结果制定出在测试执行时系统的执行方法，比如本案例中“5个人同时录入不同的新客户信息，以及具体的模拟步骤”。在测试案例设计时应注意如下几点:
●虚拟用户的操作步骤要尽量类似于真实用户的操作。 ●操作的数据要类同于真实用户实际使用数据，例如在案例中用户录入客户信息时，根据需求得到的结果，我们可以设计有3～4个虚拟用户在录入一些小客户的信息，1～2个虚拟用户在录入大客户的信息等。
●在案例设计时要充分考虑到需求中用户对模块的使用频率。使得在模拟时每个模块使用情况尽量地类似于真实环境。
测试内容一般包括并发性能测试、疲劳强度测试、大数据量测试以及系统资源监控等，我们在做性能调优测试时主要是做并发性能测试以及系统资源监控这些方面的工作。从对系统产生并发性能测试过程中监控系统中各种资源的变化，来判断导致性能瓶颈的原因。
4．脚本开发数据的准备以及测试执行与监控
测试执行与监控的主要目的是根据设计方案去验证系统是否存在瓶颈，给测试分析提供各种分析数据。此过程会与下面的“测试分析”过程不断进行重复执行，直至真正确定出系统瓶颈所在。
笔者认为，在此过程中如果有测试工具能够满足测试要求，那么应尽量使用测试工具，不要手工去开发测试程序，因为做企业项目往往时间紧张，而且测试工具毕竟是一个成熟的产品，在各方面都得到验证。使用工具将会缩短测试周期，而且现在市场上有很多成熟的测试软件。例如:Mercury的LoadRunner、IBM的Robot、Compuware的QALoad等。在这个案例中笔者使用的是Mercury的LoadRunner。关于一些技术细节笔者就不再赘述了，在这里主要提两
点。
一是数据的准备。数据准备一定要关注数据的质量和数量，不要出现一些不符合业务逻辑的废数据，并且数据量要满足测试运行的需要。例如测试需要100组数据，但是实际只准备了50组，从而导致测试执行结果出现大的偏差。 二是测试执行。除了正确按照设计的要求去设置各种参数之外，还要关注系统是否存在功能问题，这往往成为性能测试的“盲点”。原则上性能测试之前必须确保功能测试已经完备，但是任何事情都不绝对，所以一般做性能测试之初，都会模拟一个用户去运行设计的场景，主要是确保“测试脚本正确性”、“在设计的场景中应用系统不存在功能上的问题”。很多性能测试过程往往因为功能问题导致性能测试失败，或者是测试延期的现象。
5．测试分析
测试分析的主要目的是要根据测试执行获取到的数据去判断造成系统出现瓶颈的位置，挖掘造成系统瓶颈的真正原因。这个过程是技术含量最高的一环，因为在测试执行过程获取到的数据会涉及到各个方面，在这个案例中就涵盖了网络方面的知识、系统方面的知识、应用方面的知识等，测试人员需要从这些繁杂的数据中挑出异常，系统越大越复杂在这个方面对测试人员要求会更高。但是这里面也有一些技巧:
●在做测试分析时人员组成建议为:开发人员、系统人员、测试人员共同组成。这样会在技术上填补个人技术上的不足。实际每个项目涉及到的技术都可能各有不同，对于个人来说不可能每样都精通。
●反复比较一个类型的参数在不同时间的跳跃值，或者不同场景下同一个类型参数的变化。 ●在发现参数有异常变化时，不要轻易下结论，而是要尽量挖掘可能影响这个参数的其他参数值。在长期的测试过程中发现往往发现第一个所谓的瓶颈都是因为其他因素造成的。 ●在测试分析时使用较多的一种方式是排除法，根据开始获取到的信息大概能将问题定位在某一层面上。但具体在什么地方，就可以采取排除的方法去定位。
●尽量使用一些比较成熟的工具协助分析工作，这样将大大减轻工作负担。
●在确定出真正的性能瓶颈时，可以做一些小的测试模型去做验证，确定分析的正确性。 在本案例中，在测试结果经过各种比对之后，最后确定是数据库层上出现问题。但是问题究竟出现什么地方呢？笔者在分析过程中采用了许多排除法，比如更新索引的统计值、将数据库中的表从页级锁改为行级锁等，但是都效果甚微。 所以，我们回到上面看与数据库层相关的需求:
（1）因为业务需要，需要使用很多模糊查询。此类操作会进行表扫描。为了防止脏读，会向数据库申请表级意向锁。
（2）因为客户关系复杂，所以数据库设计的时候，存在多表关联。
（3）在应用开发时，我们使用了Hiberate这个组件，这些组件对于开发人员来说是一个黑盒，而且存在一些局限性:在更新记录时会同步更新所有相关联的表，即使关联表不需要更新;同步更新的记录操作会涵盖一个事物处理过程中，会产生大事务操作;无法利用SQL优化技术去优化他所产生出来的SQL语句。
研究之后发现:在进行模糊查询与大客户信息录入与修改的操作时，由hiberate这个组件产生的大事务SQL导致了数据库的互锁，是系统瓶颈所在。为了验证这一判断的正确性，笔者做了一个小的模型去验证。
假设库中有A、B、C三张表，现在有三个虚拟用户同时在上面进行操作:用户Vuser1需要查询客户信息，他只知道客户的姓氏，所以他采取了模糊查询;用户Vuser2正在修改一个客户信息，正准备保存;用户Vuser3正在查询客户办公信息，也需要模糊查询。
Vuser1操作先得到执行，在表扫描中出现表级意向锁;此时Vuser2进来需要修改A、B、C三
张表对应记录，并成功的锁定了B、C两张表对应的行（因为是行级锁），然后进行了修改，但是无法修改表A，所以Vuser2此时等待Vuser1释放锁;此时Vuser3进来了，需要查询C表，因为Vuser2并没有释放锁，此时Vuser3也处在等待状态。验证显示，在出现大数量的操作并且在多用户的操作下，此瓶颈将不断地暴露出来。
6．系统调优与验证
将获取的分析数据交付到开发组进行调优，经过调优后一般都需要再次进行验证，验证主要关注调优后的结果是否解决了所发现的系统性能瓶颈和是否产生了新的性能瓶颈。这方面的工作主要由开发人员来完成。在本案例中，去掉了Hiberate组件，改为由应用自身控制，尽量减少了大事物的出现概率，并同业务部门商议，降低了模糊查询操作的次数。在后来再做“性能评测”时确认系统达到了预期目标。
利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。
【一个性能测试实例】B/S体系结构
•被测系统
1)被测系统介绍
本系统应我国金融信息化发展设计，采用当今比较先进和流行的技术，是运行在城域网上的大型分布式应用系统。
本系统遵循J2EE规范，采用B/S体系结构进行设计和开发。业务主要分为交易业务和查询业务，查询业务采用J2EE规范，交易业务以J2EE体系架构为基础，进行进一步的处理，采用了TCP的四层结构。系统体系结构图如下： 图表1被测系统体系结构设计图
表示层：
运行在终端上。运行javaapplet程序，提供协议控制和用户界面，与系统最终用户实现直接交互，通过TCP/HTTP与前置系统通讯。向前置系统发送请求报文，并接收前置系统返回的回应报文。
商业逻辑层：
作为中间层实现核心业务逻辑服务。
交易应用服务：运行在交易主机上。在tuxedo中间件上运行业务处理程序，按交易规则处理前置机发来的交易指令，通过tuxedojolt与前置机连接，通过DB2CAPI与数据库连接。 交易前置服务和查询前置服务：运行在前置机上。交易前置服务运行服务程序接收终端请求报文并通过tuxedojolt客户端将其转发给交易主机，再通过轮询和同步反馈接收交易主机返回的报文，将其转发给业务终端；查询前置服务运行在weblogic应用服务器上并调用Jreport组件，通过JDBC完成对查询流指令的发送并接受数据库返回的结果给业务终端。
数据层：
运行在数据库主机上。负责整个系统中数据信息的存储、访问及其优化。运行DB2数据库服务程序。通过DB2CAPI与交易主机通讯，JDBC与查询前置服务通讯。 数据库主机和交易主机运行在交易中心城市，前置机运行在各个分中心城市，终端是各个城市参加交易的单位，整个系统覆盖城域网。 2)被测系统的性能要求和性能指标 金融系统是业务处理十分频繁、数据交换吞吐量很大的系统，业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观条件下，整个广域网系统必须在大业务量的情况下同时保持快速的实时响应能力，以保证整个业务系统的通畅运行。用户对此提出如下性能指标：
表格1用户要求性能指标表 下面我们会根据此系统和给定的性能指标来进行性能测试： •对被测系统进行性能测试
性能测试的目的是最大程度地模拟真实业务场景，来验证系统的性能指标，并发现可能存在的性能瓶颈。
1)对被测系统进行系统分析
我们可以看到本系统大体上由终端、前置机、交易主机、数据库主机节点组成。 在整个业务流程中，业务终端→前置机→交易主机→数据库主机形成了一个压力流串，每个节点在压力下能够正常工作是整个系统正常运转的基础。也就是说，如果其中任意一个节点在业务压力下发生了拥塞、处理不力等不正常情况，那整个系统都无法正常运转。 我们来看一下业务流程。
首先，从终端到前置机，终端产生业务报文发送至前置机，前置机上运行查询前置服务和交易前置服务，查询前置服务向下通过HTTP协议以WEB服务形式和终端连接，向上通过JDBC直接与数据库系统相连。交易前置服务向下通过基于TCP协议的socket连接和终端通讯，
向上通过tuxedojolt客户端和交易应用服务连接。交易应用服务进行业务逻辑计算，并操作数据库系统。 由以上分析，我们可以整理出整个系统的两条压力流程线来，之所以我们把其分为两条流程线，是因为交易前置服务和查询前置服务的工作原理完全不同，下与终端的连接，上与交易主机的连接也完全是的两个通路。 终端→交易前置机→交易主机→数据库系统 终端→查询前置机→数据库系统 下面我们先分析两条流程线，之后我们将再次综合分析，以考虑二者之间的相互影响作用。
第一条路线上主要运行的是登陆指令和交易指令信息。
当系统运作时，多个交易终端与交易前置服务建立socket连接，完成登陆，之后发送交易指令，造成对交易前置服务的压力。交易前置服务通过运行服务程序接收到交易指令，并检验其合法性，然后通过交易中间件tuxedo的客户端把业务的压力传递给交易主机进行处理。交易主机进行必要的金融计算和业务逻辑运行，得出反馈结果，生成消息，一方面顺原路返回到各个终端上去，一方面记录入数据库。
在本条流程线上的加压主要考验交易前置服务程序的socket多连接建立能力，tuxedo交易中间件的即时响应能力，交易主机的计算能力，以及DB2数据库的DML语句加锁机制。 第二条路线上主要运行的是查询指令信息。 查询指令产生时，通过http协议访问weblogic上的web服务器和应用服务器上的相应组件，以JDBC接口访问后台的DB2数据库，并把数据库返回的结果发送至终端界面。 在本条流程线上的加压主要验证weblogic处理能力，数据库中索引是否创建合理。 两条流程线相对，但又是互相依赖的。由于是对同一个数据库系统进行读操作和写操作，查询流程的结果依赖于交易流程数据的产生，交易流程的产生的数据又通过查询流程得到验证。在进行压力测试时，两者的协同会对数据库形成压力的冲击。 鉴于以上分析，结合用户性能指标，我们决定把本次性能测试分解为如下几个子测试来进行。 A:并发登陆测试：750个终端一分钟内并发登陆系统，并且响应时间在30秒之内。 B:业务负载测试
此下又有三个子测试。
交易流程测试：多个终端发起交易请求，逐渐加压，以达到300笔/秒的压力为限。
查询流程测试：多个终端进行查询，逐渐加压，以达到400笔/秒的压力为限。查询成功与否以所请求的web页面完全展现为标准。（查询响应能力其实和数据库中的数据量有关系，后来和用户进一步确认，基础数据为30万条） 综合测试：
在上面两种测试都通过的情况下，进行综合测试。
2)性能测试的执行过程，性能测试依照下面的步骤来进行：
第一步：测试脚本的开发
本次压力测试采用MI公司的loadrunner工具，脚本编辑和编译工作在VUGenerator(脚本作坊)中进行。
理想的脚本是对现实世界的业务行为进行了完全无误的模拟，这其实是不可能的。我们的目标是使模拟的误差在我们认可的范围之内，并能有方法加以控制。
针对并发登陆测试和交易流程测试，由于两者运行机理相同，都是终端调用socketclient，和交易前置的socketserver建立连接，将请求消息发送至交易前置机。我们考虑采用将此部分javasocket程序编入测试脚本程序，生成登陆和交易业务脚本，通过loadrunner来执行。这样做的好处是绕过终端IE界面复杂的处理逻辑，直接施压在前置机上（这种方式同时也
带来了偏差，在执行测试场景时通过其它方法得到了一定的弥补）。
脚本除了要实现与前置机的socket连接，业务发送等功能，还要建立用户信息数据池，设置检测点、异常退出点，为脚本执行后的结果统计和分析提供正确的依据。 交易业务脚本内容略。部分如下：
publicclassActions{/*登陆变量初始化*/ProtocolManagerprotocol;//ProtocolManager为实现socket连接的类ServiceNameservice;//ServiceName对服务端的信息进行了封装，包括IP地址和端口号。LoginMessagelogin；//LoginMessage为登陆时需要向服务器发送的消息，待服务器确认并返回回应消息时，登陆成功。
protocol=newProtocolManager();//创建ProtocolManager类的protocol对象 service=ServiceName.getInstance();//获得ServiceName的实例 login=newLoginMessage();//创建LoginMessage类的login对象 service.setIP(\"200.31.10.18\");//设置服务端的IP地址
service.setPort(17777);//设置服务端的端口号/*设置登陆消息*/
login.serUserName(lr.eval.string(“{loginName}”));//从数据池里读出用户名，设置在login成员变量里login.setPasswd(“1234”);//数据库中添加的用户密码都为1234/*发送登陆消息*/ protocol.login(login);//发送登陆消息
lr_start_transaction(\"trade\");//交易开始点
TradeMessagetrademessage;//生成交易消息/*设置交易消息*/ …………………………. ………………………….
/*发送交易消息*/ …………………………. ………………………….
if(sendfail)lr_end_transaction(\"trade\如果发送交易消息失败，交易结束，返回。/*循环回收主机返回的处理信息*/ ………………………… …………………………
if(recievefail)lr_end_transaction(\"trade\如果不能接收到主机处理回应消息，交易结束，返回。
if(recievesuccess)lr_end_transaction(\"trade\如果接收到主机成功处理的回应消息，交易结束，返回。 ………………………….. }
在上面的例子中，我们主要对每笔交易进行了transaction化。在交易开始时设置开始检测点，交易结束时设置结束检测点，并给loadrunner报出交易状态。实际的脚本中在回收交易响应消息时还进行了拆包，在应用层上对交易状态进行识别，并非例子中只在socket层加以判断。
针对查询流程测试，由于loadrunner工具支持基于http的web访问录制功能，我们将考虑采用以录制脚本为主，手工编写脚本为辅的方法，生成查询业务脚本，通过loadrunner来执行。由于查询脚本基本由录制生成http请求和应答，不同的压力测试工具录制会有差别，这里就不再写出查询脚本样例。
第二步：根据用户性能指标创立测试场景
在本次性能测试中，用户提出的性能指标不够细致和确切，通过对用户调查和实际业务分析，我们把性能指标的实现方式进行了明确的定位。
A:并发登陆测试场景
并发登陆750用户/分钟，登陆响应时间在30秒之内。仔细考虑一下，这里的并发登陆750用户/分钟指的是系统能够在1分钟内接受750个用户的登陆请求，而处理的效果如何则在交易终端体现，即登陆响应时间。基于这样的理解，我们把用户性能指标转化为如下的测试场景：
从第一秒钟开始，用loadrunner每秒钟登陆13个用户，并保持socket连接，直到1分钟结束，从终端向系统一共发送750个左右的用户登陆请求，系统在一分钟内建立了750个连接。在终端观察并统计登陆响应时间。如果系统不能响应持续增加的登陆请求或平均登陆响应时间大于30秒，并发登陆测试场景都不能算通过。 为了帮助用户更加深入了解系统的能力，我们对系统的瞬时并发能力进行测试，即测试系统所能承受的最大的瞬时并发用户登陆连接请求个数。这个场景通过loadrunner在登陆前设置同步点来实现，这个结果将结合上一个结果一同反映系统的登陆处理能力。 B:交易流程测试和查询流程测试：
在这里我们只对系统的业务负载能力做测试（并发处理能力在登陆测试中已经得到考证）。测试场景如下：
在loadrunner中，建立goal-orented的测试场景，以400笔/秒为目标，将调度权交给loadrunner来试图达到这个指标。 C:综合测试：
交易流程测试和查询流程测试同时进行。
以上的测试场景要求均可在loadrunner中的Controller进行设置完成。 测试场景的创建之后，我们的测试任务更加具体化和清晰化。
第三步：运行测试场景，同步监测被测系统性能行为
在loadrunner中的controller中开启unix系统资源计数器，weblogic计数器，DB2计数器，检测系统资源消耗情况，并最终和测试结果数据合并，成为分析图表。
测试结果可在测试执行完毕后，通过loadrunner工具中的Analysis（分析器）获得。 A:并发登陆测试
依照设计好的测试场景，用loadrunner工具在一分钟内渐增向系统发送登陆请求。分别进行三次，结果如下
表格2登陆测试结果数据表
注：这里的登陆成功用户指的是系统接受了登陆请求，并建立了连接。平均响应时间在登陆脚本里设置检测点，由loadrunner工具自动获得。 考察系统的瞬时并发处理能力：在完成上一步测试的前提下，逐步增加瞬时并发登陆用户数，直到系统极限。 测试执行结果如下：
表格3瞬时并发登陆测试结果数据表
B:负载测试
交易流程测试：
测试结果如下：
对于通过网络接口发送的批量业务请求，均在性能指标所指定的时间范围内得到请求成功的反馈消息，说明主机已经处理成功。
在通过网络接口发送业务请求的同时，开启IE，通过实际终端界面进行登陆和交易，系统响应时间延长，界面显示和刷新明显变慢，到业务量高峰时期，界面已经不能显示任何信息，处于不可工作的状态。
需求说明的是系统正常工作时，每个界面终端不仅应该能够展示己方的交易信息，还要展示其他交易单位的交易信息和系统信息。因此当交易量大的时候，界面需要展示的信息量是巨大的，这本身对终端界面是一个性能考验。
查询流程测试：
本流程测试在交易流程测试之后进行,以利用其生成的数据。 测试结果基本满足性能指标。
综合测试
由于交易流程测试的未通过，本测试已经不能执行。
第四步：测试结果分析及性能评价
A:并发测试结果分析
根据上述的并发测试响应时间表，我们可以得出以下的结论： 被测系统在一分钟内并不能接受750个用户的登陆请求，其可接受的登陆请求用户数大概为490个左右。在这样的条件下，登陆响应时间在用户要求范围之内。 被测系统的瞬时并发处理能力约为122个用户。 B:交易流程测试结果分析及性能评价 根据交易流程测试结果可知，通过脚本程序进行业务行为，发送业务请求消息到回收主机处理回应消息，这段时间系统是顺畅的，反应也是迅速的，但是在终端界面却不能即时展现消息。这说明信息的回馈通路在终端界面出现了性能瓶颈。当界面需要在短时间内展示大量交易信息时，已经不能承受负荷。这与终端采用javaapplet技术有关。 C:查询流程测试结果分析
查询流程基本符合性能指标。 需要说明的是，实际中，以上每个场景的测试都执行了多次，中间件参数进行了多次的调优。从以上测试的结果分析也可以看出，我们的性能测试瓶颈不是出现在中间件产品上，而是在自身开发的程序上。 •总结
由以上的实例过程我们可以看出性能测试基本由以下几个步骤进行
系统分析
将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里，要分析被测系统结构，
结合性能指标，制定具体的性能测试实施方案。这要求测试人员对被测系统结构和实施业务的全面掌握。
2.建立虚拟用户脚本
将业务流程转化为测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。在这一步骤里，要将各类被测业务流程从头至尾进行确认和记录，弄清这些交易过程可以帮助分析到每步操作的细节和时间，并能精确地转化为脚本。此过程类似制造一个能够模仿人的行为和动作的机器人过程。这个步骤非常重要，在这里将现实世界中的单个用户行为比较精确地转化为计算机程序语言。如果对现实世界的行为模仿失真，不能反映真实世界，性能测试的有效性和必要性也就失去了意义。 3.根据用户性能指标创建测试场景
根据真实业务场景，将单个用户的行为进行复制和控制，转化为多个用户的行为。在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到交易量，并发时序等参数的设置。这好比是指挥脚本运行的司令部。这个步骤十分关键，往往需要结合用户性能指标进行细致地分析。
4.运行测试场景，同步监测应用性能 在性能测试运行中，实时监测能让测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测：客户端，网络，web服务器，应用服务器，数据库和所有服务器硬件。实时监测可以在测试执行中及早发现性能瓶颈。 5.性能测试的结果分析和性能评价
结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。 在整个性能测试过程中，自动化测试工具的选择只能影响性能测试执行的复杂程度，简便一些或繁杂一些；但人的分析和思考却会直接导致性能测试的成败。所以本篇着重于对性能测试思路的整理。测试工具的介绍可以参看有关压力测试工具的资料。
注1：在本次性能测试案例中，还涉及到健壮性测试和可恢复性测试，限于篇幅，只介绍了并发测试和负载测试。
注2：loadrunner脚本样例并非实际运行脚本，只是为了表示其流程。
【理发店模型】
在我们的这个理发店中，我们事先做了如下的假设： 1.理发店共有3名理发师；
2.每位理发师剪一个发的时间都是1小时；
3.我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。 通过上面的假设我们不难想象出下面的场景：
1.当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；
2.当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者
打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；
3.很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时； 从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。
当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。
不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时图舴?小时。
通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。
在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。 我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图^_^
这张图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（ResponseTime）。图中坐标轴的横轴从左到右表现了并发用户数（NumberofConcurrentUsers）的不断增长。
在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。
根据这种性能表现，图中划分了三个区域，分别是LightLoad（较轻的压力）、HeavyLoad（较重的压力）和BuckleZone（用户无法忍受并放弃请求）。在LightLoad和HeavyLoad两个区域交界处的并发用户数，我们称为“最佳并发用户数（TheOptimumNumberofConcurrentUsers）”，而HeavyLoad和BuckleZone两个区域交界处的并发用户数则称为“最大并发用户数（TheMaximumNumberofConcurrentUsers）”。
当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。
对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和
工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。 当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。 进一步理解“最佳并发用户数”和“最大并发用户数”
对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会“此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该保证最佳并发用户数要大于系统的平均负载。
要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么^_^
而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：
1.当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；
2.在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。
对于一个系统来说，我们应该确保系统的最大并发用户数要大于系统需要承受的峰值负载。 如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。 理发店模型的进一步扩展
这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了^_^
扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。
扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。
扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。
扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。
扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改
变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。
因篇幅问题不能全部显示，请点此查看更多更全内容