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

国际化测试测试点最多的就是这一级别，这一级别又分了两大类，区域转换支持和本地化字符支持。
我们先来说一下区域转换支持，区域转换支持这块测试理解起来比较简单，但是测试点比较多，我在本地化和国际化的那个板块也发过一些帖子包含了这部分内容，今天再回顾一下。不同的国家数字显示，货币符号，时间显示，姓名顺序，地址显示，度量单位，打印机默认纸张大小,排序规则等可能不同，如果在设计和开发软件过程中没有充分考虑到这一点，将会出很多问题，最简单的，比如日期，有的国家习惯显示为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进行测试。

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