软件本地化认识的几个误区

软件本地化认识的几个误区

随着软件国际化和全球化的进程加快，软件本地化得到了很大发展，但是由于本行业信息交流不畅，使得很多非软件本地化行业人士对软件本地化的了解非常少，甚至存在很多认识的误区。

误区之一：软件本地化就是软件翻译

很多非专业人士都存在类似的认识误区，其实软件本地化和软件翻译的不同在于：一，概念不同；二，范围不同。

软件本地化是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。

软件翻译是将软件中的用户界面、帮助文档和使用手册等的文字从一种语言转换为另一种语言的过程。

软件翻译仅仅是软件本地化的一个步骤，翻译的专业化、准确性对软件本地化的质量而言至关重要。除了翻译，软件本地化还包括其它多项内容，例如，软件编译、软件测试、桌面出版和项目管理等。所以，软件本地化不只是语言翻译过程，它包括更多的处理范围和内容，软件本地化已经发展成为一个系统的软件工程。

误区之二：软件本地化就是软件汉化

这是对软件本地化的片面认识，软件本地化与软件汉化的区别在于二者的范围不同。软件汉化是软件本地化的子集，特指软件的中文本地化。

以其它语言版本为基础，创建中文版本的软件本地化过程，称为“软件汉化”。较之“软件本地化”，它更为通俗易懂。随着国际交流的增加，本地化行业人士倾向于使用“软件本地化”。

当前，大约 80% 的软件本地化以英文软件为基础，这是因为大多数软件是在美国开发的。另外，英文越来越成为信息技术的通用语言，因此其它国家的国际化软件也通常以英文为源语言，再以此为基础实现进一步本地化。因此，如果以英文为源语言进行除中文（例如，韩文、日文等）以外的软件本地化，就不能成为软件汉化。

误区之三：任何软件都可以很好地进行本地化

从软件设计的理论上，任何软件都可以本地化，但是不同设计方式的软件可以本地化的能力不同。

本地化能力良好的软件在设计时将可以本地化的内容，从软件编码中单独分离出来。这些可以本地化的内容包括菜单、对话框内静态字符、屏幕提示，图标、版本信息等。这样，在本地化过程中，只要针对这些需要本地化的资源信息进行各种语言的本地化即可，而不会因为本地化影响源语言软件的功能，也不需要更改源代码。

采用软件国际化技术设计的软件具有良好的本地化性能。从软件技术开发角度讲，软件国际化的整个产品周期，包括需求分析、软件设计、软件编码、软件测试、软件发布等过程，都充分考虑并满足软件本地化的要求。

软件国际化的设计灵活性和可译性保证了软件具有良好的可本地化性能。设计灵活性保证基本产品可以易于适应当地语言的变化。例如，软件编码需要为双字节字符集或双向语言提供支持。设计可译性保证产品的任何语言组件便于识别和理解，并且与产品的其它部分保持独立。

因此，只有良好国际化设计的软件才能容易的本地化。

误区之四：软件全球化就是软件国际化

软件全球化和软件国际化都是软件本地化的基础，但是二者的不同在于：一，概念不同；二，范围不同。

软件国际化是在程序设计和文档开发过程中，功能和代码设计能处理多种语言和文化传统，使创建不同语言版本时，不需要重新设计源程序代码的软件工程方法。

软件全球化是为进入全球市场而进行的有关的商务活动。包括软件进行正确的国际化设计，软件本地化集成，以及在全球市场进行的市场推广、销售和支持的全部过程。

软件全球化的范围和内容更为广泛，它包含了为了软件进入国际市场而从事的全球范围内的商务活动。至少包括源语言软件设计的国际化、软件的本地化、建立国际品牌策略、市场推广、国际销售和技术服务支持等。

软件国际化更侧重于为了软件便于全球化和本地化而实施的软件设计和开发的技术活动。例如，源程序编码运用 Unicode 标准和本地化资源文件与源代码分离等技术。软件国际化是软件全球化的一个方面内容，软件的正确国际化设计是软件全球化和软件本地化顺利实施的技术保证。

误区之五：软件本地化的最佳机构是各种翻译公司

近年来很多以前主要从事文档资料翻译服务的翻译公司，纷纷提供软件本地化服务。但是它们的服务范围很多仅限于软件文档翻译，对于软件本地化需要的软件编译、软件测试、软件排版和大型本地化项目管理等，缺乏足够的经验。

软件本地化行业发展至今，已经是一个完整的工程体系，任何软件本地化项目都要考虑本地化的质量、成本、时间等因素。除了技术和经验之外，项目管理、实施流程和质量保证，对顺利实施本地化项目往往起着决定性的影响。

随着软件市场专业化分工的形成，出现了专门提供软件本地化服务的专业公司。基于多年本地化服务技术和管理经验，它们更熟悉本地化流程和客户的质量要求，掌握最新的本地化技术和工具，能够提供多个语言全系列本地化的专业服务。

因此，软件本地化的最佳机构是大型软件本地化服务公司。

Blast本地化详细流程

Blast 2.4.0+本地化详细流程（基于Windows系统） 1.程序获得。从NCBI上下载Blast本地化程序，下载地址： ftp://https://www.wendangku.net/doc/6d8448921.html,/blast/executables/blast+/LATEST/ 64×安装版▲ 64×解压（绿色）版▲ 最好安装或解压到X盘根目录：如X:\blast，尽量简短，方便后边命令输入。 2.原始序列获得。方法1：找到转录组测序数据unigene数据库文件：unigene.fasta 或unigene.fa，若为unigene.fa则直接改后缀为.fasta即可。找到或修改后将数据库文件移动至Blast本地化程序目录“X:\blast\bin”。方法2：从NCBI中的ftp 库下载所需要库，链ftp://https://www.wendangku.net/doc/6d8448921.html,/blast/db/FASTA/，其中nr.gz为非冗余的数据库，nt.gz为核酸数据库，month.nt.gz为最近一个月的核酸序列数据。下载的month.nt.gz先用WINRAR解压缩，然后用makeblastdb.exe格式化。方法3：利用新版blast自带的update_blastdb.pl进行下载，这需要安装perl程序。 注释：上述三种方法各有优缺点，前两种下载速度较快，但是每次进行检索都需要对数据库进行格式化（转化成二进制数据），第三种方法下载速度较慢，但是NCBI 中已经格式化好的，在进行本地检索时不需再进行格式化，直接用即可。 3.用文本编辑器（txt文件改名字及后缀）创建一个ncbi.ini文件，文件包含下 面内容：[NCBI]Data="C:\blast\data\" 先新建TXT文件，然后改属性，将ncbi.ini文件存放到C:\Windows 4.将Blast本地化程序目录添加路径中（该步骤非必须，但会给以后的操作带来 方便），方法： a)右击我的电脑选择属性，选择高级，点击环境变量，设置环境变量 b)系统变量中，选择Path，点击“编辑”，在变量值的后面添加Blast本地化 程序所在路径，E:\blast 点击确定，将安装路径添加到path。 5.运行MS-DOC。打开DOC窗口（点击开始，选择运行，打开的输入框中输 入“CMD”，确定），访问Blast本地化程序所在文件夹，依次输入：（1）X: 回车；（2）cd blast\bin，回车。

软件测试标准及方法

软件测试方法 β测试_Beta测试 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。 α测试_Alpha测试 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。 可移植性测试 可移植性测试，英文是Portability testing。又称兼容性测试。 可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。 用户界面测试-UI测试 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息(Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入

服务器本地化服务内容

精心整理保定市天晓汇智计算机科技有限公司 ——信息化环境运维本地化服务内容 我公司拥有多年的基于服务器、网络核心设备、机房整体运维等信息化环境方面的运维服务服务的技术积累和经验；同时拥有多名相关行业的资深技术工程师， 客户对信息化环境运维的更高要求。 我公司拥有专业的帮我吧?客户服务平台，可以及时的为客户提供故障报修和远程技术支持，同时结合售后服务管理系统，及时查询服务期限内的服务记录，以便于后期维护参考。 我们可以提供的本地化服务具体内容：

1.电话、微信、远程技术服务：签约设备故障时，0.5小时内本地技术电话、微信、远程服务支持； 2.现场技术支持服务：签约设备故障时,市区2小时内到达现场技术支持服务;周边县市8小时内到达现场技术支持服务(签约前需确定客户设备所在区域); 3.备机备件现场替换服务：签约设备发生严重故障,市区2小时内备机备件(或可替 (); 4. 服务 境.(同时5. 6. 7.信息化发展规划方案编撰服务：签约服务期内，我们会为客户提供一份整体信息化发展规划方案建议书，为客户在未来的整体信息化环境构架上，提供必要的规划方案参考。

8. 编制信息化环境运维及应急服务预案：签约服务期内，我们会为客户制定一份信息化环境运维及应急服务预案，以便于日常维护和遭遇应急故障时进行参考，可以有效的降低由于没有做好系统安排，导致的故障恢复的时间延误。 9.信息化环境运维培训：签约服务期内，我们可以为客户提供一次信息化应用和安全知识的基础培训讲座。通过这个讲座，我们将为客户讲授信息化环境运维的相关 10. 11. 12. 13. 14. 以提供系统性能调优服务，此服务包括MS-windows系列操作系统、Linux（Redhat、CentOs、Suse）。 15.数据库性能调优服务：我们可以提供基于MS-SQL系列数据库、Oracle系列数据库、MySQL系列数据库的性能调优服务。

试论软件本地化工程师的专业知识

软件本地化技术是融合软件工程、翻译技术和桌面印 刷等知识的综合性技术。在软件本地化项目实现过程中， 一般需要下面四种类型的软件工程师：软件翻译、软件编 译、软件排版和软件测试。根据岗位分工的不同，分别要 求掌握软件翻译、软件编译、软件排版和软件测试等具体 的专业知识。 软件翻译 软件翻译是将软件中的用户界面、帮助文档和使用手册等的文字从一种语言转换为另一种语言的过程。 （1）优秀的语言理解和书面表达能力 对软件开发采用的源语言（绝大多数是英语）文字的准确和迅速理解，是正确翻译的前提。良好的书面表达是保证翻译质量的基础。一名优秀的软件本地化翻译，不仅需要良好的外语基础，还要有良好的本地化语言的书面表达能力。 （2）软件翻译的格式要求和术语表达知识 软件翻译和其他普通文字翻译的区别在于，软件翻译对一些词汇和术语的处理要符合软件的特殊要求，符合软件英语领域的行业标准。 （3）常用翻译工具的安装和操作技能 软件翻译需要安装和使用翻译记忆软件，以便提高翻译的效率和质量。因此，需要快速安装、设置和操作常用翻译工具。 （4）可本地化的资源文件类型及其翻译方式 除了翻译在线帮助文档外，翻译软件的界面字符是软件本地化的工作之一。

需要翻译的字符包括菜单、对话框、屏幕提示、版本信息等类型，这些不同的字符要符合特定的翻译格式。 （5）多个行业领域的技术知识 随着软件技术的发展，需要本地化的软件的种类不断增加，如果具备这些软件的应用领域知识，可以提高翻译的效率和质量。 软件编译 软件本地化编译是以源语言软件为基础，使用本地化的资源文件，创建当地语言安装程序的过程。 （1）软件开发环境的使用经验 软件编译就是编译生成本地化的软件版本，修复本地化软件的软件缺陷，需要熟悉常用软件开发工具的使用。例如，Microsoft Visual Studio和Microsoft Visual https://www.wendangku.net/doc/6d8448921.html,。另外，如果具有软件开发经验，理解资源文件等的功能，对于修复软件缺陷大有裨益。 （2）软件安装技术和软件使用经验 软件编译后首先要测试是否可以顺利正确地安装。如果出现安装错误，应该尽快排除并重新编译。所以，如果具有常用安装程序的使用经验，有助于排除安装错误。另外，如果能够熟练使用当前编译的软件，则可以提高修复软件缺陷的效率。

软件测试实践

软件测试实践作业一 1.说明一个软件可能存在哪些类型的质量问题，并举例说明软件本地化中需要注意的问题不成熟软件带来的风险。不成熟的软件产品是把测试成本交给了用户：企业往往是出于项目周期安排不当，或者根本没有安排专门测试，匆匆完成编码设计就将产品交付使用了。这样的后果自然是用户觉得产品漏洞百出，项目执行过程也遥遥无期，最后，项目双方都筋疲力尽，用户觉得受骗，而软件商则毁了声誉，追加了大量项目实施费用，可谓是“赔了夫人又折兵。质量方面还存在一些共性的问题，主要表现在四个方面：一是产品所提供的功能与说明书不符，部分功能不能用；二是实际完成的系统与用户需求之间存在差距，产品或系统达不到预期的目标；三是性能不够稳定，产品中存在的质量缺陷影响系统的正常运行； 四是产品的文档资料不全，给用户的使用和后期升级带来困难。有两大类别的质量风险和本地化有两大类别的质量风险和本地化有关，第一类和用户界面有关，另一类和操作有关。如果系统不支持本地语言的字符集，那么就会面临一个本地化的问题，无论信息以哪种字符呈现，他们必须以准确的语言翻译来呈现.如软件汉化，为了使这些非英语国家的软件用户能够熟练使用软件，必须对英语软件进行加工处理，转换成用户所在国的文字。除了语法上的困难之外，还要面临文化、伦理和宗教禁忌等问题。所以必须把俚语、双关语和俗语考虑在内。这样用户在使用软件时，就没有了语言障碍，感觉软件就像它们国家开发的。 2.给出几个理由，说明产品说明书为什么通常是软件产品制造缺陷的最大来源 软件出现了产品说明书中不一致的表现 软件功能超出产品说明书的范围 软件没有达到用户期望的目标( 虽然产品说明书中没有要求) 测试员或用户认为软件的易用性差 软件没有达到产品说明书表明的功能 规格说明书可能不完全，有二义性或自身矛盾。（另外，在设计过程中可能修改功能，如果不能紧跟这种变化并及时修改规格说明书，则产生规格说明书错误。） 3.对聊天软件的登录功能进行测试，只需写出测试思路。 输入正确的用户名和密码 输入不存在的用户名 输入存在的用户名和不匹配的密码 不输入用户名和密码 输入用户名不输入密码 不输入用户名输入密码 密码是否区分大小写

软件本地化与国际化的入门知识

软件本地化的入门知识 什么是“本地化？” 人们常说的“本地化”是指在另一个国家正式行销某产品之前，对“原始产品”进行的“修订”。本地化通常不包括对原代码的“修订”。（参阅下面的“什么是国际化”。）本地化包括但不限于以下方面：翻译、文化本地化、DTP、图形处理、编译、测试，等等。 “翻译”和“本地化”的区别是什么？ 翻译是本地化的子集。翻译包括把源文字从一种语言转换到另一种语言。然而，当文字被翻译后，必然要对产品相应地进行许多其它更改。这些更改包括技术上和文化上的更改。 技术问题包括： 调整大小 重新编排格式 调整默认设置 重新编译 测试 重新创建图标 创建新的图形 重新编排文档格式 文化问题包括避免使用不恰当或冒犯性的语言 包装 图标 宣传 样品 政治敏感的术语，地方规章和宗教信仰 什么是“全球化？” 人们常说的“全球化”是指进入国际市场的全部过程。这一过程通常有四方面需要考虑。即源代码的国际化、本地化、建立国际品牌策略和国际销售实施。 什么是“国际化？”

人们常说的“国际化”是指任何涉及撰写或改变“原始产品”源代码的行为，从而使该产品在另一个国家能够顺利地销售。通常，源代码的国际化必须在本地化之前进行。国际化方面的例子包括： 实现双字节支持 转换到 UNICODE - 消除硬编码文本 国际化用户界面设计 调整默认设置 - 调整尺寸问题 “国际化”有时是指“赋予产品新的生命力。” 怎样能减少全球化的费用？ 对内部员工进行培训，使他们对国际化问题有所了解。 确定在国际市场上拓展的产品。 进行适当的外购，缩短上市时间。 在上市时间与产品质量之间选择适当的优先级。 为您的国际化项目指派一个有经验的项目经理。 选择一个出色的本地化供应商。 给您的合作伙伴、供应商和转包商提供充分的支持。 实施恰当的国际行销和分销策略。 成功的全球化涉及那些重要因素？ 资金 产品质量 上市时间 内部员工总数（工作能力与工作量） 在全球化过程中最常见的十个问题是什么？ 下面的列表包括了大多数 IT 公司在将他们的产品全球化时，面临的最耗费时间和金钱的问题。由于每个公司和产品是不同的，该列表并不适用于所有情况。向专家咨询来帮助您决定那些方面最适合您的特殊情况。 在本地化之前，产品授权或“国际化” 不适当。包括软件用户界面、帮助、文档和行销材

软件本地化外包测试流程分析

软件本地化外包测试流程分析 作者：崔启亮 经济的全球化促进了软件产业的国际化，软件国际化生产和全球服务成为更多国际软件公司的发展策略。软件产品要获得更多的国际市场份额，必须进行软件国际化设计、开发、测试和服务。 按照国际化要求生产的软件称为国际化软件，从实现技术和生产过程分析，国际化软件包括软件国际化和软件本地化两个相辅相成的环节。软件国际化保证软件具有“全球可用”的内在特征，而软件本地化可以满足目标市场的用户在语言、文化和功能的需要。 一、国际化软件开发流程 对于国际化软件而言，完整地开发周期将包括需求分析、国际化、本地化、发布和维护等过程。其中国际化包括设计、开发和测试等，在国际化的各个环节都要重视软件的本地化能力。 国际化软件的开发流程包括开发国际化软件需要遵循软件工程的要求，分为需求分析、软件设计、软件编码、软件测试、质量保证、软件发布等过程。国际化软件的开发流程如下图所示： 在需求分析阶段，既要考虑软件的功能需求，也要考虑软件的国际化需求。另外，为了缩短源语言开发的版本和本地化版本的发布时间间隔（甚至达到同步发布），国际化版本的开发应该与软件本地化过程同时进行。在测试方面，对国际化版本的国际化功能测试和对本地化版本的本地化测试尽可能同时进行，以便尽早发现和修改国际化设计错误。 二、软件本地化测试阶段 软件本地化是国际化软件开发的一个重要阶段，软件本地化是将一个软件产品按特定国家 / 地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。 为了保证本地化软件在语言、外观和功能方面符合本地用户的最终需要，需要再国际化软件生产过程中后期的软件本地化阶段进行本地化测试。

软件测试练习题及答案

、判断 01 ）测试是为了验证软件已正确地实现了用户的要求。错 02 ）白盒测试仅与程序的内部结构有关，完全可以不考虑程序的功能要求。对 03 ）白盒测试不仅与程序的内部结构有关，还要考虑程序的功能要求。错 04）程序员兼任测试员可以提高工作效率。错 05 ）黑盒测试的测试用例是根据应用程序的功能需求设计的。对 06 ）当软件代码开发结束时，软件测试过程才开始。错 07 ）据有关数据统计，代码中 60%以上的缺陷可以通过代码审查发现出来。对 08）无效等价类是无效的输入数据构成的集合，因此无需考虑无效的等价类划分。错 09 ）软件本地化就是将一个软件产品按特定国家或语言市场的需要翻译过来。错 10）在压力测试中通常采用的是黑盒测试方法。对 11）软件测试员无法对产品说明书进行白盒测试。对 12）功能测试工具主要适合于回归测试。对 13）测试人员说：“没有可运行的程序，我无法进行测试工作” 。错 14）自底向上集成需要测试员编写驱动程序。对 15）测试是可以穷尽的。错 16）自动化测试相比手工测试而言，能发现更多的错误。错 17）软件测试自动化可以提高测试效率，可以代替手工测试。错语句至少被执行一次。对 18）语句覆盖法的基本思想是设计若干测试用例，运行被测程序，使程序中的每个可执行19） Beta 测试是验收测试的一种。对 20 ）软件开发全过程的测试工作都可以实现自动化。错 21 ）软件只要经过严格严谨的内部测试之后，可以做到没有缺陷。错 22）结构性测试是根据软件的规格说明来设计测试用例。错 23 ）软件测试工具可以代替软件测试员。错 24 ）通过软件测试，可以证明程序的正确性。错 25）在单元测试中，驱动程序模拟被测模块工作过程中所调用的下层模块。错26）软件缺陷可能会被修复，可能会被保留或者标识出来。对 27）测试用例是由测试输入数据和对应的实际输出结果这两部分组成。错28）单元测试通常由开发人员进行。对 （29 ）现在人们普遍认为软件测试不应该贯穿整个软件生命周期，而应在编程完毕之后再进行，这样可以降低成本。错 （30）文档的错误不是软件缺陷。错 31） Junit 只是单元测试工具，并不能进行现回归测试。 （32）判定表法是一种白盒测试方法。

实施软件本地化工程

实施软件本地化工程 发布时间：2004-9-3 9:58:00 软件本地化项目正式实施的初始阶段是进行软件资源文件工程处理。包括评估与准备、资源文件抽取、标识资源文件、检查翻译后的资源文件、调整用户界面尺寸、编译本地化软件、修复软件缺陷等。 1、抽取资源文件 (Leverage) 为了便于工程处理，需要本地化的源语言的资源文件包含在翻译数据库 (TDB) 中，由软件供应商提供。 为了抽取和重复利用已经翻译的资源，需要使用正确版本的本地化工具软件对源语言翻译数据库进行工程处理。有些软件供应商使用它们自己开发的本地化工具，也有的使用业界专业的本地化工具，例如 Alchemy Catalyst 和 Pass Passolo 等。 在进行资源文件抽取和重复利用前，要准备好前一版本的已经翻译过的翻译数据库。如果是第一次进行软件本地化，由于一些本地化工具软件支持术语表的导入，则在软件供应商确认的情况下，尽可能利用软件供应商的其它软件产品的术语表和本地操作系统的术语表。 在进行抽取和重复利用时，应该对本地化工具进行正确的设置，例如，源语言、目标语言、代码页、默认目标字体、提取选项、前一版本的已经翻译的翻译数据库等。 经过抽取和重复利用处理得到的翻译数据库，只包含新增的和更新的需要翻译的源语言字符。除了提供这个数据库，还要使用本地化工具的统计功能，提供全部需要翻译字符的数量（包含新增的和更新的），以便翻译团队估计任务量，分配翻译资源。 2、标识资源文件 (Mark) 如果源语言软件进行了很好的国际化设计，那么资源文件中包含了全部需要翻译的内容。但是，实际上不少软件的国际化设计并不完美，相应地，资源文件中包含了一些不需要翻译的内容，例如，变量和命令选项。另外，资源文件中的某些条目可能需要根据不同的目标区域语言，分别进行不同的本地化处理。因此，在将抽取处理的翻译数据库进行翻译前，软件工程师需要对这些不需要翻译的和需要特殊处理的条目，添加标识注释。 通常添加的标识类型如下： 不需要翻译 不要超过 n 个字符长度 重复利用操作系统中的翻译，需要审阅 本字符串与 ID:xx 字符串组成串联字符串 不要删除热键符号 保留字符结尾的空格 不要改变变量的顺序 3、检查资源文件 (Validate) 本地化工程师要在编译本地化软件前，对资源文件的翻译语言质量进行检查。由于资源文件通常使用翻译记忆软件进行翻译，因此翻译数据库中标识的内容，通常不能导出到适合翻译的文档中，从而这些标识的条目可能不能被正确处理。因此，应该重点检查标识部分的翻译的正确性。另外，在翻译数据库导出/导入到翻译记忆工具软件支持的文件格式过程，以及翻译过程中，可能会引起翻译格式和内容的错误。 检查方法首先是利用软件本地化工具的检查功能，例如，Alchemy Catalyst 的 Validate Expert（检查专家）。其次，人工检查翻译数据库中被标识的内容。 需要检查的元素如下：

本地化测试软件缺陷分类详解

本地化测试软件缺陷分类详解 本地化测试发现的软件缺陷特征明显，便于分类。本文按照本地化测试软件缺陷的特征进行分类，详细地分析各种缺陷的表现特征，简要描述各类缺陷的产生原因，最后给出各类缺陷的修正方法。 1. 缺陷类型 概括地讲，软件本地化的缺陷主要分为两大类：核心缺陷和本地化缺陷。两类缺陷的详细分类如下图所示： 各类缺陷对应的英文名称如下表所示： 中文名称英文名称说明 本地化缺陷Localization Bug L10N Bug 核心缺陷Core Bug 语言质量缺陷Linguistic Bug 用户界面缺陷UI Bug Cosmetic Bug 本地化功能缺陷Localization Functionality Bug 源语言功能缺陷Source Functionality Bug 源语言国际化缺陷Source Internationalization Bug Source L18N Bug 2. 缺陷表现特征 由于本地化缺陷是本地化测试中出现的数量最多的缺陷，所以首先分析本地化缺陷的表现特征。而本地化测试中发现的核心缺陷虽然数量不多，但是它们的危害程度更大，所以需要认真对待，接下来分析它们的表现特征。

2.1 用户界面缺陷 ?控件的文字被截断（Truncation） o对话框中的文本框、按钮、列表框、状态栏中的本地化文字只显示一部分?控件或文字没有对齐（Misaligned） o对话框中的同类控件或本地化文字没有对齐 ?控件位置重叠（Overlapped） o对话框中的控件彼此重叠 ?多余的文字（Extra strings） o软件程序的窗口或对话框中的出现多余的文字 ?丢失的文字（Missed strings） o软件程序的窗口或对话框中的文字部分或全部丢失 ?不一致的控件布局（Inconsistent layout） o本地化软件的控件布局与源语言软件不一致 ?丢失的文字（Missed strings） o软件程序的窗口或对话框中的文字部分或全部丢失 ?文字的字体、字号错误（Incorrect font name and font size） o控件的文字显示不美观，不符合本地化语言的正确字体和字号?多余的空格（Extra space） o本地化文字字符之间存在多余的空格 2.2 语言质量缺陷 ?字符没有本地化（Unlocalized strings） o对话框或软件程序窗口中的应该本地化的文字没有本地化?字符不完整地本地化（Incomplete localized strings） o对话框或软件程序窗口中的应该本地化的文字只有一部分本地化?错误的本地化字符（Error localization） o源语言文字被错误地本地化，或者对政治敏感的文字错误地进行了本地化?不一致的本地化字符（Inconsistent localized string） o相同的文字前后翻译不一致 o相同的文字各语言之间不一致 o相同的文字软件用户界面与联机帮助文件不一致 ?过度本地化（Over localization） o不应该本地化的字符进行了本地化 ?标点符号、版权、商标符号错误（Incorrect punctuation, Copyright） o标点符号、版权和商标的本地化不符合本地化语言的使用习惯 2.3 本地化功能缺陷 本地化功能缺陷是本地化软件中的某些功能不起作用，或者功能错误，与源语言功能不一致。 ?功能不起作用（Not working） o菜单、对话框的按钮、超链接不起作用 ?功能错误（Error function）

翻译人士译员必备的一些本地化软件

软件本地化包含文字翻译、软件编译、软件测试和桌面排版等多项工作，需要多种软件配合才能完成。主要包含操作系统软件，通用软件，专用软件。选择合适的软件，可以提高工作效率，创建符合行业格式的文件。本文将分类列举这些软件本地化时用到的软件。 1．操作系统软件 操作系统是软件本地化项目实现的平台。它的选择必须符合本地化的软件要求。可能用到的操作系统包括：Windows，Macintosh，Solaris，Unix和Linux。其中，Window操作系统应用最为普遍。 Window操作系统分为不同语言的不同版本。在东亚语言的软件本地化中，分为简体中文、繁体中文、日文和韩文。常用版本包括：Windows NT 4.0，Windows 2000，Windows XP Professional和Windows XP Home等。根据软件本地化的需要，可能要安装相应的软件补丁程序(Service Pack)，例如Windows NT 4.0 Service Pack 6，Windows 2000 Service Pack 4, Windows XP Service Pack 1。在局域网中，要安装服务器版本或客户端版本的操作系统。 与Window操作系统紧密相关的是浏览器。某些本地化的软件对浏览器的类型和版本有特定的要求。例如，要求必须安装Internet Explorer 6.0等。 2．通用软件 通用软件完成软件本地化的文档处理和通信交流。选择的原则是：满足软件本地化的格式要求，操作简便，提高工作效率。 常用的文档处理软件包括： （1）文字处理软件 文字处理是软件本地化的主要内容之一。各种本地化软件包的文档都是使用文字处理软件编写的。常用的软件本地化文字处理软件包括：Microsoft Word，Windows 记事本，Ultra Edit。

软件测试人员常见面试题

1.测试的策略有哪些? 参考答案：黑盒/白盒，静态/动态，手工/自动，冒烟测试，回归测试，公测(Beta测试的策略) 2.正交表测试用例设计方法的特点是什么? 参考答案：用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂;对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来;但是更深的缺陷，更复杂的缺陷，还是无能为力的;具体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。 3.什么是兼容性测试?兼容性测试侧重哪些方面? 参考答案：兼容测试主要是检查软件在不同的硬件平台、软件平台上是否可以正常的运行，即是通常说的软件的可移植性。兼容的类型，如果细分的话，有平台的兼容，网络兼容，数据库兼容，以及数据格式的兼容。兼容测试的重点是，对兼容环境的分析。通常，是在运行软件的环境不是很确定的情况下，才需要做兼容。根据软件运行的需要，或者根据需求文档，一般都能够得出用户会在什么环境下使用该软件，把这些环境整理成表单，就得出做兼容测试的兼容环境了。兼容和配置测试的区别在于，做配置测试通常不是Clean OS下做测试，而兼容测试多是在Clean OS的环境下做的。 4.我现在有个程序，发现在Windows上运行得很慢，怎么判别是程序存在问题还是软硬件系统存在问题? 参考答案： 1、检查系统是否有中毒的特征; 2、检查软件/硬件的配置是否符合软件的推荐标准; 3、确认当前的系统是否是独立，即没有对外提供什么消耗CPU资源的服务; 4、如果是C/S或者B/S结构的软件，需要检查是不是因为与服务器的连接有问题，或者访问有问题造成的; 5.描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程? 参考答案： 就是Bugzilla的状态转换图。 6.你觉得bugzilla在使用的过程中，有什么问题?

Radialix-软件本地化工具-使用教程Word版

Radialix 是一款功能比较强大的软件本地化工具，支持以 VC++、Delphi、.Net 等语言编写的软件、以及 INI 格式文本文件的本地化。尤其是它具有非标资源的本地化功能、以及可以设置更多的资源属性。以下是开发商的描述。 - PE32、PE32+ 文件、.NET 程序集，资源和各类文本文件的本地化 - 加载子程序集的 .NET 程序集的本地化 - 非标（硬编码）字符串的本地化 - IDA 插件 - Unicode 支持 - 自动翻译、包括模糊翻译 - 机器翻译 - 翻译验证检查 - 对话框、窗体和菜单的所见即所得可视化编辑 - 导出和导入 CSV、TMX 和 TXT 文件 - 翻译记忆编辑器 - XML 格式的方案文件 下面是软件界面 要汉化编辑一个程序的资源首先要导入这个程序，点击【文件】【新建】【新建本地化方案】

在打开的窗口中点击【添加文件】浏览选择要打开的程序 弹出【文件属性】窗口中【目标构建操作】选项选择【创建本地话文件】

注：如果要编辑非编资源切换到【非标字串】选项勾选【提取非标字串】

其他可以保持默认点击【确定】后如果不继续添加需要编辑的程序就在弹出窗口继续点击【下一步】，然后来到语言添加界面双击简体中文添加到下方列表中。

【下一步】继续弹出信息窗口根据提示自行填写一下，也可不填直接点击【完成】. 等待程序载入完毕可以发现程序中所有能识别的资源的在左侧窗口列出来了，点击找到相关项目列表后直接在右侧窗口进行编辑即可。

编辑完毕后点选相关项目后右键点选【“切换”只读】 等待全部编辑完毕后点击【翻译】菜单栏点击【构建全部】即可在程序原目录生成名字后缀为【_CHS.exe】的程序，这个就是编辑后生成的文件。

软件开发标准化工作流程

目录 1 引言......................................................错误!未定义书签。 编写目的..........................................错误!未定义书签。 适用范围..........................................错误!未定义书签。 定义..............................................错误!未定义书签。 流程图............................................错误!未定义书签。 2 需求调研..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 需求调研..........................................错误!未定义书签。 注意事项..........................................错误!未定义书签。 3 可行性分析................................................错误!未定义书签。 4 需求分析..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 产物/成果.........................................错误!未定义书签。 需求分析任务......................................错误!未定义书签。 需求分析方法......................................错误!未定义书签。 原型化........................................错误!未定义书签。 需求报告..........................................错误!未定义书签。 划分需求的优先级..................................错误!未定义书签。 评审需求文档和原型................................错误!未定义书签。 5 系统设计..................................................错误!未定义书签。 概述..............................................错误!未定义书签。 产物/成果.........................................错误!未定义书签。 产品设计..........................................错误!未定义书签。 概述..........................................错误!未定义书签。 流程图........................................错误!未定义书签。

软件测试常用英语

Actual Fix Time 实际修改时间Assigned To 被分配给 Closed in Version 被关闭的版本Closing Date 关闭日期 Defect ID 缺陷编号 Description 描述 Detected By 被（谁）发现 Detected in Version 被发现的版本Detected on Date 被发现的日期Estimated Fix Time 估计修改的时间Modified 修正 Planned Closing Version计划关闭的版本Priority 优先级 Project 项目 R&D Comments 研发人员备注Reproducible 可重现 Severity 严重程度 Status 状态 Summary 概要 Creation Date 创建日期 Description 描述 Designer 设计人员 Estimated DevTime 估计设计和生成测试的时间 Execution Status 执行状态 Modified 修正 Path 路径 Status 状态 Steps 步骤 Template 模版 Test Name 测试名称 Type 类型 Actual 实际结果 Description 描述 Exec Date 执行日期 Exec Time 执行时间 Expected 期望结果 Source Test 测试资料 Status 状态 Step Name 步骤名称 Duration 执行的期限 Exec Date 执行日期 Exec Time 执行时间 Host 主机 Operating System 操作系统 OS Build Number 操作系统生成的编号OS Service Pack 操作系统的服务软件包Run Name 执行名称Run VC Status 执行 VC 的状态 Run VC User 执行 VC 的用户 Run VC Version 执行 VC 的版本 Status 状态 Test Version 测试版本 Tester 测试员 Attachment 附件 Author 作者 Cover Status 覆盖状态 Creation Date 创建日期 Creation Time 创建时间 Description 描述 Modified 修正 Name 名称 Priority 优先级 Product 产品 ReqID 需求编号 Reviewed 被检查 Type 类型 Exec Date 执行日期 Modified 被修正 Planned Exec Date 计划执行的日期 Planned Exec Time 计划执行的时间 Planned Host Name 计划执行的主机名称 Responsible Tester 负责测试的人员 Status 状态 Test Version 测试的版本 Tester 测试员 Time 时间 Close Date 关闭日期 Description 描述 Modified 修正 Open Date 开放日期 Status 状态 Test Set 测试集合 Acceptance testing（验收测试），系统 开发生命周期方法论的一个阶段，这时相 关的用户和／或独立测试人员根据测试计 划和结果对系统进行测试和接收。它让系 统用户决定是否接收系统。它是一项确定 产品是否能够满足合同或用户所规定需求 的测试。这是管理性和防御性控制。 Ad hoc testing（随机测试），没有书面 测试用例、记录期望结果、检查列表、脚 本或指令的测试。主要是根据测试者的经 验对软件进行功能和性能抽查。随机测试 是根据测试说明书执行用例测试的重要补 充手段，是保证测试覆盖完整性的有效方 式和过程。 Alpha testing（α测试），是由一个用户 在开发环境下进行的测试，也可以是公司 内部的用户在模拟实际操作环境下进行的 受控测试，Alpha测试不能由程序员或测试 员完成。 Automated Testing（自动化测试），使用 自动化测试工具来进行测试，这类测试一 般不需要人干预，通常在GUI、性能等测试 中用得较多。 Beta testing（β测试），测试是软件的 多个用户在一个或多个用户的实际使用环 境下进行的测试。开发者通常不在测试现 场，Beta测试不能由程序员或测试员完成。 Black box testing（黑盒测试），指测试 人员不关心程序具体如何实现的一种测试 方法。根据软件的规格对软件进行各种输 入和观察软件的各种输出结果来发现软件 的缺陷的测试，这类测试不考虑软件内部 的运作原理，因此软件对用户来说就像一 个黑盒子。 Bug（错误），有时称作defect（缺陷）或 error（错误），软件程序中存在的编程错 误，可能会带来不必要的副作用，软件的 功能和特性与设计规格说明书或用户需求 不一致的方面。软件缺陷表现特征为：软 件未达到产品说明书标明的功能；软件出 现产品说明书指明不会出现的错误；软件 功能超出产品说明书指明的范围；虽然产 品说明书未指出但是软件应达到的目标； 软件测试人员或用户认为软件难以理解， 不易使用，运行速度缓慢等问题。 Bug report（错误报告），也称为“Bug record（错误记录）”，记录发现的软件 错误信息的文档，通常包括错误描述、复 现步骤、抓取的错误图像和注释等。 Bug tracking system（错误跟踪系统， BTS），也称为“Defect tracking system， DTS”，管理软件测试缺陷的专用数据库系 统，可以高效率地完成软件缺陷的报告、 验证、修改、查询、统计、存储等任务。 尤其适用于大型多语言软件的测试管理。 Build（工作版本），软件开发过程中用于 内部测试的功能和性能等不完善的软件版 本。工作版本既可以是系统的可操作版本， 也可以是展示要在最终产品中提供的部分 功能的部分系统。

软件本地化认识的几个误区

软件本地化认识的几个误区 随着软件国际化和全球化的进程加快，软件本地化得到了很大发展，但是由于本行业信息交流不畅，使得很多非软件本地化行业人士对软件本地化的了解非常少，甚至存在很多认识的误区。 误区之一：软件本地化就是软件翻译 很多非专业人士都存在类似的认识误区，其实软件本地化和软件翻译的不同在于：一，概念不同；二，范围不同。 软件本地化是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。 软件翻译是将软件中的用户界面、帮助文档和使用手册等的文字从一种语言转换为另一种语言的过程。 软件翻译仅仅是软件本地化的一个步骤，翻译的专业化、准确性对软件本地化的质量而言至关重要。除了翻译，软件本地化还包括其它多项内容，例如，软件编译、软件测试、桌面出版和项目管理等。所以，软件本地化不只是语言翻译过程，它包括更多的处理范围和内容，软件本地化已经发展成为一个系统的软件工程。 误区之二：软件本地化就是软件汉化 这是对软件本地化的片面认识，软件本地化与软件汉化的区别在于二者的范围不同。软件汉化是软件本地化的子集，特指软件的中文本地化。 以其它语言版本为基础，创建中文版本的软件本地化过程，称为“软件汉化”。较之“软件本地化”，它更为通俗易懂。随着国际交流的增加，本地化行业人士倾向于使用“软件本地化”。 当前，大约 80% 的软件本地化以英文软件为基础，这是因为大多数软件是在美国开发的。另外，英文越来越成为信息技术的通用语言，因此其它国家的国际化软件也通常以英文为源语言，再以此为基础实现进一步本地化。因此，如果以英文为源语言进行除中文（例如，韩文、日文等）以外的软件本地化，就不能成为软件汉化。 误区之三：任何软件都可以很好地进行本地化 从软件设计的理论上，任何软件都可以本地化，但是不同设计方式的软件可以本地化的能力不同。 本地化能力良好的软件在设计时将可以本地化的内容，从软件编码中单独分离出来。这些可以本地化的内容包括菜单、对话框内静态字符、屏幕提示，图标、版本信息等。这样，在本地化过程中，只要针对这些需要本地化的资源信息进行各种语言的本地化即可，而不会因为本地化影响源语言软件的功能，也不需要更改源代码。

软件开发标准化工作流程V10

目录 软件开发标准化工作流程 1引言 1.1编写目的 说明编写这份软件开发标准化工作流程的目的，指出预期的读者。 1.2适用范围 互联网开发中心所有项目。 1.3定义 列出本文件中用到的专门术语的定义、外文首字母组词的原词组。

1.4流程图 2需求调研 2.1概述 需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

2.2需求调研 总体而言，需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研。 ●业务规则 各个流程、功能点等事项的办理，都会有相关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。 ●表单数据 对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。 ●贯穿系统的关系 各个模块或科室之间的数据交换、传递以及数据共享等，需要我们调研人员与各个模块或科室的相关负责人进行多方沟通，确定一个多方满意的需求调研结果。 2.3注意事项 ●调研过程中，用户说的很快，不可能等我们全部记录之后， 再讲下一个问题。因此，只能在笔记本上速记，有时只能记录1、2个关键字。因此，每天调研结束之后，当天晚上必须整理当天的调研情况，写成一份调研日记。整理当天的调研记录时，还要整理出待明确的问题，下一次再找机会与用户再沟通、确认。

●调研的各个阶段，必须出具相关文档或文件，比如调研计划、 流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 ●所有疑问必须等到明确的答复，不能出现相互矛盾、似是而 非的需求。需准确理解客户的讲解，如果有问题的先做记录，之后将整理的问题向客户询问，得到明确的结果。需求必须是客户接受和确认的，不能有臆测的需求。 ●要合理安排好时间和进度。有时候客户还有自己要做的事情， 不一定能及时相应。所以必须提前预约好时间，保证整个需求调研的进度。 ●能积极引导客户。当客户出现疑虑，而调研人员能明白且能 做好客户想要的东西的时候，调研人员能及时积极引导客户，详细讲解我们所知道的东西，并能让客户接受与确认。 ●如遇公司有相关原型或产品，调研人员需先详细了解公司的 相关原型和产品，根据成品，找出本地化的差异化需求。 3可行性分析 这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。 可行性研究应该比较简短，这个阶段的任务不是具体解决