GUtils 是一些工具方法的集合，它是一个 ICU4J 和为全球化所做的自动化框架的适配器。测试，总少不了实际值和期望值，我们希望输入输出都是参数化的，在多个 Locale 下运行时，应该根据当前的 Locale 有各自对应的输入和期望。框架中我们用 Gutils 工具类来达到这一目的，设计它是为了方便我们的架构调用 ICU4J，并且获得相关 Locale 下测试的正确期望值。比如一些 Locale 的货币格式、时间日期、数字和一些其他的与语言文件相关的测试点。这样我们在全球化测试时执行自动化结果就是可以信赖的。样例脚本中我们的输入值和期望值都是由 GUtils 根据 @GLan 声明的 Locale 参数自动生成的，我们通过 @GLan 和 GUtils（ICU4J）让全球化测试脚本实现参数化测试。
样例脚本如下所示：
DOH_NUM_010.atCellNumberFormatting public class DOH_NUM_010 extends BaseTest { @Drive private LoginPage loginPage; @Drive private FilesPage filesPage; @Drive private SpreadsheetEditorPage spreadsheetEditorPage; @Before public void before() { loginPage.login(); filesPage.go(); } @Test @GLan() public void atCellNumberFormatting() { String fileName = Utils.uniqueBaseName("newSpreadsheetInFiles"); spreadsheetEditorPage.focus(filesPage.newSpreadsheet(fileName)); log.info("Verify DOH-CUR-010 Number Formatting at Cell A1."); double number = 123456.789; String localeID = GUtils .getBrowserPreferenceLan(spreadsheetEditorPage.driver); String input = GUtils.getFormattedNumber(number, localeID, 3, false); String expected1 = GUtils.getFormattedNumber(number, localeID, 0, true); String expected2 = GUtils.getFormattedNumber(number, localeID, 2, true); spreadsheetEditorPage.driver.sleep(1); spreadsheetEditorPage.typeInCell("A1", input); spreadsheetEditorPage.menuFormat.click(); spreadsheetEditorPage.menuShowNumber.click(); spreadsheetEditorPage.menuNumberFormat0.click(); spreadsheetEditorPage.typeInCell("A2", input); spreadsheetEditorPage.menuFormat.click(); spreadsheetEditorPage.menuShowNumber.click(); spreadsheetEditorPage.menuNumberFormat2.click(); spreadsheetEditorPage.driver.sleep(1); String actual1 = spreadsheetEditorPage.getCellText("A1"); String actual2 = spreadsheetEditorPage.getCellText("A2"); ga.assertEquals("Verify " + localeID + " Number " + expected1 + " at Cell A1.", expected1, actual1); ga.assertEquals("Verify " + localeID + " Number " + expected2 + " at Cell A2.", expected2, actual2); } } |
框架的优势
基于注解的对象库
注解（@ 注解，from java1.5）是 JUnit4 的亮点，通过注解和反射，测试人员可以更清晰而便捷的构建自己的测试脚本，我们的框架也更倾向于利用这种特性。
首先是基于注解的对象库的建立。Selenium webdriver 脚本看起来更像是基于过程的，测试人员要操作页面元素，就要先搜索到它，脚本中往往充斥大量的搜索，让代码可读性变差，并且这些搜索的复用性很低，如果测试人员在下一个脚本中操作同样的元素，那依然要不厌其烦地再次搜索它，而基于注解的对象库的建立则解决了这一麻烦。只要在对象库中以 @Find("locate") 注解声明一个元素，并在类文件中以 @Drive 注解引入一个对象库，测试人员就可以像操作一个普通 Java 对象一样随意操作这个元素而不需要每次搜索它。我们会建立多个脚本库文件，每个脚本库是对同一页面元素和其操作的归类。
基于注解的多语言测试
品质和成本是一对矛盾体，IBM Docs 支持 30 多种 Locale，在过往的手动测试中，受限于时间成本，手动测试往往采用抽样的方式进行，即从 30 多个 Locale 中抽取有代表性的数个 Locale 来进行全球化测试。而其实多语言环境下的复数的全球化测试也可以看作是以语言为参数的参数化回归测试，在本框架中，可以用 @GLan() 声明一个脚本，脚本就会为每个支持的语言版本运行一次。借助于自动化的多语言环境测试，全球化测试实现了由点到面的转变，大大提高了覆盖率。
提高效率，降低人力成本
有一个自动化项目收益成本比计算公式：p=k*n/(a1+a2)，k=手动执行测试用例一次所花费的时间成本，n=自动化测试用例执行次数，a1=自动化测试用例的编写时间成本，a2=自动化测试用例的维护成本，如果 p>1，我们就认为自动化测试是正收益。
抽取一个脚本 DOH_NUM_010.atCellNumberFormatting 为例，p=0.25*30/(1.5+0.5)=3.75，节约了 3.75 倍的人力成本。
我们有一个更极端的特例：DIH_SCL_010.test，是全球化测试小组应开发者的要求测试了产品在 190 个语言代码下的兼容性，如果手动运行 190 个脚本无疑是不现实的，借助本框架就很快解决了问题（节约了 15 倍的人力成本）。
可靠并且易于推广复用
这个新的框架在 IBM Docs for SmartCloud 产品中已被成功实施。事实证明这个创新的框架是有效可靠的。此外，该框架适用于 JUnit +Selenium 的结构，它可以在大多数的 B/S 产品重用。
结束语
该框架使用 JUnit +Selenium 的结构，这是一个众所周知的 Web 开发和测试工具。它可以在所有的 B/S 结构的产品中使用。下一步，我们将在 CDL 全球化的产品团队分享这个框架，并帮助他们顺利实现持续交付。
