在国际化测试中经常会提到hardcode的问题，也就是硬编码问题，我们今天就说一下这类问题。其实在前面我们都介绍过这块，今天主要把和hardcode有关的东西放在一起。
一般通常说的hardcode是指需要翻译的字符串没有提取到资源文件中。这些需要提取的字符串基本上包括了界面上显示的所有文字，包括lable，buttong的名字，提示信息，图片上的文字，如果log也需要本地化，那么记录log时也要将各种字符串提取到资源文件中。这一类的hardcode问题基本上属于国际化第三级的问题。这种问题其实一般不影响功能，但是会影响本地化的翻译工作，因为本地化翻译时一般是对资源文件里面的string进行翻译，如果string没有提取到资源文件中而是在代码中，那么这些在代码中的string翻译时将会漏掉，在本地化的版本上就会有没有翻译的字符串，这种问题一旦发现，就必须修改代码，将在代码中的string全部提取到资源文件中，然后需要对这些添加的string进行重新翻译，其实修改这类问题不难，一个问题可能几分钟或半个小时就改好了，主要是发现问题后会牵扯到资源文件修改重新翻译的问题，而一般翻译都是请第三方的专业翻译公司来做的，所以总的时间成本还是挺高的，所以这类问题最好在本地化介入前发现。
另一类问题，在国际化第一级中的一些功能问题其实也是由hardcode引起的，但是和第一种有着本质的区别。我在前面也提到过一些。将一些和系统有关的东西硬编码，没有使用系统变量，这种问题一旦发现将是非常严重的功能问题，一般情况下会导致某个功能不能正常使用。最常见的例子，默认安装路径C:\Program Files，这个也是我最喜欢举的例子，因为很多人喜欢用这个路径，但是微软在做本地化操作系统时，在德语等操作系统上，Program Files目录的名字也翻译了，给后来做应用程序的人就埋了个炸弹。还有一些和系统用户名组名有关功能也要重点关注，管理员在英文操作系统下为Administrators，俄语操作系统上为Администраторы，波兰语操作系统上为Administratorzy。如果直接用administrators,那在俄语，波兰语等操作系统上就有问题。避免这类问题的方法主要是在开发软件时要有国际化开发的思想，任何和系统有关的东西都不能假设其他操作系统和英文操作系统一样。
说到硬编码问题，我们就不得不提一下过度翻译(over translation)问题,如果将一些不需要翻译的东西提取到资源文件中，那么也会出问题，可能会过犹不及，比如说一个string中包含一个日期，这个日期是一个固定日期比如2010-12-31，如果将日期和其他字符一起提取到资源文件中，则这个日期可能不会根据系统的日期格式来进行变换，会引发另外的国际化问题。还有一种就是比如临时文件的路径 %TEMP%,如果把路径也提取到资源文件中，如果翻译人员将该路径进行了翻译，则log功能会由于找不到对应的路径而不能工作。过度翻译往往会引发功能问题，而不仅仅是UI问题。
关于第一种hardcode的测试比较简单，主要是在做测试工作中使用伪本地化（简单的说就是给显示的英文字符串加前后缀）build来进行测试，如果在伪本地化build上面发现了英文字符串，则很可能是一个hardcode问题。关于什么是伪本地化build和伪本地化build的作用我们在后面再谈。在测试过程中主要能确保每一个界面都跑了，所有有字符串的地方都检查一下，基本上就不会漏掉问题。根据我的经验，国际化测试人员最喜欢的bug估计就是这种hardcode问题了，发现起来比较简单，一个产品中，一般情况下这类bug是最多的，比较容易凑数量，而且一旦发现就肯定会重现，验证起来也比较容易。
第二种hardcode的测试就比较麻烦，因为哪些地方容易出问题很难说，往往是靠经验积累的，所谓吃一堑长一智，就是靠大家在测试中不断地积累，整理一些相关的测试点，然后在测试过程中重点关注。有些问题如果不在特定的操作系统上进行测试，估计黑盒测试测一辈子都测不出问题。做国际化开发和测试的在分析系统功能时，要有国际化软件开发的意识，就是看到某个功能的描述，就能想到可能有哪些国际化的风险，这个也是在日常工作中慢慢积累的，其实这个和一般的测试类似，比如出现了翻页功能，那肯定要测试翻到最后一页和翻到第一页这两种情况类似。
过度翻译问题也是类似的，要靠经验积累，就是大家在用伪本地化build测试时要对字符串敏感，不要看到全部字符串加了前缀和后缀就高兴了，不是hardcode问题了。对字符串中的日期，路径之类的要特别关注，看看是不是特殊处理了。
版权声明：本文出自lj1981727的51Testing软件测试博客：http://www.51testing.com/?27176
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
