コンポーネントテスト（単体テスト、ユニットテスト）とは？実施方法や重要性をわかりやすく解説

ソフトウェア開発において、品質の担保を行ううえでテストの実施は必要不可欠です。開発フェーズによって異なるテストを実施しますが、そのテストの最初に実施するコンポーネントテストは、作成したシステムの構成要素を詳細な視点で確認します。システムの構成要素の品質が確保されなければ全体の品質にも不安を残すことになりかねません。コンポーネントテストは、その後に続くテストからの手戻りなどを防ぐためにも非常に重要なテストです。

今回は、コンポーネントテストとほかのフェーズのテストとの違い、コンポーネントテストの重要性と具体的な手法について解説します。

株式会社SHIFTでは、ソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

コンポーネントテストとは、テスト工程の最初に実施されるテストです。会社やチームによっては、単体テスト・ユニットテストと呼ばれる場合もあります。「コンポーネント」は「構成要素」「部品」などの意味をもち、ソフトウェアテストにおいては独立してテストできるソフトウェアの最小単位です。

コンポーネントテストでは、ソフトウェアの各機能や画面などのソースコード単体、もしくは少数のソースコードが組み合わされた小さな範囲で、開発者が思った通りに適切に動作するか検証します。例えばECサイトのログインページを例とした場合、ログインページには以下を代表として多くの要素から成り立っています。

・ログイン時の入力項目を規定する画面のソースコード
・ログイン画面内の部品の色や配置を指定するためのスタイルのソースコード
・ログイン画面を表示するためのプログラムのソースコード
・ログイン中かどうか判断するソースコード
・ログイン画面で入力されたIDやパスワードをデータベースで検証するソースコード
・ログインが成功したときに、次の画面に遷移するためのソースコード

このような開発者が作成したソースコードのひとつひとつが想定通りに作成されているかを確認するのがコンポーネントテストです。

コンポーネントテストを実施するうえで、課題を抱えている会社やチームも存在します。大きな理由の一つ目は、開発者がソースコードを書くことに夢中になって、テストをするというモチベーションが低くなりがちであるということです。これは開発者本人だけの問題ではなく、会社の評価基準としてソースコードを書いたことだけが評価されて、テストをすることがあまり評価されないという場合もあります。もう一つの理由は、コンポーネントテストを指導したり、結果を評価したりできる開発者が非常に少ないということです。特にソースコードの作成を外部に発注している会社やチームは自身がソースコードを書かないので、その品質について何も指導や評価ができない場合もあります。その結果、目的なくコンポーネントテストを行ってしまったり、コンポーネントテスト自体を軽視してしまったりして、不完全なテストが当たり前になってしまっている可能性もあるのです。

V字モデルにおけるコンポーネントテストは、最初に行うテストに相当します。V字モデルで表すと詳細設計と対応しており、詳細設計で開発したプログラムに不備がないかを確認するテストです。

V字モデルとは、システム開発工程をV字に並べたものです。ウォーターフォール型開発モデルを、左側に設計工程、右側にテスト工程を並べることで、設計とテストのレベル感の対応を明確にしたモデルです。

V字モデルにおけるコンポーネントテストの具体的な例として、先ほど提示したECサイトの構成要素でどのようなテストを行うかを見てみましょう。

プログラムのソースコードであれば、実際に実行して、その動作や結果を確認します。

・ソースコード内に書かれたIF文が、想定の方向に分岐しているか
・APIなどで示された復帰値が、さまざまな入力に対して正しい値を返すか

また、画面のソースコードであれば、実際に表示して、その結果を確認します。

・ソースコード内に書かれた画面の部品が、正しく表示されているか
・入力可能文字数やパスワードを「●」で表示するなどの指定が仕様書通りか 

このようなテストは非常に単純で、わざわざ工数をかけて確認しなくても大丈夫だろうと思う方がいるかもしれません。しかし、コンポーネントテストで構成要素レベルの動作を確認することは、開発者が書いたものが正しいということを保証するということになります。V字モデルは、コンポーネントテストを抜け漏れなく実施することで、全体としてのテスト工数を削減、最適化できるという考え方なのです。

V字モデルについてはこちらもご覧ください。
＞＞V字モデルとは？開発とテストの流れ、活用するメリット・注意点を解説のページへ

あわせて読みたい
＞＞ウォーターフォールモデルとは？メリット・デメリット・特徴をわかりやすく解説

V字モデルで登場した、コンポーネントテスト以外のテストには次の3つがあります。

・結合テスト
・システムテスト
・受け入れテスト

これらのテストとコンポーネントテストの違いについて見ていきましょう。

あわせて読みたい
＞＞結合テストとは？目的や観点・種類・単体テストとの違いを解説
＞＞システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説
＞＞受け入れテスト（UAT）とは？実施方法や重要性をわかりやすく解説

結合テストは、機能ごとに動作するようになった部品を組み上げてから、一連の機能が動作するかどうか確認するテストです。コンポーネントテストの後に実施されるテストレベルで、複数のシステムが相互に動作するかどうかを確認します。

ユーザー認証の一部を例にあげてみましょう。以下のように「画面⇒機能A⇒機能B」を一括りにして表示やデータの入力が仕様通りに動作するかテストを行います。

・ログイン画面で入力した文字列がサーバに送信される（画面X）
・IDやパスワードがデータベースのデータと照合され認証される（機能A）
・データベースから取得した利用者名が次の画面に連携される（機能B）

結合テストを行う目的は、インターフェースの欠陥を見つけることです。コンポーネントテストを実施した要素で正しくデータの受け渡しができていることを、システムとしての動作を通して確認します。

計算結果が正しいというようなAPIレベルで確認できることはコンポーネントテストで確認しておいて、結合テストでは画面からの入力情報がプログラムに伝わるか、プログラムで処理した結果が画面に表示されるかというところに着目してテストを行います。テスト内容としては同じように思う方もいるかもしれませんが、コンポーネントテストでは秒で結果が出て問題点がピンポイントに絞り込めるのに対して、結合テストの実行は数分を要し、さらに問題が出たときには複数の要素にまたがった分析が必要となります。コンポーネントテストを先に実行することにより、結合テストで出る問題をインターフェース関係に限定することができます。

＞＞結合テストとは？目的や観点・種類・単体テストとの違いを解説

システムテストとは、システム全体の動作や能力をチェックするテストです。機能的動作だけではなく、非機能的動作が設計書通りか否かを確認するためにも行われます。コンポーネントテストがシステムを構成する要素を個別に確認するであったのに対し、システムテストはシステム全体が本番に近い環境で動作するかを確認する点で異なります。

システムテストは、あらかじめ実務で想定されるようなシナリオを想定して実施されます。テスト内容によっては、本番と同じハードウェア環境を利用したり、本番で最大と想定される負荷やデータ量で動作させたりしながらテストを行います。

例えば、ユーザーがパスワードを忘れてしまったなどの業務上のトラブルを想定し、どのようにリカバリーできるかのテストを行ったり、実際にアクセスが集中することを想定して負荷をかけたときにシステムが耐えられるかのテストを行ったりします。

＞＞システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説

受け入れテストとは、ユーザー側の観点で行うテストです。システムの発注者側で実際のビジネスでシステムが運用できるかどうかが主要な確認点です。

もう一方で、受け入れテストは、開発者のテスト環境を発注者に引き継ぐという側面ももっています。業務に変更があればシステムにも変更が必要な場合が多いですが、前の開発者に発注するとは限らず、ほかの開発者ないし発注者の内製で変更することも考えられます。ここでコンポーネントテストの環境が整っていて、リグレッションテストが容易になっていれば、変更のリスクを大きく下げることができ、コンポーネントテストの技術力が大きく評価されることでしょう。

＞＞受け入れテスト（UAT）とは？実施方法や重要性をわかりやすく解説
＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説

コンポーネントテストは、独立した要素の単位で開発者の意図通りに動作するか、仕様に漏れがないかなどをテスト工程のはやい段階で確認でき、後のテストレベルでの手戻りをなるべく少なくするために重要です。テスト工程のなかで最初に実施するテストであるということは、その後のテストにも大きな影響を与えるテストともいいかえることができます。

もしコンポーネントテストがずさんなまま結合テストやシステムテストに進んだ際にトラブルやエラーが発見された場合、どの部分で不具合があるのかの発見と対応が難しくなってしまいます。ソフトウェアの品質を担保するためにはコンポーネントテスト抜きでは難しく、その後に続くテストの土台となる部分であると認識しましょう。

コンポーネントテストで発見された不具合は確認範囲が限定的なため、開発者がどのソースコードに問題があるか把握しやすいという特徴があります。ソフトウェアの不具合を修正するために必要となるコストを抑えることにも効果的です。コンポーネントテストを形式だけのテストで終わらせず、不具合がないか徹底してテストするようにしてください。

コンポーネントテストで一般的によく実施されるテストには、以下の6種類があります。

それぞれのテストで実施される内容を確認してみましょう。

ホワイトボックステストは、ソースコードをはじめとする、システム内の要素の記述を参照して実施するテストです。書いたものが開発者の意図通りであるかを確認します。

プログラムのソースコードの場合は、プログラム内の条件判断がすべて想定の結果通りに動いているかを確認します。ANDやORなどの複合条件があれば、必要な組み合わせをすべて確認するようにします。基本的にはすべての分岐を網羅して確認するようにします。

画面のソースコードの場合は、画面を表示したときにソースコード中に書かれた画面部品が正しく表示されることを確認します。サイズ、位置、色などに加えて、パスワードが「●」になるとかプルダウンが開くとかの画面に閉じた基本的な動作も確認します。システム構成によっては画面が単体で表示できないこともありますが、その場合は結合テストの最初に最低限画面が表示できるための要素を集めて、画面表示を確認しましょう。

ほかにも、定義ファイルなど開発者が記述するものがあります。これらについても、その定義内容が想定通りに反映されていることを確認しましょう。

ホワイトボックステストは、開発者が記述したものを開発者が意図した通りに動いていることを確認するテストで、後の工程では行われないテストです。コンポーネントテストのなかでは非常に重要な位置づけになります。

＞＞ホワイトボックステストとは？手法やメリット、ブラックボックステストとの違いを解説

ブラックボックステストは、ソースコードのなかを見るのではなく、仕様書に書かれた内容でテストをします。コンポーネントテストでは、API設計書や、画面の説明が記載された基本設計書などを基にテストをすることになります。

ホワイトボックステストでは開発者が書いたものをテストしますが、書かなかったものを見つけることには不向きです。仕様書の内容を網羅的にテストすることによって、実装が漏れていないことを確認します。

プログラムのソースコードであれば、必要な機能がすべて動作するかを確認することで、実装漏れを見つけることができます。画面であれば、仕様書に書いてある画面部品がすべて表示されているかを確認します。

ブラックボックステストは場合によっては結合テストで実施することがあるかもしれませんが、結合テストでは細かい条件まで網羅しようとすると莫大なテストケースが必要になって大きな工数がかかることが多いです。コンポーネントテストで確認できるものについては、コンポーネントテストで実施するのがおすすめです。

＞＞ブラックボックステストとは？特徴や技法、ホワイトボックステストとの違いを解説

リグレッションテストは、システムに変更が行われたときにほかの変更されていない機能に影響がないことを確認するテストです。

プログラムのソースコードは、ソースコード単品で実行できるものは稀で、ほとんどの場合対象のソースコードを呼ぶドライバというプログラムが必要になります。そのため、ドライバが整備されていれば、必要なときに何度でも自動で実行できることになります。いまのプログラミング言語ではドライバを簡単につくったり、結果を簡単に集計するフレームワークも準備されています。

テストの実行時間も非常に短く、1テストケースの実行がミリ秒単位で終わることも珍しくありません。そのため、毎晩のようにコンポーネントテストをリグレッションテストとして自動実行し、日々の修正に起因する想定外の影響を見つけるという環境を準備するプロジェクトが増えています。

リグレッションテストは長期にわたってシステムをメンテナンスするのに非常に有効な手段です。いつでもコンポーネントテストを自動実行できる環境を作成しましょう。

＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説

性能テストは、システムのレスポンスやシステムリソースの使用状況を確認するテストです。負荷状態や大量データ処理時のシステム挙動も確認します。

コンポーネントテストでは、主に無負荷状態でのデータベース処理のレスポンスを確認します。データベースへのアクセス処理は、SQLの書き方やスキーマの定義によってはレスポンスが悪くなるケースがあります。これをコンポーネントテストのレベルで検出し、必要な対策を実施しておくことで、後々の手戻りを防ぐことができます。

性能問題の対策には、いろいろな検討が必要で、時間を要することがあります。単体での性能が悪いと、後のシステムテストで負荷をかけたときに、大問題となるのは目に見えています。コンポーネントテストでレスポンスをチェックしておくことは、後から見つかる問題への対応を早期にはじめられることになります。

ユーザビリティテストは、システムの利用者が快適にシステムを使えるかどうかを確認するテストです。

コンポーネントテストでは画面は表示するところまでで、その先は動きません。まずは表示した画面が見やすいかという観点で確認を行います。

システムを使う人は健常者だけとは限りません。近年は目の不自由な人への対応も期待されることが増えています。文字の大きさをある程度大きくしたり、文字と背景のコントラストを十分に取ったり、あるいはブラウザの読み上げ機能だけで画面が理解できるか、といった確認を行います。大きなディスプレイを使えば文字が大きくなると思った方もいるかもしれませんが、大型ディスプレイは視野の範囲を超えるので使いにくいという例もあるそうです。

コンポーネントテストでユーザビリティについて確認できることは限られますが、画面の作成基準を決める意味でも、早期に、場合によっては開発をはじめる前にでも確認しておきましょう。

＞＞ユーザビリティテスト（ユーザビリティ評価）とは？基礎知識や具体的な方法まで解説

セキュリティの要件は、仕組みの検討を重ねて、実装すべき仕様に落ちていきます。コンポーネントテストではセキュリティテストという名目ではないかもしれませんが、セキュリティのために必要な仕様が問題なく実装されていることを確認しておく必要があります。

例としては、アクセス権の制御、暗号化、認証方式、問題追跡のための操作ログ、脆弱性対策などがあげられます。セキュリティのレベルについても年々強化されています。パスワードのもち方は、かつては暗号化されていればよしとされていましたが、その後非可逆なダイジェストが推奨され、現在は人によって異なるダイジェストを使う方法が推奨されるようになっています。

コンポーネントテストにおいては、セキュリティ要件が変更されて方式が変更になったときに、リグレッションテストなどの再テストが容易になるように考慮しておくのがいいでしょう。

＞＞脆弱性診断とは？診断の種類や必要な理由、やり方やツールについても解説

コンポーネントテストは、開発したソフトウェアの品質を担保するために必要な基本のテストです。V字モデルにおける4つのテストのなかでは確認する機能や範囲も限定的である分、不具合の発見や原因の特定も容易にできる場合が多いでしょう。手戻りを防ぎつつソフトウェアの品質を高めるためには、コンポーネントテストでどれだけ網羅的にテストが実行できるのかがカギになります。

コンポーネントテストを含めたテストケースの実施がむずかしい、コンポーネントテストの工数が多く対応できないなどのお悩みを抱えている場合は、ぜひ一度SHIFTまでご相談ください。SHIFTでは、ソフトウェアテスト・品質保証サービスを提供しており、どんな品質課題にも対応できるソリューションを提供できます。

豊富な実績に加え、徹底的な効率化や可視化も行っており、テスト実施に不安のある方のサポート体制が整っています。自社ではテストができない、テストを行う対象が多いなどでお困りの方はぜひ一度SHIFまでお問い合わせください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。

そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。

＼おすすめの資料／　※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に ＜理由＆メリット＞
・ソフトウェアテストを外注すべき5つの理由とは！？
・サービス導入事例集

これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。

ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。

ご相談はこちらから。
＞＞お問い合わせ
＞＞料金について

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座