YAZエンジニアが運営するメディア

ソフトウェア開発では、必ずテストを行う必要があります。要件定義に則しているか、エラーなく処理できているか、品質に問題はないか、といった点を確認するのがテストの目的です。結果に応じて、コーディングに修正を施します。

実際に運用が開始してから不具合が見つかると深刻な問題に発展するケースがあるため、ソフトウェアテストは段階的に、慎重に行われます。ソフトウェアテストのなかでも重要な部分を占めるのが、結合テストです。こちらでは、結合テストの基礎知識や主な種類、代表的な手法やスムーズに実施するためのポイントなどについて紹介します。

結合テストの基礎知識

まずは、結合テストの基本的な情報についてご案内します。結合テストとは、複数のプログラムやモジュールを組み合わせて行う動作確認のテストのことです。「IT（Integration Test）」や「JT（Joint Test）」とも呼ばれます。プログラムやモジュール間の構造やデータの受け渡しに問題がないかを確認するのが主な目的です。

システム開発においては、複数種類のテストが実施されます。結合テストも、開発で一般的に実施されるテスト工程のひとつです。

他の動作確認テストとの違い

• 単体テスト

単体テストは、独立したプログラムやモジュール単体で行う動作確認テストです。モジュールとは、プログラムの部品を意味します。一般的な、システムはモジュールの集合体ということになります。

モジュールを結合する前に、単体テストにてひとつひとつテストを行います。これに対し、結合テストは、単体テストで正常に動作したものを組み合わせて、動作を確認します。

• システムテスト（総合テスト）

システムテスト（総合テスト）は、システム全体が正常に動作するか確認するテストです。結合テストをクリアした機能を組み合わせ、システム全体で不具合がないかをチェックする最終テストとして実施されます。最終的に、発注側の要求を実現するシステムとなっているかを確認するのが目的です。

システムテストはさらに分類可能です。ユーザーが主体となるシステムテストが、ユーザーテストです。対して、リリース後の運用について検証する場合は、運用テストと呼ばれます。

結合テストの主な種類

結合テストにはいくつかの種類があります。以下では、代表的な結合テストの種類をご紹介します。

インターフェーステスト

インターフェーステストは、個々のプログラムやモジュールが連携して動作するかを確認するためのテストです。データの引き渡しが正常に行われているか、といった観点から検証します。

ブラックボックステスト

ブラックボックステストは内部構造を把握せずに、入力に対して正しい出力が得られるかを確認するテストです。実施にあたり、開発の知識は求められません。開発者以外のメンバーでも行えるため、費用対効果が高いテストといえます。

業務シナリオテスト

業務シナリオテストは、実際の業務を想定した工程で動作確認を行うテストです。基本的には、業務に則した操作を行いますが、イレギュラーな操作も必ず行うようにする必要があります。これは、レアケースでも不具合が起こらないようにするためです。

負荷テスト

負荷テストは、システムの限界まで負荷をかけた状態で動作停止やパフォーマンス低下が起こらないかを検証するテストです。例として、最大アクセス数に到達するまでレスポンスが低下しないか、想定される連続稼働時間でシステムダウンしないか、といったテストを行います。

結合テストの実施方式とポイント

結合テストにはいくつかの実施方式があり、それぞれに特徴があります。また、結合テストをスムーズに実施するためには、特定のポイントについて知っておかなければなりません。以下では、結合テストの実施方式と、スムーズに結合テストを行うためのポイントについて解説します。

結合テストの実施方式

• トップダウンテスト

トップダウンテストは、プログラムで上位階層にあるモジュールから順番にテストを行う方法です。上位階層にあるモジュールをテスト対象として繰り返し検証するため、重要な不具合を早期発見するために適しています。下位のモジュールが開発中の場合は、代替品のダミーモジュールである「スタブ」を使用します。そのため、下位モジュールを未テストの場合も実行可能です。

• ボトムアップテスト

ボトムアップテストは、プログラムで下位階層にあるモジュールから優先的にテストを行う方式です。下位モジュールのほうが優先度の高い機能を担う場合、重要な機能からチェックできる点がメリットです。上位のモジュールが開発中の場合は、「ドライバ」と呼ばれる上位モジュールの代替品を使用します。

結合テストをスムーズに実施するポイント

• 余裕のあるスケジュールで行う

結合テストは、スケジュールに余裕を持たせた状態で行うのが基本です。結合テストの遅延は、プロジェクト全体の遅延につながることがあります。結合テストで不具合が発覚した場合も、プロジェクトに大幅な遅れが生じないようなスケジュールリングをすることが重要です。

単体テストをクリアしたとしても、結合テストで不具合が生じることは少なくありません。また、結合テストの段階で依頼側の要求追加により仕様変更が加えられることもあります。このことからも、結合テストには十分な時間的余裕が必要です。

• 本番に近い環境でテストを実施する

結合テストは、可能な限り本場に近い環境を構築してテストを実施する必要があります。システムに利用する端末やバージョンなどを揃える、実際に利用する時間帯でテストする、といった細かい部分まで本番の環境を再現しましょう。

実際に起きるトラブルは環境に大きく依存します。同環境でなければ発見できない問題を事前に解消できるため、本番環境に近づけてテストを行うことは極めて重要です。

• データベースのデータを書き換えないようにする

単体テストでは、データベースを編集してテストデータを作成するケースが少なくありません。しかし、結合テストで入力データを直接利用すると必要なデータを削除するおそれがあります。このことから、データベースのデータを書き換えるのは好ましくありません。準備コストが発生しますが、テストで使用できるデータを別途用意するのが安心といえます。

品質を保つためには綿密な結合テストが不可欠

システム開発において、バグを残したまま納品することは避けなければなりません。そのため、開発工程においてテストは非常に重要です。テストのなかでは、結合テストは綿密に行う必要があります。一方で、結合テストが長期化すると、スケジュールに大幅な遅れが生じてしまうケースがあります。

手戻りなどが起こらないよう、網羅的、かつ効率的に結合テストを行うことが肝要です。スムーズに結合テストを行うためには、開発者の技術や知識が求められます。開発を依頼する際は、結合テストを迅速に行い、開発コストがお得なYAZをご検討ください。