有人用Sikuli测试他们的基于GUI的应用程序吗?

引用 Unit Testing for GUI (在项目中) Documentation ):

Sikuli旨在通过与JUnit集成来支持GUI的单元测试。可以通过单击View/Unit Test(视图/单元测试)或Mac上的快捷键Cmd-U(或Windows/Linux上的ctrl-U)打开单元测试面板。

因此,虽然我的理解是Sikuli最初是针对GUI自动化的,但它绝对可以用于GUI测试(如果您认为GUI测试=GUI自动化+验证框架,则这与此密切相关)。看一看 Unit testing for GUI (JEdit) 完整示例(请参见 assertXXX 在图像上)。

实际上,我在Sikuli中看到了很大的测试潜力,因为它似乎使编写测试变得非常容易,即使没有编写一行真正的应用程序(例如,使用一些初始模型)。Sikuli可以成为各种口味测试(BDD、验收测试等)的好伴侣。

这真是一个令人惊叹的软件,非常令人印象深刻。

我广泛使用Sikuli实现UI测试自动化。我在2011年1月发现了锡库利党,现在“迟到”了。我真的很高兴我很晚才发现它,因为虽然它在早些时候就已经有了希望,但直到Sikuli X1.0-RC1(发生在12月)发布,我才认为它已经为黄金时段做好了准备。

以前,我使用TestQuest和Eggplant实现UI测试自动化。在我看来,西库利把他们两个都打了下来。我真的相信它有潜力显著地改变人们如何更好地执行UI测试自动化,并将它传播给我周围的人们。

正确使用Sikuli意味着 不 遵循“录制和播放”模式。相反,您必须使用Sikuli开发测试自动化——正如您需要使用所有工具一样——作为软件开发任务。

我们目前正在将为茄子构建的用户界面自动化DSL(领域特定语言)移植到Sikuli。我们将在DSL中利用的一个关键特性是Sikuli的文本识别功能。这将允许我们在产品的不同本地化版本中运行相同的脚本。

因为Sikuli建立在 OpenCV (for image recognition) 和 tesseract-ocr (for text recognition) 它拥有难以置信的力量和灵活性。

另外,请参阅论文: http://groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf

使用Flex Web应用程序记录了工作流。花了一段时间才想出一个可靠的策略来创建屏幕截图,但一旦我做到了,即使在我改变了我的桌面颜色方案之后,脚本仍然可以继续工作!不过,当您需要单击类似控件(如复选框、输入字段)集合中的特定控件时,语法会变得有点笨拙。看来唯一的方法是 find() 与 right(); left(); inside() . 看起来屏幕截图越小,它们被检测到的越可靠。在我看来,一个好的做法是只在屏幕截图中包含重要的对象,并使它们尽可能原子化,但又不损害它们的独特性。

@约旦, “正确使用Sikuli”绝对是指您没有遵循“录制和播放”模式。相反,您必须使用Sikuli开发测试自动化——正如您需要使用所有工具一样——作为软件开发任务。

我创建了一个端到端测试自动化解决方案,用于测试由世界最大的PC制造商生产的视频会议应用程序。他们不明白这是一个完整的开发项目,而不是任何猴子都能执行的点击操作。试图用动态类型语言解释编码的挑战是不可能的。

根据我的经验,最大的挑战是形象管理。我在测试自动化的第一次迭代中使用了文件系统和configparser。使用configparser是有效的,但是很难实现。将来我计划使用blobs。Sikuli还不支持直接从数据库中提取图像,尽管我有相关工作要做。

使用IDE非常关键,因为Sikuli IDE没有和开发工具。我配置的2个IDE,NetBeans和Eclipse/Pydev有自己的一组问题。对于编码是很好的,但是错误、空白的注入和代码丢失都会使这两个问题的解决方案都不理想。我在NetBeans中编码和测试,在Sikulide中执行,并将所有内容保存在记事本中作为备份。

在遇到任何困难的时候,我都是西库利的忠实支持者。Sikuli有可能改变测试自动化,使其能够在不必成为OO编码人员的情况下进入整个QA社区。

为了减少Sikuli以开发人员为中心的测试自动化,还可以查看robotframework.org。有一个关于如何为机器人框架制作(自定义)Sikuli测试库的教程

http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html

我还创建了一个简单的通用版本

http://code.google.com/p/simplesikuli

如果Sikuli在窗口处理、GUI控件、鼠标和键盘交互方面有任何限制,那么您总是可以用另一个伟大的免费测试工具来补充它:autoit。autoit本身也有局限性,当您将它与sikuli结合时,它们可以弥补每个工具的缺点,从而取代商业级的GUI测试工具。

以下是我对Sikuli在测试自动化方面的惊人表现: http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/

我有一个可靠的跨平台Miro测试套件。

我实际上正在编写一个使用Sikuli进行GUI测试/错误处理的框架。太棒了。

我已经使用了Sikuli进行了GUI测试,并且能够将它与Hudson集成。

我刚刚使用skikuli+robotframework发布了自己的GUI应用程序测试框架。

SikuliFramework在Sikuli的基础上提供了一个面向对象的抽象,以帮助交互GUI元素,例如按钮集、复选框、单选按钮、窗口以及用于GUI自动化和测试的对话层次结构。它还与robotframework紧密集成。

https://github.com/smysnk/sikuli-framework

Sikuli基于静态图像匹配。因此,它只适用于GUI足够稳定的情况。对于动态图形用户界面(如动画或图形用户界面),它包含了某种随机性,因此不太适用。

而Sikuli只覆盖被测对象的视觉部分。它不知道内部状态是否确实如预期的那样。

我是Sikuli的粉丝,我相信它是对其他测试的补充,可以节省很多手动测试工作。

然而,要想把它弄好需要时间。 我在两年的时间里给了它第二次机会,第二次我能够取得好的成绩,因为我对环境更加熟悉。

它附带了一个直观的IDE和Python,可以很容易地扩展一些东西。 更改点击位置、设置公差和记录内容非常容易。一旦掌握了如何记录和检查文档,就可以很容易地使用最少的图像并提高准确性。它可以很容易地捕获GUI中的更改和结果。等待某个事件也很容易。错误检查很容易。

最大的问题是,如果您只是在另一台机器上运行记录的测试,而不是在另一台机器上运行记录的测试,那么记录的测试往往会失败。这可能与基于图像比较的模式匹配有关。通过给出公差值,可以提高匹配模式的概率。但不断改变容忍度有时会让人恼火。我的建议是在不同的平台上使用一组不同的映像,最好在一台机器或虚拟机上运行它。

一旦有了一组通用的工作流,就可以创建一个包含这些通用功能的库,例如(打开、关闭、保存项目、更改设置),并跨不同的脚本使用这些功能。随着图书馆的全面建设,这变得非常容易。它还意味着您只需在单个位置更改脚本,它将反映在所有脚本中。

我还创建了一个简单的框架( image attached )来运行测试并使用C.NET记录结果。人们可以利用任何东西来创建一个简单的测试运行应用程序。它只需要在命令行上运行测试并检查结果。