现有的解决方案
        我们前面提到的重用和自动化是两个不同的问题，于是我们意识到我们需要找到两个不同的解决方案。但是，我们还是希望能有一种方案可以同时解决这两个问题。为此，我们有以下顺序的选择：
        设计一个可以同时解决两个问题的解决方案。
        设计两个可以一起工作的单独的解决方案。
        一个重用的方案，一个自动化的方案，由此产生的重用为自动化提供支持性的组件。
        两个完全独立的不相交的解决方案。

        在接下来的小节中，我们会讨论现有的已探索过的解决方案，以及它们是如何来解决重用和自动化这两个问题的，同时我们也会讨论这些方案与我们上述的选择是如何关联在一起的。

        脚本语言  脚本语言如Perl、Python、Tcl和Java（虽然从技术上说Java并不算作一种脚本语言，因为Java程序是需要编译的）在整个编程业内以及测试组织内部都是非常流行的，这是由于它们使快速开发周期的实现变得更为容易。作为编程语言，脚本语言并没有打算直接去解决重用或自动化的问题。此外，它们的直接目标也不在测试环境上。尽管有这些局限性，但是考虑到脚本语言应用的广泛性和其庞大的使用者基础，为了解决我们的问题，我们还是应该检验一下这些脚本语言的潜力。

        虽然脚本语言不是一个直接的解决方案，但是对于重用的问题来说，脚本语言具有一些通用的特性。首先，它们可以使用在各种各样的操作系统上。而且，它们具有大量的行之有效的扩展集。虽然从测试的角度上看，它们并不完整，但是这些扩展会提供一个牢固的基础。此外，一些脚本语言（特别是Tcl和Java）能够为多码页的处理提供支持。

        脚本语言的优点可以清楚地表现在我们的第3类选择上。但不幸的是，发挥这些优点的前提是只能规范一种语言，让这一种语言变成公共的语言。然而，正如前面所提到的，我们的测试人员会利用许多不同的编程语言来创建测试，而且，要让他们转向一个公共的编程语言其本身就是一项极为困难的工作。即使我们说服了组内的所有测试人员，但我们说服不了整个组织中（更不用说是其他部门或站点上）的测试人员，虽然我们很希望能和他们分享我们的解决方案。因此，对于我们的解决方案而言，我们不能够依赖于脚本语言。

        测试工具  一个测试工具就是一个应用程序，用来执行一个或多个系统上的测试。换句话说，设计测试工具的目的就是自动化地执行各种测试。

        有很多可利用的各种不同的测试工具。每种工具都面向某个特殊类型的测试。例如，很多典型的利用shell脚本或C语言编写的UNIX**测试。这些测试通常是独立的可执行程序，成功时返回0，发生错误时返回其他非0值。如开源组织的Test Environment Toolkit（TET，测试环境工具包，即TETware），就是被设计来执行这类测试的。比较起来，Sun公司的Java Test利用基础的Java编程语言来创建面向Java程序的测试工具。一个测试组很少会同时使用这两种工具。此外，测试组也很少会针对他们所测试的那些专业区域来创建自己的工具，比如I/0子系统和协议组。

        显然，测试工具是直接应用于自动化方面的。然而，一般说来，测试工具只能解决自动化问题中的执行部分。而它依然没有解决一些诸如测试序列的分布、测试序列的监控以及测试序列的动态执行等问题。此外，测试工具没有直接应用于重用方面。因此，在最好的情况下，测试工具也只是我们第4类选择所对应的解决方案的一个部分而已。正如前面我们所描述的，测试工具与测试环境的接近度，可能会使它在我们最终的解决方案中起到一定的作用。但是，我们仍然需要寻找一种解决方案来解决重用问题，并使用和扩展我们现有的测试工具（如果有的话）来填补自动化方面的一些空白。

        CORBA  从最基本的角度讲，CORBA**是一套全工业范围的规格说明，它定义了一个机制，允许应用程序运行在不同的操作系统上，并且可以用不同的语言来编写通讯代码。同时，CORBA在其通讯层的顶端定义了一套高级别的服务（如命名、事件和事务服务等）。这里需要注意一点，CORBA本身并不是一个产品，它只是一套规格说明。对于任意已知的操作系统、语言和服务，寻找一个已在其软件环境中实施了CORBA的第三方软件商是很有必要的。

        CORBA并不能直接地去解决重用和自动化的问题。然而，单就重用的问题上看，CORBA是具有一些通用性的。首先，CORBA可在各种操作系统上执行。其次，CORBA支持各种编程语言。因此，CORBA解决了我们重用中的两个关键问题。相比之下，CORBA并没有为多码页的处理提供直接地支持。此外，一套可用的CORBA服务并没有直接面向一个测试环境，这就可以理解为什么说CORBA是为整个计算机编程工业提供了通用性。

        显然，CORBA适合于我们的第3类选择，虽然它并没有为多码页的处理和现有的自动化组件提供支持，此外，正如我们上面所描述的，没有什么公司会去生产一种叫“CORBA”的产品，这就意味着我们为了得到一个完整的方案，就必须从多个第三方软件商那里获取产品，并配置它们，让它们一起工作。在过去，这种努力是非常困难的。虽然现在的情况有所好转，我们还是宁可避免这一层的复杂性。因此，我们觉得一个CORBA解决方案并不值得我们去费力地实施和维护它。
STAF的设计
        在我们用尽了其他的途径之后，我们决定创建我们自己的方案。我们使用一个两阶（两个阶段）性的方法来开发STAF。第一个阶段讨论重用的问题。由这个单独的阶段，我们得到了一个适用于我们的第3类选择的解决方案。第二个阶段处理自动化的问题。在这个阶段中，我们以重用方案的顶层为基础构建，并做了对应的扩展，使其能够解决我们自动化的问题。这个二步法所提供的解决方案，刚好适用于我们的第1类选择。由此产生了STAF，即软件测试自动化框架（Software Testing Automation Framework）。

        在接下来的小节中，我们会围绕STAF来阐述它的设计思想，以及它如何为我们提供了一个重用的解决方案。而随后的小节会讨论我们如何构建并扩展了这个方案，以解决自动化的问题。

        服务  STAF是基于可重用组件的思想设计的。在STAF中，我们称这些组件为服务。STAF中的每个服务代表了一个专用的功能集，如日志等。从根本上说，STAF自身是一个daemon进程（在STAF中被称为STAFProc），它提供了一个轻量级的分发机制，负责把请求（来自本地和远程进程）转发给这些服务。STAF有两个“特色”服务，内部和外部服务。内部服务被集成到daemon进程的内部，并提供核心服务，比如数据管理和同步等。外部服务需要通过共享库（shared libraries）来访问，并由STAF动态地加载（装入）。这些外部库在采用一些如C或C++编程语言时，直接代表其服务本身，最终会产生本地的可执行对象代码，当使用面向其他语言的proxy（代理）接口时，如Java或REXX语言，则不产生本地的可执行对象代码。图4则展现了“flavors”（特色）服务和proxy（代理）处理之间的差别。
                    

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