WPF UI自动化与.NET 4.5与棱镜和MVVM与单击一次应用程序，以方便非开发人员使用

Question

我已经搜索并尝试了一些东西，也就是这条线：

如何测试WPF用户界面？

我试着开始使用Systems.Windows.Automation和TestAutomationFX(第三方工具)。我的观点是，虽然TestAutomation对简单的事情有好处，但是当它下降到多个UI级别时(一个用户控件中的一个用户控件来自一个加载的程序集)，我可能不得不手动地调整它们的代码，以得到我想要的东西。System.Windows.Automation看起来很老了，我必须手动完成所有事情，这可能比我想要投入的时间更长，因为我不是全职从事自动化创建。我还从WindowsSDKforWindows7下载了Inspect.exe，它可以很好地反映UI中的对象。对于后面的简单代码，这两个测试人员运行得都很好，但是当它向下几个层时，似乎有点牵扯进来。我还打算尝试GitHub上的“TestSTack/ White”，它是从最初的Project中移来的。

我很好奇最近是否有人在UI自动化方面有经验，而非开发人员可以在QA职位上使用这些经验。我正在考虑得到VS 2013测试专业，但这似乎是过火，潜在的，是比VS 2013专业比更多的费用，从我可以看到。基本上，这不是加载测试或复杂的动态实体结果更改，只是函数测试，希望有10个左右的不同变量的运行。这只是一个更令人困惑的布局，因为我们结合了棱镜方法，Microsoft.Practices.Prism，以及MVVM。

我不介意在VS 2013和.NET 4.5中开发一些东西，但我希望得到的东西不是我正在为之开发的另一套项目，而是为了节省时间。在单元测试项目中，我是一个极端的新手，但最终目标实际上是：

1. 为非开发人员提供一个exe或某些环境，以便在使用WPF编写UI后，按照Prism和MVVM体系结构自动运行Click。
2. 希望有某种类型的CSV、config或其他方法，他可以更改变量来运行某些测试。
3. 让它能够以配置或可变的方式输入单击一次应用程序的exe (单击一次很有趣，在我打开任务管理器的经验中找到它，然后单击一次应用程序的“打开位置”，这在不同的框中是不同的)。

这可能要求很多，或者对那些每天做单元测试的人来说很简单，我不知道。我打算尝试第三方产品、非.NET产品来运行.NET，并在VS中使用C#进行编码以使项目运行我的UI(只要它可以在没有VS的框上运行)。

Answer 1

理想情况下，您根本不需要进行很多UI测试--应用程序的大部分逻辑应该通过单元测试进行测试。使用MVVM，您可以很容易地测试视图模型，以确保按钮在需要时被禁用/启用，依此类推。

通过UI测试核心业务逻辑是一种灾难。别这么做。UI测试非常脆弱，如果UI发生了任何重大变化，则需要重新记录或更新UI。如果您的测试失败的原因与您试图测试更改的核心逻辑无关，那么您就不太可能相信测试验证了它们应该验证的内容。如果您不信任这些测试，就会开始忽略失败。“哦，考试有时会失败，没什么大不了的。”如果你不能百分之百地相信你的测试是准确的，为什么要费心去做这个测试呢？

所以，您想通过UI测试工具测试的是UI的最顶层，只是为了确保您的视图模型正确地绑定到您的视图。这归结为，真的，只是几个测试。为此，您可以很容易地使用编码UI。棘手的部分是确保您的所有控件都是自动化友好的，这涉及到给控件指定正确的名称，并确保将正确的自动化属性附加到控件上。

在VS Premium和以上版本中都有编码的UI，您不需要使用来管理和运行测试，尽管这当然更容易。

不过，听起来你真正想要的是MTM。您希望手动测试人员能够通过与应用程序交互来记录测试，然后稍后再播放它们。这正是MTM设计的目的，也是它的优势所在。

Answer 2

遗憾的是，对于您所处的阶段来说，这个答案听起来太晚了，但是我对的基本知识感到满意：

基本上，您首先要设置一些IOC容器和依赖项注入方案以及PRISM。然后，您的服务可以提供设计时、运行时和测试时实现以及模拟等。有一些视频和教程，但是像大多数wpf一样，作为一个新手，很难对过时的东西和相关的最佳实践进行排序。

MVVM至少有一个重点，使混合在设计时工作，并闻起来像是某种最佳实践。

现在，这部分不幸地没有回答你的问题:这个想法是能够布局在混合，这样你就可以看到事情将是什么样子，而不是无休止的调整-编译运行周期。测试纯粹在底层的ViewModel和模型上进行。然后，您可以看到应用程序工作，因为UI绑定不太可能出错/手动运行和验证相对简单。最后一部分适用于我的项目，但可能对你的项目很不满意。