GUI 自动化测试 - 窗口句柄问题
我们公司目前正在为紧凑框架应用程序编写一个GUI自动化测试工具。 我们最初搜索了很多工具，但没有一个适合我们。
通过使用该工具，您可以记录测试用例并将它们分组到测试套件中。 对于每个测试套件都会生成一个应用程序，该应用程序启动被测应用程序并模拟用户输入。
一般来说，该工具工作正常，但由于我们使用窗口句柄来模拟用户输入，因此您无法执行很多操作。 例如，我们不可能获得控件的名称（我们只能获得标题）。
使用窗口句柄的另一个问题是检查更改。 目前，我们模拟对控件的单击，并根据结果我们知道应用程序是否已进入下一步。
是否有其他（更简单的）方法来执行此类操作（例如消息队列或其他任何方法）？
Our company is currently writing a GUI automation testing tool for compact framework applications. We have initially searched many tools but none of them was right for us.
By using the tool you can record test-cases and group them together to test-suites. For every test-suite there is generated an application, which launches the application-under-test and simulates user-input.
In general the tool works fine, but as we are using window handles for simulation user input, you can't do very many things. For example it is impossible for us to get the name of a control (we just get the caption).
Another problem using window handles is checking for a change. At the moment we simulate a click on a control and depending on the result we know if the application has gone to the next step.
Is there any other (simpler) way for doing such things (for example the message queue or anything else)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
有趣的问题！ 我已经有一段时间没有做过任何低级（比如 Win32）Windows 编程了，但这就是我会做的。
使用命名管道并让您的应用程序监听它。 使用此命名管道作为通信介质，实现一个真正简单的协议，您可以通过该协议在给定 HWND 的情况下查询应用程序的控件名称，或者您认为有用的其他内容。 确保协议足够丰富，以便应用程序和测试框架之间交换足够的信息。 确保测试框架不会从应用程序中产生太多“特殊行为”，因为这样您就不会真正测试功能，而是测试您的测试框架。
可能有更优雅、更酷的方法来实现这一点，但这是我从头到尾记住的，仅使用简单的 Win32 API 调用。
我们在工作中为产品实现的另一种方法是在事件脚本中记录用户事件，例如鼠标单击和按键事件。 这应该足够丰富，以便您可以让应用程序回放它，人为地将这些事件注入消息队列，并让它的行为与您第一次录制脚本时的行为相同。 当您播放脚本时，您基本上是在模拟用户。
除此之外，您还可以记录任何重要状态（用户的文档、首选项、GUI 控件层次结构等），在录制脚本时记录一次，在回放脚本时记录一次。 这为您提供了两组可以比较的数据，以确保一切都保持不变。 该解决方案为您提供不易修改的测试（如果 GUI 发生更改，您必须重新记录），但提供了很棒的回归测试。
（编辑：这在 Beta 测试期间也是一个很棒的 QA 工具，例如：只需让您的用户记录他们的操作，如果发生崩溃，您就有很好的机会通过回放脚本轻松重现问题）
祝您好运！
卡尔
Interesting problem! I've not done any low-level (think Win32) Windows programming in a while, but here's what I would do.
Use a named pipe and have your application listen to it. Using this named pipe as a communication medium, implement a real simple protocol whereby you can query the application for the name of a control given its HWND, or other things you find useful. Make sure the protocol is rich enough so that there is sufficient information exchanged between your application and the test framework. Make sure that the test framework does not yield too much "special behavior" from the app, because then you wouldn't really be testing the features, but rather your test framework.
There's probably way more elegant and cooler ways to implement this, but this is what I remember from the top of my head, using only simple Win32 API calls.
Another approach, which we have implemented for our product at work, is to record user events, such as mouse clicks and key events in an event script. This should be rich enough so that you can have the application play it back, artificially injecting those events into the message queue, and have it behave the same way it did when you first recorded the script. You basically simulate the user when you play back the script.
In addition to that, you can record any important state (user's document, preferences, GUI controls hierarchy, etc.), once when you record the script, and once when you play it back. This gives you two sets of data you can compare, to make sure for instance that everything stays the same. This solution gives you tests that not easy to modify (you have to re-record if your GUI changes), but that provide awesome regression testing.
(EDIT: This is also a terrific QA tool during beta testing, for instance: just have your users record their actions, and if there's a crash, you have a good chance of easily reproducing the problem by just playing back the script)
Good luck!
Carl
如果自动化 GUI 测试工具了解编写应用程序的框架，则它可以使用该信息来制作更好或更高级的脚本。 例如 TestComplete 了解 Borland 的 VCL 和 WinForms。 如果您测试使用 Windows Presentation Foundation 构建的应用程序，则可以对此内置。
If the Automated GUI testing tool has knowledge about the framework the application is written in it could use that information to make better or more advanced scripts. TestComplete for example knows about Borland's VCL and WinForms. If you test applications build using Windows Presentation Foundation has advanced support for this build in.
使用NUnitForms。 我在单线程和多线程应用程序中使用它们取得了巨大成功，您不必担心句柄和类似的东西
这里有一些关于 NUnitForms 的文章值得阅读
NUnitForms 和 DragDrop 注册失败 - MTA 与 STA 的问题
使用 NUnitForms 编译的应用程序 exe GUI 测试
use NUnitForms. I've used them with great success for single and multi threading apps and you don't have to worry about handles and stuff like that
Here are some posts about NUnitForms worth reading
NUnitForms and failed DragDrop registration - problem of MTA vs STA
Compiled application exe GUI testing with NUnitForms
我终于找到了在测试应用程序和被测应用程序之间进行通信的解决方案： 托管间谍。 它基本上是一个构建在 ManagedSpyLib 之上的 .NET 应用程序。
ManagedSpyLib 允许以编程方式访问另一个进程的 Windows 窗体控件。 为此，它使用 Window Hooks 和内存映射文件。
感谢所有帮助我找到此解决方案的人！
I finally found a solution to communicate between the testing-application and the application-under-test: Managed Spy. It's basically a .NET application build on top of ManagedSpyLib.
ManagedSpyLib allows programmatic access to the Windows Forms controls of another process. For this it uses Window Hooks and memory-mapping files.
Thanks for all who helped me to get to this solution!
Managed Spy 不提供紧凑框架应用程序的解决方案。
Jamo Solutions 公司 (www.jamosolutions.com) 满足移动设备上的自动化测试要求，包括 .net 紧凑框架应用程序。
Managed Spy does not provide a solution for compact framework applications.
The company Jamo Solutions (www.jamosolutions.com) meets the requirements for automation testing on mobile devices, including .net compact framework applications.