ソフトウェアテスト
ソフトウェアテスト(software test)とは、コンピュータのプログラムを実行し、正しく動作するかどうか確認する作業のことである。ソフトウェアテストは、プログラム中の欠陥(バグ)をできる限り多く発見することを目標として行われる。ソフトウェアテストに成功するとは、欠陥を発見することである。ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。
目次 |
ホワイトボックステストとブラックボックステスト[編集]
プログラムの構造に注目したテストをホワイトボックステスト(white box test)、プログラムの入力と出力に注目したテストをブラックボックステスト(black box test)という。
ホワイトボックステスト[編集]
ホワイトボックステストとは、プログラムの構造に着目したソフトウェアテストのことである。着目する構造には命令や分岐などがあり、注目した構造に対してどれだけの割合の部分を実行できたかを網羅率で表す。
1: int abs(int x){
2: if(x<0){
3: x=-x;
4: }
5: return x;
6: }
命令網羅(C0)[編集]
命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい。上記のabs関数では、x = -1 を用いてテストすれば命令網羅基準に従ってテストできたことになる。
分岐網羅(C1)[編集]
判定条件網羅とも。分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい。上記のabs関数では、x=-1、x=0を用いてそれぞれテストすれば、分岐網羅基準にしたがってテストできたことになる。
条件網羅(C2)[編集]
条件網羅基準を用いてテストを行う場合は、複数条件で起こりうる真・偽と分岐の組み合わせ経路を実行すればよい。
ブラックボックステスト[編集]
ブラックボックステストでは、プログラムの入出力だけに注目し仕様通りにプログラムが動作するか(もしくは仕様通りに動作しないか)をテストする。プログラムの入力が単一の値である場合は同値分割や限界値分析を、プログラムの入力が複数あり相互に影響を与えるような場合はディシジョンテーブルや原因結果グラフなどを用いて入力を決定する。
同値分割[編集]
入力を同じように扱えるグループに値を分けたものを同値クラスと呼び、それぞれの代表的な値を用いてテストを行う。 有効な同値クラスを、有効同値クラス、無効(エラー)となる同値クラスを無効同値クラスと呼ぶ。
限界値分析(境界値分析)[編集]
入力を同じように扱えるグループに値を分け、その境界となる値を用いてテストを行う。プログラムのエラーは分岐の境界で発生する場合が多いため、限界値分析に基づいたテストを行うことで、同値分割に基づいたテストよりも多くの欠陥を発見することができる。
同値分割と限界値分析の適用例[編集]
例えば、次のようなプログラムがあったとする。
- 入力: 時刻 (0:00-23:59)
- 出力: 10:00≦入力≦20:00であれば通常料金、それ以外であれば割増料金
通常料金の同値クラスは10:00以上20:00以下。 割増料金の同値クラスは0:00以上10:00未満と20:00を超え23:59以下。 無効同値クラスは0:00未満と23:59より大きい場合となる。 0:00 10:00 20:00 23:59 ーーー-○●--------○●---------●○--------●○--- 無効同値 同値クラス 同値クラス 同値クラス 無効同値 クラス (割増料金) (通常料金) (割増料金) クラス (エラー) <------------有効同値クラス----------> (エラー) ●:端を含む ○:端を含まない
同値分割ではそれぞれの範囲から代表的な値を入力として選びテストを行う。
- 入力例)-1:00、8:00、12:00、22:00、25:00
限界値分析では、入力の範囲を想定される出力ごとに分割し、それぞれの範囲の境界を入力として選びテストを行う。
- 入力例)-0:01、0:00、9:59、10:00、20:00、20:01、23:59、24:00
ディシジョンテーブル[編集]
ディシジョンテーブルとは、入力が複数のパラメータから構成されている場合に、 入力と出力の関係を表形式で表したものである。 表の各列がテストケースを表している。
| テストケース | 1 | 2 | 3 | 4 | |
| 入力 | 平日である | ○ | ○ | × | × |
| 午前10時から午後8時 | ○ | × | ○ | × | |
| 出力 | 通常料金 | ○ | |||
| 割増料金 | ○ | ○ | ○ | ||
原因結果グラフ(因果グラフ)[編集]
単体テストと結合テスト[編集]
全体が完成してからテストをすることをビッグバンテストという。規模の小さなプログラムであれば、この手法でうまくいく場合もあるが、この手法は大規模なプログラムに対して適当でない。なぜなら、大規模なプログラムを一気にテストをして問題が発生したときに、問題の原因を巨大なプログラム中から探すのが困難だからである。また、ソフトウェア中に複数のバグが存在する場合、それらのバグが相互に影響しあい、バグの原因の特定がさらに困難になる場合もある。そのため、ソフトウェアテストでは、最初に単体テストによってモジュール単位のテストを行う。単体テストの問題で、十分にモジュール単位のテストが終わったら、結合テストに進む。また、小規模なプログラムであっても、単体テストを行わずに結合テストへ入るのはテスト全体の効率を下げる為、現場でビッグバンテストを行うケースはまず無い。
単体テスト[編集]
詳細は「単体テスト」を参照
単体テスト、あるいはユニットテストとは、メソッドなどの小さな単位で行うテストのことである。単体テストは、ホワイトボックステストを利用して行われる場合が多い。「Unit Testing」の略である「UT」と呼ばれることが多い。また、開発現場によっては「CT(和製:Coding Test)」や「PT(和製:Program Test)」と略されることもある。
単体テストのツールとしてテスティングフレームワークJUnitが有名である。これはJava専用だが、他の言語にも同様のものがあり、それらは総称してxUnitと呼ばれている。
結合テスト(Integration Testing)[編集]
結合テストとは、単体テストでテストが完了したプログラムを組み合わせて行うテストである。プログラムのどの部分から組み合わせていくかで、トップダウンテスト(top down test)とボトムアップテスト(bottom up test)に分けることができる。「Integration Testing」の略である「IT」と呼ばれることが多い。また、統合テストと呼ばれる場合もある。
トップダウンテスト[編集]
結合テストにおける手法の一つ。単体テストが完了したモジュールのうち、上位モジュールから順に結合させてテストを行なう。この手法の利点は、仕様的な振る舞いを決定する上位モジュールを早期に検証することによって、機能漏れ、仕様の認識違いなどの致命的な不具合を、開発の早い段階で発見できることにある。一方で、数の多い下位モジュールの検証が先送りされるため、開発と平行してテストを進めにくいという欠点もある。
- トップダウンテストを行う際には「スタブ」を用意しなければならない。
ボトムアップテスト[編集]
結合テストにおける手法の一つ。トップダウンテストとは逆に、単体テストが完了した下位モジュールから順に結合させてテストを行なう。この手法の利点は、数が多く独立性の高い下位モジュールから順に検証することで、開発とテストを平行して実施できることにある。一方で、システムの根幹となる上位モジュールで不具合が発見された場合、テストが完了したはずの下位モジュールも影響を受けるという欠点も持っている。
テストドライバとテストスタブ[編集]
単体テストや結合テストを行う際に、テスト対象のプログラムを呼び出すためのプログラムや、テスト対象のプログラムが利用しているプログラムがまだ使えない(もしくは、テストが完了していないため使うべきでない)場合がある。このような場合に、テスト対象のプログラムを呼び出すためのプログラムをテストドライバ(test driver)、テスト対象のプログラムが利用しているプログラムの代替となるプログラムをテストスタブ(test stub)という。
int isCompositeNumber(int x) {
return !isPrimeNumber(x);
}
上記のプログラムは、与えられた値が合成数かどうかを判定するプログラムである。このプログラムをテストするために必要なテストドライバとテストスタブの例を示す。
テストドライバ[編集]
int main() {
int num;
for (num = 2; num <= 10; num++) {
if (isCompositeNumber(num)) {
printf("%d is a composite number", num);
} else {
printf("%d is not a composite number", num);
}
}
}
テストスタブ[編集]
int isPrimeNumber(int num) {
return (num == 2) || (num == 3) || (num == 5) || (num == 7);
}
このテストスタブは与えられた値が素数かどうかを判定するプログラムとしては明らかに不完全であるが、テストドライバから実行される範囲においては確実に正しい挙動を示すので、これで十分である。
統計的手法[編集]
冒頭で述べたように、ソフトウェアテストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。そこで、いつソフトウェアテストを終了すればよいかを決定するための基準として信頼度成長曲線等が利用される場合がある。
システムテスト[編集]
プログラムを単独ではなく、他のプログラムやハードウェア、通信ネットワーク、データベースなどと組み合わせて実施するテスト。機能を検証することから機能テストと呼ばれることもある。エンタープライズ系のソフトウェアの場合、実際の顧客環境を使って行うこともある。組み込みソフトウェアの場合、実際のハードウェアにソフトウェアを組み込んだ状態で行うテストを指す。
受け入れテスト、検収テスト、承認テスト[編集]
受け入れテスト(検収テスト、承認テストとも呼ばれる)とは、システムの実際の利用者が行うテストで、システムが要求通りの機能や性能を備えているかどうか確認する。
アルファテスト、ベータテスト[編集]
完成前のソフトウェアを一般のユーザに利用してもらい、欠陥を発見してもらうテストのこと。ベータテストで配布されるソフトウェア(ベータ版)は、基本的には製品版と同等の機能を備えるが、予期せぬ不具合が存在する可能性があるため、利用に際しては細心の注意を払わなければならない。アルファテストは、ベータテストよりも完成度の低い段階(アルファ版)で行うテストである。オンラインゲームにおいては、ベータテストを広く一般に公開し、宣伝の目的も兼ねて実施される場合が多い。
ストレステスト[編集]
ストレステストとは、ソフトウェアシステムに対して高い負荷を与え、データの破壊など致命的な問題が発生しないかをテストすること。ストレステストを行うことで、高い負荷が加わっている状況でしか発生しない不具合や、発生確率の低い欠陥を発見することができる。
パフォーマンステスト[編集]
パフォーマンステストとは、ソフトウェアシステムの性能を測り、既定の性能が出ることを確かめること。通常、プログラム単体では問題が発生しなくても、通信、データベース、I/O、高負荷、長時間使用などの条件下では性能が低下することがあるため、これを確認するために実施する。OSやミドルウェアなどでは性能を測定するための共通の計測モデルが決まっていることもある。
回帰テスト(リグレッションテスト)[編集]
プログラムを修正・変更した場合に、修正前の他の機能が動作することを確認するために行うテストを回帰テスト(リグレッションテスト/退行テスト)という。過去のテスト資産が使え、実施する回数も多いことからテスト自動化の対象とされることが多い。
関連項目[編集]
- ソフトウェア工学
- テスト自動化
- テスト駆動開発
- 信頼度成長曲線
- インスペクション
- コードレビュー
- テストファースト
- ソフトウェア品質
- テスト管理システム
- ISO 9126
- ユニットテスト・フレームワーク一覧
関連ツール[編集]
- xUnit - コンピュータプログラムの単体テストツール
- JUnit - Javaプログラムの単体テストツール
- TestNG
- JTest
- CppTest
- CCTest
- djUnit
- Harness - スクリプトによるブラウザ自動操作、エビデンス自動記録、レポート出力を搭載したテスト自動化ツール
- TestLink - オープンソースのテスト管理システム
- Micro Focus Silk製品
- HP Quality Center - ヒューレット・パッカード社のソフトウェアテストツール
- VERISIUM(ベリシウム) - Webアプリケーション専用テストツール(機能/回帰テスト:vTest, 負荷テスト:vPerformer)
- CEGTest - 原因結果グラフからテスト条件を作成するツール