■PM Tools A to Z_No.38
　　ソフトウェア・テスト（１）

筆者がこれまでレビューを担当してきたプロジェクトにおいて、開発ソフトウェアの品質が問題になった際にその原因を分析してみると、ある工程で検出されるべきバグがそれより後工程で発見されたために、デグレードなどへの対処が不十分になってしまっていたことが少なからずあります。特に単体テストでは、多くがプログラムを作成した当人がそのテストも実施しており、第三者のレビューが事前にも事後にも十分に行われていないケースがあります。このようなプロジェクトでは、単体テストレベルにおけるソフトウェアの品質は、多分に個々のプログラマに依存してしまいます。
今回から数回にわたり、ソフトウェア品質を確保するためのテストについて考えます。
なお、ソフトウェア・テストは、PMBOK(R)ではプロジェクト品質マネジメント知識エリアの品質管理プロセスの一部になります。

１．ソフトウェア・テストの種類

	始めにソフトウェア・テストの種類（例）を挙げておきます。なお、テストの名称は典型的と思われるものを使用しました。 　 ・単体テスト
		モジュール仕様やプログラム仕様をベースに、モジュールやプログラムのロジックに着目して行われるテスト。
	・結合テスト
		モジュール、プログラム、サブシステムなどの間のインタフェースを検証するためのテスト。単体テスト済みのモジュールやプログラムを結合してテストを行う。最上位のモジュール／プログラムから結合テストを行う場合をトップダウン・テスト、最下位のモジュール／プログラムから行う場合をボトムアップ・テストという。
	・システムテスト
		システムの全機能が、システム設計書の要件通りに動作することを確認するためのテスト。機能仕様書をベースにテストケースを設定する機能テストや、システム性能が機能仕様書通りかどうかを確認する総合テストを行う。
	・検収テスト
		システムの全機能が、機能仕様書の要件通りに動作することを保証するためのテスト。通常、発注者側が主体となって実施される。

２．テストデータ選定の観点からのテストの分類

	テストをテストデータ選定の観点から分類すると、次の２種類があります。 　 ・ホワイトボックス・テスト（構造テスト）
		プログラムの実行パスや内部仕様にしたがってテストデータを選定する。プログラムのすべてのステートメント（命令）、分岐、条件の組合せを網羅的にテストする。これは単体テストで行うことが多い。
	・ブラックボックス・テスト（機能テスト）
		プログラムの外部仕様にしたがってテストデータを選定する。実際に入力される可能性のあるデータの組合せを想定して、プログラムの機能をすべてテストする。通常、結合テスト以降で実施される。

３．カバレージ

	ホワイトボックス・テストでは、テストケース（テストデータの組合せ）がどの程度プログラムの内部構造をカバーしているかを示すカバレージ指標が定められます。 カバレージとは、テストがどの程度の網羅性を持つかを示す尺度です。例えば、単体テストでは、プログラムの分岐やパスを網羅している程度を示します。 以下によく使われるカバレージ指標を掲げます。 カバレージ指標（例）： 　 ・Ｃ０（命令網羅）指標
		プログラム中の全ステートメントが、少なくとも１度は実行されるようなテストデータを選定する。次図の場合、ａ→ｃのパスを通過するようにテストデータを選定すればよく、ａ→ｂのパスを通過するテストはしなくてよい。一般的に網羅基準としては弱いとされている。
	・Ｃ１（判定条件網羅）指標
		プログラム中の判定条件が真偽いずれの結果も持つように、すべての分岐命令が少なくとも１度は実行されるようなテストデータを選定する。 次図の場合、判定条件がYesとNoの両方の場合を確認できるように、２つのテストデータを選定すればよい。したがって、分岐命令の結果がYesとなる場合では、「A、Bとも真」、「Aが真でBが偽」、「Aが偽でBが真」の３ケースのうちの１ケースが選定されていればよく、網羅基準としては、C0よりは勝るが、まだ十分とはいえない。
	なお、カバレージ指標は上記を含め、C1p（判定条件が複合文の場合、それを単一文に分割した形でC1レベルのテストを行う）など１０種類程定義されています。

本日の授業の終わりにあたり、ソフトウェア・テストとデバッグの違いを挙げておきますと、ソフトウェア・テストとは「対象ソフトウェアのエラーを発見するまでの行為」であり、デバッグは「その発見されたエラーを修正する作業」となります。

参考文献：

（１）ソフトウェアのテスト技法　玉井哲雄　他著　共立出版 （２）ソフトウェア品質ガイドブック　森口繁一編　日本規格協会