这个问题与单元测试无关。它适用于桌面产品。
这是关于测试 gui 并测试在正确的时间在正确的文本框中输入正确的内容。
我曾经工作过的一家公司使用过 WinRunner（不同的部门，所以我不太了解），但现在它已被惠普关闭，但无论你是留在惠普还是去其他地方，他们似乎都不在乎。在您注册之前，您无法阅读有关该产品的信息，这很烦人。
该工具必须与 MFC（不可协商）一起使用，理想的工具也将...
其他 SO 用户为自动化 GUI 测试做了什么？
我们为 Rational Robot (RRAFS)使用SAFS 框架。WinRunner (WRAFS) 也有 SAFS 实现，看起来他们有一个新的“基于图像的测试”实现，我不熟悉。
这个框架很好地将 UI 实现与测试脚本分开。我已经测试了由两个不同团队开发的 Web 应用程序的四个版本（一个团队使用经典 ASP，一个使用 ASP.NET），我只需要更改我的 UI 对象的应用程序映射，测试本身不需要改变。
也就是说，框架的语言很麻烦，需要习惯。就语言结构而言，它不是很健壮，但是通过一些努力，您可以做任何您需要做的事情。这有点像 Windows Batch 语言中的“编程”，但用于测试；）
为了满足您的上述个人要求：
1)该工具必须与 MFC 一起使用（不可协商）。 SAFS 框架使用第 3 方“记录回放”工具来驱动测试，例如 Rational Robot 或 Mercury WinRunner。如果该工具可以与 MFC 应用程序交互，那么框架可以。我不知道“基于图像的测试”实现如何驱动测试，但我猜它也可以与 MFC 一起使用。
2）自动化。 SAFS 框架与STAF框架集成，这将允许您自动执行测试。我有一个概念验证测试，它使用 STAF 从映像池中启动 VM 映像，安装被测应用程序，运行 RRAFS 测试，并将结果放在 Web 服务器上供其他人使用。
3)可编写脚本。 是的，但如前所述，它不是最强大的编程语言。我写了一个 Excel 加载项，我们的测试人员用它来编写他们的测试，这可以稍微简化一些事情。
4)自动使用不同的屏幕分辨率。 是的，因为它在 UI 对象而不是屏幕上“隐藏”。除了“基于图像的测试”选项之外......
5）能够“窥探”单个静态文本框等。 是的，您可以等待 UI 对象出现、消失、具有值、更改值等。
6)足够直观，非程序员也可以创建脚本。 经过一些训练。我们取得了有限的成功。一些 QA 人员可以编写测试，但有些人很挣扎。
7)有报告工具，包括个人用户的电子邮件。 是的，使用 STAF 框架，您可以将结果发布到 Web 服务器、发送电子邮件等。
这里有很多好的答案，但我想解决这个目标声明，特别是：
我能理解你为什么想要这个，但它比你想象的要困难得多。虽然您可以找到许多声称可以轻松编写脚本的工具，但在实践中，您的自动化团队中至少需要一些懂编程的人。编写相当健壮的脚本将涉及循环、if/then/else 和子例程调用中的一种或多种。不是非程序员会觉得直观的东西。
特别要警惕您可以使用工具“记录”一个人，然后回放以进行测试的想法。这种“自动化”通常非常脆弱，以至于您最终会为软件中的几乎每一次更改修改或重新录制脚本。
来自强大的 Mercury/HP 背景，我强烈建议您使用 QuickTest Professional 进行 GUI 测试。它有很多与 WinRunner 相同的功能，但没有很多代码。可以通过 QTP 界面使用最少的自定义 VB 代码（如果有的话）完成简单的 GUI 检查。可以使用 QTP 中的数据表通过简单的比较来检查框旁边的文本。
如果您习惯了 WinRunner，并且知道 VBScript（不太了解 TSL），那么我肯定会看 QTP。
至于您的其他要求，QTP 还具有 Spy 功能，如 WinRunner，它将列出您可以对对象执行的所有属性和操作。至于使用的简单性，在我以前的工作中，我们会让业务或系统测试人员创建简单的烟雾脚本，然后我会使用它们并对它们进行编码以进行更深入的测试（多个数据值、错误检查等）。至于报告，QTP 将对您输入的标签以及您可以输入的自定义数据进行简单的通过/失败/警告报告。因此，您可以使用 case 语句根据结果填充输出值。它不会直接发送电子邮件，但如果您与 TestDirector/QualityCenter 集成，您可以通过那里进行设置，以及自动启动脚本，
拍
请参阅用户界面测试。
桌面或 Web 应用程序在这里具有相同的测试模式（我在这两个方面都工作过）。
在 UI 中放置尽可能少的逻辑并测试其下方的所有内容。所以你说，但是如果我想测试单击按钮时会发生这样那样的事情怎么办？单击该按钮时调用的方法应该调用另一个实际进行思考的类。
您可能会说，但我正在使用一些只能存在于我的 UI 中的静态类/方法，用适配器包装它们并利用该接口以使您的代码可测试。
您想要自动化的 GUI 测试部分应该在 UI 下方自动化。GUI 的某些部分无法自动化。检查以确保事情“看起来正确”，或测试您是否可以看到某些元素等。所有这些都是您的人类应该做的。确保事件正确触发，并且从您的业务对象中正确返回值，这就是所有单元测试。
从您的问题中我可以看出，您几乎已经决定需要一个自动化 GUI 测试器，但这不是这项工作的正确工具。如果您决定使用它，您就是在尝试找到做错事的最佳方法。
如果您认为这与单元测试无关，因为您正在测试 GUI 交互，那么我可以保证您的单元测试距离您的 UI 不够近。如果你是，你会觉得你要测试的大部分内容都是多余的。
如果您不同意我的观点，请发表一些理由，我们将对此进行讨论。
如果您正在测试网络产品，还有更多（开源）替代方案。对于桌面产品，下面是一些流行的通用桌面 GUI 自动化工具（排名不分先后）。我亲自与所有这些人一起工作过，他们都完成了工作。如果您选择使用供应商工具，请为您正在考虑的工具获取 POC，并根据总体上最适合公司的工具做出决定。一种工具可能更适合特定应用程序，但可能还有其他项目/应用程序需要考虑。