我已经完成了四种方式中的一种，我可以用这些方式中的每一种分享我的经验和意见。

1. 检查非文本以验证消息。通常带有错误消息或其他重要的信息性消息，它们与作为 html 标记属性可用的错误（或消息）代码相结合。如果不是，您可以要求您的开发人员将它们包括在内，以便您知道每次出现消息 ID 1234 时，该文本是适合情况和区域设置的文本。这实施起来相当便宜，并为您提供了相当大的成功概率。
   

2. 使用捆绑在服务器代码中的 resx 来获取适合您的自动化的区域设置文本。这需要找到并设置一个工具或代码来为您解析 resx 文件。此外，每次针对新构建运行时，您都需要下拉当前版本的 resx 以及您的自动化。这将为您提供最完整的覆盖范围，并确保您始终检查开发人员为区域设置分配的文本。缺点是这实际上并没有测试任何重要的东西。您仍然不知道文本是否适合上下文，并且您正在寻找的文本与您从 resx 获得的文本不同的可能性几乎为 0，因为您正在使用相同的数据测试网站该网站使用的。
   

3. 基本上是 Siva 在他的回答中描述的方法。这种方法的问题是维护成本。每次字符串更改时，您都必须使用正在运行的每个语言环境的字符串来修改 XML。
   

4. 验证英文版本的文本，但对于其他语言环境跳过它。这实际上是我建议的，可能是除了 1 之外的。很可能你会在每次构建时对英文网站运行一次自动化。通过这种方式，您可以确保文本正确显示并且适合上下文。在所有其他语言环境中进行测试并不会真正为您买任何东西，因为您无论如何都不理解文本。你仍然可以做一些事情，比如确保 div（或任何包含文本的标签）存在并且样式正确（不隐藏等），就像它显示文本一样。您可以做的另一项检查是确保在非英语运行时不会出现英文文本。通常如果文本没有本地化，
   
   总而言之，详尽地测试每个语言环境不会给您带来太多收益，而且可能会浪费资源。您应该专注于测试网站的功能，并希望您的本地化团队能够很好地完成他们的工作并在上下文中测试他们自己的字符串。
   另一个注意事项：如果您依靠文本来识别元素，那是一个错误，您应该要求您的开发人员改为提供 ID，或者找到一些其他方式来识别元素 - 可能使用与确实具有 ID 或其他元素的其他元素的关系在不同语言中不变的唯一标识符。
   附加说明：您可以而且应该仍然测试具有不同字符集和/或手动或自动双向的语言。老实说，我更喜欢手动进行这些测试，因为您将看到的错误通常与页面布局和/或字符集的正确呈现（如果编码不正确）有关，而这些错误很难以自动化方式进行测试。

这是自动化测试设计中出现的常见问题。

由于表单中的文本字符串可能会更改，并且如果目的是对存在的任何语言的“文本”进行功能验证，那么我建议您像您所做的那样使用控件 ID。

虽然这是可能的（并且 Siva 解释了一种可能的方式），但根据我的经验，在自动化中验证字符串的内容似乎并不值得追求恕我直言，并且是持续维护和大量误报的秘诀。

如果测试字符串的内容很重要，那么您始终可以调用 API 来检测测试中的当前 OS UI 语言环境/语言（而不是将 arg 作为参数传递），然后使用模糊匹配或获取字符串示例 a 将字符代码点与给定语言环境/语言的字符范围代码点值进行比较。

我承认使用自动化来验证多语言用户界面可能是合适的。我公司的用户界面只有英文。我使用自动化来验证部分用户界面，但我手动验证消息。我认为不仅要孤立地查看每条消息（和其他静态文本），还要在用户界面的其余部分的上下文中查看每条消息（和其他静态文本），这最好由实际的人来完成。

是的，我们会验证。从我工作过的自动化套件中，我观察到了它。

每个代码中的 ID 都是相同的，根据语言环境，我们可以传递预期的文本。

我们可以有一个GetExpectedText接受 Id 和语言环境的函数。它将返回适用于 / 以检查该语言环境的文本。

您可以使用自定义验证方法

VerifyText(GetActualTextBased by ID, GetExpectedText("Id","Locale"))