types automation testing
テスト自動化についていくつかの誤解があるさまざまなタイプの自動化テストを学びます。
のこの第2部では テスト自動化チュートリアルシリーズ 、自動化されたテストの種類について簡単に説明し、次に最も重要なこととして、テストの自動化に関する誤解を解き明かします。
最高の無料のyoutubeからmp3へのコンバーター
自動化テストとは何ですか？
自動化テストは、一連のテストを手動で実行せずに何度も実行する方法として定義できます。テスト戦略に自動化テストを導入することは、費用と時間を節約する方法です。
学習内容：
自動化テストの種類
自動化テストのタイプは、自動化できるテストスイートの種類を定義します。多くのテスターは、このトピックを、テストスイートを便利に実行できる自動化パックに設計する方法を定義する自動化フレームワークのタイプと混同しています。
この記事では、自動化テストの種類を詳しく見ていき、最後に自動化フレームワークについて簡単に見ていきます。
上記の分類について詳しく理解しましょう。
テストの種類に基づく自動化
機能テストの自動化：
機能テストは、アプリケーションの背後にあるビジネスロジックをテストするために作成されています。これらを自動化するということは、アプリケーションに期待されるビジネスロジックと機能を検証するためのスクリプトを作成することを意味します。
非機能テストの自動化：
非機能テストは、アプリケーションの非ビジネス要件を定義します。これらは、パフォーマンス、セキュリティ、データベースなどに関連する要件です。これらの要件は、一定のままにすることも、ソフトウェアのサイズに応じて拡張することもできます。
テストのフェーズに基づく自動化
ユニットテストの自動化：
これらのテストは、開発フェーズ自体の間に実行されます。理想的には、開発の完了後、テストのためにシステムをテスターに渡す前に、開発者によって実行されます。
APIテストの自動化：
APIテストは、統合フェーズで実行されます。これらは開発チームまたはテストチームによって実行される場合があり、アプリケーションのUIレイヤーが構築される前または後に実行できます。これらのテストは、アプリケーションが構築されている要求と応答に基づいたテストを対象としています。
UIベースのテストの自動化：
UIベースのテストは、テスト実行フェーズで実行されます。これらは特にテスターによって実行され、アプリケーションのUIがテスターに渡される前に1回だけ実行されます。これらは、アプリケーションのフロントエンドからアプリケーションの機能とビジネスロジックをテストします。
テストの種類に基づく自動化
ユニットテスト：
単体テストは、アプリケーションのコードをテストするために構築されたテストであり、通常はコード自体に組み込まれています。それらは、メソッドや関数の記述方法などのコーディング標準を対象としています。
これらのテストは、開発者自身が作成することが多いですが、今日の世界では、自動化テスターも作成を求められる場合があります。
これらのテストを実行し、バグが発生しないということは、コードが問題なくコンパイルおよび実行されることを意味します。これらのテストは通常、アプリケーションの機能面を対象としておらず、コードを対象としているため、開発者が必要とするときに実行できるように自動化する方が適切です。
スモークテスト：
スモークテストは、テストライフサイクルで実行される有名なテストです。これらはビルド後のテストであり、ビルドがアプリケーションから提供された直後に実行され、ビルドが完了した後もアプリケーションが機能していることを確認します。
これは小さなテストスイートであり、複数回実行されるため、自動化するのが理にかなっています。これらのテストは通常、機能的な性質のものであり、アプリケーションのタイプに応じて、ツールを選択できます。
APIテスト：
APIテストは、過去数年で非常に有名になりました。 APIアーキテクチャ上に構築されたアプリケーションは、このテストを実行できます。
APIテストでは、テスターは、アプリケーションが構築されているさまざまなAPIの要求と応答の組み合わせをチェックすることにより、アプリケーションのビジネスレイヤーを検証します。 APIテストは、以下の統合テストの一部として実行することもできます。
統合テスト：
名前自体が示す統合テストとは、すべてのモジュールを統合し、アプリケーションの機能をチェックすることによってアプリケーションをテストすることを意味します。
統合テストは、APIテストを介して実行することも、アプリケーションのUIレイヤーを介して実行することもできます。
UIテスト：
UIテストは、UIレイヤーまたはアプリケーションのフロントエンドから実行されます。これらは、機能のテストを対象とする場合もあれば、単にアプリケーションのUI要素をテストする場合もあります。
UIを自動化して機能をテストすることは、一般的な方法です。ただし、GUI機能の自動化は、より複雑な自動化の1つです。
回帰テスト：
最も一般的に自動化されたテストスイートの1つは、回帰テストスイートです。ご存知かもしれませんが、リグレッションは、新しいモジュールのテストの最後に実行されるテストであり、既存のモジュールが影響を受けていないことを確認します。
これは、テストの新しい反復ごとに繰り返され、メインのテストケースは、通常、新しい反復の後にいくつかの新しい追加で修正されたままになります。頻繁に実行されるため、ほとんどすべてのテストチームがこのパックの自動化を試みます。
継続的インテグレーションとしての自動化：
自動化された回帰テスト自体で継続的インテグレーションが再び実行される場合がありますが、CIを実現するために、新しい展開が行われるたびに回帰テストスイートまたは識別されたテストスイートを実行できるようにします。
セキュリティテスト：
セキュリティテストは、機能的なテストと、アプリケーションの脆弱性のテストを含む非機能的なタイプのテストの両方が可能です。機能テストは、承認などに関連するテストで構成されますが、非機能要件は、SQLインジェクション、クロスサイトスクリプティングなどのテストである可能性があります。
パフォーマンステストと品質管理：
パフォーマンステストは、アプリケーションの負荷、ストレス、スケーラビリティのテストなどの要件を対象とする非機能テストです。
検収試験：
受け入れテストは、クライアントによって与えられた受け入れ基準が満たされているかどうかを確認するために通常行われる機能テストに再び分類されます。
これまで、自動化できるテストのタイプと同じもののさまざまな分類について説明してきましたが、すべての分類は、最終的には自動化されたテストスイートの同じ最終結果につながります。前に述べたように、これらがフレームワークとどのように異なるかについて少し理解する必要があります。
上記の分類から自動化するテストを特定したら、手動での介入をあまり必要とせずに、これらのテストをスムーズに実行できるようにロジックを設計する必要があります。手動テストスイートから自動テストスイートへのこの設計は、フレームワークの出番です。
次に、トップ3のテスト自動化タイプについて説明します。
- ユニットテスト
- APIテスト
- GUIテスト
＃1） 自動化されたユニットテスト
自動化されたユニットテスト コードレベルをテストするために書かれています。バグは、開発者によって作成された関数、メソッド、およびルーチンで識別されます。
一部の企業は開発者に単体テストを自分で行うように依頼し、一部の企業は専門のテスト自動化リソースを採用しています。これらのリソースはソースコードにアクセスでき、本番コードを解読するための単体テストを記述します。
単体テストが存在するため、コードがコンパイルされるたびに、すべての単体テストが実行され、すべての機能が機能している場合は結果が示されます。単体テストが失敗した場合は、製品コードにバグが存在することを意味します。
市場に存在する最も人気のあるツールのいくつかは次のとおりです。 NUnit そして JUnit 。 Microsoftは、ユニットテスト用の独自のフレームワークも提供しています。 MSTest 。これらのツールのWebサイトにアクセスすると、単体テストの作成方法に関する例とチュートリアルがさらに提供されます。
＃二） 自動化されたWebサービス/ APIテスト
アプリケーションプログラミングインターフェイス（API）を使用すると、ソフトウェアが他のソフトウェアアプリケーションと通信できるようになります。他のソフトウェアと同様に、APIをテストする必要があります。このタイプのテストでは、通常、GUIは関与しません。
ここでテストするのは、通常、機能、コンプライアンス、およびセキュリティの問題です。 Webアプリケーションでは、アプリケーションの要求と応答をテストして、それらが安全で暗号化されているかどうかをテストできます。
これは、APIテストを使用できる例の1つです。 APIテストで最も人気のあるツールは 石鹸 無料版と有料版の両方があります。必要に応じて使用できる他のツールもあります。
＃3） 自動化されたGUIテスト。
このタイプの自動テストは、アプリケーションのユーザーインターフェイスのテストを伴うため、最も困難な自動化形式です。
GUIは非常に変更される可能性があるため、これは困難です。ただし、このタイプのテストは、ユーザーがアプリケーションで行うことにも最も近いものです。ユーザーはマウスとキーボードを使用するため、自動化されたGUIテストも、マウスとキーボードを使用してユーザーインターフェイスに存在するオブジェクトをクリックまたは書き込むことにより、同じ動作を模倣します。
このため、バグを早期に発見でき、回帰テストやフォームへの入力など、時間がかかりすぎる多くのシナリオで使用できます。
最も人気のあるGUIテストツールは次のとおりです。 Micro Focus統合機能テスト（UFT） 、 セレン 、 テスト完了 そして Microsoftコード化UI （これは、Visual Studio UltimateおよびPremiumエディションの一部です）。
自動化テストの種類と同様に、フレームワークにも複数の種類があります。
自動化フレームワーク
一般的に使用される自動化フレームワークには、次のものがあります。
- リニア（録音と再生）
- キーワード駆動
- データ駆動型
- ページオブジェクトモデル
- 基本単位
さらに読む=> 自動化フレームワーク
自動化プロセスの最初のステップは自動化のタイプを特定することです。次に、設計するフレームワークを特定し、これらを念頭に置いて、ニーズに合ったツールを選択できます。
自動化ツール
ターゲットとするテストのタイプと、それを中心に構築する可能性のあるフレームワークのタイプに基づいて、次のツールを使用できます。
- セレン ： Webアプリケーションをテストするための非常に強力なツール。複数のブラウザをサポートします。
- JunitとNunit： 開発者によるユニットテストに主に使用されるツール。
- QTP ： Web以外のアプリケーションに最適なツールであり、組み込みのオブジェクトリポジトリが付属しています。
- シクリ： GUIテスト用のオープンソースツール。
- 石鹸UI： APIテスト用のツール。
- 安心してください： APIテストフレームワークを作成するためのライブラリ。
- appium ： モバイルテスト、ネイティブアプリテスト、ハイブリッド、およびモバイルWebアプリケーションテストをサポートするツール。
- Jmeter ： パフォーマンステストに使用されるツール。
- TestNG： TestNGは、それ自体は自動化ツールではありませんが、セレン、appium、安心などで構築された自動化フレームワークに優れたサポートを提供します。
さらに読む=> テスト自動化ツール
自動化テストに関する誤解
何年にもわたって、私はテスト自動化についていくつかの誤解を聞いてきました。この記事でもそれらをクリアする必要があると思います。
誤解＃1。 自動化は、手動テスターに取って代わるものです。
テストの自動化は、テスターがテストをより速く、より信頼性の高い方法で行えるようにするためのものです。人間に取って代わることはできません。
テスト自動化を車と考えてください。歩いて帰ると20分くらいかかります。でも車を使えば2分で到着します。車の運転手はまだあなた、人間です、しかし..車は人間が彼/彼女の目標をより速く達成するのを助けます。また、歩いていないので、ほとんどのエネルギーが節約されます。したがって、このエネルギーを使用して、より重要なことを実行できます。
自動化テストについても同じことが言えます。これを使用して、繰り返される長くて退屈なテストのほとんどをすばやくテストし、時間とエネルギーを節約して、新しく重要な機能に焦点を合わせてテストします。
なので ジェームズ・バッハ 素晴らしい引用を言った：
「ツールはテストしません。人々だけがテストします。ツールは、人々がテストするのを「助ける」アクションのみを実行します。 「「
ツールはオブジェクトをクリックできます。ただし、クリックする場所は常に手動テスト担当者によって指示されます。私はあなたが今私の主張を理解していると思います。
誤解＃2 。 太陽の下ですべてを自動化することができます
テストケースを100％自動化しようとすると、おそらくそれができるでしょうが、それができれば、最初のポイントは誤りになります。すべてが自動化されている場合、手動テスターは何をしますか？
混乱していますか？正しい？
実際、重要なのは、テストケースを100％自動化することはできないということです。テスターとして、100％テストできるアプリケーションはないと信じているからです。私たちが見逃すシナリオは常にいくつかあります。アプリケーションがクライアントによって使用される場合にのみ発生するバグは常に存在します。
アプリケーションを100％テストできない場合、100％の自動化をどのように約束できますか？
また、既存のすべてのテストケースを自動化できる可能性は非常に低いです。自動化が難しく、手動で実行する方が簡単なシナリオは常に存在します。
例えば 、1人のユーザーがデータを入力し、2人目のユーザーがデータを承認し、3人目のユーザーがデータを表示し、4人目のユーザーがデータを表示することを禁止します。これらのシナリオは自動化できますが、多くの時間と労力がかかります。したがって、手動で行う方が簡単です。
私たちは車を使って距離を移動しますが、途中で信号が長くなる可能性があり、燃料消費が発生し、駐車スペースの問題、駐車料金、その他多くの頭痛の種が発生します。いくつかのシナリオでは、私たちはただ歩いて目的地に到着します:) 。
したがって、すべてを自動化しようとすべきではありません。重要なシナリオと手動で行うのに時間がかかるシナリオのみを自動化します。
誤解＃3 。 自動化には、録音と再生のみが含まれます。
ファンタジーの世界に住んではいけません。このファンタジーは、実際にはさまざまな自動化ツールベンダーからの虚偽の広告によって作成されています。ステップを記録して再生するだけで、テストケースが自動化されると言われています。まあ、それは大きな嘘です！
自動化はすべてであり、記録と再生だけではありません。純粋なオートメーションエンジニアは通常、録音および再生機能をまったく使用しません。記録と再生は通常、ツールがステップのスクリプトをどのように生成しているかを知るために使用されます。
スクリプトを理解すると、常にスクリプトを使用して自動テストを作成します。覚えておいてください テスト自動化を行う場合は、プログラミングを知っている必要があります 。 一方、プログラミングを知らなくてもがっかりしないでください。他のタスクと同じように、プログラミングも練習と献身で学ぶことができます。
私はコンピュータサイエンスのバックグラウンドを持っていない人々を知っていますが、彼らはプログラミングを学び、今では素晴らしい自動化エンジニアです。マイクロソフトでは、プログラミングができるテスターを雇っています。という SDET （テスト用のソフトウェア開発エンジニア）。ジョブの説明の最初の行には、「SDETは多くのコードを記述しています…」と書かれています。
プログラムを学ぶことを学んでください、それから逃げないでください。それはあなたになります 素晴らしいテスター 。
結論
この記事が、テスト自動化に関連するいくつかの概念を明確にするのに役立つことを願っています。
さまざまな分類方法を使用して、さまざまなタイプの自動化テストの高レベルをカバーしました。
主な分類は次のとおりです。
- テストのタイプ（機能的または非機能的）に基づく自動化。
- テストのフェーズ（ユニット、API、またはUI）に基づく自動化。
- さまざまなタイプのテスト（複数のテストタイプ）に基づく自動化。
また、これらのタイプの自動テストに使用できるさまざまなツールをリストアップしました。
次回の記事では、 のステップバイステップの手順 組織でテスト自動化を開始する方法 。