テスト

単体テストが終了したらモジュールを結合し、設計・開発したシステムが正常に動作するか、運用に耐えられるかなどを確認するために、テストを実施します。テストは、プログラムやシステムの品質を確認する重要な工程です。
テストは、テスト計画に基づいて実施し、その実績を評価しながら作業を進めていきます。

<ページ先頭へ>

テストの実施手順

テストを行う手順は、次のとおりです。

<ページ先頭へ>

テストの技法

システム開発における主なテストの技法には、「ホワイトボックステスト」と「ブラックボックステスト」があります。

●ホワイトボックステスト

「ホワイトボックステスト」とは、プログラムの制御や流れに着目し、プログラムの内部構造や論理をチェックする技法のことです。

●ブラックボックステスト

「ブラックボックステスト」とは、入力データに対する出力結果について着目し、機能が仕様書どおりかをチェックする技法のことです。多くのテスト工程で使われる技法です。

<ページ先頭へ>

テストの計画

テストの計画では、入力したデータに対して期待通りの結果が出力されるかを検証するためのデータを準備します。しかし、正しいデータが入力された場合の結果を確認するだけで、テストを終了させるのでは不十分です。実際の業務では、必ずしも正しいデータが入力される、また正常な状態でシステムが使われるとは限らないため、様々なケースを想定して、次のようなテストデータを用意します。

正常データ 業務が正常に処理されることを確認する。
例外データ 業務で発生する例外データが例外として処理されるかを確認する。
エラーデータ 誤ったデータがエラーとして正確に検出されるかを確認する。
※まず、正常データでのテストを行ってから、次に例外データやエラーデータでテストを行う。

ブラックボックステストを実施するためのテストデータを作成する主な方法には、「同値分割」や「限界値分析」があります。


・同値分割

「同値分割」とは、入力するデータを「有効同値クラス」「無効同値クラス」にクラス分けし、それぞれのクラスを代表する値をテストデータとして採用する方法のことです。特徴としては、テストデータを作成しやすいことが挙げられます。

有効同値クラス 入力データとして正常に処理される値の範囲
無効同値クラス 入力データとしてエラーとなるような値の範囲

条件
年齢20歳以上
50歳未満
有効同値クラス 20歳以上49歳以下
無効同値クラス 19歳以下または50歳以上


年 齢
同値分割


・限界値分析

「限界値分析」とは、同値分割のクラス境界にあたる値を、テストデータとして採用する方法のことです。境界の条件が複雑な場合には、テストデータの漏れが発生しやすいため注意が必要です。


現在開発中のプログラムにおいて、ブラックボックステストを行う。テストデータとして用意する値は何になるか。ここでのテスト方式は、限界値分析で、変数Ⅹの有効値は、-64以上、-15以下とする。

ここでの有効同値クラス(正しい数値の範囲)は、-64以上、-15以下となっているため、無効同値クラス(エラーとなる数値の範囲)は、-65以下のデータと、-14以上のデータとなる。
限界値分析で使用するテストデータは、2つのクラスの境界にあたる値であるため、-65、-64、-15、-14がテストデータとして用意する値になる。

限界値分析の例

<ページ先頭へ>

テストの実施

システム開発におけるテストには、次のようなものがあります。

●結合テスト(統合テスト)

「結合テスト」では、モジュールやプログラムを統合して、ソフトウェア方式設計通りに正しく実行できるかを検証します。単体テストが完了したモジュール間やプログラム間で実施し、プログラム間のデータの受け渡しや画面遷移が正しく行われるかどうかを確認します。一般的に、ソフトウェア方式設計(内部設計)の担当者がテストケースを作成し、システム開発部門内でテストを実施します。
結合テストには、次のようなものがあります。

・トップダウンテスト

「トップダウンテスト」とは、上位のモジュールから順番にテストしていく方法のことです。会のモジュールがすべて完成していないことが多いため、上位のモジュールに呼び出される仮のモジュール「スタブ」を用意します。

トップダウンテスト


・ボトムアップテスト

「ボトムアップテスト」とは、会のモジュールから順番にテストしていく方法のことです。上位のモジュールが完成していない場合は、会のモジュールを呼び出す仮のモジュール「ドライバ」を用意します。

ボトムアップテスト


●システムテスト(総合テスト)

「システムテスト」では、結合テストが完了したプログラムを結合して機能全体がシステム方式設計(外部設計)で設計した要求仕様を満たしているかを検証します。一般的に、システム方式設計(外部設計)の担当者がテストケースを作成し、システム開発部門と利用者(システム利用部門)が協力してテストを実施します。
システムテストでは、目的に応じて次のようなテストを実施します。

名 称 説 明
機能テスト 必要な機能がすべて含まれているかをテストする。
性能テスト レスポンスタイムやターンアラウンドタイム、スループットなどの処理性能が要求を満たしているかを検証する。
例外処理テスト エラー処理機能や回復機能が正常にっ動作するかを検証する。
負荷テスト
(ラッシュテスト)
大量のデータの投入や同時に稼働する端末数を増加させるなど、システムに負荷をかけ、システムが耐えられるかを検証する。
操作性テスト 利用者(システム利用部門)が操作しやすいかを検証する。
リグレッションテスト
(回帰テスト、退行テスト)
各テスト工程で発見されたエラーを修正したり仕様を変更したりしたときに、ほかのプログラムに影響がないかを検証する。
ペネトレーションテスト
(侵入テスト)
外部からの攻撃や侵入を実際に行ってみて、システムのセキュリティホールやファイアウォールの弱点(ぜい弱性)を検出する。

●運用テスト

「運用テスト」では、実際の業務データを使用し、業務の実態に合ったシステムかどうか、操作マニュアルや運用マニュアル通りに稼働できるかどうかを検証します。利用者(システム利用部門)が主体となって実施します。
運用テストでは、次のような項目をテストします。

項 目 説 明
業務機能 業務を行う上で必要な機能を満たしているかを検証する。
操作性 利用者(システム利用部門)が操作しやすいシステム化を検証する。
異常対策 データ異常、異常な操作、機器異常などの場合の対策が講じられているかを検証する。
処理能力 現行の機器構成で処理能力が十分かを検証する。

<ページ先頭へ>

テスト結果の評価

システムを検収するには、テストの結果が良好であることが必要です。このとき、テスト結果にもとづきシステムを評価する基準について考慮する必要があります。
代表的な評価基準には「バグ管理図」があります。バグ管理図とは、テスト時間と検出されたバグの累積数の関係をグラフにしたものです。
理想的なバグ管理図は「ゴンペルツ曲線(信頼度成長曲線)」と呼ばれる形の曲線になります。

ゴンペルツ曲線

バグ管理図の例

①のグラフはゴンペルツ曲線になっており、次のような状況が読み取れる。

  • 初期段階では、バグが発生し、テスト項目の消化がはかどっていない。
  • 中期段階では、テスト項目の消化がはかどり、バグの検出も多くなっている。
  • 終期段階では、バグの検出が収束に向かっている。

以上のことから、テストを終えてもよいということがわかる。ただし、バグの検出が収束に向かっていても、未消化のテスト項目が残っている場合は、テストがはかどっていないことも考えられる。そのため、テストの終了については、テストの消化状況も併せて検討する必要がある。

②のグラフはゴンペルツ曲線になっておらず、次のような状況が読み取れる。

  • 初期段階では、バグが発生し、テスト項目の消化がはかどっていない。
  • 中期段階では、バグの検出が増え続け、収束する兆しが見えない。また、テスト項目の消化もはかどっていない。

以上のことから、未消化のテスト項目が多い状態で、プログラムの品質やテスト方法に問題があることが考えられる。プログラムに欠陥がないか、テスト方法が最適かどうかを再度検討する必要がある。

エラー対応工数の例

システム開発において、エラーの発生は避けては通れないが、どのタイミングでエラーを検出し対応するかによってその対応工数が異なる。システム開発の初期段階では、プログラムが単体であることからエラーの発生したプログラムだけを修正し、テストを実施するという手順になるため、対応工数が比較的少なくて済む。しかし、後工程に進むとプログラムが連結され、エラーの発生したプログラムだけでなく、周囲のプロいグラムについてもテストを行う必要があるため、テストにかかる工数が初期段階に比べて大幅に増加する。
また、開発工数の増加は、費用面において見積もりと大きく差異を生じさせてしまう。システム開発における工数は、そのまま費用(人件費)として考えられるため、開発初期段階でプログラムの品質を高めておく必要がある。

<ページ先頭へ>


  プロフィール  PR:無料HP  免許合宿 格安  ゲーム 制作  タナベ  中古ホイール 新潟  タイヤ 18インチ  大学  バイクパーツ  マラカイト  心理学部 大学  イーキャピタル 口コミ  タイヤ 取り付け 浜松  名簿屋