日本的 IBM Center of Excellence 和罗马的 IBM Tivoli 实验室正一同开发一套最佳实践和工具，让 Rational Functional Tester 的自动化套件在 GVT（全球化验证测试，Globalization Verification Testing）阶段可以进行复用，从而提高团队的生产力。作者揭示了他们所使用的过程和最终的结果。

介绍

在过去的几年，那些可以帮助编程人员更快的创建应用程序的工具（尤其是那些拥有图形用户界面的工具）确实卓有成效地提高了编程人员的生产力。 因此，测试员要求使用比以往更短的时间在数量日益增长的软件程序上设计并运行更为复杂和更有效率的测试用例。这就必须提高测试团队的效率并且增强内部的协作以最大限度地发挥团队的生产力。

许多测试团队发现自动化测试带给他们所需的优势。自动化测试套件使日常严格的执行一组基本测试用例成为了可能。他们不但帮助评定产品基本功能的品质而且还为测试团队成员节省了时间，使得他们可以把这些时间用于进行更高级别的品质保证测试。此外，最佳实践和业界分享的常规经验教训可以提高开发和管理测试套件的效率，从而可以减少通常很昂贵的测试自动化的花费。

尽管能够减少花费并确认了自动化测试套件的价值，但它必须尽可能多的进行复用以最大化 ROI。在2004年的秋天，罗马的 TWS 测试自动化团队（罗马的 IBM® Tivoli®实验室，意大利）和在 Yamato IBM Center of Excellence 的 DBCS 测试团队（日本）共同合作，把部分测试资源用于为 DBCS 测试寻找一种复用测试脚本的方法，而不是把全部可用资源用于人工测试。这个举动推动了工具的开发，并且在成本允许的情况下，针对 DBCS 测试 引入了一系列的能够复用 已有 Rational Functional Tester 的测试套件的最佳实践。

回页首

Rational Functional Tester 选项

IBM® Rational® Functional Tester（RFT）是一个面向对象的用于测试使用在 Windows 2000、Windows XP 和 Linux 平台上的 Java、HTML、VB.NET、Microsoft® Windows® 应用软件的自动化测试工具。RFT 提供了两种主要的自动化测试方法：

• 快速但不稳定： RFT 提供一个强大而且可重放的工具把使用者在测试产品过程中的行为记录在一系列的文件和脚本中。当这个纪录完成时，使用者可以很容易地播放测试的脚本。向导和指南可以帮助使用者。遗憾的是，以这种方式创建的套件工具对被测试应用软件中很细小的变化都非常的敏感。尽管这种方法对快速改变中的产品(开发的早期阶段)以及那些只有少量资源需要短期自动控制项目的团队很有价值，而更加工程化的方法对于中期或者长期的项目设计却是更加可取的。
• 慢速但稳定：RFT 使用 Java 编写测试脚本。通过使用编程工具、向导并且遵循最佳实践，创建一个完善的、易维护的自动化测试套件，并且让代码复用最大化是可以实现的。这个方法的成本很高，但是这些花费通常在整个开发周期中被扣除(未来产品版本中没有提及套件的复用性)。

这两种不同方法最主要的技术区别是在测试套件中被测试应用程序的数据被储存和处理的方式。在快速但不稳定的方法中，数据遍布在几个不同的文件中，但是使用慢速但稳定的方法，应用程序的数据很有逻辑的被组织在一起，并且如何处理这些数据成为了编写测试脚本的一部分。结构化的数据处理不但优化了可维护性，使代码可以重复使用，而且还产生了积极的作用使我们可以有机会为 GVT 重用测试套件。

对象图

每一个 RFT 的测试脚本都有一个针对被测试应用的对象图。Functional Tester 测试对象图列举了应用程序中可以使用的测试对象，而无论他们是否展示出来。这个数据用于在脚本重放时识别被测试应用程序的元素。

当使用记录和重放方法时，RFT 自动处理所有的测试对象图细节，而且它还提供操纵对象图的工具。这使用户在测试的过程中获得更大的灵活性和敏捷性，因为您可在必要时做出更改：

• 创建新的测试对象图(基于已存在的图或者当需要时增加对象)
• 增加或者删除对象
• 更改对象属性 (在被测试应用程序产生很小的变化时将十分有用)

在慢速但稳定的方法中，我们发现，所有的测试套件拥有唯一的对象图不会减少测试脚本的性能。此外，它有助于将花费降到最低以及 GVT 测试套件的转化。

使用 RFT 进行 GVT 的方法

当使用 RTF 试图进行多语言自动化测试时，测试者通常使用三种主要的方法：

• 使用唯一的 ID 来识别对象：通过操纵对象图，RTF 可以被配置成为不用依赖局部部件(比如窗口标题和按钮标签)来识别对象。这个方法减少了所有将来以不同语言运行套件所需的重复工作，但是由于它紧紧地被绑定在实现细节中，所以它在套件的编写代码阶段是非常昂贵，同时甚至是在应用程序中非常小的改变都会被揭示出来。
• 在对象图中为每种语言创建一个国家的语言：:直接的方法是为每个将要被测试的语言创建一个对象图。它最主要的缺点是自动化测试人员需要创建并且维护不止一个对象图，而是好几个对象图。这个方法被推荐用于维护发布软件，在那里连小小的改变都通常需要显示在对象图中。语言技能是这个解决方案的前提条件。
• 具体化字符串：您可以将字符串转移到被翻译的 ad-hoc 脚本（.java）和对象图中。缺点是翻译这些运行在不同的地区的套件，导致仅仅翻译了这些字符串，所以它仅仅工作在受到限制的一些文件中而不是在整个的套件中。

第三种方法在开发新的发布软件过程中是最有效的，但是在对象图的翻译过程中需要工具的帮助。

GTV 自动化项目的进化

在 2004 年间，IBM®Tivoli® Workload Scheduler (TWS)测试团队成立了一个非常小的测试自动化子团队。他们的中期目标是设计并应用一个完善的测试自动化的解决方案，它包含了全部产品的基本功能，并且重点是所有产品的接口。因为他们拥有清晰的工具指导和最佳实践，首先被他们关注的接口是产品的 GUI。

秋季，位于罗马的 TWS 测试团队和 Yamato 的 DBCS 测试团队在 DBCS 测试战略方面达成一致。这两个团队决定投入一部分资金用于找到一种可以为 DBCS 测试重用测试套件的最佳实践。

在2005年年初，我们成功地共同完成了 DBCS 测试战略，并且获得了一些已翻译好的应用于日本语环境的自动化测试脚本。此外，首个版本的全球化工具也可以使用了。从那时开始，我们改进了那个工具，并且我们把所有掌握的知识开发成为最佳实践。

文章的以下部分将介绍全球化工具，引入一种最佳实践，并且提供操作数据。

回页首

测试套件的全球化工具步骤

全球化测试套件共有四个步骤，前两个步骤由我们开发的自动化全球化工具处理（见图1）。

(A)提取信息目录
通过从原始的软件产品的源代码中提取翻译表达式，词典被自动生成。通常，软件产品将包含翻译文字的文件与逻辑源代码分离。翻译人员修改被提取的翻译文件，但是并没有修改基本的源代码。这可以被用于产品的翻译。对于我们的目的来说，我们通过比较原始的文件和相应的翻译文件来生成字典。

(B) 替换对象图
通过使用原始表达式提取翻译字典，Window Map 中的适当标签的字符串值被自动翻译为目标语言。

(C) 处理硬编码字符串
自动化测试支持软件的 Window Map 技术的目的不是用于抽象化测试套件的翻译，所以有可能一些术语被留在硬编码测试套件中。因为存在这种情况，从脚本中提取硬编码部分用于翻译是一个必须的过程。即使这里仅仅只有一些术语和工作量需要手工提炼，但是这是让测试套件工作正常的必要步骤。当然，当这些术语提炼结束后，您可以使用这个被生成的字典来进行翻译了。

(D) 使用非英文的数据
为了保证使用非英文内容可以正确地工作，您必须将输入到测试套件的数据改为非英文的数据。如果测试套件的输入数据也与源代码分离的话，修改这个数据将变得非常容易。例如，IBM® Rational® TestManager datamart 就是为这个目的进行工作的。

回页首

最佳实践

在使用自动全球化工具来生成和应用字典时需要考虑几件事情：

• 缩小数据过滤
• 使用变量表达术语
• 为同样的术语进行多种翻译的可能性
• 不存在于指定的字典中的术语
• 相应的正则表达式
• 对于专用于测试支持软件术语的需要

缩小并过滤数据
Window Map 抽象这个自动化工具；因此，许多数值不是翻译对象。两个行为可让 Window Map 忽略不必要的数据：

• 基于有价值的属性，在缩小翻译候选的属性之后使用字典。
• 使用过滤的功能忽略一些数据，因为这里有许多数据没有在字典中登记并，且也不是翻译的候选(例如，数值)。

使用变量表达术语

当使用变量表达术语来生成和应用字典时，需要特殊的考虑。这种情况下，字典有必要包含变量并且使用包含变量的字典。在翻译的时，您可以把它作为从一个不连续术语的翻译到另一个不连续术语翻译进行处理。当您从源代码中创建这个字典时，一个变量被定义为特殊字符(比如{0}，见图2)。测试套件为变量设定一个特定的值。因此，当使用被翻译的值替换变量时，对象图的代替品需要能够识别变量以能够填充这个特定值。

当您应用这个定义时，您需要考虑语法。许多语言是 S(主语) + V(谓语) + O(宾语)，但不是所有的语言都是这样。比如，日语和韩语是 S+O+V 的结构。（图3 显示了一个翻译的例子。）通过机器辅助的普通翻译例子,在分析与法时,考虑术语的发音部分是很有必要的。 但是在测试套件中创建的字典会从英文源代码和目标语言源代码中提取。这个字典非常简单，它包括了不仅仅是单词，还包括了整个或部分的句子，没有任何关于语音和句子结构的任何信息。它是通过使用基本样式匹配生成的（见图4）。因此，在测试套件中使用字典比使用实际的翻译更加简单。

为同样的术语进行多种翻译的可能性
在目标产品的源代码中，不同的变量可能使用同样的标签进行定义。有时，同样的标签在不同的用户界面有着完全不同的意思，所以它必须翻译成为不同的术语。这就意味着在翻译测试套件中的一个术语时，有好几个候选的翻译答案。在常规的机器辅助翻译中，这里没有什么问题，因为人们知道什么是多余的并且加以改正。测试套件在这一点上就有困难了，因为这里仅仅只有唯一的答案作为最后的翻译结果。

不存在于指定的字典中的术语
操作系统或者其他的软件有时显示除产品屏幕消息和信息以外的文本。，因为通过原始的表达式提取字典是不可能获取这些术语的，因此我们准备了另外一个字典。我们手工注册这些特定的术语。

相应的正则表达式
在创建自动化测试套件时，有一个使用正则表达式的提取方法。这是一个当数据不同但测试流程却几乎相同时通过提取它们来表达两个或更多流程（见图5）的方法。使用正则表达式可以减少开发的费用，并且有助于维护。
但是，很难通过使用被原始表达提取翻译字典定义的专有名词规范表达来匹配这个方法。在这种情况下，您在使用字典时必须增加考虑正则表达的处理。这与前面介绍的用变量处理术语很相似。这种情况西下，度量测试套件的唯一性是必然的。

对于专用于测试支持软件术语的需要
这依赖于自动化测试支持软件，但是 Rational Functional Tester 在内部使用标签 Message_message ID。同样，语言版本期望使用 "Message_" 作为某个语言环境中翻译标签的第一部分。因此，我们在这个字典中定义这个部分被 Functional Tester 独自使用。

回页首

IBM Tivoli Workload Scheduler 测试团队的经历

在我们学习过程中使用自动化全球化工具时，我们的工作量从2.7个人月的工作量减少到3人天的工作量。这样，所有的人工劳动会被用在处理那些工具所不能支持的特定术语上面。

有 69 个术语中需要人工修改(占到全部修改的3%)。因为如果一个人没有100%正确使用翻译，自动化测试软件是不会工作的，这一点非常重要。 通过准备将不自动化的度量和方法，这个数据的详细分类对实现100%自动化是十分必要的。

有213个条目(11%)的字符串是不需要相应的翻译的。这是被最初列出作为输出的，它与没有翻译的术语混在一起。如之前所说明的那样，通过增加这些术语到术语清单中来忽略和使用过滤器，这是很容易区分开的。我们注册了61个术语作为过滤器对象，结果是在213个术语中出现相同字符串的重复。

图6显示了详细的对象图的分类，在那里有来自产品术语的2092个条目以及106个 IBM Rational Functional Tester 工具使用的条目。这两种情况他们都可以正确地自动翻译（翻译目标 2,267个条目中的97% ：产品术语，2092；工具使用，106；以及未知， 69）。

回页首

结论

通过准许基本的代码品质和把测试者从常规的测试工作中解放出来，自动化帮助增进了测试团队的生产力。尽管几个可获得的最佳实践已经通过降低费用明显地提高了自动化测试的效率，但是我们还是要建议通过尽可能多的开拓自动的方法来最大限度的优化 ROI。

本文描述的翻译工具和最佳实践可以使测试团队以更少的资金获得更多的收益。本文还介绍了如何把资金投入在新技术的开发中，以及如何利用内部合作产生创新和可度量的效益。