TOP＞プロジェクト管理＞ テストについて

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第12回：よりよいシステムにするために 著者：システムクリエイト  田中 徹   2005/2/18

前のページ  1  2   3  次のページ

テストについて

前回までの記事で、テストの重要性、特に本番稼動開始前に行うシステムテストについては詳しく述べてきました。システムテストを行うときは、行き当たりばったりで行うのではなく、十分に検討を重ねたテスト仕様書に基づき行うということをお話してきましたが、そのテスト仕様書についての補足説明をします。    テスト仕様書は開発初期の設計段階で作成する「用件定義書」の内容が網羅されていなければなりません。テスト仕様書は、大分類−中分類−詳細と分かれている方が見やすいので、多くの場合そう書かれています。テスト内容のそれぞれに、用件定義書に書かれている内容と対になる項目に用件定義書の番号を振り、用件定義書にテスト仕様書の番号を振ればテストの抜けが確認でき、各機能でどういうテストを行ったかがすぐに分かり便利です。    テスト仕様書に沿って検証作業を行い、期待通りの処理が出来たかどうかが重要なわけですが、ただそれだけの記述では意味がありません。正常に処理されたならどんな出力がされたのか、メッセージは何が出たかなどを記録し、また、画面やデータベースのテーブル内容のハードコピーなどが残せるならそれらを添付します。表面には出てこない一時ファイルなどがあれば、それを残せる工夫も欲しいところです。

機能以外でテスト仕様書に書かれるべきテスト項目

要件定義書と照らし合わせて検証できるものは、システムの機能が中心になります。しかし、機能以外でも当然テストを行わなければならないこともあります。その代表例として「0割」、「データ件数オーバー」、「繰り返しテスト」、「複数ユーザテスト」、「処理時間測定」などがあります。これ以外にもシステムの内容によっては行うべきテストがありますので、詳細に関してはSEと詰めて下さい。

0割

データ件数0件で処理を行ったり、0件の出力結果を出すテストを0割（ゼロワリ）と呼んでいます。0割はシステムダウンを引き起こす可能性があるので、特に念入りに行います。0件の入出力と判断されたら、どの過程で終わるのか、どんなエラーメッセージが出るのかを検証します。

データ件数オーバー

入出力されるデータ件数の上限や下限を設定している場合、上限を超えるデータ件数、下限を下回るデータ件数が入力された場合、どう処理されるかを検証します。バッチ処理（一連の流れ処理）等で行われる場合は、どの段階で弾き出されるか、どんなエラーメッセージが出るのかを検証します。もちろん出力においても同じです。検索結果をリスト出力する場合など、検索結果数が上限を超えた場合どの様に処理されるのか、上限を超えた場合はリスト出力できないようなガードがされているのかなどを検証します。

繰り返しテスト

同じ処理を続けて行うテストです。1度のテストでは正常に処理されても、2度3度と続けて行われると正常に処理されない場合もあります。少し専門的になりますが、ファイルを扱う場合など、1度目の処理でファイルが正常にクローズされないと、2度目に処理が行われたとき、ファイルがオープンできずに処理エラーとなることなどがあります。どの処理に対してこのテストを行えばいいのかはSEに相談するとして、こういうテストが必要な処理もあるということは知っておいて下さい。

複数ユーザテスト

ネットワーク環境で処理を行う場合に重要となります。同じタイミングで複数のユーザから同じ処理がリクエストされた場合、どう判断され、どう処理されるのかということです。ネットワーク環境で運用するなら当たり前のテストですが、開発は単体で行うことが多いので、時間を掛けて行う必要があります。データベースを扱う場合などは特に気をつけなければなりません。処理中データベースをずっと開放しないプログラムなどの問題は、1ユーザのテストでは検出されないからです。

処理時間測定

業務によっては、処理速度が重視される機能を持つシステムがあります。例えば、お客様対応専用電話を常時監視しているシステムで、登録された電話番号から電話が掛かってくると、自動的にそのお客様の情報が画面に表示されるケースなどです。受話器を上げてから数秒掛かって表示されたのでは意味がありません。理想では瞬時に、遅くとも電話に出た担当者が「はい、○○でございます」と言い終わるまでには表示されていないと、実用に耐えられません。    この様な場合では、複数ユーザテストとも組み合わせて行うことが望ましいでしょう。時間帯やシステム稼動条件も色々と変えて、条件が揃っていて最速で何秒、混んでいる時間帯、負荷が高いシステム状態で何秒掛かるか、というベンチマークテストも綿密に行う必要があります。システムの機能は単に働けばいいのではなく、実用に耐えられてこそいいシステムなのです。

前のページ  1  2   3  次のページ

著者プロフィール システムクリエイト有限会社  田中 徹 代表取締役。1963年生まれ。MS-DOS時代から、汎用機−PCでのデータ送受信を行ってのチャート（金融業）、表・グラフ描画（財務系）などのシステム開発を行う。 社内人事管理（勤怠・人材活用）、流通業、制御系の分野や集計業務なども手掛ける。ソフトウェアハウスや大手開発会社まで多数の現場で開発を経験し、33歳で独立。現在は各業種・分野でSEとして、またシステムコンサルタントとして活動中

INDEX 第12回：よりよいシステムにするために   いいシステムとは テストについて   セキュリティ

だからあなたの会社のシステムは動かない 〜システム発注担当者の悩みを解決します〜 第1回 システム発注担当者の苦悩 第2回 システム開発の流れ 第3回 開発形態と開発会社の規模による違い 第4回 見積もりについて 第5回 発注側の体制・社内体制を整える 第6回 発注担当者に必要なもの（1）〜業務知識とIT知識、業務フロー〜 第7回 発注担当者に必要なもの（2）〜社内調整、SEとの付き合い方〜 第8回 そもそもSE、プログラマってどんな人？ 第9回 さあ困った 〜その時発注担当者がするべき事は〜 第10回 本番に向けてのテスト 第11回 先達に学ぶ 〜トラブル事例紹介〜 第12回 よりよいシステムにするために