《软件测试》第十章外国语言测试

10.0 前言
10.1 使文字和图片有意义
10.2 翻译问题
- 10.2.1 文本扩展
- 10.2.2 ASCII、DBCS和Unicode
- 10.2.3 热键和快捷键
- 10.2.4 扩展字符
- 10.2.5 字符计算
- 10.2.6 从左向右和从右向左读
- 10.2.7 图形中的文字
- 10.2.8 让文本与代码脱离
10.3 本地化问题
- 10.3.1 内容
- 10.3.2 数据格式
10.4 配置和兼容性问题
- 10.4.1 国外平台配置
- 10.4.2 数据兼容性
10.5 测试量有多大

10.0 前言

本章讲述如何测试为其他国家和语言编写的软件。本章重点包括：

为什么只进行翻译是不够的
单词和文本受何影响
足球和电话为什么重要
配置和兼容性问题
测试其他语言有多大工作量

10.1 使文字和图片有意义

以西班牙文为例。把英语翻译成西班牙文应该是轻而易举的事，对吧？那么是指哪个国家的西班牙文？西班牙的西班牙文吗？哥斯达黎加、秘鲁或多米尼加共和国的西班牙文呢？它们都是西班牙语国家，但是语言有极大差异，为一个国家编写的软件不能被其他国家很好地接受。

除了语言，还要考虑地域——用户的国家和地理位置。使软件适应特定地域特征，照顾到语言、方言、地区习俗和文化的过程称为本地化或国际化。测试此类软件称为本地化测试。

10.2 翻译问题

虽然翻译只是整个本地化工作的一部分，但是从测试角度看这是重要的一环，最明显的问题是如何测试用其他语言做的产品。那么，软件测试员或者测试小组至少要对所测试的语言基本熟悉，能够驾驭软件，看懂软件显示的文字，输入必要的命令执行测试。

软件测试小组一定要有人对测试的语言比较熟悉。当然，如果程序附带32种语言，难度就太大了。解决方法是委托本地化测试公司进行测试。全世界有许多这样的公司，它们几乎可以进行任何一种语言的测试。更多详情可以在因特网上查找“本地化测试”相关的主题。

10.2.1 文本扩展

可能出现的翻译问题中最直接的例子来自于文本扩展。实践证明，当英语被翻译为其他语言，用来表达同一事物时往往需要加一些字符。一个好的大拇指规则是每个单词长度预计增加100%——例如一个按钮上；语句和短小段落长度预计增加50%——通常是在对话框和错误提示信息中的短语。

因为这些扩展现象，所以必须仔细测试可能受到变长了的文本影响的软件部分。要找出没有正确换行、截断和连字符位置不对的文本，这种现象可能出现在任何地方——屏幕、窗口、框体和按钮等。还要找到虽然文本有足够的扩展空间，但这是通过把其他的文本挤出去来实现的情况。

变长了的文本还可能导致主程序失败，甚至系统崩溃。程序员可能为英语文本信息分配了足够的内存，但是对于翻译文本字符串就不够了。软件的英文版可能工作正常，但是德文版可能就在显示信息时崩溃。白盒测试员即使不认识任何外语单词，也可以发现这个问题。

10.2.2 ASCII、DBCS和Unicode

ASCII只能表示256种不同的字符——远不足以表示所有语言的全部字符。当开始为不同语言开发软件时，就需要找到克服该限制的解决方案。在MS-DOS时代常用的一个方法是使用称为代码页的技术，而且今天仍然在沿用。代码页实质上是ASCII表的替换，每一种语言用一个不同的代码页。如果在法国的PC上软件在用魁北克语运行，就会读入并使用支持法文字符的代码页。俄罗斯对西里尔字符使用另一个不同的代码页，依此类推。

某些软件使用称为DBCS（双字节字符集）的系统提供对超过256个字符的语言的支持。用两个字节代替一个字节来表示最多可容纳65536个字符。

代码页和DBCS在许多情况下已经足够了，但是会遇到一些问题，最重要的是兼容性问题。没有相应的代码页或者相互之间的转换，字符就不能正确解释，甚至根本认不出来就不能解释。解决这个麻烦的方法是使用Unicode标准。

Unicode为每一个字符提供惟一编号，无论何种平台，无论何种程序，无论何种语言。

因为Unicode是由主要软件公司、硬件生产厂商和其他标准组织所支持的世界标准，所以它变得更加通用。大多数主要软件应用程序都支持它。如果软件终究需要进行本地化，软件测试员和程序员就应该摆脱“古老ASCII的”束缚，而转向Unicode，以节省时间、减少烦恼和软件缺陷。

10.2.3 热键和快捷键

英语单词Search用法语说是Réhercher。如果在软件的英语版中选择Search的热键是Alt+S，那么在法文版中需要进行改变。在软件的本地化版本中，需要测试所有热键和快捷键工作是否正常，而且使用起来不困难。例如，需要按第三个键。同时，不要忘记检查英文热键和快捷键是否被禁用。

10.2.4 扩展字符

本地化软件，甚至非本地化软件中存在的一个常见问题是扩展字符的处理。回顾古老的ASCII码表，扩展字符是指普通英文字母A~Z和a~z之外的字符。这样的例子有重音字符，还包含许多在键盘上见不到的象形字符。如果软件中使用Unicode或者正确地组织代码页或者DBCS来编写，这就不成问题，但是*软件测试员从来不假设，因此这值得检查。

测试扩展字符的方法是找出软件中所有接受字符输入和输出之处。在每一处都尝试使用扩展字符，看能否与常规字符一样处理。对话框、登录画面和所有文本域都是合适的对象。通过调制解调器可以收发扩展字符吗？能使用扩展字符命名文件，甚至在文件中包含扩展字符吗？它们能否正确打印？在程序之间剪切、复制和粘贴扩展字符会怎样？

测试扩展字符是否被正确处理的最简单的方法是，把它们加入测试的标准字符所在的等价划分中。和处于ASCII表边界上容易导致软件缺陷的字符一起，加进一个Æ、一个Ø和一个β。

10.2.5 字符计算

与扩展字符有关的问题是软件在对其进行计算时如何解释。关于这方面的两个例子是文字排序和大小写转换。

测试的软件对文字列表排序或者按字母排序吗？也许在诸如文件名、网站地址等可选项目的列表框中进行？如果是，如何对文字排序？如果测试的软件在亚洲地区销售，那么是否意识到排序的依据是书写字符的笔画次序？要弄清楚测试的语言采用什么样的排序规则，并开发测试用例专门检查排列次序的正确性。

扩展字符计算打破的另一个领域是大小写转换。分类和按字母顺序排列只是两个例子。仔细查看软件确定是否还有对字母或文字进行计算的其他情况，比如拼写检查？

10.2.6 从左向右和从右向左读

翻译中有一个大难题是某些语言从右向左读，而不是从左向右读。大多数主要操作系统提供了处理这些语言的内部支持。利用操作系统的特性来实现这些需要大量的编程工作。从测试的角度来看，把它当作全新的产品，而不仅是本地化产品比较稳妥。

10.2.7 图形中的文字

另一个翻译问题是处理图形中的文字。它的影响是当软件本地化时，每一个图标都要改变，以反映新的语言。如果有不少这样的图标，本地化程序就会耗资巨大。要在开发周期的早期找出图形文本软件缺陷，而不要留到最后发现。

10.2.8 让文本与代码脱离

最后要讨论的翻译问题是白盒测试问题——让文本与代码脱离。这句话的意思是说 所有文本字符串、错误提示信息和其他可以翻译的内容都应该存放在与源代码独立的文件中。应该杜绝如下代码：

Print "Hello World"

大多数本地化人员不是程序员，也没有必要是。让他们修改源代码，进行语言翻译，既没有把握又有风险。他们要修改的是称为资源软件的简单文本文件，该文件包含软件可以显示的全部信息。当软件运行时，通过查找该文件来引用信息，不管信息的内容是什么。这就是说，对于白盒测试员来说，检查代码，确保没有任何嵌入的字符串未出现在外部文本文件中很重要。

这个问题的另一个变化形式是当代码动态生成文本信息时。例如，它可能用一些文本碎片拼凑成一个大的提示信息。问题在于各种语言的文字顺序是不一样的。虽然在英文中可以很好地拼在一起，但是用中文甚至德文独立翻译每一个短语，拼在一起就会发生混乱。所以不要把字符串直接放进代码，也不要用代码来连接字符串。

10.3 本地化问题

翻译文字和允许字符串包含不同字符和长度都不难。难的是修改软件使其适应国外市场。经过准确翻译和仔细测试的软件是精确和可靠的，但是如果程序员不考虑本地化的问题，程序就可能不够准确和高质量。一个软件可能外观和感觉很佳、容易理解、极其稳定，但是对于其他地方的人来说，它可能是完全错误的。首先保证产品正确地本地化，才能谈到下一步。

10.3.1 内容

如果测试将要本地化的产品，就需要仔细检查内容，以确保其适应使用该软件的地区。这里所说的内容是指产品中除了代码之外的所有东西。以下清单给出了解决本地化问题要仔细审查的各类内容（根据具体产品还有更多例子）：

范例文档
图片
视频
有边界争端的地图
包装
图标
声音
帮助文件
市场宣传材料
Web链接

最后要说的是，软件中包含的内容无论是文字、图形、声音还是别的，都特别容易引起本地化问题。在测试有关内容的这些问题时，如果对使用软件的地区文化不了解，一定要找一个熟悉该地区文化的人帮忙。

10.3.2 数据格式

不同的地区在诸如货币、时间和度量衡上使用不同的数据单位格式。与内容一样，这些都是本地化问题，而不是翻译问题。下表给出了在测试本地化软件时需要熟悉的不同种类的单位：

幸运的是，大多数设计用于多个地区的操作系统都支持这些不同的单位及其格式，有了这种内置支持，程序员编写本地化软件就容易多了，但也并非绝对安全。

注意：软件内部处理单位的方式并不需要和单位的显示方式一致。例如，在区域设置程序中的日期选项卡上显示了短日期格式m/d/yy。这并不是说操作系统只处理两位数字的年份（这样会出现千年虫问题）。在这种情况下，该设置仅意味着显示两位数字的年份，操作系统仍然支持4位数字的年份的计算。这是测试时要多考虑的一件事。

如果测试本地化软件，就需要对当地使用的度量单位非常熟悉。为了正确测试软件，需要从原版软件创建的测试数据中建立不同的等价划分。

10.4 配置和兼容性问题

测试软件与各种硬件和软件交互时出现的问题在遇到全新且不同的组合时会愈发扩大。此类测试不一定更加困难，只是任务栏更大了。这也对寻找和获取用于测试的国外版本硬件和软件的后勤准备工作提出了更多的任务。

10.4.1 国外平台配置

键盘也许是语言依赖性最大的硬件，但是根据测试内容，还有很多其他硬件也是如此。例如，打印机需要打印出软件发送的所有字符，并且在不同国家使用的各种规格纸张上以正确格式输出结果。从根本上来讲，软件可能会用到的任何外设都要在平台配置和兼容性测试的等价划分中考虑。

10.4.2 数据兼容性

与平台配置测试一样，当增加了本地化问题后，数据的兼容性测试也有了全新的意义。

在上图所示循环往复的数据传输过程中，由于存在所有的度量单位和扩展字符转换和处理，因此很多地方可能有软件缺陷。其中一些软件缺陷可能源于设计上的判断，例如，在应用程序之间移动数据时如果需要改变格式会怎样？格式会自动转换，还是会提示用户做出判断？会显示错误提示还是坚持移动数据并更改单位？ 在测试本地化软件的兼容性之前需要回答这些重要的问题。一旦明确了这些问题，就可以正常进行兼容性测试了——只需要在等价划分中增加一些测试用例。

10.5 测试量有多大

如果软件从一开始设计就考虑到了本章所述的问题，那么本地化版本中包含更多软件缺陷和增大测试量的风险就很小。相反，如果软件专门为美国英语市场编写，后来决定本地化为其他语言，那么明智的做法是把软件当作需要进行全部测试的全新版本。

另一个问题关系到整个软件产品中什么需要改变。如果本地化工作只限于修改诸如文本和图形等内容——不是代码——测试工作可能只是对改动进行合法性检查。但是，如果因为低劣的设计或者其他问题，基本代码必须改变，就要考虑测试代码，并且检查功能和内容。