目次
ソフトウェア開発において、テストは品質を担保する上でも重要な工程です。品質に問題はないか、当初作成した要件定義通りになっているかを確認しなければなりません。ソフトウェアテストは確認対象の粒度によって以下の4つの段階(レベル)に分けることができます。
・コンポーネントテスト(単体テスト、ユニットテスト)
・結合テスト
・システムテスト
・受け入れテスト
本記事では「結合テスト」に焦点を当て、その概要と目的、種類や実施方法について解説します。
株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流~下流(テスト計画・テスト設計・テスト実行・テスト品質管理)まで一気通貫でご依頼いただけます。
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
>>ソフトウェアテスト・第三者検証のページへ
>>導入事例ページへ
>>料金についてページへ
>>お問い合わせページへ
結合テストとは
結合テストは、コンポーネントテスト(単体、ユニット)以降に実施されるテストです。さまざまな観点のテストの目的(テストタイプ)で実施できることから、プロジェクトの中盤から終盤にかけて長い期間で実施されます。
結合テストでは、単体で動作するようになったコンポーネントやシステムを組み合わせることで実際の動作に近い状態でソフトウェアの挙動を確認します。具体的には、データの受け渡しが正常に行われるか、データを渡すタイミングは適切かどうかなどを検証する項目です。
ユーザー認証の一部を例にあげてご説明します。
・入力フォームが表示される(画面X)
・パスワードが伏せ字で表示される(機能A)
・パスワードが一致した場合認証に成功する(機能B)
このように「画面⇒機能A⇒機能B」を一括りにして表示やデータの入力などが、 仕様通りに動作するかのテストを行います。
どのような画面と機能を一括りにしてテストを実施するかは、企業やチームによって変わります。
ソフトウェアテストの目的、役割といった基礎知識を学びたい方におすすめの動画はこちら
>>「ソフトウェアテスト入門動画」のページへ
結合テストとコンポーネント(単体、ユニット)テストの違い
結合テストとコンポーネントテストでは、テストの対象範囲が異なります。コンポーネントテストは、システムの最小単位であるプログラムやモジュール単体をテスト対象とするのに対し、結合テストでは、コンポーネントテストをクリアしたモジュールとモジュールをつなぎまとまった範囲をテスト対象とします。そのため、コンポーネントテストはその機能に焦点を当ててテストを行い、結合テストでは全体のデータの流れに焦点を当ててテストを行います。
コンポーネントテストに関してはこちらもご覧ください。
>>コンポーネント(単体、ユニット)テストとは?手法などを例で紹介のページへ
結合テストの目的
結合テストの目的について確認しましょう。
JSTQB(Japan Software Testing Qualifications Board)では、以下の5つを結合テストの目的として定めています。
・リスクの軽減
・インターフェースの機能的/非機能的振る舞いが設計および仕様通りであることの検証
・インターフェース品質に対する信頼の積み上げ
・欠陥の検出(インターフェース自体、コンポーネントに内在、またはシステムに内在)
・欠陥がより高いテストレベルまで見逃されることの防止
(参照:JSTQB『テスト技術者資格制度Foundation LevelシラバスVersion 2018V3.1.J03』)
結合テストでは、コンポーネントやシステム間の相互処理に焦点を当て、上記を目的に実施します。
結合テストに必要な観点
結合テストに必要な観点は次のとおりです。
・モジュール間のインターフェースの確認
モジュール間のインターフェースが正しく動作していることを確認する必要があります。インターフェースの正しさとは、モジュールが正しいデータ形式でデータをやり取りし、正しい処理を実行していることです。
・期待される結果の確認
モジュール間の相互作用によって得られる結果が、期待される結果と一致していることを確認する必要があります。期待される結果とは、仕様書に定められた結果または、ユーザーが期待する結果です。
・データの確認
さまざまな種類のデータを入力して、モジュール間の相互作用をテストする必要があります。データには、正しいデータ、不正なデータ、境界値データなどがあります。
・エラーの発生可能性の確認
モジュール間の相互作用によってエラーが発生する可能性を検討する必要があります。エラーの発生可能性が高い場合は、重点的にテストする必要があります。
V字モデルにおける結合テスト
V字モデルにおいて、結合テストは基本設計と対になります。
例えば、基本設計の段階で「画面遷移」にまで言及されている場合、結合テストでは画面遷移に関してまで検証を行います。
V字モデルとは
ソフトウェアの品質を保つためには、各開発工程に対して行うテストを明確にしておかなければなりません。V字モデルを参考にできるプロジェクトであれば、漏れなどを減らすことができます。
V字モデルとは、開発の上流工程とテスト工程を対に並べたモデルです。上流工程ですり合わせた粒度を流用できるため、共通の認識が得やすくなります。
V字モデルについてはこちらもご覧ください。
>>V字モデルとは?開発とテストの流れ、活用するメリット・注意点を解説のページへ
結合テストが重要となる理由
結合テストが重要となる理由は、結合テストで考慮することが、「システムテスト」「受け入れテスト」の2つのテストレベルにも影響し、テスト実施の工数や品質に大きな影響を与えることです。
開発者にとって、結合テストで得られたフィードバックは具体的で確認範囲が比較的小さく、不具合が発生している箇所の特定が容易になるケースが多くあります。一方、「システムテスト」「受け入れテスト」で得られるフィードバックは抽象的であることが多いため、不具合箇所の特定に時間を要するケースもあるでしょう。
このことから、なるべく結合テストの段階で不具合を検出する必要があります。
なお、結合テストはコンポーネントテストを経て独立した機能を組み合わせていく、最初のテストです。テストの対象やテストの目的、インプットする情報などが多岐に渡るため、ほかのテストレベルと比較して一層事前のテスト計画が重要になります。
▼あわせて読みたい▼
>>テスト計画とは?目的や種類・作り方・注意点をわかりやすく解説のページへ
また、結合テストは、「機能を組み合わせて行う」という性質上、テストの粒度が人によってばらつきやすくなります。そのため、テストを実施する前にチーム内で粒度の認識を合わせておかなければなりません。
結合テストの実施方法
結合テストでは、さまざまな目的でテストを実施できます。ここではテストタイプ別に結合テストを実際に実施する例を紹介します。
テストタイプとは、テストで確認したい目的別に分類したものです。一般的には以下の6つに分類されます。
・疎通テスト
・機能テスト
・性能テスト
・回帰テスト
・セキュリティテスト
・ユーザビリティテスト
結合テストでは、基本的にはどのテストタイプにおいても行うことが理想的です。しかし、実際にはプロジェクトによって優先度が変わります。
なかでも「疎通テスト」「機能テスト」に関しては、これらを行っていないと結合テストの次のテストレベルを行う際に、不具合が多く発生する可能性があるため特に重要になります。また、反対に「ユーザビリティテスト」はその性質上、結合テストのなかで行うには向いていないこともあります。
これらをふまえて、それぞれのテストタイプを確認してみましょう。
疎通テストとは
疎通テストは、アプリケーションの観点とネットワークの観点で使用される言葉です。アプリケーションの観点では、アプリケーション同士をつないだ際に正常に動作するかを確認します。ネットワークの観点では、システム間でネットワークを通じてデータの行き来ができるかを確認する場合に使用されます。
結合テストにおける疎通テストの実施方法
疎通テストでは、モジュール間をつないだ際に動作するか、データの行き来ができるかを確認します。つまり、結合テストを実施するにあたって問題が無いかをテストします。
機能テストを実施するに先立って、疎通テストですべてのモジュールが一部でも実行できることを確認することで、結合テストの初期に発生しやすいモジュール接続の問題を除去し、機能テストがはじまってからの手戻りを防ぎます。
機能テストとは
ソフトウェアの機能が、上流工程やプロダクトマネージャーが決めた仕様通りに動作するか検証するテストです。
機能テストについてはこちらもご覧ください。
>>機能テストとは?非機能テストとの違いや種類、実施手順を解説のページへ
結合テストにおける機能テストの実施方法
ここでのテスト対象となるのは、例えばECサイトにおいては「会員登録ができること」「商品購入ができること」「問い合わせを送ったら返信メールが返ってくること」などの機能です。
ここのECサイトでは問い合わせを送った際、外部のメールシステムに連携され返信メールが返ってくると想定します。
メールを送信するシステムに未接続(環境未対応)の場合は、この処理をモック(Mock:代替処理でインターフェースを確認するもの)に置き換えることで、実際のメールを送信することなく、メールを送信するために必要なリクエストやその先の処理を行うレスポンスが得られているかを確認することができます。
モックを利用する際は、どの部分までがモックなのかを記録しておくことが重要です。
このようなテストを結合テストで行っておくと、次のテストレベルであるシステムテストや受け入れテストで不具合が多く見つかり手戻りが増える可能性を削減できます。
このことから、「疎通テスト」「機能テスト」の2つは、結合テスト内では特に重要なテストタイプであるといえます。
性能テストとは
実際のユーザーの利用に耐えられるかどうか検証を行います。
結合テストにおける性能テストの実施方法
結合テストでは、単体で性能を確認しておくことが重要です。レスポンスが想定した時間内に返ってくるかなどを確認します。システムテストで負荷テストを行うので、結合テストでは性能確認は不要、と誤解される方もいますが、そもそも単体テストで所定のレスポンスが出なければ、負荷時はそれよりもレスポンスが悪くなってしまいます。そのため、結合テストの段階で、単体での性能確認をして、問題があれば修正しておくことは非常に重要です。
性能テストについてはこちらもご覧ください。
>>性能テストとは?実施する目的や種類、重要な指標について解説のページへ
関連サービスについて
回帰テスト(リグレッションテスト)とは
回帰テストは、リグレッションテストや退行テストとも呼ばれます。
システムが複雑になってくると変更を行った場所とは別のところに影響が出るケースもあります。その時にシステムの改修を行っていない部分に不具合(リグレッション)が発生しないか検証するテストです。
リグレッションテストに関してはこちらもご覧ください。
>>リグレッションテスト(回帰テスト)とは?目的や自動化のメリットを解説のページへ
結合テストにおける回帰テストの実施方法
理想は変更があった箇所を含め全体的に仕様に基づいた挙動をするか実行する方法ですが、現実的ではありません。そのため、ある程度影響が出そうな範囲を絞ってテストを実施します。
ユーザー認証の部分を変更した場合、ユーザー情報のシステム内でのもち方に影響が出る可能性があるかもしれません。すでにログインしているユーザーの挙動がどうなるかなどを確認します。
セキュリティテストとは
悪意のあるユーザーにシステムが攻撃されても大丈夫かどうか、検証を行うテストです。パラメータに対して、攻撃コードを入れて実行します。セキュリティテストは、必ず本番で使用するデータから切り離された環境で行ってください。
セキュリティテストについてはこちらもご覧ください。
>>脆弱性診断とは?診断の種類や必要な理由、やり方やツールについても解説のページへ
>>ペネトレーションテストとは?脆弱性診断との違いやメリット・注意点、手法について解説のページへ
>>脆弱性診断とペネトレーションテストの違いとは?自社に必要なのはどちらか、選び方を解説のページへ
結合テストにおけるセキュリティテストの実施方法
Web画面で入力された情報がそのままSQLやJavaScriptとして実行された場合に、想定と異なる動きになるサイバー攻撃が知られています。これを防ぐためには、すべてのリクエストで、不正な入力があっても対処できていることを確認する必要があります。
関連サービスについて
ユーザビリティテスト
ソフトウェアで実際に業務を行ったり、シナリオを想定してユーザーの操作感や使用感などを検証したりすることが、ユーザビリティテストです。
結合テストにおけるユーザビリティテストについて
結合テストはさまざまな目的で実施することが可能です。
結合テストにおけるユーザビリティテストでは、実際の操作感や使用感などを検証するには不向きですが、画面標準に従っているか、画面部品が想定通りにうごいているかといった視点から確認を行います。
ユーザビリティテストについてはこちらもご覧ください。
>>ユーザビリティテスト(ユーザビリティ評価)とは?基礎知識や具体的な方法まで解説のページへ
関連サービスについて
結合テストを実施する際のポイント
結合テストを実施する際のポイントとして以下の3点があげられます。
・狭い範囲から広い範囲に広げるようにテストを計画する
・重要な機能から先にテストする
・組み合わせテストの絞り込みを計画する
いずれもシステムやソフトウェアの品質を高めるために必要となります。それぞれどのようなことに注意すべきなのかを確認しましょう。
狭い範囲から広い範囲に広げるようにテストを計画する
どこからどのような順番でテストを実施するか、テスト計画がポイントの1つです。
関係するモジュールや画面が少ない狭い範囲でテストをして不具合を見つければ、容易に問題にたどり着くことができます。最初から関係するモジュールが多岐にわたるようなテストを実施して不具合が出れば、該当の問題を探すのは容易ではありません。先に狭い範囲をテストしてから、広い範囲のテストをすると、ある程度問題が除去された後なので検出される不具合は限定的になります。そのため、狭い範囲から徐々に範囲を広げていくようにテストを計画すると効率よくテストをすることができます。
テスト対象の概要や構成を良く理解した上で、効率的にテストが実施できるテスト計画を立案しましょう。
重要な機能から先にテストする
2つ目のポイントは、重要な機能から先にテストすることです。システム開発は期限・予算がある上で行われます。その中で効率的・効果的にテストを実施するに当たっては、そのシステムの核となる機能から順にテストすることが重要です。このような機能はほかに与える影響も大きいため、まずは重要な機能からテストを実施しましょう。
組み合わせテストの絞り込みを計画する
3つ目のポイントは、組み合わせてテストの絞り込みを計画することです。組み合わせテストを網羅しようとすると莫大なテストケースになりがちです。すべてを実施することは非現実的なことも多いため、目標のテストケース数を定め、それに合わせて直交表やオールペア法などの技法を活用してテストケースを絞り込むことがポイントです。
そのほかのテストレベル
改めて結合テスト以外のテストレベルでテストしたい領域を確認してみましょう。
コンポーネントテスト(単体テスト、ユニットテスト)とは
コンポーネントテストは、機能ごとに独立したプログラムを単体でテストする段階です。プロジェクトによっては、単体テストやユニットテストといわれているケースもあります。
ソースコードA、クラスB、画面Cのように各パーツが正常に動作するかを検証します。
システムテストとは
システムテストは、最初に定義した業務要件に合致しているかと確認する開発側の最終テストです。
システム構築後、実際にシステムを使用する状況と同様の環境で、システムが業務要件に合っているか、想定通りのユーザビリティや性能を満たしているかを確認します。
システムテストについてはこちらもご覧ください。
>>システムテスト(総合テスト)とは?その目的・観点・種類、実務で使える手順について解説のページへ
受け入れテストとは
受け入れテストは、ユーザー側の観点で行うテストです。システムの発注者側で実際のビジネスでシステムが運用できるかどうかを確認します。仕様書通りの開発であっても、実際に業務を行う環境で使用できなければ意味がありません。実際の業務環境においてシステムが意図通りに動作するかを検証します。
受け入れテストについてはこちらもご覧ください。
>>受け入れテスト(UAT)とは?実施方法や重要性をわかりやすく解説のページへ
まとめ
結合テストは、ソフトウェアテストの中でも重要な位置を占めます。のちに続く工程に影響を与えやすいため、発見した不具合は修正しておかなければなりません。
SHIFTでは、ソフトウェアテストに力を入れています。開発も上流工程から納品まで対応可能ですが、ソフトウェアテストのみのご依頼も受け付けています。第三者検証のプロ集団として、ロジカルで無駄のないソフトウェアテストが可能です。
ソフトウェア開発にかかるあらゆる質問や課題を解決できる実績と経験が、SHIFTにはあります。システム・ソフトウェア開発にお困りなら、ぜひSHIFTまでご相談ください。
>>ソフトウェアテスト・第三者検証のページへ
>>導入事例ページへ
>>料金についてページへ
>>お問い合わせページへ
ソフトウェアテストの悩みはSHIFTが解決できます!
「自社で効率よくソフトウェアテストを実施できない…。」
「どうしてもテスト工数が膨らんでしまう…。」
「期日に間に合わない…。」
「リリース後に不具合が発生してしまっている…。」
といった悩みを抱えている企業は多いでしょう。
質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。
そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。
\おすすめの資料/ ※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に <理由&メリット>
・ソフトウェアテストを外注すべき5つの理由とは!?
・サービス導入事例集
これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。
ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。
監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――