Develop Internationalized Software
Develop Internationalized Software
1. Glossary
开发国际化软件包含很多专业术语，现在将常用的列举如下：
1、 国际化（Internationalization，I18N）
软件国际化是在软件设计和文档开发过程中，使得功能和代码设计能处理多种语言和文化传统，使创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。由于单词较长，为了便于书写，将中间的18个字母省略，简写成I18N。
2、 全球可用（Word-Ready）
适当地国际化设计，可以方便地实现本地化的程序。国际化软件的设计目标就是设计成全球可用软件程序。
3、 本地化能力（Localizability）
本地化能力是表征国际化软件实现本地化的难易程度的指标。良好的软件国际化设计是增强本地化能力的基础，可以降低软件本地化过程的成本。
4、 单一二进制（Single binary）
国际化软件中的完全国际化的二进制功能文件，不用再做修改即可用于该软件的任何本地化的语言版本。
5、 区域（Locale）
区域指的是与某个地方或者某种文化关联的一组信息。也就是说，区域是由语言、国家/地区，以及文化传统确定的用户环境特征的集合。
6、 硬编码（Hard-coding）
软件工程师在进行国际化软件编码时，把需要本地化的字符串放在程序的主体代码中，而不是放在外部可以易于本地化的资源文件中；基于假设的字符串长度，设定字符串的长度数值常量；在代码中对需要本地化的关于语言或文化方面的任何假设（例如日期和时间格式等）。软件国际化设计应该避免任何硬编码，以提高本地化能力。
7、 伪本地化（Pseudo localization）
伪本地化是自动模拟本地化过程，并且构建和测试模拟的本地化版本的过程。把软件中的需要本地化的字符串转变为“伪字符串”，用来国际化软件的本地化能力，包括本地化功能和外观。
8、 国际化功能测试（Internationalized functionality testing）
软件经过国际化设计后，对软件的国际化功能和国际化支持程度的测试，用来验证软件的全球可用性和软件的本地化能力。
9、 双向语言(bi-directional language)
对于希伯莱语或阿拉伯语，文字是从右向左显示；而其中的英文单词或商标符号从左向右显示；对于中文，都是从左向右显示。
10、 编译版本(build)
软件开发过程中编译的用于测试的内部版本。一个大型的软件项目通常需要执行多个内部版本的测试，因此需要按计划编译出多个版本用于测试。
11、 代码页(code page)
字符集和字符编码方案。对每一种语言字符，都用唯一的数字索引表示。
12、 伪翻译(pseudo translation)
将软件中的可以翻译的字符串用长的本地化的字符代替的自动或手工处理的过程，主要用于发现编译和执行本地化文件时潜在的问题。
2. World-Readiness
World-Ready software是指完全国际化的且易于本地化的软件。World-Readiness（全球可用）包括两个方面：全球化（Globalization）和本地化能力（Localizability）。World-Readiness和Localization（本地化）一起构成了国际化软件的基础。
开发国际化软件，首先需要在软件需求规格说明书中明确World-Readiness需求，这些需求大致应涵盖：
1、 Globalization——全球化方面的需求。
2、 customizing features——客制的特性。
3、 MUI——可本地化的UI的需求约束。
4、 legal issues——相关法律条文。
5、 accessibility of features——可达成的特性。
6、 target languages——将要翻译成的语言。
7、 locale-aware feature's behavior——特定区域中特性的不同行为。
开发国际化软件的平台是操作系统，它必须符合国际化软件的需求。另外，还需要一些专业工具和辅助工具，比如翻译软件、自动化测试工具、资源文件查看和编辑工具、文档处理工具和通信工具等等。
2.1. Globalization
全球化是指：开发特性和代码设计都不仅仅基于某一种语言的核心程序的过程。其输入、显示和输出都是使用Unicode编码的，而数据和特定的区域相关。它是指软件内建的可以支持所有的目标语言和区域的能力，它是包括以下任务的一个过程：
1、 明确需要支持的语言和区域。
2、 设计时需要考虑到所支持目标市场、语言和区域。
3、 对于所有软件支持的区域，编写的代码所具有的功能完全一致。
这些任务都集中于“locale-awareness”的概念。另外，全球化的第二个方面包括为内部处理编码数据以及和其它应用程序共享数据。第三个方面为输入、输出和显示数据给用户。
开发国际化软件的步骤：
1、 Use Unicode。
2、 Make application locale and culture aware。
3、 Designing application’s text output, and declaring with fonts in a multilingual context。
4、 Deal with MUI(Multilingual User Interface) 。
2.1.1. Use Unicode
开发全球化的第一步就是使用Unicode编码。
Unicode的简介：
Unicode是一种字符编码方法，它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是"Universal Multiple-Octet Coded Character Set"，简称为UCS（Unicode Character Set）。UCS规定了怎么用多个字节表示各种文字。UCS有两种格式：UCS-2和UCS-4——UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。而怎样传输这些编码，则是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-7、UTF-16和UTF-32。UTF-8以字节为编码单元，没有字节序的问题；UTF-16以两个字节为编码单元，存在编码单元的字节序的问题，这靠BOM（Byte Order Mark）来区别Big-Endian和Little-Endian。
Windows对Unicode的支持：
Windows从Windows NT3.1开始支持Unicode；Windows NT 4、Windows 2000和Windows XP 讲Unicode作为其 native encoding。基于Windows NT的操作系统使用的是UTF-16。所以通常我们应该使用UTF-16。
创建Win32 Unicode Application：
数据类型：使用TCHAR、_TCHAR、LPTSTR、LPTCH，而不要使用char、LPSTR、LPCH。
API：使用generic function prototypes，在自定义function的时候也必须使用Unicode Version。
使用TEXT macro：将“L”加在一个字符串的前面来表示其为Unicode字符串。
编译： Win32 编译时标志 -DUNICODE 和 C 运行时编译时标志-D_UNICODE 都必须被定义。
2.1.2. Locale and Cultural Awareness
使用了Unicode编码仅仅是国际化软件的一部分。有很多因素需要考虑，其中包括Locale and Cultural Awareness，它主要体现在语言规则和文化习惯，比如日期、时间、日历、货币符号、地址、纸张大小、电话号码和度量单位等。
2.1.3. Text Input, Output, and Display
需要作下面的事情：
1、 使得应用程序能处理不同的输入语言和方法。
2、 正确显示所支持的语言文字。
3、 通过平衡对语言处理的系统支持，懂得用来显示文本的不同选项（Understand different options for displaying text by leveraging system support for multilingual computing.）
4、 学会如何处理字体。
对于Input和显示不同语言的文字，Windows已经提供了很好的支持。
2.1.4. Multilingual User Interface (MUI)
国际化软件的终极目标是授权给用户能以任何语言访问和操作数据。
Windows从Windows2000开始MUI。
启用MUI本质上必须作：
1、 将注册表中的string转移到资源文件中。
2、 从内核将可本地化的string移除。
3、 使用MUI-enabled shell去显示本地化的内容（比如开始菜单、快捷方式等）。
4、 防止开发者将文件路径硬编码（hard-coded）。
5、 如果使用了非传统的Win32资源（比如XML和HTML），则阻止每个组件中的特定代码安装和加载资源文件。
实现MUI的三种方法：
1、 为每种语言编译一个binary。此方法通常运用于老版本的windows。
2、 编译一个语言上中立的binary，带有一个含有多种语言支持的资源动态链接库（DLL）。
3、 编译一个语言上中立的binary，每个语言一个资源DLL。是目前广泛采用的一种方法。
MUI in Win32 Applications：
1、 检测操作系统的UI使用的语言。
2、 获得应用程序能支持的语言列表。
3、 根据操作系统的UI语言，加载合适的资源DLL。
4、 允许用户选择不同的UI语言。
Web内容：
1、 将资源存储在数据库、XML文件或者资源文件中。
2、 使用变量引用string 资源。
3、 检测在初始化时显示的语言。
4、 在显示时加载合适的资源。
2.2. Localizability
本地化能力是软件具有被本地化的能力——在不改变软件功能和代码的情况下，可将软件本地化为任何语言。它可以分为软件本地化能力和内容本地化能力。
Software Localizability Guidelines
1、 独立可本地化的资源。
l 不要将不需要本地化的资源和可本地化的资源存放在一起。
l 将可本地化的资源都存储于resource repository（比如资源文件、数据库等）中。这些资源包括——UI 资源（比如菜单、按钮、工具栏等）；用于改编产品的资源（比如区域信息、文件名、账户名等），这些资源如果本地化不当会影响到软件的功能，最好不要存在应用程序内部，且令这样的资源越少越好。
l 使用API去获取系统的本地化的值（比如使用SHGetFolderPath函数获取本地化的文件夹路径）。
l 可以将不需要本地化的资源放入头文件中。
l 不要轻易改变资源的ID。
2、 处理String。
l 避免运行时合成字符串。比如对于可以枚举的少数动态情况，“Are you sure you want to delete the”+一个变量（可能是file和directory），应该改变为两个完整的提示信息"Are you sure you want to delete the file?"和"Are you sure you want to delete the directory?"。
l 如果必须使用变量（字符串中有占位符），则应该使用唯一的名字。比如将"Not enough memory to %s the file %s."改变为"Not enough memory to %1 the file %2."。
l 使用FormatMessage来格式化消息。
l 尽量保持一个句子完整。显示给用户的信息最好是一个string就是一个完整的句子，以便于理解和本地化。
l 观测string的Buffer Sizes。由于不同的语言表达相同的意思所使用的字符个数不同，编码不当会造成缓冲区溢出（buffer overruns）的错误。
3、 对UI的本地化能力的考虑。
l 为控件预留较多的空间，比如将Label放在Edit上方，以给Label和Edit都留下比较大的空间来显示字符。
l 令对话框可以改变大小。
l 界面上使用完整的语句，而不是把一个语句分割在控件两边。
l 不要将某些控件（比如Button、Dropdown）置于其它控件之上；后者将控件隐藏于其它控件背后。
l 不要将Button的Text和某个变量联系在一起，即其Text不应该是动态的。
l 避免使用特定文化的图片和图标，而应该使用中性的标志。
l 避免使用肢体图片。
l 避免Gender-Specific Roles and Ethnic Stereotypes。
l 避免宗教相关的引用。
l 避免政治符号。
l 避免图片文字。如果将文字嵌入图片中，则不利于本地化。
Mirroring
如果需要支持阿拉伯文，则需要考虑Mirroring。
Content Localizability Guidelines
随着产品发布还有相关文档（比如帮助文档），它们需要满足：
1、 内容尽量简单明了。
2、 内容（文字、艺术，多媒体）必须是文化上可接受的。
3、 内容必须遵从一致的模式。
4、 不管用户选择什么区域，帮助系统的功能都是一样的。
3. Localization
主要是大量的翻译工作——包括产品中的所有text、menus、 dialog boxes、buttons、wizards、online Help、printed documentation、 packaging、CD labels 和multimedia files。这其中需要考虑每个区域特定的因素（比如文化习惯、法规等等）。
4. Testing
开发国际化软件是需要整个开发流程都以国际化为目标——包括需求、设计、编码，还有测试。
4.1. Testing for World-Readiness
World-Readiness软件测试包括软件国际化测试和软件本地化能力测试。软件的国际化测试是重要的测试阶段，必须在本地化测试之前进行测试。国际化软件的测试目的是判断软件的国际化程度，确定软件是否支持可能的任何区域，是否可以容易地进行本地化。
4.1.1. The Approach to Testing
老的测试方法（测试每个语言版本的功能、本地化的正确性等）是较为低效的，如果软件需要多支持一倍语言或区域，则必须付出多一倍的资源，即使有两个区域是非常相似的，也不能保证在其中一个区域运行良好的软件能在另外一个区域正常工作
通过使测试全球化，我们可以使测试变得容易和有效率。这里有一个重要的概念“enabling（Altering program code to handle input, display, and editing of bidirectional or East Asian languages, such as Arabic and Japanese, respectively.）”——修改程序代码分别处理双向语言或东亚语言的输入、显示和编辑，比如阿拉伯文（从右向左书写文字）和中文。在正确地做了“enabling”后， 全部world-ready 的应用都能处理底层平台支持的所有语言。因此，我们不是去测试每个本地化版本的功能，而是为核心产品测试被全球化的功能。但这并不是说就根本不用去测试每个本地化版本了，不同于老的测试方法的地方是——我仅仅需要检查产品对于给定的区域或语言适应得如何（we only need to check how well the product was adapted for a given locale or language，to verify that localization does not break globalized and localizable resources）；此时，测试人员此门语言的掌握程度成为关键因素。
在进行本地化之前，必须确保软件是国际化的和易于本地化的。如果产品核心开发和测试满足了word-ready标准，则软件的多语言sim-ship是可能的；本地化能力测试应当和国际化功能测试并行；在代码足够稳定后就开始进行本地化，且仅在本地化能力测试的初始阶段开始后。将国际化思想贯穿整个开发的各个阶段，测试和开发同步进行。这样的好处是，很多软件缺陷（核心功能缺陷和国际化缺陷）可以在软件开发阶段修正，从而软件本地化变得非常容易进行，减少了软件本地化后的缺陷。
Testing process required for shipping an internationalized product
测试不再是开发后的一个被动执行的过程，尽早介入测试可以发现、报告和修正软件缺陷，由于国际化不再是一个单独的过程，所以软件的功能测试、国际化测试将同步进行。这样即使没有本地化Build，测试人员可以使用“伪本地化版本”进行“伪本地化测试”，以便发现本地化能力方面的缺陷。
4.1.2. Globalization of the Test
我们最先开始的就是验证软件的功能是否全球化了。即检查其是否满足全球化的条件：
1． 基于Unicode。即能正确处理任何Unicode text，处理多语言文本时没有数据丢失。
2． 如果需要进行文本转换，是否选择了正确的编码。
3． 代码遵从用户特定的文化设置。系统区域仅影响编码转换（encoding conversions），用户区域设置只定义了date， time，number 和 currency formatting，calendar 和 sorting 设置。
在进行测试之前，需要作一些准备工作：
1、 将需要测试的内容划分成几个部分。
2、 确定一个测试的优先顺序，优先测试对全球化影响大的组件。比如未处理未进行Unicode编码的数据的组件、大量处理文本数据的组件、操作文件进行存储和数据交换的组件等等。
3、 选择一个合适的测试平台，比如English Windows XP（它能让我们自由调整区域和语言设置）。
4、 建立测试环境。模拟一些多国语言的场景以检查软件是否能正常工作，比如：对于分布式系统，检查其是否能在不同区域的系统间正确地交换数据；组件是否能正确处理和尊崇用户的区域设置等等。
执行测试：
为了进行国际化的测试前，需要国际化测试数据（比如使用不同于系统区域的其它区域的Unicode text、各种语言文字混合的文本、特定区域的一些特殊要求），测试覆盖到了各个功能，认清国际化问题（globalization problems）——比如不能正确地显示文本。
测试方法：
1． 测试通用功能。
l 在各种语言环境下安装应用程序。
l 各种系统和用户区域设置的通用功能。
l 通过各种区域设置卸载应用程序。
2． 测试文本处理功能。
l 使用不同区域的输入法编辑器交互式文本输入。
l 多语言文本的剪贴板操作。
l 用户界面的文本处理。双字节字符集的输入和输出。
l 多字节字符集文本的缓冲区大小的处理。
3． 测试区域特征功能。
l 遵循区域标准，正确输入、存储并检索区域特定数据。
l 验证带有数据分割符的输入时间、日期和数值。
l 纸张和信封的大小和打印的正确性。
l 区域有关的度量衡的处理功能。
4.1.3. Localizability Testing
本地化能力测试的目标是被测试过的软件的UI能被很容易地翻译成为目标语言而不需要重新设计或者修改代码。由于其bug必须在开发阶段被修正，所以应该尽可能地在开发的早期就进行检查。但是不幸的是，这些bug通常要到做本地化的是否才能发现；此外，本地化只有在代码完成后且趋于稳定的时候才会进行，所以不可避免地在开发和本地化之间有一个很长的时间跨度。解决此矛盾的办法如下：
1、 运行一个pseudo-localized版的程序。伪本地化版本测试可以不用实际本地化，就能够发现在本地化过程中的用户界面的翻译错误。镜像技术也是伪本地化版本测试的常用技术，发现一些本地化过程中的控件布局方面的错误。
2、 Code review。检查代码以发现代码中存在的违反Localizability的问题（比如必须将code和resource隔离开、不能在运行时控制UI控件的位置和标签（caption），图标和图片不能含有文字、不存在对驱动器和文件名或者注册键的假设等等）。
3、 Review UI和documentation。确保用户界面和文档中所用的术语清晰、一致、明确。当用户界面和文档提到相同的特性，使用的术语不一致，或者当文档使用了太多的技术行话时，会使本地化过程增加很大难度。如果本地化能力依赖于伪本地化，更应该注重检查文档的内容。
4、 运行一个试验性的项目（project）。虽然针对伪本地化版本的测试能够发现很多本地化能力方面的问题，但是仍然不能代替对实际的本地化版本进行本地化能力的测试。在选择合适的本地化版本时，通常考虑以下方面：
l 选择熟悉的可以迅速创建和测试的本地化语言版本。
l 选择特别容易暴露本地化问题的语言版本。
l 选择非常重要的目标市场的语言版本。
4.1.4. Localization Testing
本地化测试检查软件是否恰当地被翻译为目标语言。它建立于国际化测试基础之上，如果产品不是足够国际化的以支持该语言，那根本没有必要开始进行本地化。
软件本地化测试的目的是为了发现和报告本地化软件的错误和缺陷。通过对这些错误和缺陷的处理，确保本地化软件的语言质量、互操作性、功能等符合软件本地化的设计要求，满足当地语言市场用户的使用要求。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助设计出有针对性的检测方法，改善测试的有效性。
Localization Testing需要关注的方面：
1、 Things that are often altered during localization, such as the UI and content files。
2、 Culture-specific, language-specific, and country-specific areas。
3、 The availability of drivers for local hardware and the encryption algorithms incorporated into the application。
4、 The rules and regulations for distribution of cryptographic software differ from country to country。
5、 The customization that could not be automated through the globalization services infrastructure (Win32 NLS APIs and the .NET Framework)。
6、 Basic functionality tests; setup, upgrade, and uninstall tests that are run in the localized environment。
7、 Application and hardware compatibility tests according to the product's target market。
重点是发现软件因本地化产生的错误。不要过多的耗费时间测试软件的功能，因为本地化测试前，源语言软件已经进行过功能测试和国际化测试。所以，应该将本地化测试的重点放在本地化方面的错误。
使用的平台：
建议使用English Windows XP。
对UI的Localization Testing：
1、 当应用程序运行了某些进程（比如运行了一些windows 服务），要特别注意应用程序的行为。比如UI上使用的是用户设置的区域设置，而后台服务使用的操作系统的区域设置。
2、 验证所有的应用程序资源。
3、 验证语义准确性和资源属性。
4、 检查排字错误。
5、 检查各种文档（比如用户手册、在线帮助、消息通知等）是彼此一致的。
6、 确认遵从系统、输入和显示环境的标准。
7、 检查UI的可用性。
8、 确认文化上的适应性。
9、 检查政治上敏感的内容。
10、 确保关于本公司的信息（联系信息、产品支持服务电话）都是最新的。
11、 产品发行地的法律规定。
4.2. Testing Localizability with Pseudo-Localization
伪本地化将产品中的那些文本（字符串）翻译为伪字符串，这样产生的伪语言（pseudo-language）就用来测试不同方面的本地化对产品的功能和外观会产生怎样的影响。“不同方面的本地化”包括用不同字符集的字符来翻译字符串以及加长的字符串，还有对图片、图像声音、文档内容的伪本地化，以及伪翻转（pseudo-mirroring）等。通过将产品伪本地化，可以得到产品的伪本地化版本。使用伪本地化技术，我们可以不必等到真正的本地化过程才开始国际化测试。随着产品的开发进程，产品变得日益复杂，对伪本地化版本的测试应当成为国际化测试的一个部分，它可以帮助我们发现那些产品的本地化能力bug。伪本地化测试工作可以使用自动化测试工具来进行，一般自动化测试工具都有此功能。
本地化能力bug的分类：
l 需要本地化的资源没有暴露给本地化人员。
l 需要本地化的文件的格式不是可以被本地化的格式，或者被Hard-Coded到了源代码中。
l 将不需要本地化的字符串进行了本地化。
l 非拉丁字符导致了功能或者表面问题。
l 字符串长度的扩展导致了缓冲区溢出错误。
l 功能性字符串没有被一致地本地化。比如文件名。
l 产品不能修改以适应本地化要求。比如和特定区域相关的字体、字典等。
l 产品的UI不能进行翻转（mirroring）。比如阿拉伯文是从右至左书写文字的。
l 在运行时生成字符串和调整UI。这样的字符串和UI根本无法进行本地化。
4.3. The Role of Test Tools
测试工具在测试过程中起着很重要的作用，尤其是自动化测试工具。虽然自动化测试工具不能完全代替手工测试，但是在很多领域它都发挥了巨大的作用。通过在初始版本和本地化版本上运行自动化测试，可以检验本地化是否破坏了功能。另外，确保被国际化的产品在多种不同的环境下测试，进行大范围输入数据的测试。
为能正确地测试全球化软件，测试工具本身必须要求是全球化的软件，它能自动根据区域设置调整自己，并且能够处理国际化文本数据。另外，如果它必须通过名字来访问本地化对象，则测试工具必须被本地化的。如果工具本身存在一些局限性，可以作一些工具来有效利用工具：
1、 通过资源的identifiers, ordinal numbers, 或者 window classes来访问对象，而不是caption。
2、 将文本资源从代码中独立出来以方便本地化。
5. Tools and Utilities
5.1. pseudoLocalizer
pseudoLocalizer -- a tool to aid development and testing of internationalized applications
5.2. Strgen
Strgen generates multi-lingual strings to be used in globalization testing, (runs on only Windows NT/2000/XP/Server 2003).
5.3. Microsoft Advanced Character Mapping Tool for Traditional Chinese Windows
The Microsoft Advanced Character Mapping Tool helps users migrate from the proprietary solution to the Unicode standard, reducing the time and effort needed to find the correct Unicode value for a specific character.
5.4. Robot
其思想就是：测试人员把标准答案都告诉Robot，然后Robot就会对照着系统进行检查。用Robot直接录控件，它会对控件进行识别（就是一个一个的对象），从而可以获得每个对象的属性，然后我们可以检查这些属性，就和编程的原理一样。Robot的语法使用Basic的语法，它的语言使用SQA Basic。
5.4.1. Features of Robot
支持多种 IDE：
l Microsoft Visual Studio .NET
l Oracle Developer/2000
l
l PeopleSoft
l PowerBuilder
支持多种语言：
l Java
l HTML 和 DHTML
l Visual Basic
l Visual C++
l ActiveX
l XML
自动 GUI 功能测试
l 执行分布式功能测试
l 测试所有 .NET 本机控件，包括 VB.NET、C#、J#、Managed C++
l 允许在记录时查看和编辑测试脚本
Rational Robot可开发三种测试脚本：用于功能测试的GUI脚本、用于性能测试的VU以及VB脚本，如下表：
|
方面 |
GUI脚本 |
VU脚本 |
|
VU脚本 |
在一台计算机上同时只能执行一个GUI脚本。 |
在一台计算机上同时可以执行多个VU脚本。 |
|
语言 |
包括对GUI对象的键盘敲击以及鼠标点击行为，脚本用SQA Basic语言写成。 |
包括客户端发送到服务器的要求，脚本用VU语言写成。 |
|
测试领域 |
用于功能测试和性能测试。 |
通常用于加入用户负载的性能测试，例如：测试不同负载下服务器响应时间。 |
|
查证点 |
可以包括查证点，用于比较记录回放时捕获的信息。 |
不支持查证点。 |
|
用户 |
单用户,模拟前台的实际用户操作 |
多用户，虚拟测试者模拟发送到数据库、Tuxedo或者Web服务器的请求，Robot记录网络流量等后台，忽略前台GUI操作。 |
5.4.2. Use Robot to Test Windows Forms UI
一般是使用Robot第一次的输入，Robot会自动产生脚本，此脚本可以用于自动化测试，我们还可以修改脚本以满足所需的测试。所有的.NET 的component都可以被自动化测试工具捕捉到，进行捕捉时可以设置为根据对象的“ID”进行捕捉，也根据对象的“text”进行选择（不推荐，不适用于国际化软件测试）；而对于MFC控件等第三方控件的捕捉带有选择性，只有部分控件可被捕捉到——Robot只能识别标准控件，对于用户自定义控件则常常无法识别。因此，我们可以事先使用rational识别器识别控件，通过识别的控件可以被robot捕捉到。在开发过程中，应当尽量使用标准控件，为使用自动化测试工具提供条件。
