在这个请求流中，有许多需要我们注意的地方。首先，从REXX程序的观点出发指定一个面向网络的请求是非常容易的。其次，测试机具有不同的操作系统和不同的硬件体系结构，而REXX程序和事件服务都不需要了解这些差别。另外，REXX程序和基于Java的事件服务都不需要关心我们所使用的其他的语言。

        我们在设计STAF时，只是让STAF处理字符串，这一关键和有利的决策使我们能够实现上述的特点。同时，它也让我们保证了STAF简单性和灵活性。

        Unicode  由于我们把主要的关注点放在了字符串，以及码页的问题上，因此，我们设计的STAF内部使用了Unicode**。当产生一个STAFSubmit( )的调用时，输入字符串被转换为Unicode。在随后对其进一步的处理时，仍然使用Unicode编码。只有当结果从STAFSubmit( )返回时，或者STAF不得不与操作系统或不接受Unicode字符串的实体进行交互时，数据才不会被转换为Unicode。通过利用Unicode来处理数据，我们可以保证数据的完整性。例如，某个使用了日文码页的系统发送了一个请求，以记录一些包含了日文码页字符的数据，而此请求会发送到一个使用了英文码页的系统上，当产生一个STAFSubmit( )的调用时，这些数据从一开始就被转换为Unicode（以维护数据的完整性），并保持为Unicode，直到产生另一个STAFSubmit( )的调用以检索这个数据为止。如果是一个相同的也使用日文码页的系统对此数据发起请求，那么此数据会由Unicode转换回日文码页的字符，以此保证数据的完整性，因此这个数据最初使用的是相同的码页。检索的数据与最开始记录的数据是一致的，尽管在一段时间内，系统是以英文码页的形式保存或维护着此数据。因此，通过在整个STAF中使用Unicode，我们解决了处理多码页的问题。

        可用的服务  为了解决自动化的问题，我们需要在我们的自动化之上构建一个组件集。在我们构建STAF时，我们保留了这一最为重要的想法，以确保我们开发的服务包括这些基本的自动化组件。这里我们会描述一些STAF提供的服务。稍后，我们会看到这些服务，看看他们是如何为我们的自动化问题创建解决方案的。

        在STAF中有三个核心服务，它们分别是handle（句柄）、variable（变量）和queue（队列）服务。这些服务提供了最基本的公共功能，并跨越了所有的服务。同时也为我们提供了一个持续构建的基础。一点也不奇怪，这些服务展现了STAF中handles、variables和queuing的能力。

        Handles用来识别并封装STAF环境中的应用程序的数据。当一个应用程序希望使用STAF时，它会通过调用一个注册的API以获得一个handle（句柄）。返回的handle会特别地指向注册的应用程序。一般来说，应用程序与handles之间是1对N（多）的映射关系。一个应用程序可以有多个handle，但任意一个给定的handle只属于一个单个的应用程序。然而，STAF不支持特殊的“static”（静态）handles，而这些handles可在应用程序之间共享。每个STAF的handle都有一个与之关联的信息queue（队列）。这个队列允许应用程序接收来自于其他应用和服务的数据。它也构成了STAF中本地和面向网络的IPC（进程间通信）的基础。很多服务都是通过它的队列来向应用程序发送数据的。这些队列允许应用程序以事件驱动的方式工作，类似于许多窗口系统所使用的方法。

        通过STAF的变量（服务），STAF能够提供数据管理的功能。STAF应用程序使用的这些STAF变量的方法与编程语言使用变量的方法大致相同。在提交了一个STAF请求时，请求中的变量会被他们的值所替换。STAF变量（服务）有一个强大的功能是可以在运行的应用程序的范围之外对变量进行修改。这个功能提供了一个能力，就是可以动态地修改应用程序的特性。
        例如，设计一个程序，用来向系统施加一定百分比的负载，而此程序可能允许我们通过一个环境变量或者一个命令行参数来设定这个百分比。在这种情况下，程序一旦开始运行，改变负载百分比的唯一方法就是停止程序，修改环境变量或命令行参数，并重启程序。而使用STAF变量则可以在不停止程序的情况下修改负载百分比的值。对程序所做的唯一修改也仅仅是让程序周期性的重新评估STAF变量的值。这些STAF变量被保存在变量池中。每一个STAF handle（句柄）都具有唯一的，且为对应的应用程序所特有的变量池。STAF也会提供一个全局变量池，一个给定的STAF系统上所有句柄公用的变量池。此公共性允许我们在全局变量池中设定默认值，然后按照各个句柄的访问顺序覆盖这些默认值。

        除了handle（句柄），variable（变量）和queue（队列），STAF还提供其他几项服务。STAF通过semaphore（信号量）和resource pool（资源池）服务提供同步功能。其中，信号量服务提供两种信号量的操作：mutual exclusion (mutex--同时共享排他性，即互斥）和事件信号量。与通常由操作系统提供的信号量相比，STAF信号量具有两个优点。一，可通过网络远程使用。二，更加可视化，这意味他们也更为简单，例如，要判断谁拥有一个mutex（互斥）信号量和谁正在等待一个event（事件）信号量。而资源池服务则为管理已命名的，如machines（机器）、user identifiers（用户ID）和licenses（许可）等资源池，提供了一个管理手段。特别的是，它提供了对池内容进行管理，以及同步存取池中元素的特性。

        STAF通过process（进程）服务来执行STAF系统上的进程启动、停止和查询操作。它可以对进程的执行进行详细地控制，包括明确的环境变量、工作目录、输入/输出重定向，以及有效的用户ID。进程服务也能应用户的要求，在进程结束时发送通知。这些通知通过前面描述的队列功能发送。

        STAF通过file system（文件系统）服务提供文件系统功能。目前，这个服务为文件的传送和文件内容的存取提供了理论依据。STAF的未来版本会把此服务的功能扩展到文件和目录的管理中，如目录的创建和枚举，以及文件或目录的删除。

        通过log（日志）服务，STAF提供日志记录功能。在最基础的层上，此服务根据各个级别，如“FATAL”、“ERROR”、“WARING”以及“DEBUG”，提供时间戳（time-stamped）类消息的日志记录。各种更高级别的功能都建立在这个基础之上，包括本地和集中式的日志记录、程序间的日志共享、动态的level-masking（级别遮盖），以及活跃态日志的维护。动态的level-masking有其特殊的意义。级别遮盖指用户能够判断日志记录的级别，以确定把哪种级别的记录保存在日志文件中。未包含在级别遮盖中的记录级别的信息会被丢弃。事实上这个特性是动态的，意味着我们可以在程序运行时，修改级别遮盖。例如，用户能够在遇到问题的时候，“打开”debug（级别）的信息，而不需要停止并重启程序。

        STAF通过monitor（监控）服务提供远程监控功能。此服务提供了一个轻量级的分发-查询（publish-query）机制。 应用程序公布他们的状态，并允许其他程序远程查询这个状态。所公布的状态是一个简单的时间戳字符串，但这已经能够充分的证明监控服务的健壮性了，尤其是对于典型的测试和应用进程的监控而言。

        通过event（事件）服务，STAF具有事件处理的能力。这项服务提供了标准的发布-订阅（publish-subscribe）机制。应用程序注册为具体类型的事件和可能的子类型事件。其他应用程序根据类型、子类型和一系列属性（属性/值的结对）生成事件。事件会通过上文描述的队列功能发送。

        除上述服务外，团队为了满足特定需求会开发自己的服务，而STAF会让这变得很简单。这些新的服务会成为STAF服务组件集的一部分。究其本质，STAF是一个模块化的基于服务的平台，这也为它的发展和演变提供了基础。

从重用到自动化
        前面的内容一直在讨论重用的问题，接下来我们把重点转移到自动化上。我们的计划是通过对STAF提供的自动化组件的利用，在STAF之上构建一个解决方案。

        我们首先要处理“Ogre”测试序列的执行问题。我们并不打算去尝试着改进已有的test harness（测试工具），以此让它去适应STAF，而是选择创建一个全新的STAF测试。随后，我们提出了一个名为Generic WorkLoad的处理机程序，简称GenWL (读音JEN-wall)。这个harness允许我们创建一个文本文件，为场景定义它的配置数据、执行过程，以及与执行相对应的系统。这个文本文件被称作为“工作负载”文件。通过对GenWL的使用，我们可以在一个中央管理控制台上，用一个单命令启动或停止整个的工作负载，这也是我们所期望的目标。同样，GenWL在解决自动化问题的其他方面上，扮演着重要的角色，这也是我们接下来要讨论的内容。
[译者注：test harness的概念
        在国内的测试术语中，一般把test harness翻译为测试用具，指包含测试驱动和测试比较器的测试工具。以下是英文释义：
In software testing, a test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitor its behavior and outputs. It has two main parts: the test execution engine and the test script repository.Test harnesses allow for the automation of tests. Think of it as scaffolding upon which you will build your tests.
A test harness should allow specific tests to run (this helps in optimising), orchestrate a runtime environment, and provide a capability to analyse results.
        在软件测试中，test harness或自动化测试框架是一个包含了软件和测试数据（这些数据已经过配置）的集合，用以测试一个程序单元，使之在不同的条件下运行，并监控它的行为和输出。Test harness有两个主要的组成部分：测试执行引擎和测试脚本储存库（repository）。因此，Test harness能够使我们实现自动化地测试。简单的说，你可以把test harness当作是你构建测试时所使用脚手架。
        一个test harness应包括具体的测试运行（有利于优化），设计运行时环境，以及提供结果分析的能力。]

        接下来，我们要面对并解决在一个已知的系统上执行多个Ogre实例时所引发的问题。其中，最迫切需要解决的两个问题是测试序列的同步和资源的管理。为了处理对测试的同步访问，我们应用了STAF的semaphore（信号量）服务，特别是它支持的mutex信号量（服务）。此服务允许测试序列的一个实例获得对一个测试的独占访问权，随后，此测试一旦执行完毕，则释放此独占权限。在对盘符和打印机端口的管理上，我们应用了STAF的资源池服务。这项服务允许我们分别为盘符和打印机端口建立自己的（资源）池。然后在池中对入口的访问进行管理。因此，当此测试序列的一个实例请求一个盘符时，我们可以保证不会有其他的实例能获得此盘符，直到第一个实例释放了它的控制并返回到资源池服务。解决了这些问题后，我们就能在我们的系统上运行Ogre的多个实例。对这个测试序列所做的修改如图6所示。特别需要说明的是，图6的淡紫色区域表示，我们使用STAF解决了测试序列的同步和资源管理的问题。

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