結合テストとは

結合テストの概念は、いくつかの疑問を提起します。1つ目は、結合テストが必要かどうかです。その答えは、少なくとも部分的には当事者である会社に依存します。公的な影響が限定的である小規模組織は、結合テストの必要性が免除される場合があります。

しかし、一般の人々と幅広く関わっている企業にとって、結合テストはますます重要になっています。そして、新しいソフトウェア・アプリケーションやツールのリリースに取り組むテクノロジー企業であれば、結合テストはさらに重要です。

良い第一印象を残す機会は二度と訪れない、という金言があります。同じ概念が、現代の企業にも当てはまります。彼らのほとんどは、ユーザーを惹きつけ、定期購読者や消費者に変え、成功した収益性の高い継続的な関係を維持しようと懸命に取り組んでいます。このような企業は、人気を博すであろう新しいプログラムやアプリを発表する際に、多くの間違いを犯すわけにはいきません。

消費者は、インストールから他のプログラムやシステムとの対話に至るまで、問題のテクノロジーが宣伝どおりに機能することを期待しています。このため、多くの組織にとって、結合テストはビジネスを行う上で必要なステップです。

つまり、結合テストの目標は、部分とシステムが正常に連携して動作することを確認することです。しかし、PRの観点から見ると、結合テストのもう1つの目標は、現代の環境において信頼できるビジネスを実行できる責任ある企業としての、組織のアイデンティティーを保護することです。

結合テストという用語は、特定の「ウォーターフォール」手法を説明する目的において時間と共に定着しました。以前は、ソフトウェア・モジュールや関連プロジェクトは孤立した環境で作られていたため、QAチームには、コードベースの断片を個別にテストし、ソフトウェア・システムに導入する前にそれらの結果を分析するという、非常に骨の折れる仕事が残されました。

結合テストは、テストケースの作成と評価を通じて行われます。最初のフェーズでは、さまざまなモジュールが対話するアプリケーション内の領域である統合ポイントを正確に特定します。統合ポイントが確立されると、それを中心にテストケースが設計されます。これらのテストケースは、さまざまなインプット・シナリオ、実際の状況、予想される結果に応じて、統合ポイントがどのように機能するかを示すために作成されています。

テスト対象から収集されたデータを使用して、プロジェクトの利害関係者はすべてのプロジェクトデータが保管されているコードベースに必要な調整を行うことができます。

結合テストで使用されるテストケースは、開発者がいくつかの特定のオペレーション領域に焦点を当てる際に役立ちます。

結合テストの全体的な複雑さを増大させるもう1つの側面は、モジュール間および／またはコンポーネント間に存在する関係である依存関係です。一般的な依存関係では、1つのコンポーネントが機能するには、関連するコンポーネントが最初に必要に応じて動作する必要があります。プログラムの実行における潜在的な問題を分類しようとする際には、このような依存関係を考慮する必要があります。

結合テストの実行時に実施される個々のテスト手順には標準的なシーケンスがあります。このような順序付けられたシーケンスにより、開発者はさまざまなコードを構造化された方法で体系的に評価できます。通常、テスト・シーケンスは最も単純な個々のコンポーネントのチェックから始まり、下位レベルのモジュールのバグを、後でオペレーションに悪影響を与える前に修正します。その後、テストはより詳細な統合へと移行し、そのパフォーマンスを評価します。

バグの早期発見に加えて、通常のテスト・シーケンスでは、論理的な進行を使用してコードのデータ・フローを模倣し、コンポーネントのインタラクションが正しい順序でテストされていることを確認します。さらに、テスト・シーケンスでは、低レベル・モジュールに関する重要性の低いテストに低い優先度が割り当てられるため、開発者は最も重要なオペレーションに集中できます。

従来のテスト・シーケンスでは、テスト形式は次の順序で検査されます。

1. 単体テスト：個々の機能を評価する。
2. 結合テスト：コンポーネントがどのように相互作用するかを確認する。
3. システム・テスト：システム全体の全体的な機能を決定する。
4. 受け入れテスト：ユーザーの視点から機能をチェックする。

結合テストは、この標準的なシーケンスの最初のテスト・ステップではありません。個々のコンポーネント間の相互作用のテストは既に単体テストを通じて完了しているため、結合テストはプロセス内の特定の時点で行われます。次のレベルのシステム・テストでは、スケールアウトの流れをさらに進め、システム全体とその連携が正常に動作しているのかどうかについて、よりマクロな視点で実行します。

結合テストの手法には数多くの種類がありますが、これらはソフトウェア・システムを評価するために最もよく使用される結合テスト手法です。

トップダウン・アプローチは、インクリメンタル結合テストにおいて2つある主要なタイプのうちの1つです。メイン・モジュールとその機能に焦点を当ててから、サブモジュールとサブルーチンを評価します。このアプローチの最大の特性の1つは、下位レベルのモジュールが完全に特定される前であっても、プロセスの早い段階で使用できることです。テスターは、低レベル・モジュールの代わりとしてプレースホルダー（スタブと呼ばれます）を使用できます。

結合テストのもう1つの主な例は、テスト・シーケンスの順序を切り替えるボトムアップ結合テストです。ボトムアップ・アプローチでは、サブモジュールとサブルーチンが最初に評価されます。次に、このアプローチはメイン・モジュールのテストに移行します。そして、トップダウン・テストが必要に応じてスタブをプレースホルダーとして使用するのと同じように、ボトムアップ結合テストでは、まだ特定されていない高レベルのコンポーネントの代替として、ドライバと呼ばれる一時的なモジュールを使用します。

折衷結合（サンドイッチ結合と呼ばれることもあります）は、トップダウン方式とボトムアップ方式を組み合わせたものです。折衷結合の主な利点は、トップダウン・テストとボトムアップ・テストの両方を（直接的に逆の双方向で）制限する強制的なプロセス・シーケンスを克服できることです。折衷結合では、ユーザーのニーズに応じて、メインモジュール、またはサブモジュールおよびサブルーチンのいずれかからテストを開始できます。

結合テストを実施するもう1つの重要な方法として、ビッグバン結合テストがあります。ここでは、システム内に存在するすべての個々のユニット、コンポーネント、およびモジュールが、あたかも1つのユニットであるかのように繋ぎ合わされ、一度にテストされます。ビッグバン・テストは、システムがさまざまな構成要素すべてで動作する場合、すぐに答えを出すことができます。

ただし、この形式のテストには制限があります。その過程でシステムが期待通りに機能しないことが判明しても、ビッグバン・テストでは、どの単体要素が正常に連携して機能しないのかを明らかにできません。

一般的な結合テストの方法をいくつか以下に示します。ソフトウェア会社のニーズによって、どれも正しい方法論である可能性があるため、ここではアルファベット順に並べています。

• API結合テスト：アプリケーション・プログラミング・インターフェイス（API）はコンピューティングの重要な部分であり、ソフトウェア・アプリケーションが相互に接続してデータを正常に共有できるようにします。APIテストは、システム内のさまざまなAPIがどのように連携して動作するかをチェックするソフトウェア・テストの一手段です。目標は、これらのAPIが単一の組織化されたユニットの一部であるかのように完璧に機能することです。APIが相互にスムーズに動作するほど、システム全体のオペレーションが向上します。

• 自動結合テスト：ソフトウェア開発プロセスの重要な部分である自動テストは、ソフトウェア・コンポーネントがどのように連携するかを評価するもう一つの方法です。この結合テストプロセスでは、特殊なテスト・ツールとスクリプトの動作に基づいてテスト・ケースが実行されます。このようにして、デプロイメントの実行前に統合上の問題を検知して修正できます。また、自動化されているため、システム全体がより効率的でアジャイルになります。自動テストは、継続的に更新されるコード変更に関する共有リポジトリに依存するDevOpsプラクティスである継続的インテグレーションの重要な要素です。

• ブラック・ボックス・テスト：ブラック・ボックス・アナロジーは、ブラックボックスの内部動作（コンピュータ・コードに関係するものでも、報告された会社の収益などの他の運用面に関わるものでも）が完全に理解されていないこと認識されているあらゆる状況に適用できます。ブラックボックス結合テストの場合、テスターは、さまざまなモジュール内で使用されている特定のコードをじっくり調べることを望んでいません。むしろ、システム、コンポーネント、モジュールが調和して動作するかどうかについて、よりシンプルで迅速な回答を求めています。

• エンドツーエンド・テスト：名前が示すように、エンドツーエンド・テスト（E2Eテストと呼ばれることもある）は、システム全体の機能を最初から最後までチェックする方法をテスターに提供します。それ以外にも、E2Eテストでは現実世界のテスト・シナリオを模倣し、テスト対象ユニットを決定するテスト計画を組み込むことで、結合テストの環境を整えることができます。E2Eテストは通常、結合テストプロセスの後半、結合テストが完了した後、ユーザー受け入れテストの前に行われます。

• 機能テスト：すべてのソフトウェア・テストの種類の中で、システムの機能そのものを学習することに最も特化しているのは、機能結合テスト（FIT）です。FITは、さまざまなモジュールやコンポーネントが必要に応じて相互作用できることを検証します。また、ソフトウェア開発ライフサイクルの早い段階で、欠陥が本格的な問題になる前に特定するのに役立ちます。テスターは通常、単体テストが実施された後、完全なシステム・テストが開始される前に機能テストを実施します。

• 回帰テスト：回帰テストというテスト・フレームワークもあります。これは、統合プロセス中に行われた変更によって、システムの他の部分に意図せず不具合が発生していないかどうかを確認するための事後テスト環境として機能します。新しいオンライン決済手段などの新機能が導入された場合、既に正しく機能しているシステムがその追加機能によって機能しない事態を避けるために、回帰テストが実行されます。

• ホワイトボックス・テスト：ブラックボックス・テストとは対照的に、ホワイトボックス・テストは、テスターが問題領域を特定し、それらの問題をデバッグするために修正的なコード変更を行うことを期待して、（そのアプローチにはほぼ確実に時間がかかるとしても）テスト・プロセス中に関連するコードを調べたいと望んでいることを前提としています。「ホワイトボックス」というフレーズは、システムの内部構造を明確にしたいというこの意思を反映していますが、「クリアボックス」という表現が、テスターが求めるものをより正確に説明しているかもしれません。

このニッチ市場でも、多数の結合テスト・ツールとフレームワークが利用されています。以下に、最も利用されているものをいくつか紹介します。

• Citris：Citrisは、オープンソースのJavaTMフレームワークを使用して、Javaの膨大なユーザー・ベース（これが、Javaが世界で最も人気のあるプログラミング言語の1つとなっている理由です）に対応します。Citrisは、APIの使用状況（トランザクションなど）を管理し、テスト・メッセージを生成できます。

• Katalon：Katalon Studioの自動テスト・ソフトウェアにはオープンソース・フレームワークのSeleniumが組み込まれています。これは、テスターがJavaScript、NodeJS、Pythonなどのさまざまなプログラミング言語でテスト・スクリプトを記述できるブラウザーベースのツールです。

• Postman：API結合テストは、Postmanを利用することで円滑に実行できます。このツールは、コラボレーションを可能にし、自動化に対応する点でも優れています。さらに、ユーザーは、そのテストをコレクションに含めたり保存したりすることなく、テストを作成できます。テスターはPostmanでリクエストを実行し、対応するURLを受け取ります。

• SoapUI：SoapUIは、Webアプリケーションをテストし、結合テストを実行できるオープンソース・ツールを提供します。これにより、テスターは、テストケースの作成をサポートし、ユーザーがテスト・データを簡単に操作できるようにするグラフィカル・インターフェイスを獲得できます。

貴社が必要としているのがフロントエンドまたはバックエンドの評価や修復であるかに関わらず、結合テストは、ビジネスを最大限の効率と収益性で運営するために今や極めて重要になっている、正常な接続性について評価する手段となります。

前述のように、ソフトウェア開発者は考えられるあらゆるニーズと関連するすべての構成に対応する結合テスト方法の特定と開発に取り組んでいるため、結合テストには相当数の方法があります。ほとんどのソフトウェア開発会社はこのようなテストの必要性を理解しているため、テストは滞りなく実行されます。DevOpsに取り組む企業の約70%が、すでに何らかの形式で結合テストを行っているという推定報告もあります。

では、どの統合ツールが、お客様のビジネスに適しているのでしょうか。柔軟なマーケットプレイスのおかげで、高い確率で、貴社のニーズに適したものを見つけられるでしょう。そのニーズを正確に把握するために、「自分自身を知る」という昔ながらの金言に目を向けることをお勧めします。この言葉は、ポストモダンの世界においても未だに有益なアドバイスです。