GUIベースのアプリをテストするためにSIKULIを使用した人はいますか？
[〜＃〜] sikuli [〜＃〜] 大きな可能性を秘めているようです。誰かがこれをテスト用のツールとして使用しようとしましたか？それとも、ユーザーのアクションを自動化するのに適していますか？
引用 GUIのユニットテスト （プロジェクト内 ドキュメント ）：
Sikuliは、junitと統合することにより、GUIのユニットテストをサポートするように設計されています。ユニットテストパネルを開くには、[表示]/[ユニットテスト]をクリックするか、Macの場合はショートカットCmd Windows/Linuxの場合はCtrl-U）をクリックします。
したがって、SIKULIは最初はGUI自動化を目的としていると理解していますが、GUIテストにも確実に使用できます（GUIテスト= GUI自動化+検証フレームワークを考慮すると密接に関連しています）。完全な例については、---（GUI（JEdit）のユニットテスト を参照してください（画像のassertXXXを参照してください）。
実際、SIKULIには、実際のアプリケーションを1行も記述しなくても（たとえば、いくつかの初期モックアップを使用するだけで）、テストの記述が非常に簡単になるように見えるため、テストの大きな可能性があります。 SIKULIは、さまざまな種類のテスト（BDD、受け入れテストなど）の優れたコンパニオンになる可能性があります。
それは本当に素晴らしいソフトウェアで、とても印象的です。
私はUIテストの自動化にSikuliを幅広く使用しています。私は2011年1月に発見したSikuliパーティーに「遅れ」ています。以前は有望でしたが、Sikuli x1.0-rc1（12月に発生）までは考えられないため、遅れて発見できて本当にうれしいです。 ）プライムタイムの準備ができたことがリリースされました。
以前は、UIテストの自動化にTestQuestとEggPlantを使用していました。私の意見では、Sikuliは彼らの両方を打ち負かします。人々がUIテストの自動化をより良く実行する方法を劇的に変える可能性があり、私の周りの人々にそれを広める可能性があると私は心から信じています。
Sikuliを正しく使用するということは、「記録と再生」モデルに従っていないではないことを意味します。むしろ、ソフトウェア開発タスクとして、すべてのツールで必要なように、Sikuliを使用したテスト自動化の開発に取り組む必要があります。
現在、EggPlant用に構築したUIオートメーションDSL（ドメイン固有言語）をSikuliに移植中です。 DSLで活用する重要な機能の1つは、Sikuliのテキスト認識機能です。これにより、ローカライズされたさまざまなバージョンの製品で同じスクリプトを実行できるようになります。
Sikuliは OpenCV（画像認識用） および tesseract-ocr（テキスト認識用） に基づいているため、信じられないほどのパワーと柔軟性を備えています。
@ jordan、Absolutleyのスポット 'Sikuliを正しく使用することは、「記録と再生」モデルに従っていないことを意味します。むしろ、ソフトウェア開発タスクとして、すべてのツールで必要なように、Sikuliを使用したテスト自動化の開発に取り組む必要があります。
私は、世界最大のPCメーカーが作成したビデオ会議アプリケーションをテストするためのエンドツーエンドのテスト自動化ソリューションを作成しました。彼らは、それが完全な開発プロジェクトであり、どのサルでも実行できるポイントアンドクリック操作ではないことを理解していませんでした。動的に型付けされた言語でコーディングすることの課題を説明しようとすることは不可能でした。
私の経験から、最大の課題は画像管理です。テスト自動化の最初の反復では、ファイルシステムとconfigparserを使用しました。 configparserの使用は機能しましたが、実装は困難でした。将来的にはblobを使用する予定です。 Sikuliは、回避策はありますが、DBからの画像の直接抽出を（まだ）サポートしていません。
Sikuli IDEには開発ツールがないため、IDEの使用は重要です。私が構成した2つのIDE、NetBeansとEclipse/PyDevには、独自の問題のセット。コーディングには最適ですが、誤ったエラー、空白の挿入、コードの損失はどちらも理想的な解決策ではありません。NetBeansでコーディングとテストを行い、SikuliIDEで実行し、すべてをバックアップとしてメモ帳に保存します。
どんな困難に遭遇しても、私はシクリの大きな支持者です。 Sikuliは、テストの自動化を変更する可能性があり、OOコーダーでなくても、QAコミュニティ全体にアクセスできるようになります。
FlexWebアプリでワークフローを記録しました。スクリーンショットを作成するための信頼できる戦略を見つけるのにしばらく時間がかかりましたが、一度作成すると、デスクトップの配色を変更した後もスクリプトは機能し続けました。同様のコントロールのコレクション、つまりチェックボックス、入力フィールドで特定のコントロールをクリックする必要がある場合でも、構文は少し厄介になります。それを行う唯一の方法は、find()をright(); left(); inside()と組み合わせて使用することです。スクリーンショットが小さいほど、確実に検出されるようです。 Imoの良い習慣は、スクリーンショットに重要なオブジェクトのみを含め、それらの一意性を損なうことなく、可能な限りアトミックにすることです。
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テストツールに取って代わります。
Skikuli + RobotFrameworkを使用したGUIアプリケーションテスト用の独自のフレームワークを公開しました。
SikuliFrameworkは、Sikuliの上にオブジェクト指向の抽象化を提供し、GUIの自動化とテストのためのボタン、チェックボックス、ラジオボタン、ウィンドウ、ダイアログ階層などのGUI要素の相互作用を支援します。また、RobotFrameworkと緊密に統合されています。
Sikuliは静止画像マッチングに基づいています。したがって、GUIが十分に安定している状況にのみ適しています。アニメーションやある種のランダム性を含むGUIなどの動的GUIの場合、それほど適用できません。
そして、Sikuliはテストされた視覚的な部分だけをカバーします。内部状態が実際に期待どおりであるかどうかはわかりません。
テスト自動化におけるSikuliの素晴らしさについての私の見解は次のとおりです。 http://pculture.org/devblogs/mirotesting/2011/06/24/using-sikuli-to-automate-miro-testing/
Miro用の信頼できるクロスプラットフォームテストスイートがあります。
私はSikuliのファンであり、他のテストを補完し、手動テストの労力の多くを節約できると信じています。
ただし、正しく理解するには時間がかかります。 2年ぶりにセカンドショットを行い、2回目は環境に親しみ、良い結果を出すことができました。
直感的なIDEおよびpythonを使用すると、いくつかのことを簡単に拡張できます。クリック位置の変更、許容値の設定、および記録を行うのは非常に簡単です。ドキュメントの記録と確認の方法を把握すると、最小限の画像を使いやすくなり、精度が向上します。GUIの変更をキャッチして結果を非常に簡単にします。また、特定のイベントを待つのも簡単です。エラーの確認も簡単です。
それに関する最大の問題は、記録されたものとは別のマシンで実行した場合、記録されたテストが失敗することが多いことです。これは、画像比較ベースのパターンマッチングに関係している可能性があります。許容値を与えることにより、一致パターンの確率を向上させることができます。しかし、公差を変え続けるのは時々面倒になります。異なるプラットフォームで異なるイメージのセットを使用し、できれば単一のマシンまたはVMで実行することをお勧めします。
ワークフローの共通セットを作成したら、（プロジェクトの開閉、設定の変更）などの共通機能のライブラリを作成し、さまざまなスクリプトで使用できます。ライブラリが包括的になるにつれて、それは非常に簡単になります。また、スクリプトを1つの場所でのみ変更する必要があり、すべてのスクリプトに反映されることも意味します。
また、C＃.Netを使用してテストを実行し、結果を記録するための単純なフレームワーク（画像添付）を作成しました。何でも利用して、簡単なテスト実行アプリケーションを作成できます。コマンドラインでテストを実行し、結果を確認するだけです。 
私は、テストリソースが限られている小さなチームで働いていました。 Sikuliを使用することで、既存のQAチームの労力を実際に節約し、バグをメインにプッシュする前にバグを見つけることができました。
私は社内の他のチームのメンバーにSikuliを推奨し、彼らはそれを使用してMLモデルのデータセットを生成しました。彼らは、パラメータを使用してEnggアプリケーションを自動化することでそれを実現しました。
シクリは最初に沈むのに時間がかかります。しかし、正しく行われると、多くの労力を節約できます。
GUIテストにsikuliを使用しましたが、HUDSONと統合することもできました。
私は実際にsikuliでGUIテスト/エラー処理のためのフレームワークを書いています。それは素晴らしい。