最終更新日: 2024年2月19日

ソフトウェアテストの分類方法

一口にソフトウェアテストと言っても、様々な種類があるのはご存じでしたでしょうか? これらソフトウェアテストは「工程」「品質」「実行方法」「技法」という4つの方法で分類されます。

工程による分類単体テスト
結合テスト
システムテスト
受け入れテスト
品質による分類機能テスト
性能テスト
負荷テスト
ユーザビリティテスト
セキュリティテスト
実行方法による分類動的テスト
静的テスト
技法による分類ブラックボックステスト
ホワイトボックステスト

まず「工程」とは、ソフトウェア開発の工程(要求分析→基本設計→機能設計→詳細設計→コーディング)に応じた各テストの分類方法です。ソフトウェア開発の工程にあわせ、この分類のテストを段階的に実施します。

次に「品質」とは、「どのような品質をテストするか」といった視点による分類です。たとえば機能をテストするのか、使いやすさ(ユーザビリティ)をテストするか、セキュリティをテストするかなどの視点で分類されます。

「実行方法」とは、名前の通り「テストをどのように行うか」という実行方法による分類です。実際にプログラムを動かして行う「動的テスト」と、プログラムを動かさずコードのレビュー等で行う「静的テスト」があります。

最後の「技法」とは、「テストケース」を作る技法に関する分類です。テストケースとは、テストの具体的な内容(実行する際の条件や期待される結果など)をまとめた項目を指します。実際のテストでは、たくさんのテストケースがリストアップされるわけです。

この記事では、これら4つの分類の中でも工程に着目し、実際にどんなテストの種類があるかみていきます。

ソフトウェアテストのV字モデル

V字モデル
工程の分類に入る各テストの詳細についてみる前に、これらテストに深い関連のあるV字モデルについて紹介します。このモデルをみることによって、工程に分類されるテストが開発の工程とどのように対応するかが、よくわかるからです。

V字モデルとは、ソフトウェアの開発工程とテスト工程の流れと、それぞれの対応関係をV字型の図で表したものです。ご覧のようにV字型の左部分には、開発に関する工程が左上から右下へ(要求分析からはじまりコーディングまで)すすむかたちで示されています。

コーディングまで完了すると、コーディングから図の右側・右上にすすんでいくテストの工程へと移っていきます。開発の各工程で決定・設計された内容が正しく実現されているかが、表に示したようにそれぞれの段階に対応したテストによって確認されるわけです。

V字モデルの問題点

V字モデルでは、各工程が完璧に終了していることを前提として次の段階へすすみます。しかし、あとから前の工程での問題が見つかると、その工程に戻って改めてやり直さなくてはなりません。

たとえば詳細設計の段階で要求分析に問題があったことが判明した場合は、要求分析に戻って、該当箇所に関連する基本設計→機能設計→詳細設計とやり直すことになるわけです。より上位の工程で問題が見つかるほど、負担が大きくなります。

工程ごとのテストの種類

それでは、「工程」の分類に関わる各テストの内容をみていきましょう。
まず、図にするとこうなります。

工程によるテストの分類の図

単体テスト

システムの他の部分と切り離して、個々のプログラム(コンポーネント・モジュール)が動作するかを名前の通り「単体」でチェックするテストのことです。ユニットテスト・コンポーネントテストなどと呼ばれることもあります。なお単体テストにおいては、プログラム・コンポーネント・モジュールの何がテスト対象になるかはプロジェクトによって異なります。

【関連記事】単体テストとは何か?をわかりやすく解説します

結合テスト

単体テストでチェックしたプログラム(コンポーネント・モジュール)を組み合わせたときに、正常に動作するかを試すテストのことです。少数のプログラムの組み合わせからのテストからはじめ、徐々に統合する範囲を広げていきます。「統合テスト」とよばれることもあります。

なお、効率をあげるために最初から結合の範囲を広げてテストを行う場合がありますが、賢明とは言えません。不具合が確認された際に、どのプログラム(コンポーネント・モジュール)に原因があるのか絞り込みが難しくなるためです。

システムテスト

これまではプログラムを個々もしくは部分的にテストしてきましたが、システムテストではプログラム全体をテストし、基本設計でまとめられた仕様通りに動作するかをチェックします。

なお、統合テストまではテストするのに適した「テスト環境」にてテストを実施することが多いと想定されます。しかしシステムテストでは、できるだけ本番と同じ環境でテストを実施することが必要です。テスト環境では起こりえないような、環境に依存した問題が確認される可能性があるためです。

受け入れテスト

ソフトウェア開発の最初に行われる「要求定義」にまとめられた要求を満たせているかを確認するためのテストです。受け入れテストの目的は、不具合を見つけることではありません。

また受け入れテストはソフトウェアリリース直前に行われることが多いですが、それだけではありません。たとえばシステムがビジネスで利用できるかをユーザ自身で確認する「ユーザ受け入れテスト」、実際のシステム運用に耐えられるかをシステム管理者が確認する「運用受け入れテスト」などがあります。

まとめ

ソフトウェアテストは、「工程・品質・実行方法・技法」という4つの方法で分類されます。その中でも「工程」に分類されるソフトウェアテストは、開発からテストまでの流れを示すV字モデルにおいて、開発の各工程と関連付けて考えられるものです。具体的には、個々のプログラムをテストする「単体テスト」、複数のプログラムをつなげてテストする「結合テスト」、ソフトウェア内のプログラム全体をテストする「システムテスト」、要求定義の内容を満たしているかチェックする最終テスト「受け入れテスト」があります。