我从一种产品的自动化开始，这种产品使用一种语言，不久将移植到另一种语言。唯一的好处是-测试自动化才刚刚开始。

所以有两件事让我感到烦恼-测试脚本中的硬编码字符串（应用程序标题，警报消息等）和应键入测试数据

我在想拥有一个全局变量，该变量指示要执行测试的语言环境，然后决定要在测试方法中使用的String / test数据。 >
现在考虑我将测试中使用的字符串外部化，然后决定在测试方法中使用哪种语言的字符串，因此我可以执行-

 public void myAweSomeMethodWorkingInAllLocales() { 
   if(locale is fr) {
     testDataFile=privateLocation/frTestDataForThisLocale
     testStringFile=privateLocation/frAPPStringForThisLocale
   } else if (locale is in) {
     testDataFile=privateLocation/inTestDataForThisLocale
     testStringFile=privateLocation/inAPPStringForThisLocale       
  }
  //Carry Out my Super tests here
  }


，但是我发现在我的每种测试方法中这样做都不麻烦。我可以改善吗？

#1 楼

测试国际化和本地化还有许多其他方面，以及我认为您正在尝试解决的其他解决问题的方法，但是我将仅针对您的特定问题提供答案。

我建议从测试套件中删除所有硬编码的语言环境引用，而不是让整个测试套件针对通过命令行参数，属性文件或环境变量指定的单个语言环境进行测试。然后，不要执行此操作... 

if(locale is fr) {
  testDataFile=privateLocation/frTestDataForThisLocale
  testStringFile=privateLocation/frAPPStringForThisLocale
} else if (locale is in) {
  testDataFile=privateLocation/inTestDataForThisLocale
  testStringFile=privateLocation/inAPPStringForThisLocale


}

...我会这样做：

 testDataFile=getTestDataForThisLocale(the-locale-we-are-testing-this-time)
 testStringFile=getAppStringsForThisLocale(the-locale-we-are-testing-this-time)


如果要测试两个语言环境，可以运行两次测试套件。这使您不必在整个测试套件中嵌入依赖于语言环境的if语句。

评论

更干净的阅读，我也想工具。

–塔伦
11年8月8日在6:13

#2 楼

我在这里写了一篇关于这个的博客。这些是我开发针对28种语言的产品的测试自动化解决方案时遇到的一些陷阱。

我绝不会对任何字符串进行硬编码-实际上，您的自动化根本不应该依赖它们。根据被测产品的体系结构，您应该从开发中获得认可，以确保UI上的每个控件都具有唯一的静态标识符。例如，对于基于HTML的UI，可以使用'id'属性。我相信也可以为Win32控件分配标识符。

维护字符串文件是一种不好的方法，如果字符串发生更改（例如，由于本地化错误而导致的新版本或错误修复），您将需要更新此类文件。

如果您使用某种独特的标识符，则您的自动化可能会适用于许多版本，除非发生重大的UI大修。

评论

猜猜是什么，在发布此问题之前，我阅读了您的博客并发表了评论（尽管尚不可见）。我看到有关唯一标识的要点。但是，如果您必须检查不同语言的验证消息，该怎么办？现在，您将保留不同的String文件，每个语言环境一个文件吗？

–塔伦
11年8月8日在6:16
是的，在那种情况下，我们将为每种语言维护一个字符串文件，但是通常这只是几个字符串。即使这样做，我们也会遇到一些问题，因为错误消息会随着版本的不同而变化，或者某些技术作者决定更改错误消息以使其更具描述性。我猜在这样的情况下，别无选择（除非您有认真的开发人员支持，并且错误对话框根据其所包含的内容分配了ID）。顺便说一句，评论已被批准;-)

–吉米·柯林斯（Jimmy Collins）
2011年8月8日在16:04
我们的错误消息始终包含一个文本和一个错误ID（内部用于获取本地化的字符串格式字符串）。因此我们的错误是经过验证的错误错误ID而不是错误文本

– k3b
11年8月8日在20:54
@ k3b也是一种很好的方法。

–吉米·柯林斯（Jimmy Collins）
2011年8月9日在21:18

#3 楼

如果您的应用程序支持Unicode，那么我真的不理解按语言或语言家族隔离输入或输出测试数据的原因。如果您在产品代码中的某个地方遇到了ANSI和Unicode之间的问题，那么您肯定会遇到一些问题，并且在整个Unicode范围内使用各种字符进行测试将比基于语言的资源更快地解决这些问题。

但是，尤其是在这种情况下，随机测试数据生成变得很有价值；甚至是特定于语言环境的测试数据。不必跳过其他的if或switch / case语句，您可以将“ locale”参数传递给采用语言/ locale参数的“ GetString（）”方法。

设计良好的随机字符串生成器可以按语言族，语言等或混合方式生成字符串。我现在还在做一个工作，它将生成看起来像真实句子的文件，或者从特定于语言环境的文档中获取文本内容，随机化单词并吐出句子，段落等。

或者，如果您是使用静态文件读取测试数据，还可以让系统完成工作。如果您有一个用每种语言环境/语言代码命名的文件，则可以以编程方式检测当前的语言代码，然后只需读取该文件即可。 

            string testDataFileName = "testdata.txt";

        CultureInfo ci = CultureInfo.CurrentCulture;
        string isoLanguage = (ci.ThreeLetterISOLanguageName);

        string path = Path.GetFullPath(
            Environment.GetFolderPath(Environment.SpecialFolder.Desktop));
        try
        {
            using (StreamReader readFile = new StreamReader(
                Path.Combine(path, string.Concat(isoLanguage, testDataFileName))))
            {
                //do stuff
            }
        }
        catch (FileNotFoundException)
        {
            // handle file not found exceptions
        }


在这种情况下，我得到的是3个字母的ISO语言名称（完整列表位于http://www.loc.gov/standards/iso639-2 /php/code_list.php），并将其添加到文件名或扩展名之前，然后使用流阅读器打开并读取文件的内容。

这样就无需在启动时传递命令行args测试，并且只需添加新的satic数据文件即可根据需要扩展到新的语言环境。

#4 楼

多年前，我采用了类似的方法在不同的语言环境下进行测试。

我在项目的国际化阶段使用了类似的方法：
http://strazzere.blogspot.com/2010/04/pseudo-translation-of -strings-as-aid-to.html

我还外部化了所有资源（字符串），并由专业翻译为我翻译了这些资源。