テストの種類

受け入れテスト

この種類のテストは、機能またはシステムが顧客の期待と要件を満たしているかどうかを判断するために行われます。この種類のテストは通常、顧客の協力またはフィードバックを必要とし、次の質問に答える検証活動です。

私たちは正しい製品を構築しているか？

ウェブアプリケーションの場合、このテストの自動化は、ユーザーの期待される動作をシミュレートすることにより、Selenium で直接実行できます。このシミュレーションは、記録/再生、またはこのドキュメントで説明されているさまざまなサポートされている言語を通じて実行できます。 注: 受け入れテストは機能テストのサブタイプであり、機能テストとも呼ばれる場合があります。

機能テスト

この種類のテストは、機能またはシステムが問題なく適切に機能するかどうかを判断するために行われます。すべてのシナリオが網羅され、システムが本来の機能を実行していることを確認するために、さまざまなレベルでシステムをチェックします。これは、次の質問に答える検証アクティビティです。

私たちは製品を正しく構築しているか？

これには通常、次のものが含まれます。テストがエラー（404、例外など）なしで動作すること、使用可能な方法（正しいリダイレクト）で動作すること、
アクセス可能な方法で、仕様に一致していること（上記の受け入れテストを参照）。

ウェブアプリケーションの場合、このテストの自動化は、期待される戻り値をシミュレートすることにより、Selenium で直接実行できます。
このシミュレーションは、記録/再生、またはこのドキュメントで説明されているさまざまなサポートされている言語を通じて実行できます。

統合テスト

統合テストは、システムの異なるコンポーネントまたはモジュール間のインタラクションを検証します。複数のモジュールがまとめてテストされます。統合テストの目的は、すべてのモジュールが統合され、期待どおりに連携して動作することを確認することです。自動化された統合テストは、これらのインタラクションが期待どおりに動作し、統合されたコンポーネントが適切に連携して機能することを保証するのに役立ちます。

例：e コマース Web サイトで商品の注文から支払いまでの流れをテストします。

システムテスト

システムテストは、完全に統合された製品のテストです。これはエンドツーエンドのテストであり、テスト環境は本番環境に似ています。ここでは、ソフトウェアのすべての機能をナビゲートし、エンドビジネス/エンド機能が動作するかどうかをテストします。エンド機能のみをテストし、データフローのチェックや機能テストなどは行いません。

例：e コマース Web サイトへのログインから注文、注文履歴ページでの注文の再確認、ログオフまでのエンドツーエンドのフローをテストします。

パフォーマンス testing

名前が示すように、パフォーマンステストは、アプリケーションがどの程度適切に実行されているかを測定するために行われます。

パフォーマンステストには、主に 2 つのサブタイプがあります。

負荷テスト

負荷テストは、アプリケーションがさまざまな定義された負荷（通常は特定の数のユーザーが同時に接続している状態）でどの程度適切に動作するかを検証するために行われます。

ストレステスト

ストレステストは、アプリケーションがストレス下（または最大サポート負荷を超えた状態）でどの程度適切に動作するかを検証するために行われます。

一般的に、パフォーマンステストは、Selenium で記述されたテストを実行して、Web アプリの特定の機能にアクセスするさまざまなユーザーをシミュレートし、意味のある測定値を取得することによって行われます。

これは通常、メトリクスを取得する他のツールによって行われます。そのようなツールの 1 つが JMeter です。

Web アプリケーションの場合、測定する詳細には、スループット、レイテンシ、データ損失、個々のコンポーネントのロード時間などが含まれます。

注 1: すべてのブラウザには、開発者ツールセクションにパフォーマンス タブがあります (F12 キーを押すとアクセスできます)。

注 2: これは、一般的に機能/フィーチャごとではなく、システムごとに測定されるため、非機能テストのサブタイプです。

リグレッションテスト

このテストは通常、変更、修正、または機能追加の後に行われます。

変更によって既存の機能が壊れていないことを確認するために、すでに実行された一部のテストが再度実行されます。

再実行されるテストのセットは、アプリケーションと開発チームに応じて、完全または部分的な場合があり、いくつかの異なるタイプを含めることができます。

テスト駆動開発 (TDD)

テストタイプ自体というよりも、TDD は、テストが機能の設計を推進する反復的な開発手法です。

各サイクルは、機能が最終的に合格する必要がある一連のユニットテストを作成することから始まります（最初の実行では失敗するはずです）。

この後、テストに合格するために開発が行われます。テストが再度実行され、別のサイクルが開始され、すべてのテストに合格するまでこのプロセスが続きます。

これは、欠陥は早期に発見されるほどコストが低くなるという事実に基づいて、アプリケーションの開発をスピードアップすることを目的としています。

行動駆動開発 (BDD)

BDD は、上記の TDD に基づく反復的な開発手法でもあり、アプリケーションの開発にすべての関係者を関与させることを目的としています。

各サイクルは、いくつかの仕様（失敗するはず）を作成することから始まります。次に、失敗するユニットテスト（これも失敗するはず）を作成し、開発を行います。

このサイクルは、すべての種類のテストに合格するまで繰り返されます。

そのために、仕様言語が使用されます。これはすべての関係者が理解でき、シンプル、標準、かつ明示的である必要があります。ほとんどのツールは、この言語として Gherkin を使用しています。

目標は、潜在的な受け入れエラーも対象とし、関係者間のコミュニケーションをより円滑にすることで、TDD よりもさらに多くのエラーを検出できるようにすることです。

仕様を記述し、Cucumber や SpecFlow などのコード関数と一致させるための一連のツールが現在利用可能です。

BDD 仕様を実行可能なコードに直接変換することにより、このプロセスをさらに高速化するために、Selenium の上に構築された一連のツールがあります。これらのツールの一部は、JBehave、Capybara、Robot Framework です。