执行测试序列  我们启动或停止一个场景的现有机制是让一人或多人去每个客户端启动或停止测试序列。这在具有128个客户端的情况下是很大的工作量，需要大量的时间和人力。而且这种方法也会发生忽略某个或某些客户端的情况，这会对场景本身产生相当大的影响（比如，负载或压力不充足导致缺陷未出现）。因此，我们希望解决方案能够允许我们利用一个中央“管理控制台”来启动和停止场景。

        测试序列的分布  我们创建了新的测试或修改了现有的测试，并且需要把它们分布到所有的客户端系统上。现有的机制是由一人或多人去每个客户端用软盘复制这些测试。这个方法相当复杂，因为这些测试在每个客户端上的位置通常是不一样的。因此，它也有前面我们提到的问题，非常耗费时间和人力。同样，它也会引发另一个问题，某个或某些客户端不能接收已更新的测试，导致测试出现假错。因此，我们希望解决方案能够为我们提供一种机制，让我们能够正确地、一致地把我们的测试分配到我们客户端上。

        监控测试序列  一个场景运行时，我们需要不断地监控它，以确保运行时不出现失败的情况。现有的方法是由一人或多人在每个客户端的系统屏幕上查找这些错误。虽然，在客户端上运行的测试出现错误时，它会发出类似于报警的蜂鸣声，而我们通常也会走进测试实验室中去“聆听”错误。但不幸的是，我们不得不在下班之后继续监控这些场景，甚至于周末也不能停止，这意味着我们必须有一个人，他需要周期性地开着自己的车去工作，到实验室去查找和监听错误。这种方法也是非常耗费时间和人力的。同时它也会对士气产生负面影响，因为它被认为是“grunt”（沉闷无聊的）工作。因此，我们希望解决方案能为我们提供一种远程监控的机制，这样我们就可以在自己的办公室或是利用telnet在家里来评估场景的运行状态了。

        动态地执行测试序列  “Ogre”测试序列具备很好的可配置性。它的配置文件中定义了一个属性扩展列表，在对测试序列进行初始化时（并为了更快速的访问而对环境变量进行缓存）它会读取这个配置文件。这些属性操作了场景的很多方面，如服务器上的可用资源，当前已掉线的服务器，以及服务器的访问频率相对于其他服务器之间的比例等。这样的可配置性允许我们做单行修改，可以阻止客户端访问一台给定的服务器（如果出现了问题需要作调查）或增加或减少一台服务器上接收自其他服务器上的压力。然而，唯一可行的方法就是要把整个场景停下来修改这些参数，然后再把场景启动起来。举个例子，假设一个时长为72小时的场景，运行了36个小时，我们发现其中的一台服务器上出现了问题。于是我们停止运行场景，并修改配置文件让这台服务器不可用，然后重新启动此场景，继续运行剩下的服务器，直到我们分析出问题的所在。12个小时之后，问题被修复了，我们需要把修复的服务器放回到组合的测试环境中去。为此，我们不得不停止并重新启动整个场景，于是，我们把那段时间—修复问题服务器的时间，积累在其他服务器上的运行时间都否定了。在我们需要修改服务器的压力比或其他的配置参数时，也出现了类似的情况。因此，我们希望解决方案能够让我们在一个场景的运行期内动态地修改配置信息。

        “Ogre”的另一个问题是我们在任意一台客户端上一次只能执行一个测试序列的实例。但是，如果能够在相同的客户端同时执行测试序列的多个实例，那么我们就可以利用较少的客户端获得同等量的压力。图3展现了Ogre测试序列的单个实例在一台系统上执行的基本流程。注意红色的区域。这些区域表明在同一台系统上运行Ogre的多个实例时，会产生冲突。接下来的两个小节会详细描述这部分的内容。
       

        测试序列资源管理  为了建立一个服务器链接，客户端必须通过被访问的资源指定一个驱动器名（有文件资源）或一个打印机端口（有打印机资源）。当运行测试序列的多个实例时，就会出现资源争用的情况。因此，我们希望解决方案能够让我们管理驱动器名和打印机端口，能够让我们在测试序列的多个实例之间分配这些资源。

        测试序列的同步  我们的测试中有一些具有严格的、不可变的对测试过程本身的依赖。这样，在运行测试序列的多个实例时，我们就需要一种方法，以避免多个实例同时执行相同的测试。因此，我们希望解决方案能够让我们同步地访问单个的测试。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。