我实际上使用过 Sikuli，并相信它是 QA 自动化的未来。图像比较的模糊逻辑是纯粹的天才。您可以将其调高到完全匹配或将其调低。我在多个浏览器/操作系统和分辨率上运行了相同的测试，没有太多问题。

它比过去的旧 x,y 测试更强大。我创建了一个 image.sikuli 脚本来托管我所有的图像，我只是重复使用它们。

我负责测试的应用程序不能很好地与 QTP 或 TestComplete 配合使用，我看不到元素。这在使用嵌入式组件的应用程序中似乎越来越普遍。Sikuli 弥补了这一差距，我发现它比其他的更容易使用（尽管 IDE 不是很好）。它没有其他一些工具所提倡的记录和回放功能，但再次这样做永远不会产生可重复的强大自动化。

Selenium 也不进行任何图像比较。虽然测试可能通过，但在 IE 9 上可能看起来很糟糕。Sikuli 至少可以对元素和按钮进行高级比较，以确保它们正确呈现。

我可以想出一些想法：

• 您正在为不知道如何提供元素 ID 或使用其他 API 的开发人员进行测试，并且不会及时返回并修复问题。这是在积累技术债务——最好让开发人员把它做好——但是，例如，在没有考虑可测试性的情况下设计的遗留应用程序上，屏幕截图测试可能是创建 UI 测试的唯一合理选择。事实上，这个工具可能会按照这些思路为我解决即将出现的问题。. .

• 您正在专门进行测试以确保 UI 在外观上保持合理相似。正常的 UI 测试不关心按钮的外观，并且无法捕捉到使用的图像是否被意外删除或与旧按钮图像交换。我已经在主要应用程序上看到了用于这些目的的其他屏幕截图测试。

• 如果您可以从 PM 中获得真正准确的屏幕截图，则可以在将 ID 分配给元素之前进行 UI 测试，并自动确保最终 UI 与 PM 规范匹配。

只要您可以将屏幕截图分配给变量并重复使用它们（因此您在整个测试套件中只有一个“确定”按钮的屏幕截图），维护不会太糟糕 IMO。如果 ID 仍在更改并且 UI 处于极端变化中，这可能会更容易。我曾经参与过一个项目，开发人员一直在意外删除 ID，我不得不等待数周才能定期获得可靠的标识符。但是根据定义，UI 元素将始终具有图像，这意味着 1 分钟的测试修复而不是 3 周的等待，我无法自动运行该测试并需要手动运行它，或者 15 分钟到 1-小时修复以编写解决方法并对其进行测试。

当可能有两个或多个相似的 UI 片段（例如，两个“确定”按钮，一个在错误上，一个在标准配置屏幕上）时，我能想到的主要困难会出现，但即使是 ID 也可能有类似的问题（你想要“dynamicMenuOption11”还是“dynamicMenuOption12”？），并且大多数时候你可以通过截取更大的屏幕截图来解决这个问题（例如，获取“应用”按钮的边缘或错误对话框来识别正确的按钮） . 这比在 IMO 中编码 ID、检查其他值等更容易解决。

编辑： 我确实认为 Tarun 提出了一个很好的观点，即 Sikuli 对变化的容忍程度。该视频声称某种“最合适”的匹配，但它的容忍度如何？而且，如果过于宽容，会不会产生假动作和假传球？

在我看来，没有！

当您使用图像来定位元素时，当有人出现并决定更改应用程序的外观或元素在屏幕上的位置时，您就会遇到麻烦。您将构建一个脆弱的测试套件，并将永远更新您使用的图像。

一个问题是 IE 和 firefox 并不总是以相同的方式呈现 css，细微的差异会导致您的测试失败，因此您需要在测试中检查不同的图像。这确实是一种开销，您可以避免这样做。

另一方面，Selenium 和 Watir 并不关心元素的外观，相反，您可以使用许多不同的技术（id、名称、类...）来找到它，这些技术允许您构建可靠的测试套件。

我不确定这是否像说 Sikuli 是一种比 Selenium 或 Watir 更好的测试自动化技术那么容易——它只是一种替代方案。

在我当前的项目中，前端测试团队正在努力测试使用 flexmonkium 的应用程序。他们有在 flexmonkium 中编写测试的技能和经验，但是我们的应用程序需要使用 flexmonkium 库重新编译，否则测试根本无法连接到应用程序中。在很长一段时间内不可能做到这一点，因此团队需要另一种方法。我们选择了 Sikuli，因为它不需要任何钩子到被测应用程序中——它只是简单地处理屏幕上的内容。

Sikuli 有缺点（速度慢、不可预测、跨浏览器问题等），但在某些情况下，它可能是一个不错的选择。你需要自己做决定。