用TestManager做性能测试

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

一旦用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         向数据库发送成千条查询请求

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