システム・テストの対象は，結合テストを終了した機能やサブシステムをまとめた「システム」となる。Vモデルによればシステム・テストは要求分析工程に対応している。テストの目的は，要求分析で定義された，負荷限界や必要なリソースなどの要件を，「システム」が正しく実現しているかどうかを確認することだ。
また要求分析には，開発/運用/利用部門の共通の認識として，システムのコンセプトや目的，達成すべき目標などが記述されている。テスト実施者は，開発者としての視点だけではなく，利用者や運用担当者の視点も含めたテスト・ケースを設定して，テストを実施すべきである。
III-(1)：負荷テスト
システムが，どこまでの負荷に耐えられるかを実測確認する。後述の「パフォーマンス・テスト」とは，正確には別のものである。代表的な負荷テストには以下のものがある。
●ロングラン・テスト
ある一定時間システムを連続稼働させて，一定の負荷がかかり続ける状況でも，安定稼働できるかどうかを確認する。リソース消費量を測定して，判断の基準にする。
●高頻度テスト
 図7●高頻度テストの結果例 負荷テストを実施し，単位時間当たりの処理件数を測定する。測定結果から，処理の集中にどの程度まで耐えられるかを見極める。応答時間の変化とリソースの使用量を記録することで，チューニングの資料にも流用できる [画像のクリックで拡大表示] |
単位時間当たりの繰り返し回数を増加させた場合，システムがどこまで耐えられるかを確認する。例えば，オンライン・システムのディスパッチャ処理が，1秒当たり何件のトランザクションまで耐えられるかを確認する場合に利用する（図7[拡大表示]）。
要求定義で目標値が定められていない場合でも，繰り返し回数の増減に対する，リソース消費量や応答時間の変化などを測定しておく。将来のチューニングなどにデータを生かすためだ。
●ボリューム・テスト
システムが扱うことができるデータのサイズや量の限界を確認する。例えば，一度に処理すべきファイル・サイズや送受信すべき電文のサイズを超えるデータが入力された場合，正常にエラー処理を実行することを確認する。
●ストレージ・テスト
メモリーやディスクなどのリソースを極端に少なくした状態で，システムがどこまで動作できるかを確認する。動作環境が専用に用意されているシステムであれば，リソースが足りなくなることは少ない。ただし，既存システムに新機能やサブシステムを追加する場合は，リソース不足が懸念される。ストレージ・テストを実施することで，適正なリソース量を見極めたい。
また，複数のシステムがリソースを共有する場合は，別の確認が必要だ。複数のシステムが高負荷の状態で，各々のシステムに割り振られたリソースの範囲内でシステムが快適に稼働するか，共用するワーク・エリアが不足しないか，などを確認する。
III-(2)：パフォーマンス・テスト
負荷を増した時のシステムの挙動やボトルネックを確認することが目的。システムへの負荷のかけ方は，前述した負荷テストと同様なため，負荷テストと合わせて実施されることが多い。負荷テスト同様，測定結果はチューニングの資料として，運用部門に提供し，運用設計に反映する。
 表4●主な負荷テスト・ツール [画像のクリックで拡大表示] |
 表5●障害テストのテスト項目例 [画像のクリックで拡大表示] |
 表6●管理者権限を確認するセキュリティ・テストのテスト項目例 [画像のクリックで拡大表示] |
負荷テストやパフォーマンス・テストでは，例えば数十台，数百台のクライアントから同時にサーバーへ処理を実行するなどしてシステムへ負荷をかける。人手に頼った場合は，相当に大掛かりなテストとなるため，負荷テスト・ツールを有効に利用したい（表4[拡大表示]）。また，負荷テストのシナリオは，「参照処理が80％，更新処理が20％」など，現実に想定できる割合を設定することが重要だ。
III-(3)：障害テスト
システムの設計や要件で想定されている障害に対して，システムが正しく動作すること，意図しない動作や新たな障害が発生しないこと，などを確認する。このテストを実施する時点で障害復旧方法が定まっている場合は，障害時の対応や復旧方法が正しいこと，漏れがないこともテストで確認したい。テスト結果は各部門を含めて評価して，障害復旧手順書や運用設計に反映させる。
テスト設計書は，要求定義書や障害復旧手順書を基に作成する。その際，まずシステム障害を「サーバー障害」，「ネットワーク障害」など大項目に分け，次第に詳細化していくと作成しやすい（表5[拡大表示]）。
III-(4)：セキュリティ・テスト
セキュリティ・ポリシーが，システムに正しく反映されていることを確認する。システムで対策すべきセキュリティ項目には，外部からの不正アクセス，内部での権限/承認コントロール，情報の漏えい，などがある。
ただし通常は，システム内部の権限や承認のコントロールを中心にテストする＊17。世界規模の24時間365日運転のシステムでは，利用者がアクセス中に権限変更される可能性もある。こうした場合でも，アクセス権限を超えた不正アクセスが発生しないことなどを意識してテストすべきだ（表6[拡大表示]）。さらに，シングル・サインオンによるユーザー認証システムなど，セキュリティ・ポリシーを管理するシステムが障害を起こした場合，システム全体にどの程度影響を及ぼすか，対策は適切かどうかを確認しておく。
III-(5)：構成テスト
システムのハードウエア，OS，ミドルウエア，データベース，通信ソフトウエアなどについて，導入状況や設定情報などが，設計上で定義された内容で問題ないか，変更した場合に影響がどこに及ぶかを確認する。
企業システムの場合，導入先の環境や設定はあらかじめ明確になっているため，現状の確認は容易だ。しかし，共存する他システムなどが規定している設定情報や，他システムを対象にしたチューニングなどの影響から，自システムの設定情報が変更される可能性もある。このようなケースを想定して構成テストを実施するが，開発部門だけでは十分にテスト・ケースが作成できない。構成テストの計画段階やレビューには運用部門にも参画してもらう必要がある。
|
倉田 克徳 エス・キュー・シー 代表取締役 石川 和則 エス・キュー・シー 取締役 事業企画室長 |
