接下来的小节，我们会逐个地查看这些需要重用和自动化的区域，并描述我们在每个区域中所面对的问题。

        重用 这一小节会提供一些来自于电子商务（e-Business）SVT团队的例子，他们测试的产品就是我们上文提到的OS/2 WARP服务器，同时他们对重用满怀期望。在这个团队中，又包含了很多更小的组，他们侧重于测试的开发和执行，在整个项目中负责不同的区域。我们希望能保证每个小组可以利用公共的测试例程集。要更好地了解这一期望，我们需要考虑一些潜在的问题，这里，让我们看看一个看似简单的测试—把原文信息记录到一个文件中（日志文件）。当我们把这个活动留给每个测试员或测试组，由他们各自重新创建，而不是使用公共的可重用例程时，问题出现了：
        日志文件被保存在不同的地方：有一些组创建的日志例程，把他们的日志文件保存在运行测试的目录中。而另外一些组创建的日志例程把它们保存在中心目录中。这一差异使我们很难去确定所有记录了测试执行的日志文件的保存位置。最终，你不得不遍历整个系统寻找这些日志文件。
        日志文件的格式不同：不同的组在日志中记录的数据字段不同。导致我们很难去编写脚本来解析并寻找这些日志文件中的信息。
        信息的类型不同：一个组可能使用“FATAL”信息，相同的意思其他的组可能用的是“ERROR”，或者一个组可能使用“TRACE”，而另一个用的是“DEBUG”。这一变化使我们很难解析日志文件。同时，也增加了我们理解这些日志信息含义的难度。
        这些问题没有哪个是不能克服的，而且，通过一个“标准”文档的说明--日志文件的保存位置、日志记录的格式，以及信息类型的含义和使用目的等，我们可以很好的处理这些问题。尽管如此，这份清单还是为我们对公共和一致的可重用例程的期望提供了证明。

        多种编程语言  我们的测试员使用各种编程语言编写了各种各样的测试。当测试操作系统的C语言APIs（应用程序接口）时，他们用C编写测试。在测试操作系统的命令行应用或具有命令行接口的应用程序时，他们利用脚本语言如REXX（OS/2系统的本地脚本语言）来编写测试。当测试操作系统的Java虚拟机时，他们用Java语言编写测试。因此，要使我们的测试人员能够使用公共的可重用例程来执行上文所描述的那些工作--如日志记录等，那我们就得让所有的编程语言都能够访问我们的例程。

        多码页  电子商务OS/2 WARP服务器可以被翻译成14种不同的语言版本，英语、日语和德语等。这是一个很不平常的问题，一个语言的翻译版本在另一个语言中就不存在。因此，我们有责任测试所有的这些版本。测试多种版本会在我们的测试中引入额外的复杂度，特别是我们的测试可以使用的那些可重用的组件集。这一情况的一个具体表现是不同的翻译版本要使用不同的码页。一个码页就是一个字符集（比如使用英语或日语）的编码，从而形成一个二进制形式，这样，计算机就可以识别和解释这些字符集的编码了。使用不同的码页就意味着对相同字符进行的编码，不同的码页会使用不同的二进制形式（比如，一个码页使用一个二进制形式对字母“A”进行编码，而另一个码页则会使用不同的二进制形式对字母“A”进行编码）。因此，在测试产品多种语言的翻译版本时，一定要注意程序的输入和输出要使用不同的码页。如果我们的测试人员将使用一个读写日志文件的公共例程集，那么这些例程处理的信息，不仅要能够使用英语的码页，还要能够使用其他13种语言的码页，来测试产品不同的翻译版本。

        多操作系统  我们在测试电子商务OS/2 WARP服务器的同时，还需让我们的测试能够在其他的操作系统上运行，比如Windows**和AIX*（Advanced Interactive Executive*--先进的交互执行系统），以执行产品的互操作性和兼容性测试。如果我们希望使用公共可重用的例程来执行如日志操作等任务，那我们就得让所有的操作系统都能够访问我们的例程。

        现存的自动化组件  我们检查了我们的测试组不断地重新创建着的那些组件类型，以及那些现存的需要支持自动化的组件，我们意识到我们需要相当数量的基础自动化组件。这些组件包括进程执行、文件传送、同步、日志、远程监控、资源管理、事件管理、数据管理和队列等。此外，我们不仅要求在本地使用这些组件，还需要通过网络的远程方式使用这些组件。如果解决方案不能提供这些组件，我们就不得不自己来创建它们。因此，我们希望解决方案能够提供一些重要的基础自动化组件。

        自动化 这一小节会提供一些使用“Ogre”测试序列的例子。正如我们前面所提到的，这个测试序列被设计用来测试LAN服务器和基于OS/2系统的产品，主要针对大负载和压力条件下的测试。这个测试序列由一组单个的测试组成，它们侧重于产品的某一具体方面（比如在客户端和服务器之间来回传送文件）的测试。这些测试在一组客户端系统上以伪随机循环方式运行。这组客户端系统通常会很大，有超过128个以环形布置的系统。被测试的服务器组通常很小，一般不超过3个。这个测试序列的执行周期一般为24到72个小时。这样，由客户端和服务器的组合配置，加上它们的数量以及运行时间的总量，构成了一个场景。如果在规定的运行期结束之后，所有的客户端和服务器仍然具备可操作性，那么我们认为这个场景是成功的。在一个给定的SVT周期内，我们会执行多重场景测试。

        图2为我们展现了基本的过程流，它被用来执行一个给定的Ogre场景。注意图中的红色区域。这些区域表示过程流中手工执行的步骤。在随后的小节中，我们会详细地描述这些区域。

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