软件测试是软件开发生命周期中的一项完整、昂贵且耗时的活动。而通常情况下，在软件开发中实现对公共工件的重用可以显著地提升我们的生产率。此外，由于测试会涉及到被测试系统运行时的各种配置和环境条件，因此，自动化地执行相关的测试活动，可以帮助我们节约测试过程中的另一种潜在资源。本文主要讨论测试组织对重用和自动化的实现，同时，我们也会描述一下目前已存在的一些解决方案的缺点，并针对重用和自动化的问题，向大家介绍一种新的方案：Software Testing Automation Framework（STAF），它是一种多平台、多语言的重用方法。STAF基于可重用服务的概念，使我们能够在测试过程中把主要的活动给与自动化地实现。我们会描述STAF是如何设计的。并通过一个实际的测试组织，讨论STAF如何把一个“资源密集”的测试序列给与自动化地实现。
早在1997年，我工作过的一些系统验证测试（SVT）和功能验证测试（FVT）的组织已经明白，为了适应未来的新项目，他们需要减少每个现有项目的资源。为此目的，这些组织创建了专责小组，以研究如何降低测试的费用。这个专责小组主要关注两个区域上的改进，它们是重用和自动化。对我们来说，重用涉及多个测试之间的公共功能的共享库能力。因此，针对本文的目的，测试就是执行一个程序来确认另一个程序的行为。而自动化主要指去除人与过程之间的交互，并替换为机器或程序控制。在我们的事例中，这个过程就是软件测试。通过重用和自动化，我们计划减少测试所需的那些资源（如硬件、人或者时间等）。
为了说明我们遇到的这些问题，以及我们提到的解决方案，这里，我使用一个曾经进行过SVT（系统验证测试）的产品作为例子。这个产品是IBM OS/2 WARP*电子商务（e-Business）服务器，它不仅包含了基础的操作系统（OS/2*--Operating System/2*），也包括了一个局域网（LAN）内部的文件和打印服务器（也就是LAN服务器），以及Web服务器、Java虚拟机（JMV）等等。测试这样的产品是一件令人畏惧且耗时的工作。而我们所做的任何改进，其目的都是要降低这项工作的复杂度，让它变得更为可行。
为此目的，我们会设计测试序列（test suite）对产品的相同区域进行确认测试。此处，我们会讨论一个特别的测试序列，它就是人们所熟知的“食人魔（Ogre--引申为耗费大量的人力物力）”测试序列。我们设计的这个测试序列用来执行LAN服务器和基础OS/2的负载和压力测试。食人魔是“著名的”资源密集测试序列，而我们尝试着利用自动化来帮助我们减少测试所需的硬件、人员和时间的数量。
根据我们的要求，降低我们所创建的测试的复杂度并将其自动化成了我们最需要关注的方面，因此，我们查找了IBM和测试业界内的一些现有的解决方案。然而，这些解决方案中没有一个是符合我们要求的，于是我们自己开发了一个新的方案，它就是软件测试自动化框架（STAF）。本文将会探索STAF的设计，并讲解STAF是如何实现重用的，以及如何使用STAF来自动化并改进我们的Ogre测试序列。另外，STAF提供的这个解决方案也具有相当的灵活性，这在后文中会有表现。最后，这项技术会为大多数测试组织所采用，以加强他们的测试过程的效率。
遇到的问题
图1描绘了一个软件测试周期。其中，计划由被测试产品的特征分析和测试工作的详细范围这两部分组成。设计则包括了文件和确认产品所需的测试细节。开发涉及对实际测试的创建或修改。执行则与实际测试的运行有关。分析或复查是对测试结果和测试工作有效性的评估，此评估会作为下一个测试周期的计划阶段所使用的依据。
重用侧重于对测试周期中开发部分的改进，以及对设计部分的小程度改进。自动化侧重于对测试周期中执行部分的改进。虽然每个产品的测试周期都是不同的，但通常大多数的人工都花在了执行上，接着是开发，然后是设计、计划和分析或复查。通过改进（或提高）我们的重用和自动化水平，我们可以对测试周期中这些耗时费力的工作产生积极地影响。
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
