LoadRunner性能测试流程及测试标准（优秀范文5篇）

第一篇：LoadRunner性能测试流程及测试标准

loadRunner性能测试 1.什么是性能测试

软件的功能：对一个软件基本功能能够实现，比如：银行卡能够正常转账成功（用户数=1）软件的性能：要求软件性能更好，一般关注多用户的使用情况，软件的响应时间。响应时间例子：登录一个软件，点击“登录”按钮时，多久能够显示成功登录的页面。

性能问题: 1． 每秒平均浏览量：2200次/秒

浏览量（PV，Page View）：即页面访问量或点击量，用户每次刷新即被计算一次 购票申请：20万张/秒以上

自身设计浏览量100万次/小时 浏览量280次/秒

2.响应时间的358原则：

3秒之内，客户比较满意 5秒之内，客户可以接受 8秒之内，客户可以忍受 大于8秒，无法忍受

3.一般进行性能测试之前，要对系统尤其是数据库进行备份

负载测试是一种

正常 的测试（在正常测试的指标下测出最大的负载量）

指标或者某种资源达到某种指标，比如响应时间达到多少，比如CPU负载100%等

压力测试和负载测试二者的区别：

负载测试强调系统在正常工作情况下的性能指标

压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点

影响系统性能的主要因素

（1）硬件： CPU,内存，硬盘，网卡及其他网络设备【最好解决】（2）操作系统（3）网络

（4）中间件（又叫应用服务器），web服务器（5）数据库服务器（6）客户端

（7）变成语言，程序实现方式，算法【最难解决】

客户端=服务端（Web服务器）=应用服务器=数据库服务器

性能测试主要关心两个部分：web服务器和应用服务器。客户端向服务器发送请求

服务器端向客户端返回应答（响应response）

性能测试的常用术语： 并发（Concurrency）：所有用户在同一时刻（一个时间点，可以精确到毫秒级）做同一件事情或操作，一般针对同一类型的业务

例如：在信用卡审批业务中，一定数目的用户在同一时刻对已经完成的审批业务进行提交 做并发的测试就称为“并发测试”。【发测试不包含睡眠时间】 在线（OnLine）：多用户在一段时间内对系统执行操作【包含睡眠时间】

并发测试与在线测试对系统的压力不同，一般来讲并发测试的压力和在线测试的压力的比值是10:1。例如：200用户并发测试相当于2000用户在线测试。

并发测试一定是多用户。

请求响应时间

指从客户端发送一个请求开始计时，到客户端接到从服务器端返回的响应结果计时结束。在一些工具中，请求响应时间通常被称为TTLB 即“Time to Last Byte”，意思是从开始发送第一个请求开始，到客户端收到最后一个字节的响应为止所耗费的时间。请求响应时间的单位一般为“秒”或者“毫秒”

再复杂的响应时间都可以分为3段：请求的响应时间=客户端的响应时间+网络的响应时间+服务器的响应时间

一般测试放在内网里，带宽，网络不会成为瓶颈。只用分析客户端的响应问题和服务器的响应问题。一般客户端的响应很少有问题，一般只分析服务器响应问题即可。

事务响应时间：用户完成某个具体事务（如跨行取款事务）所需要的时间。事务可能包含多个请求。比如点击“登录”按钮，到登录进页面。

事务的响应时间和请求响应时间的区别？

一个事务包含一个或多个请求（一般，一个请求指的是一个http请求）。

点击率：

每秒钟用户向web服务器提交的http请求数。---点击率越大，对服务器的压力也越大

---注意：点击不是指鼠标的一次“单击”操作。因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP请求（比如跳转页面需要更新展示图片等）。

点击量的计算：假如单击“登录”按钮，请求一个页面登录后的欢迎页面中包含3个图片，则每个图片都需要重新发送一个http请求，所以，单击鼠标一次产生的http请求总数为4=1（登录请求）+3（图片请求）点击率=点击量/时间

吞吐量：

用户在任意给定一秒从服务器端获得的全部数据量，单位是字节 吞吐量/传输时间=吞吐率

吞吐率很重要，反应了服务器的处理速度和性能，也是衡量网络性能的重要指标。TPS（事务数/秒）

在性能测试过程中，要监控服务器系统的各项资源情况，比如：CPU，内存，磁盘及网络等情况。

吞吐率和点击率的区别：

吞吐率：指服务器每秒处理的数据量。反应了服务器的处理能力，吞吐率越大，服务器处理能力越强。

点击率：客户端每秒向服务器发送请求的数量。反应了服务器的压力，点击率越大，服务器的压力越大

吞吐率受点击率影响，也受服务器性能的限制。

完美的吞吐率是：在带宽充足的情况下，吞吐率随着点击率的增加而增加。

资源利用率

指对不同的资源系统的使用程度，包括web服务器，操作系统，数据库服务器，网络，硬件，是测试和分析瓶颈的主要参数

-如：服务器cpu利用率，磁盘利用率等

它是分析系统性能指标进而改善性能的主要依据，因此是web性能测试工作的重点。

性能测试的策略（即方法）：重点测试方法：基准测试，并发测试，综合场景测试，疲劳强度测试，极限测试，递增测试

基准测试：一般做的是单用户测试（Benchmark Testing）

----指测试环境确定以后，对业务模型中涉及的重要业务做单独的测试。

----目的是获取单用户执行时的各项性能指标，为多用户并发和综合场景等性能测试分析提供参考依据。

并发测试：就是多用户的并发测试某个测试点。并发测试对系统要求比较严格，因为要模拟一个瞬间压力。并且要忽略系统的睡眠时间（思考时间）。

递增测试：

A）指每隔一定时间段（如5秒，10秒）加载不同数目的虚拟用户执行测试点操作，对测试点进行递增用户压力加载测试。原因：所有用户（5000）共同登陆可能会导致系统压力过大，进而影响到后面关心的测试点（buy）的性能，导致关心的测试点结果不准确，所以采取递增，分散一下前面的压力，使系统关心的测试点能够正常的测试。（这里是递增着登陆）B）测试一个测试点（如：购票），先测试单用户，再测试20用户，40用户等情况，有利于分析，也称为递增测试。（这里是递增着全套测试）

综合场景测试【重难点】：

通过对系统结构和功能的分析，对用户的分布和使用频率的分析，来构造系统综合场景的测试模型，模拟不同用户执行不同操作。

如10%的用户执行浏览首页，50%的用户执行查询订单，40%的用户执行订购机票，最大限度地模拟系统的真实场景，使用户预知系统投入使用后的性能水平。没特别指明的话，一般都是指在线的。

Login不适合放在综合场景中运行。

综合场景：号称能最真实的模拟实际的生产环境。如测试时间为50分钟，则综合场景中的每个脚本都是在循环执行。所以综合场景中不宜加入login测试点，因为不能真实模拟实际的生产环境。

疲劳强度测试：是一种特殊的强度测试（压力测试）。指在一定的压力下（如：相同的用户数）长时间（疲劳）对系统进行测试，并监控服务器的各项资源情况。如：7x24小时,24小时（如移动电信银行的服务器）。测试其服务器的稳定性：指长时间的运行过程中，系统的各项资源及时间等指标表现是否正常。

内存泄露：系统的服务器内存都被占用，而没有释放。导致系统没有可用内存。

内存泄露测试：通过LR监控时查看具体的几项指标，或者通过其它的专门内存泄露检测工具测试。

数据容量测试：查看系统服务器能否实现大数量下使用情况，系统的各项资源表现情况。如：200G，或者3个T。

极限测试：也叫“摸高测试”，测试系统的极限，如系统最大能承受的用户数，吞吐量等。

虚拟用户：Virtual Users 控制台：Controller 分析工具：Analysis

LoadRunner的三大组件：

虚拟用户脚本生成器（Virtual User Generator）---Creat/Edit Scripts【Generator：生成器】 压力调度控制台（Controller）---Run Load Tests 压力结果分析器（Analysis）---Analyze Test Results

QTP（功能自动化的工具）和LR（性能测试工具）的区别： QTP关心的是功能方面，LR关心的是性能方面。

QTP关心界面的控件属性（对象，对象的属性，属性值等）等，LR关心的是客户端和服务器之间往来的数据包。

LR的工作原理：

录制时，LR记录客户端和服务器二者之间的所有对话（数据包），形成脚本，回放时，LR模拟真实的客户端，向服务器发送请求。并验证服务器的响应。

LR是怎么记录下数据包的：（1）基于局域网的广播原理。【这种用的很少】（2）基于一种嗅探原理sniffer。【目前在用的方式】

虚拟用户脚本生成器：是用来生成脚本的

LR的常用术语：

虚拟用户（Virtual User 【简称VU】）：在场景中，loadRUnner用VU代替实际用户。Vuser模拟实际用户执行操作。一个场景可以包含几十，几百甚至几千个Vuser。（每个虚拟用户是一个进程或者线程，一般用的是线程）

Vuser脚本（Virtual User Script）：用于描述VU在场景中执行的操作。（记录的客户端发送的请求。）

事物（Transaction）：为度量服务器的性能，需要定义事务。事务表示要度量的最终用户业务流程或操作。

为何要定义事务：因为脚本中将关心的操作（如购票）定义为一个事务，则结果报告中（analysis）就会返回事务的响应时间。不关心的操作就不需要定义成事务。

场景（Scenario）：场景是一种文件，用于根据性能要求定义在每一个测试回话运行期间发生的事件。模拟真实环境中，用户运行的情况。【将脚本放到控制台去运行（包括设置各种参数）】

综合场景：将不同的脚本，至少3个放到控制台去共同运行一段时间。具体定义见PPT。

测试注意：

----设置IE（清楚浏览器缓存）：进入工具Internet选项常规设置每次访问此页面时检查

----LR中修改参数：进入ControllerRunTime SettingTnternet Protocol Proxy，选择No Proxy。

Jojo /bean

LR基本测试流程：

制定性能测试计划（部分）创建测试脚本编译，运行测试脚本【VUG】创建场景运行，监控场景，收集数据【Con 控制台】生成测试报告，分析测试结果【analysis】

最好用英文命名

小技巧： 弹出结果

日志文件

Transaction 事务

将一个操作设置成事务的目的：获取操作的响应时间（在analysis报告里）

在带宽充足的情况下，完美的吞吐率应该随着点击率的升高而升高。反过来，当服务器压力过大服务器处理能力不足时，吞吐率会随着点击率的增高而保持恒定或者降低，那么点击率也会受到相应影响而变慢。

即吞吐率和点击率是相互影响的。

脚本生成器可以模拟1个用户，多用户一定要用控制台来实现。（控制台就是来生成管理多用户的。）

基准测试是单用户测试，可用脚本生成器（生成的调试结果是没有响应时间的），但是也还是需要控制台。因为结果要写到报告里。（结果生成器analysis得出单用户测试的结果，比如响应时间等等）

疲劳测试和综合场景测试的区别就是时间的长短，疲劳测试运行的时间会长一些。

只要业务逻辑不变（操作不变），则不需要重新调试脚本，回归测试中可以直接利用原来脚本。

调试脚本时请频繁保存副本，因为LR回退键效果不是很好。

脚本必须现在脚本生成器进行运行，执行通过将脚本放入控制台，在控制台执行完毕后生成结果报告

总的吞吐率

服务水平等级协议

报告中事务响应时间的标准方差值：越趋近于0，说明系统越稳定（每一项事务的响应时间非常相似）

90percent：表示90%的事务都可以在该响应时间内完成。代表一个大多数情况。

HTTP状态码： 200表示成功

4XX表示客户端的失败 5XX表示服务器的失败

当场景设定的duration时间结束时，所有的虚拟用户需要运行完当前的transaction以及action再结束。

基准测试执行方法

单用户执行脚本操作1分钟 单用户执行脚本操作5次

B/S脚本必须要有登陆，有退出（否则假退出其实链接还没断开，会影响测试结果）

Replay log：脚本执行日志 Recording log：录制时的日志

Generation log：所有客户端和服务器二者之间的对话

快捷键：

ctrl+G

Go to Line 跳到某一行

跳到对应的日志

基准测试：单用户测试。3.4 1.7 1.8 1.6 为了规避第一次测试的不准确性，则有两种测试方法：（1）设置循环5次（N次）

Run-time Setting 循环5次，或者持续运行1分钟。（取平均值）Run logic：循环次数----设置为5 Pacing：两次循环之间的步长值（时间间隔）----随机值2-4秒 Think time：ignore（忽略思考时间），因为对结果没什么影响

Pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值

基准测试单用户对服务器压力不大，一般可以ignore think time。

监控资源：监控服务器的资源

客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。

（2）持续运行1分钟

当duration和run_time setting中循环（run logic）都有值的话，duration的优先级比较高【二者循环的位置都为action】 Run logic：循环次数----设置为1

Pacing：步长值，为了更真实的模拟环境（断开连接，释放资源），一般选随机值 基准测试单用户对服务器压力不大，一般可以ignore think time。监控资源：监控服务器的资源

客户端的资源：自己随时把握一下，不要成为测试的瓶颈即可。

并发测试执行方法： 脚本添加集合点

在控制台设置并发策略

注意：refresh中有两个选择，看情况使用。

脚本和控制台的run-time setting都设置的话，哪个优先级高？控制台的优先级高！脚本中的run-time setting 何时使用？运行脚本的时候使用

并发测试有两个步骤：

1）脚本中加并发点（即集合点）

2）在控制台设置：5个虚拟用户（VU），可以设置递增（不设也可），设置并发策略。

Run-time Setting---忽略休息时间，因为需要瞬间压力。

第二篇：LoadRunner测试SQL语句性能

本次通过loadRunner录制SQLServer介绍一下如何测试一个sql语句或存储过程的执行性能。主要分如下几个步骤完成：

第一步、测试准备

第二步、配置ODBC数据源

第三步、录制SQL语句在Sql Server查询分析器中的运行过程

第四步、优化录制脚本，设置事务

第五步、改变查询数量级查看SQL语句的性能

第六步、在controller中运行脚本

下面开始具体的介绍：

测试准备阶段我们首先要确认测试数据库服务器：我们可以在本地安装SQL SERVER数据库服务端及客户端，也可以确定一台装好的SQL SERVER服务器。

接下来，准备测试数据：对数据库测试时我们要考虑的不是SQL语句是否能够正确执行，而是在某数量级的情况下SQL语句的执行效率及数据库服务的运行情况，所以我们分别准备不同数量级的测试数据，即根据实际的业务情况预估数据库中的记录数，在本次讲解中我们不考虑业务逻辑也不考虑数据表之间的关系，我们只建立一张表，并向此表中加入不同数量级的数据，如分别加入1000条、10000条、50000条、100000条数据查看某SQL语句的执行效率。在查询分析器中运行如下脚本：

--创建测试数据库

create database loadrunner_test;

use loadrunner_test

--创建测试数据表

create table test_table

(username varchar(50),sex int,age int,address varchar(100),post int)

--通过一段程序插入不同数量级的记录，具体的语法在这里就不多说了

declare@iint

set@i=0

while@i<1000//循环1000次，可以根据测试数据情况改变插入条数

begin

BEGIN TRAN T1

insert into test_table(username,sex,age,address,post)values('户瑞海'+cast(@i as varchar),@i-1,@i+1,'北京市和平里'+cast(@i as varchar)+'号',123456);

IF @@ERROR <> 0

begin

rollback;

select @@error

end

else

begin

commit;

set@i=@i+1

end

end

好了，执行完上述语句后，建立的数据表中已经有1000条记录了，下面进行第二步的操作，配置ODBC数据源，为了能让loadrunner能够通过ODBC协议连接到我们建立的SQL SERVER数据路，我们需要在本机上建立ODBC数据源，建立方法如下：

控制面板—性能和维护—管理工具—数据源（ODBC）--添加，在列表中选择SQL SERVER点击完成，根据向导输入数据源名称，链接的服务器，下一步，输入链接数据库的用户名和密码，更改链接的数据库，完成ODBC的配置，如果配置正确的话，在最后一步点击“测试数据源”，会弹出测试成功的提示。

配置好ODBC数据源后就要录制SQL语句在查询分析器中的执行过程了：

1、打开loadrunner，选择ODBC协议

2、在start recording中的application type 选择win32 application；program to record中录入SQL SERVER查询分析器的路径“..安装目录isqlw.exe”

3、开始录制，首先通过查询分析器登录SQL SERVER，在打开的查询分析器窗口中输入要测试的SQL语句，如“select * from test_table;”

4、在查询分析器中执行该语句，执行完成后，结束录制

好了，现在就可以看到loadrunner生成的脚本了（由于脚本过长，在这里就不粘贴了，有需要的朋友可以加我QQ，我把脚本发给你们），通过这些语句，我们可以看出，登录数据库的过程、执行SQL语句的过程。

接下来，我们来优化脚本，我们分别为数据库登录部分和执行SQL语句的部分加一个事物，在增加一个double的变量获取事务执行时间，简单内容如下：

Action()

{double trans_time;//定义一个double型变量用来保存事务执行时间

lr_start_transaction(“sqserver_login”);//设置登录事务的开始

lrd_init(&InitInfo, DBTypeVersion);//初始化链接（下面的都是loadrunner生成的脚本了，大家可以通过帮助查到每个函数的意思）

lrd_open_context(&Ctx1, LRD_DBTYPE_ODBC, 0, 0, 0);

lrd_db_option(Ctx1, OT_ODBC_OV_ODBC3, 0, 0);

lrd_alloc_connection(&Con1, LRD_DBTYPE_ODBC, Ctx1, 0 /*Unused*/, 0);

………………

trans_time=lr_get_transaction_duration(“sqserver_login”);//获得登录数据库的时间lr_output_message(“sqserver_login事务耗时 %f 秒”, trans_time);//输出该时间

lr_end_transaction(“sqserver_login”, LR_AUTO);//结束登录事务

lr_start_transaction(“start_select”);//开始查询事务

lrd_cancel(0, Csr2, 0 /*Unused*/, 0);

lrd_stmt(Csr2, “select * from test_table;rn”,-1, 1, 0 /*None*/, 0);//此句为执行的SQL lrd_bind_cols(Csr2, BCInfo_D42, 0);

lrd_fetch(Csr2,-10, 1, 0, PrintRow24, 0);

……………..trans_time=lr_get_transaction_duration(“start_select”);//获得该SQL的执行时间

lr_output_message(“start_select事务耗时 %f 秒”, trans_time);//输出该时间

lr_end_transaction(“start_select”, LR_AUTO);//结束查询事务

优化后，在执行上述脚本后，就可以得到登录到数据库的时间及运行select * from test_table这条语句的时间了，当然我们也可以根据实际情况对该条语句进行参数化，可以测试多条语句的执行时间，也可以将该语句改为调用存储过程的语句来测试存储过程的运行时间。

接下来把该脚本在controller中运行，设置虚拟用户数，设置集合点，这些操作我就不说了，但是值得注意的是，没有Mercury 授权的SQL SERVER用户license，在运行该脚本时回报错，提示“You do not have a license for this Vuser type.Please contact Mercury Interactive to renew your license.”我们公司穷啊买不起loadrunner，所以我也无法继续试验，希望有license朋友们监控一下运行结果！

最起码在VUGen中运行该脚本我们可以得到任意一个SQL语句及存储过程的执行时间，如果我们测试的B/S结构的程序，我们也可以通过HTML协议录制的脚本在CONTROLLER中监控SQL SERVER服务器的性能情况，这样两方面结合起来就可以对数据库性能做一个完整的监控了。

第三篇：LoadRunner测试总结

性能测试（并发负载压力）测试分析－简要篇

在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：

• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）• 查找瓶颈时按以下顺序，由易到难。

服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。• 分段排除法 很有效

分析的信息来源：

•1 根据场景运行过程中的错误提示信息

•2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：•Error: Failed to connect to server “10.10.10.30:8080”: [10060] Connection

•Error: timed out Error: Server “10.10.10.30” has shut down the connection prematurely

分析：

•A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

•B、应用服务没有死

（应用服务参数设置问题）

例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

•C、数据库的连接

（1、在应用服务的性能参数可能太小了

2、数据库启动的最大连接数（跟硬件的内存有关）)

2Error: Page download timeout(120 seconds)has expired

分析：可能是以下原因造成•A、应用服务参数设置太大导致服务器的瓶颈

•B、页面中图片太多

•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：

• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3．服务器资源监控指标：

内存：UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。Windows资源监控中，如果ProcessPrivate Bytes计数器和ProcessWorking Set计数器的值在长时间内持续升高，同时MemoryAvailable bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率;

内存不够出错(out of memory errors)

处理器：UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85%

合理使用的范围在60%至70%。Windows资源监控中，如果SystemProcessor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆:

很慢的响应时间(slow response time)

CPU空闲时间为零(zero percent idle CPU)

过高的用户占用CPU时间(high percent user CPU)

过高的系统占用CPU时间(high percent system CPU)

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization)

太长的磁盘等待队列(large disk queue length)

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)太高的物理I/O速率:large physical I/O rate(not sufficient in itself)

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加

SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率：

select(sum(pins-reloads))/sum(pins)from v$librarycache;

select(sum(gets-getmisses))/sum(gets)from v$rowcache;

自由内存：select * from v$sgastat where name=’free memory’;如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。缓冲区高速缓存命中率：

select name,value from v$sysstat where name in('db block gets’,'consistent gets','physical reads');

Hit Ratio = 1-(physical reads /(db block gets + consistent gets))如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = 'redo log space requests';如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1,(a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name='sorts(disk)' and b.name='sorts(memory)'

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

说明：

以上只是个人的体会和部分资料的整理，并不代表专家之言。算抛砖引玉，有不同看法和更深入的分析的，希望大家勇要发言，以推动我们国内的性能测试工作。

第四篇：材料性能试验相关标准及测试方法

材料力学性能试验标准及测试方法

1.拉伸实验

[1] 标准

金属拉伸试件按国标GB/T6397-1986《金属拉伸试验试样》[1] 标准ASTM D3039-76用于测定高模量纤维增强聚合物复合材料面内拉伸性能；ASTM D638用于测定试件的拉伸强度和拉伸模量[2]； 2.压缩试验

[1] 标准

压缩试件按国标GB/T7314-1987《金属压缩实验试样》[1] ASTM D3410-75(剪切荷载法测定带无支撑标准截面的聚合体母体复合材料压缩特性的试验方法)[3]。3.弯曲试验

[1] 标准

ASTM D7624用于测定聚合物基复合材料的弯曲刚度与强度性能[2]。

4.剪切试验

[1] 标准

ASTM D5379适用大部分的纤维增强型复合材料[2]。

5.层间断裂

[1] 标准

ASTM D5528和JIS K7086，仅适用于单向分层测试。其他的还未有相关标准[2]。6.冲击试验

[1] 标准

金属材料按照GB/T229-1994加工成V形缺口或U形缺口[1] 目前复合材料在冲击后的损伤性能表征主要是损伤阻抗(Damage Resistance)和损伤容限(Damage To tolerance)。

目前关于损伤阻抗和损伤容限的测试标准有ASTM D6264-98(04)和ASTM D7136 /D7136M-05标准。D6264-98用来测量纤维增强复合材料对集中准静态压痕力的损伤阻抗；D7136用来测量材料对落锤冲击试件的损伤阻抗[2]。7.疲劳试验

[1] 疲劳极限测试标准

单点试验按照航标HB5152-1980规定；升降试验法按照国标GB/T3075-1982和GB/T4337-1984[1]。

参考文献

[1] 金保森.材料力学实验.2005 [2] 郑锡涛.液体成形复合材料力学性能测试方法研究进展.2010 [3] JM 惠特尼.纤维增强复合材料试验力学.1990 [4] J.M.霍奇金森.先进纤维增强复合材料性能测试.2005

第五篇：喷漆性能测试

6.4 喷漆性能测试（样品数量：每种颜色6套外壳）

试验条件：物理测试需要在注塑完成，产品放置72小时以后进行，化学测试则需6天以后。喷涂干燥 硬化后应在常温下放置48小时以后再进行试验。

试验方法：

1）把滤纸放于酸性（PH=2.6）溶液中充分浸透；

2）用胶带将浸有酸性溶液的滤纸分别粘在两套喷涂样品表面，确保滤纸与样品喷漆 表面充分接触，将样品放入试验箱。

3）测试时间以试验箱达到所需温湿度条件时开始计算。在24小时与48小时分别取 出一套样品，揭下滤纸，并放置2小时后，检查样品表面喷涂。

检验标准：样品表面无变色、起气泡、起皮、脱落、褪色以及其他与测试前状态不一致的现象。

6.4.5 镜面划伤测试

测试环境：室温（20~25° C）；

测试目的：验证镜面耐硬物划伤性能的可靠性

样品数量：不少于2个

试验方法：将实验样品固定在划伤试验机上，接触部分为直径为1mm的碳化钨球，硬度为90.5～ 91.5，用载重（load）为500g的力在样品表面往复划伤50次，划线速度为3～4cm/秒，接触部分与被测面成90度角，对样品的X和Y轴两个轴向进行测试。每10次对镜面进行外观检查，并对镜面表面进行清洁。检验标准：镜面表面划伤宽度应不大于100μm（依靠目视分辨、参照缺陷限度样板）

6.4.6 紫外线照射测试

测试环境：50° C

测试目的：验证喷涂抗紫外线照射的可靠性

样品数量：不少于1套壳体

试验方法：在温度为50° C，紫外线为340W/mm2的光线下直射油漆表面48小时。

试验结束后 将手机外壳取出，在常温下冷却2小时后检查喷漆表面。

检验标准：印刷、电镀无褪色、变色、纹路、开裂、剥落以及与测试前不一致的现象。

6.4.7盐雾测试

测试环境：35° C

测试目的：测试样机抗盐雾腐蚀能力

试验方法：a.溶液含量：5%的氯化钠溶液b.将手机关机放在盐雾试验箱内，合上翻盖，样机用绳子悬挂起来，以免溶液喷洒 不均或有的表面喷不到。c.样机需要立即被放入测试箱。实验周期是48个小时。实验过程中样机不得被中途 取出，如果急需取出测试，要严格记录测试时间，该实验需向后延迟相同时间。d.取出样机，放置48小时进行常温干燥，对其进行外观检查。

检验标准：外观检查无异常：表面喷涂、丝印、电镀、装饰件、标牌等无脱落、起泡、腐蚀以及与测试前不一致的现象。

试验环境：温度20~25度，湿度65＋/-20% 6.4.1 耐磨测试测试环境：室温（20~25° C）；测试目的：喷涂/印刷等抗摩擦性能的可靠性 样品数量：不少于1套壳体

试验方法：将最终喷涂的手机外壳固定在RCA试验机上，用175g力队同一点进行摩擦试验。对于表面摩擦300cycles，侧面和侧棱摩擦150 Cycles。特殊形状的手机摩擦点的确定由测试工程师和设计工程师共同确定

检验标准：对于喷涂、电镀、IMD等，涂层不能脱落，不可露出底材质地；对于表面印刷类，印刷图案、字体不能出现缺损、不清晰现象。

6.4.2 附着力测试

测试环境：室温室温（20~25° C）；高低温箱

测试目的：喷涂附着力测试

样品数量：不少于1套壳体

试验方法：选最终喷涂的手机外壳表面，使用百格刀刻出25个1mm2方格，划线应深及底材；使用毛刷将划线处的喷漆粉屑清除干净；再用3M610号胶带纸完全粘贴在方格面，1分钟后迅 速以90度的角度撕下胶带，检查被测区域表面。

检验标准：有涂层脱落的方格数应不大于总方格数的3%；单个方格涂层脱落面积不大于单个方格总面积的50%。

6.4.3 硬度测试

测试环境：室温（20~25° C）；

测试目的：表面喷涂硬度的可靠性

样品数量：不少于1套壳体

试验方法：将铅笔芯削成圆柱形并在400目砂纸上磨平后，装在铅笔硬度测试仪上，以500g 的力度，铅笔与水平面的夹角为45度，在样品表面从不同方向划出30~50mm长的线条3~5条。对于喷漆表面的硬度标准为2H（三菱牌），500g的载荷；对于Lens表面的硬度标准为3H（三菱牌），500g的载荷；每划完一次都应将铅笔磨平。

检验标准：用橡皮擦去铅笔痕迹，目视喷漆、印刷、电镀、Lens表面无划痕。

6.4.4 汗液测试

测试环境：60° C，95%RH

测试目的：表面抗汗液腐蚀的能力

样机数量：不少于2套

注：部品由于使用场所、材质、色泽等有特殊要求时可以考虑采用其他标准。

7.2 整机状态下的可靠性试验

温度冲击测试（Thermal shock）

测试环境：低温箱：-40° C ；高温箱：+80° C

试验方法：将手机设置成关机状态放置于高温箱内持续30分钟后，在15秒内迅速移入低温箱并持续30分钟，为一个循环，共循环27次。实验结束将样机从温度冲击箱中取出，并在 室温下恢复2小时，进行外观、机械和电性能检查。

试验标准：手机各项功能正常；外观检验：壳体表面喷涂、丝印、电镀无气泡、褶皱、裂纹、起皮、脱落；装饰件无翘起、脱落以及其他与测试前状态不一致的现象。跌落试验（Drop Test）测试条件：1.5m高度，20mm大理石板。

试验方法：将手机处于开机状态，进行6个面的自由跌落实验，每个面的跌落次数为1次，跌 落之后进行外观、机械和电性能检查。对于翻盖手机，在跌翻盖一面时，应将一半样品合上翻盖跌，一半样品打开翻盖跌。

试验标准：手机各项功能正常；

外观检查：壳体表面无明显掉漆，无裂纹、破损、冲击痕以 及其他与测试前不一致的现象。振动试验（Vibration test）

测试条件：振幅：0.38mm；振频：10~30Hz；振幅：0.19mm；振频：30~55Hz；

试验方法：将手机开机放入振动箱。X、Y、Z三个轴向分别振动1个小时之后取出，然 后进行外观、机械和电性能检查。

试验标准：振动前5分钟内手机内存和设置没有丢失现象，后55分钟可以出现关机现象，手机各项功能正常，尤其是显示和SPL，外壳无严重损伤（如掉漆），内部元件无脱落。

湿热试验（Humidity test）

测试环境：60oC，95%RH

试验方法：将手机处于关机状态，放入温度实验箱内的架子上，持续60个小时之后 取出，恢复2小时，然后进行外观、机械和电性能检查。

试验标准：手机各项功能正常；外观检查：外观测试无异常（壳体、Lens表面无裂纹、气泡；Lens 无被腐蚀现象；金属、电镀壳体或装饰件无变色、腐蚀，以及无其他与测试前不一致的现象）。

高温/低温参数测试（Parametric Test）

测试环境：-10oC/55oC

试验方法：将手机处于开机状态，放入温度实验箱内的架子上。持续2个小时之后(与 环境温度平衡)，然后在此环境下进行电性能检查，检查项目见附表1。

试验标准：手机电性能指标满足要求，功能正常，表面喷涂、电镀无裂纹等。高温高湿参数测试（Parametric Test）

测试环境：+45oC，95%RH

试验方法：将手机处于开机状态，放入温度实验箱内的架子上。持续48个小时之 后，然后在此环境下进行电性能检查。

试验标准：手机电性能指标满足要求，功能正常；结构检查：装饰件、Logo及机壳 等无脱落，壳体卡钩无脱出、断裂，外壳无变形；

外观检查：壳体表面无明显掉漆，无裂纹、破损、冲击痕以及其他与测试前状态不一致现象。高温/低温功能测试（Functional test）

测试环境：-40oC/+70oC