当今大多数软件发布范围是全世界，而不仅仅是某一个国家，某一种语言。Microsoft公司Windows 98配置了73种不同语言的支持，从阿富汗语到匈牙利语到越南语。大多数其他公司也这样做，意识到了英语国家的市场不过是潜在客户的一小半。为全球发布软件进行设计和测试具有商业上的重大意义。
     本章重点包括：
  1、为什么只进行翻译是不够的？
  2、单字和文章受何影响？
  3、足球和电话为什么重要？
  4、配置和兼容性问题？
  5、测试其他语言有多大的工作量？
10.1  使文字和图片有意义
     看到过某个器械或者玩具按字面意思粗劣翻译外语的用户手册吗？
     这就是粗劣的翻译。没有精心制作的外国语软件，对于不讲英语的用户可能就是这样的感觉。质量不高的翻译是逐字直译单词，要想使整个操作提示意思明确、实用，就需要投入更多的时间和精力。
     好的翻译工作者可以做到这一点，如果对两种语言都很熟练，就能够将外文翻译流畅表达原文的意思。遗憾的是，在软件行业中甚至连一个像样的好翻译都找不到。
     假如说西班牙文。把英文翻译成西班牙文是轻而易举的事，对吧？那么是指哪个国家的西班牙文？西班牙的西班牙文吗？哥斯达黎加、秘鲁或多米尼加共和国的西班牙文呢？它们都是西班牙语国家，但是语言有极大差异，为一个国家编写的软件不能被共他国家奶好地接受。即使英语也有同样的问题。不仅有美国英语，还有加拿大、澳大利亚和英国英语。在字处理程序中可以另人惊奇地找到colour,neigbour和rumour这样的单词。
     除了语言，还需要考虑地域－用户的国家和地理位置。使软件适应特定地域特征，照顾到语言、方言、地区习俗和文化的过程称为本地化。测试此类软件称为本地化测试。

10.2 翻译问题
 
    虽然翻译只是整个本地化工作的一部分，但是从测试角度看这是重要的一环。最明显的问题是如何测试用其他语言做的产品。那么，软件测试员或者测试小组至少要对所测试的语言基本熟悉，能够驾驭软件，看懂软件显示的文字，输入必要的命令执行测试。现在也许要申请一直没时间上的斯洛尼亚公共大学课程了。
 
   注意：
   软件测试小组一定要有人对测试的语言比较熟悉。当然，如果程序附带32种语言，难度就太大了。解决方法是与本地化测试公司进行业务联系。全世界有许多这样的公司，它们几乎可以进行任何一种语言的测试。更多详情可以在因特网上查找“本地化测试”相关的主题。
    不要求测试小组中的每一个人会软件所用的当地语言，只需要有一个人就行了。不知道软件说什么也可以检查许多内容。学会一点语言肯定会有帮助，但是从下面的讲解中可以看到没有特别流利的外语水平也可以进行许多测试工作。

10.2.1 文本扩展

    可能出的翻译问题中最直接的例子是称为文本扩展的现象。虽然英语有时显得比较啰嗦，但是实践证明，当英语被翻译为其他语言时，表达同一事物时往往需要加一些字符。一个好的大拇指规则是预计每个单词长度增加100%－例如，在一个按钮上。预计语句和短小段落长度增加50%－通常是在对话框和错误提示信息中的短语。
    因为这些扩展现象，所以必须仔细测试可能受到变长文本影响的软件部分。要找出没有正确换行、截断的和连字符位置不对的文本。这种现象可能出现在任何地方－屏幕、窗口、框体和按钮等等。还要找到文本没有扩展空间的情况，文本的部分内容会丢失。
    变长文本还可能导致主程序失败，甚至系统崩溃。程序员可能为英语文本信息分配了足够的内存，但是对于翻译文本就不够了。软件的英文版可能工作正常，但是德文版可能在显示信息时崩溃。白盒子测试员可以在不认识任何外语单词的前提下发现这个问题。

10.2.2 ASCII、DBSC和UNICODE
     ASCII只能表示256种不同的字符－远不足以表示所有语言的全部字符。当开始为不同语言开发软件时，就需要找到克服该限制的解决方案。在MS-DOS时代常用的，而且今天仍然沿用的一个方法是使用称为代码页的技术。代码页实质上是ASCII表的代用品，每一种语言用一个代码页。如果软件在法国的PC上碰到“魁北克”，就读入并使用一个支持法文字符的代码页。俄罗斯对西里尔字符使用另一个不同的代码页，依次类推。
    这个方法虽然有点笨，毕竟对于少于256个字符的语言还行，但是像中文、日文等包含数千个符号的语言就会出问题。某些软件使用称为DBCS（双字节字符集）的系统提供256个以上的字符。用两个字节代替一个字节最多可容纳65635个字符。
     代码页和DBCS在许多情况下足够了，但是对付不了某些问题。最重要的是兼容性问题。如果在德国计算机上运行英国了处理程序，读入一个希伯莱文档，结果可能乱七八糟。没有相应的代码页或者相互之间的转换，字符就不能正确解释，甚至根本认不出来。
     解决这个麻烦的方法是使用Unicode标准。
        Unicode为每一个字符提供唯一编号，
           无论何种平台，
           无论何种程序，
           无论何种语言。“Unicode是什么”引自Unicode学会网站 ，www.unicode.org
   因为Unicode是世界标准，由主要软件公司、硬件生产厂商和其他标准组织支持，所以它变得更加通用。大多数主要软件应用程序支持它。如果软件终究逃不过本地化的命运，软件测试员和程序员就应该摆脱“古老ASCII的束缚”，转向Unicode，以节省时间，减少烦恼和软件缺陷。
10.2.3 热键和快捷键
 
     软件的英文版中选择Search的热键是Alt+S,那么在法文版中也不会变。在软件的本地化版本中，需要测试所有热键和快捷键工作是否正常，而且易用－例如，不需要按第3个键。同时，不要忘记检查英文热键和快捷键是否被禁用。
10.2.4 扩展字符

    本地化软件，甚至非本地化软件中存在的一个常见问题是扩展字符的处理。回顾古老的ASCII表，扩展字符是指普通英文字母A－Z和a-z之外的字符。
    测试扩展字符的方法是找出软件中所有接受字符输入和输出之处。在每一处都尝试使用扩展字符，看能够与常规字符一样处理。对话框、登录画面和所有文本域都是合适的对象。通过调制解调器可以收发扩展字符吗？能使用扩展字符命名文件，甚至在文件中包含扩展字符吗？它们能否正确打印？在程序之间剪切、复制和粘贴扩展字符会怎样？
    提示：
    确保测试扩展字符是否正确处理最简单的方法是，把它们加入测试的标准字符所在的等价区间。和处于ASCII表边界上容易导致软件缺陷的字符一起，塞进一个AE，一个a和一个b.
10.2.5 字符计算

    与扩展字符有关的问题是软件对其进行计算时如何解释。两个例子是文字排序和大小写转换。
    如果测试的软件在亚洲地区销售，那么是否意识到排序的依据是书写字符的次序？上面的列表如果用中文写，排序次序就完全不同。要弄清楚测试的语言采用什么样的排序规则，并开发测试安例专门检查排序次序。扩展字符计算打破的另一个领域是大小写转换。这是一个问题，因为许多程序员在学校学会的大小写转换“技巧”是在字母的ASCII值上加、减32。在A的ASCII值上加32，就得到a的ASCII值。遗憾的是，这不适用于扩展字符。

10.2.6 从左向右和从右向左读

    翻译中有一个大难题是某些语言例如希伯莱文和阿拉拍文从右向左读，而不是从左向右读。请想象整个用户界面相对自身镜像是什么情形。幸好大多数主要操作系统提供了处理这些语言的内部支持。如果没有这一点，完成任务几乎是不可能的。即使如此，翻译这样的文本也不是容易的事。利用操作系统的特性来实现需要大量编程工作。从测试的角度看，把它当做全新的产品，而不仅是本地化产品比较稳妥。
10.2.7 图形中的文字
    WORD 2000中的字体处理方法有粗体、斜体、下划线和字体颜色的标准图标。由于它们使用英文字母B/I/U和A，因此对不讲英文的日本人毫无意义。它们还借助外观表达含义－B有一点黑，I是倾斜的，U下方有一条线－但是软件不是猜谜。
    它的影响是当软件本地化时，每一个图标都要改变，以反映新的语言。如果有不少这样的图标，本地化程序就会耗资巨大。在开发周期中要早一点找出图形文本软件缺陷，而不要留到最后发现。
10.2.8 使文字脱离代码

     最后要讨论的翻译问题是白盒测试问题－使文字与代码脱离。这句话的意思是说所有文本字符串、错误提示信息和其他真正可以翻译的内容都应该存放在与源代码独立的文件中。应该杜绝如下代码：
 print"Hello World"
     大多数本地化人员不是程序员，也没有必要是。让他们修改源代码，进行语言翻译，既没有把握又没有用。他们要修改的是称为资源文件的简单文本文件，该文件包含软件可以显示的全部信息。当软件运行时，通过查找该文件来引用信息，不管信息的内容是什么。无论信息是英文还是丹麦文，都是一样显示。
     这个问题的另一个变化形式是当代码动态生成文本信息时，例如，它可能用一些文本碎片拼凑成一个大的提示信息。代码可能把以下3个字符串：
1、“You pressed the"
2、包含用按键名称的变量字符串
3、"key just in time!"
    放在一起组成一条提示信息。如果变量字符串的值为stop nuclear reaction,整条信息就是： you pressed the stop nucluear reaction key just in time!

    问题在于各种语言的文字顺序是不一样的。独立翻译每一个短语，在英文中可以很好地拼在一起，但是在中文甚至德文中就会发生混乱。不要让代码分断字符串，也不要用代码连接字符串。

10.3 本地化问题
    如前所述，翻译问题只是全部问题的一半。翻译文字和允许字符串包含不同字符和长度都不难。难的是修改软件使其适应国外市场。
    提醒：
    经过准确翻译和仔细测试的软件是精确和可靠的，但是可能不够准确和高质量。一个软件可能外观和感觉最佳，容易理解，极其稳定，但是饱含其他地方的人来说，它可能是完全错误的。先保证产品正确地本地化，才能谈到下一步。

10.3.1  内容

     如果用美国英语编写的新软件百科全书包含英国足球、女王、电话亭、左侧行驶。在美国，soccer ball（美国足球）与football（英国足球）不是一回事！司机不能左侧行驶！这些对美国人来说可能不对，但是在其他国家则可能是千真万确的。如果测试将要本地化的产品，就需要仔细检查内容，以确保其适应使用该软件的地区。
     这里所说的内容是指产品中除了代码之外的所有东西。以下清单给出了解决本地化问题要仔细审查的各类内容。不要把它当做完整清单，根据具体产品还有更多例子。考虑一下软件输送到其他国家还会有哪些内容可能出问题。
  范例文档      图标
  图片          声音
  视频剪辑      帮助文件
  有边界争端的地图   市场宣传材料
  包装           WEB链接

 鼻子太长
   1993年，Microsoft公司发布了两个儿童产品Creative WriterT和Fine Artist.这两个产品用一个名叫McZee的帮手形象来指导孩子使用软件，为选择他的外貌、肤色、举止和个性等，公司进行了大量研究。最后他变成一个面目奇特的家伙，龅牙、深紫色皮肤、大鼻子。
   遗憾的是，花费巨大精力绘制完成这个将在屏幕上出现的动画人物之后，从Microsoft国外办事处打来电话。他们曾经拿到了该软件的预览版，经过审核之后认为无法接受。原因如下：McZee的鼻子太长了。在他们的文化中，有大鼻子的人不是一般人，大鼻子总是令人与各种反面人物形象联系起来。他们说除非该产品进行该地区的本地化，否则根本没人买。
    由于为每一个市场单独创造不同的McZee形象代价太高，因此艺术创作以拣回原来扔掉的形象告终，McZee用他第一次设计的鼻子。
    最后要说的是，软件中包含的内容无论是文字、图形还是别的，都可能引起本地化的问题。如果对使用软件的地区文化不了解，一方面测试有关内容的这些问题，另一方面一定要找一个熟悉该地区文件的人帮忙。

10.3.2 数据格式
    不同的地区使用不同的数据单位格式，例如货币、时间和度量衡。与内容一样，这些是本地化问题，而不是翻译问题。一个用美国英语发布的使用英尺的程序不能只靠文本翻译变为使用分米，而是需要修改代码，以改变基本的公式和风格线等等。

    幸运的是，大多数设计用于多个地区的系统都支持这些不同的单位及其格式。
    注意：
    单位如何显示不一定说软件内部也是这样处理。例如，在Regional Setting程序中的Date选项卡上显示了短日期格式m/d/yy。这并不是说操作系统只处理两位数字的年份（这样会出现千年虫）。在这种情况下，该设置仅意味着显示两位数字的年份，操作系统仍然4位数年份的计算。这是测试时要多考虑的一件事。
    如果测试本地化软件，就需要对当地使用的度量单位非常熟悉。为了正确测试软件，需要从软件原版的测试数据中建立不同的等价区间。

10.4 配置和兼容性问题
     第8章和第9章中关于配置和兼容性测试的信息对于软件本地化版本测试相当重要。测试软件与各种硬件和软件交互所产生的问题在遇到全新的不同组合时愈发扩大。此类测试不一定更加困难，只是任务量更大了。这同时对寻找和获取测试用的硬件和软件国外版的后勤准备技巧提出了更高要求。

10.4.1 国外平台配置
     Windows 98支持73种语言和66种键盘，通过Keyborad Properties对话框和Control Panel来设置。
     键盘也许是语言依赖性最大的硬件，但是根据测试内容，还有其他硬件也是如此。例如，打印机需要打印软件发送的所有字符，并且在不同国家使用的各种规格纸张上正确格式化输出结果。如果软件使用调制解调器，就可能存在与电话线或者通讯协议差异有关的问题。从根本上讲，软件可能会用到的任何外设都要在平台配置和兼容性测试的等价区间中考虑。
     注意：
     在设计等价区间时，不要忘了应该考虑构成平台的所有硬件和软件，包括硬件本身、设备驱动程序和操作系统。在MAC机上使用法文打印机、英文操作系统以及软件的德文版，可能是一种非常合理的用户配置。

10.4.2 数据兼容性
     与平台配置测试一样，当增加了本地化问题之后，数据的兼容性测试也具有了全新的意义。在测试本地化软件的兼容性之前要回答这些重要的问题。一旦明确了这些问题，就可以正常进行兼容性测试了－只是在等价区间中增加一些测试案例。

10.5 测试量有多大

     笼罩在本地化测试上的未定义之数是软件测试量有多大。假如花了6个月测试美国英文版，那么测试法文本地化版本也要花6个月吗？会不会因为配置和兼容性问题增加而花费更多时间？
     这个复杂的问题要由以下两个问题来回答：
  1、项目从一开始就本地化了吗？
  2、本地化版本中更改程序代码了吗？
     如果软件从一开始设计就考虑到了本章所述的问题，那么本地化版本包含更多软件缺陷和测试量增大的风险就很小。相反，如果软件专门为美国英语市场编写，后来决定本地化为其他语言，那么把软件当做需要全部测试的全新版本是明智的做法。
     另一个问题关系到整个软件产品中什么需要改变。如果本地化工作只限于修改诸如文字和图形等内容－不是代码－测试工作可能只是对改动进行合法检查。但是，如果是因为设计失误或者其他问题，基本代码必须改变，就要考虑测试代码，并且检查功能和内容。
  注意：
     本地化测试量是一个风险抉择，与所有的测试一样。随着测试经验的增长，就会知道做决定的过程有什么变数。
  注意：
     知道自己要本地化的产品的开发小组彩用的一个方法是测试本地化能力。也就是说，他们测试产品的第1个版本，假设它最终被本地化。白盒子测试员检查文本字符串、试题单位处理、扩展字符的代码以及其他代码级问题。他们甚至会“伪造”本地化版本。黑盒子测试员仔细审查说明书和产品本身，检查图形文本和配置等问题。他们会利用“伪造”版本进行兼容性测试。
     最终，当产品本地化时，以后将会出现的许多问题已经被找出并修复了，本地化工作变得比较轻松，费用也不高。

10.7 小测验
      1、翻译和本地化有何区别？
      2、要了解他国语言才能测试本地化产品吗？
      3、什么是文本扩展，由此可能导致什么样的常见软件缺陷？
      4、指出扩展字符可能导致问题的一些领域。
      5、使文本字符串与代码脱离为什么重要？
      6、说出在本地化程序之间可能变化的一些数据格式类型。