# テストの種類

URL: https://deploy-preview-2977--selenium-dev.netlify.app/ja/documentation/test_practices/testing_types/

---

### 受け入れテスト
このタイプのテストは、機能またはシステムが顧客の期待と要件を満たしているかどうかを判断するために行われます。
このタイプのテストには通常、顧客の協力またはフィードバックが関与します。
下記質問に答えることで確認することができます。
> **_正しい_** 製品を作っていますか？

Webアプリケーションの場合、ユーザーの予想される動作をシミュレートすることで、
このテストの自動化をSeleniumで直接実行できます。
このシミュレーションは、このドキュメントで説明されているように、記録/再生によって、
またはサポートされているさまざまな言語によって実行できます。
注：受け入れテストは **_機能テスト_** のサブタイプであり、一部の人はこれにも言及する場合があります。

### 機能テスト
このタイプのテストは、機能またはシステムが問題なく正常に機能するかどうかを判断するために行われます。
システムをさまざまなレベルでチェックして、すべてのシナリオがカバーされていること、
およびシステムが実行すべきことを実行していることを確認します。
下記質問に答えることで確認することができます。
>製品を **_正しく_** 作っていますか？

これは通常以下を含みます。
テストがエラーなし（404、例外...）、使用可能な方法（正しいリダイレクト）で機能する、
利用しやすく、仕様に一致します（上記の **_受け入れテスト_** を参照）。

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

### パフォーマンステスト
その名前が示すように、パフォーマンステストは、アプリケーションのパフォーマンスを測定するために行われます。

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

#### ロードテスト
ロードテストは、定義されたさまざまな負荷（通常、特定の数のユーザーが同時に接続されている場合）でアプリケーションがどの程度機能するかを確認するために行われます。

>For example,  **_Testing that the site can handle numerous orders/users at once._**

#### ストレステスト
ストレステストは、ストレス下（またはサポートされている最大負荷以上）でアプリケーションがどの程度機能するかを確認するために行われます。

>For example,  **_Testing that your ecommerce site can handle Black Friday_**

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

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

Webアプリケーションの場合、測定する詳細には、スループット、待ち時間、データ損失、個々のコンポーネントの読み込み時間などが含まれます…

注1：すべてのブラウザには、開発者のツールセクションにパフォーマンスタブがあります（F12キーを押すとアクセス可能）

注2：これは一般に機能/機能ごとではなくシステムごとに測定されるため、 **_非機能テスト_** のサブタイプです。

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

変更によって既存の機能が破壊されないようにするために、すでに実行されたいくつかのテストが再度実行されます。

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

>For example,  **_Testing that your new search bar doesn't break the other buttons on the menu_**

### テスト駆動開発 (TDD)
テストタイプそのものではなく、TDDはテストが機能の設計を推進する反復的な開発方法論です。

各サイクルは、機能がパスする単体テストのセットを作成することから始まります（最初に実行すると失敗します）。

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

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

### ビヘイビア駆動開発 (BDD)
BDDは、上記に基づいた反復開発方法論（TDD）でもあり、その目的は、アプリケーションの開発にすべての関係者を関与させることです。

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

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

そのためには、仕様言語が使用されます。
すべての関係者が理解でき、単純で、標準的かつ明示的でなければなりません。
ほとんどのツールは、この言語として **_Gherkin_**  を使用します。

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

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

Selenium上に一連のツールが構築されており、BDD仕様を実行可能コードに直接変換することにより、このプロセスをさらに高速化しています。 これらのいくつかは、 _**JBehave、Capybara、およびRobot Framework**_ です。