Click here to visit our sponsor



---------------------------------------------------------------------

(システムテスト計画について)

---------------------------------------------------------------------

---------------------------------------------------------------------
(設問ア)
---------------------------------------------------------------------
1. システムの概要と特徴
---------------------------------------------------------------------
1−1.システムの概要
----
 私は、地方自治体S市のコンピュータ障害処理業務を
ワークフロー化するシステムの開発業務に参画した。本
システムは、S市のシステム部門が各部門で発生する故
障などのコンピュータの障害を「障害管理票」という定
型フォーマットを用いて障害の発生から対応完了までの
状況を管理するためのシステムである。
 本システムは、ワークフローエンジンを使用して構築
した。システム部門が障害発生の連絡を受けると、1件
の障害管理票をサーバー上のデータとして作成する。新
規作成した障害管理票は、上司の承認が必要であるため、
上司に対して承認を要求する電子メールを送付する。上
司の承認を得ると、その障害管理票は「障害対応中」状
態となり、必要な処置を行って問題が解決すると,対応
内容を入力し、再度上司の承認を得て「処理完了」状態
となり、1つの障害に対する対応が完了する。
----
1−2.システムの特徴
----
 本システムは、別のワークフローエンジンを使用して
実験システムが構築されており、既に一年間稼動してい
た。このため、ユーザーはシステムが必要とする要件を
明確に把握しており、レスポンスについても具体的に「
障害管理票の登録時間はボタンを押してから3秒以内」
などの要望がはっきりしていた。また、ネットワーク上
で約20人が本システムを使用するため、クライアント
側に複数のOSや本システムが印刷などのために使用す
るソフトウエアのバージョンが異なる環境でシステムが
動作することが求められた。
----
1−3.私の立場と役割
----
 私は、本開発業務にアプリケーションエンジニアとし
て参画し、基本設計および詳細設計を担当した。
---------------------------------------------------------------------
(設問イ)
---------------------------------------------------------------------
 2.テスト計画とテスト時の工夫点
---------------------------------------------------------------------
2−1.テスト計画における品質要件とその理由
----
 システムテストは、以下の目標を持ったテストを行う
方針を立てた。

a. 各種レスポンスタイムの検証
 ユーザーから最も求められていたレスポンスタイムに
ついて、本番環境に近い状態で計測を行うテストを実施
することとした。なぜなら、結合テストまではテスト
データを使用してユーザーの求めるレスポンスの確保は
できていたが、データ件数が予想最大件数時のレスポン
スの計測ができていなかったためである。

b. 競合操作後のシステムの安全性・整合性の検証
 障害管理票を2人で同時に起票したり、同じ障害管理
票を同時に更新を行った後、システムが安全に動作する
か、データに不整合が起きないかを検証することにした。
なぜなら、本システムに適用するワークフローエンジン
が、データをロックする機能を保有しておらず、起票済
みの障害管理票を同時に更新した場合、後書き優先とな
ることがわかっていた。障害管理票は、先にも触れたよ
うに「発生」や「上司承認待ち」などいくつかの状態を
管理している。その状態ごとに動作するプログラムが存
在しているため、障害管理票の取り得る全ての状態にお
いて競合発生後にシステムが正常に動作するか,データ
の不整合が発生しないかを確認する必要があった。
----
2−2.テスト実施時の制約条件とそれに対する工夫
----
 テスト実施時には以下のような制約事項があった。

a. ユーザーのマシン環境が使えない
 ユーザーのマシン環境は、S市の市役所内部であり、
システムテストのために環境を長時間使用することは許
されなかった。そこで、ユーザーの環境で特徴的な点で
あるクライアントのソフトウエアのバージョンの組み合
わせを社内で再現することが必要となった。その対策と
して私は、ユーザーのパソコンにインストールされてい
る各種ソフトウエアのバージョンの調査を依頼し、当社
でそれらの組み合わせを再現して本システムが動作する
か確認することにした。
 結果として、表計算ソフトウエアは特定のバージョン
以降でないとグループウエアソフトのマクロから起動で
きないことが明らかとなった。また、システムテスト前
は、グループウエアサーバーの共有フォルダ上に印刷用
の表計算ファイルを配置し、グループウエアクライアン
トのマクロからそのファイルを開くことにしていたが、
表計算ソフトのバージョンにより動作が異なることがわ
かった。そこで、印刷用の表計算ファイルをクライアン
トのローカルファイルとした場合は安定して動作するこ
とがわかったので、印刷用表計算ファイルの配置を変更
することにした。

b. 現実のデータが存在しない(Accessの方が良い?)
 本システムは新規構築であるため、現実のデータが存
在しておらず、最大予想データ件数時のレスポンスが
ユーザーの要求を守れるかが問題となった。しかし、別
のワークフローエンジンではあるが、実験システムに蓄
えられた昨年一年間のデータは存在していた。ユーザー
にそのデータをテスト用に使用して良いか確認したとこ
ろ、問題ないとの回答だったのでデータを本システムに
移行するプログラムを作成し、現実に近いテストデータ
を作成することができた。
 この結果、データ件数が多い場合、障害管理票の起票
時のレスポンスがユーザーの要件を満たせないことがわ
かった。理由は、新規の管理番号を採番するために、そ
れまでに登録された全ての障害管理票を参照してから最
新の管理番号を発行しているためであった。そこで、管
理番号を管理する専用のデータベースを準備することに
より、起票時のレスポンスをユーザー要望に近いものに
することができた。
---------------------------------------------------------------------
(設問イ)
---------------------------------------------------------------------
3.システムテスト計画の評価と今後の改善点
---------------------------------------------------------------------
3−1.システムテストの結果の評価
----
 システムテストは、事前に計画を充分行ったものの、
当初の予定よりも作業量が多くなったためカットオー
バーの予定を1ヶ月遅らせることとなってしまった。
しかし、テストは充分に行うことができた。今回のシ
ステムテストは、以下の2点が特に効果があった。
a. 昨年の実データをテスト時に使用できたこと
b. 競合や誤操作などの試験を充分にできたこと
 システムテストを工夫した結果、ユーザーの要求する
レスポンスタイムの確保ができたこと、誤操作などに対
するシステムの安全性が検証できたこと、さらに問題発
生時の対処方法を運用説明書に盛り込むことができたこ
となど、システムテストが効果的に行えたと考えている。
----
3−2.今後の改善点
----
 システムを導入時、本システムがクライアントで利用
する表計算ソフトおよびスクリプト言語エンジン(Mi
crosoft VBScript)のバージョンの違
いにより、システムが正常に動作しない場合が発生した。
この問題解決を解決し、全てのクライアントでシステム
が正常に動作するまでに更に1ヶ月の時間を費やしてし
まった。この点から、今後、オープンシステムのシステ
ムテストを行う場合、利用するソフトウエアのバージョ
ンの違いによる動作確認も必要なのだと感じた。





[ 戻る ]