私は自分の GUI をテストする問題に取り組んでいますが、ここでの最善のアプローチが完全にはわかりません。私の GUI は従来の MVC フレームワークを使用して構築されているため、GUI 自体を立ち上げなくても、GUI のロジック部分を簡単にテストできます。ただし、GUI の機能をテストする場合、GUI コンポーネントを個別にテストすることに専念する必要があるのか、それとも主にシステムの機能テストに専念する必要があるのか、よくわかりません。これはかなり複雑なシステムであり、GUI のテストにはサーバーへのメッセージの送信と、GUI での応答の観察が頻繁に含まれます。私の最初の考えは、UI を実際にテストするにはシステム全体を実行する必要があるため、ここでは機能テストを行う方法であるということです。この問題に関するコメントをお待ちしております。
ありがとう、ジェフ
私が提供できるその他の GUI テスト ツールは 、 Thoughtworks White、 PyWinAuto、 AutoIt、 AutoHotKeyです。
GUI を自動化しようとするときに心に留めておくべきことの 1 つは、それを行う唯一の方法は、自動化を念頭に置いて GUI を構築することであるということです。GUI がプロジェクトの早い段階でテスト容易性をサポートすべきではないと考えている開発者を粉砕し、テストのニーズに応じてオンデマンドでの自動化に役立つすべてのフックを喜んで公開します。
（少なくとも）2つの問題があります。環境（サーバー）の複雑さとGUIの複雑さです。
GUIテストを自動化するための多くのツールがあります。それらはすべて多かれ少なかれ壊れやすく、レイアウトの変更に直面してもほぼ一定のメンテナンスが必要です。それらを使用することで得られるメリットはありますが、それは長期的なメリットです。
一方、環境は飼いならすことができる領域です。アプリケーションが依存性注入/反転手法（サーバーコンポーネントをアプリケーションに「注入」する）を使用して設計されている場合は、関連するサーバーインターフェイスの「モック」を使用してテストケースのスクリプトを作成できます。
これら2つの手法を組み合わせると、GUIテストを自動化できます。
最後の考え-頑張ってください！
MVC (これは使い古された用語です) の範囲のどこに座っているかに応じて、ビューのテストは、ビューへの正しい入力に応答して正しいモデル メソッドが呼び出されることを確認し、クライアント側の検証をテストするための機械的なプロセスになる可能性があります。知るか。
MVC から進化した多くのパターン (パッシブ ビュー、監視コントローラーを考えています) は、ビューのテストをほとんど必要としないように努力しています。使用しているパターンのバリアント)。
「GUI を頻繁にテストするには、サーバーにメッセージを送信し、GUI での応答を観察する必要があります」このステートメントは私を悩ませます。
私はすぐに、サーバーのモックまたはスタブを使用して GUI をテストし、正しい対話が行われ、GUI が適切に応答することをテストする必要があると考えています。
サーバーの自動化された機能テストが必要な場合、それらに GUI を含める必要はないと思います。
Mercury QuickTest Pro、Borland SilkTest、および Ranorex Recorder は、いくつかの GUI テスト ツールです。
廊下のユーザビリティテストを試してください。安くて便利です。最寄りの廊下に行き、最初に通りかかった人をつかんで、コンピューターの前に座らせ、ソフトウェアを使用します。彼らの肩越しに見守ると、彼らが何をしようとしているのか、何が彼らを苛立たせているのかなどがわかります。これを数回行い、パターンに注目してください。
私たちのプロジェクトには GUI テストが組み込まれていますが、それには副作用があります。ただし、開発者には重要な設計原則が 1 つあります。それは、GUI レイヤーをできるだけ薄く保つことです。
これは、GUI クラスにロジックがないことを意味します。入力の検証などを担当するプレゼンテーション モデルでこれを分離します。
Unix マシンでのテストでは、テストの実行時に Xvfb サーバーを DISPLAY として使用します。
私のアドバイス: 従来の GUI テストは忘れてください。これは高すぎる。テストのコーディングには多くの時間がかかります。ツールは実際には安定していないため、信頼できないテスト結果が得られます。コードとテストの結合は非常に強く、メンテナンスに多くの時間を費やすことになります。
新しい傾向は、GUI テストを無視することです。ガイドラインリンク テキストとして、Fowler の ModelViewPresenter パターンを参照してください。
これを言うことができる最も明確な方法は次のとおりです。
自動化された GUI テストの作成に時間を無駄にしないでください。
特に MVC アプリを使用している場合 - あなたのケースでは、サーバーにメッセージを送信するときに、正しいメッセージ番号が戻ってきて完了していることを確認できます。GUIがメッセージIDを正しい文字列に変換していることを確認するために、いくつかのケースを追加するか、完全に別のテストを追加できますが、そのテストを1回実行するだけで済みます。
SIMPLE WebベースのGUIテストの場合は、iMacros （単純なFirefoxプラグインで、テスト全体を別の人に送信するための優れた機能があります）を試してください。SIMPLEのスペルはイニシャルであることに注意してください...
WinTaskはGUIテストを行うための非常に良い方法であることがわかりました。OSがUIの各要素を参照する方法を絶えず変更しない限り、WinTaskはUI要素を名前でアドレス指定するため、レイアウトが変更された場合でも、UI要素を押したり微調整したり選択したりできます。
つまり、「GUI」の「U」をお見逃しなく
: テストしようとしているものがすべて正しく機能し、計画どおりに機能する場合は、Seb Rose の回答に従うことができます。
ただし、 USER インターフェイスは、アプリケーションが作成された対象のユーザーではなく、ユーザーのことを考えて作成する必要があることを忘れないでください。したがって、すべてが正常に機能することを確認したら、アプリケーションを使用する可能性のあるさまざまなユーザーのすべてのグループを代表するユーザーで構成されるチームで、すべてのビュー/画面/フォームをテストします: 上級ユーザー、管理者、MS Officeユーザー、コンピューター プロファイルの低いユーザー、コンピューター プロファイルの高いユーザー...そして、すべてのユーザーの批評を受け取り、ミックスを作成し、必要に応じて GUI を修正し、GUI ユーザーのテストに戻ります。
あなたが探しているのは「受け入れテスト」です。その方法は、使用しているフレームワーク、作成しているアプリケーションの種類、および言語によって異なります。特定のテクノロジーと上記のフレーズをグーグルで検索すると、使用できるツールがいくつか見つかるはずです。