Question

我们（我的同事）有一个基于GUI的~~凌乱的12 y.o。~~成熟的应用程序，目前的计划是添加新的对话框＆amp; WPF中的其他GUI，以及替换WPF中的一些旧对话框。同时我们希望能够以可维护的方式测试Monster-GUI自动化。一些挑战：

申请量很大。
不断获得新功能。
它正在被改变（错误修复，补丁）。
它有一个后端，中间是一层。如果你将它击败致死，它的状态可能会失控。

我们想要的是：

一些可以自动测试WPF的工具。
自动发现对话框的输入和输出。如果添加不执行任何操作的标签，旧测试仍应有效。但是，如果删除必要的文本字段，它应该会失败。如果测试套件易于维护，如果它运行并且在大多数时间没有中断，那将是非常好的。
每个新对话框都应该考虑到可测试性。

此时我并不确切知道自己想要什么，所以我将此标记为社区维基。如果必须测试一个巨大的基于GUI的应用程序响铃（即使不在WPF中），那么请在这里分享你的好，坏和丑陋的经历。

Answer 1

好的，你的应用听起来很大！我可以分享我最近设计的应用程序的经验;它是一个GUI，与服务器交谈Web服务，后者又联系了多个数据库和其他Web服务。客户群大约有15,000名用户......无论哪种方式 - 无论你如何接近它，这都是很多工作;好处是它可以帮助你在每次释放时都不会咀嚼你的指甲！

<强> MVVM

一般情况下，我还会推荐MVVM模式，并在没有GUI的情况下尽可能多地进行测试。 GUI测试很简单！我喜欢Josh Smith关于MSDN的文章：“WPF Apps With The Model-View-ViewModel Design Pattern”（http://msdn.microsoft.com/en-us/magazine/dd419663.aspx）

测试脚本

这个应用程序的诀窍是我们有很多要测试，它的内容不断移动，而且（奇怪的是）没有足够的人来完成每次迭代的测试工作。

我的解决方案是提出一个利用现有库的自定义测试工具。我们有一个简单的脚本引擎，可以读取文件并执行命令。实际上，我们开发了DSL（http://en.wikipedia.org/wiki/Domain-specific_language）来测试我们的特定应用程序。 DSL包括一些简单的命令，用于指示它正在测试的“窗口”，任何特定的“设置”信号，然后是一系列命令，然后是断言。它看起来像这样：

Test NewXyzItem
Setup Clear_items

Press Some_button
Enter_text_into Name Bobby Joe
(...)
Press Save

Assert_db_has_itemX SomeKey

每行的格式为

"command" "argument" [data]

脚本进入目录组，“测试运行器”加载它们，解析它们并执行它们。随时创建日志和报告非常有用，我加入了屏幕截图等方面的功能。 如果您有兴趣实施此类内容，并希望有一只手让我知道。

这里最方便的是我们可以对测试策略进行全面改变。

编写脚本变得非常简单，这很重要，因为最终会有许多脚本。控件是按名称发现的，因此您遵循约定（例如，“Name”可能是代码中的“NameTextBox”，或者“Save”可能是“SaveButton”）。

您实际上可以利用NUnit等成为您的测试运行者。

注意 - 只需以交互方式运行测试，进行GUI测试以使用CI很困难且有问题......

数据与测试

这里的一个主要问题是数据管理是测试问题的一个重要部分，不容忽视。我们的“新部署”也很长，但有些部分是外部的，我们无法控制数据的新鲜度。我们处理清理的方式是通过脚本提供钩子，允许我们在测试之前轻松删除对象。不是最佳的，但很少成为问题。

<强>库

您可能会在“White”中找到最有用的库（http://white.codeplex.com/）它可以测试一般的Windows应用程序 - 即WPF和WinForms。基本上你最终会编写这样的代码：

Button button = window.Get<Button>("SaveButton");
button.Click();

如果您的应用程序进行异步调用，您需要为测试运行器提供一个策略，以了解异步调用何时完成，可能是状态栏或其他内容。这取决于你如何挂钩......

再次，很多工作，但它是值得的。

PK： - ）

Answer 2

在我看来，WPF的主要优势之一实际上是不需要UI特定测试的能力。使用M-V-VM方法可以让您从UI / messy-GUI区域中取出逻辑。拥有一个可单元测试的ViewModel（特别是如果你正在编写新的对话框！），你可以编写模拟GUI点击的单元测试。

我真的要重新考虑你想要实现的目标，转移到WPF以及你希望通过某种类型的WPF GUI自动化测试来实现的目标。一旦确定，请查看transitioning from WinForms to WPF是否仍符合您的需求。

Answer 3

正如Jimmy Lyke所说，你的大多数测试应该集中在ViewModel上。这包括为ViewModel编写单元测试 - 基本上是发送命令，设置和获取属性。

完成后，95％的测试都不在考虑范围内。如果你想更进一步，除了手动“演练”测试之外测试视图你还会做什么，有一些简单的“健全性检查”你可以很容易地自动化，以确保你不会意外删除一个重要的TextBox或渲染视觉指示器不可见。

以下每种技术都可以使用一些简单的自动化代码进行自动化，这些代码使用“霰弹枪”方法，盲目运行可视化树，并且不假设实际的UI结构。

要验证所有ViewModel数据是否已绑定，请找到所有Visuals和Freezables（使用可视树）并检查每个绑定属性的BindingExpression的绑定路径。
要验证是否以某种方式显示所有ViewModel数据，请使用脚本更改ViewModel数据，并在每次更改后使用RenderTargetBitmap捕获UI并在数据更改之前将其与之进行比较，以确保UI已更改。
要验证属性值是否正确更新，请查找所有Visuals和Freezables，并扫描并记录它们上的所有绑定属性，然后对ViewModel进行更改，重新扫描和搜索以获得对任何属性的预期更改给定的类型。（要仔细检查，您可以使用特定Visual受影响的位图比较技术。）
要验证是否可以访问所有命令，请设置已知的ViewModel状态，然后触发绑定到可见按钮的每个命令，以查看是否有任何命令触发ICommand或以其他方式更新ViewModel状态。
< / LI>
要验证用户是否可以实际编辑ViewModel属性，请更改每个可见TextBox，ComboBox，ListBox的内容或选择，以查看是否有任何属性影响该属性。
要有机会检查影响UI的任何更改，请在一组不同的窗口大小中保留包含各种ViewModel状态中每个视图的位图快照的数据库。构建新版本的应用程序时，运行相同的快照系统并与之前的位图进行比较。如果有任何改变，请为QA人员生成一个手动任务，以便在视觉上比较旧位图和新位图，看看是否有任何重要的位置发生了变化。

视图上可以进行其他测试自动化，但上面的内容将为您提供一个开始。

我必须再次指出，最好专注于彻底测试ViewModel。视图中的错误非常罕见，通常可以快速检测到，并且通常很容易修复。但是，一旦ViewModel测试彻底，就可以对视图测试进行一些自动化。

Answer 4

你有一个非常大的应用程序。我猜它有很多逻辑包含在表示层中，你永远不会有时间重构野兽来将视图与逻辑的其余部分分开。

你在这里没有太多选择，但是：

随着时间的推移重构代码。这可能是很少的方法提取，因此您可以进行单元测试或转换到合适的模型。
使用Windows GUI testing tools种中的一种或多种。请注意，如果您计划进行大量布局和/或控制更改，请尽可能延迟。本文中的工具将使用动作的绝对定位，控制链接（有时通过内部ID）或两者的混合。由于他们通常不必使用代码进行培训（针对QC测试人员，而不是程序员），因此测试将在更改后停止运行。
投资人类测试人员。虽然不是一个好的选择，但它确实提高了结束质量，并开始让管理层更多地考虑重构应用程序的成本。

Answer 5

为了测试WPF应用程序，我们取得了一些成功：

PowerShell
TestPlant

并且可能是新的VSTS 2010 features，但我们还没有尝试过它们

测试Gui-heavy WPF应用程序

5 个答案: