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