我有一个会计&薪资客户端/服务器应用程序，其中有几个输入表单与复杂的数据验证规则。我正在寻找一种执行用户界面单元测试的有效方法。单元测试用户界面。什么是有效的方法？
对于复杂的验证规则，我的意思是：
我发现最有前途的模式是由M.福勒（http://martinfowler.com/eaaDev/ModelViewPresenter.html）建议。
您是否有任何关于用户界面单元测试的经验？作为我使用的技术堆栈：.NET 3.5 & Windows窗体小部件库。
我不会称之为“单元测试”，但我在运行WinForms UI自动化测试以及使用WatiN的Web UI中取得了一定程度的成功。
假设您可以获取要测试的应用程序窗口的句柄，您应该能够编写大量C＃代码来测试用户界面的功能。
很多人谴责尝试对用户界面运行自动化测试的想法，因为存在太多以至于无法以这种方式进行测试。例如，没有自动化测试会注意到字体很难看，或者某些文字很混乱，或者按钮稍微偏离中心。毫无疑问，对于这些类型的东西，你绝对需要一个聪明的人在看屏幕。
但是，除了那种类型的测试之外，肯定会有大量重复性测试可以自动化并定期执行。大多数大型应用程序都有一整套回归测试脚本，必须在新版本发布时手动执行。这些测试通常是你可以训练猴子做的事情，只是点击这个链接的指令列表，输入一些文本，点击这个按钮，检查产生的信息等等。这些东西对于质量保证测试人员来说是浪费时间，而且使他们感到痛苦，所以如果他们能够自动化，很好。这些类型的测试应该能够由您的构建服务器每天自动运行，并且可以制作得比任何手动测试都要透彻得多。
再一次，它不会发现奇怪的未知事物，但它会给你一定程度的自信，认为你的小改变并没有打破你在应用程序另一端从未听说过的其他屏幕。当然，这会导致开发人员进行更多的工作，因为应用程序的小改动可能会因为愚蠢的原因而中断测试，就像任何自动化测试一样，但它会为您节省大量时间进行测试和调试。这对你来说是否值得你去决定，但我认为这是一个不应该像你平常看到的那样快速被解雇的考虑。
根据定义，单元测试对于测试接口并不是那么好。单元测试应测试单个实体的后端功能。对于功能测试，请为此获取框架。考虑Mercury（现为HP）Quality Center或Performance Center等产品。如果你有预算，试试Selenium。
功能测试是单元测试的一个步骤，不应与彼此混淆。
用户界面测试很难，通常最好在比单元测试更高的测试水平上完成。
Martin Fowler提出的使用MVC/MVP分离的测试控制器和逻辑是一个很好的开始，但是您经常需要使用WinRunner或QTP等自动化工具对其进行扩展，以便以自动方式全面测试UI。
是否还存在任何开源工具呢？ – pierocampanelli 2010-05-17 19:35:39
对于复杂的验证规则，我的意思是：
* "Disable button X if I Insert a value in textfield Y"
这些规则同时测试模型和视图，这是什么让他们艰难。相反，验证当您在文本字段Y中插入值时，模型会获取该值;具有空Y的模型具有X_ENABLED == false，并且非空Y具有X_ENABLED == true;并且，给定一个X_ENABLED == true的模型，View的按钮被启用。这些测试中只有两个涉及UI，它们应该非常简单，几乎不会失败。将复杂的逻辑放入容易测试的模型中。
正如其他人所说的那样，对UI进行Untit测试是一种痛苦。我只想补充一点，Team Foundation 2010的新功能Test & Lab Manager是对UI进行手动测试和自动执行后续测试的好方法。在运行测试时足够聪明，至少在WinForms，WPF和网站上可以识别GUI结构。
同意您的考虑。我认为有一些测试总比没有好。所以我想找到一种快速编写批处理的方法，当有人执行小的更改时，这可以让我提高可信度。 – pierocampanelli 2010-05-17 16:46:37