测试人员需要掌握的IT“基本功”包括操作系统方面的一些基本知识，随着LINUX的普及，在未来IT行业里LINUX的应用将取代现在的window操作系统。

学习的主要目的：测试环境的搭建

学习内容包括：

Linux安装

网络配置

基本命令的使用

Shell脚本编写

常用软件安装、WEB服务器搭建、应用服务器搭建

Linux下的编程知识：Shell、C、Perl、Python、PHP等

有两种情况
第一种：

如果是同一个用例 单机达到本机硬件承受能力极限或者许可证数量的极限 可以分成多个负载生成器统一加压.

第二种：

如果是一个包含多用例的综合场景 可以用多个负载生成器加压 也可以单独在各测试机上独立执行单个用例，加压时间不一定同步，有可能需要看其他机器的测试结果来决定加压的力度和时机

    • 系统是否满足预期的性能要求
    • 作为对系统进行调优的参考
    • 系统的可扩展性
    • 用性能测试手段发现系统存在的问题
    • 提供部署方案的参考

    2  性能指标

    • 常用的性能指标如下：
    • CPU利用率
    • 内存占用率
    • 磁盘I/O
    • 响应时间

    3  影响性能的因素

    • 网络状况（隔离的网络环境）
    • 硬件设备（CPU数、内存大小、总线速度）
    • 系统/应用服务器/数据库配置
    • 数据库设计和数据库访问实现（SQL语句）
    • 系统架构（同步/异步）

    4  性能测试步骤

    • 分析性能需求（需求规格说明书）
    • 性能测试计划
    • 性能测试方案
    • 建立数据模型
    • 性能测试报告

    5  性能测试方案应包含的内容

    • 对软件系统架构的分析（了解输入、输出数据的类型、数据量）
    • 性能测试组网图（网络环境说明）
    • 硬件环境说明
    • 测试范围、目的与方法
    • 性能测试工具的选型
    • 测试的启动/退出条件
    • 测试场景详细说明
    • 测试执行及测试结果分析

    6  性能测试场景的选取

    • 分析性能测试需求
    • 选择关键场景
    • 分析输入、输出数据

    7  大数据量的产生

    • 在详细分析性能需求的基础上
    • 数据量尽量与实际情况一致

    8、性能测试经验

    • 测试开始前与产品/开发人员充分协商
    • 测试过程中与开发人员紧密合作
    • 测试工具：不要迷信LoadRunner
       1、针对特定系统的加压工具比LoadRunner更加实用
       2、 尽量考虑使用操作系统本身的命令来监测系统资源、完成性能测试
    • 对测试人员的要求：
       1、熟悉系统架构
       2、熟悉数据库
       3、熟悉操作系统

症状

WebLogic 应用程序性能问题的症状是什么？您看到的症状可以指导您在所有可能的问题中进行搜索。请准备一个笔记本并开始向人们调查。试着把对问题根本原因的推测和假设与系统行为的实际证据分离。下面是一个常见症状集的列表：

·        持续缓慢：应用程序一直特别慢。改变环境因素(负载、数据库连接数量)对整体响应时间的改变很小。

·        随着时间推进越来越慢：系统运行时间越长(负载相对均衡不变的情况下)，就变得越慢。有可能是(最后)达到了某个阈值，系统被锁定或者由于大量错误而崩溃。

·        随着负载增加越来越慢：每增加一个额外用户，应用程序就变得越慢。如果用户离开系统，系统就“冷却下来”，恢复正常。

·        零星的挂起或者异常错误：偶尔(可能由于负载或某些其它原因)，在页面无法完成或者出现追踪到异常和堆栈的错误页时，用户会看到挂起的情况。挂起的数量可能不同，但总是无法完全消除，甚至在强化(“burn in”) 期间之后也是如此。

·        可以预见的锁定：首先出现一些挂起或错误，然后加速出现，直到系统完全被锁定。通常这些问题可以通过“重新启动来管理”的方式解决。

·        突然混乱：系统一直运行正常，相当一段时间里(可能一个小时，也可能是三天)性能都还差强人意，但是“突然某个时候，根本没有任何原因的”，系统开始出现大量错误，或者被锁定。

为什么问题诊断如此复杂？

对于WebLogic 应用程序的某个具体应用模式来说，没有既定的公式可以用来推导出它的性能(在严格的实时工程当中，速度单调分析这类技术确实可以做这项工作，但是在本文里还是让我们忘记它吧)。网络上是否存在另外一个系统正在密集使用一个共享的后端服务，对于实际产生的性能有很大影响。性能也许还取决于JDBC 驱动程序版本和数据库的正确匹配。也许开发人员三年前写的一些代码恰巧在这个时候才出现特定类型的异常，而您急切需要的解决问题回馈，却恰恰包含在这个异常里。

从本质上说，典型业务系统的性能是由成千上万交互的变量和决策共同作用的结果。就像人体一样，有太多连锁着的部分和过程，所以很难理解系统的整体。因此我们进行了简化，并求助于拱形模式。

疾病

　　您看到的症状的根本原因是什么？它是初级流行性感冒或者是肺炎的开始吗？是应用程序内部的底层问题还是它所在的JVM 外部的问题？请参阅表1 中应用程序性能低下的一些最常见原因。

表1

测量关键的统计指标

　　当您负责诊断问题的时候，您应当能够跟踪关于您的WebLogic 应用程序健康情况的关键统计指标。您能测量什么？有什么工具可以提供帮助呢？

·        使用的全部内存：在不同级别上(JVM 堆栈，操作系统)，Java 堆栈profiler 对堆栈的正确使用提供了可见性；像top ,vmstat 以及Windows Perfmon 这样的工具在操作系统级别上为内存使用提供可见性。察看Java 堆栈的一个简单的聚合视图，请打开–verbose：gc 开关(如果在您的JVM 上可以使用的话)。

·        CPU 时间：合并(可以通过使用top 等方式得到)每个组件或每种方法。其中某些指标可以通过WebLogic 管理控制台得到。也可以通过Java profile 使用它们。

·        计时(a.k.a.“实” 时)：每事务，每组件，每方法；可以按统计平均值或单独的数据点查看。Java profiler 可以产生一些这样的数据，但是使用程序监控解决方案可能是您的最佳选择。

·        内部资源：分配的数量，使用的数量，等待的客户数量，获得资源的平均等待时间，使用资源平均消耗的时间，使用资源完成请求工作时使用的平均时间。应用程序服务器通常会给出这些数字的最小可视性。

·        外部资源：分配的数量，使用的数量，等待的客户数量，平均等待时间，加上对这些外部系统的直接测量(例如查看它能多快完成请求的工作)。不要忘记运行应用程序服务器的操作系统和硬件也是“外部资源”-例如，是否您使用了太多的进程或端口？可以用两种形式测试这些资源–从JVM 内部测试提供资源的桥接层，用外部资源本身的工具测量外部资源。

·        网络应用：带宽使用，延迟。虽然操作系统自带的工具(例如netstat)也有助于做这些工作，但是网络嗅探器设备可以深入了解这些信息。

·        系统状态：用线程清除，日志和跟踪文件，堆栈跟踪等等。或者在更深层次上，就像调试器中查看的那样使用变量的值。

实验工作

　　有的时候，在一次标杆运行中获得的数据，不足以揭示答案。那么找到答案的机会就在于您还有些有限的预算，可以运行试验或者做实验工作，来完成诊断。您可以运行什么类型的试验呢？您可以修改、观察什么变量呢？

·        尝试观察系统行为在一段时间上的变化。应用一个衡定的负载，并观察您的指标随时间发生的变化。您可能会看到某些趋势，短则一小时就可看到，长则二三天。例如，您可以看到内存使用随着时间而增长。随着使用的内存数量达到上限，JVM 花在搜索垃圾上的时间和操作系统花在分配内存页面上的时间开始减少用户事务的整体响应时间。当抛开GC 的时候，垃圾搜集的整个过程可能过长，从而造成执行中的事务超时和异常。现在可以开始查找资源泄漏或内存泄漏了。

·        尝试在系统上改变负载。采用三到四种工作负载(例如，10个，50个和100个用户)，并搜集每个负载的数据。分析一下您对这些负载的测量情况。例如，您可能发现，当您的账户登录servlet 的响应时间无论如何都会低于50 毫秒的时候，计算销售税的EJB 却随着用户数据的增长，速度呈线性下降。如果这个EJB 性能在负载下的差异能解释整体响应时间性能在负载下的增长，那么现在就是深入分析这个组件的时候了。谨记一定还要把负载恢复原状，并查看系统是否复原。

·        尝试把系统分成小单元，针对每个单元轮流进行压力测试。选择一个或多个坐标系对系统进行划分。主要的一个是系统面上的层：负载均衡器、Web 服务器、WebLogic Server，以及后端。其它示例包括用户账户，内部组件，事务类型，以及单独的页面。假设您选择了用户账户。在用户A 的账户下运行一些负载，然后再在用户B 的账户(应当非常不同)下运行某些负载；比较两次运行间不同的测量结果。或者，轮流选择您使用的后端系统，分别对使用每个后端系统比较重的应用程序组件进行压力测试。具体要选择哪个坐标进行划分，完全取决于您要证明或者否定哪个假设。下面是一些具体想法：
　　- 如果某个用户的登录看起来造成了问题，那么有可能是这个用户账户档案(例如，装入2,000 个订单的完整采购历史)，或者可能是他使用系统的方式(例如，页面访问的顺序，或者他用来查找某个文档的查询字符串的正确性)。
　　- 如果您使用的是一个集群系统，请尝试以单台机器为单位划分。尽管尽了最大努力，有的时候还会有一些机器没有安装最新的应用服务器或者操作系统补丁，这就会造成不同的性能特征。而且，还请注意负载均衡器，或者保姆进程，查看它们是否公平地分配了工作并跟踪了进入请求。

诊断：测试您的推测

　　在这个时候，您应当已经有了足够的信息，可以形成关于性能瓶颈原因的推测了(请参阅表1)。为了验证您的推测是否正确或者在多个备选的推测之间进行筛选，您需要分析更多的信息或者在系统上运行更多的标杆测试。这里是一些可以帮助您的指导意见：

·        区分糟糕的编码(或者是应用程序组件或者是桥接层)和瓶颈(内部的或外部的)，请查看整体的CPU 使用情况。如果它在负载下没变化，但是整体响应时间变化了，那么就是应用程序花费了它的大多数时间来等待。

·        仅仅是因为好像是外部资源的问题，不代表您就可以立刻把责任推到资源上。例如，分层或联网的问题，也能造成数据库看起来很慢，虽然实际上它并不慢。或者，更简单一点，您对数据库的请求可能是不合理的(每次用户登录的时候，都要进行三个表之间的200 万行记录合并)。应当一直把桥接层的响应时间(例如，JDBC 驱动器)和资源提供的时间或者工具提供的时间进行比较(例如，DBA Studio)。

·        结构化的图表有助于您理解系统内部的整体交互，但是不要忘记地图并不是领地。.编码错误或者对架构意图的误解，有可能使系统的实际行为与期望的行为不同。请相信性能工作提供的实际数据，而不要相信一个声称“每个用户事务将只会发布一个SQL 语句”这样的文档。

·        使用Occam 军刀。假设您有两个备选推测，一个是：在200 万行代码里，有一个编码糟糕的组件，直到上周这个组件才集成进来；另一个是JVM 的即时编译器生成了糟糕的机器码，破坏了这个变量的内存完整性。除非您有具体的数据来证实，否则(我已经看到了第二种情况发生)，请更详细地检查第一个假设。J2EE 系统确实容易出错，但是不要让这一点就妨碍您先测试一个更简单的假设。

·        日志文件中没有错误不代表不存在错误。有许多原因可以造成不在日志里写下异常；可能是因为程序员认为某件事“永远不会发生”，于是就排除了这个异常；也可能是因为某些组件可以使用故障恢复机制，所以就没有记录第一次故障。

示例诊断

　　让我们来实际研究一个示例。您的WebLogic 应用程序表现出在负载下越来越慢的症状。您加入的用户越多，系统越慢。一旦消除负载，系统就冷静下来，没有任何后遗症。您对这一主要症状进行测试，发现并得到图2 所示的以下结果(时间测量针对的是单一典型事务的端到端完成时间)。

表2

应用程序性能在负载下越来越慢

您形成了几个假设。也许这里的毛病是一个糟糕编码的组件，也许是后端系统的瓶颈。它可能是一个同步阻塞点。您怎样才能分清它们的不同呢？假设您还测试了应用程序服务器在负载运行期间的CPU整体使用情况，并得到了表3 所示的结果。

表3

问题看起来好像是“等待”瓶颈

现在看起来，系统不是CPU 密集型的，这就是说它的多数时间都花在等待上了。那么是它的内部(例如，同步交通阻塞)或外部(缓慢的数据库)的问题？好，让我们假设我们还稍微多搜集了一些数据，如表4 所示。

表4

问题是否出在一个缓慢的SQL 语句上呢？

现在看起来并不是内部等待数据库连接的瓶颈，相反，好像是JDBC 查询本身的问题。JDBC 查询不仅随整体事务时间的不同而不同，而且它糟糕的性能还解释了整体性能糟糕的原因。但是，我们还不能完全确定。您仍然还有三个主要的假设要排序：是否数据库本身慢？应用程序是否对数据库进行了不合理的请求？或者问题是不是出在应用程序和数据库之间的某个层上？您拿出数据库供应商专用的工具，从它的角度查看响应时间。假设您看到如表5 所示的数字。

表5

实际是数据库中的SQL 语句慢

如果您没有看到这条信息，那么您可能要返回JDBC 驱动程序，期待能够发现其中的某些同步问题(请记住，CPU 没有被抑制)。幸运的是，在这个案例里，您已经把具体问题的范围缩小到数据库查询上。找出查询请求是否足够合理，需要一些相关领域的知识，需要熟悉系统，但是在这个案例里，它也许就是发现查询把非索引字段和外键进行了比较。您和DBA 协作，它修改索引方案，让查询变得更快，而您则找到了您的药方。

结束语

　　诊断WebLogic J2EE 应用程序的性能瓶颈是一个艰苦的旅程。请随时保持清醒，把事实与推测分开，总是用实际的证据来确认您的推测。我希望给您带来了思考和实践问题的一些有用的想法的分类。就像调试，这仍然是一项不明确的艺术，但是深思熟虑会带您走出困境。祝您好运!

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：

　　1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。

　　2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。

　　3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。

　　4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

　　5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

　　6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

　　7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

　　8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

　　9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

　　10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

　　11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

　　12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

　　13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。

　　14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

　　15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

　　16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

　　17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。

　　18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*

　　19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。

　　20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.

一般情况下，测试要用到多个测试脚本和多台计算机。在运行时，用设计的套件来协调测试脚本的回放。这些测试套件向服务器施加模拟的工作负载。可以在本地计算机上运行测试套件。

一旦用TestManager创建了描述服务器行为基线的套件，就可以重复运行这些套件，然后用TestManager的报告生成工具分析测试结果。

Rational TestManager与性能测试

用TestManager做性能测试有助于在实际应用之前发现和改进性能问题。使用TestManager提供的工具可以鉴别，定位，分析性能瓶颈。

作为一个自动负载测试工具，TestManager模拟一个或者多个真是用户各种行为。TestManager用虚拟测试者代替用户向服务器施加负载。

因为TestManager允许在一个计算机上回放多个虚拟测试者的动作，所以可以在几台甚至一台计算机上模拟成百上千个虚拟测试者。

为什么用TestManager做性能测试

TestManager有很多用处，在解决以下性能测试问题时十分优秀：

TestManager环境

用TestManager可以在一个分布式环境下运行套件。这个环境是由一台本地计算机（用来协调测试执行和回放测试脚本）和多台代理计算机（可以没有，用来回放测试脚本）组成。

下面这张图描绘了典型的TestManager配置：

服务器可以运行各种操作系统，通过TCP/IP网络连接到本地计算机和代理计算机。

计划性能测试

测试服务器的性能，典型的做法是用许多虚拟测试者向服务器施加负载。目的是检查服务器在负载压力下是如何运行的。

需要回答的一些性能问题包括：

l         在正常情况下服务器支持多少个虚拟测试者

l         在正常条件下，服务器性能会不会在某个时候迅速下降

l         当超出正常范围时系统运行情况如何？在最坏情况下，系统性能是适当下降呢，还是完全崩溃？

l         在不同的硬件配置条件下系统运行情况如何？

下面讨论计划一个测试的主要步骤：

测试响应时间

用TestManager可以测量各种性能指示器。尽管分布式功能测试可以根据通过还是失败来测量正确性，但是通过性能测试可以测量时间。例如：

l         完成一个动作需要多长时间？

l         在很大的负载压力下服务器可以响应多快？

可以测量客户端响应时间或者服务器端响应时间。

设置性能测试的通过/失败标准

性能是主观的，需要设置性能是通过或者失败的标准。通过或者失败的标准通常是一个可以接受的响应时间的范围。例如，可以用下面这些值作为一个可以接受的响应时间：

l         对于100个虚拟测试者，90%的交互响应时间为5秒或者低于5秒。所有响应时间不能超过20秒。

l         对于500个虚拟测试者，80%的交互响应时间为10秒或者低于10秒。所有响应时间不能超过45秒。

确定性能需求

在计划性能测试时，需要确定测试所需要的硬件和软件。例如：

l         服务器端：数据库服务器、WEB服务器、其他服务器系统

l         客户端：Windows 2000，NT，98，95，or Me计算机、网络计算机、或者Macintosh或者UNIX工作站

l         用于访问的数据库

l         用于运行的应用

除此之外，要确定以下参数：

l         用来准确表示工作负载的测试数据库和其他测试文件的大小

l         为了防止I/O瓶颈，数据的分布情况

l         测试数据库时，主要的数据库参数设置

设计模拟真实的工作负载

性能测试要准确地镜像站点的工作负载。因此，必须确定站点的交互类型。

例如，用户是偶然查询和更新数据库呢，还是经常更新数据库？如果是经常更新数据库，那么这些更新是复杂的，还是简短的？

设计工作负载时，要考虑以下这些问题：

l         工作负载间隔––工作负载模型表示的时间段。例如，工作负载间隔可能是一个高峰小时，一天或者an end-of-the-month billing cycle。

l         测试变量––性能测试期间可以改变的因素。例如，为了检查在工作负载增加时，响应时间是如何下降的，需要设置不同数量的虚拟测试者来施加负载。最好一次只有一个变量发生改变。接着，如果在下一次测试时性能发生改变，就可以知道性能的改变是由哪个变量引起的。在创建一个套件时需要设置测试变量。

l         虚拟测试者类别––在性能测试中，我们可能需要根据虚拟测试者所执行的动作将它们分为几个组。对于每一个组，需要明确虚拟测试者的个数或者占总测试者的百分比。例如，20%的虚拟测试者清算账目，30%的虚拟测试者在做数据资料登记，50%的虚拟测试者在销售。

在一个套件中可以创建用户组。然而，在计划和测试相关的测试脚本时必须记住这些用户组。测试脚本应该能够准确的反映真实用户组的动作。

l         用户工作情况––虚拟测试者执行的动作集合和执行动作的频率。虚拟测试者的动作应该尽可能的模拟用户实际的工作。例如，如果销售组的用户访问数据库比其他两组多70%，那么在工作负载中应该反映这一情况。

l         用户特征––确定虚拟测试者在执行一个交互之前会暂停多长时间，确定一个交互执行的频率，确定一个交互可以连续执行多少次。因为这些值直接影响系统的整体性能，所以准确的建模真实用户特征是很重要的。例如，一个思考需要五秒，每分钟输入30个单词的用户给系统施加的负载比一个思考需要一秒，每分钟输入60个单词的用户给系统施加的负载小。用延迟和思考时间来建模虚拟测试者的特征。更多关于延迟的信息，查看263页“插入一个延迟”。更多关于思考时间的信息，查看Robot手册。

当设计一个工作负载模型时，需要考虑以上因素以确保准确的测试环境。定义的测试目标越明确，达到目标就越快。

实施性能测试

一旦确定了通过和失败的标准，硬件和软件需求和工作负载模型，就可以创建测试脚本，建立测试了。在这个过程中需要考虑的问题是：

l         中止条件––如果一个虚拟测试者运行失败，测试应该停止还是继续？如果大量的虚拟测试者中有一些失败，一般情况下测试可以继续。但是，如果一个虚拟测试者执行基础动作（例如，建立数据库）失败，测试应该停止。

在套件中要设置中止条件。更多关于设置中止条件的信息，查看99页“控制套件中止方式”

l         稳定的工作负载––测试只有在所有的虚拟测试者连接后才开始运行，还是应该立刻开始运行？如果要测量虚拟测试者的响应时间，就需要在所有的测试者都连接之后再开始实际的测试。为了做性能报告需要定义一个稳定的工作负载。关于更多的信息，查看321页“关于稳定负载的报告”

l         将要测试的应用––测试所有的应用是不划算的。在对整体性能影响很小的应用进行测试时，消耗的时间和资源会影响测试关键应用的时间。所以在计划和设计测试时，必须考虑均衡。通常情况下，应该找出产生系统80%负载的20%的应用。例如，可以不关心只在每年年底才更新数据库的应用。

l         将要运行测试的数据库––确定是在production数据库还是测试数据库上运行测试。

性能测试举例

这一部分总结了一些典型的性能测试。在定义测试时，每一个测试都有一张表列出了要考虑的主要因素。这些表只是作为一个指南，它们不可能包括性能测试所有可能的因素。

正常条件下支持的虚拟测试者数量

为了确保一个系统满足测量性需求，需要确定一台服务器可以支持的虚拟测试者的数量。在响应时间不可接受之前，系统可以支持多少个虚拟测试者？

例如，估计一个数据库系统可以支持500个虚拟测试者。我们计划分别用300个，400个，500个，600个和700个虚拟测试者并发完成多个任务来运行测试。下面这张表列出了在设计测试时包括的主要元素：

增量的增加虚拟测试者

性能测试共同的需求是当不同虚拟测试者执行他们的动作时测试系统会发生什么。例如，当人们早上开始他们一天工作的时候，测试服务器运行情况。或者测试服务器如何处理在一天中不断增加的工作负载，特别是在高峰负载时服务器的响应。

利用TestManager可以通过不断增加虚拟测试者负载来对这种类型的工作负载建模。测试工作从设计工作负载模型开始。例如，记录应用使用频率和数量。接着，当建立套件时：

l         确定不同的用户组在套件中开始执行的时间

l         为每一个用户组设置运行测试脚本的虚拟测试者数量和一个迭代数（可选）

通过设置虚拟测试者的开始时间和迭代数，就可以增量的增加负载。也可以在套件运行的具体时间增加负载。

下面描述一个重叠运行的简单测试：

l         运行一个有100个虚拟测试者的套件。这一组虚拟测试者代表第一组登陆职员，反复重复同一组登陆交互，所以应该让每一个虚拟测试者多次迭代交互；应该设置足够多的迭代以使这组虚拟测试者直到套件结束时才停止运行测试脚本。必须确定需要多少次迭代。

l         在套件中设置一个延迟。延迟的类型可以是在套件的开始，或者在一天的某个时刻开始。当延迟结束后，200个新的虚拟测试者开始运行。这是第二组登陆职员，他们和第一组重叠。

l         这个组合的职员组表示高峰负载，300个虚拟测试者重复执行交互。

下面这张表总结了重叠运行的一个简单测试：

在压力条件下系统运行情况

压力测试是试图导致服务器崩溃的测试。当怀疑服务器在一些方面有漏洞时用压力测试，在这种情况下，当一个操作执行很多次或者很长一段时间时，服务器响应就会完全崩溃或者下降。

因为压力测试包括很多并发操作（例如，一瞬间向服务器发送成百上千个请求），所以虚拟测试者要提供执行这种压力测试最为实用和有效的方式。连续不断的执行测试脚本有助于检查在压力条件下运行应用的长期效果。

在一个简单的压力测试中，虚拟测试者不断重复的执行同一个操作几个小时。测试可能包括：

l         在数据库中添加成千条记录

l         向数据库发送成千条查询请求

下面这张表总结了一个简单的压力测试：