結合テストの観点とは

ソフトウェア開発において、テストは品質を担保する上で大変重要な工程です。ソフトウェアのテストをレベルに分けると、大別して次の4つがあります。「単体テスト」（コンポーネントテスト）、「結合テスト」、「システムテスト」、「運用テスト」です。ソフトウェアの品質を担保するには、各テスト工程において各種検証を通じ、バグの洗い出しと、その改修を行うことです。

ここでは、「結合テスト」を中心にして「単体テスト」も含め、その種類・目的・観点・手法などについて解説していきます。「結合テストは難しい」というイメージがありますが、実際にやってみるとさほど難しくはありませんので、ぜひ体得してエンジニアとしてのスキルを磨いてください。

「テスト」について解説していく前に、それぞれのテストがシステム開発工程のどこに位置するのかを確認しておきましょう。

システム開発の工程の「単体テスト」と「結合テスト」の違いを徹底解説！

システム開発の工程

システム開発の工程には、「ウォーターフォールモデル」「アジャイルモデル」「プロトタイプモデル」などがありますが、ここでは伝統的な「ウォーターフォールモデル」を念頭に置いて、システム開発の工程について解説していきます。 各工程については略語も表記しておきますので、この機会に覚えてください。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

要件定義フェイズは、システム化計画やシステム企画フェイズで作成した計画書をベースにして、ユーザーやクライアントが実現したいことを機能要件、技術要件にまとめる工程です。成果物としては要件定義書で、内容についてクライアントやユーザーの合意を得た上で基本設計フェイズに進みます。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

基本設計フェイズでは、要件定義工程で決定した内容に従って、主にユーザーインターフェースを決定します。プロジェクトの規模にもよりますが、基本設計書は一般的にシステムの大きな機能ごとに作成されます。「システム構成図」「画面一覧」「帳票一覧」など、数十種類の資料が成果物となります。また、機能は「機能要件」と「非機能要件」に分かれます。

詳細設計フェイズでは基本設計書の内容に従い、システムに搭載する機能をモジュールごとに分割して、詳細設計書にブレイクダウンしていきます。「機能仕様書」「データフロー図」「データベース設計書」などもここで確定していきます。

主にプログラマーが詳細設計書の内容に従ってプログラミングを行います。プログラミングとコーディングを同義と考える方もいますが、プログラミングはプログラムを作成する作業全般のことで、コーディングはプログラミング言語を用いてソースコードを作成することを意味します。つまりコーティングはプログラミング作業の一部*です。

現場で多く使われるプログラミング言語一覧！種類別に詳しく解説

詳細設計書に基づいて作成したプログラムが、詳細設計書通りの動きをするかどうかを確認します。プログラマー自身がテスト仕様に基づいてテストするケースが大半ですが、テスターと呼ばれる担当者がテスト工程を担当することもあります。

新人が任されやすい単体テストとその仕様書の作成について徹底解説！

単体テストで問題が発見されなければ、複数のモジュールからなるサブシステム全体のテストを行います。ここで、各サブシステム間のインターフェースに問題がないか、各サブシステムの連携が正常に行えているかなどの確認を行います。

結合テストフェイズで、各サブシステムに問題がないことを確認できたら、システム全体を動かして不具合がないかどうかを確認します。要件定義通りの動きをしているかを確認しますが、パフォーマンスチェックも行います。 アクセスが集中した時や処理データ量が急増した時など、イレギュラー時の動きについても確認します。

結合テストとシステムテストの違いは、結合テストはあくまでもサブシステム内の全体テスト、システムテストはシステム全体のテストである点が大きく異なります。

運用テストは、開発したシステムを納品・リリースする前に行う最終工程です。実際の本番イメージでシステムが正常に稼働するかどうか、誤操作などで不具合が起きないか、操作性に問題がないかなど、起こりうるトラブルをすべて想定して、細かくチェックを行います。

ここで不具合を発見できないと、クライアントやユーザーに重大な損害をもたらす事もあるため、小さな不具合も見逃せない重要な工程と言えます。この後、システム移行（リリース）の工程を経て、システムの「保守・運用」フェイズへと進みます。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

単体テストの目的や観点

前述した通り、単体テストはプログラム毎にテストを行います。ここでは単体テストについて、目的や観点を簡単に解説します。

単体テストを行う目的は、プログラム単位の不具合を発見し、早期に修正して結合テストの効率を上げ、ソフトウェアの品質を担保することです。

単体テストの観点としては、主に「条件網羅テスト」と「境界値テスト、異常値テスト」の2種類があります。

「条件網羅テスト」は一般的によく行われるテストで、詳細設計書に記述されたロジックの条件を網羅したテストで、仕様通りに動作するかどうかを確認します。

「境界値テスト、異常値テスト」では、本来受け付けてはならないイレギュラーなデータを意図的に入力して、それらが正しく弾かれるかどうかを確認します。基本的にはこの両方の観点で単体テストを行います。

結合テストの目的や観点

単体テストを無事通過すると、結合テスト工程に入ります。結合テスト工程では、複数のモジュールから構成されるサブシスムごとにテストを行います。ここでは、結合テストの目的・観点・手法について紹介していきます。

結合テストは、モジュール間の連携やデータの受け渡しなどに問題がないことを確認するのが目的です。ここで不具合が発見されると、仕様書に遡って仕様書の修正、プログラムの修正が行われることもあります。しかし、結合テストを確実に実施おくと、総合テストで大きな問題が起きることは少ないでしょう。

結合テストには、同一サブシステム内でモジュール間で行う「内部結合テスト」と、サブシステム間の機能連携について確認を行う「外部結合テスト」があります。

前述の通り、結合テストには「内部結合テスト」と「外部結合テスト」があり、それぞれ確認する観点が異なります。

「内部結合テスト」では、1つのサブシステム内における機能連携の観点から確認し、「外部結合テスト」では、サブシステム間や他のシステム間との機能連携の観点から確認を行います。両者に共通するのは、機能と機能同士の連携が正常に行われているかどうかを確認する点です。 また、テストの観点を見逃すことがないよう、次項の「テスト観点リスト」を作成してテストを行う開発者もいます。

「システムテストの観点に基づくサンプル」や「結合テスト計画書」の記述項目などが以下、IPA作成のガイドブックなどにも載っていますので、ぜひ参照してみてください。

【参照1】：高信頼化ソフトウェアのための開発手法ガイドブック（IPA：独立行政法人 情報処理推進機構）

【参照2】：ソフトウェアテスト見積りガイドブック（IPA：独立行政法人 情報処理推進機構）

前述のテスト観点をまとめたものを「テスト観点リスト」と呼びます。

結合テストを行うエンジニアが「テスト観点」を理解はしていても、属人的な判断に委ねてしまうと、エンジニアによって「テスト観点」に温度差が生じ、必要なテストが漏れてしまうリスクがあります。

そこで役立つのが「テスト観点リスト」です。システム開発は、さまざまな設計書、仕様書に基づいて進められていきますが、テストにもテストとしての仕様書が必要です。 「テスト観点リスト」には定型パターンがありませんので、システムの種類や特性ごとに個別に作成する必要がありますが、重要なことは観点がずれない、観点を漏らさないことです。

ソフトウェア品質評価の国際規格に「ISO/IEC9126」があります。「ISO/IEC9126」は、品質特性として機能性・信頼性・使用性・効率性・保守性・移植性の6つを挙げています。テスト観点リストは、それらを「大きな観点」から「小さな観点」にブレイクダウンしていきます。 たとえば、品質特性の中で「機能性」を1つの観点にして次のようにブレイクダウンしてみましょう。信頼性・使用性・効率性・保守性・移植性についても同様に記述します。

 　　　　　　　　　　　（観点リストの例）

大分類　>   中分類    > 小分類  >　細分類    >　テスト観点

・機能性> 機能テスト>画面表示>レイアウト>配置・サイズ・タイトル

・　　　　　〃                      　 > 画面項目  >文字の内容・文字サイズ・文字の書式・初期値...

以上はあくまでも1つの例てす。「テスト観点リスト」は自由に作成して構いません。作成し、改廃して、組織ノウハウとしていきます。 その際、エンジニアのミーティングで衆知を集め、「テスト観点リスト」の完成度を高めていけば、テストはより効率的、効果的になり、品質向上に大いに役立つでしょう。

コードレビューの観点とは？やり方や便利なツールについても紹介！

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

■インターフェーステスト それぞれのプログラムやモジュールが、互いに正しく連携して動くかどうかを確認するテストです。AのプログラムからBのプログラムに正しくデータが引き渡しをされているか、といった観点で検証します。

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

■業務シナリオテスト こちらはさらに実際の業務を想定した動作確認を行うテストです。業務に則した操作が中心となるため、実際にシステムを操作、利用するユーザーに行ってもらう場合もあります。そこで重要なことは、イレギュラーな操作を必ず行うことです。たとえば、本来あり得ないような数値やデータを入力したり、エンターキーを何度も叩いたり、といったことを実施することです。

■負荷テスト 負荷テストは、システムに最大の負荷をかけた場合の動作状態を確認し、システム停止やパフォーマンス低下が起こらないかを確認するテストです。たとえば、想定する最大のアクセス数があった場合や、想定する最大のデータ量を処理した際のパフォーマンスなどを確認します。 また、結合テストは納期がタイトになると、スケジュールを圧迫することが少なくありません。テストの自動化ツールやシミュレーターソフトなどを利用することで結合テストを効率化し、その負荷をかなり軽減することができますので、ツールの活用も検討してみましょう。

システムの品質アップの鍵はテスト

システムはどんなに手を掛けて開発しても、本番で大きなトラブルを招くと、失うものも大変大きなものになります。クライアントやユーザーに多大な迷惑を及ぼすばかりか、その企業の顧客に対しても損害を与え、企業の根幹を揺るがす事態も起こり得ます。

また、システムエンジニアとしての信用が落ち、取引ができなくなるかもしれません。そこで、重要なポイントとなるのはテストやスケジュールです。納期優先で工数を短縮した結果、テストが不十分となり、本番で重大な不具合が生じるケースを避けるには、余裕のあるスケジュールと確実なテストの実施です。

多くのシステム障害の原因の大半は、イレギュラーケースを想定した結合テストや総合テストをしていないことにあります。これは不可抗力ではなくヒューマンエラーです。

エンジニアの成果は、作成したシステムの品質で決まります。品質を高めるには、高いテストスキルを持つことです。これを読まれたエンジニアの皆さんは、ぜひテストを重視するエンジニアを目指してください。