我想知道，如果代码被混淆了，运行 UI 测试有多困难（尤其是关于 WPF 应用程序，当使用访问应用程序的自动化属性和基于图像的测试框架时，例如 Ranorex、TestStudio、TestComplete、挤压，...）。
我只能找到很少的信息，这意味着测试应该总是在代码被混淆之前完成，但不完全是为什么。
然而，有人可能会争辩说，测试应该在实际交付给客户的版本上运行。此外，如果我们使用 3rd-Party 组件作为 SW 的一部分，我们可能没有使用非混淆版本的奢侈。
据我了解 UI-Automation，目标是公开应用程序的相关属性，以便它们不仅可以用于测试框架，还可以用于屏幕阅读器等。因此，我不太明白为什么代码被混淆后可能会出现问题。混淆本身不应该影响暴露属性的数量，还是它？
我不能代表其他人，但 Ranorex 依靠 UIA (UIAutomation)，一个自动化和可访问性框架，来自动化 WPF 应用程序。
UIA 几乎从未受到混淆的影响。还要记住，大多数混淆工具避免混淆公共类的公共成员，这是大多数 UI 控件使用的。
唯一的例外是您显式配置混淆工具以混淆可能影响 UIA 的字符串（例如AutomationProperties附加属性）的极少数情况。
另一个相当罕见的例外可能与反射有关。如果您使用反射（通常是一个坏主意，但有时是不可避免的）来激活应用程序中不太容易到达的区域，那么混淆可能会带来问题。这个问题很容易通过在混淆工具中添加一些例外，或者在混淆之前运行测试来解决。
从理论上讲，无论您是在应用程序被混淆之前还是之后测试它都无关紧要，因为理论上应该混淆对应用程序的逻辑没有任何影响。在实践中，存在一些差异，这可能会影响您的测试，尽管很少见。混淆的应用程序往往更快一些，有时混淆会破坏意外或计划外的代码元素。因此，您必须问自己是否要在用户实际会遇到的应用程序上执行 UI 自动化并捕获可能只会影响 UI 自动化的混淆问题，或者在混淆之前测试应用程序以确保应用程序的行为是正确的，而不管任何额外的构建和部署步骤可能正在等待中。显然，无论您选择哪种方法，您都必须应对可能产生的影响。
在混淆之前运行测试的另一个考虑因素是，如果在运行测试时遇到应用程序错误，开发人员将更容易调试它们。但是，如果程序员知道如何调试混淆符号（使用代码映射等），那么这种考虑主要是没有实际意义的。