混淆（WPF-）应用程序的UI自动化测试

Question

我想知道，如果对代码进行了混淆（如果使用访问应用程序自动化属性的测试框架以及基于Ranorex，TestStudio，TestComplete的基于图像的测试框架，则尤其是关于WPF应用程序），则运行UI测试有多困难？嘎吱，...）。

我只能找到很少的信息，这意味着应该始终在混淆代码之前进行测试，但不完全是原因。

但是，可能有人争辩说，应该在实际交付给客户的版本上运行测试。 另外，如果我们将3rd-Party组件用作软件的一部分，则可能无法使用未混淆的版本。

据我了解UI自动化，目标是公开应用程序的相关属性，以便它们不仅可以用于测试框架，还可以用于屏幕阅读器等。 因此，我不太理解为什么一旦对代码进行混淆就可能会出现问题。 混淆本身根本不应该影响暴露属性的数量，或者是？

Answer 1

我无法代表其他人，但是Ranorex依靠UIA（UIAutomation）（一种自动化和可访问性框架）来自动化WPF应用程序。

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

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

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

从理论上讲，在混淆之前或之后测试应用程序都没有关系，因为从理论上讲混淆不会对应用程序的逻辑产生任何影响。 实际上，存在一些差异，这可能会影响您的测试，尽管很少。 混淆的应用程序往往会更快一些，有时混淆会破坏意外的或计划外的代码元素。 因此，您必须问自己是否要对用户执行应用程序上的UI自动化，而用户实际上会发现并捕获可能仅影响UI自动化的混淆问题，还是要在混淆之前测试应用程序，以确保应用程序的行为正确无视（无论其他版本如何）部署步骤可能正在等待中。 显然，无论选择哪种方法，您都必须应对可能的影响。

在混淆之前运行测试的另一个注意事项是，如果在运行测试时遇到应用程序错误，则开发人员将可以更轻松地调试它们。 但是，如果程序员知道如何调试混淆的符号（使用代码映射等），则这种考虑主要是没有意义的。