我一直在编写一些 GUI 测试框架，它们可以通过记录鼠标和键盘事件并重放它们来记录和重放一些 GUI 用户场景。
鼠标事件当前记录为(press or release, (x, y)). 但是，这是非常脆弱的，因为如果仅目标小部件移动了几个像素，但结构和其他一切都保持不变，则测试用例将停止工作。
有什么更好的方法来做到这一点？我能想到的一些事情
在小部件及其父小部件树中记录目标小部件的“树路径”。即(press or release, (top level, first child, second child, destination))，“子列表”是 Qt 的QObject子列表返回的内容。我认为这有一个缺点，即现在的测试依赖于内部代码结构。
给每个可测试的小部件一个唯一的名称，并在重放时使用该名称搜索小部件。这似乎是一个不可忽视的开销。
任何其他想法，以及普遍接受的“最佳”方法是什么？
测试用例在多大程度上与测试的特定设置以及代码的更改绑定在多大程度上取决于您自己的决定。这本质上是您的规格有多严格的问题。
一方面，有“机械”或“哑”测试。可能是您正在使用严格控制的初始条件进行测试：初始窗口位置的相同设置是在测试之前预先设置的，强制执行相同的平台样式，相同的字体可用等。那么这是一个合理的期望如果您在小部件中切换两个按钮，或更改初始窗口/对话框大小，则测试应该会失败。
另一方面，还有“人类”测试。如果从纸上阅读脚本的人在测试中成功，您可能希望测试成功。在这种情况下，字体、视觉元素的位置等微小的变化并不重要：人类测试人员很容易适应这些变化。
这两个极端甚至可能同时适用，但适用于应用程序的不同部分，或产品生命周期的不同阶段。
如果您正在为航空飞行管理系统设计 UI，那么有些方面可能需要完全“机械”的、非适应性测试，因为规范更改未涵盖的 UI 更改实际上是一个错误.
如果您正在设计一个消费者应用程序，您可能希望在错误修复或次要版本中保持规范，但可以在主要版本中放宽这一点。
在实现更灵活、更人性化的测试时，需要来自被测代码或测试用例生成过程或两者的合作。
测试用例生成过程（测试脚本、人类等）对特定事件的含义具有重要的了解。例如，对通用按钮的单击实际上注定要在按钮的中间 - 那么按钮的活动区域是否具有不响应单击的圆角并不重要。单击也可能指向标有“确定”的按钮，无论该按钮是位于特定平台上按钮栏的右侧还是左侧边缘。
测试代码还具有关于特定事件分类的重要知识。例如，如果单击是在绘画程序的画布上单击，则单击的坐标本身可能很重要。否则，它可能是小部件中重要的特定视觉元素，而不是其精确坐标。在后一种情况下，由于平台样式或代码更新而对小部件外观的更改可能会使相对坐标过时。