有沒有人用SIKULI來測試他們基於GUI的應用程序？

Question

SIKULI似乎有巨大的潛力。 有沒有人試圖用這個作為測試工具？ 或者它更適合自動化用戶操作？

Answer 1

GUI的引用單元測試 （在項目文檔中 ）：

Sikuli旨在通過與junit集成來支持GUI的單元測試。 可以通過單擊View / Unit Test或Mac上的快捷鍵Cmd-U（或Windows / Linux上的Ctrl-U）打開單元測試面板。

因此，雖然我的理解是SIKULI最初的目標是GUI自動化，但它絕對可以用於GUI測試（如果您考慮GUI測試= GUI自動化+驗證框架，這是密切相關的）。 有關完整示例的GUI（JEdit）單元測試 （請參閱圖像上的assertXXX ）。

事實上，我發現SIKULI有很大的潛力用於測試，因為它似乎使編寫測試非常容易，即使沒有編寫實際應用程序的單行（例如，僅使用一些初始模型）。 SIKULI可以成為各種測試風格（BDD，驗收測試等）的絕佳伴侶。

它真的是一個令人驚嘆的軟件，非常令人印象深刻。

Answer 2

我正在廣泛使用Sikuli進行UI測試自動化。 我對2011年1月發現它的Sikuli派對“遲到了”。我很高興我發現它很晚，因為雖然它早先很有希望，但我認為直到Sikuli x1.0-rc1（發生於12月） ）被釋放，它准備好黃金時段。

以前，我使用TestQuest和EggPlant進行UI測試自動化。 在我看來，Sikuli擊敗他們兩人。 我真的相信它有可能大大改變人們如何更好地執行UI測試自動化，並將它傳播給我周圍的人。

正確使用Sikuli意味着您沒有遵循“記錄和回放”模型。 相反，您必須使用Sikuli開發測試自動化 - 您需要使用所有工具 - 作為軟件開發任務。

我們目前正在將為EggPlant構建的UI自動化DSL（域特定語言）移植到Sikuli。 我們將在DSL中利用的一個關鍵特性是Sikuli的文本識別功能。 這將允許我們在我們產品的各種本地化版本中運行相同的腳本。

因為Sikuli建立在OpenCV（用於圖像識別）和tesseract-ocr（用於文本識別）之上，所以它具有令人難以置信的功率和靈活性。

Answer 3

另見論文： http ： //groups.csail.mit.edu/uid/projects/sikuli/sikuli-chi2010.pdf

Answer 4

使用Flex Web應用程序記錄工作流程。 花了一段時間來找出創建屏幕截圖的可靠策略，但是一旦我這樣做了，即使我更改了我的桌面配色方案，腳本也繼續工作！ 當您需要單擊類似控件集合中的特定控件（即復選框，輸入字段）時，語法會有點尷尬。 看起來唯一的方法是將find()與right(); left(); inside()結合使用right(); left(); inside() right(); left(); inside() right(); left(); inside() 。 似乎屏幕截圖越小，檢測到的越可靠。 Imo一個好的做法是在屏幕截圖中只包含重要的對象，並盡可能使它們盡可能原子，但不會影響它們的獨特性。

Answer 5

@jordan，Absolutley對'正確使用Sikuli'的觀點意味着你沒有遵循“記錄和回放”模式。 相反，您必須使用Sikuli開發測試自動化 - 您需要使用所有工具 - 作為軟件開發任務。

我創建了一個端到端測試自動化解決方案，用於測試由全球最大的PC制造商制作的視頻會議應用程序。 他們不明白這是一個完整的開發項目，而不是任何猴子可以執行的點擊操作。 試圖用動態類型語言解釋編碼的挑戰是不可能的。

根據我的經驗，最大的挑戰是圖像管理。 我使用文件系統和configparser進行測試自動化的第一次迭代。 然而，使用configparser很難實現。 將來我計划使用blob。 雖然我確實有一個解決方案，但Sikuli不支持直接從數據庫中提取圖像。

由於Sikuli IDE無法使用和開發工具，因此使用IDE至關重要。 我配置的2個IDE，NetBeans和Eclipse / PyDev都有自己的問題。 它們非常適合編碼，但是錯誤的錯誤，空白注入和代碼丟失都使得這兩者都不是理想的解決方案。 我在NetBeans中編碼和測試，在SikuliIDE中執行並將所有內容保存在記事本中作為備份。

盡管遇到任何困難，我仍然是Sikuli的大力支持者。 Sikuli有可能改變測試自動化，使其無需成為OO編碼器即可訪問整個QA社區。

Answer 6

對於Sikuli較少的以開發人員為中心的測試自動化，還可以查看RobotFramework.org。 有一個關於如何為Robot Framework制作（自定義）Sikuli測試庫的教程

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

我也創建了一個簡單的通用版本

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

如果在窗口處理，GUI控制，鼠標和鍵盤交互方面存在Sikuli的限制，您可以使用另一個優秀的免費測試工具來補充它：AutoIt。 AutoIt本身也有局限性，當你將它與Sikuli結合使用時，它們彌補了每個工具的缺點，取代了商業級的GUI測試工具。

Answer 7

我使用sikuli進行GUI測試，我也能夠將它與HUDSON集成。

Answer 8

我剛剛使用Skikuli + RobotFramework發布了我自己的GUI應用程序測試框架。

SikuliFramework在Sikuli之上提供了一個面向對象的抽象，以協助交互GUI元素，例如用於GUI自動化和測試的按鈕，復選框，單選按鈕，窗口和對話層次結構。 它還與RobotFramework緊密集成。

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

Answer 9

Sikuli基於靜態圖像匹配。 因此它僅適用於GUI足夠穩定的情況。 對於動態GUI，例如包含某種隨機性的動畫或GUI，它不太適用。

而Sikuli僅涵蓋測試的視覺部分。 它不知道內部狀態是否確實如預期。

Answer 10

我是Sikuli的粉絲，我相信它是對其他測試的補充，可以節省大量的手動測試工作。

但是，要做到這一點需要時間。 我在兩年的時間里給了它第二次拍攝，第二次我能夠取得好成績，因為我對環境比較熟悉。

它配備了直觀的IDE和python，可以輕松擴展一些內容。 更改點擊位置，設置容差和記錄事物非常容易。 一旦掌握了如何記錄和檢查文檔，就可以輕松使用最少的圖像並提高准確性。 它可以很容易地捕獲GUI中的變化。 等待某個事件也很容易。 錯誤檢查很容易。

它最大的問題是，如果你在另一台機器上運行它而不是記錄它，那么記錄的測試經常會失敗。 它可能與基於圖像比較的模式匹配有關。 可以通過給出公差值來改善匹配模式概率。 但有時候繼續改變容忍度會很煩人。 我的建議是在不同平台上使用不同的圖像集，最好在單個機器或VM上運行。

一旦擁有了一組通用的工作流，就可以創建一個包含這些常用功能的庫，例如（打開 - 關閉 - 保存項目，更改設置）以及跨不同腳本使用。 隨着圖書館的全面發展，它變得非常容易。 這也意味着您只需要在一個位置更改腳本，它將反映在所有腳本中。

我還創建了一個簡單的框架（ 附加圖像 ）來運行測試並使用C＃.Net記錄結果。 可以使用任何東西來創建一個簡單的測試運行應用程序。 它只需要在命令行上運行測試並檢查結果。

我在一個小團隊工作，我們的測試資源有限。 有了Sikuli，我實際上節省了現有QA團隊的努力，並且在將其推向主要部分之前幫助自己捕獲了bug。

我向我公司其他團隊的成員推薦了Sikuli，他們使用它來生成ML模型的數據集。 他們通過使用參數自動化他們的Engg應用程序來實現它。

Sikuli最初需要時間沉淪。 但如果做得好，它可以節省很多努力。

Answer 11

以下是我對Sikuli測試自動化的驚人看法： http ： //pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/

我有一個可靠的Miro跨平台測試套件。

Answer 12

我實際上正在編寫一個用sikuli進行GUI測試/錯誤處理的框架。 這很棒。