ソフトウエアテストの考え方――本質、基本を知る：現場で使うためのオールペア法、直交表の基本（1）（1/2 ページ）

手法やツールだけでなく、そもそもテストとは何か、トレードオフを適切に判断するために必要な知識は何かをじっくり考えてみましょう。

[五味弘，OKI（沖電気工業）]

連載バックナンバー

はじめに

　本連載では、ソフトウエアの品質を高めるための手法の一つである、オールペア法と直交表の基本的な考え方を紹介していきます。第一回である今回は、現在のソフトウエアテストの目的や問題点、課題を整理し、ソフトウエアテストそのものに対する考え方やツールの使いどころ、トレードオフについて整理していきます。

ソフトウエアテストの目的と問題点

　最初にソフトウエアテストそのものを振り返ってみて、テストの目的と問題点を挙げていきます。

ソフトウエアテストの目的〜品質とコスト

　ソフトウエアテストとは、対象のソフトウエアシステムの動作の妥当性を検証する一連のテストです。その究極の目的は品質を向上し、保証することです。ソフトウエアテストでは必要十分な品質を得ると同時に、効率的にテストを実施することが求められます。

　テストはやみくもにするものではありませんし、テストに掛けるコストは少な過ぎても多過ぎてもよくありません。数学のように完全性を求めるのでなく、工学としてコストと効果を考慮して、テストを実施する必要があります。テストで正当性が完全に検証できないときは、合理性のある制限を設けてテストをする必要があります。

　開発現場におけるソフトウエアテストの代表的な13個の問題点を表1に挙げました。以下では、その中からいくつかを紹介していきます。

表1　ソフトウエアテストの代表的な13個の問題点

	問題
1	要求品質とテストコストのバランス
2	テストの完了基準と網羅基準
3	テストコストとその効果の定量的計測
4	非機能要求のテスト（性能やユーザビリティなど）
5	無効値（例外処理）の取り扱い
6	発見的手法（因子や水準の抽出、探索的テスト）の方法
7	効率的なテストの実行（テストの容易性や優先順位などの見極め）
8	テストの自動化
9	テストのコストと効果の相場観（見積もり）
10	本番環境に近い環境の構築
11	テスト計画の策定
12	テスト結果の分析・品質予測
13	テスト技術者の育成

テストの問題点（1）いろいろな条件で異なる要求品質とテストコスト

　例えば、Webアプリケーションと制御系・組み込み系アプリケーションなどの分野によって、あるいは業務対象や運用方法などによっても、求められる品質が違うので、掛けるテストコストも異なるべきです。

　また、金融・保険業の業種と情報通信業、製造業など業種によって、要求される品質とテストコストも違ってきます。このように求められる品質とそれに掛けるテストコストは多種多様な条件によって異なってきます。

　このように、実施すべきテスト、適正なテストコストはどのくらいかについての判断は、要件や案件ごとに個別に検討せざるを得ません。そのため、開発現場ではテスト計画の策定が難しくなるのです。

テストの問題点（2）テストの完了基準と網羅基準

　組み合わせテスト（結合テスト）では、テスト対象となるシステムの規模にもよりますが、全ての組み合わせを網羅するのはコスト的にも、そして物理的にも難しい場合がほとんどかと思います。そこで、どこかでテストを打ち切りにするためのテストの完了基準を決めなければなりません。しかし開発現場ではスケジュールやコストだけを考慮して、この完了基準が恣意的に運用されている場合が多く、問題になっています。

　また、完了基準の一つの条件であるテストの網羅基準があいまいになっているテストを見かけます。これでは他の箇所に障害があるかどうかも分からず、テストをいつ完了したらいいかも分かりません。

テストの問題点はその他にも

　上記のような代表的な問題だけでなく、テストのコストと効果を定量的に計測していないことや非機能要求に対するテストが不十分であるという問題点などが実際の開発場面で出てきます。

　このようにテストに対するコストと効果を考える際には問題点がいろいろとあり（表1）、それを解決していく必要あります。次からは、いままでこれらの問題に対したどのような解決策が採られてきたのか、またその課題はどこにあるのかを紹介します。

これまでのソフトウエアテストと課題

　ソフトウエアテストは昔から実施され、多くの手法やツールがあります。ここではこれまでのソフトウエアテストを概観し、開発現場での実際の運用がどうだったのかを見ていきましょう。

　ソフトウエアテストには大きく分けて、（1）プログラムの中身を見るホワイトボックステストと（2）中身を見ないブラックボックステストがあります。

　次の項目以降ではホワイトボックステストとブラックボックステストの代表的な手法を紹介します。表では主要なものを取り上げ、解説ではさらにその中から代表的なものを挙げていきます。

ホワイトボックステスト

　ホワイトボックステストには次のようなものが挙げられます。

表2　代表的なホワイトボックステスト

テスト名	内容
制御パステスト	プログラムの処理経路に注目して動作確認をするテスト
データフローパステスト	データの流れに注目して動作確認をするテスト
状態遷移パス／マトリックステスト	プログラムの状態遷移に注目して動作確認をするテスト
リソースパステスト	ヒープ領域やディスク領域などのリソースに注目して動作確認をするテスト

　ホワイトボックステストでは、プログラムを“入力”として、特定の網羅基準を満たすようにテストケースを作成します。テストケースを作成するときにプログラムを見ることができますので、機械的に網羅性が検証できます。実際にテストツールによる網羅性の検証や網羅基準を満たしたテストケースの自動生成も行えます。

　網羅基準には、例えばプログラムの処理経路に注目した制御パステストではパスカバレッジ（経路組み合わせ網羅）の基準があり、この網羅基準に対応したツールもいろいろとあります。パスカバレッジで網羅基準を厳しくするとテストケースの数が膨大になるため、要求品質とコストのバランスを考慮して、テスト方針として網羅基準を設定することになります。

　実際の開発現場で問題になるのは、例外処理などのプログラムの網羅性をどのように扱うかということです。一般的に例外処理のテストにはコストが掛かりますが、プログラム障害の原因の多くもこの例外処理にあるといわれています。これを考えて、コストとテスト効果のバランスを考える必要があります。

ブラックボックステスト

　ブラックボックステストには次のようなものが挙げられます。

表3　代表的なブラックボックステスト

テスト名	内容
同値分割	入力と出力を同値分割して動作確認をするテスト
境界値分析／限界値分析	同値分割で、代表値を境界値にして動作確認をするテスト
原因結果グラフ／デシジョンテーブル	原因と結果の条件を全て書き出し、網羅性を確認して実施するテスト
機能網羅／パラメーター網羅	入力パラメーターに注目して、その組み合わせとその結果を確認するテスト
ケースフロー図	ケースフロー図を描いて、テストの網羅性を確認して実施するテスト
オールペア法／直交表	組み合わせテストをオールペア法や直交表の考えで効率よく実施するテスト
統計的操作	実際の稼働状況の統計量を元に操作パターンを作り、実施するテスト
ユースケース網羅	ユーザー操作を表現したユースケース図を元に網羅性を確認して実施するテスト
探索的テスト	直前のテスト結果に応じて、次のテストを探索的に実施するテスト

　ブラックボックステストではプログラムを見ずに仕様書やマニュアルなどのドキュメント類を“入力”として、テストケースを作成します。このテストではソフトウエア障害を効率的に発見できるテストケースを作成するために、ソフトウエアの機能やデータをどのように合理的に一つのもの（同値類）としてまとめるかが問題になります。同値分割を機械的に行うのは困難ですが、逆にいえば、これがエンジニアとしての腕の見せ所になります。

　ブラックボックステストには、この同値分割や境界値分析、デシジョンテーブル、ケースフローダイアグラム（CFD）、ユースケース網羅、オールペア法、直交表、探索的テストなどの多種多用な手法があり、これらを組み合わせてテストすることになります。

　ブラックボックステストで使われるツールは、テストケースを自動生成するものではなく、テストを管理するものや支援するものが主流です。