1898.本地化系统软件测试毕业论文.doc

毕业论文（设计）目 录摘要 2关键字 2Abstract 3Keyword3前言 41. 软件本地化和本地化测试基础 5什么是软件本地化 5什么是本地化测试 5本地化测试与普通测试的区别 6本地化测试的特点 6本地化软件测试目的和原则 8软件本地化测试模型 92. 测试本地化软件10本地化软件测试的主要内容 10本地化软件测试策略 12软件本地化错误揭秘 13软件本地化测试方法 16测试用例举例 20如何写错误报告 24如何报告错误 27结束语 29参考文献29摘 要本地化软件测试是全球化软件测试的一种。它是随软件全球化的产生而产生。所以本地化测试带有全球化的特性，该特性就决定了本地化测试的生命周期，也决定了本地化测试的发展前途和发展速度。本文主要介绍了本地化软件测试的概念，本地化软件测试的前景，本地化软件测试与普通的软件测试之间的区别，本地化测试的目的和原则，本地化测试的主要测试内容，有什么测试策略，本地化软件经常出现的错误及产生错误的原因，本地化测试的模型分类，本地化测试的方法，常用的几种测试用例，如何写错误报告，如何用工具上报错误。同时，本文还给出了部分例子，及一个报告错误用的软件的用法。由于工作环境多在英文环境中，所以，后面涉及到实际工作的东西多用英文描述。关键词：本地化；测试方法；错误报告AbstractLocalization of software testing is a test of globalization software. It appeared with globalization of software. Localization of software develops very quickly. This paper introduced the concept of localization of software testing, localization of the prospects for software testing, software testing and localization of the ordinary the distinction between software testing, Localization of the purpose and principles of testing, the localization of software errors and often the wrong reasons, the localization of the test model classification, localization testing methods, how to write a bug report, how to use tools to report bugs. At the same time, the paper also gives some examples, and a tool for bug report. As the working environment is more in the English environment, so the actual work involved behind the things the use of English description.Keywords: localization; testing method; bug report本地化软件测试前 言软件本地化测试是软件本地化项目的一个重要组成部分，在软件行业，尤其在与国际接轨的当今，已越来越受到重视。当某个公司或者机构希望将其产品和服务推广到本土以外的地方时就少不了“本地化”的环节。大抵要先去考察一下当地的各种环境，然后相应的改造自己的产品和服务，使之看起来如同本地化产出的一样，从而尽量淡化其在最终用户眼中的外来色彩，目的则无非是为了确保产品或服务在当地市场最大可能的接受程度。 软件本地化测试是提高软件本地化质量的重要手段，是控制软件本地化质量的关键措施。目的是为了发现本地化的软件中的错误和缺陷，通过修复这些错误和缺陷， 提高软件本地化质量。综合的软件本地化测试解决方案，可以保证软件发布进度、降低支持和维护成本，并保证产品有上乘的质量。 软件本地化测试是一个工程系统，包含多个紧密联系的环节和内容。软件本地化测试作为保证软件本地化质量和可靠性的技术手段，随着软件国际市场的激烈竞争和软件用户对质量要求的不断提高，软件本地化测试在软件本地化项目中的作用更加突出。软件本地化测试的关键在于软件供应商（Software Provider）和本地化提供商(Localization Vendor)对测试的高度重视，包括测试资源、测试文档、测试流程、测试方法和测试管理等方面有效准备和正确实施。本地化软件测试是对本地化软件质量控制的重要手段，是运行本地化软件程序寻找和发现错误的质量控制过程。 软件本地化测试是由软件本地化提供商和软件供应商互相协作的软件质量保证活动。源语言软件和多种语言本地化软件同时发布，已经成为大多数软件提供商追求的 软件发布策略。因此，软件本地化测试将与源语言软件的测试保持同步。在软件本地化测试中发现的源语言软件的功能设计错误，需要由软件供应商处理。软件供应商已知得其他源语言软件的功能错误，需要通知本地化服务商，以免重复测试和报告相同的错误，影响测试效率。1.软件本地化和本地化测试基础1.1什么是软件本地化 那么什么是软件本地化呢？拿Word 2003为例说明，英文Word 2003能够在简体中文Windows 2003上安装和使用，但是大家很少直接使用英文的Word 2003，为什么呢？ 因为使用英文的软件不如使用中文的软件更易于理解。把英文Word 2003经过语言处理和技术加工，重新制作成简体中文Word 2003的过程，称为英文Word 2003的软件本地化。当然除了简体中文之外，Word 2003还有几十种其他语言的本地化，例如，日语、德语、法语，繁体中文的Word 2003。 所以，软件本地化是对原始语言（例如，英文）开发的软件进行语言转换和工程处理，生成不同语言版本的技术。1.2 什么是本地化测试“本地化软件测试”，就是在本地化的操作系统上测试本地化软件，例如在简体中文Windows XP Professional上测试简体中文的Word 2003。本地化软件测试是国际化软件测试的一种。1.3 本地化测试和一般测试的区别 软件本地化测试的测试对象是本地化的软件，需要在本地化的操作系统上进行。虽然本地化的软件是基于源程序软件创建的，但二者的测试内容和重点具有很大的不同。 一般地，二者的不同在于：（1）测试顺序不同。首先要现对源程序软件进行测试，然后再创建本地化软件，测试本地化软件。（2）测试内容和重点不同。源程序软件主要测试功能和性能，结合软件界面的测试。本地化软件的测试，更注重因本地化引起的错误，例如，翻译是否正确，本地化的界面是否美观，本地化后的功能是否与源语言软件保持一致。（3）测试环境不同。源程序软件测试通常在源语言的操作系统上进行。本地化软件在本地化的操作系统上进行。 本地化测试过程中，需要同时运行源程序软件和本地化软件，依照源程序软件结果作为本地化软件的主要参考。1.4 本地化测试的特点 本地化测试具有软件测试的一般特征，在此不再赘述，下面说一下其特有的特征：（1）本地化测试对语言的要求较高不仅要准确理解英文（测试的全部文档，例如测试计划、测试用例、测试管理文档、工作邮件都是英文的），还要使用本地化母语人员进行本地化测试，例如测试简体中文的本地化产品，我们中国大陆人完全胜任。而测试德语本地化软件，需要母语是德语的测试人员才能满足要求。（2）本地化测试以手工测试为主，但是经常使用许多定制的专用测试程序手工测试是本地化测试的主要方法，为了提高效率，满足特定测试需要，经常使用各种专门开发的测试工具。一般这些测试工具都是开发英文软件的公司开发人员或测试开发人员开发的。（3）本地化测试通常采用外包测试进行为了降低成本，保证测试质量，国外大的软件开发公司都把本地化的产品外包给各个不同的专业本地化服务公司，软件公司负责提供测试技术指导和测试进度管理。（4）本地化测试的缺陷具有规律性特征本地化缺陷主要包括语言质量缺陷、用户界面布局缺陷、本地化功能缺陷等，这些缺陷具有比较明显的特征，采用规范的测试流程，可以发现绝大多数缺陷。（5）本地化测试特别强调交流和沟通由于实行外包测试，本地化测试公司要经常与位于国外的软件开发公司进行有效交流，以便使测试按照计划和质量完成。有些项目需要每天与客户交流，发送进度报 告。更多的是每周报告进度，进行电话会议，电子邮件等交流。此外，本地化测试公司内部的测试团队成员也经常交流彼此的进度和问题。（6）本地化测试属于发展比较迅速的专业测试由于中国属于较大的软件消费市场，国外大的软件公司为了在中国获得更多的软件销售利润，越来越多的软件都要进行中文本地化。另一方面，中国成为新兴的软件外包服务提供国，国外公司逐渐把软件外包测试放在中国进行。这样，本地化测试就不断发展起来，目前中国很多大型本地化服务公司的本地化测试业务都呈现稳定增长的态势。1.5 本地化测试的目的和原则1.5.1测试的目的软件本地化测试的目的是为了发现和报告本地化软件的错误和缺陷。通过对这些错误和缺陷的处理，确保本地化软件的语言质量、互操作性、功能等符合软件本地化的设计要求，满足当地语言市场用户的使用要求。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助设计出有针对性地检测方法，改善测试的有效性。 软件本地化测试的目标是以最少的时间、人力和软硬件资源，找出本地化软件中的各种类型的错误和缺陷。测试应该能验证本地化软件的功能和性能与源语言软件保 持一致，本地化软件的语言质量、软件界面、文档内容等符合当地语言市场用户的使用要求，符合特定区域的文化传统和风俗习惯。软件的特点、测试方法和测试时间等因素，决定了软件本地化测试，不可能进行完全测试。因此，经过软件本地化测试，无法表明软件中不存在潜在的错误，但是有效的测试能够发现尽量多的比较严重的软件错误。1.5.2测试的原则 测试原则规定了测试过程中应该遵循的基本方法，软件本地化测试的原则如下。尽早地和不断地进行软件测试。软件本地化测试不是软件本地化的一个独立阶段，它贯穿于软件本地化项目的各个阶段。测试计划、测试样例等测试要素要在测 试本地化软件版本（Build）前准备好。一旦得到可以测试的软件本地化版本，立刻组织测试。争取尽早发现更多的错误，把出现的错误在早期进行修复处理， 减少后期修复错误时耗费过多的时间和人力。在本地化软硬件环境中测试本地化软件。为了尽量符合本地化软件的使用环境和习惯，应该在本地化的操作系统上安装和测试本地化软件，使用当地语言市场的通 用硬件，例如当地布局的键盘等，这样可以发现更多的本地化软件的区域语言、操作系统和硬件的兼容性问题。为了便于参考和对比，需要将源语言（例如英语）软 件安装在源语言操作系统上。软件错误报告、软件错误修复和软件错误修复验证应该由不同的软件工程师处理。为了保证软件测试效果，软件错误报告应该由测试工程师负责，软件错误修复应该由负责错误确认和处理的软件工程师负责，软件错误修复后的验证和关闭应该由软件错误报告者（测试工程师）负责。软件本地化测试的重点是发现软件因本地化产生的错误。不要过多的耗费时间测试软件的功能，因为本地化测试前，源语言软件已经进行过功能测试和国际化测 试。所以，应该将本地化测试的重点放在本地化方面的错误，例如语言表达质量，软件界面布局，本地化字符的输入、输出和显示等。严格执行测试计划，排除测试的随意性。测试执行前，对每一项测试做出周密的计划，包括测试版本号、测试内容、测试平台、测试进度、资源要求、测试用例、测试流程、测试质量控制等，符合测试计划和测试要求说明文档的要求。采用软件错误数据库管理软件测试中的所有软件错误。对每一个本地化测试的项目，建立结构完整、功能丰富、使用方便的数据库，以便有效的完成软件错误报告、查询、修复、存储等功能，从而提高测试效率，保证测试质量。1.6 软件本地化测试模型 根据本地化测试人员语言技能、测试技能、对软件产品的熟悉程度和各项本地化测试内容的测试顺序，可以分为三种本地化测试的模型：本地化集成测试模型、本地化“一加一”测试模型、本地化分布测试模型。 1本地化集成测试模型 本地化集成测试模型是指本地化测试团队的测试人员完成包含本地化功能测试、用户界面测试和语言质量的全部三项内容。 为了达到较高的测试质量，要求测试人员不仅掌握良好的测试技能，熟悉被测产品的功能特性，还要精通本地化语言和当地的文化习俗。无疑，这种测试模型对测试人员的技能提出了非常高的要求。 2本地化“一加一”测试模型 本地化“一加一”测试模型是指为了完成本地化测试的三项内容，安排一个（或一组）测试人员和一个（或一组）语言人员坐在一起，一起共同执行功能测试、用户界面测试和语言质量测试。 在实际测试过程中，测试人员和语言人员各有分工，并且互相配合。测试 人员熟悉测试技术和被测产品，主要执行功能测试和用户界面测试，而语言质量测试需要在语言人员的指导下进行，语言人员可能不熟悉被测试产品，但精通本地化 语言，主要在测试人员的帮助下测试语言质量，也可以执行一些用户界面测试。 3本地化分布测试模型 本地化分布测试模型是指按照一定的时间顺序，将测试内容进行详细分工，安排不同技能的人员，分别执行本地化功能、用户界面和语言质量的测试。 例如，测试人员先执行本地化功能测试和用户界面测试，测试完成后再由语言人员测试本地化语言质量，反之亦然。测试人员和语言人员可以同时并行执行各自的测试内容，前提条件是语言人员必须熟悉测试的步骤。 2.测试本地化软件2.1 本地化软件测试的主要内容 不同的测试阶段有不同的测试内容。根据被测软件的测试特征，软件本地化测试的内容大体上包括安装/卸载性能测试 (Install/Uninstall Testing)、软件功能测试(Function Testing)、本地化语言测试(Linguistic Testing)、软件外观测试(Cosmetic Testing)。测试内容由不同的测试阶段决定，例如第一个Build，以软件界面测试为主，中间Build以功能和界面为主，最后Build终点测试安装/卸载，软件帮助和主要功能。（1）安装/卸载性能测试测试本地化的软件是否可以正确地安装/卸载在本地语言的操作系统上（包括是否支持本地语言的安装目录名）。 安装/卸载前后安装文件、快捷方式、程序图标和注册表等的变化是否与源语言程序一致。（2）软件功能测试本地化软件功能是否与源语言软件功能相同。是否支持当地语言的输入和输出，如对双字节支持和正确显示。对当地日期，时间，货币符号等的支持性能。是否支持当地语言的文件名和目录名。（3）软件界面测试软件安装窗口中的按钮，菜单等的布局是否合理，美观。软件运行后的界面元素，包括菜单、快捷键、对话框、屏幕提示、按钮、列表框的布局和本地化字体和字号是否正确。 界面文字的翻译是否与术语表一致，是否存在没有翻译的元素。（4）帮助文件功能和翻译质量本地化帮助文件的功能是否与源语言软件一致。本地化帮助文件的布局是否合理，美观。本地化帮助文件的文字翻译是否准确、专业，是否存在没有翻译的段落。2.2 本地化软件测试策略 测试策略描述测试项目和测试任务之间的关系，说明要测试什么和怎样测试。软件本地化测试策略是进行软件本地化测试采用的有效测试方法论和测试手段。对于软件本地化测试，本地化提供商主要进行外观测试和本地化语言测试，软件供应商主要进行国际化测试和功能测试。软件在本地化之前，必须先经过软件国际化测试和本地化性能测试等功能测试，然后再编译本地化版本。 软件本地化提供商应该重点处理本地化提供商可以解决和擅长的调整本地化软件用户界面布局和语言翻译等问题，对于测试过程报告的软件硬编码（指直接嵌入在代码中的需要本地化的字符）和软件自身的功能错误只能由软件提供商处理。由于软件本地化和源语言软件开发一起进行，因此，软件本地化测试通常要测试多个功能不断完善和丰富的本地化版本。这些不同的本地化版本测试的重点和具 体测试内容各不相同。一般，第一个本地化版本，重点测试软件外观，即软件用户界面测试，包括界面控件大小和位置，也包括界面本地化的字符内容和样式，而在 此阶段，软件联机帮助和其他文档都还没有本地化，不需要测试。软件的功能还不完善，不要过多耗费时间进行功能测试。最后一个本地化测试版本，是测试的最后 阶段，要尽量保证全面的测试，包括本地化功能测试，软件程序、联机帮助语言质量测试，安装/卸载测试，并尽快处理发现的软件错误。在第一个和最后一个测试 版本之间的中间版本的测试，要保持功能测试和语言测试行结合的测试方法，在稍后的软件界面冻结版本的测试中，重点测试文档本地化质量，包括语言和本地化图 像的格式等方面。关于软件错误和缺陷处理，应该尽量保证在每个版本测试周期内全部解决，以免错误和缺陷逐渐积累而最终没有时间全部处理，从而影响本地化测试质量。为了有效处理测试中的报告的软件错误和缺陷，本地化提供商和软件供应商的测试工程师必须每天检索共享专用的软件测试错误数据库，对属于自己要处理的错误及时处 理。对于软件测试错误数据库中任何错误的处理，都要保存详细的处理记录。从测试理论上讲，每个新版本的测试都需要对前面的版本进行回归测试，以保证新软件版本功能的改进不会使以前的错误重现或产生新的错误。为了保证软件的最终质量，至少对最后一个本地化版本的交付测试执行回归测试。对于本地化测试报告的功能错误，首先确认在本地化操作系统上安装和运行本地化版本可以重复错误，然后验证在源语言操作系统上安装和运行源语言版本是否 也可以重复此错误，如果可以重复，则说明该错误属于源语言版本的设计错误。如果不能重复，还要在本地化操作系统上安装和运行源语言版本，如果能重复，则说 明是与本地化操作系统有关的错误。如果不能重复，则说明该错误是本地化版本由于不正确的本地化产生的错误。这两类错误的修复处理难度较大，关键是定位错误 产生的准确位置和真实原因。为了保证软件测试报告的错误质量，以及快速查询、分类和存储测试中的错误，软件本地化供应商创建该项目内部专用的软件错误报告数据库 (Software Problem Report, SPR)非常必要。为了提高报告给软件供应商的全部软件错误都是可以重复的真实错误，软件工程师负责软件测试并向错误报告数据库添加错误记录，高级测试工程师负责验证报告的错误包含完整的报告信息，确认属于真正的软件错误，然后添加到软件供应商提供的项目共享专用错误数据库，并注意这两个数据库的每个本地 化测试错误记录保持一一对应和保持错误状态同步更新。2.3 本地化软件错误典型类型 下面对本地化软件的错误的三种典型类型进行分类讨论，探讨错误的表现特征，产生的原因。1、功能错误（Core Defect）表现特征：     不能实现设计要求的功能。    产生与设计要求不符合的结果。     绝大多数存在于源语言软件和本地化软件，也有仅出现在本地化软件中。     经常出现在软件的菜单项、工具栏按钮和对话框的功能按钮中。 产生原因：     源语言软件编码错误。     错误本地化，如将程序中的变量字串名进行了翻译等。 2、国际化错误(Glob Defect) 表现特征：     控件或对话框中显示不可辩识或无意义的明显错误的字符。     不支持双字节字符的输入和输出，包括双字节的文件名和路径名。     与当地不符合的默认打印纸张大小。     与当地不符合的日期和时间格式。     本地化软件的列表项排序错误。     某些没有本地化的字符串。     仅出现在本地化后的版本中。 产生原因：     源程序在设计时没有正确进行国际化设计，例如，没有提供双字节字符集的支持。     源程序在设计时没有将可以本地化的字符串与软件代码进行彻底分离。     软件本地化后，单字节字符向双字节字符转化过程中，由于单字节和双字节之间的差别，可能使得某些本地化后的双字节字符的显示乱码。 3、本地化错误(Local Defect)   包括翻译错误和控件大小和位置引起的布局错误。 表现特征：    应该翻译而没有翻译的英文字符。     不应该翻译而翻译的中文字词。     错误翻译的字词。     较多隐含在对话框各控件以及帮助文档中。     只在本地化版本中存在该类型错误。     控件相互重叠或排列不均匀。     控件中字符显示不完整。     主要出现在本地化版本的对话框中。 产生原因：     翻译人员不熟悉翻译要求。     翻译人员工作疏漏。     用户界面的翻译与标准术语表不一致。     软件本地化后，由于源语言和本地化语言的表达方式不同，本地化后的字符数与源语言不同，每个字符所占空间尺寸不同，使得在英文版本正确显示的控件字符，可能在本地化版本显示不正确。 在编译本地化软件之前，没有对资源文件对话框及其控件调整大小。 本地化人员调整软件资源文件不当引起。例如，对话框及其控件高度或宽度的不正确调整。 一些对话框控件的布局错误如果也存在于源语言软件中，则属于软件设计错误，应该分配给软件供应商处理。    以上对本地化软件测试经常遇到的三种错误类型进行了分析，实际测试是一个动态的过程，不能孤立静态地对待发现的错误，错误的类型并不是绝对的，需要具体问题。例如，本地化软件中如果发现应该翻译而没有翻译的错误，既可能是由于本地化翻译过程中忘记翻译引起的本地化错误，也可能是源语言软件设计编程中的硬编码引起的国际化错误。再者，某些软件功能错误既可能是由于本地化翻译过程中采用了错误的翻译格式(例如，某些不应该翻译的程序变量字符被翻译了)引起的错误，也可能是源语言软件编程错误。最后，一个错误可能包含着其他的不同类型的错误。比如在对话框中，选择某个按钮，产生一个错误提示对话框，这可能是一个按钮功能错误，如果对话框中存在需要翻译而没有翻译的英文，则又是一个本地化翻译错误，如果对话框中存在无法辨识的字符，则又是一个国际化错误，如果对话框中按钮排列重叠，则还是一个本地化布局错误。2.4 本地化软件测试具体方法软件本地化测试工程师的基本任务包含两条：第一是发现软件缺陷；第二是报告软件缺陷。而发现软件缺陷是首要的任务，道理很简单：没有发现软件缺陷，则无法报告软件缺陷。因此，对于软件本地化测试工程师，提高发现软件缺陷的技能成为第一位的任务。 本文结合本地化测试的项目实践进行较为深入的描述。 发现缺陷的前提条件 ： 寻找和发现软件缺陷，首先需要理解软件本地化测试的目的和测试范围，在测试前，必须要阅读和理解测试说明书和测试用例；其次，要熟悉本地化软件缺陷的主要类型和表现特征。再次，熟悉被测软件的语言知识和软件功能特征。再次强调阅度测试说明书和测试用例的重要性。测试说明书包含了测试范围、测试系统的要求、缺陷定义等于测试密切相关的内容。测试用例包含具体测试范围、测试方法和测试步骤的具体实现方式。在正式进行任何测试活动前，必须认真阅读测试说明书 和测试用例，以便彻底了解测试的重点和可能出现软件缺陷的软件部分。         好的测试习惯是在测试准备阶段，通读测试说明书和测试用例，并且记录一些重点内容，对于不熟悉的内容及时交流解决。 不好的习惯是一边做测试，一边阅读测试说明书和测试用例。这种测试方法的最大危害是抓不住测试重点，没有测试的全局意识，往往被细小问题困扰，不利于提高测试效率。 发现缺陷的基本方法：本地化软件缺陷，具有比较鲜明的特征，发现本地化软件缺陷具有内在规律，以下对于发现本地化软件缺陷的基本方法进行论述。 1. 按照一定的顺序排查软件缺陷 本地化软件缺陷可以分为用户界面错误、语言质量错误和功能错误等。这些不同类型的错误有时同时出现在软件的某个部分，为了更全面的发现这些缺陷需要遵循一定的测试排查步骤。 以测试一个本地化对话框为例。首先，查看对话框控件的用户界面错误是否有被截断（ Truncation ）的错误 是否控件布局不整齐或者重叠 是否丢失热键 与英文软件的热键不一致 文本字体类型和大小错误 字符显示乱码错误     其次，查看对话框语言质量错误 是否有没有遗漏的需要本地化的英文文字 本地化的文字是否内容正确、专业和流畅 是否存在多余的翻译，例如，不该翻译的内容进行了翻译 是否翻译的内容带有敏感的政治问题和与目标市场的风俗传统不一致 标点符号是否符合本地化语言用户的使用习惯 再次，查看对话框功能错误 各个要测试的按钮功能是否起作用 各个要测试的按钮功能是否正确 Tab 键的跳转是否正确 控件的热键是否起作用       按照以上的顺序测试，主要是为了按照从易到难的原则，全面地查找软件缺陷，而不是说功能错误是不重要的，相反功能错误是优先级比较高的错误，应该正确处理。     2. 对照源语言软件确认缺陷     绝大多数本地化软件缺陷都是由于本地化过程引起的，但是也有少量错误是由于源语言软件不正确的设计引起的。这类错误表现为同一个错误在源语言软件和本地化 版本中都可以复现，例如某些功能不起作用，热键重复等。还有一种错误只在本地化软件中复现，但是本地化工程师无法解决，需要软件开发人员修改编码进行修正，例如不支持双字节的输入、显示、输出等，这些属于源语言软件的国际化设计错误。     因此，如果发现了功能错误和热键等软件缺陷，应该在相同测试环境的源语言软件上，进行同样步骤地测试，将测试结果进行比较，并且报告中应该指出该软件缺陷是否也存在于源语言软件上。     3. 利用软件缺陷的“扎堆”现象     软件缺陷的“扎堆”现象就是被测软件的某些部分往往出现不止一个错误。因此，如果在某一部分发现了很多错误，应该进一步仔细测试是否还包含了更多的软件缺陷。     软件缺陷的“扎堆”现象的常见形式：     对话框的某个控件功能不起作用，可能其他控件的功能也不起作用。     某个文本框不能正确显示双字节字符，则其他文本框也可能不支持双字节字符。     联机帮助某段文字的翻译包含了很多错误，与其相邻的上下段的文字可能也包含很多的语言质量问题。     安装文件某个对话框的“上一步”或“下一步”按钮被截断，则这两个按钮在其他对话框中也可能被截断。     软件测试中重视软件缺陷的“扎堆”现象，有助于发现更多的软件缺陷。     4. 关注测试容易产生软件缺陷的部分     软件缺陷几乎无处不在，可以出现在软件的任何地方。但是，软件缺陷的差生也有些规律，软件的某些部分更容易产生软件缺陷，这些部分是软件错误的“重灾区”，在测试期间应该引起重视和测试。     容易产生软件本地化缺陷的软件部分包括： 软件的“关于”对话框中容易产生版权（ C ）和商标（ TM ）等字符的显示错误。 软件中与语言设置相关的部分容易产生软件国际化错误，例如，排序方式、数字格式、日期格式、时间格式、货币符号、度量衡、电话号码格式、纸张类型等。 对话框和菜单中容易产生热键错误。对话框中容易产生用户界面错误。 终端用户许可协议（ EULA ）容易产生国家和地区名称翻译的政治敏感错误，例如，将地区翻译成国家等。 联机帮助文件中容易产生与软件界面不一致的术语翻译错误。     5. 参考其他语言版本测试发现的缺陷     如果测试项目组同时在测试不同语言的相通本地化版本，应该尽量参考其它本地化软件测试过程中发现的缺陷，例如，在报告的缺陷管理库中搜索报告的缺陷，与其 他语言的测试工程师交流等，查看自己是否漏测、漏报了某些软件缺陷，并且努力补上。另外，有些本地化错误可能仅仅出现在某个本地化语言版本中，属于该语言 版本的本地化过程引起的错误，在报告软件缺陷时，说明本缺陷不出现在其他本地化语言版本上，将有助于软件工程师正确隔离软件缺陷，分配给合适的人员处理缺陷。     6. 使用测试辅助工具     根据测试的不同内容，选择合适的测试辅助工具，可以有效的发现软件缺陷。例如，使用文件和文件夹比较工具（例如， Beyond Compare 或 WinDiff ）可以方便地比较英文和本地化 build 的文件和文件夹内容。 Html QA 可以很方便、准确地定位编译的本地化联机帮助文件的链接是否完整、正确。     总结：     本地化软件的缺陷的类型具有明显的特征，测试工程师只要熟悉这些特征，按照适当的测试顺序，仔细地观察比较可以发现绝大多数软件缺陷。另外，本地化测试也是不断实践、不断丰富测试经验的过程，测试人员之间加强交流，不断自我总结测试经验，可以不断提高寻找和发现软件缺陷的能力。 2.5 测试用例举例许多公司在测试本地化软件的时候用不同的测试用例。一个好的测试用例包含：测试数据，测试步骤，预期结果。然而，由于时间的限制，在实际的测试中可能不会包含所有的元素。在这一节，我介绍了6种测试用例(因为工作环境多为英文环境，再加上为了表述准确，我们会部分应用英文描述)：AD Hoc, Checklist , Spreadsheet Matrix, Pass/Fail Checklist, Detailed Test Case, and Complete Test Case.（1） AD Hoc test case AD Hoc 测试没有具体的指导方案。你只需要不断的用不断地倒弄要测试的软件。（2） Checklist test case Checklist test case 给出一些指导，告诉你测试什么，去哪测。但是你必须自己预测预期的结果。下面是它的一个例子。1. Open URL: 2. Input a term in search box, e.g.”聊城大学” ，do a search3. Input a term in search box, e.g. “jasld;kfjlsdajfklsakdjflskjdaflkasjdl”, do a search4. Press the link “影视”5. Press the logo “所有简体中文网页”6. Input a term in search box , delete it then（3） Spreadsheet test caseSpreadsheet test case 经常作为管理工具来定义，以及为测试人员分派测试任务。它可能包含一些测试数据，但是测试人员仍然需要自己寻找测试数据以及预测结果。下面是它的一个例子。（4） Pass/Fail test casePass/Fail test case 中，你仅需要关心你测什么，它是Pass 还是Fail。下面有一个例子。在这个例子中包含：1. 题目（Title）2. 步骤（steps）3. 预期结果（Expected Result）例：Search The following tests verify search in #000001Steps:1. Open URL: 2. Input a term in search box, e.g., “聊城大学”3. Click “搜索” button.Expected Result: Some results return._Pass _Fail _Not implemented（5） Detailed Test Case很多时候，我们希望测试时用的测试用例包含了大部分的核心，那样我们就可以仅仅把精力放在找Bug上，而不必要再重新找测试的步骤或特别数据。我们也希望我们能够报告我们已经测试了哪些，还有多少没有完成。Detailed test case 是个很好的选择。Detailed test case 是介于 Complete test case 和 Pass/Fail Checklist test case 之间的一种测试用例。它跟 Complete test case 相比，就像是速记，它的步骤更具灵动性，没有后者那么的严格。它比P/F用了更多的测试数据，即比P/F更加的严密。因此，Detailed test case 可以用 test case Datebase 或 Spreadsheet 两者之一来进行设计。其实，Detailed test case 可以用3种不同的格式来写，除了上述两种，还有一种 Document 的格式。下面我们分别举例说明。 Detailed Test Case 用 document 格式表示Steps:1. Open URL: 2. Input a term in search