自動化されたユーザーインターフェイステストはどのような問題を解決しますか？

現在、自動化されたユーザーインターフェイステストを調査中です（現在、自動化された単体テストと統合テストを行っています）。

SeleniumとTelerikを見てきましたが、後者の方がはるかに柔軟なレコーダであるため、後者を選択のツールとして採用しました。テスターがあまり多くのコードを書くことは望ましくありません。

ただし、全体的なメリットを理解しようとしています。人々の意見はどのようなもので、どのようなものがうまく機能し、何がうまくいかないのでしょうか？

私たちのシステムは絶えず開発されており、（ウェブベースの）プラットフォームの新しいバージョンを定期的にリリースしています。

これまでのところ、主な利点は、特にプラットフォームの複数のクライアント展開での回帰テストにあります。

他の人の意見を本当に探しています。私たちはそれが正しいことだと「考える」が、すでに忙しいスケジュールの中で、さらなる洞察を探している。

私のチームが自動UIテストを実装したとき、多くの素晴らしいことが起こりました。

まず、QAチームは、アプリケーションのテストがはるかに効率的になり、アプリケーションの習熟度が向上しました。リードQAは、UIのテストスイートに新しいQAメンバーを導入することで、新しいQAメンバーをすばやくスピードアップできるようになったと言いました。

第二に、開発チームに戻ってきたQAチケットの品質が向上しました。「送信ボタンをクリックしたときにページが壊れた」の代わりに、失敗した正確なケースを取得して、フォームへの入力内容を確認できるようにしました。また、QAチームは、失敗したすべてのケースをチェックし、そのページの他のシナリオをテストして、何が起こったのかをよりよく理解できるようにすることで、さらに一歩踏み出しました。

第三に、QAチームにはもっと時間がありました。この余分な時間で、彼らはより多くの設計会議に参加することができました。これにより、開発者が新しい機能をコーディングするのと同時に、新しいテストスイートケースを作成することができました。

また、使用したテストスイートのストレステストは、金の重さでした。正直なところ、私たちのアプリは投げられるものはほとんど何でも取ることができるので、夜の眠りが良くなりました。かなりの数のページが見つかりましたが、それらはプレッシャーに耐えて公開する前に修正することができました。完璧。

最後に見つけたのは、QAチームによるいくつかの調整により、アプリでSQLインジェクションテストを実行できることです。すぐに修正できる脆弱性がいくつか見つかりました。

UIテストスイートのセットアップにはかなりの時間がかかりました。しかし、いったんそれができれば、それが開発プロセスの中心になりました。

自動化されたUIテストは、実際の統合テストです。彼らはシステムが稼働しているときに実際に使用される方法でシステム全体をテストします。それは彼らを最も意味のあるテストにします。ただし、これらは最も脆弱で、実行速度が最も遅い傾向があります。

コスト/ベネフィット比に注意してください（脆弱性はコストの一部です）、手動でのみテストされるものがあることをためらわないでください（ただし、テストされることを確認してください）。また、可能な場合は、開発者がUIテストスイートの特定の部分をローカルで実行しているバージョンのアプリに対して実行できるようにして、開発中のテストから利益を得られるようにします。

もちろん、ビルドサーバーでテストを（少なくとも1日に1回）自動的に実行することは絶対に必要です。

テスターがあまり多くのコードを書いて欲しくありません。

IMOこれは夢物語です。自動テストの作成はコードを記述しています。録音機能は、あなたがより速くそのコードの一部を書いて、それを手動で書き込むことで、より迅速に開始するのに役立つ（とあなたが書いたコードを手動で速くなる点を欠場ひどく場合を遅く）が、手動で最終的に書いたコードは、あなたが何かすることができます終わりますたくさんやってます。テストフレームワークがそれを十分にサポートし、コードを書くことができない人が自動テストを作成できるようにするという（非常に売れる）パイプドリームに開発が集中しすぎていないことを願っています。

そして、テスターがあまり多くのコードを書いてほしくない

私たちは反対のアプローチを取りました。テスターがコードを書くことを望んでいました。

これが私たちが採用し始めたワークフローです。管理はフロントエンドの自動テストに絶対に依存しないため、これを行うのは簡単ではありません。彼らは「十分に近い」ために喜んで解決します。

1. ユーザーストーリー。

2. 運用コンセプト。ストーリーがどのように機能するか。設計レビュー。

3. スクリーンスケッチ：UIデザイン。どのように見えるでしょう。

4. セレンスクリプト。スクリプトがすべて機能すれば、リリースは完了です。

5. スクリプトが機能するまでのコーディングとテスト。

自動テストは、機能が存在することを実証する唯一の方法です。

手動テストはエラーが発生しやすく、管理のオーバーライドの対象になります。「それで十分です。失敗したテストは、これを時間通りにリリースするほど重要ではありません。」

「自動テストのないプログラム機能は存在しません。」

視覚的なプレゼンテーションは別の話です。視覚的なレイアウトの手動テストは、審美的な判断や、非常に大きく複雑な画面いっぱいのピクセルの特定の（小さな）問題の調査を伴う可能性があるため、例外的なケースです。

これまでのところ、主な利点は、特にプラットフォームの複数のクライアント展開での回帰テストにあります。

回帰テストの自動化は良いことです。これにより、テスターはより興味深い作業を行えるようになります-これにより、自動化されたテストの追加、アプリケーションのストレステスト、またはその他多数のテストが追加されます。

また、自動化することにより、開発者にテストを実行させ、プロセスの後半でのみ発見される問題を未然に防ぐことができます。

私たちはSeleniumとTelerikを見て、より柔軟性の高いレコーダのために、後者を選択のツールとして決めました。

あなたがどれだけ調べたのか分かりません。確かに他のオプションもあります。いくつか例を挙げて、Watir、WatiN、Sikuliを調べましたか？

そして、テスターがあまり多くのコードを書いてほしくありません。

これらのスクリプトを保守しなければならない人々にとって、私は気分が悪いです。ほとんどの場合、簡単に変更できるコードがないと、スクリプトが壊れやすくなり、再記録するよりもスクリプトの変更に時間がかかり始め、さらに時間を無駄にします。

ただし、全体的なメリットを理解しようとしています。人々の意見はどのようなもので、どのようなものがうまく機能し、何がうまくいかないのでしょうか？

テストの自動化は、正しく行われた場合にすばらしいことです。これにより、テスト担当者が最善を尽くしてテストを行う時間を増やすことができるように、回帰テスト/チェックの時間を節約できます。それは銀の弾丸であるとはいえ、しばらく信じないでください。自動化スクリプトは、アプリケーションが既に存在するがテストが存在しない場合、開発にかなりの時間を必要とし、リリースごとに絶えず更新する必要があります。自動テストは、チームの新しい人がシステムの動作を確認するための優れた方法でもあります。また、テスターが自動化する必要があるものを決定できるようにしてください。チェックするのにそれほど時間をかけない小さなチェックで、非常に単調で自動化が簡単な場合は、それから始めてください。常に自動化を通じて最も多く得られるチェックから始めて、そこから作業します。

これまでのところ、主な利点は、特にプラットフォームの複数のクライアント展開での回帰テストにあります。

これが主な利点であり、正しく設定されていれば、わずかな設定変更で必要なほとんどのブラウザをテストできます。

私たちはそれが正しいことだと「考える」が、すでに忙しいスケジュールの中で、さらなる洞察を探している。

前述したように、テストの自動化にはかなりの労力がかかりますが、正しく行われた場合、「テストの自動化を設定しなかったらよかった」と言ったチームにはまだ会っていません。

あなたは、回帰が巨大なものであることは正しいです。また-

• テストがモジュール方式で記述されている場合、テストセットを組み合わせて一致させることで、より大きな成果を得ることができます。

• データのロードに自動テストスクリプトを再利用したため、大規模なテストを行うためにデータベースを調整する必要がありません。

• 性能テスト

• マルチスレッドテスト

• Webシステムの場合-ブラウザー間のスワップとOS間のスワップ。ブラウザーの一貫性の問題では、可能な限り幅広いベースにアクセスすることは大きなことです。

スキップすること-特にWebシステムでは、ディスプレイの要素が動的な変更IDで作成される場合に注意してください-多くの場合、自動化されたテストスクリプトはこれをうまく処理できません。

ほんの一例：Webページのレンダリング時間を正確に測定する

自動化テストを使用すると、Webブラウザーのパフォーマンスをテストするのがはるかに簡単になります。受け入れる可能性のある最大応答時間を測定するには、テストスクリプトで定数を設定するか、関数パラメーターとして渡します。たとえば、次の疑似コードで$ sel-> wait_for_page_to_load（$ mypage、$ maxtime）を使用します。

低い値でクロスブラウザーテストを行うことは非常に有益です。

別の方法は、従業員にストップウォッチでタイミング測定を行わせることです。

自動化されたユーザーインターフェイステストにより、次のことが可能になります。

• 多数のコンポーネントのテストを迅速に繰り返す
• 毎回多数の関数をテストすることを忘れないでください
• アプリケーションの成長に伴うテストスイートの実行と実行時間の比較
• 数百の異なる入力と可変条件で実行をセットアップする
• テストを作成しなかった人々がそれを実行し、視覚的な問題を確認できるようにする
• エンドユーザーが使用中のアプリケーションをすばやく簡単に確認できるようにします
• テストUIの実行をネットワーク、リモートサーバー、またはサービスに配布する
• 並列マシンを使用してボリュームテストを開始します。

ただし、他の人が指摘しているように：

Telerik ...

はるかに柔軟なレコーダーによる選択ツール

私たちの多くにとっては危険です。

この方法で記録されたスクリプトは、長期的な解決策ではない傾向があります。

• データベース/オブジェクトIDはケースごとに変わる傾向があります
• 手動で記録されたスクリプトは、頻繁に変更されるページレイアウトタグに依存することがよくあります
• 再利用を許可する代わりに、一般的なアクションを何度も記述する必要があります（SitePrismとPageObjectのアプローチを参照）
• 現在のページ情報に基づいて追加情報を取得するには、xpathなどのツールを使用する必要がある場合があります。単純な記録されたスクリプトはこれを行いません。
• コードを記述する開発者とテスターは、CSSクラス、ID、およびHTML5データ属性を使用することは推奨されません。CSSクラス、ID、およびHTML5データ属性は、より堅牢で保守可能なテストにつながるプラクティスです。

Telerikには、考慮すべきいくつかの利点があります。

• モバイルクライアント向け
• 成長を管理する組み込みツール
• Android、iOS、Windows Phoneを処理します

ギャップを埋めるのに役立つアプローチは、ツールページレコーダーを使用して初期スクリプトを記録し、その後、ID、クラス、およびデータ属性を使用するようにスクリプトを変更して、時間の経過とともに持続させることです。これは、Firefox Seleniumプラグインで実際に使用したアプローチです。

これにより、「エキスパートテスト」（「探索的テスト」に似ていますが、エンドユーザーまたは多くのビジネス知識を持つチームのメンバーによって実行されます）の実行、結果の記録、測定、自動化が容易になります。

私は異なる背景からこれに来ます。私の以前の雇用主では、商用の自動テストツール（QALoad、QARun、TestPartner、SilkTest、SilkPerfomer）を開発しました。

自動化されたUIテストは、2つの役割を果たしていると考えました。

1. 完全な回帰テスト

2. テスト環境の自動セットアップ

夜間に回帰テストを実行するツールに大きく依存しました。すべてのボタンとダイアログをテストして、UIとビジネスロジックの間に何の支障もないことを確認するだけの人材がいませんでした。

より重要なテストでは、1人で複数のVMを起動し、スクリプトを使用して実際のテストのポイントに到達できることがわかりました。彼らは重要な部分に集中することができ、24ステップのテストケースに従うことを試みません。

自動化されたテストの唯一の問題は、重複または不要なテストを排除するために、いかなる種類の監督もなしに、ボックスにあまりにも多くのテストをダンプする習慣でした。スイートが12時間以内に完了するように、ときどき行って整理する必要があります。

あらゆる種類の自動テストは、回帰テストを提供します。以前は機能していたテストを実行することにより、追加したものに関係なく、テストが引き続き機能する（または機能しない）ことを確認します。これは、テストが統合テスト（通常UIに触れない）かAAT（通常UIを必要とする）であるかに関係なく当てはまります。

自動化されたUIテストでは、ユーザーがボタンをクリックしたかのようにシステムをテストできます。したがって、このようなテストを使用して、システム内のナビゲーション、ラベルおよび/またはメッセージの正確さ、特定のテスト環境でのパフォーマンスおよび/またはロード時間などを検証できます。主な目標は、ボタンをクリックするのに費やすQAの時間を短縮することです。統合と単体テストがプログラマーに行うように。彼は1つのテストを1回セットアップできます（通常、自分のマウスクリックとデータエントリをスクリプトに記録することによって）。テストが適切に機能したら、テスト対象のシステムの正当性を確認するために必要なすべてのことをもう一度実行します。Seleniumなどの一部のフレームワークでは、ブラウザー間でテストを移行できるため、サイトが適切に動作する複数の環境をテストできます。

自動テストなしでは、QAテスターの数と速度によって制限されます。彼らは文字通りシステムを実際に操作して、新しい機能が要件を満たしていることをテストし、（同じくらい重要なことですが）既に存在するものを壊していないことをテストする必要があります。

テストにより、さまざまなことが決まります。これらのテストの多くは自動化できるため、骨の折れる作業をなくすことができ、より多くのことができます。テストを自動化できるかどうかを判断するには、最初に彼らが尋ねる質問が適切かどうかを確認する必要があります。

• コンポーネントが仕様に従って機能するかどうかを判断していますか？
• 考えられるさまざまな入力と出力のすべてをテストしますか？
• コンポーネントのストレステスト？
• または、「動作する」ことをテストしようとしていますか？

これらのほとんどは、本質的に機械的であるため、自動化できます。新しい関数は入力を受け付けるので、ランダムなデータを投げるとどうなりますか？ただし、システムが機能するかどうかをテストするなど、実際に使用する必要がある人もいます。そうでない場合、ユーザーの期待がプログラムの期待と同じであるかどうかはわかりません。つまり、システムが「壊れる」までです。

私の経験では、自動化されたユーザーインターフェイステストは、次のような多くのギャップをカバーしています。

• ドキュメントの欠如（例：自動テストランナーを使用して既存の機能をデモする）
• スコープクリープによる古い要件（例：テスト実行中に画面をキャプチャして要件とコードのギャップを特定する）
• 開発者とテスターの高い離職率（例：開発者ツールを開いた状態でテスト実行中に画面をキャプチャすることによるレガシーJavaScriptのリバースエンジニアリング）
• XPath回帰テストによる標準の命名規則の違反の特定（例：すべてのDOM属性ノードでキャメルケース名を検索）
• コンピューターのみが発見できるセキュリティホールを認識する（例：あるタブからログアウトし、同時に他のタブからフォームを送信する）

チームの経験を共有したいと思います。私たちは、独自のUIテストツールであるScreensterを使用して、当社およびお客様のWebアプリをテストしています。ビジュアル/ CSSテストタスクのSeleniumに代わる有用な代替物であることが証明されています。Screensterは、Webページのさまざまなバージョンのスクリーンショットベースの比較を実行するテスト自動化ツールです。まず、ページの視覚的なベースラインを作成し、各ユーザーアクションのスクリーンショットを撮ります。次回の実行時に、各ステップで新しいスクリーンショットを撮り、ベースラインのスクリーンショットと比較して、違いを強調します。

要約すると、Screensterには次の利点があります。視覚的なベースライン：テスト記録中にユーザーステップごとにスクリーンショットがキャプチャされますスクリーンショットのCSS要素とアクションを実行します。たとえば、それらを無視領域としてマークして、さらなる比較から除外します