从 I18N 到 L10N

我所在的项目组Filenet项目组，进行的是我认为是相当标准的Localization Test的流程，我在这总结一下，我个人认为只有知道了工作流程，才谈的上项目管理，就好像有了东西，才能用篮子去盛。这个简单的道理，我自己也觉得曾经工作的一些困惑，原因就这句话了。
来源是我左右问的。
首先介绍一下I18NàL10N，就是说从一个I18N的英文的Build到一个本地化的Build。我的理解就是这么一回事，比如说一个IE页面的Title，I18N的build里面这样实现就可以了，用一个外部变量，typedef short* String 类型的（可是保证是双字节为单位），到了L10N的build， 赋另一个值，不就可以了吗。
1．Filenet公司(爱尔兰)的Deployment Test Team，它主要测试一个I18N的build的安装，并且为QA Test Team做一些类似BVT(Basic Validation Test)的测试，当它做完了之后，它将系统打包，形成VMware的压缩文件，交给QA Test Team。
2．QA Test Team，包括一个QA leader, 几个QA, 一个Engineer。它一方面从Deployment Test Team得到压缩文件，这样一个测试的环境可以很快的搭起来，而且重要的是QA Test Team所用的I18N的build是没有被改动的。另一方面，它从翻译组（我不知道这是个什么Team，应该在Filenet美国公司里）得到一个VSS源程序，Engineer根据这个文件，可以Create出来一个Language pack。（VSS是Visual Source Safe的缩写。）。QA leader的作用不用说了，QA负责产品的功能和外观的测试，如果有自动化测试的内容，也是QA的事情。功能测试的时候，根据Word文档形式的Testscripts，外观的测试，只能用眼睛。自动化测试是最先进的测试手段，用于功能和压力测试。Engineer的职责是负责本地化过程的一系列事情。
然后在介绍一下一个本地化的build是如何产生的，在I18N build上安装language pack。在我们测试的这个产品是这样的机制，这是一个Browser-Server的产品，重新在Websphere或Weblogic上部署一个包含Language pack的一个Application就可以了。
然后的重点就是一个localized build的产生过程，这个好话我就不说了，“一个本地化的产品要看起来或使用起来象是在这个本地化语言的国家里开发出来的”。
介绍这个之前，简单介绍一下Clearquest在项目管理的应用。Clearquest是IBM Rational 的一个产品，用于项目管理。举例来说，一个Manager或者一个Architector 可以发Quest给一个Developer，这个quest为Open, Developer接到后，处理，转给Testor，此时Quest可以为coded，Testor接到后，测试成功，tested。在我们的这个项目中，QA发出Bug quest给Engineer, Engineer接到后，修Bug，成功后, fixed, QA确信后，Closed。
以后我把I18N build称为US build，VSS源文件称为VSS文件。得到这个US build和VSS文件后，在测试环境部署US build，Engineer根据VSS文件编译一个language back出来，安装language pack，得到Localized prebuild。
QA在prebuild上 regress(回归测试)其他语言出现的bugs，Engineer 通过解这些可能的bug，得到build1.
QA在build1上进行Testcase测试，这个时候进行的是功能测试，得到build2。
QA在build2上进行相应区域的界面的测试，是美观测试，得到build3。
QA在build3上regress build1和build2的bugs，得到build4。
QA在build4上做smoke test（一些功能测试），如果没有问题，得到发布版，如果有问题，出build5，通过后得到发布版。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/2228/showart_5814.html

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有