統合テストとは正確には何ですか？

私の友人と私は、統合テストとは何かを正確に分類するのに苦労してきました。

今、家に帰る途中で、統合テストの実世界の例を挙げようとするたびに、それが受け入れテストであることがわかりました。事業者が大声で言うことで、システムが何を提供すべきかを特定します。

これらのテストタイプの分類についてRuby on Railsのドキュメントを確認しましたが、今では完全にスローされています。

統合テストの簡単なアカデミックな説明を実際の例で教えてもらえますか？

現時点では、この記事で Gojko Adzicが作成した「あなたがそれを何と呼ぶか​​は重要ではありませんが、何をするのか」という声明が好きです。

あなたは本当にあなたがテストしようとしているものをテストについて話している人々と指定する必要があります。

役割が何であるかに応じて、異なる見解を持つ多くの人々がいます。

テスターに​​とって、オランダで一般的に受け入れられているテスト方法論はTMapです。TMapは次の区別を行います。

• 単体テスト
• ユニット統合テスト
• システムテスト
• システム統合テスト
• 受け入れテスト（すべての種類/レベル）
• 機能受け入れテスト
• ユーザー受け入れテスト
• 生産受け入れ試験

これらには、上記のテスト内で実行できるより具体的な種類のテストがあります。概要については、このdocをご覧ください。

ウィキペディアにも概要があります。

この本は、実用的なプログラマは言います：

• ユニットテストは、モジュールを実行するテストです
• 統合テストは、システムの主要部分がうまく機能することを示しています

これらのさまざまな情報源を見て、自分の経験や意見をいくつか入れて、3つのカテゴリで区別することから始めます

• 一般的に誰がテストを行うのか
• テストされるもの

• テストの目標は何ですか

  • ユニットテスト：コードレベルの正確さを示すためにプログラマーがクラスのロジックをテストします。それらは高速であり、テストするつもりのないシステムの他の部分に依存してはなりません。
  • 機能的受け入れテスト：テスト部門によって行われた限定的な（特別に作成された）データセットでのユースケースシナリオのテスト。指定されたすべてのシナリオが指定どおりに機能することを示します。
  • ユーザー受け入れテスト：ユーザーの代表者によって行われたデータのような実稼働環境でのユースケースシナリオのテストを行い、アプリケーションを正式に受け入れさせます
  • 統合テスト：モジュールの異なる部分間の通信パスをテスト部門または開発者がテストして、すべてのモジュールが正しく機能することを示します。

上記の私のリストはほんの始まりであり、提案ですが、私は本当に考えています。「あなたがそれを何と呼ぶか​​は重要ではありませんが、何をするのか」

お役に立てれば。

26-10-2016編集：つい最近、YouTube 単体テストと統合テストの非常に良い紹介が行われました-MPJの黙想-FunFunFunction＃55

統合テスト、受け入れテストであることが判明

明らかに。

これら2つはほとんど同じものです。ただし、テスト定義には若干異なるディメンションがあります。

統合==システム全体。

受け入れ==システム全体。

唯一の違い（これは微妙ですが）は、テストケースの定義です。

統合==統合の深さと程度をテストするテストケース。すべてのエッジケースとコーナーケースで機能しますか？テストケースは、デザイナーやコーダーによって作成された技術的な傾向があります。

受け入れ==テストケースは、機能セットの80％をエンドユーザーに焦点を当てて実行します。すべてのエッジおよびコーナーケースではありません。テストケースは技術的ではない傾向があり、エンドユーザーが作成します。

私は個人的には、システムのすべてのコンポーネントがモックオブジェクトではなく、本物である場合の統合テストを機能テストと考えています。

実際のリポジトリ、実際のデータベース、実際のUI。システムが完全にアセンブルされたときに特定の機能をテストし、展開されたときのようになります。

私の（私は認める）ほとんどの経験では、統合という言葉は本当に誤解を生む可能性があることを理解しました。実際、システム内で完全に分離された何かを見つけることは難しく、いくつかの要素は確かに統合が必要です。

したがって、私は次の区別をすることに慣れました。

• 私は単体テストを使用して、テストするクラスが達成する責任があるすべての動作を識別、文書化、および強調しています。
• 私のシステムに別の「外部」システムと何らかの会話をしているコンポーネント（おそらく複数）があるときはいつでも、統合テストを行っています。（以下に続く...）
• システムで期待される特定のワークフローを定義し、文書化し、ストレスをかけるために、受け入れテストを実装します。

統合テストの定義では、外部とは開発範囲外のシステムを意味しました。何らかの理由で動作をすぐに変更することはできません。ライブラリ、変更できないシステムのコンポーネント（社内の他のプロジェクトと共有されている）、dbmsなどです。これらのテストでは、システムの実際の環境に非常によく似たものを設定する必要があります。動作します：外部システムを初期化し、特定の状態に設定する必要があります。現実的なデータをデータベースに登録する必要があります。等

代わりに、受け入れテストを行うとき、私は何かを偽造します。私は何か違うことに取り組んでいます。システムの仕様に取り組んでいます。外部エンティティと協力する能力ではありません。

これは、KeesDijkが以前に説明したものと比べて本当に狭い視野ですが、私がこれまで取り組んできたプロジェクトは、このレベルの単純化を可能にするのに十分小さいと思います。

統合テストは、設計されたような複雑なシステムの構成要素（例えばソフトウェア、航空機、発電所）が一緒に働いていることを確認します。

航空機について話していると想像してみてください（ソフトウェアを使用すると、より抽象的なものになり、違いを生むのが難しくなります）。統合テストには次の検証が含まれます。

• 一部のコンポーネント間の正しい相互作用。例：スタートボタンを押すと、エンジンが始動し、プロペラが予想される回転速度に達します（航空機は依然として地上にとどまります）
• 外部コンポーネントとの正しい相互作用。例：埋め込み無線が固定無線と通信できることを確認します（航空機はまだ地上にあります）
• 関係するすべてのコンポーネント間の相互作用を修正し、システム全体が期待どおりに機能するようにします。例：テストパイロットとエンジニアの乗組員が飛行機を開始し、飛行機で飛行します（全員がパラシュートを着用しています...）。

統合テストは、技術的な問題に対処し、システムがコンポーネントにその細分化にもかかわらず、働くつまりこと、。ソフトウェアでは、コンポーネントはユースケース、モジュール、機能、インターフェース、ライブラリなどになります。

受け入れテストは、製品が目的に適合していることを確認します。それらは原則として顧客によって実行されます。航空機にたとえると、次のことを検証することが含まれます。

• 想定されるビジネスシナリオは、ほぼ実際の状況で期待される結果につながります。例：テスト搭乗者と搭乗のリハーサルを行い、スタッフが運用手順で予想どおり搭乗を監視できることを確認します。一部のシナリオは非常に単純なため、単体テストのように見えますが、ユーザーが実行します（たとえば、会社の機器で電気プラグを試す）。
• このシステムは、ほぼ実際のビジネス状況で機能します。例：燃料消費量が約束どおりであることを確認するために、航空会社から新たに訓練されたパイロットとともに、2つの実際の目的地間で空のテスト飛行を行います。

受け入れテストは、より多くの責任問題に対処します。クライアント/サプライヤーの関係では、契約上の責任（すべての要件の遵守）になります。しかし、いずれにせよ、システムで彼らの義務を引き継ぐことを保証し、不測の事態を慎重に防ぐことは、使用する組織の責任でもあります（例えば、新しいワゴンは5 cm大きすぎました-冗談ではありません！）。

結論：統合テストと受け入れテストは重複しています。彼らは両方とも、システムが全体として機能することを示すつもりです。ただし、システム全体がより大きな組織システムの一部である可能性があるため、「全体」は顧客にとってより大きく、システムインテグレーターにとってはより技術的です。

統合テストは、2つ以上のモジュール間の接続とデータフローの正確性をチェックする以外の何物でもありません。

例：メール（1つのモジュール）を作成し、それを有効なユーザーID（2番目のモジュール）に送信する場合、統合テストでは、送信済みメールが送信済みアイテムにあるかどうかを確認します。

統合テストの実用的な定義の1つは、アウトプロセスとの対話を必要とするテストです。

例えば：

• ファイルシステム
• ネットワーク
• データベース
• 外部API

プロセスと外部世界との間にはある種の契約が存在し、その契約が統合テストの目標であることを最小限に検証します。つまり、契約を確認するだけです。もしそうなら、あなたはシステム/エンドツーエンド空間に向かって動いています。

ユニットテストは、プロセス境界内のすべてのロジックをテストできます。また、低速/脆弱/複雑な「外部世界」への依存関係がないため、正確に簡単にテストできます。

統合テストはありますが、この定義ではカバーしていません（そのため、私はそれを実際的な定義と呼んでいます）。

厳密に言えば、はい、この定義はシステム/エンドツーエンドのテストもカバーします。私の哲学では、それらは「極端な」統合テストの一種であるため、その名前が別の側面を強調する理由です。他の方向では、ユニットテストはゼロコンポーネントの統合テストと見なすことができます。つまり、すべてのテストは、0-nコンポーネント間で統合する統合スペクトルのどこかにあると見なすことができます :-)