テスト
■ テスト。 テストの種類には、 単体テスト、結合テスト、システムテスト、 運用テスト、レグレッションテストの5種類がある。 ■ 単体テスト。 1つのモジュール(プログラム)が、 要求された機能通りに動くかどうかをテストする。 単体テストの手法としては、 モジュールのインターフェースに着目したブラックボックステストと、 モジュールの内部構造に着目したホワイトボックステストがある。 単体テストは、基本的にはブラックボックステストで行われるが、 必要に応じてホワイトボックステストが行われる。 (1) ブラックボックステスト。 プログラムの外部仕様を元にテスト項目の設定を行う。 とくにプログラムの外部的な入出力仕様を見ながら、 様々なデータを入力して、出力結果を確認する。 +-------------+-------------------------------------------+ | 同値分割 | 有効な値の範囲と、無効な値の範囲から、 | | | それぞれ1値を入力してテストする。 | +-------------+-------------------------------------------+ | 限界値分析 | 有効な値の範囲と無効な値の範囲の、 | | | 境界値を入力してテストする。 | +-------------+-------------------------------------------+ | 因果グラフ | 入力値と出力値の論理関係を図式化し、 | | | デシジョンテーブルを作成、検証する。 | +-------------+-------------------------------------------+ (2) ホワイトボックステスト。 プログラムの内部構造によってテスト項目を設定する。 モジュールの論理構造や、制御の流れに着目し、 可能な限り、すべての実行経路を通るようにテストを作成する。 +---------------+-------------------------------------------+ | 命令網羅 | すべての命令を少なくとも1回は実行させる。 | +---------------+-------------------------------------------+ | 判定条件網羅 | 判定条件が真偽2択のとき、 | | | 真となる場合と、偽となる場合の両方を、 | | | 少なくとも1回は実行させる。 | +---------------+-------------------------------------------+ | 複数条件網羅 | 判定条件が複合条件のとき、 | | | すべての可能な結果の組み合わせを、 | | | 少なくとも1回は実行させる。 | +---------------+-------------------------------------------+ プログラムが持つすべての経路をどれくらいカバーしたか、 すなわち、テストが完了した経路数を全ての経路数で除算した値のことを、 カバレッジという。 ■ 結合テスト。 単体で正しく動くことが検証されたモジュールを、 2つ、3つと徐々に結合させてテストを行い、 モジュール間のインターフェースが正しいかどうかをテストする。 最終的にはプログラムを構成するすべてのモジュールを結合してテストを行う。 結合テストの主な手法としては、ボトムアップテストとトップダウンテストがある。 ボトムアップテストでは、 下位のモジュールから上位のモジュールへと順に結合しながらテストする。 トップダウンテストでは、 上位のモジュールから下位のモジュールへ、順に結合しながらテストする。 ■ システムテスト。 システムとしての要件が満たされているかを確認するためのテスト。 機能テストや操作性テストのほか、障害回復テストや耐久テスト、例外テストなど、 さまざまな角度からテストを行うため、総合テストとも言う。 開発側が主導で行うテストの中では、最終テストとなる。 ■ 運用テスト。 ユーザ部門が主体となって進めるテスト。 ユーザ部門がテストケースを設定し、実際の運用と同じ条件下でテストを行い、 システム要件を満たしているか確認する。 システム利用開始前の最終テストである。 ■ レグレッションテスト。 システムの保守の段階で行なわれるテスト。 現在稼動しているシステムがあり、その一部を修正したとき、 他の部分に影響して新しい誤りが発生していないかどうかを検証するもの。 ■ バグ管理図。 縦軸にバグの累積個数、横軸にテスト時間(テスト消化件数) をとったグラフ。 信頼性成長曲線、バグ曲線とも呼ぶ。 一般に、プログラムのバグ発生率は、 ロジスティック曲線やゴンペルツ曲線などの成長曲線で近似できる。 最初はバグの発生数が少ないが、時間経過と共に徐々増加し、 最後にはある一定のバグ数に収束する。 バグ数が収束したとき、プログラムは一定の品質に達したと判断される。 参考URL 名古屋工学院専門学校様 問54の図 http://www.denpa.ac.jp/exam/josys/2001au_kaisetsu/H13-2-6.html ■ エラー埋め込み法。バグ埋め込み法。 プログラムに潜在するバグの量を推定する方法の1つ。 あらかじめ既知のバグをプログラムに埋め込んでおき、 その存在を知らない検査グループにバグ発見テストを行わせる。 通常、故意に埋め込んだバグのすべてが発見されることはなく、 また埋め込んだバグ以外に、今まで発見されなかった潜在バグが発見される。 両者の発見率を基にして、プログラムの潜在バグ数を推定することができる。 発見された埋め込みバグ数/故意に埋め込んだ全バグ数 = 発見された潜在バグ数/テスト前の全潜在バグ数 以上。 2004/03/10 pm