软件性能测试结果分析总结

平均响应时间：在互联网上对于用户响应时间，有一个普遍的标准。2/5/10秒原则。

　　也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力”的用户体验。在5秒之内响应客户被认为“比较不错”的用户体验，在10秒内给用户响应被认为“糟糕”的用户体验。如果超过10秒还没有得到响应，那么大多用户会认为这次请求是失败的。

定义：指的是客户发出请求到得到响应的整个过程的时间。在某些工具中，请求响应时间通常会被称为“TTLB”(Time to laster byte) ,意思是从发起一个请求开始，到客户端收到最后一个字节的响应所耗费的时间。

错误状态情况分析：常用的HTTP状态代码如下：

400 无法解析此请求。

401.1 未经授权：访问由于凭据无效被拒绝。

401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。

401.3 未经授权：访问由于 ACL 对所请求资源的设置被拒绝。

401.4 未经授权：Web 服务器上安装的筛选器授权失败。

401.5 未经授权：ISAPI/CGI 应用程序授权失败。

401.7 未经授权：由于 Web 服务器上的 URL 授权策略而拒绝访问。

403 禁止访问：访问被拒绝。

403.1 禁止访问：执行访问被拒绝。

403.2 禁止访问：读取访问被拒绝。

403.3 禁止访问：写入访问被拒绝。

403.4 禁止访问：需要使用 SSL 查看该资源。

403.5 禁止访问：需要使用 SSL 128 查看该资源。

403.6 禁止访问：客户端的 IP 地址被拒绝。

403.7 禁止访问：需要 SSL 客户端证书。

403.8 禁止访问：客户端的 DNS 名称被拒绝。

403.9 禁止访问：太多客户端试图连接到 Web 服务器。

403.10 禁止访问：Web 服务器配置为拒绝执行访问。

403.11 禁止访问：密码已更改。

403.12 禁止访问：服务器证书映射器拒绝了客户端证书访问。

403.13 禁止访问：客户端证书已在 Web 服务器上吊销。

403.14 禁止访问：在 Web 服务器上已拒绝目录列表。

403.15 禁止访问：Web 服务器已超过客户端访问许可证限制。

403.16 禁止访问：客户端证书格式错误或未被 Web 服务器信任。

403.17 禁止访问：客户端证书已经到期或者尚未生效。

403.18 禁止访问：无法在当前应用程序池中执行请求的 URL。

403.19 禁止访问：无法在该应用程序池中为客户端执行 CGI。

403.20 禁止访问：Passport 登录失败。

404 找不到文件或目录。

404.1 文件或目录未找到：网站无法在所请求的端口访问。

需要注意的是404.1错误只会出现在具有多个IP地址的计算机上。如果在特定IP地址/端口组合上收到客户端请求，而且没有将IP地址配置为在该特定的端口上侦听，则IIS返回 404.1 HTTP错误。例如，如果一台计算机有两个IP地址，而只将其中一个IP地址配置为在端口80上侦听，则另一个IP地址从端口80收到的任何请求都将导致IIS返回404.1错误。只应在此服务级别设置该错误，因为只有当服务器上使用多个IP地址时才会将它返回给客户端。

404.2 文件或目录无法找到：锁定策略禁止该请求。

404.3 文件或目录无法找到：MIME 映射策略禁止该请求。

405 用于访问该页的 HTTP 动作未被许可。

406 客户端浏览器不接受所请求页面的 MIME 类型。

407 Web 服务器需要初始的代理验证。

410 文件已删除。

412 客户端设置的前提条件在 Web 服务器上评估时失败。

414 请求 URL 太大，因此在 Web 服务器上不接受该 URL。

500 服务器内部错误。

500.11 服务器错误：Web 服务器上的应用程序正在关闭。

500.12 服务器错误：Web 服务器上的应用程序正在重新启动。

500.13 服务器错误：Web 服务器太忙。

500.14 服务器错误：服务器上的无效应用程序配置。

500.15 服务器错误：不允许直接请求 GLOBAL.ASA。

500.16 服务器错误：UNC 授权凭据不正确。

500.17 服务器错误：URL 授权存储无法找到。

500.18 服务器错误：URL 授权存储无法打开。

500.19 服务器错误：该文件的数据在配置数据库中配置不正确。

500.20 服务器错误：URL 授权域无法找到。

500 100 内部服务器错误：ASP 错误。

501 标题值指定的配置没有执行。

502 Web 服务器作为网关或代理服务器时收到无效的响应。

每秒点击数：“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。图显示的是“Hits per Second”与“Average Throughput(bytes/second)”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请求，并能够返回结果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。如果“Hits per Second”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。

说明：具体结果根据实际数据情况分析。

对于本次测试来说，“Hits per Second”与“Average Throughput (bytes/second)”都是正常的，而且整体表现还是不错的。

一般情况下，这两种指标用于性能调优，比如给定了几个条件，去检测另外一个条件，用这两个指标衡量，往往起到很好的效果。比如要比较某两种硬件平台的优劣，就可以使用相同的配置方法部署软件系统，然后使用相同的脚本、场景设计、统计方法去分析，最终得出一个较优的配置。

吞吐量：1. 用户协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用户协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率，事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

2. 用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈所在位置。

备注说明：对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系。

点击率：点击率可以看作是TPS的一种特定情况。点击率更能体现用户端对服务器的压力。TPS更能体现服务器对客户请求的处理能力。

每秒钟用户向web服务器提交的HTTP请求数。这个指标是web 应用特有的一个指标；web应用是“请求-响应”模式，用户发一个申请，服务器就要处理一次，所以点击是web应用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。容易看出，点击率越大。对服务器的压力也越大，点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

备注说明：需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为一次“单击”操作中，客户端可能向服务器发现多个HTTP请求。

吞吐率：　单位时间内网络上传输的数据量，也可以指单位时间内处理客户请求数量。它是衡量网络性能的重要指标，通常情况下，吞吐率用“字节数/秒”来衡量，当然，你可以用“请求数/秒”和“页面数/秒”来衡量。

备注说明：不管是一个请求还是一个页面，它的本质都是在网络上传输的数据，那么来表示数据的单位就是字节数。

　　不过以不同的方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设置、服务器架构、应用服务器制约；以请求数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。

但是从业务的角度看，吞吐率也可以用“业务数/小时或天”、“访问人数/小时或天”、“页面访问量/小时或天”来衡量。例如，在银行卡审批系统中，可以用“千件/小时”来衡量系统的业务处理能力。那么，从用户的角度，一个表单提交可以得到一次审批。又引出来一个概念---事务。

TPS: 每秒钟系统能够处理事务或交易的数量，它是衡量系统处理能力的重要指标。Trasaction per second也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，最终利用这些信息来估计得分。客户机使用加权协函数平均方法来计算客户机的得分，测试软件就是利用客户机的这些信息使用加权协函数平均方法来计算服务器端的整体TPS得分。一般来说系统的TPS取决于系统事务最低处理能力的模块的TPS，经验值10-100

经验分析：

1、TPS标准差/TPS Average>8%,或者<2%则系统存在性能瓶颈

2、当增大系统的压力(或增加并发用户数)时，吞吐率和TPS的变化曲线呈正比变化，则系统基本稳定。

3、若压力增大时，吞吐率的曲线增加到一定程度后出现变化缓慢，甚至平坦，同时TPS也趋于平坦，查看系统资源使用，如果资源使用率比较高，则说明服务器硬件资源存在问题，需要拓展硬件或者优化应用。反之，则说明服务器硬件资源不存在问题，查看网络流量，估计网络带宽存在问题。

4、点击率/TPS曲线出现变化缓慢或者平坦,很可能是服务器响应时间增加，观察服务器资源使用情况，确定是否是服务器问题或者应用问题

5. 　一个系统吞吐量通常由ＱＰＳ（ＴＰＳ）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。

         性能测试网站评测标准：

6．经验分析测试数据对比：

     1.用户数与相应时间对比

   2.用户数与CPU占用对比

   3.用户数与吞吐量对比

   4.

第二篇：软件性能测试原理及性能测试实例分析

软件性能测试原理及性能测试实例分析

作者：网络转载 发表于：[ 2011-10-28 11:12:54 ]

软件测试是保证软件质量的重要手段，也是软件过程中一个必不可少的环节。而性能测试则隶属于软件测试中的系统级测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。

性能测试的含义

目前对性能测试没有明确的定义，一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，批量业务处理能力等。

性能测试的分解

在性能测试的执行中，可以根据具体的性能指标，分解为几种测试，根据其关系，可以在不同的时间和空间内执行。这些子测试通常包括以下几种：

并发测试：验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。 负载测试：验证系统的负载工作能力。系统配置不变的条件下，在一定时间内，服务器端在高负载情况下的性能行为表现。这里的负载可以是用户数，交易数，事务数等。

配置测试：核实在操作条件保持不变的情况下，系统在使用不同配置时其性能行为的可接受性。

健壮性测试：核实被测系统的性能行为在异常或极端条件之下的可接受性。这里的异常或极端条件指的是资源过少，用户数过多，突发故障等。

随着软件系统的规模日益庞大，结构日趋复杂，对软件系统的性能测试已经成为必须和趋势。尤其大型的分布式软件系统更要在正式运行前进行性能测试，因为这样的系统在投入生产之后，往往要接受大批量的业务量，这对应用程序本身，操作系统， 中心数据库服务器，中间件服务器，网络设备的承受力都是一个严峻的考验。在其中任意一个环节出现的问题都可能给用户带来巨大的商业损失。预见软件系统的并发承受能力以避免商业风险，这是在软件测试阶段就应该解决的。例如中国人民银行的现代化支付系统和上海外汇交易中心的本币交易系统都在投入生产之前进行了多轮的第三方性能测试，起到了很好的作用。 下面我就介绍一个性能测试案例。

一个性能测试实例

被测系统

1)被测系统介绍

本系统应我国金融信息化发展设计，采用当今比较先进和流行的技术，是运行在城域网上的大型分布式应用系统。

本系统遵循J2EE规范，采用B/S体系结构进行设计和开发。业务主要分为交易业务和查询业务，查询业务采用J2EE规范，交易业务以J2EE体系架构为基础，进行进一步的处理，采用了TCP的四层结构。

表示层：

运行在终端上。运行java applet程序，提供协议控制和用户界面，与系统最终用户实现直接交互，通过TCP/HTTP与前置系统通讯。向前置系统发送请求报文，并接收前置系统返回的回应报文。

商业逻辑层：

作为中间层实现核心业务逻辑服务。

交易应用服务：运行在交易主机上。在tuxedo中间件上运行业务处理程序，按交易规则处理前置机发来的交易指令，通过tuxedo jolt与前置机连接，通过DB2 C API与数据库连接。

交易前置服务和查询前置服务：运行在前置机上。交易前置服务运行服务程序接收终端请求报文并通过tuxedo jolt客户端将其转发给交易主机，再通过轮询和同步反馈接收交易主机返回的报文，将其转发给业务终端；查询前置服务运行在weblogic应用服务器上并调用Jreport组件，通过JDBC完成对查询流指令的发送并接受数据库返回的结果给业务终端。

数据层：

运行在数据库主机上。负责整个系统中数据信息的存储、访问及其优化。运行DB2数据库服务程序。通过DB2 C API与交易主机通讯，JDBC与查询前置服务通讯。

数据库主机和交易主机运行在交易中心城市，前置机运行在各个分中心城市，终端是各个城市参加交易的单位，整个系统覆盖城域网。

2) 被测系统的性能要求和性能指标

金融系统是业务处理十分频繁、数据交换吞吐量很大的系统，业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观的条件下，整个广域网系统必须在大业务量的情况下同时保持快速的实时响应能力，以保证整个业务系统的畅通运行。 下面我们会根据此系统和给定的性能指标来进行性能测试：

对被测系统进行性能测试

性能测试的目的是最大程度大模拟真实业务场景，来验证系统的性能指标，并发现可能存在的性能瓶颈。

1）对被测系统进行系统分析

我们可以看到本系统大体上有终端、前置机、交易主机、数据库主机节点组成。

在整个业务流程中，业务终端—>前置机—>交易主机—>数据库主机形成了一个压力串，每个节点在压力下能够正常工作是整个系统正常运转的基础。也就是说，如果其中任意一个节点在业务压力下发生了拥塞、处理不力等不正常情况，那整个系统都无法正常运转。 首先，从终端到前置机，终端产生业务报文发送至前置机，前置机上运行查询前置服务和交易前置服务，查询前置服务向下通过HTTP协议以WEB服务形式和终端连接，向上通过JDBC直接与数据库系统相连。交易前置服务向下通过基于TCP协议的Socket连接和终端通讯，向上通过tuxedo jolt客户端和交易应用服务连接。交易应用服务器进行业务逻辑计算，并操作数据库系统。

由以上分析，我们可以整理出整个系统的两条压力流程线来，之所以我们把其分为两条流程线，是因为交易前置服务和查询前置服务的工作原理完全不同，下与终端的链接，上与交易主机的链接也完全是独立的两个通路。

终端→交易前置机→交易主机→数据库系统

终端→查询前置机→数据库系统

下面我们先独立分析两条流程线，之后我们将再次综合分析，以考虑二者之间的相互影响作用。

第一条路线上主要运行的是登陆指令和交易指令信息。

当系统运作时，多个交易终端与交易前置服务建立socket连接，完成登陆，之后发送交易指令，造成对交易前置服务的压力。交易前置服务通过运行服务程序接收到交易指令，并检验其合法性，然后通过交易中间件tuxedo的客户端把业务的压力传递给交易主机进行处理。交易主机进行必要的金融计算和业务逻辑运行，得出反馈结果，生成消息，一方面顺原路返回到各个终端上去，一方面记录入数据库。

2)性能测试的执行过程，性能测试依照下面的步骤来进行：

第一步：测试脚本的开发

本次压力测试采用MI公司的loadrunner工具，脚本编辑和编译工作在VU Generator(脚本作坊)中进行。

理想的脚本是对现实世界的业务行为进行了完全无误的模拟，这其实是不可能的。我们的目标是使模拟的误差在我们认可的范围之内，并能有方法加以控制。

针对并发登陆测试和交易流程测试，由于两者运行机理相同，都是终端调用socket client，和交易前置的socket server建立连接，将请求消息发送至交易前置机。我们考虑采用将此部分java socket程序编入测试脚本程序，生成登陆和交易业务脚本，通过loadrunner来执行。这样做的好处是绕过终端IE界面复杂的处理逻辑，直接施压在前置机上（这种方式同时也带来了偏差，在执行测试场景时通过其它方法得到了一定的弥补）。 脚本除了要实现与前置机的socket连接，业务发送等功能，还要建立用户信息数据池，设置检测点、异常退出点，为脚本执行后的结果统计和分析提供正确的依据。

交易业务脚本内容略。部分如下：

public class Actions {/*登陆变量初始化*/ProtocolManager

protocol;//ProtocolManager为实现socket连接的类 ServiceName service;

//ServiceName对服务端的信息进行了封装，包括IP地址和端口号。LoginMessage login；//LoginMessage为登陆时需要向服务器发送的消息，待服务器确认并返回回应消息时，登陆成功。protocol = new ProtocolManager(); //创建ProtocolManager类的protocol对象service = ServiceName.getInstance();//获得ServiceName的实例login=new LoginMessage();//创建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");//交易开始点TradeMessage trademessage;//生成交易消息/*设置交易消息*/

………………………….

………………………….

/*发送交易消息*/

………………………….

………………………….

if(sendfail)lr_end_transaction("trade"， LR_FAIL);//如果发送交易消息失败，交易结束，返回。/*循环回收主机返回的处理信息*/

…………………………

…………………………

if(recievefail)lr_end_transaction("trade"， LR_FAIL);//如果不能接收到主机处理回应消息，交易结束，返回。if(recievesuccess)lr_end_transaction("trade"， LR_PASS);//如果接收到主机成功处理的回应消息，交易结束，返回。

…………………………..

}

在上面的例子中，我们主要对每笔交易进行了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: 交易流程测试结果分析及性能评价

根据交易流程测试结果可知，通过脚本程序进行业务行为，发送业务请求消息到回收主机处理回应消息，这段时间系统是顺畅的，反应也是迅速的，但是在终端界面却不能即时展现消息。这说明信息的回馈通路在终端界面出现了性能瓶颈。当界面需要在短时间内展示大量交易信息时，已经不能承受负荷。这与终端采用java applet技术有关。

C: 查询流程测试结果分析

查询流程基本符合性能指标。

需要说明的是，实际中，以上每个场景的测试都执行了多次，中间件参数进行了多次的调优。从以上测试的结果分析也可以看出，我们的性能测试瓶颈不是出现在中间件产品上，而是在自身开发的程序上。

总结

由以上的实例过程我们可以看出性能测试基本由以下几个步骤进行

系统分析

将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里，要分析被测系统结构，结合性能指标，制定具体的性能测试实施方案。这要求测试人员对被测系统结构和实施业务的全面掌握。

2. 建立虚拟用户脚本

将业务流程转化为测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。在这一步骤里，要将各类被测业务流程从头至尾进行确认和记录，弄清这些交易过程可以帮助分析到每步操作的细节和时间，并能精确地转化为脚本。此过程类似制造一个能够模仿人的行为和动作的机器人过程。这个步骤非常重要，在这里将现实世界中的单个用户行为比较精确地转化为计算机程序语言。如果对现实世界的行为模仿失真，不能反映真实世界，性能测试的有效性和必要性也就失去了意义。

3. 根据用户性能指标创建测试场景

根据真实业务场景，将单个用户的行为进行复制和控制，转化为多个用户的行为。在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到交易量，并发时序等参数的设置。这好比是指挥脚本运行的司令部。这个步骤十分关键，往往需要结合用户性能指标进行细致地分析。

4. 运行测试场景，同步监测应用性能

在性能测试运行中，实时监测能让测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测：客户端，网络，web服务器，应用服务器，数据库和所有服务器硬件。实时监测可以在测试执行中及早发现性能瓶颈。

5. 性能测试的结果分析和性能评价

结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。

在整个性能测试过程中，自动化测试工具的选择只能影响性能测试执行的复杂程度，简便一些或繁杂一些；但人的分析和思考却会直接导致性能测试的成败。所以本篇着重于对性能测试思路的整理。测试工具的介绍可以参看有关压力测试工具的资料。

注1：在本次性能测试案例中，还涉及到健壮性测试和可恢复性测试，限于篇幅，只介绍了并发测试和负载测试。

注2：loadrunner脚本样例并非实际运行脚本，只是为了表示其流程。

在本条流程线上的加压主要考验交易前置服务程序的socket多连接建立能力，tuxedo交易中间件的即时响应能力，交易主机的计算能力，以及DB2数据库的DML语句加锁机制。

第二条路线上主要运行的是查询指令信息。

查询指令产生时，通过http协议访问weblogic上的web服务器和应用服务器上的相应组件，以JDBC接口访问后台的DB2数据库，并把数据库返回的结果发送至终端界面。 在本条流程线上的加压主要验证weblogic处理能力，数据库中索引是否创建合理。 两条流程线相对独立，但又是互相依赖的。由于是对同一个数据库系统进行读操作和写操作，查询流程的结果依赖于交易流程数据的产生，交易流程的产生的数据又通过查询流程得到验证。在进行压力测试时，两者的协同会对数据库形成压力的冲击。

鉴于以上分析，结合用户性能指标，我们决定把本次性能测试分解为如下几个子测试来进行。

A: 并发登陆测试：750个终端一分钟内并发登陆系统，并且响应时间在30秒之内。 B: 业务负载测试

此下又有三个子测试。

交易流程测试：多个终端发起交易请求，逐渐加压，以达到300笔/秒的压力为限。 查询流程测试：多个终端进行查询，逐渐加压，以达到400笔/秒的压力为限。查询成功与否以所请求的web页面完全展现为标准。（查询响应能力其实和数据库中的数据量有关系，后来和用户进一步确认，基础数据为30万条）

综合测试：

在上面两种测试都通过的情况下，进行综合测试。