有没有人使用SIKULI来testing他们基于GUI的应用程序？
SIKULI似乎有巨大的潜力。 有没有人试图使用这个作为testing工具？ 或者它会更适合用户的自动操作？
引用GUI的unit testing （在项目文档中 ）：
Sikuli被devise为通过与junit集成来支持GUI的unit testing。 unit testing面板可以通过点击View / Unit Test或Mac上的快捷方式Cmd-U（或Windows / Linux上的Ctrl-U）来打开。
所以，尽pipe我的理解是，SIKULI最初是针对GUI自动化的，但它肯定可以用于GUItesting（如果考虑到GUItesting= GUI自动化+validation框架，这与testing密切相关）。 查看完整示例的GUI（JEdit）的unit testing （并查看图像上的assertXXX ）。
事实上，我发现SIKULI在testing方面有很大的潜力，因为它似乎使得编写testing变得非常简单，即使没有编写真正的应用程序（仅仅使用一些最初的模型）。 SIKULI可以成为各种风味testing（BDD，验收testing等）的绝佳伴侣。
这真是一个惊人的软件，非常令人印象深刻。
我正在广泛地使用Sikuli进行UItesting自动化。 我对西库利派对的“迟到”已经在2011年1月发现了。我真的很高兴我发现它迟到了，因为尽pipe早些时候有希望，但是直到西库利x1.0-rc1（发生在十二月）被释放，准备黄金时间。
以前，我使用TestQuest和EggPlant进行UItesting自动化。 在我看来，Sikuli击败了他们双手。 我真的相信它有可能大大地改变人们如何更好地进行UItesting自动化，并将其传播给我周围的人。
正确使用Sikuli意味着你没有遵循“logging和回放”模型。 相反，您必须与Sikuli一起开发testing自动化 – 因为您需要使用所有工具 – 作为软件开发任务。
我们目前正在将我们为EggPlant构build的UI自动化DSL（域特定语言）移植到Sikuli。 我们将在我们的DSL中利用的一个关键特性是Sikuli的文本识别function。 这将允许我们跨产品的各种本地化版本运行相同的脚本。
由于Sikulibuild立在OpenCV（用于图像识别）和tesseract-ocr（用于文本识别）之上，因此它具有令人难以置信的强大function和灵活性。
此外，请参阅文件： http : //groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf
使用Flex Web应用程序logging工作stream程。 花了一段时间想出一个可靠的策略来创build屏幕截图，但是一旦我做到了，甚至在我改变了我的桌面配色scheme后，脚本仍然继续工作！ 虽然语法有点笨拙，但是当你需要点击一个类似控件集合中的特定控件时，也就是checkbox，input字段。 看起来唯一的方法是使用find()和right(); left(); inside() right(); left(); inside() right(); left(); inside() 。 好像截图越小，检测到的就越可靠。 Imo一个好的做法是在屏幕截图上仅包含重要的对象，并尽可能使其成为primefaces，但不会影响其唯一性。
Absolutley发现“正确使用Sikuli”意味着您没有遵循“录制和播放”模式。 相反，您必须与Sikuli一起开发testing自动化 – 因为您需要使用所有工具 – 作为软件开发任务。
我创build了一个端到端testing自动化解决scheme，用于testing世界上最大的PC制造商制造的video会议应用程序。 他们不明白这是一个完整的开发项目，而不是任何猴子都能执行的点击操作。 试图解释用dynamictypes语言编码的挑战是不可能的。
从我的经验来看，最大的挑战是图像pipe理。 我使用文件系统和configparser进行testing自动化的第一次迭代。 使用configparser工作但是很难实现。 在将来，我计划使用斑点。 Sikuli不支持从数据库直接提取图像（但是），但我有一个解决办法。
Sikuli IDE无法使用和开发工具，因此使用IDE至关重要。 我configuration的2个IDE，NetBeans和Eclipse / PyDev都有自己的问题。 这对于编码来说很好，但是错误的错误，空白和代码丢失的注入使得两者都不是理想的解决scheme。 我在NetBeans中进行编码和testing，在SikuliIDE中执行，并将所有内容保存在记事本中作为备份。
尽pipe遇到任何困难，我是Sikuli的大力支持者。 Sikuli具有改变testing自动化的潜力，使其不必成为面向对象的编码人员就可以访问整个QA社区。
对于Sikuli开发人员更less的自动化testing，也可以查看RobotFramework.org。 有一个关于如何为Robot Framework制作（定制）Sikulitesting库的教程
http://blog.mykhailo.com/2011/02/how-to-sikuli-and-robot-framework.html
我也创build了一个简单的通用版本
http://code.google.com/p/simplesikuli
如果在窗口处理，GUI控件，鼠标和键盘交互方面Sikuli有任何限制，您可以随时使用另一个很棒的免费testing工具AutoIt来补充它。 AutoIt本身也有局限性，当它与Sikuli结合使用时，它们弥补了每个工具的缺点，取代商业级的GUItesting工具。
这个video提到“它容忍一点点改变（原文如此）”。 当变化超过“一点”时，我对所需的努力保持警惕。 界面令人印象深刻，但是过多的误报可能会使testing变慢。
这里是我对Sikuli的testing自动化的感受： http : //pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/
我有一个可靠的Miro跨平台testing套件。
我实际上正在编写一个用sikuli进行GUItesting/error handling的框架。 这很棒。
我已经使用sikuli进行GUItesting，也可以将它与HUDSON集成。
我刚刚发布了我自己的使用Skikuli + RobotFramework进行GUI应用程序testing的框架。
SikuliFramework在Sikuli上面提供了一个面向对象的抽象，用于协助交互GUI元素，例如用于GUI自动化和testing的button，checkbox，单选button，窗口和对话层次集。 它还与RobotFramework紧密集成。
Sikuli基于静态图像匹配。 所以它只适用于GUI足够稳定的情况。 对于包括某种随机性的animation或GUI等dynamicGUI，则不太适用。
而Sikuli只覆盖了testing的视觉部分。 不知道内部状态是否确实如预期的那样。
