この質問は単体テストに関するものではありません。そして、それはデスクトップ製品用です。
これは、GUI のテストと、適切なタイミングで適切なテキスト ボックスに適切な内容が入力されることをテストすることに関するものです。
私が以前働いていた会社はWinRunnerを使用していました（別の部門なので、それ以上のことはわかりません）が、現在はHPによって閉鎖されていますが、HPにとどまるか他の場所に行くかは気にしていないようです. サインアップするまで製品について読むことができず、面倒です。
ツールは MFC (交渉不可) で動作する必要があり、理想的なツールは...
自動化された GUI テストのために、他の SO ユーザーは何をしますか?
Rational Robot (RRAFS) にはSAFS フレームワークを使用します。WinRunner (WRAFS) 用の SAFS 実装もあり、私がよく知らない新しい「イメージベースのテスト」実装があるようです。
このフレームワークは、UI の実装をテスト スクリプトから分離するという優れた機能を果たします。2 つの異なるチーム (クラシック ASP を使用するチームと ASP.NET を使用するチーム) によって開発された Web アプリケーションの 4 つのリリースをテストしましたが、UI オブジェクトのアプリケーション マップを変更するだけで済み、テスト自体は変更する必要がありませんでした。変化する。
とはいえ、フレームワークの言語は扱いにくく、慣れるまでに時間がかかります。言語構造に関してはそれほど堅牢ではありませんが、少し努力すれば、必要なことは何でもできます。これは、Windows Batch 言語の「プログラミング」に似ていますが、テスト用です ;)
上記の個々の要件に対応するには:
1)ツールは MFC で動作する必要があります (交渉不可)。 SAFS フレームワークは、Rational Robot や Mercury WinRunner などのサード パーティの「記録再生」ツールを使用してテストを実行します。そのツールが MFC アプリと対話できる場合は、フレームワークも対話できます。「イメージベースのテスト」の実装がテストをどのように推進するかはわかりませんが、MFC でも機能すると思います。
2)自動化する。 SAFS フレームワークはSTAF フレームワークと統合され、テストの実行を自動化できます。STAF を使用してイメージのプールから VM イメージを開始し、テスト対象のアプリケーションをインストールし、RRAFS テストを実行し、結果を他のユーザーが取得できるように Web サーバーに配置する概念実証テストを行っています。
3)スクリプト可能であること。 はい。ただし、前述のとおり、最も堅牢なプログラミング言語ではありません。私は、テスト担当者がテストを作成するために使用する Excel アドインを作成しました。
4)さまざまな画面解像度で自動的に動作します。 はい、画面ではなく UI オブジェクトを「隠れて」見ているからです。おそらく「画像ベースのテスト」オプションを除いて...
5)個々の静的テキスト ボックスなどを「スパイ」できる。 はい、UI オブジェクトが表示される、消える、値が設定される、値が変更されるなどを待つことができます。
6)直観的であるため、プログラマー以外でもスクリプトを作成できます。 いくつかのトレーニングで。限られた成功しか収めていません。テストを書けるQA担当者もいれば、苦労するQA担当者もいます。
7)個々のユーザーの電子メールを含むレポート ツールを使用します。 はい、STAF フレームワークを使用して、結果を Web サーバーに投稿したり、電子メールを送信したりできます。
Mercury/HP の経験が豊富なため、GUI テストには QuickTest Professional を使用することを強くお勧めします。WinRunner と同じ機能がたくさんありますが、多くのコードは必要ありません。簡単な GUI チェックは、最小限のカスタム VB コードを使用して、QTP インターフェイスを介して実行できます。ボックスの横にあるテキストのチェックは、QTP のデータシートを使用して単純な比較で行うことができます。
WinRunner に慣れていて、VBScript (TSL はそれほど多くない) を知っている場合は、断固として QTP を検討します。
その他の要件に関しては、QTP には WinRunner などのスパイ機能もあり、オブジェクトに対して実行できるすべてのプロパティとアクションを一覧表示します。使いやすさについては、私の以前の仕事では、ビジネスまたはシステムのテスターに簡単なスモーク スクリプトを作成してもらい、それを使用して、より詳細なテスト (複数のデータ値、エラー チェックなど) 用にコーディングしていました。レポートに関しては、QTP は、入力できるカスタム データと共に、入力したタグの合格/不合格/警告の簡単なレポートを作成します。そのため、case ステートメントを使用して、結果に基づいて出力値を入力できます。単純に電子メールを送信するわけではありませんが、TestDirector/QualityCenter と統合すると、スクリプトのキックオフを自動化するとともに、そこからセットアップできます。
パット
ここには多くの良い答えがありますが、具体的には次の目標ステートメントに対処したかったのです。
あなたがこれを望む理由は理解できますが、あなたが思っているよりもはるかに難しいです。スクリプトを簡単に記述できると主張するツールはいくらでもありますが、実際には、自動化チームにプログラミングを理解している人が少なくとも何人か必要になります。適度に堅牢なスクリプトを作成するには、1 つ以上のループ、if/then/else、およびサブルーチン呼び出しが必要になります。プログラマーでない人が直感的に理解できるようなものではありません。
ツールを使用して人を「記録」し、テストのために再生できるという考えには特に注意してください。この種の「自動化」は、多くの場合非常に脆いため、ソフトウェアのほぼすべての変更に対してスクリプトを変更または再記録することになります。
デスクトップアプリとWebアプリはどちらも、ここでは同じテストパターンを持っています（私は両方で作業しました）。
UIにできるだけ少ないロジックを配置し、その下のすべてをテストします。だからあなたは言いますが、ボタンがクリックされたときにそのようなことが起こることをテストしたい場合はどうなりますか？そのボタンがクリックされたときに呼び出されるメソッドは、実際に思考を行う別のクラスを呼び出す必要があります。
あなたは言うかもしれませんが、私は自分のUIにのみ存在できる静的なクラス/メソッドを使用しており、それらをアダプターでラップし、そのインターフェイスを利用してコードをテスト可能にします。
自動化するGUIテストの部分は、UIの下で自動化する必要があります。GUIには、自動化できない部分があります。物事が「正しく見える」ことを確認すること、または特定の要素を見ることができることをテストすることなど。これらはすべて、人間が行うべきことです。イベントが適切に発生し、値がビジネスオブジェクトから適切に返されることを確認することは、すべて単体テストです。
あなたの質問から、自動化されたGUIテスターが必要であるとすでにほぼ決心していることがわかりますが、それはこの仕事に適したツールではありません。あなたがそれを使うことに決めたなら、あなたは間違ったことをする最良の方法を見つけようとしているのです。
GUIの相互作用をテストしているため、これが単体テストに関するものではないと思われる場合は、UIに十分近い単体テストではないことを保証できます。もしそうなら、あなたはあなたがテストするであろうもののほとんどが冗長であるように感じるでしょう。
私に同意できない場合は、いくつかの理由を投稿してください。これをハッシュ化します。
ユーザー インターフェイス テストを参照してください。
Web 製品をテストしている場合は、さらに多くの (オープン ソース) 代替手段があります。デスクトップ製品については、一般的な汎用デスクトップ GUI 自動化ツールを以下に示します (順不同)。私はこれらすべてと個人的に仕事をしてきましたが、彼らはすべて仕事を成し遂げています。ベンダー ツールを使用することを選択した場合は、検討しているツールの POC を取得し、一般的にどのツールが会社に最も適しているかに基づいて決定を下してください。1 つのツールが特定のアプリケーションにより適している場合がありますが、考慮すべき他のプロジェクト/アプリケーションがある場合があります。