発注ラウンジは、システム開発の発注に必要な様々なノウハウや発注ナビで実際に開発された発注者様のインタビューなど、発注担当者様のための情報発信サイトです。

結合テストでシステムの連携を検証!主な種類と実施方式の違い

結合テストとは、システム開発におけるテスト手法の一つです。
システム開発では、結合テストのほかに単体テストや機能テスト、システムテストなどがあり、開発の工程によって実施するテストが異なります。
システム開発は、完成して終わりではありません。
開発したシステムを運用させることが目的であり、ユーザー満足度の高いシステムを納品するためには品質の高いテストが必要不可欠です。
今回は、テスト手法の中でもシステム連携部分を検証する結合テストの概要や種類、具体的なテスト方法や実施時の注意点などについてご紹介します。

integrationtesting2-min

 

目次

 

結合テストとは?

結合テストは、IT(Integration Test)、JT(Joint Test)とも呼ばれます。複数のプログラムやモジュールを同時に稼働して行う動作テストで、モジュール同士を結合した際に意図した通りに動作するかどうかを検証します。

結合テストは、事前にテスト仕様書を作成し、実際に行うテスト項目を決めてから行います。結合テストの項目は、前段階である単体テストをすべて完了していることが前提です。
結合テスト前に行う単体テストは、個々の機能やモジュールが単体で動作するかどうかを検証するテストです。単体テストで実施しているテスト項目は、結合テストではほとんど行わないか、簡易的に確認するレベルに留めることが一般的です。

結合テストでは、ただ動作するかどうかをテストするのではなく、操作と機能動作の組み合わせが正しいか、仕様書通りに機能しているかについても検証します。単体テストによって、個々で正しく動作することが確認された機能やモジュールを対象とし、機能間の連携や一連の機能が仕様書通りに正しく動作するのかを確認します。

 

結合テストの主な種類

結合テストは、システムやプロジェクトの規模によって範囲が変わります。大規模なプロジェクトであればあるほど、システムの数も機能も多いため、結合テストの工程を分けて検証するのが一般的です。

●インタフェーステスト

「結合テストといえば、インタフェーステスト」というほど定番のテストです。インタフェーステストでは、個々の機能が正しく連携するかどうかを検証します。機能間やモジュール間でデータを引き渡した際、データの型が異なることによってデータの値が変わらないか、そもそも引き渡されるべきデータがすべて引き渡されているか、連携元と連携先のモジュールは仕様書通りに問題なく動作するかなどの検証を行います。

●業務シナリオテスト

業務シナリオテストとは、実際の業務を想定したテストです。内容は目的の業務や対象システムによって異なりますが、実際に業務で行う工程や一日の流れをテスト仕様書として作成して検証します。

ポイントは、イレギュラーケースを必ず含めることです。基本的に正しい動作は、システム開発中に何回もチェックしているため、問題なく動作することがほとんどです。しかし、イレギュラーな操作は想定していないので、正常に動作しないことがあります。
例えば、登録後のレコード削除ができるか、登録したレコードの変更ができるか、同じレコードを二つのアカウントで同時に更新ができないよう制御されているかなど、業務で発生する可能性のあるイレギュラーなシナリオは、必ず検証する必要があります。

●負荷テスト

負荷テストとは、システムリソースの限界まで操作し、意図しないシステムのパフォーマンス低下や停止が発生しないかを検証するテストです。例えば、同時にアクセスが集中した際にも、定められた最大アクセス数までレスポンスが低下せずに正しく処理できるかどうかを検証します。

また、予想される連続稼働時間までシステムを動かし続け、意図せず停止しないかを検証します。稼働テストの問題例としては、エラーログの保存領域が少なく見積もられていた結果、100時間の稼働には問題がなくても、200時間稼働した場合にエラーログの保存領域に空きがなくなり、意図しない動作をしてしまうといったことが考えられます。

 

結合テストの実施方式

結合テストには、トップダウンテストとボトムアップテストの二つの実施方式があります。具体的にどのようにテストを実施するのか、結合テストの実施方式について解説します。

●トップダウンテスト

トップダウンテストとは、上位のモジュールから呼び出して、下位へとテストを行う方式です。トップダウンテストの特徴は、上位モジュールから順番にテストしていくため、より重要な上位モジュールに対して早期段階からテストが可能となる点です。
また、重要な上位モジュールを繰り返しテストすることになるので、重大な潜在バグを発見しやすいというメリットがあります。

しかし、上位のモジュールから順に行うため、下位モジュールまで、ある程度開発が進まないとテストを進められません。開発の初期段階では、テストをしながら開発を同時に行うことは難しいでしょう。

●ボトムアップテスト

ボトムアップテストは、トップダウンテストとは反対に、下位のモジュールから上位に向かって順に行うテスト方式です。ボトムアップテストは、開発初期から同時にテストを行うことが可能で、テストケースやテスト仕様書の作成、結果のチェックが簡単であるというメリットがあります。

一方、下位のモジュールからテストを行うため、最終的に上位モジュール部分にバグが見つかった場合、修正量が肥大化する恐れがあります。

 

結合テストを実施するときのポイント

結合テストは、システム開発の規模や対象のシステムなどによって、テスト内容が大きく変わります。そのため、どんなシステムにも対応する万能の結合テストはありません。しかし、結合テストを実施する際のポイントは、ほとんど共通しています。実施時の注意点をしっかり覚えておきましょう。

●本番環境と同じ環境・データでテストをする

可能な限り、実際に運用する本番環境と同じ環境をテスト環境でも準備しましょう。システムを利用するクライアント端末やWebブラウザも、「Chromeでは問題なく操作ができるが、本番環境のInternet Explorerでは操作ができない」といった問題が考えられるからです。同じミドルウェアやサーバを活用することはもちろん、バージョンも同じであれば、より品質の高いテストが可能となります。

また、環境だけでなくデータやスケジュールも本番環境と同様であることが望ましいです。例えば、cron(ジョブスクリプトを自動実行するデーモンプロセス)を利用して自動的に実行されるジョブを本番環境で予定していれば、テスト環境でも同じ時刻に実行するようにcronを設定します。ジョブで利用するリソースが、同時刻にはほかの操作によって利用できずに失敗する可能性が考えられるため、スケジュールも本番環境と同じにしましょう。

●DBのデータを直接書き換えるのはNG

テストを簡易的に済ませようとして、DBに保存されているデータを直接追加・変更・削除してしまうことがあります。しかし、データを変更する場合には、必ずシステム上の機能を利用して変更するようにしましょう。システム上の機能を駆使してデータを変更することによって、漏れていたイレギュラーな操作によるバグを発見できる可能性もあります。

 

綿密な結合テストが高品質のシステム納品につながる

integrationtesting1-min

スケジュール通りにシステムを開発することももちろん大切ですが、スケジュールに遅れがなかったとしてもバグの多いシステムを納品しては意味がありません。
バグを極力取り除いたシステムこそ、納品後のシステム運用において重要となり、納品後に実行される操作を漏れなく組み込んだテスト仕様書を作成し、綿密な結合テストを実施することは品質の高いシステム納品につながります。
システム開発で、テストは最も重要な工程といっても過言ではありません。
ご紹介したポイントを意識して、より効果的な結合テストを実施してみてください。

 

■システム開発の外注先探しは「発注ナビ」で

システム開発会社はすでにお決まりですか?

発注ナビは、システム開発に特化した発注先選定支援サービスです。
全国1500社以上の開発会社から、貴社に代わって最適な発注先をお探しします。
ご相談からご紹介まで完全無料(成約手数料なども一切不要です)。
最短1日のスピード紹介で、お急ぎの案件でもお待たせすることがありません。

詳しくはこちらをご覧ください。

 

 

発注先選びにお困りの方はこちら

具体的に『システム開発』が得意な会社を探す

システム開発の発注先を「専門スタッフ」に相談する

関連する記事

PAGETOP