pafuイーランスクール 学んでできる

メニューへ戻る

テスト工程・保守(システム開発技術)

学習のポイント

ボトムアップアプローチで行う、各工程のテストについて把握し、デバッグの方法、保守について理解しましょう。

1. テストの流れ
テスト工程では、「各工程の設計の正しさを検証」しながら、ソフトウェアユニット(モジュール)から「システム」にまで、段階的にまとめ上げます。

1. 単体テスト(ソフトウェアユニットテスト)…ソフトウェアユニット「モジュール」のテストを実施する。
  ↓
2. ソフトウェア結合テスト…ソフトウェアユニット「モジュール」を結合し、ソフトウェア品目にまとめ上げる。
  ↓
3. ソフトウェア適格性テスト…ソフトウェア要件通りに実現されているかをテストする。
  ↓
4. システム結合テスト…ソフトウェア品目を結合して、システムとしてまとめ上げる。
  ↓
5. システム適格性テスト…システム要件通りに実現されているかをテストする。

2. 単体テスト(ソフトウェアユニットテスト)
単体テスト
プログラムを構成する最小単位の「モジュール」のテストで以下の2種類の方法があります。
ホワイトボックステスト
「プログラムの内部論理に基づいてテストケースを設定する技法」です。
命令網羅
プログラム中のすべての命令が少なくとも1回は実行されるようにテストする。
判定条件網羅
プログラムの判定条件で真と偽が少なくとも1回は実行するようにテストする。
条件網羅
判定条件において、真偽についての組合せを満たす条件を少なくとも1回は実行するようにテストする。
複数条件網羅
判定条件で条件のとりうるすべての組合せを網羅するようにテストする。

ブラックボックステスト
プログラムの「外部仕様」をもとにテストケースを設定する。つまりプログラムを中身の見えない箱と見なします。
同値分割
入力データを「同じ出力結果が得られるグループ」に分割します。このグループを「同値クラス」と言います。この際、正常処理を行う同値クラスを「有効同値クラス」と言い、エラー処理を行う同値クラスを「無効同値クラス」と言います。
限界値分析
同値クラスの境界値をテストケースとすることを言います。
3. ソフトウェア結合テスト
各々のモジュールを結合して行うテスト。以下の種類があります。
増加テスト トップダウンテスト
ボトムアップテスト
サンドイッチテスト
非増加テスト ビックバンテスト
一斉テスト
増加テスト」とは、モジュールを段階的に結合して行います
非増加テスト」とは、モジュールを一度に結合して行います
トップダウンテスト
上位モジユールに下位モジュールを順次組み合わせて行きます。完成されていない下位モジュールは「スタブ」を使用して補います。
ボトムアップテスト
下位モジュールから順次、上位モジュールを組合わせてテストを行い、完成されていない上位モジュールがある場合は「ドライバ」を使用して補います。
サンドイッチテスト
最上位モジュールからトップダウンテスト、最下位モジュールからボトムアップテストを並行的に行います。「ドライバ」と「スタブ」の両方が必要となります。
ビックバンテスト
「スタブ」「ドライバ」を用意しておき、すべてのモジュールを結合してテストを行います。最も短期間で結合テストを終了できますが、比較的小規模のソフトウェアにしか向いていません。
一斉テスト
小規模ソフトウェアに向いた方法で、モシュールの単体テストは行わず、直接、すべてのモジュールを結合してテストわ行います。「ドライバ」「スタブ」は不要です。
4. システム適格性確認テスト
要件定義で定められた機能やセキュリティなどが実現さけているかどうかテストを行います。具体的には以下のテストを行います。

1. 機能テスト
システムがユーザーの要求する機能を満たしているかどうかの検証
2. 性能テスト
仕様で定められた性能を満たしているかどうかテストする。具体的には、処理速度、ターンアラウンドタイム、レスポンスタイム(応答時間)、スループットなどのシステムの性能の検証。
3. 負荷テスト
システムに量的な負荷をかけ、耐えられるかどうかを検証。
4. 例外テスト
エラー処理などの例外処理を正しく行うか検証。

5. 運用テスト
ユーザ部門が主体となって行うテストで、ユーザ部門が提示した条件を満たしているかどうか確かめるテストです。以下の順番に行われます。
「承認テスト」→「導入テスト」→「実地テスト」
承認テスト」システム納品後、ユーザ部門がテストデータを用意して動作確認する。
導入テスト」実際の動作環境のもとでシステムが仕様どおりの性能を満たしているか確認してシステムの検収と受領を行う。
実地テスト」システムを実際に業務で使用して確認・評価する。これはシステムが破棄されるまで継続します。
6. その他のテスト
1. ベネトレーションテスト
通信ネットワークで外部と接続されたコンピュータシステムの「セキュリティ上の脆弱性を調査する」テスト手法の一つで、既に知られている手法を用いて「実際に侵入や攻撃を試みる方式」のテスト。
2. アサーションチェック
プログラムの実行中に、使用されている変数の間で特定の時点で成立する条件をアサーションといいます。アサーションチェックは、この条件をプログラムの適切な箇所に挿入し、実行時にその部分のアサーションが成立しているかを検査することで、プログラムの正当性を検証する手法です。
3. ストレステスト
システムに要求されている処理能力の限界状態における動作を確認するテストです。
4.ベンチマークテスト
標準的なプログラムの実行時間を計測することによって,他のコンピュータと性能を比較するテストです。
7. デバック
マシンデバック
動的テスト」とも言い、「プログラムを実際に動かすことによって行うテスト」です。デバックを支援する「デバックプログラム」には以下のものがあります。
メモリダンプ 主記憶装置内の状態を印字するプログラム
トレーサ 命令の実行順にその命令と実行結果を印字するプログラム
スナップショット 主記憶装置内の指定したアドレスやレジスタの内容を実行中に一定間隔で出力するプログラム
机上デバック
静的テスト」とも言い、「人間がプログラムリストをもとに目で検査する方法」。
8. 保守とは?
保守」とはソフトウエア納品後に「顕在化したエラーや、ソフトウェアに対する変更要求に対処する」工程です。共通フレームでは4つのタイプの保守があります。
是正保守 ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正。
予防保守 引渡し後のソフトウェア製品の潜在的な障害が運用障害になる前に発見し,是正を行うための修正。
適応保守 引渡し後,変化した又は変化している環境において,ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正。
完全化保守 引渡し後のソフトウェア製品の性能又は保守性を改善するための修正。
※保守の注意点
保守の注意点として「リップル効果」と言い、ソフトウェアの一部の修正が。場合によっては、ソフトウェア全体に悪影響を及ぼすことを言います。
レグレッションテスト
保守作業により、正しく変更が行われ、新たなバグが生じていないかをチェックするテストです。
メニューへ戻る

pafuイーランスクール

pafuイーランスクール 学んでできる