結合テストとは？目的・観点・種類・手順を徹底解説！
システム開発の現場では、いくつものテストが実施され、大きく分けると「単体テスト」「結合テスト」「システムテスト」の3種類です。このような種類があることは、理解できている人が多いのではないでしょうか。
ただ、テストの存在自体は認識できていても、具体的な内容が把握できていないケースが見受けられます。特に結合テストは、中間のテストであるためその内容について理解されていない状況です。今回は、システム開発の中でも重要となる結合テストについて解説していきます。
結合テストの基本知識
結合テストの基本知識について概要とテストイメージから解説します。
結合テストの概要
結合テストは、単体テストが終わった後に実施されるテストを指します。さまざまなテスト内容を実施できる工程であるため、多くのテスト項目を用意することが多いでしょう。その結果、時間をかけた実施になることが特徴です。テスト工程の中でも、中盤から後半にかけて実施するもので、特に長い時間が割かれると考えて良いでしょう。
一般的に結合テストでは、複数のコンポーネントを組み合わせて、想定通りに動作するか評価します。単体テストで、コンポーネントの評価が完了しているはずです。そのため、組み合わせた場合を中心に、実際に動作させて評価しなければなりません。
結合テストの評価例
例えば、特定のコンポーネントから出力したデータが別のコンポーネントに取り組みできるかどうかをテストします。データの形式はもちろん、想定した時間で受け渡しできるかや取り組み内容に問題がないかなども評価するのです。具体的に結合テストのイメージを例で挙げると以下のとおりです。
- コンポーネントAからコンポーネントBへのデータ連携
- ボタンを押した際のファンクションC起動
- 画面Dから画面Eへの遷移
このテストケースは一例ですが、複数のコンポーネントを組み合わせてテストケースを作成します。ただ、コンポーネントを一気に繋ぎ合わせるテストではありません。基本的には2つのコンポーネントを組み合わせてテストすることが特徴です。例えば、コンポーネントAとコンポーネントBをテストして、コンポーネントBとコンポーネントCをテストします。コンポーネントAからコンポーネントCまで一気にテストする作業は、システムテストと呼ばれ、別のテスト工程になるのです。
結合テストと単体テストの違い
結合テストと単体テストは、テスト対象や進め方が異なっています。
まず、単体テストでは、それぞれのコンポーネントを個別にテストします。例えば、特定のコンポーネントで計算した結果が正しいかどうかや、特定のファイルを取り込みできるかなどです。複数のコンポーネントを同時に動かすことはなく、単体のコンポーネントを動かすと理解すれば良いでしょう。
それに対して、結合テストは上記で解説したとおり、2つのコンポーネントを組み合わせて実施します。単体で動作させるか、組み合わせるかという観点で大きな違いがあると理解しましょう。また、組み合わせるかどうかの違いにより、事前にテスト用のデータを準備しておくかなどの違いも生じます。
結合テストを実施する目的
結合テストを実施する目的は人によって解釈が異なります。JSTQB（Japan Software Testing Qualifications Board）の基準を参考にしてみると、以下の5つが挙げられています。
- リスクの軽減
- コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証
- コンポーネント品質に対する信頼の積み上げ
- コンポーネントに存在する欠陥の検出
- 欠陥がより高いテストレベルまで見逃されることの防止
繰り返しにはなりますが、結合テストは2つのコンポーネント間の組み合わせを中心にテストするものです。紹介した基準でもコンポーネントの振る舞いに関する要件があるため、これらが主な目的であると理解して差し支えないでしょう。
結合テストの種類
結合テストは基本的にコンポーネント間のテストではありますが、厳密には2つの意味合いで利用される可能性があります。
コンポーネント結合テスト
コンポーネント結合テストは、コンポーネントの組み合わせに注目したテストです。上記で解説している結合テストは、全てコンポーネント結合テストであると理解してよいでしょう。単体テストの後に実施して、必要に応じて自動化するなど、効率化しながら大量のケースを進めます。
一般的に「結合テスト」とだけ表現するならば、コンポーネント結合テストであると理解して差し支えありません。以下で解説するシステム統合テストは、場合によって「総合テスト」など別のテストに内包される可能性があるからです。ただ、どちらも結合テストと呼べるものであるため、2種類とも理解しておくとよいでしょう。
システム統合テスト
システム統合テストは、システムやパッケージ、マイクロサービスなどの間で結合テストを実施することです。実施内容としては、上記のコンポーネントと同じようなものと考えましょう。ただ、これらはコンポーネントではなく、独立したシステムやアプリケーションです。そのため、厳密には異なったテストとして考えられています。
システム間であるため、内部的なデータの動きではなく、インターフェースを利用したデータ連携などがテストの中心です。データを作成し外部インターフェースで連携するなど、システムテストに近いテストでもあります。ただ、特定のシナリオに沿って実施することはなく、それぞれの結合を重視している点で異なったものです。
結合テストの観点
結合テストは実施すればよいというものではありません。要件定義書に沿って適切なテストケースが作成されなければなりません。コンポーネント間の組み合わせを評価するために、以下を必ず考慮するようにしましょう。
機能が正確かどうか
最初に評価すべきは、機能が正確に実装されているかどうかです。ここでの機能とは単体レベルではなく「コンポーネント間連携が正常に動いているか」であると捉えてください。例えば、コンポーネントAからコンポーネントBへとデータが適切に連携できるかなどです。
コンポーネント単体のテストは「単体テスト」で実施する内容であり、ここで評価することは求められません。事前に単体テストが完了していて、それらの連携が正常であるかを評価するのです。これを切り分けできていないと、結合テストのケースが増えすぎる可能性があります。
仕様に沿っているか
単純に機能が動作しているだけではなく、仕様書通りになっているかどうかも評価しなければなりません。仮にコンポーネント間で、データが連携できたとしても、それが仕様書と異なった動きであれば意味はないのです。テストの根底には、仕様書が存在しているため、これに沿った内容であるかどうかを重視しなければなりません。
むしろ、結合テストのテストケースを作成する際は、仕様書を参考にすることが重要です。プログラムをベースとしてテストケースを作成することもありますが、これは単体テストの作業であると考えたほうが良いでしょう。結合テストの場面では、詳細設計書の一部や基本設計書を参考にすることが重要です。
非機能要件を考慮する
結合テストの段階でも、非機能要件の考慮が重要です。こちらはシステムテストで評価されることが多いですが、可能な範囲については、結合テストで評価しましょう。例えば、システムのパフォーマンスやスケーラビリティは、結合テストで実施できるかもしれません。
多くの場合、非機能要件について要件定義書に記載されているはずです。そのため、事前にその内容を踏まえて、テストケースを作成できるでしょう。もし結合テストの段階で要件に問題があるならば、システムテストでもその問題が露呈します。問題は早い段階で検出できたほうが影響範囲は少なくなるため、テストケースに含めておきたい部分なのです。
結合テストを実施する手順
実際に結合テストを実施する人へ向けて、具体的な実施手順を解説します。なお、これは一例であるため、場合によって手順が変更される可能性があります。
テスト計画の作成
テスト計画は結合テストなど各種テストを成功させるために必要不可欠な工程です。まず、テストの目的と範囲を定義して、テストする機能や実施するシナリオの特定などを済ませておきましょう。続いて、テストに必要なリソースとして、テスト環境、テストツール、人員の割り当てなども検討します。同時に、テストのスケジュールを設定し、開始日と終了日をテスト計画に含めておくことが重要です。
また、テスト計画を作成するだけなく、これらの計画を正確にドキュメント化し、関係者にレビューしてもらうことを心がけましょう。場合によっては、実現できないテスト計画になっているかもしれません。そのため、第三者目線で評価してもらうことが重要です。また、リソースの確保が必要となるため、それらの調節作業という観点でもレビューしてもらいましょう。
テストケースの設計
テストケースの設計は、結合テストの中核となる作業であり、実際にテスト担当者が実施するテストシナリオの作成から検討することが重要です。解説したとおり、結合テストは設計書に基づいて実施する必要があるため、各種設計書から仕様を理解する作業が求められます。そして、モジュール間のインターフェースや連携仕様などを考慮したテストシナリオを作成するのです。
次に、各テストシナリオに基づいて具体的なテストケースを設計します。各テストケースには、入力データ、期待される出力、前提条件、後始末処理を明記しなければなりません。詳細なテストケースを設計することで、テスト実行時に予期しない問題が発生するリスクを最小限に抑えられます。
テスト環境の準備
結合テストは専用の環境を用意することがあるため、必要ならば環境をセットアップしましょう。例えば、必要なハードウェアとソフトウェアをインストールし、テスト環境を整備します。また、テストデータを準備して、それらをテスト環境に適応しておく作業も重要です。
適切なテスト環境を準備しないと、テストの品質が下がってしまうリスクを抱えます。特にバグが発生した際、問題を切り分けできなくなるため、注意しましょう。
テストの実施
一通りの準備が完了したならば、実際にテストを実施していきます。テストが成功する計画を含む準備段階が重要となるため、焦って実施しないように注意が必要です。実施の前には担当者への情報共有や、テスト実施にあたっての注意点の解説なども必要です。
基本的にテストは、テストケースに沿って進めるだけです。そのため、結合テストのケースが正確に作成されていれば、大きな問題は発生しないでしょう。テスト担当者には正確なエビデンスを取得してもらい、何かしらのバグが発見された際は修正できるような体制も準備しておきます。なお、修正はテストと並行して実施することもあれば、全てのテストが完了してから修正することもあります。これはプロジェクトの体制などにもよって左右される部分であるため、臨機応変に対応しましょう。
バグの報告と修正
一般的に結合テストでバグが発見された際はその内容をドキュメントにまとめて報告します。報告先はプロジェクトリーダーや開発の担当者など状況によりけりです。修正によってリリースに大きな影響が出るならば、プロジェクトマネージャーなども参加する可能性があります。
バグの内容について説明した結果、どのような優先順位で対応するかを検討することが一般的です。すぐさま対応することもあればコストや期間などの都合から一旦は見送ることもあり得ます。テストを実施しながら報告会など繰り返し実施して、全体のバグについて方針を決定しなければなりません。
まとめ
結合テストとはどのような工程であるかについて解説しました。複数のコンポートを連携するテストであり、単体テストのあとに実施されます。設計書に基づいた仕様になっているかを軸に評価しなければなりません。
なお、結合テストには種類がありますが、基本的にはコンポーネント結合テストが実施されます。ただ、システム統合テストを指す場合もあるため、念のために理解を深めておきましょう。
