我们在对同步和资源管理做出上述改变的时候，发现我们对测试序列的再分布要比平时频繁的多，因此，我们要与上述的改变一起，同时解决测试序列的分布问题。这里，我们可以利用STAF的文件系统和变量服务。使用这两个服务时，我们写了一小段脚本，对一个文件中的客户端列表进行迭代，并使用文件系统服务复制每个文件。而变量服务用于处理目标映射的问题，把在复制命令中定义的抽象目标映射为每个客户端的实际目标。利用对文件所包含客户端列表的维护，我们能保证把已更新的测试序列一致地分布到所有的客户端上去。
我们解决了测试序列的分布和执行的问题，接下来讨论测试序列的监控问题。与之对应，我们可以利用STAF提供的监控服务。每当我们的测试序列进入一个子测试或出现一个错误或警告时，它会向监控服务发布它的状态。考虑到此发布信息，我们接着开发了一种方法，即使用GenWL执行工具来查看此信息。由GenWL阅读的工作负载文件定义了所有的测试序列实例；因此，对于GenWL而言，与监控服务之间的交互，以此为所有的测试序列实例检索已发布的状态，是件很琐碎的事情。随后，GenWL会以一个系统接着一个系统的方式显示这个信息。我们在管理控制台上利用一个单命令，就能够查明整个Ogre场景的当前状态。
尽管GenWL和监控服务允许我们在任意的一个已知的时间点上判断场景的状态，但是这个功能并不足以让我们确定，在超出了我们已延长的时间的情况下（例如，从晚上直到第二天的早上），会发生什么事情。利用GenWL和监控服务，我们能看到场景在我们离开和进来时的状态，但我们对这个时间段内出现的问题仍然一无所知。
为了解决这个问题，我们简单地修改了一下当前的日志记录机制，即调用STAF的日志服务。而我们使用的方法类似于我们之前解决测试序列分布问题的方法。于是，我们创建了一个简单的脚本，对一个文件中的客户端列表进行迭代，并使用日志服务的功能来检索所有的错误和警告信息，而这些信息出现的时间都超出了已知的时间段。随后，我们能从这些错误和警告中查清哪些是真正的问题，或者只是由于人为因素使服务器暂时超出了它的能力范围。这里要说明一点，Ogre是一个负载和压力测试，因此我们可以预料到，我们的测试偶尔会让服务器超过它们的极限。
最后，留给我们的是动态执行的问题。为了解决这个问题，我们再次利用了GenWL。正如上面所提到的，工作负载文件包含了场景的配置信息。在工作负载文件被处理时，此配置信息被保存在每一个使用STAF变量服务的客户端系统上。随后，执行的测试序列会通过变量服务重新检索这些配置信息。通过对变量服务的使用，我们能够动态地更新配置信息。因此，如果我们需要改变配置信息，比如重新引入一个服务器或改变服务器的压力比（stress ratios），我们只需要更新一下工作负载文件中相应的值，并指示GenWL把这个值发送给所有的客户端。
图7表现了一个已进行了自动化修改后的Ogre 场景流程。和图2相比，请注意，现在的大多数步骤都已实现了自动化。而仅有的两个非自动化步骤则是更新配置和安装一个新版本。更新配置包括手工地对工作负载文件进行配置变更的更新。这个更新要求有效的人为干预。安装一个新版本属于其他范围的自动化，它对Ogre场景没有什么用处。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
