本地化测试

　　Christian Kopsch自2011年起就在位于弗莱堡的公司Haufe-Lexware担任web app的测试经理。Kopsch是敏捷过程的超级粉丝，偏爱做Scrum和Kanban项目。除了他作为一名测试经理的项目管理工作外，他还一直对测试激情满满，常常一有可能就尝试着自己测试。大家都鼓励Christian在本地化项目中使出浑身解数。让中国市场适应一个web app，对他及整个团队来说是一项新且刺激的挑战，一个具有里程碑意义的成就。
　　在全球化，外包和Web 3.0的时代，越来越多的公司争先恐后地进入市场，急着把他们的软件解决方案提供给国际客户。软件成功国际化后，第二步就要进行本地化了。通常，本地化是一个让软件适应特定地理和文化区域的过程。下文就是一篇作为一名测试和测试经理关于一个本地化项目的为期一年的工作经历报告。
　　开始
　　我们的在线知识数据库成功投放到德国市场后，我们的团队收到了额外订单要将我们的web app投向中国市场。我们的核心团队包括七名开发，两名测试，一名担任需求工程师的产品所有者，一名scrum专家和一名优秀的项目经理。如果有更多的工作量，就需要外部开发员和QA资源来立即支援核心团队。敏捷项目中最先使用的方法是Scrum；然后是Kanban。这个项目包含许多刺激的地方，对我们来说有很多新的挑战及机遇。新项目最开始，我们在软件本地化方面几乎没有任何经验。为了克服这个挑战，我们需要在几个月内就获取该知识。一开始会有很多不同的问题，比如:
　　--中国的审查制度会对我们的工作产生多大的影响呢？
　　--中国的审查制度会如何影响并限制我们的客户呢？
　　--我们能和中国的合作伙伴及企业主顺利沟通吗？
　　--转化数据而没有一丝问题，这可能吗？

　　此时我们一开始的疑问就很快消失了，我们畅通无阻的工作。很幸运，我们北京的承包商在这种情况下也没有任何疑问。从一开始，我们就学会问恰当的问题，这样就为我们后来的合作奠定了坚实的基础。
　　准备
　　我们的第一次头脑风暴会议上，我们讨论了各种场景以便检测软件测试中可能的影响。在讨论中，我们发现开发和测试是难以分割的。基本问题有：功能和非功能的需求，硬件和软件测试配置，以及语言和文化现实间的差异。项目开始时，很明显，利益相关者都没有足够的经验能立马找到一个明确的满足客户期待的方法。很不幸，我很确定，当我们的项目在2013年年中开始时只有几个实际案例对本地化和软件测试近研究并报告。有了我能用到的有限材料，我在接下来的几周集中工作，开展了广泛的研究并获取了新知识。另外，我们和一名将我们引入“软件的国家化和本地化”话题的外部专家建立了研讨会。研讨会后，我们开始想接下来几周会发生什么，包括有哪些问题我们要提前解决，哪些障碍仍需面对。
　　主要问题
　　从项目的角度出发，下面的几大问题都需要好好审查并更做出具体的规定：
　　1.硬件和软件标准及要求
　　首先我们讨论了中国潜在客户会使用哪些硬件和软件。他们使用不同的外部输入设备，不同的显示器或不同的组件吗？移动设备和台式机的区别在哪？会用哪些操作系统，浏览器或第三方组件呢？在一份详细的分析中我们发现，和德国市场相比，这几点区别并不大。
　　2.字符集和特殊字符
　　我们意识到，中国字符集和特定特殊字符会影响我们的app。这可能是相关的，比如：注册或登录功能中，当我们在我们的app中输入搜索问题时。而且，通过我们的app发送email时，我们需要知道如果名字，email地址或域中有特殊字符时，会不会发生错误。因为迄今为止，我们的软件一直在Windows 1252中使用Windows编码的数据，我们在显示中文字符上确实存在一些错误。该项目转而使用UTF-8中统一编码的数据，并将内部搜索功能从Optisearch变为TRS（一个在中国被广泛使用的app）。
　　3.数字格式
　　哪些额外数字格式可能会需要呢？最受关注的就是日期，时间，度量单位，权重和数字或邮政编码和电话号码的不同格式。这样，我们需要额外的输入字段吗？其中我们的软件重点关注日期格式。app中，我们使用日期标记或归类不同的文件类型。所以我们将格式从德国转为中国标准。
　　4.图形用户界面（GUI）
　　在将软件本地化的过程中，按钮、标签、导航和菜单的转变是必须的。这就出现了一个问题，关于翻译了的文本是否仍适合现存布局和按钮。我们会遇到什么类型的bug呢？这些bug接下来会不会要求一些新类型呢？在关于我们软件的表面的几项手动测试中，如预期的，我们发现了因为从德国文本转变为中文字符而造成的许多类型的bug。有时候按钮和标记转变时需要不同数量的字，空间和字符距离。这些bug被改正，新标记被调整的能够满足类型指导了。
　　5.不同的输出格式
　　我们app的一个基本功能，能够将不同文件类型导成不同格式。中国的文件标准是什么？我们需要新的输出格式吗？现存文件类型格式是否不适应现在的中国市场？企业主做出分析后，我们发现，和我们现在支持的格式并没有多大的区别，因此这方面并不需要做任何修改。
　　除了这五个主要问题之外，我们还必须考虑详述并调整许多其他问题。我们处理外部系统和技术接口，许可及追踪。我们还很关注语言精准度，很明显我们需要母语是中文的人或翻译。
　　尽管整个项目有这么多难题，但我们团队还是克服了它们。关于测试的具体问题，我，作为一名测试员和测试经理，走出了自己的安全区。
　　本地化测试
　　项目开始时，我们团队使用Scrum。开发并交付了常规版本，但是普通app的必要基本功能仍包含在内。此外还开发了一些针对中国市场的新功能。几次sprint后我们发现，某些情况下，Scrum对我们来说太静态了。单独一次sprint，新功能和用户故事常常过于复杂不能有效地确定和实施。
　　随后，项目转向Kanban。整个过程中，固定sprint和任务变得更流畅且我们团队变得更敏捷了。除了我们软件的实际本地化，我们中国客户的新要求发给我们了，然后立即就被我们指定，开发并测试。整个本地化和开发过程，以及所有测试水平的测试都是在德国进行的。生产也在德国；但是我们需要建立一个将软件和数据转向远东的过程。项目完成并交付到中国后，我们的客户就会在中国进行用户验收测试。验收测试一完成，就可以投入使用了。之后，我们的软件将在中国市场推广，我们的app将由中国的中国服务合作商本地托管。在测试开始时，我们要面临关于测试系统和测试环境的问题。首先，我们复用我们之前就有的（有中文安装包的）测试系统。我们决定在德国市场最受欢迎的浏览器上执行我们的测试——火狐，Chrome和IE8-11——因为我们希望以后能在中国市场支持它们。另外，我们也在百度浏览器（它在中国被广泛使用且它基于Chrome引擎）上进行测试。对于测试环境，我们首先使用不同的本地测试实例。同时，我们也在建立一个在德国托管的分期系统。然后，我们改进了我们的测试能力并开始在该环境中进行性能测试。最初因为参数文件与中文字符集不相容，我们在开发和执行HP Loadrunner脚本上遇到了一些小问题。我们快速地解决了这个缺陷并发现了一些应对措施，这样我们就能继续使用脚本了。
　　德国和中国间的沟通
　　关于这点，我们几乎不用自动化测试，因为我们的用户界面最初太不稳定了。新功能和变化
　　被迭代且敏捷地用到GUI中。这些通常是半成品，因为一些要求说明地并不完整。这导致了更多的问题，更需要更好的项目团队、客户及中国的同事间交流沟通。因为德国和中国间六小时的时差，只有很少时间空窗来通过如电话进行每日言语交流。不然我们就得花上一天来等着接收邮件反馈。但是，我们还是成功地克服了这些挑战。测试员几乎不直接与中国客户交流。直接交流的责任由与中国同事密切合作的首席项目经理及一些精选的开发人员承担。最重要的一点就是要经常与项目团队中所有的参与者和利益相关者交流，对话。
　　功能测试
　　我们的功能测试主要手动执行。我们将它们与探索性测试相结合。随着我们的GUI开发了越来越多的中文标记和文本，渐渐产生了关于如何区分我们app中各个标记，按钮及其相关功能的问题，因为我们核心团队中没人说中文。我们想各种办法。一种是向翻译咨询。很幸运，这个问题比预期的解决得要早：有个同事母语是汉语，他支持我们核心团队所有必要的翻译工作及文本转换。另外，我们也建了一个和我们中文产品相同的英文参照产品。这就简化了测试工作，尤其是对于外部同事和支持本地QA团队的工作人员，特别是关于中文按钮，标记和文本的识别工作。在我们所支持浏览器的扩展GUI测试中，我们发现了许多类别的如预期一样的bug。这些bug被修好了或GUI的类别进行了相应的调整。用来创建和执行测试用例的主要工具是HP ALM。
　　测试工具和测试流程
　　我们主要的疑问是：关于中文特殊字符的主要问题很幸运地没有事实根据且工作毫无阻碍。事实上，在我们现在的项目中简单地显示中文字符是不可能的，但是在使用HP ALM中的统一编码后，一切都进行地很顺利，且中文字符显示也没有任何问题了。我们决定将这些相关字符附加到一个文本文件中，因为我们偶尔才会用到它们。Bug追踪的话，我们仍使用JIRA。我们无需改变该工具，因为所有的JIRA流程都是在德国进行的。此外，项目语言德语英语都有，这样就没有问题了。
　　所学到的经验教训
　　所有这些挑战都出现在去年。我们快速地适应了困难，我们快速地克服了这些障碍以保证最佳实现。为期十二个月的项目后，我们将把完成的本地化软件移交给我们的中国客户。在中国进行了验收测试后，我们的软件就会推向中国市场的我们的新亚洲客户。回顾过去一年，我的结论是：软件测试和软件开发都有类似的挑战。将软件测试和软件开发分开看待几乎是不可能的。因此，客观来讲，多数情况下，它们是同义的。尤其是在我们项目开始时，我们将软件测试视作独立的工作。持续的沟通是项目最重要的方面；团队在我们的敏捷项目中合作地越紧密，我们就能越快地在项目质量上获得提高。项目是否将继续是维护模式或我们移交后是否有新的要求都还不是很明确，因为我们要看看我们的潜在中国客户是否会接受我们的软件或，甚至，它是否能在现在的市场上好好运行。这是我们进入这个市场的第一次尝试，我们必须看看过去几年我们的投入是否能让客户满意。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。