システム全体を確認
単体テストや結合テストは，システムを構成するソフトウエアに着目してテストを実施する。これに対して，システムテストは，ハードウエアと利用者という要素を加えて，システムとして動作したときに発生する総合的な問題を検出することが目的である。
例えば，システム用に準備したマニュアルの問題，利用者への教育の問題，ヘルプの内容，ユーザビリティなど，様々な観点でテストを行う必要がある。
システムテストを担当するエンジニアの多くはソフトウエア・エンジニアだ。しかし，ソフトウエア・エンジニアの多くはプログラム構造やデータベースなどには精通していても，システムを客観的に見ることに慣れていないことが多く，偏った視点になりがちである。
そこでシステムテストを実施する際には，まずシステム全体を客観的に俯瞰し，システムの持つ構造上の弱点や運用上の問題点を洗い出さなければならない。
この際，システム設計時に作成したハードウエア構成，ソフトウエア構成，ネットワーク構成や運用設計書，リソース計算書などのドキュメントが，貴重な情報源となる。これらのドキュメントとテストの目的に基づいてシステムを模式的に表し，テスト計画を練る注2）。
図4[拡大表示]に，システムテストで実施されることが多い「負荷テスト」の設計例を示した。負荷テストを設計するには，まず利用者の行う様々な操作が，どの処理に負荷を与えるかを理解しなければならない。そのうえで，負荷をかける操作手順をテストケースとしてまとめ，これに従って負荷をかけてレスポンスタイムを計測する。
図4では，システム構造をサブシステムとデータベースの2つの側面で模式化し，各サブシステムに負荷を与える操作を洗い出したうえで，テスト項目を決定している。
システム構造を模式化することで，負荷をかけるべきサブシステムの漏れを防ぐことができる。
システムのリスクを評価する
システムテストは品質向上の最終段階であり，以前のテスト・フェーズで発見された問題を含めて，すべての問題が解決されなければならない。ただし，現実的には様々な理由により利用者に回避操作を要求したり，運用や保守に引き継がなければならない問題も皆無ではない。このため，システムテストの進ちょく管理では，通常の問題管理／テスト実行管理とは別に，残存リスクの管理も行う必要がある。
残存リスクを表す指標は，システムの種類や目的によって異なるが，「システム稼働後のコスト」や「システム稼働により想定される売り上げ」など，なるべく金額に換算して管理するべきである注3）。
表3[拡大表示]は，負荷テストの結果から，システムのキャパシティが企画時に想定された売り上げを実現するのに十分かどうか，というリスクを分析した例である。
表では，最もレスポンスタイムの遅い処理は「ID仮登録」で，この処理の1時間当たりの限界処理件数が1438件であることを示している。つまり，システムの限界処理数は1438件／時間ということになる。
仮に登録した人の15％がライセンスを購入し，その平均購入単価が1000円とすると，事例システムでの時間当たりの売上高は，1438件×0.15×1000円＝21万5700円となる。
月間のシステム稼働時間（ユーザーが主に利用する時間）を180時間とすると，月間売上高のキャパシティは，21万5700円×180＝3882万6000円。もし，システム要件が月間売上高4000万円だったとすれば，現状では約120万円分の能力が不足していることになる。
以上，テスト・フェーズに沿って，具体的なテストの実践方法を見てきた。もちろん，対象となるシステムによって，テストの方針や内容は千差万別である。このため，プロジェクト・マネジャーやテスト担当者の創意工夫なくしては，高品質なシステムは実現できないことに，十分注意して欲しい。
石川 和則／エス・キュー・シー 取締役東海大学海洋学部卒業。1984年にCSK入社。OS/2関連のテスト・プロジェクトなどに参加。その後，エー・アンド・アイシステムでアプリケーション開発などに従事した後，1995年よりエス・キュー・シー取締役に就任。現在は上海の現地法人である索科思軟件測試の副董事長も兼務 |
