什么是本地化测试?示例测试用例和清单

⚡ 智能摘要

本地化测试检查软件在特定地区、语言环境或文化中是否运行正确,涵盖翻译内容、用户界面布局、货币、日期和时间格式,以及该市场用户所期望的本地惯例。

  • 🌐 速记: 该技术写作 L10N,因为在本地化中,L 和 N 之间有 10 个字符。
  • 🎯 主要目标: 内容和用户界面几乎吸收了测试人员记录的所有本地化缺陷。
  • 🧭 四个阶段: 典型的测试周期包括构建验证、功能测试、回归测试和最终验收。
  • 📐 布局风险: 翻译后的字符串会展开,双字节和从右到左的脚本会破坏英语从未展现过的布局。
  • 🤖 自动化: 一旦相同的场景在多个地区运行,脚本套件就能迅速收回成本。
  • 🔀 与 I18N 不同: 国际化负责编写代码;本地化负责验证最终市场。

针对目标区域进行语言、货币和日期格式的本地化测试

本地化测试

本地化测试 是一种软件测试技术,用于测试软件在特定地区、区域或文化中的行为。对软件进行本地化测试的目的是测试特定区域适当的语言和文化方面。这是根据目标语言和国家定制软件的过程。

本地化测试主要影响的领域包括内容和UI。

这是测试全球化应用程序的过程,其 UI、默认语言、货币、日期、时间格式和文档均根据目标国家或地区设计。它确保应用程序足以在特定国家/地区使用。

计费示例:

1. 如果该项目是为印度泰米尔纳德邦设计的,则设计的项目应该使用泰米尔语,应该有泰米尔虚拟键盘等。

2. 如果项目是针对美国设计的,那么时间格式应该按照美国标准时间更改。此外,语言和货币格式也应遵循美国标准。

下图展示了同一产品针对不同地区进行的调整,语言、货币和格式规则都会发生变化,而底层结构保持不变。

本地化测试:将一个产品版本适配到多个目标语言环境

为什么进行本地化测试?

进行本地化测试的目的是检查特定地区的语言和文化方面是否合适。它包括根据要求更改用户界面甚至初始设置。

在这种类型的测试中,许多不同的测试人员会重复相同的功能。他们会验证各种内容,例如排版错误、UI 的文化适宜性、语言错误等。

它也被称为“L10N”,因为在单词 localization 中,L 和 N 之间有 10 个字符。

这项努力背后也有商业原因。标签翻译错误,或者日期写成 03/04 而不是 4 月,都会削弱团队已经付费进入的市场对其的信任度,而且这些缺陷是由目标地区的测试人员发现的,而不是由…… 图形用户界面测试 用英语表演。

本地化测试与国际化测试

这两项活动是先后进行的,而非相互竞争。国际化测试 (I18N) 确认代码库能够接受任何语言环境;本地化测试 (L10N) 则进一步确认某个特定语言环境是否正确。

本地化测试 (L10N) 国际化测试(I18N)
验证产品在目标区域是否具有原生感 验证该产品无需重新开发即可支持多个地区。
检查翻译文本、货币、日期、时间和文化契合度 检查字符编码、字符串外部化和区域设置感知代码
一旦该市场的翻译版本存在,即可运行。 首先运行,在任何文本发送翻译之前运行。
需要一位懂当地语言的测试员或审阅员 核心团队可以使用伪翻译版本执行此操作。

查看本教程 本地化测试和全球化测试的区别.

如何进行本地化测试

对于典型的本地化测试,我们设置了构建验证测试, 功能测试, 迭代测试,并最终签字。

1. 构建验证测试只是 功能测试这项操作在质量保证开始任何详细测试之前执行。其精神与……类似。 烟雾测试如果语言包完全无法加载,则本地化版本会很快被拒绝。

2. 正常测试是运行正常测试用例并在执行过程中发现日志缺陷的步骤。

3.回归测试是 缺陷 回归过程以确保缺陷得到修复,同时修复的缺陷不会对周围区域产生影响。

4. 最终签字是在交付给客户之前对构建进行最终检查。

每个阶段都会针对不同的语言环境重复进行,而不是针对整个产品只进行一次。在法语版本中修复的缺陷也必须在德语和日语版本中重新修复,因为它们之间经常共享同一个字符串资源。

本地化测试的自动化

如果项目很大,需要经常测试,那么我们会选择 自动化测试.

  • 选择自动化工具编写脚本。
  • 以待测试本地化策略的场景为例。
  • 根据此编写脚本。
  • 收集结果并将场景更新为通过/失败。

注意: Selenium 是该领域的先驱工具之一。它功能非常丰富,但使用起来需要更多的技术知识。

自动化存在一个值得明确指出的局限性。脚本可以证明货币符号发生了变化,并且没有字符串被截断,但它无法判断翻译是否自然流畅,也无法判断图标是否令人反感。机器检查处理的是机械层面的问题;语言层面的问题仍然需要由母语审校人员来解决。

本地化测试工具

本地化工作会用到三种不同类型的工具,大多数团队最终都会使用这三种工具。

  • 功能自动化框架: Selenium, Appium 类似的框架会对每个本地化版本重新运行相同的测试套件,而大部分重复验证工作都发生在这里。
  • 翻译管理系统: 拥有字符串资源的平台可以让翻译人员、开发人员和测试人员使用同一个词汇表,这样同一个术语就不会在两个屏幕上以两种不同的方式翻译。
  • 伪定位工具: 这些操作会在真正开始翻译之前,用带重音符号的加长占位符替换英文字符串,从而暴露出无法容纳较长单词的硬编码文本和布局。

设备和浏览器的覆盖范围与工具本身同样重要。字体、输入法和默认语言环境因平台而异,因此本地化版本必须在实际目标设备上进行测试。 移动测试 以及为以下浏览器集定义的 Web应用程序测试.

本地化测试最佳实践清单

  • 聘请一家在 i18n 工程方面拥有专业知识的本地化公司
  • 确保您的本地化测试策略为双字节语言提供更多时间。
  • 在执行 DBCS 之前,请确保您已正确国际化您的代码。trac发送任何文本进行翻译
  • 首先将所有字符串外部化到资源文件中,这样就不会有任何用户可见的文本仍然硬编码在源代码中。
  • 尽早运行伪本地化版本,因为它可以在花费翻译资金之前发现截断和硬编码文本。
  • 预留版面空间用于文本扩展,因为从英语翻译过来的内容通常比原标签的篇幅要长。
  • 在真实屏幕上测试从右到左的语言环境,例如阿拉伯语和希伯来语,因为镜像布局和混合方向的文本在这些屏幕上最容易出现问题。
  • 维护一份针对不同地区的风格指南,涵盖日期顺序、小数分隔符、地址格式、敬语和语气。
  • 请一位以英语为母语的人审阅最终的屏幕画面,因为文化契合度无法仅凭剧本来保证。

其中两项取决于平台而非语言,因此本地化版本通常会与原生版本一起安排发布。 兼容性测试配置测试 而不是在他们之后。

本地化测试的示例测试用例

下表给出了一组初始检查项。每一行都会变成完整的检查项。 测试用例 一旦填写了特定区域设置的预期结果。

S.No 测试用例 Description
1 提供词汇表以供参考和检查。
2 时间和日期的格式适合目标区域。
3 电话号码格式适合目标区域。
4 目标地区的货币。
5 许可证和规则是否遵守当前网站(地区)。
6 页面中的文本内容布局无错误、字体独立且行对齐。
7 特殊字符、超链接和热键功能。
8 输入字段的验证消息。
9 生成的版本包含所有必要的文件。
10 本地化屏幕具有与源产品相同类型的元素和编号。
11 确保软件或 Web 应用程序的本地化用户界面与目标操作系统和用户环境中的源用户界面相一致。
12 排序和字母顺序遵循目标语言的规则,而不是源语言的规则。
13 从右到左的语言环境能够正确地镜像布局,包括导航、图标和混合方向的字符串。
14 键盘输入、拼写检查和搜索功能支持带重音符号和多字节字符。

本地化测试的优势

以下是本地化测试的好处

  • 降低总体测试成本
  • 总体支持成本降低
  • 有助于减少测试时间。
  • 它具有更大的灵活性和可扩展性。

这些节省源于集中式地一次性修复本地化缺陷,而不是像以前那样针对每个市场支持队列分别进行修复。可访问性方面的提升也往往随之而来,因为同样的原则既能保证布局在较长的德语文本下保持完整,也能保证在放大文本时保持完整。 可访问性测试.

本地化测试的缺点

以下是本地化测试的挑战

  • 需要领域专家
  • 聘请当地翻译通常会使这个过程变得昂贵
  • 不同国家的 DBCS 字符存储方式不同
  • 测试人员可能面临时间安排上的挑战

进度压力是大多数团队低估的因素。翻译工作通常在开发周期的后期进行,因此本地化缺陷往往在临近发布时才显现出来,而这恰恰是布局更改成本最高的时候。本地化规划是更广泛的计划的一部分,详见下文。 软件测试类型 使这种挤压保持在可控范围内,以及总体上 软件测试 引言部分概述了该阶段在整个阶段中的位置。

常见问题

将设备语言切换为阿拉伯语或希伯来语,并检查整个布局是否镜像一致——包括导航、图标、进度指示器和滚动方向。混合文本(例如,拉丁语产品名称出现在阿拉伯语文本中)通常是故障点。

翻译后的文本通常比英文原文长,因此按钮、菜单和表格标题可能会出现溢出或截断的情况。在设计时预留一些宽度,然后在最长的目标语言文本上进行验证,可以避免大多数此类问题。

它会将所有可翻译的字符串替换为带有重音符号且故意加长的版本。任何仍然以纯英文显示的文本都是硬编码的,任何被截断的标签都表明布局无法容纳扩展。这两种情况在购买翻译服务之前就已经存在。

质量保证工程师负责功能和布局检查,而目标语言的母语人士则负责审核措辞、语气和文化契合度。这种分工方式避免了聘请语言学家重新进行技术回归测试。

硬编码的英文字符串、截断的标签、模糊的日期顺序、错误的小数点和千位分隔符、损坏的重音字符,以及连接起来的句子,由于这些片段是用代码组装的,所以翻译成毫无意义。

伪本地化检查在字符串外部化后立即开始,远早于翻译。完整的本地化检查在第一个翻译版本可用时开始,并在每个迭代周期中重复进行,而不是等到发布前只进行一次检查。

机器学习会将本地化截图与源布局进行比对,以标记截断和重叠部分,对翻译的术语偏差进行评分,并对风险最高的语言版本进行排名。最终的文化判断仍由母语审校人员做出。

是的。它会生成本地化参数化的草案。 Selenium 脚手架、资源文件断言和基于区域设置代码的数据驱动循环。每个区域设置的预期值仍然必须来自样式指南,而不是模型。

总结一下这篇文章: