本地化测试

发表于:2012-7-03 10:51

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Kiki 译    来源:51Testing软件测试网采编

  在本文中,我们将含括在编码阶段期间所能够做的事情和为了使发现问题最有效,你应该将你的本地化测试力量集中在何处等问题。

  翻译应用程序的资源和测试代码与开发平行进行通常是一种较好的方法。这有助于在过程的早期揭露代码,功能设计中的问题,因为那时做变更相对还是比较容易的。

  这也可以帮助决定什么时候“冻结”用户界面和功能设计。越快越好。设想一下每次用户界面发生变更时,都不得不重新翻译的情况。而且UI的变更也涉及到其他类型必须要修改的文档-在线帮助和指南。

  记住晚期的变更会给本地化产品的发布带来显著又昂贵的费用和延期。

  在本地化过程中,记住以下事项将可以帮助你在随后的阶段中节约大量的时间:

  ● 位图(Bitmaps):应该无字母和标点符号因为它们到处都会发生变化,例如引号。

  ● 本地化中的对话框(Localizing dialog box):与英语相比,有些语言方面需要为消息和命令名称准备更多的空间。一个30个字符的简单信息在翻译为另一种语言的过程中可以会“增长”40%到60% 。菜单和对话框中的文字可能会溢出。以前为了使文字合适的缩略语可能会无法接受了。

  ● 正文串可能会超出内部的存储量,或覆盖代码或其他的数据。扩展的菜单可能增长的太宽以致于不能在屏幕上显示完全

  ● 应该删除掉在目标语言下不支持的功能,而不应把它变灰,那样只会混淆用户,因为用户可能不理解为什么有些命令从来都不可用。

  到什么地方查找问题

  发现没有为本地化正确设计的源代码是很普通的事。最极端的案例是硬编码的字符串,常量和在代码中的字符。包含需要被本地化的硬编码元素的文件通常很难处理。翻译不能有效地翻译那些是由开发者编写的源代码文件, 特别是如果代码正在不断地开发过程中。 大多数翻译不是程序员,并且可能会删除掉重要的细节, 例如结束的引号或分号,或者和翻译字符串一样翻译程序关键字,这将导致开发人员要花格外的时间去修复这些类型的问题。

  一个典型的解决这种问题的办法是将所有可本地化的项目分离到一个或多个文件中,这样可以使本地化变得更容易管理。例如,对于基于Windows的应用程序,最简单的方法就是使用“资源(resource)”文件。它们很容易编辑,而且你不需要重现编译源代码。

  此外, 所有本地化的文件, 不管它们包含代码还是用户界面元素,都可以放在一个单独的目录下,这样翻译只需要访问包含本地语言文件的和其负责的已本地化文件的目录

  以下列出了通常需要本地化和应该是可本地化文件中一部分的要素。

  ● 信息Messages

  ● 常量Constants

  ● 提示Prompts

  ● 对话框Dialogs

  ● 声音Sounds

  ● 宏语言Macro languages

  ● 状态栏Status bars

  ● 菜单Menus

  ● 工具栏Toolbars

  测试

  从表面上看起来很简单,但是测试已本地化的产品需要注意一些并非所有的测试小组都准备的细节。

  如果测试在产品生命周期的早些时候就开始测试,那么已本地化的产品会一个更好的成功机会。为了迅速的发布它然后移到本地化版本上,一个常见的错误是集中全部的测试力量在国内的产品上。 所有版本的早期测试经常能发现会影响本地化版本存在于核心代码里的严重的缺陷。 这将为早期测试做计划以确保开发部门在整个项目中重视国际化和地方化问题而不是把那些忧虑当作追悔。

  在测试已本地化的软件时,考虑不同的测试的层次。

  最初,集中测试在本地操作系统上程序的安装和卸装;正文串在对话框中是否合适;纠正货币,时间等等,遵循的格式;并且所有的正文串都是目标语言。测试过程中一个关键组成部分是保证“最终”的本地化产品功能和需求的一致。

  更高级的功能性测试将集中在拼写的正确性,语法,排序等等。注意到这需要一定的语言学水平,这类测试通常要求一名说母语的人(native speaker)来执行测试。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号