単体テストが終了したらモジュールを結合し、設計・開発したシステムが正常に動作するか、運用に耐えられるかなどを確認するために、テストを実施します。テストは、プログラムやシステムの品質を確認する重要な工程です。テストは、テスト計画に基づいて実施し、その実績を評価しながら作業を進めていきます。更新日:10月12日テストを行う手順は、次のとおりです。更新日:10月12日システム開発における主なテストの技法には、「ホワイトボックステスト」と「ブラックボックステスト」があります。●ホワイトボックステスト「ホワイトボックステスト」とは、プログラムの制御や流れに着目し、プログラムの内部構造や論理をチェックする技法のことです。●ブラックボックステスト「ブラックボックステスト」とは、入力データに対する出力結果について着目し、機能が仕様書どおりかをチェックする技法のことです。多くのテスト工程で使われる技法です。更新日:10月12日テストの計画では、入力したデータに対して期待通りの結果が出力されるかを検証するためのデータを準備します。正しいデータが入力された場合の結果を確認するだけで、テストを終了させるのでは不十分です。実際の業務では、必ずしも正しいデータが入力される、また正常な状態でシステムが使われるとは限らないため、様々なケースを想定して、次のようなテストデータを用意します。正常データ業務が正常に処理されることを確認する。例外データ業務で発生する例外データが例外として処理されるかを確認する。エラーデータ誤ったデータがエラーとして正確に検出されるかを確認する。※まず、正常データでのテストを行ってから、次に例外データやエラーデータでテストを行う。入力するデータを「有効同値クラス」と「無効同値クラス」にクラス分けし、それぞれのクラスを代表する値をテストデータとして採用する方法のことです。特徴としては、テストデータを作成しやすいことが挙げられます。同値分割のクラス境界にあたる値を、テストデータとして採用する方法のことです。境界の条件が複雑な場合には、テストデータの漏れが発生しやすいため注意が必要です。現在開発中のプログラムにおいて、ブラックボックステストを行う。テストデータとして用意する値は何になるか。ここでのテスト方式は、限界値分析で、変数Xの有効値は、-64以上、-15以下とする。ここでの有効同値クラス(正しい数値の範囲)は、-64以上、-15以下となっているため、無効同値クラス(エラーとなる数値の範囲)は、-65以下のデータと、-14以上のデータとなる。限界値分析で使用するテストデータは、2つのクラスの境界にあたる値であるため、-65、-64、-15、-14がテストデータとして用意する値になる。更新日:10月12日システム開発におけるテストには、次のようなものがあります。●結合テスト(統合テスト)「結合テスト」では、モジュールやプログラムを統合して、ソフトウェア方式設計通りに正しく実行できるかを検証します。単体テストが完了したモジュール間やプログラム間で実施し、プログラム間のデータの受け渡しや画面遷移が正しく行われるかどうかを確認します。一般的に、ソフトウェア方式設計(内部設計)の担当者がテストケースを作成し、システム開発部門内でテストを実施します。結合テストには、次のようなものがあります。・トップダウンテスト「トップダウンテスト」とは、上位のモジュールから順番にテストしていく方法のことです。会のモジュールがすべて完成していないことが多いため、上位のモジュールに呼び出される仮のモジュール「スタブ」を用意します。・ボトムアップテスト「ボトムアップテスト」とは、会のモジュールから順番にテストしていく方法のことです。上位のモジュールが完成していない場合は、会のモジュールを呼び出す仮のモジュール「ドライバ」を用意します。●システムテスト(総合テスト)「システムテスト」では、結合テストが完了したプログラムを結合して機能全体がシステム方式設計(外部設計)で設計した要求仕様を満たしているかを検証します。一般的に、システム方式設計(外部設計)の担当者がテストケースを作成し、システム開発部門と利用者(システム利用部門)が協力してテストを実施します。システムテストでは、目的に応じて次のようなテストを実施します。必要な機能がすべて含まれているかをテストする。レスポンスタイムやターンアラウンドタイム、スループットなどの処理性能が要求を満たしているかを検証する。エラー処理機能や回復機能が正常にっ動作するかを検証する。大量のデータの投入や同時に稼働する端末数を増加させるなど、システムに負荷をかけ、システムが耐えられるかを検証する。利用者(システム利用部門)が操作しやすいかを検証する。各テスト工程で発見されたエラーを修正したり仕様を変更したりしたときに、ほかのプログラムに影響がないかを検証する。外部からの攻撃や侵入を実際に行ってみて、システムのセキュリティホールやファイアウォールの弱点(ぜい弱性)を検出する。●運用テスト「運用テスト」では、実際の業務データを使用し、業務の実態に合ったシステムかどうか、操作マニュアルや運用マニュアル通りに稼働できるかどうかを検証します。利用者(システム利用部門)が主体となって実施します。運用テストでは、次のような項目をテストします。業務を行う上で必要な機能を満たしているかを検証する。利用者(システム利用部門)が操作しやすいシステム化を検証する。データ異常、異常な操作、機器異常などの場合の対策が講じられているかを検証する。現行の機器構成で処理能力が十分かを検証する。更新日:10月12日システムを検収するには、テストの結果が良好であることが必要です。このとき、テスト結果にもとづきシステムを評価する基準について考慮する必要があります。代表的な評価基準には「バグ管理図」があります。バグ管理図とは、テスト時間と検出されたバグの累積数の関係をグラフにしたものです。理想的なバグ管理図は「ゴンペルツ曲線(信頼度成長曲線)」と呼ばれる形の曲線になります。1のグラフはゴンペルツ曲線になっており、次のような状況が読み取れる。初期段階では、バグが発生し、テスト項目の消化がはかどっていない。中期段階では、テスト項目の消化がはかどり、バグの検出も多くなっている。終期段階では、バグの検出が収束に向かっている。以上のことから、テストを終えてもよいということがわかる。バグの検出が収束に向かっていても、未消化のテスト項目が残っている場合は、テストがはかどっていないことも考えられる。そのため、テストの終了については、テストの消化状況も併せて検討する必要がある。2のグラフはゴンペルツ曲線になっておらず、次のような状況が読み取れる。初期段階では、バグが発生し、テスト項目の消化がはかどっていない。中期段階では、バグの検出が増え続け、収束する兆しが見えない。テスト項目の消化もはかどっていない。以上のことから、未消化のテスト項目が多い状態で、プログラムの品質やテスト方法に問題があることが考えられる。プログラムに欠陥がないか、テスト方法が最適かどうかを再度検討する必要がある。システム開発において、エラーの発生は避けては通れないが、どのタイミングでエラーを検出し対応するかによってその対応工数が異なる。システム開発の初期段階では、プログラムが単体であることからエラーの発生したプログラムだけを修正し、テストを実施するという手順になるため、対応工数が比較的少なくて済む。後工程に進むとプログラムが連結され、エラーの発生したプログラムだけでなく、周囲のプロいグラムについてもテストを行う必要があるため、テストにかかる工数が初期段階に比べて大幅に増加する。開発工数の増加は、費用面において見積もりと大きく差異を生じさせてしまう。システム開発における工数は、そのまま費用(人件費)として考えられるため、開発初期段階でプログラムの品質を高めておく必要がある。