前面我们已经多次提到了伪本地化build,今天我们就来谈谈它。
软件伪本地化build从字面意思来理解就是一个假的本地化build。伪本地化的英文是“Pseudo Localization”，它不是软件真正本地化，而是在源语言软件的基础上，按照一定的规则，将需要本地化的文本使用本地化文字进行替换，模拟本地化软件的过程。经过这种处理得到的软件的界面将包含本地化文字，看起来像本地化软件，所以称为“伪本地化”。

在进行国际化测试时，我们需要保证被测软件有足够好的可本地化能力，也就是我前面说过的国际化测试第三级测试，用英文build是发现不了国际化测试第三级的问题的，但是国际化第三极的问题又不能等到本地化build出来再进行测试然后进行修改，等到那个时候已经太晚了，所以在国际化测试过程中就出现了伪本地化build.

伪本地化build主要是对资源文件进行处理，给资源文件中的每一个字符串加前缀和后缀，有的时候会使用自动翻译将资源文件直接范围，然后做一个伪本地化build.

使用伪本地化build可以确定是否存在硬编码的字符串，如果所有的字符串都是增加了前缀或后缀，或用本地化字符替换了，那么运行软件时出现的英文字符串则属于不能本地化的硬编码缺陷，即这些英文字符没有包含在可以本地化的资源文件中。

使用伪本地化build还可以发现字符扩展的问题，大家都知道，一个语言翻译到另外一个语言时，字符的长度会发生变化，如果界面上没有预留足够的空间，则会出现翻译后字符串的裁断。在使用伪本地化build时，因为字符串在英文字符串基础上增加了前缀和后缀，长度会变长一些，如果界面上控件的长度没有考虑国际化，则很可能出现截断问题。比如button,label,dropdown list等名字或值显示不完整，影响用户阅读和使用。

使用伪本地化build进行测试，因为在字符串在英文基础上增加了前缀和后缀，还可以发现缓冲区溢出问题，如果你在使用伪本地化build上测试发现功能问题很可能是缓冲区溢出问题。

使用伪本地化build进行测试,还可以发现字符串串联的问题，就是一个长字符串是根据程序运行过程中变量的值由两个或多个字符串拼接而成，这样会影响本地化的翻译工作。我们可以根据字符串的前缀和后缀来分析字符串，判断这类问题。

使用伪本地化build还可以发现一些对话框大小的硬编码问题，如果对话框大小不能根据对话框上的显示文字多少进行变化，则会影响本地化翻译后的显示。

关于伪本地化build上面由于字符长度扩展引发的截断问题我们还要分不同的情况，这些问题有可能不需要修改代码，而是直接调整资源文件就可以改好，这样，这些问题就可以直接交给本地化的工程师去做，国际化的开发就可以不去关注了，如果出现的截断问题必须通过修改代码才能修复，则必须由国际化开发人员修复。但是这种问题测试人员不好判断，可以寻求开发人员的帮助，在做伪本地化测试前，请开发人员分析程序UI显示是否可以通过资源文件调整，如果可以通过资源文件调整来改变UI显示，则测试人员在测试过程中可以不关注截断类问题，省去很多报bug的时间。

在使用伪本地化build测试过程中也可能会发现有些问题是伪本地化build的问题，和产品本身无关，这个主要看做build的人的质量，比如字符加前后缀，很可能有些比较特殊的地方没有加上，或有问题，这些具体问题在做项目过程中要具体分析。

 

 

 

看到有人在问全球化和国际化的关系，国际化和本地话的关系，我们今天就简单说说这三者之间的关系。

我们所说的全球化，国际化，本地化都是针对软件来说的。简单的来说全球化=国际化+本地化。

所谓的全球化，就是软件的目标市场并不是一个国家，而是多个国家或区域，我这里借用一下崔启亮老师的书里面的定义

 

全球化软件是为全球用户设计，面向全球市场发布的具有一致的界面，风格和功能的软件，他的核心特征和代码设计并不仅仅局限于某一种语言和区域用户，可以支持不同目标市场的语言和数据的输入，输出，显示和存储。全球化软件也称为国际化软件，全球化对应的英文是Globalization,缩写为G11N.G是首字母，N是尾字母。11表示在首字母G和尾字母N之间省略了11个字母。

 

其实全球化软件按照字面意思理解的话也可以叫国际化软件。全球就是针对多个国家的意思，国际化也是针对多个国家的意思，但是全球化软件在开发过程中又可以分为两个大的部分，一般叫做国际化和本地化，为了将此国际化和彼国际化分开，所以叫做全球化。  所以全球化=国际化+本地化

这块主要是定义的问题，如果把一个面向全球用户的软件叫做国际化软件也可以，但是如果在做这个软件的公司内部就不好区分这个大的国际化和他下面细分出来的国际化，所以一般就叫做全球化。所以如果你是给公司外部的人来说，不关注技术细节的话，说你的产品是全球化软件或国际化软件都可以。但是公司内部具体去做这个软件的话最好还是将全球化和国际化定义严格分开。崔启亮老师的书<<国际化软件测试>>，我感觉名字叫做全球化软件测试可能会更好一点，当初我看了名字我还以为是讲做国际化的，结果发现国际化和本地化都讲。

 

下面我们来说说国际化和本地化的关系，其实我和项目组里的人合作了很长时间，他们有时候也是分不清楚国际化和本地化，大家对本地化可能了解的比较多，因为这个也比较好理解，就是要做不同语言的本地化版本。但是国际化具体做什么他们就不是特别清楚，所以两个老是搞错。

我们还是来引用崔老师的定义：

软件国际化就是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化习俗，能够在创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。国际化的英文单词是Internationalization,所写为I18N,其中I是首字母，N是尾字母。18表示在首字母的I和尾字母N之间省略了18个字母

 

软件本地化是将一个软件产品按照特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。本地化的英文对应Localization,缩写为L10N,其中L为首字母，N是尾字母，10表示在首字母的L和尾字母的N之间省略了10个字母。

 

我们从上面的描述上去分析，国际化需要保证功能和代码设计能处理多种语言和文化习俗，在创建不同语言版本时，不需要重新设计源程序代码，这个说明国际化实际上是为本地化服务的，其实在软件开发过程中加入国际化的设计就是为了更好，更快的出本地化版本。国际化并不针对某一特定语言来做，国际化做好了的话，你的软件就可以处理多种语言和文化习俗，语言也就是各种国家的文字显示，输入输出，各种语言的操作系统上运行，习俗通常指的是区域相关的，比如日期时间显示格式，数字，货币符号，姓名显示顺序等。当你的软件如果国际化做的比较好时，在做本地化时就不需要重新设计或修改源代码,只需要进行资源文件的翻译，然后出本地化的build. 而本地化是针对特定语言的，特定市场的，如果该语言和该市场没有特殊要求，那么简单的说就是一个将资源文件进行翻译，然后出一个本地化的build，然后测试该本地化build上本地化问题，比如字符串没有翻译等，这个是全球化软件最理想的情况，但是往往个别国家或区域对软件在基础功能上又有些特殊的要求，本地化组需要在基于已经发布的英文版上增加特色功能然后自己发布。

 

我们简单的总结一下本地化测试和国际化测试，基于比较理想的全球化软件开发模式，各个国家没有自己特殊的需求

1 测试需要用的操作系统：

国际化测试人员一般会基于多个语言的操作系统进行测试，因为国际化测试需要负责软件对各个不同国家操作系统的支持。一般至少选择两个，亚洲为代表的比如日语，和欧洲为代表的，比如德语。

本地化测试人员一般只在某一个特定语言的操作系统进行测试。除非该测试人员要负责多个语言的本地化。

2 测试的build

  国际化测试一般用英文build和伪本地化build进行测试，英文build一般主要用来发现国际化第一级和第二级的问题，伪本地化build主要用来测试国际化第三级的问题。

  本地化测试一般用已经翻译过的本地化build.

3 bug的处理方式

  国际化的bug一般都是需要通过修改代码才行修改好

  本地化的bug一般都是通过修改翻译，修改资源文件来修复，不需要修改代码(这个是理想情况。)

4 测试的核心关注点不同

  国际化测试关注针对各种语言的支持，概括来说就是对DBCS，Hi-ASCII的支持，包括显示，输入，输出等，还有对于不同国家的时间日期格式，货币符号显示等

  本地化测试主要关注自己测试的语言上的输入，输出，显示，所测语言上一些特殊性等。

5测试进入项目的时间不同

  国际化测试一般很早就开始进入项目，基本上是项目开始不久，需求基本确定后。

  本地化测试一般进入项目时间较晚，一般是国际化测试进入到中期或快结束时进入。

从以上可以看出国际化和本地化的关系，概括来说就是好的国际化设计可以使软件更容易的本地化，减少本地化过程所需要的时间和精力，缩短发布时间。同理，国际化测试人员做的好了，本地化测试人员的工作就比较容易了。

 

 

在国际化测试中经常会提到hardcode的问题，也就是硬编码问题，我们今天就说一下这类问题。其实在前面我们都介绍过这块，今天主要把和hardcode有关的东西放在一起。

一般通常说的hardcode是指需要翻译的字符串没有提取到资源文件中。这些需要提取的字符串基本上包括了界面上显示的所有文字，包括lable，buttong的名字，提示信息，图片上的文字，如果log也需要本地化，那么记录log时也要将各种字符串提取到资源文件中。这一类的hardcode问题基本上属于国际化第三级的问题。这种问题其实一般不影响功能，但是会影响本地化的翻译工作，因为本地化翻译时一般是对资源文件里面的string进行翻译，如果string没有提取到资源文件中而是在代码中，那么这些在代码中的string翻译时将会漏掉，在本地化的版本上就会有没有翻译的字符串，这种问题一旦发现，就必须修改代码，将在代码中的string全部提取到资源文件中，然后需要对这些添加的string进行重新翻译，其实修改这类问题不难，一个问题可能几分钟或半个小时就改好了，主要是发现问题后会牵扯到资源文件修改重新翻译的问题，而一般翻译都是请第三方的专业翻译公司来做的，所以总的时间成本还是挺高的，所以这类问题最好在本地化介入前发现。

另一类问题，在国际化第一级中的一些功能问题其实也是由hardcode引起的，但是和第一种有着本质的区别。我在前面也提到过一些。将一些和系统有关的东西硬编码，没有使用系统变量，这种问题一旦发现将是非常严重的功能问题，一般情况下会导致某个功能不能正常使用。最常见的例子，默认安装路径C:\Program Files，这个也是我最喜欢举的例子，因为很多人喜欢用这个路径，但是微软在做本地化操作系统时，在德语等操作系统上，Program Files目录的名字也翻译了，给后来做应用程序的人就埋了个炸弹。还有一些和系统用户名组名有关功能也要重点关注，管理员在英文操作系统下为Administrators，俄语操作系统上为Администраторы，波兰语操作系统上为Administratorzy。如果直接用administrators,那在俄语，波兰语等操作系统上就有问题。避免这类问题的方法主要是在开发软件时要有国际化开发的思想，任何和系统有关的东西都不能假设其他操作系统和英文操作系统一样。

说到硬编码问题，我们就不得不提一下过度翻译(over translation)问题,如果将一些不需要翻译的东西提取到资源文件中，那么也会出问题，可能会过犹不及，比如说一个string中包含一个日期，这个日期是一个固定日期比如2010-12-31，如果将日期和其他字符一起提取到资源文件中，则这个日期可能不会根据系统的日期格式来进行变换，会引发另外的国际化问题。还有一种就是比如临时文件的路径 %TEMP%,如果把路径也提取到资源文件中，如果翻译人员将该路径进行了翻译，则log功能会由于找不到对应的路径而不能工作。过度翻译往往会引发功能问题，而不仅仅是UI问题。

关于第一种hardcode的测试比较简单，主要是在做测试工作中使用伪本地化（简单的说就是给显示的英文字符串加前后缀）build来进行测试，如果在伪本地化build上面发现了英文字符串，则很可能是一个hardcode问题。关于什么是伪本地化build和伪本地化build的作用我们在后面再谈。在测试过程中主要能确保每一个界面都跑了，所有有字符串的地方都检查一下，基本上就不会漏掉问题。根据我的经验，国际化测试人员最喜欢的bug估计就是这种hardcode问题了，发现起来比较简单，一个产品中，一般情况下这类bug是最多的，比较容易凑数量，而且一旦发现就肯定会重现，验证起来也比较容易。

第二种hardcode的测试就比较麻烦，因为哪些地方容易出问题很难说，往往是靠经验积累的，所谓吃一堑长一智，就是靠大家在测试中不断地积累，整理一些相关的测试点，然后在测试过程中重点关注。有些问题如果不在特定的操作系统上进行测试，估计黑盒测试测一辈子都测不出问题。做国际化开发和测试的在分析系统功能时，要有国际化软件开发的意识，就是看到某个功能的描述，就能想到可能有哪些国际化的风险，这个也是在日常工作中慢慢积累的，其实这个和一般的测试类似，比如出现了翻页功能，那肯定要测试翻到最后一页和翻到第一页这两种情况类似。

过度翻译问题也是类似的，要靠经验积累，就是大家在用伪本地化build测试时要对字符串敏感，不要看到全部字符串加了前缀和后缀就高兴了，不是hardcode问题了。对字符串中的日期，路径之类的要特别关注，看看是不是特殊处理了。

 

自动化测试一直是一个比较热门的话题，我今天不是谈怎样去做自动化的框架或具体的自动化技术的细节，其实自己在这方面也只是个外行，今天主要谈一下自动化测试在国际化测试中应用的一些注意点。我所谓的自动化指的是基于GUI回放机制的功能自动化。
以我个人在自动化方面的经验，指望自动化工具去帮你发现测试遗漏的问题基本不可能，自动化需要测试的测试点基本上是从手工测试的用例中挑选的，在自动化测试中的检查点在手工测试用例中肯定都有,如果你的目的是靠自动化去发现问题，建议放弃这个打算。目前自动化测试应用基本上都是在做回归测试或者BAT(Build Acceptance Test)测试。

当维护一个已经比较成熟的产品时，如果经常需要对当前产品做一些小改动，测试人员往往关注的是改动的功能点测试，但是没有改动的部分就不会有问题吗？没有经过测试谁也不敢保证。如果每次改动都是很小的一部分，而其他功能的核心部分都需要重新测试一遍，测试人员的压力会相当大，而且这样重复的工作也会导致测试人员工作的积极性下降，如果对于产品的核心功能中绝大多数可以自动化的测试点进行自动化，测试人员在做测试时只重点关注改动的部分和各个功能之间有关联的部分，这样测试人员的精力将更集中，也可以花更多的时间去考虑改动对关联功能的影响，整个测试效率会大大提高，而且可以保证产品的核心功能没有问题。
另一种使用自动化的场景是BAT测试，我们在测试过程中经常会选择一些非常重要的测试用例作为BAT的case，如果这些case全部pass,我们才会进行下面的测试，如果这些Case中有一个或多个fail了，我们会要求开发人员重新出build,这些case的选择其实和维护产品过程中回归测试的核心功能测试case选择差不多。这样就出现了一个问题，我们测试人员拿到的build可能过不了BAT测试，而且有时候是连着几个build过不了BAT测试，这样会使测试人员产生抱怨，也影响大家工作的积极性，如果有可能的话，将这些BAT里面的Case做成自动化的Case,这样新build来的时候，自动化工具就可以帮你判断这个build是否有问题。如果没有问题，测试人员才进行正式的测试。

其实国际化的测试如果想去做自动化测试，也和上面两种情况类似，而且通常国际化需要自动化的case都是基于英文对应的自动化case进行修改或复用。我们现在是假设已经有了一套可以在英文上正常运行的脚本，怎么让他们能在本地化的操作系统上运行，以自动化测试工具QTP为例，首先，原来的自动化脚本是在英文操作系统上面运行的，你需要让脚本能在本地化的操作系统上面运行，其次，如果要支持本地化字符的输入输出，你就要将每一个和输入有关的地方都写在脚本里，比如输入框，下拉框的选择等，因为一般做BAT脚本时，输入框如果有默认值，一般会使用默认值，下拉框也是用默认值。如果你要测试输入本地化字符，用默认值肯定是不行的。
我们以第一个点为例，要保证脚本能在各种本地化操作系统上运行，这个其实和手工测试差不多，你要考虑哪些因素可能会影响脚本在本地化操作系统上运行，比如一般情况下软件默认会安装到C:\Program Files，但是德语等语言就不是这个目录，那么你的脚本就需要修改，当安装软件时脚本就要考虑不同的操作系统使用不同的默认安装路径。还有，对于messagebox等，在英文下显示为yes,no, 在中文会显示为是(Y),否(N)，还有一些其他类似的标准控件，他们都是实现了MUI的，在不同的操作系统下他们的text属性就不一样。如果你的对像识别属性中包含了text属性，脚本在本地化操作系统上运行就识别不了针对这些标准控件的操作，因为找不到对象，在QTP中，针对每一个需要测试的本地化的操作系统都必须有自己的object repository，你可以在英文的object repository基础上，使用update from application功能，直接去更新对象的属性就可以了。以上两个点是我在用QTP做国际化的自动化测试中感觉需要注意的地方。并不是所有的国际化测试点都适合用自动化来做的，比如UI上面的check,如果你去写脚本去check,脚本的check点会很多，维护也不好维护，成本太高，一般可以采用让QTP运行时将跑过的所有界面都抓图下来，然后人工检查的方式，你只要在options-->run里面设置Save still image captures to results 为always就可以了。这样通过运行时自动抓的图可以发现一些UI方面的问题。

其实在实际过程中也遇到过一些其他问题，有些可能是QTP自己对国际化支持的问题，比如一个输入框，脚本中有给其输入值的语句，在英文操作系统下跑没有问题，但是在日文操作系统下运行就有问题，通过回放脚本，你可以发现运行时有输入的动作，但是没有回车事件，这种情况就需要针对问题出现的问题进行特殊处理，这些实际上又都回到了自动化脚本的写法问题上，就不详细写了。至于其他的自动化测试工具如何来做国际化的测试，可能和用QTP有些细节的不同。但是我想核心的东西应该是一样的。

国际化测试里面有一种MDP的测试，MDP(Multi-lingual Data processing)就是多种语言数据处理。指的是产品具有处理多种语言数据的能力。
MDP一般是针对Server/Client的产品，当Server端安装到服务器上后，它可能需要处理来自不同国家的数据，比如client端发送的数据是日文，德语。针对MDP的测试主要是在Server端装上需要处理的语言，比如说一个英文的Server需要装上东亚语言包，当不同的client发送不同的语言到Server时,Server都可以正常显示和处理。

前面提到了一般程序的MUI测试，国际化里面还有一块是针对Web程序的MUI测试。测试方法是大同小异。
Web程序MUI有两种方式，一种是根据操作系统语言来显示对应的语言，然后用户可以在界面上选择换语言的方式来实现，这种方式在一般的程序MUI实现时也可能会遇到。也就是你选择选择什么语言系统就显示什么语言。因为你能选择的语言列表就是该软件支持的语言列表，该程序肯定要包含该语言列表里面的资源文件。

另外一种是根据浏览器的语言首选项来显示对应的语言.以常用的IE浏览器为例，进入Internet 选项--〉语言,在语言首选项里面大家一般看到的可能是中文或英文，这两种是根据大家操作的语言默认设置的，你可以添加一些其他语言，比如日语，韩语，德语等，所有添加的语言按照从上到下的顺序有一个优先级，当你去测试一个MUI的Web程序时，首先还是确定该MUI程序具体支持哪些语言和默认的语言，然后去语言首选项里面添加语言，比如把程序支持的语言放在第一位看是否正确显示对应的语言，把程序不支持的语言放在第一位，把程序支持的语言放在第二位，第三位等，去看程序是否用放在第二位的语言或第三位的语言去显示。 如果语言首选项里面的语言被测程序都不支持，那程序会用默认的语言比如英语来显示。 当把程序不支持的语言放在第一位，把程序支持的语言放在第二位，或之后，不同的软件需求可能不一致，简单一点的，如果语言首选项的第一位被测程序不支持，则直接用默认语言来显示，复杂一点的，遍历语言首选项，找到第一个被测程序支持的语言，然后用其显示，这个根据项目具体要求来看。

以上是针对Web程序的MUI测试总结。

MUI产品一般有两种方式，一种是一个安装包，安装包中包含了该产品支持的所有语言对应的资源文件，这种安装包的好处是只安装一次，缺点是安装包可能会比较大，因为包含了所有语言对应的资源文件。另一种形式是一个安装包加多个语言包的形式，用户可以在安装了英文产品后，根据自己需要来安装不同的语言包。这种形式的好处是安装包比较小，只包含自己需要的资源文件，缺点是语言包需要单独安装，但是两种形式的测试点大同小异。

测试MUI时首先要确定当前测试的产品具体要支持哪些语言,还要确定被测产品的默认语言是什么。所谓的默认语言就是当我们的被测产品没有当前操作系统的语言对应的资源文件时我们会自动选择使用哪种语言。在测试MUI产品时，一般都会使用支持MUI的操作系统进行测试。 MUI测试主要有以下几个方面:
1 将被测产品安装到某一个语言的操作系统上时(假设被测产品包含该语言对应的资源文件)，所有的字符串显示的语言都要使用和操作系统一致的语言。同时产品功能没有问题。功能测试是每一个测试点都需要保证的，测试时一般不会进行全面测试，只选择一些核心的功能点进行测试。
2 当操作系统的语言从语言A切换到语言B时(假设被测产品包含语言A和B对应的资源文件)，被测产品的所有字符串显示语言会从A切换到B
3 被测产品安装到操作系统上后，检查安装目录下包含了所有需要支持的语言对应的资源文件。一个MUI产品一般支持多个语言，测试时有可能没有足够的测试操作系统来逐一的对每种语言进行安装测试，这种情况下一般只检查是否包含了所有的资源文件。
4 将被测产品安装到一个该产品不支持的语言时，产品会显示它支持的默认语言。一般情况下默认语言为英语。

以上是工作中可能会用到的一些测试点，后面有时间再继续补充

国际化测试过程中经常会提到问题字符，顾名思义，所谓的问题字符就是当你使用它时会引起国际化问题的字符。

这里有一个关于问题字符的blog,针对不同的语言列举了一些问题字符，大家在测试过程中可以去使用。相当于一个测试数据集

http://blogs.msdn.com/b/michkap/archive/2007/06/12/3251648.aspx

关于问题字符，大家也可以参考以前的一个帖子。

http://bbs.51testing.com/thread-109540-1-4.html

今天谈谈国际化测试的第四级--双向文字识别能力
一般的国家，文字显示和界面布局现在都是从左到右的，从上到下的。但是像一些阿拉伯国家他们的文字和图像显示是从右到左的，如果想把产品卖到这些国家，还需要考虑支持从左到右和从右到左的显示问题。当系统的语言是英文或习惯从左到右显示的语言时，语言显示需要从左到右，如果是阿拉伯国家从右向左显示的话，我们的软件也要支持从右到左显示。
主要包括以下几个方面：
1 界面布局上的Frame
当我们把整个界面分为两块时，比如A和B,从左到右显示就是块A 块B,从右到左就是块B 块A
2 Frame中的控件，
包括对话框中的按钮顺序，横向滚动条和竖向滚动条的显示，标签的顺序，图片，导航显示，tab显示。
3 控件中的文字显示
各种控件中文字显示的方向也要支持从左到右和从右到左的显示。

目前我还没有参与过这种项目，还没有什么实际经验，以后有具体的经验后再对这部分进行补充。

前面我们已经谈到了国际化测试的两个级别，今天我们来谈国际化测试的第三级，使软件具备本地化能力

当一个软件已经可以满足国际化前面两个级别后，已经可以保证英文版本的软件在各种平台上运行了.如果还准备发布针对不同国家的本地化版本，我们还需要软件有一定的可本地化能力。当软件具有了可本地化能力后，本地化的工程师基本上不需要对代码进行改动，只需要去翻译资源文件就可以了。

第一点是要保证我们的代码里字符串不能被硬编码。
我们在国际化第一级里面也提到过硬编码，那种硬编码和国际化第三级的硬编码有点区别，在国际化第一级的硬编码主要是一些系统变量被硬编码后引发的系统功能问题，在国际化第三级里面的硬编码，主要是针对一些需要显示给用户的界面上的字符串，错误消息框，日志，图标上的问题等，这些字符串都需要提取到资源文件里。如果没有提取到资源文件里面，而是遗漏在代码中，那么本地化后的软件可能出现有些字符显示的是本地化的文字，有些地方是英文。如果要修改这样的问题，是需要修改代码的。测试这种问题没有什么好方法，也没有什么技巧，主要是要对系统业务熟悉，力争测试到每一个界面。不过，好像现在也有一些开发人员可以写一些工具来检查代码中是否有硬编码,可以减少漏测的风险

第二点是要保证所有显示字符串的控件要进行一定的空间扩展
当英文句子翻译为其他语言时，长度一般都会发生变化，当翻译后的字符串长度增加时，就造成字符串在空间中显示不完整的问题，比较轻微的用户还可以看到大部分句子，知道显示的是什么意思，严重的话可能就看到句子里面的几个字，根本不知道要做什么。

第三点是在代码中避免使用字符串的连接。
就是一个你要显示给用户的句子要放在一个字符串里，不要根据判断条件去组合句子，
例如：str="You can";
      if(condition==true) str+="not"
      str+="delete this object"

出现这种情况,本地化工程师将很难结合上下文去翻译字符串.

第四点是不能硬编码字体和字体的大小。
在不同的操作系统上字体可能是不一样的，如果硬编码了字体，有些本地化的字符是没办法显示的。默认的字体大小也是不一样的，例如日文操作系统上的字体感觉要比其他的大一些。如果硬编码字体和字体的大小，会引起文字显示的问题。

第五点是尽量将控件放在句子的开头或结尾，不要将控件放在句子中。如果将一个控件例如下拉框放在句子中间，就意味着控件两边有两个string,由于翻译后可能造成词语顺序颠倒，本地化工程师翻译时有可能翻译的不正确，不能完全表达句子的意思.

第六点是过度本地化,将一些不需要本地化的内容放入到了资源文件中,而且没有注释告诉本地化工程师.导致本地化工程师将不需要翻译的东西翻译了,引发问题.

 

 

今天我们来说一下国际化测试的第二级，保证软件在何区域性或区域设置中都能正常运行，并且能够支持本地化的字符输入，输出和显示。

国际化测试测试点最多的就是这一级别，这一级别又分了两大类，区域转换支持和本地化字符支持。
我们先来说一下区域转换支持，区域转换支持这块测试理解起来比较简单，但是测试点比较多，我在本地化和国际化的那个板块也发过一些帖子包含了这部分内容，今天再回顾一下。不同的国家数字显示，货币符号，时间显示，姓名顺序，地址显示，度量单位，打印机默认纸张大小,排序规则等可能不同，如果在设计和开发软件过程中没有充分考虑到这一点，将会出很多问题，最简单的，比如日期，有的国家习惯显示为MM/DD/YYYY,有的国家习惯用DD/MM/YYYY，如果有一个日期07/20/2009，大家可能会说是2009年7月20日，如果是07/10/2007，这个日期就有不同的含义，所以在设计国际化软件时，像日期，货币符号这些东西决不能硬编码，一定要根据用户的区域设置来取，而且要能随着用户的区域设置变化而变化,要不然要出很多问题。大家可以到控制面板-->语言和区域设置中看一下，选不同的国家看看这些区别。这些测试点虽然测试起来比较简单，但是很零碎，分布在不同的地方，并且一般不会影响程序的功能使用，主要考验的是测试人员对国际化的测试点的熟悉程度和细心程度，所以是国际化测试中比较容易疏漏的地方。在崔老师的书里面有详细的介绍，其中还提到了颜色，图像，还有一些政治相关的东西。颜色大家可能比较好理解，西方人和东方人对颜色有不同的理解，就像中国的股市涨就用红色，跌就用绿色，美国就和我们的相反。建议大家可以看一看崔老师的书这一部分。

区域转化支持除了上面说的对用户区域设置的支持外，还有一块就是对时区(TimeZone)转换的支持。大家都知道，当我们是白天的时候，美国是晚上，如果你在北京说你是早上8点，那美国那边有可能是下午4点，所以在系统中记录时间时，一定要记录GMT时间，显示时间时再根据系统当前的时区转换为本地时间。以Report为例，如果有一个Report上要显示一些时间，当用户在美国用客户端看到的时间应该是美国当地的时间，当用户在中国用客户端看到的应该是中国当地的时间，时区转换支持的测试起来也比较简单，直接到日期和时间设置中，改变时区设置，看系统中显示的时间会不会根据时区的变化而变化，再根据当前的时区计算一下时间转换的是否正确。比如当前时区为GMT+8,时间显示为9:00AM,所以当前时间为GMT+0 1点， 如果你把时区转换为东京时区GMT+9，那么时间显示应该为10:00 AM。这里顺便提一下时间显示，有的国家习惯用24小时制，有的国家习惯用12小时制，这个也是区域转换支持的测试点之一。在测试时区时，要特别注意的就是客户端和服务器端程序，客户端要记录GMT时间，在客户端显示为客户端本地时间，传送GMT时间到服务器端，服务器端显示时再根据服务器时区转换为服务器本地时间。在工作当中经常有些开发人员在这个地方出错。关于时区测试还有一个测试点就是夏令时的测试，以前中国也有夏令时，就是到夏天，时间会提早一小时，夏天过后，再推迟一小时，现在美国和欧洲的一些国家还在实行夏令时，特别是美国不同的州还实行不同的夏令时，所以在测试时间时还要考虑如果在特定的时区刚好赶上在实行夏令时的日期，系统显示的时间也要考虑夏令时的问题。

国际化测试第二级另一个测试点就是本地化字符的支持，支持本地化字符一般就是支持Hi-ASCII和DBCS,有时候也叫做支持多字节字符。(Hi-ASCII和DBCS大家可以到网上看看具体的概念。)只要是软件中能输入的地方，都要想办法去输入本地化字符，包括安装路径，新建的对象名，报表，导入导出文件中包含本地化字符等，看本地化的字符是否能正常显示，是否影响程序的功能正常运行。一般情况下至少要选两种语言的操作系统进行测试，东亚这边选日文或中文，欧洲那边选德语或法语，如果资源比较多的化还可以选一些其他语言，测试过程中，除了使用一般的本地化字符外，还要使用一些能引起国际化问题的问题字符。比如0x5c,如果DBCS中第二个字节包含"0x5c"，则这个字则可能会引起一些问题，"0x5c" 实际上就是"\"，如果它是在DBCS的第二个字节，处理不当就会出问题，可以在百度或google搜一下关键字0x5c看看相关问题的描述。如果软件对本地化字符支持不好，那么在显示这些本地化字符时有可能出现??,有可能会出现乱码，大家有时候在网站或使用一些软件时看到文字不能正常显示就是典型的国际化问题，主要原因就是在编码方式上可能有问题，在使用文字时一定要先看看字符的编码是什么方式。说到编码这块大家可以在网上看看Unicode相关的东西，还有UTF-8之类的编码方式，也可以看看有些人问道一些乱码，问号问题的解答，看完那些相信大家对字符处理会有更多的认识。从测试角度来看，在测试这块的时候并没有太多的技巧可言，关键是提前准备好测试数据，就是准备在测试中输入的Hi-ASCII或DBCS字符，还有那些问题字符。只要测试数据准备的足够充分，剩下的就是检验测试结果了。

国际化第二级就说到这里，下次我们再说国际化的第三级，保证测试软件可以被方便的本地化而不需要重新设计或修改代码。

 

上次提到了国际化测试一般情况下分为4个级别，今天主要谈谈国际化测试的第一级，也是最基本的一个级别，保证英文版本的产品可以在本地化系统上正常运行。

这一级别主要有两方面的工作，一个是检查英文版本的产品在本地化系统上功能是否正常，一个是检查英文版本的产品在本地化系统上UI是否显示正常。不过在测试过程中，所有可以输入的地方我们都会用英文，不会使用到本地化的字符(比如Hi-ASCII字符或DBCS字符, ).

国际化测试第一级中的功能问题，目前从我的经验来看大部分是由于硬编码引起的。我自己现在主要在做Windows平台下的测试工作，所以举的例子基本上都是Windows平台下的，比如常见的安装问题，一般程序安装时除了给自定义的安装目录放文件以外，还会给\Program Files放一些文件，程序使用过程中会读取\Program Files目录下的一些文件，有些开发人员会认为所有的操作系统该路径都是\Program Files，所以代码中就将\Program Files写死在代码中，其实Windows操作系统本地化版本中有些将\Program Files进行了本地化，比如德语Windows操作系统\Program Files就变成了\Programme,如果代码中直接写死为\Program Files，那肯定要出问题，所以一定要取系统的变量来获取安装目录才行，如果是做Windows mobile手机软件的国际化测试，那德语的Pocket PC一定要做为重点，德语的Pocket PC中就是\Programme，而SmartPhone中就是通常的\Program Files，这也是我自己测试过程中的一个积累。另外一个需要注意的就是和Windows中的一些系统组名称相关的功能，因为组名在不同语言的操作系统上是不一样的，比如英文操作系统上显示Administrators，波兰语操作系统上为Administratorzy 其他的可能还有一些类似比较容易出错的地方，不过我目前还没有遇到，遇到后再进行补充。

国际化测试第一级中的UI问题也比较常见，比如英文版本的产品装在本地化操作系统后，有些Label和Button会出现截断，有时候一些界面滚动条没有了，主要原因是不同语言操作系统的默认字体大小不一样，你会发现文字的高度和宽度有一些变化，控件显示的宽度和高度有时也会发生变化，轻微一点的就是一些截断，严重的时候button上的文字看不清楚，有时候button都找不到，导致部分功能无法使用。

国际化测试第一级基本上就是这些，但是在实际的工作中，由于时间的原因，我们在执行test cases时，有时也不会严格的区分什么时候执行第一级的case，什么时候执行第二级的case.一般都是混在一起的。在发现bug的时候，一定要确认到底是不是国际化bug,我们都要在全英文的环境中去确认，如果全英文环境中没有发现问题，只有在本地化的操作系统中有问题，那一般就是国际化问题，同时我们还要确认到底是哪一个级别的国际化bug,哪一个分类的bug.同一个级别也有不同的分类，比如国际化第一级一般就分为功能级别的和UI级别的。一定要在bug描述中写清楚bug是属于什么级别的和具体的测试环境，这主要是因为一般国际化bug和测试环境关系比较大，写清楚后开发人员比较容易分析原因，也便于去重现bug.另外写清楚国际化bug的级别和分类对项目后期bug分析有很大作用，项目结束后要分析bug的分布，以便确认bug产生的原因，是因为开发人员缺少国际化开发的知识还是其他原因，同时从bug分布上也可以分析出后面类似项目的国际化测试重点，以及评估国际化测试的质量。

今天就写到这，后面有时间我们再谈国际化测试第二级。

做国际化测试也有一段时间了，随着项目经验的增加和知识的逐渐积累，对国际化测试有了一些新的认识，现在重新总结一下，希望对即将进入国际化测试这个领域的新人有所帮助，也希望和目前在做国际化测试的一些朋友有一些经验上的分享，能够互相切磋，共同进步。

 

平时大家讨论测试方面的东西时，大多是手工测试，自动化测试，性能测试之类的话题，也许有些人还没有听过国际化测试，我们首先还是先来介绍一下什么是国际化软件？

 

国际化软件说白了就是有很多语言版本的软件而且要符合当地用户的习惯，还要支持当地的语言输入输出，比如一个软件可能有英文版，中文版，日文版，德语版等，以前的一个开发流程可能是先开发一个版本出来，一般情况下是英文版，然后在英文版的基础上再开发其他语言版本，这样做有很多不好的地方，比如要去改英文版的代码，这样就造成了很多工作量，导致本地化的版本迟迟不能发布，而且软件后期维护成本很高。随着开发流程的优化，现在做国际化软件一般是从软件设计阶段就考虑国际化的相关因素，在软件开发过程早期，国际化就参与进来，边开发基本功能，边修改国际化相关的问题，等到英文版做到一半左右时，本地化也参与进来，当英文版基本稳定时，本地化的工作也进行了大部分，当英文版发布时，过不了多长时间，本地化版本也就出来了，有时候做的好，本地化版本和英文版可能会在同时发布。

 

国际化就是要保证软件在设计开发过程中充分考虑不同语言，不用区域，不同国家的使用，能够使软件很容易的被本地化，而不需要修改软件的代码。

国际化一般包括四个级别：

第一级: 保证英文版本的产品可以在本地化系统上正常运行

第二级：保证软件在何区域性或区域设置中都能正常运行，并且能够支持本地化的字符输入，输出和显示。

第三级：保证测试软件可以被方便的本地化而不需要重新设计或修改代码。

第四级：支持双向识别能力。

公司会根据项目资源和市场情况决定具体做到什么级别。

在做国际化过程中，有几个缩写经常用，下面一一做一下介绍

国际化   Internationalization – I18N

本地化    Localization – L10N

全球化    Globalization – G11N

因为I和N中间有18个字母，所以Internationalization简称为I18N, 其他依次类推。

 

在工作当中，发现很多项目组的人对国际化组和本地化组一直搞不清楚，其实这两个组的工作虽然有关联，但是工作的性质和内容还是有很大差别的，工作重心也不一样。

说的简单一点就是国际化是为本地化做准备，好的国际化是好的本地化的基础。

从工作性质上简单来说就是国际化牵扯到修改源代码，本地化主要是修改资源文件

从测试的build上来说，国际化需要用英文build和伪本地化build进行测试，本地化只需要用本地化build进行测试。

 

好了，今天就写到这里，后面再详细介绍一些国际化测试的细节。