测试Gui-heavy WPF应用程序

Question

测试Gui-heavy WPF应用程序

Ham*_*jan 30 .net testing wpf agile user-interface

我们(我的同事)有一个基于GUI 的~~混乱的12岁~~成熟应用程序,目前的计划是在WPF中添加新的对话框和其他GUI,以及替换WPF中的一些旧对话框.同时我们希望能够以可维护的方式测试Monster-GUI自动化.一些挑战:

应用程序非常庞大.
它不断获得新功能.
它正在改变(错误修复,补丁).
它有一个后端,中间有一层.如果你把它击败致死,它的状态可能会失控.

我们想要的是:

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

在这一点上,我不知道我想要什么,所以我将其标记为社区维基.如果必须测试一个巨大的基于GUI的应用程序响铃(即使不在WPF中),那么请在这里分享你的好,坏和丑陋的经历.

Answer 1

Pau*_*ler 21

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

MVVM

一般来说,我也会推荐MVVM模式,并在没有GUI的情况下尽可能多地进行测试.GUI测试很简单!我喜欢Josh Smith关于MSDN的文章:" 使用Model-View-ViewModel设计模式的WPF应用程序 "(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]

Run Code Online (Sandbox Code Playgroud)

脚本进入目录组,"测试运行器"加载它们,解析它们并执行它们.随时创建日志和报告非常有用,我加入了屏幕截图等方面的功能.如果你有兴趣实现这样的东西,并希望一只手告诉我.

这方面的便利之处在于我们可以对测试策略进行全面更改.

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

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

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

数据和测试

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

图书馆

您可能在" 白色 "中找到最有用的库(http://white.codeplex.com/)它可以测试一般的Windows应用程序 - 即WPF和WinForms.基本上你最终编码这样的事情:

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

Run Code Online (Sandbox Code Playgroud)

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

同样,很多工作,但它是值得的.

PK :-)

Answer 2

Jim*_*yke 15

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

我真的要重新考虑你想要实现的目标,转移到WPF以及你希望通过某种类型的WPF GUI自动化测试来实现的目标.一旦建立起来,如果它仍然符合您的需求,请考虑从WinForms转换到WPF.

我会质疑你的主要前提,即使在MV-VM中仍然需要UI特定的测试.至少,您应该验证所有文本是否可读,验证所有菜单选项,按钮等是否存在和完成.当然,它不需要通过GUI进行业务逻辑测试,但GUI仍然需要测试. (6认同)

Answer 3

Ray*_*rns 5

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

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

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

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

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

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

归档时间：	15 年，6 月前
查看次数：	8734 次
最近记录：	15 年，5 月前