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

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

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

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

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

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

### 要件定義：RD（Requirements Definition）

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

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

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

### 基本設計（外部設計）：UI（User Interface）

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

### 詳細設計（内部設計）：DD（Detail Design）

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

### プログラミング：PG（Programing）

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

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

### 製造・単体テスト：M（Manufacture）、UT（Unit Test）

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

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

### 結合テスト：IT（Integration Test）or JT（Joint Test）

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

### システムテスト（総合テスト）：ST（System Test）

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

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

### 運用テスト：OT（Operation Test）

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


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

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

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

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

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

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

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

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

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

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

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

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

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

*【参照1】：[高信頼化ソフトウェアのための開発手法ガイドブック（IPA：独立行政法人 情報処理推進機構）](https://www.ipa.go.jp/files/000005144.pdf)*

*【参照2】：[ソフトウェアテスト見積りガイドブック（IPA：独立行政法人 情報処理推進機構）](https://www.ipa.go.jp/files/000005132.pdf)*

<center>[『マイナビIT AGENT』なら、 IT業界に精通した専任アドバイザーと豊富な求人で、 あなたの転職活動を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv15)</center>

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

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

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

### テスト観点リストの作成方法

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

 　　　　　　　　　　　（観点リストの例）

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

システム開発においては必ず単体テストや結合テストを行いますが、各テストは目的や観点が異なります。システムはプログラムやサブシステムの集合体であり、目的や観点に応じた正しいテストを行うことが重要です。ここでは結合テストの目的、観点などを中心に解説していきます。

ソフトウェア開発において、テストは品質を担保する上で大変重要な工程である。

結合テストには「内部結合テスト」と「外部結合テスト」の2つの観点がある。

エンジニアの成果は、作成したシステムの品質で決まるため、品質を担保するテストは確実に行うことである。

結合テストの「内部結合テスト」と「外部結合テスト」は何が違う？観点や目的も解説

*[【マイナビITエージェント】あなたの転職活動を無料でサポートいたします](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=banner&utm_campaign=acv12_2)*

## 「単体テスト」と「結合テスト」の違いとは？

開発の現場では、エラーを検知する「テスト」作業が非常に重要です。ここでは、「単体テスト」と「結合テスト」はどういったものなのかを、システム開発の工程とともに紹介します。

### どちらもシステム開発で重要な工程の1つ

システム開発を行う上で、エラーや不具合はつきものです。どんなに細かくチェックを行っても、実際動かしてみると予期しないエラーが出たり、求めている機能が使えなかったりすることは多々あります。

そこで、必要になるのが「テスト工程」です。作成したシステムを納品するまでに、顧客が求める要件が満たされているか、たとえエラーが出力されてもシステムが稼働するような作りになっているかを地道にテストしなければなりません。

そんなテスト工程のうち、よく知られているのが「単体テスト」と「結合テスト」です。**同じシステム開発において実施されるテスト工程ですが、「単体テストは機能を小さい単体でテストする」、「結合テストは複数のモジュールを組み合わせてテストする」といった違いがあります。**

それぞれのテストを行う目的やタイミングは異なりますが、どちらもシステム開発では欠かせない重要な工程の1つです。

そもそも、このシステム開発はどのような流れで行われるのでしょうか？システム開発は決められた手順通りに進めていきます。例えるなら、家を建てる過程と似ています。

一般的には、*「要件定義→外部設計→内部設計→プログラミング（構築）→単体テスト→結合テスト→システムテスト→運用テスト→システム移行」といった流れをたどります。*

なお、「インフラエンジニア」と「アプリエンジニア」ではプログラミングの有無など、多少工程は変化します。今回は「アプリのシステム開発」を基準に紹介します。

システム開発の工程とは？基本的な流れや略語の意味を解説！

要件定義とはシステム開発プロジェクトを進める前に、顧客にとって必要な機能や要件をまとめる作業のことです。プロジェクトが進んでいくとともに要件定義に立ち返ることも多く、目的をはっきりさせる工程でもあります。プロジェクトが上手くいくかは要件定義で決まると言っても過言ではありません。

要件定義書とは？仕様書との違いや書き方のポイントを解説

外部設計では要件定義で作成した内容をもとに、外見的な見た目の部分を設計していきます。ユーザーの使いやすさに影響を与える部分になるので、使いやすいシステムを作るために大切な工程になります。

内部設計では、システムの中身であるプログラミングの設計をします。外部設計はユーザー側からの視点よりでしたが、内部設計では開発者側からの視点よりで設計していきます。

内部設計でプログラミングの設計が決まったら、設計書通りプログラミングを行っていきます。ただプログラミングを行うのでなく、設計書を作成した人やテストを行う人と積極的にコミュニケーションを行うのも大切です。

プログラミングを使う仕事とは？種類別の例や向いている人の特徴

後で詳しく紹介しますが、単体テストではプログラミングの粒度（単位）ごとにテストを行っていきます。この単位はモジュールと言われることもあります。単純作業になりがちなため、より効率が求められる工程でもあります。

こちらも後で詳しく紹介しますが、結合テストは複数のモジュールを組み合わせて、正しく機能しているかを検証します。結合テストはテスト項目の洗い出しが難しい部分でもあります。

*・総合テスト（システムテスト）*

総合テストでは全ての作成したプログラムが、要件定義で作成したシステム要件通りに正しく動くかをテストする工程です。性能や機能のテストを行います。ここからは、アプリの基盤を作成したインフラエンジニアの人と協力して行っていくこともあるでしょう。

システムテストとは？その手法やシステムテストの仕事に転職するには

運用テストでは実際にシステムを運用する顧客先の環境を設定し、システムに影響や不具合がでないかをテストしていきます。これまでのテストと比較すると実用性に重きを置いたテストとなっています。

システム移行は、古いシステムから新しく開発システムへ切り替える工程です。成功するか、ハラハラする工程でもあります。

保守・運用では、システムが問題なく運用しているかチェックしたり、よりよい状態にシステムを稼働させることができないか、プログラムを修正したりします。システムは24時間365日稼働していなければならないものもあるため、常にシステムを監視する業務も含まれます。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

### システム開発のモデルの紹介

**システム開発には、さまざまな種類の開発モデルが存在します。**例えば、「ウォーターフォールモデル」、「アジャイル開発」、「プロトタイプモデル」、「スパイラルモデル」などです。ここでは、システム開発で最もよく使われる2種類のモデルを紹介します。

*・ウォーターフォールモデル*

**ウォーターフォールモデルは、要件定義や設計などの上流工程から、テスト、保守・運用などの下流工程へ、順を追って行われていくのが特徴です。**例えば、設計が完全に行われていないのに、プログラミングを行うことはありません。

スケジュール管理がしやすいので、大規模なシステム開発に適している開発手法と言えます。一方、工程でのミスが生じた場合の手戻りがある場合、時間を要してしまうのがデメリットです。

ウォーターフォール開発モデルとは？各工程やメリット・デメリットを解説！

アジャイルには「素早い、機敏な」という意味があります。アジャイル開発は文字通りスピード感のある開発手法です。**短い開発期間で単位を区切り、変更や修正を行います。**

メリットは、新しい技術開発などですぐに成果物が欲しいとき、とりあえず作ってみることができる点です。一方、スケジュール管理がしづらいのはデメリットです。

<center>[『マイナビIT AGENT』なら、 IT業界に精通した専任アドバイザーと豊富な求人で、 あなたの転職活動を丁寧にサポートします。](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

ここでは、まず「単体テスト」について詳しく紹介します。上述したように、単体テストでは、プログラミングの対象単位ごとにテストを行っていきます。具体例を詳しく説明します。

単体テストは「Unit Test（UT工程）」とも呼ばれる通り、メソッドや関数などの1つ1つの小さな単位ごとに行うテストのことです。**1つの画面や1つの機能で実施される動作をテストすることが目的となっています。**

しかし、実際にシステム開発で作るプログラムでは、画面や機能が複数存在している場合が多いです。そのため、動作の連携に関しては単体テストではなく、後で紹介する結合テストでチェックを行います。

一般的に、単体テストは条件分岐を網羅する観点からテストを行います。**理由としては、条件分岐を網羅することで、品質をある程度は確保できるからです。**

ただし、コスト、納期、品質のバランスの観点から、100％の品質を確保するテストはできないことは頭に入れておきましょう。

単体テストの手法の種類はさまざまです。代表的な手法である、「ホワイトボックステスト」と「ブラックボックステスト」を取り上げて紹介します。

**ホワイトボックステストは、プログラムが設計したとおりに動作するかを1つ1つ網羅的に確認するテストです。**つまり、「開発者側の視点」に立ったテストとも言えます。

例えば、設計書ではエラーが発生すると定義された文字列を入力し、出力結果が正常かどうかを検証します。ホワイトボックステストのメリットは、1つ1つのモジュールに対して網羅的に検証できることです。一方、デメリットは工数が増えてしまうことです。

**ブラックボックステストは、開発するシステム自体の仕様を満たしているかどうかを確認する機能のテストです。**つまり、「利用者側の視点」にたったテストと言えます。内部のプログラムについては考慮しないため、「ホワイトボックス」とは逆の「ブラックボックス」と呼ばれています。

テスト例として、設計書で0～100までの数値を正常と設定した場合、境界付近である値（例えば、0、-1など）を選んでテストします。理由としては、境界付近にプログラムの欠陥が多いためです。

ブラックボックステストのメリットは、利用者の要件を満たしていることが確認できる上に、工数を抑えることができる点です。一方で、プログラムの内部処理が適切に行われているのかわからない点はデメリットです。

### 単体テストの仕様書を作成する

単体テストを実施する際は、単体テスト仕様書と呼ばれるドキュメントを用意します。仕様書を作成する際は、「入力手順」「テスト方法」「テスト観点」などを詳しく記載しましょう。単体テストの仕様書を丁寧に作成すると、網羅的にテストを行うことが可能になり、結果的にシステムの品質を上げられます。

<center>[エンジニア転職を成功させるため ぜひ*『マイナビIT エージェント』*をご活用ください！](https://mynavi-agent.jp/it/?utm_source=and-engineer&utm_medium=content-text&utm_campaign=acv12_2)</center>

結合テストでは複数のモジュールを組み合わせて、正しく機能しているかを確認します。ここからは結合テストについて詳しく紹介します。

「結合テスト」の観点や目的を押さえ、システムの品質を担保しよう！

結合テストは「Combined Test（CT工程）」とも呼ばれており、複数のモジュールを組み合わせて行うテストのことです。**「モジュールを結合させたときに、設計したように動作するのか」「想定外の状況のエラーが出力されても、システム要件が満たされているか」といったことを検証するのが目的です。**

また、単体テストで正常を確認できたモジュール同士を組み合わせるだけでなく、その他の外部モジュールを結合したテストも行うことがあります。

**結合テストは要件定義に基づいて、機能要件や非機能要件の観点からテスト項目を洗い出します。**単体テスト同様に、コスト、納期、品質のバランスの観点からテスト項目を選定することが大切です。

単体テストと違い、結合テストではシステムの全体的なデータの流れを把握ができる技術が必要になります。1つ1つの機能にエラーがなくても、連携させると問題が発生する可能性があるためです。

**結合テストの手法としては、「インターフェーステスト」「ブラックボックステスト」の2つが代表的です。**具体的に紹介します。

インターフェースとは、モジュール同士を接続したときに、データの引き渡しを仲介する仕組みのことを指します。インターフェーステストは、結合テストの中では「定番」と言ってもいいほど一般的なもので、「連結テスト」とも呼ばれます。

インターフェーステストでは、機能間やモジュール間でデータを引き渡す際に、引き渡されるべきデータがきちんと引き渡されているか、連携に関わるモジュールが設計した通りに正常に動作しているかなどを検証します。

単体テストで説明した通り、ブラックボックステストはプログラムの内部構造を考慮しないで、入力に対して正常な出力結果を得ることができるか検証するテストです。

結合テストでは、単体テストで正常を確認できたモジュール同士を結合して、ブラックボックステストを実施することで、仕様を満たしているかどうかを確認します。

また、この2つ以外に「トップダウンテスト」と「ボトムアップテスト」があります。「トップダウンテスト」は上位モジュールを呼び出した後に、下位モジュールヘと移行してテストを進めていく方式です。「ボトムアップテスト」はプログラムの下位階層にあるモジュールから、優先的にテストを進めていく方式です。

## 単体テストと結合テストを実行するエンジニアは？

システム開発において重要な役割であるテスト工程ですが、実際の業務では誰が実施するのでしょうか？ここでは、テスト工程を担うエンジニアについて解説します。

### 基本はテストエンジニアが行う

テスト工程を行うのは「テストエンジニア」と呼ばれる業種です。**テストエンジニアはテストの実行だけでなく、テスト計画の策定、結果の分析、改善提案まで幅広い技術と知識を求められます。**

近年は品質管理やセキュリティーがさらに重要視されているため、大きな責任も伴います。また、効率向上のために「IaC」のようなテスト自動化ツールを導入する企業もあり、常に新しい知見が必要です。

テストエンジニアとは？テスターとの違い・向いている人・将来性を解説

テストエンジニアの求人の探し方と、そのポイントを解説！

「単体テスト」と「結合テスト」はシステム開発の工程の中のひとつです。テスト工程はシステム開発を行う上で、未然にシステムエラーを防ぐ大切な役割を果たしています。この記事では、「単体テスト」と「結合テスト」の位置づけと違いについて徹底解説していきます。

単体テストと結合テストはシステム開発の中の一工程

単体テストはメソッドや関数など1つ1つの小さな粒度（単位）ごとに行う

結合テストは複数のモジュールを組み合わせて行う

「単体テスト」と「結合テスト」の違いとは？やり方や観点を解説

結合テストの記事（1ページ目）