UI-模糊(WPF-)应用程序的自动化测试

Question

我想知道，如果代码被混淆了，运行UI-Tests有多难(特别是当使用访问应用程序的自动化属性的测试框架，而不是基于图像的测试框架时，例如Ranorex，TestStudio，TestComplete，Squish，...)。

我只能找到一些关于这方面的信息，这意味着测试应该总是在代码被混淆之前完成，但不是确切的原因。

然而，有人可能会争辩说，测试应该在实际交付给客户的版本上运行。此外，如果我们使用第三方组件作为软件的一部分，我们可能没有使用非模糊版本的奢侈。

据我所知，UI-Automation的目标是公开应用程序的相关属性，这样它们不仅可以被测试框架使用，还可以被屏幕阅读器等使用。因此，我不太理解为什么一旦代码被混淆就会出现问题。混淆本身不应该影响暴露的属性的数量，或者是不是？

Answer 1

我不能代表其他人说话，但Ranorex依赖于UIA (UIAutomation)，一个自动化和可访问性框架，来自动化WPF应用程序。

UIA几乎不会受到混淆的影响。还要记住，大多数混淆工具避免混淆公共类的公共成员，这是大多数UI控件使用的。

唯一的例外是，在极少数情况下，您显式配置模糊处理工具来混淆可能影响UIA的字符串，例如AutomationProperties附加属性。

另一个相当罕见的例外可能与反射有关。如果你使用反射(通常是一个不好的主意，但有时是不可避免的)来激活你的应用程序中较难访问的区域，那么混淆可能会带来问题。这个问题可以通过向混淆工具添加一些异常，或者在混淆之前运行测试来轻松解决。

从理论上讲，无论你是在应用程序被模糊之前还是之后测试它，这都无关紧要，因为模糊处理理论上应该不会对应用程序的逻辑产生任何影响。在实践中，有一些差异，这可能会影响您的测试，尽管很少。混淆的应用程序往往会更快一些，有时混淆会破坏意想不到的或计划外的代码元素。因此，你必须问问自己，是想在用户实际得到的应用程序上执行UI自动化，并捕获可能只影响UI自动化的混淆问题，还是在混淆之前测试应用程序，以确保应用程序的行为是正确的，而不管管道中可能等待着什么额外的构建和部署步骤。显然，无论您选择哪种方法，都必须处理可能的影响。

在混淆之前运行测试的另一个注意事项是，如果在运行测试时遇到应用程序错误，开发人员将更容易调试它们。然而，如果程序员知道如何调试混淆的符号(使用代码映射或类似的)，那么这种考虑基本上是没有意义的。