本文将描述我们如何为了达到持续交付的目的，为全球化测试搭建创新的自动化框架，将其作为 GUI（Graphical User Interface）自动化测试和验收测试的环节，整合入 IBM Docs 产品整个持续交付的过程中。所有的脚本都集成进版本控制系统，一旦开发人员触发代码交付事件，所有全球化脚本会按照顺序在虚机池中自动运行，满足持续交付快速响应，缩短时间周期的要求。
概述
在传统的全球化测试中，自动化测试框架是以功能测试脚本作为参考，把全球化测试数据导入到功能测试脚本中，然而这种做法不能完全集中全球化相关的测试点。因为产品的功能点是巨大的，有些却与全球化测试点完全无关。这样为全球化做出来的自动化测试不但效率低，而且大量消耗人力和时间资源。
在持续交付的软件管理过程中，我们必须有信心确保所有的测试都是严格、可靠的。在传统的全球化测试中，自动化测试结果不能提供全球化测试要点的覆盖率的准确数据，并且它将错过关键全球化测试区域。在我们这个创新的框架中，将产品的页面元素和页面流程映射到全球化测试区域，以全球化测试要点为核心，设计自动化测试脚本，而不是功能点。这样能直击全球化测试点，不会把人力和时间浪费在功能方面的测试，并且能准确得出全球化测试点的覆盖率，测试结果不但高效可靠，而且是可衡量的。
架构介绍
全球化测试中创新的自动化框架的目的是映射全球化测试要点中测试区域和产品页面元素/页面流程，如图 1 所示，这可以使全球化相关的自动化测试结果严格和可靠。这个框架可以完全覆盖全球化测试区域，让自动化测试更全面，而到产品元素/流程的映射也让自动化用例执行记录更简洁，减少了由流程作为切入点而引起的脚本重复。并且可以集成在 IBM Docs 持续交付的渠道中。
图 1. 框架模型
我们选择了 Selenium+JUnit+ICU 结构，Selenium webdriver 是个开放而强大的 Web 测试类库，模拟用户真实操作浏览器实例，非常适合偏向用户体验层面的全球化测试，相比上一代它处理 Ajax 的能力更强，并且支持多种浏览器。但 Selenium 更偏向于操作而非测试，没有对测试用例执行和管理的功能，而这正是 JUnit 的强项。
测试本质上是一种期望，全球化测试是确保产品基本的国际化功能包括多语言支持、字符集和让产品在不同的文化习惯上能符合我们期望的测试，那么我们的“期望值”呢？我们希望脚本里的期望值是动态的、参数化的，不是写进脚本的硬代码，我们借助了 ICU 来达到这一点。
抽象全球化测试区域为测试类。每个映射链接是一个自动化脚本。页面是一个抽象的产品界面，包括页面元素、页面的功能和反射的页面元素分配。规则是对测试用例的 JUnit 结构装修的操作，使用一个自定义的规则，脚本设计师可以装饰和重新定义的测试案例，结合相关功能的实现。如图 2 所示。
图 2. 创新的全球化自动化测试框架
技术实现
在具体执行上，由于每个产品的特性不同，对应的全球化测试点也不尽相同。所以在为每个产品执行全球化测试之前，要先研究产品中与全球化有关的功能，生成针对特定产品特有的全球化测试区域, 这是初次筛选。
然后根据筛选的全球化测试区域, 选择性生成自动化测试类，这是二次筛选，过滤掉不适合自动化的测试区域，我们并不认为自动化的覆盖率要达到 100%，自动化的目的是为了降低成本，所以我们评估一个测试区域，认为如果手动测试比编写维护自动化脚本的时间更短，并且该测试区域回归性低，我们就会对该区域进行手动测试。
每个测试类都是一个测试区域的抽象，在测试类中，创建数个脚本，脚本是测试区域所对应的页面元素和页面操作。通过这种流程我们实现了全球化测试要点到待测元素的点对点的映射。
为了让自动化更好地支持全球化特殊的测试特性，我们创建了两个专门的 JUnit 规则和两个类。
Gassert Rule
LanguageSuite Rule
GData
GUtils
Gassert Rule，由于 JUnit Assert 是阻塞式断言，如果一个 assertEqueals 失败，测试脚本就会停止执行，这种特性是不适用于全球化测试的。全球化测试需要在一个功能点测试各种不同类型的数据，任何一类的数据失败都不能影响其余类型数据的执行。我们通过扩展 ErrorCollector，创建了一个新的规则，命名为 Gassert。当 assertEquals 失败的时候，测试会一直执行，不会打断。此时程序会标记一个失败的记号，并且自动截一张图记录在测试日志里面。这样就可以确保不同类型的全球化测试数据全部可以测试到，并准确定位缺陷的根源。测试结束之后会生成日志文件记录测试信息，可以通过查看日志文件来了解测试结果。
LanguageSuite Rule, 也是针对全球化测试的特性专门设计的。我们都知道，TestGUI 框架是不支持浏览器的 Locale 更改。为了提高自动化的效率，满足在全球化测试区域中切换浏览器 Locale 的需求，我们创建了 LanguageSuite Rule。以下面的代码为例，通过 Glan 定义了 3 个 Locale,NL(Dutch), zh-TW(Traditional Chinese) 和 FR（French)。
@Test
@Glan({“nl”,“zh-TW”,“fr”})
public void atCell()
{
……
}
这样，自动化脚本就会根据定义的 Locale 自动切换浏览器执行 3 次，生成 3 个测试日志，如图 3 所示。
图 3. 全球化测试中的自动化测试日志
GData，是用 dom4j 写的类，是为全球化测试要点中所有的测试数据做的抽象类。比如：我们想要使用全球化测试要点中的全球化数据，使用该类中的 getDataByld 方法就能根据测试数据的 ID 编号来抽取正确的数据，这样就不需要在脚本中以 hardcode 的方式列出所有的测试数据，只需要指定 ID。并且，我们把抽取出的测试数据通过 Unicode Hex 格式保存在 XML 文件中，这样就避免了因为编码带来的测试数据无法读取的问题。代码实例如下所示：
private static List<String> testData = new ArrayList<String>();
@BeforeClass
public static void beforeClass() {
int[] ids = { 3, 4, 5, 6, 7, 8, 9, 11, 20, 40, 44, 45 };
GData gData = GData.getInstance();
for (int id : ids) {
testData.add(gData.getDataById(id));
}
}
