メニュー

自動化テストとは（テスト自動化を開始するための究極のガイド）

what is automation testing

問題を排除するために楽器を試してください

プロジェクトで自動化テストを開始するための完全ガイド：

自動化テストとは何ですか？

自動化テストは、実際の結果をテストして期待される結果と比較するためのソフトウェアテスト手法です。これは、テストスクリプトを作成するか、自動化テストツールを使用することで実現できます。テスト自動化は、手動で実行するのが難しい反復タスクやその他のテストタスクを自動化するために使用されます。

自動化テストガイド

プロジェクトの自動化テストを開始しますが、以下に説明する最も基本的な手順に苦労していますか？

  • プロジェクトに自動化を導入するにはどうすればよいですか？
  • 最適で適切な自動化ツールを選択する方法は？
  • スクリプトを効果的に開発する方法は？
  • テストスクリプトを実行および維持する方法は？
  • そして最後に、自動化テストを成功させるために従う必要のあるベストプラクティスは何ですか？

本日、「」に関する一連のチュートリアルで知識を深める予定です。 自動化テストの開始 」。この一連の自動化チュートリアルでは、簡単な例を使用して、上記のすべての質問に段階的に回答します。

プロジェクトで自動化を開始するための一連のチュートリアルを見てみましょう。

自動化エンドツーエンドプロセス：

チュートリアル＃1 ： プロジェクトで自動化を開始するためのベストガイド
チュートリアル＃2： 自動テストの種類といくつかの誤解
チュートリアル＃3： プロジェクトに自動化を導入するための10のステップ
チュートリアル＃4： 最適な自動化ツールの選択に関するAtoZガイド
チュートリアル＃5： スクリプト開発および自動化フレームワーク
チュートリアル＃6： 自動化の実行とレポート
チュートリアル＃7： テスト自動化のベストプラクティスと戦略

自動化のヒント：

チュートリアル＃8： テスト作業を自動化する前に読むべき10のヒント
チュートリアル＃9： 手動プロジェクトと自動化プロジェクトでは、テスト計画はどのように異なりますか
チュートリアル＃10： 自動化をいつ選択するか？
チュートリアル＃11： 自動化テストの課題
チュートリアル＃12： 自動化で概念実証（POC）を実装するためのガイド
チュートリアル＃13： 自動化のための正しいテストケースを選択する方法
チュートリアル＃14： 手動テストケースを自動化スクリプトに変換する方法

オートメーションのキャリア：

チュートリアル＃15： より優れた自動化テスターに​​なるためのヒント
チュートリアル＃16： テスト自動化–それは専門的なキャリアですか？通常のテスターも自動化を行うことができますか？

人気のある自動化ツール：

チュートリアル＃17： Seleniumチュートリアル31以上の最高の無料Seleniumトレーニングチュートリアル
チュートリアル＃18： QTPチュートリアル
チュートリアル＃19： SoapUIWebサービステストツール
チュートリアル＃20： パフォーマンステスト用のHPLoadRunner

自動化フレームワーク：

チュートリアル＃21： 自動化のためのフレームワークが必要な理由
チュートリアル＃22： 最も人気のある自動化フレームワーク

アジャイルの自動化：

チュートリアル＃23： アジャイルの世界で効率的な自動化を実装する方法

その他の自動化ツール：

チュートリアル＃24： 最高の自動化テストツール
チュートリアル＃25： SikuliGUI自動化ツール
チュートリアル＃26： PowerShell：PowerShellを使用したデスクトップアプリケーションUIオートメーション
チュートリアル＃27： Catalon Automation Recorder（Selenium IDE Alternative）
チュートリアル＃28： Gebツール：Gebツールを使用したブラウザの自動化
チュートリアル＃29： AutoIt：AutoItを使用してWindowsポップアップを処理する方法
チュートリアル＃30： キュウリ：キュウリツールとセレンを使用した自動化
チュートリアル＃31： AngularJSアプリケーションのエンドツーエンドテスト用の分度器テストツール

モバイル自動化テスト：

チュートリアル＃32： AppiumStudioハンズオンチュートリアル
チュートリアル＃33： 初心者のためのAppiumチュートリアル
チュートリアル＃34： Selendroidチュートリアル：Androidモバイル自動化フレームワーク
チュートリアル＃35： Ranorexチュートリアル：強力なデスクトップ、Web、およびモバイルテストツール

ドメイン固有の自動化の例：

チュートリアル＃36： JAVA / J2EEアプリケーションの自動化

自動化ジョブの面接準備：

チュートリアル＃37： 自動化テストの面接の質問
チュートリアル＃38： Seleniumのインタビューの質問

「自動化テストの究極のガイド」シリーズの最初のチュートリアルを見てみましょう！

学習内容：

自動化テストとは何ですか？

ソフトウェアが何かを実行できるのなら、なぜソフトウェアはソフトウェアをテストできないのでしょうか。

この声明はあなたにとって論理的に聞こえますか？

はいの場合、おめでとうございます。これは、この一連の有益なチュートリアルで説明する中心点であるテスト自動化について考えています。

SQAとしての仕事の初日を想像してみてください。テストするアプリケーションが表示されます。これは、数百のフォームと数千のレポートを含むERPアプリケーションです。約50の異なるフィールドを含むフォームを開くことから、探索的テストを開始します。

このフォームにランダムなデータを入力しようとすると、約20分かかりました。次に、送信を押します。ウォラ!!未処理の例外のように見えるエラーメッセージが表示されます。あなたはとても幸せになります。手順を誇らしげに書き留め、バグ管理システムでバグを報告します。大変な努力をして、あなたは本当に自信とエネルギッシュを感じます。 1日が終わるまでテストを続け、さらにいくつかのバグを見つけます。 「すごい初日」と思いました。

翌日、開発者は問題を修正し、ビルドの新しいバージョンをリリースしました。同じフォームを同じ手順でテストしたところ、バグが修正されていることがわかりました。修正済みとマークします。大変な努力。あなたはそのバグを特定することで製品の品質に貢献しました。このバグが修正されると、品質が向上します。

3日目になると、開発者は再び新しいバージョンをリリースしました。ここで、もう一度そのフォームをテストして、回帰の問題が見つからないことを確認する必要があります。同じ20分。今、あなたは少し退屈を感じます。

今から1か月後、新しいバージョンが絶えずリリースされ、リリースごとに、この長いフォームとこのような他の100のフォームをテストして、リグレッションがないことを確認する必要があると想像してください。

経験のためのphpインタビューの質問と回答

今、あなたは怒りを感じます。 疲れた 。手順をスキップし始めます。全フィールドの約50％しか入力しません。あなたの正確さは同じではありません、あなたのエネルギーは同じではありません、そして間違いなく、あなたのステップは同じではありません。

そしてある日、クライアントは同じフォームで同じバグを報告します。あなたは哀れな気持ちになります。あなたは今自信がありません。あなたはあなたが十分な能力を持っていないと思います。マネージャーはあなたの能力に疑問を投げかけています。

ニュースがあります。これは、そこにある手動テスターの90％の話です。あなたも違いはありません。

回帰の問題は最も苦痛な問題です。私たちは人間です。そして、私たちは毎日同じエネルギー、スピード、正確さで同じことをすることはできません。これは機械が行うことです。これは、最初に繰り返されたのと同じ速度、精度、およびエネルギーで同じステップを繰り返すために必要な自動化です。

私のポイントを取得してください！

友人をテストする自動化

このような状況が発生した場合は常に、テストケースを自動化する必要があります。 テスト自動化はあなたの友達です 。リグレッションを処理しながら、新しい機能に集中するのに役立ちます。自動化により、3分以内にそのフォームに記入できます。

スクリプトはすべてのフィールドに入力し、スクリーンショットとともに結果を通知します。失敗した場合、テストケースが失敗した場所を特定できるため、テストケースを簡単に再現できます。

自動化–回帰テストのための費用効果の高い方法

自動化のコストは最初は本当に高くなります。これには、ツールのコスト、自動化テストリソースのコスト、および彼/彼女のトレーニングが含まれます。

ただし、スクリプトの準備ができたら、同じ精度でかなり迅速に何百回も繰り返し実行できます。これにより、手動テストにかかる時間を大幅に節約できます。そのため、コストは徐々に減少し、最終的には費用対効果の高い方法になります。 回帰試験 。

自動化が必要なシナリオ

自動化テストが必要になるのは、上記のシナリオだけではありません。手動でテストできない状況がいくつかあります。

例えば 、

  1. 2つの画像をピクセルごとに比較します。
  2. 数千の行と列を含む2つのスプレッドシートを比較します。
  3. 100,000ユーザーの負荷の下でアプリケーションをテストします。
  4. パフォーマンスベンチマーク。
  5. さまざまなブラウザでアプリケーションをテストする 並行して異なるオペレーティングシステム上で。

これらの状況では、ツールによるテストが必要であり、テストする必要があります。

では、いつ自動化するのでしょうか？

これはの時代です アジャイル手法 SDLCでは、開発とテストがほぼ並行して行われ、いつ自動化するかを決定するのは非常に困難です。

自動化に踏み込む前に、次の状況を考慮してください

  • 製品にUIさえない場合、製品はその原始的な段階にある可能性があります。これらの段階では、自動化するものについて明確に考える必要があります。以下の点に注意してください。
    • テストは時代遅れであってはなりません。
    • 製品が進化するにつれて、スクリプトを簡単に選択して追加できるようになります。
    • 夢中にならないようにし、スクリプトを簡単にデバッグできるようにすることが非常に重要です。
  • UIは頻繁に変更されるため、初期段階ではUIの自動化を試みないでください。これにより、スクリプトが失敗します。製品が安定するまで、可能な限りAPIレベル/非UIレベルの自動化を選択してください。 APIの自動化は、修正とデバッグが簡単です。

最適な自動化ケースを決定する方法：

自動化はテストサイクルの不可欠な部分であり、自動化を決定する前に、自動化で何を達成したいかを決定することが非常に重要です。

自動化が提供するように見える利点は非常に魅力的ですが、同時に、組織化されていない自動化スイートはゲーム全体を台無しにする可能性があります。テスターは、ほとんどの場合、スクリプトのデバッグと修正を行うことになり、テスト時間が失われる可能性があります。

効率的なテスト自動化

このシリーズでは、自動化スイートを効率的にして、適切なテストケースを取得し、当社の自動化スクリプトを使用して適切な結果を得る方法について説明します。

また、自動化するタイミング、自動化するもの、自動化しないもの、自動化を戦略化する方法などの質問に対する回答についても説明しました。

自動化のための適切なテスト

この問題に取り組む最善の方法は、当社の製品に適した「自動化戦略」をすばやく考案することです。

テストケースをグループ化して、グループごとに異なる種類の結果が得られるようにするという考え方です。以下の図は、テストしている製品/ソリューションに応じて、同様のテストケースをグループ化する方法を示しています。

テストケースのグループ化

ここで、深く掘り下げて、各グループが達成に役立つことを理解しましょう。

＃1） すべての基本機能のテストスイートを作成します 陽性テスト 。このスイートは自動化する必要があり、このスイートをビルドに対して実行すると、結果がすぐに表示されます。このスイートで失敗したスクリプトはS1またはS2の欠陥につながり、そのビルド固有のものは失格となる可能性があります。そのため、ここで多くの時間を節約できました。

追加のステップとして、この自動化されたテストスイートをBVT（ビルド検証テスト）の一部として追加し、QA自動化スクリプトを製品ビルドプロセスにチェックインできます。したがって、ビルドの準備ができたら、テスターは自動化テストの結果を確認し、ビルドがインストールおよび以降のテストプロセスに適しているかどうかを判断できます。

これにより、自動化の目標が明確に達成されます。

  • テストの労力を削減します。
  • 初期の段階でバグを見つけます。

＃二） 次に、 エンドツーエンドテスト 。

大規模なソリューションでは、特にプロジェクトの重要な段階で、エンドツーエンドの機能をテストすることが重要です。エンドツーエンドのソリューションテストにも触れる自動化スクリプトがいくつか必要です。このスイートを実行すると、結果は、製品全体が期待どおりに機能しているかどうかを示す必要があります。

統合部分のいずれかが壊れている場合は、自動化テストスイートを示す必要があります。このスイートは、ソリューションのすべての小さな機能をカバーする必要はありませんが、製品全体の動作をカバーする必要があります。アルファ版、ベータ版、またはその他の中間リリースがある場合は常に、そのようなスクリプトが便利であり、顧客にある程度の信頼を与えます。

よりよく理解するために、私たちがテストしていると仮定しましょう オンラインショッピングポータル 、エンドツーエンドのテストの一環として、関連する主要なステップのみをカバーする必要があります。

以下に示すように：

  • ユーザーログイン。
  • アイテムを参照して選択します。
  • 支払いオプション–これはフロントエンドテストをカバーします。
  • バックエンドの注文管理（複数の統合パートナーとの通信、在庫の確認、ユーザーへのメール送信など）–これは、個々の部品の統合のテストと製品の核心に役立ちます。

したがって、そのようなスクリプトを1つ実行すると、ソリューション全体が正常に機能しているという確信が得られます。

私のルーターのログインとパスワードは何ですか

＃3） 3番目のセットは 機能/機能ベースのテスト 。

ために 例 、ファイルを参照して選択する機能がある場合があるため、これを自動化すると、ケースを自動化して、さまざまなタイプのファイル、ファイルのサイズなどの選択を含めることができ、機能テストが実行されます。その機能に変更/追加がある場合、このスイートはリグレッションスイートとして機能できます。

＃4） リストの次は UIベースのテスト。 ページネーション、テキストボックスの文字制限、カレンダーボタン、ドロップダウン、グラフ、画像など、UIのみを中心とした多くの機能など、純粋にUIベースの機能をテストする別のスイートを用意できます。 UIが完全にダウンしているか、特定のページが期待どおりに表示されない場合を除いて、これらのスクリプトの失敗は通常それほど重要ではありません。

＃5） 単純ですが、手動で実行するのは非常に面倒な、さらに別の一連のテストを行うことができます。面倒だが単純なテストは理想的な自動化の候補です。たとえば、1000人の顧客の詳細をデータベースに入力すると、機能は単純ですが、手動で実行するのは非常に面倒です。このようなテストは自動化する必要があります。そうでない場合、それらはほとんど無視され、テストされないことになります。

自動化しないものは何ですか？

以下に示すのは、自動化してはならないいくつかのテストです。

＃1）ネガティブテスト/フェイルオーバーテスト

自動化を試みるべきではありません ネガティブテストまたはフェイルオーバーテスト 、これらのテストに関しては、テスターは分析的に考える必要があり、ネガティブテストは私たちを助けることができる合格または不合格の結果を与えるために実際には簡単ではありません。

ネガティブテストでは、実際の災害復旧の種類のシナリオをシミュレートするために、多くの手動介入が必要になります。例として、Webサービスの信頼性などの機能をテストしています。ここで一般化すると、このようなテストの主な目的は、意図的な障害を引き起こし、製品の信頼性を確認することです。

上記の失敗のシミュレーションは簡単ではありません。いくつかのスタブを挿入したり、その間にいくつかのツールを使用したりする可能性があり、自動化はここに進むための最良の方法ではありません。

＃2）アドホックテスト

これらのテストは、常に製品に実際に関連しているわけではなく、プロジェクト開始のその段階でテスターが考えることさえできるかもしれません。また、アドホックテストを自動化する取り組みは、重要度に対して検証する必要があります。テストが触れる機能の。

例えば 、データの圧縮/暗号化を処理する機能をテストしているテスターは、さまざまなアルゴリズムを使用して、さまざまなデータ、ファイルタイプ、ファイルサイズ、破損したデータ、データの組み合わせを使用して、集中的なアドホックテストを行った可能性があります。プラットフォームなど。

計画するとき オートメーション その機能のすべてのアドホックテストだけを優先して徹底的に自動化するのではなく、他の主要な機能を自動化するための時間が少しかかる場合があります。

＃3）大規模な事前設定によるテスト

いくつかの巨大な前提条件を必要とするテストがあります。

例えば、 製品は、システムへのインストール、キューのセットアップ、キューの作成などを必要とするメッセージングキューシステムと統合されるため、一部の機能についてサードパーティソフトウェアと統合する製品がある場合があります。

3rdパーティソフトウェアは何でもかまいませんし、セットアップは本質的に複雑である可能性があり、そのようなスクリプトが自動化されている場合、これらはそのサードパーティソフトウェアの機能/セットアップに永久に依存します。

前提条件は次のとおりです。

現在、両側のセットアップが行われており、すべてが正常であるため、物事はシンプルでクリーンに見える可能性があります。プロジェクトがメンテナンスフェーズに入ると、プロジェクトは別のチームに移動され、実際のテストは非常に単純ですが、スクリプトが3のために失敗するようなスクリプトをデバッグすることになることが、何度も見られます。rdパーティーソフトウェアの問題。

上記は単なる例であり、一般に、次の簡単なテストのために面倒な事前設定があるテストに注意してください。

テスト自動化の簡単な例

（Webまたはデスクトップで）ソフトウェアをテストするときは、通常、マウスとキーボードを使用して手順を実行します。自動化ツールは、スクリプトまたはプログラミング言語を使用して、同じ手順を模倣します。

例えば 、電卓をテストしていて、テストケースが、2つの数値を加算して、結果を確認する必要がある場合。スクリプトは、マウスとキーボードを使用して同じ手順を実行します。

以下に例を示します。

手動テストケースの手順：

  1. 電卓を起動します
  2. 2を押す
  3. +を押します
  4. 3を押す
  5. =を押します
  6. 画面に5が表示されます。
  7. 電卓を閉じます。

自動化スクリプト：

//the example is written in MS Coded UI using c# language. (TestMethod) public void TestCalculator() { //launch the application var app = ApplicationUnderTest.Launch('C:\Windows\System32\calc.exe'); //do all the operations Mouse.Click(button2); Mouse.Click(buttonAdd); Mouse.Click(button3); Mouse.Click(buttonEqual); //evaluate the results Assert.AreEqual('5', txtResult.DisplayText,”Calculator is not showing 5); //close the application app.Close(); }

上記のスクリプトは、手動の手順を複製したものにすぎません。スクリプトは簡単に作成でき、理解も簡単です。

アサーションとは何ですか？

スクリプトの最後から2番目の行には、もう少し説明が必要です。

Assert.AreEqual（“ 5”、txtResult.DisplayText、”電卓は5を表示していません）;

すべてのテストケースで、最後にいくつかの期待または予測された結果があります。上記のスクリプトでは、画面に「5」が表示されることを期待しています。実際の結果は、画面に表示される結果です。すべてのテストケースで、期待される結果と実際の結果を比較します。

自動化テストについても同じことが言えます。ここでの唯一の違いは、テスト自動化でその比較を行うと、すべてのツールで他の何かと呼ばれることです。

一部のツールでは、これを「 アサーション 」、「 チェックポイント 」と呼ばれ、「検証」と呼ばれることもあります。しかし、基本的に、これは単なる比較です。この比較が失敗した場合、 例えば。 画面に5ではなく15が表示されている場合、このアサーション/チェックポイント/検証は失敗し、テストケースは失敗としてマークされます。

アサーションが原因でテストケースが失敗した場合は、テストの自動化によってバグが検出されたことを意味します。手動テストで通常行うのと同じように、バグ管理システムに報告する必要があります。

上記のスクリプトでは、最後から2番目の行でアサーションを実行しました。 5は期待される結果です。 txtResult 。 DisplayText は実際の結果であり、等しくない場合は、「電卓は5を表示していません」というメッセージが表示されます。

結論

多くの場合、テスターはプロジェクトの期限に遭遇し、テストの見積もりを改善するためにすべてのケースを自動化することを義務付けています。

自動化については、いくつかの一般的な「間違った」認識があります。

彼らです：

  • すべてのテストケースを自動化できます。
  • テストを自動化すると、テスト時間が大幅に短縮されます。
  • 自動化スクリプトがスムーズに実行されていれば、バグは発生しません。

自動化により、特定のタイプのテストでのみテスト時間を短縮できることを明確にする必要があります。計画やシーケンスなしですべてのテストを自動化すると、大量のスクリプトが発生します。これは、メンテナンスが多く、失敗することが多く、手動による介入も必要になります。また、絶えず進化する製品では、自動化スクリプトが廃止され、定期的なチェックが必要になる場合があります。

適切な候補者をグループ化して自動化すると、時間を大幅に節約でき、自動化のすべてのメリットが得られます。

この優れたチュートリアルは、わずか7つのポイントに要約できます。

自動化テスト：

  • プログラムで行われるテストです。
  • ツールを使用して、テストの実行を制御します。
  • 期待される結果を実際の結果（アサーション）と比較します。
  • 反復的だが必要なタスクを自動化できます（ 例えば。 回帰テストケース）。
  • 手動で行うのが難しいいくつかのタスクを自動化できます（例えば。負荷テストシナリオ）。
  • スクリプトはすばやく繰り返し実行できます。
  • 長期的には費用対効果が高いです。

ここでは、自動化について簡単に説明していますが、それは必ずしも簡単に実行できるという意味ではありません。それに伴う課題、リスク、その他多くの障害があります。テスト自動化がうまくいかない可能性のある方法はたくさんありますが、すべてがうまくいけば、テスト自動化のメリットは非常に大きくなります。

このシリーズの今後の予定：

今後のチュートリアルでは、自動化に関連するいくつかの側面について説明します。

これらには以下が含まれます：

ソフトウェア開発ライフサイクルフェーズとは
  1. 自動テストの種類といくつかの誤解。
  2. 組織に自動化を導入し、テスト自動化を行う際の一般的な落とし穴を回避する方法。
  3. ツールの選択プロセスとさまざまな自動化ツールの比較。
  4. 例を含むスクリプト開発および自動化フレームワーク。
  5. テスト自動化の実行とレポート。
  6. テスト自動化のベストプラクティスと戦略。

自動化テストのすべての概念についてもっと知りたいですか？このシリーズの今後のチュートリアルのリストに注意して注目し、以下のコメントセクションで自由に考えを表明してください。

次のチュートリアル＃2

推奨読書

^