JP5537599B2 - 業務システムにおけるバージョンアップ管理方法 - Google Patents

Description

本発明は、いわゆる業務システムについて、バージョンアップ（世代変更）を行うための技術に関する。その中でも、特に、バージョンアップの際のテストを行う技術に関する。

現在、様々な業務がいわゆるコンピュータシステムで実行されている。このような場合、新たな機能追加や修正によるバージョンアップが必要になってくる。そして、バージョンアップにおいては、追加、修正する機能のテストを行う必要がある。

このテストに関する従来技術として、特許文献１が存在する。特許文献１では、複数のコンポーネントから構成されるソフトウェアの効率的なバージョンアップ手法を提供することを目的としている。この目的を達成するために、特許文献１には、受け付けたバージョンアップ対象のコンポーネント及びそのテストプログラムをコンポーネント管理サーバ取得し、このテストプログラム等をについて、テストに失敗した場合、関連する未実行コンポーネントが存在すれば、当該コンポーネントをバージョンアップ対象のコンポーネントと共にバージョンアップを行うものである。

特開2008-269128号公報

ここで、業務システムにおいては、一度のバージョンアップにおいて、複数の機能が追加ないし変更されることがある。このような場合、あるモジュールについて、複数回のテストが実行されることがある。さらに、複数回のテストを行った場合、それぞれでモジュールに修正が入ることがあり得る。

しかし、特許文献１においては、複数回のテストが行われることは考慮されておらず、これを如何に自動的に行うかについては開示されていない。

上記の課題を解決するために、本発明では、テスト対象機能毎に、関連する各モジュールの変更の有無をタイムスタンプを用いて判断し、その結果を確定フラグとして記録することで管理するものである。この中でも特に、本発明では、テスト対象機能を識別する変更機能ＩＤを、変更があったモジュールと対応付けて記憶することで、変更後のモジュールのうち有効なものを特定することが好適である。つまり、修正があったモジュールかを、マスタテーブルに格納された変更機能ＩＤで判断し、当該変更機能ＩＤと該当するテスト機能を用いて、有効なモジュール（修正済みの）を特定するものである。

本発明によれば、複数のモジュールについて、複数回のテストがなされた場合でも容易に管理することが可能になる。

本発明の一実施形態の対象の概念を示す図。 本発明の一実施形態での処理フローの概要を示す図。 本発明の一実施形態で用いられるシステム構成を示す図。 本発明の一実施形態でのフローチャート。 本発明の一実施形態でのテスト対策機能管理表。 本発明の一実施形態でのマスタ管理表。 本発明の一実施形態での修正モジュール管理表。

本発明の一実施形態について、図面を用いて説明する。
図１は、本実施形態の対象の概念を示す図である。まず、保守環境（サーバ）と現行(稼動)環境が存在し、それぞれがネットワークを介して接続される。そして、保守環境でテスト、修正された内容が、ネットワークを介して、現行環境に展開され、旧バージョンと差換えられる。その流れを図２を用いて説明する。まず、（１）バージョンアップの際、元になるもの（本例では、第４世代）のプログラム等をテスト環境に移行する。（２）そして、テスト環境で、新機能に対応するモジュールの追加、修正およびテストを実行する。（３）テスト完了した後、リリース候補モジュールとして、リリース管理サーバに格納する。また、これらと並行して、（４）現行環境では、ミラー領域を作成し、現行のプログラム等をミラー領域に同期させる。そして、（２）のテスト完了した場合、（５）ネットワークを介してテストが完了したプログラム等を、現行環境にネットワークを介して展開し、また、（６）新世代として(本例では第５世代)、保守環境に保存する。また、現行環境では、（５）で展開されたものを現行環境に登録し、さらなる動作確認を行う。この結果、不具合が生じた場合には、（７）バージョンアップ前に戻す、つまり、ミラー領域に格納されている内容を現行領域に上書きする。また、不具合が生じなかった場合には、ミラー領域の旧バージョン（本例では第四世代）を削除する。

以下、この詳細を図面を用いて説明する。図３に本実施形態で用いるシステムの構成図を示す。本システムは、テスト環境であるユーザＡテストサーバ３１０１と、テスト要員がテスト等を実行させるための入力を行うテスト端末３１１１、３１１２と、ネットワークを介して接続される現行環境である現行サーバ３３０１、３３０２とこれを利用するための各利用者端末で構成される。そして、リリース管理サーバ３００では、図５から７に示す各種テーブルを保持している。また、マスタ管理サーバ３２０、現行サーバ３３０１、３３０２においては、業務実行するプログラム等が格納されている。また、各端末においても、いわゆるコンピュータで実現されるものであり、このプログラムに従って、CPUのような演算装置が各種処理を実行する（各サーバについても同様）。また、リリース管理サーバ３００は、複数の現行サーバ(システム)とネットワークを介して接続され、それぞれ保守（バージョンアップ）が可能になっている。

なお、本実施形態が対象とするバージョンアップにおいては、そのテストを「変更機能」単位で行う。これは、追加、修正されるモジュールやこれらと関連して動作する既存のモジュールを単位とし、これら関連は、変更表と呼ばれる対応表で対応付けられている。この変更表は、紙媒体であっても構わないし、電子媒体に電子的に記録されていもよい。

以下、図４のフローチャートを用いて、本実施形態の処理の詳細を説明する。本実施形態では、上述した（２）の処理を行うものである。

ステップ４０１において、リリース管理サーバ３００は、各テスト機能について、当該テストでテストされるモジュールを、テスト対策機能管理表（図５）に登録する。これは、テスト要員からの入力に従ってテスト端末３１１１や３１１２からの入力ないし図示しない設計情報に従って、構成欄に「既存」「新規」を登録するものである。ここで、「既存」とはバージョンアップ前から存在するモジュールを示し、「新規」とは、バージョンアップにより追加、ないし、修正されるモジュールを示す。そして、該当するテスト対策機能において、テストされるモジュールに記録される。これは、上述した変更表に基づいて特定され、テスト要員の入力に従い、あるいは電子的なデータに従って特定される。

次に、ステップ４０２において、リリース管理サーバ３００は、テストすべきテスト対策機能を特定する。これは、テスト要員からの入力に従ってテスト端末３１１１や３１１２からの入力に従って、特定すればよい。

次に、ステップ４０３において、特定されたテスト対策機能について、変更機能ＩＤの有無を判断する。変更機能ＩＤは、他のテスト対策機能でのテストにおいて、修正されたこと、および修正されたテストのテスト対策機能を識別するものである。このために、まず、テスト対策機能管理表（図５）を用いて、特定されたテスト対策機能でテストされるモジュールを、構成欄から判断する。そして、テストされるモジュールについて、マスタテーブル（図６）の対応するレコードに変更機能ＩＤ６００７が登録されているかを判断する。この結果、登録されている場合は、ステップ４０４に進む。登録されていない場合には、ステップ４０５に進む。

ステップ４０４において、リリース管理サーバ３００は、変更機能ＩＤを用いて、該当する実体モジュールを特定する。これは、以下の処理により実現される。まず、変更機能ＩＤを抽出する。そして、抽出された変更機能ＩＤをキーに、対象となるモジュールが修正(変更)されたテスト対象機能と、モジュールを識別する識別子を特定する。そして、これらをキーに、図７に示す修正プログラム管理表を検索し、最新（ないし有効な）モジュールを特定する。そして、このモジュールを含む当該テスト対象機能に必要なモジュールを、テスト環境に投入する。

また、ステップ４０５において、ステップ４０３で変更機能ＩＤ６００７が登録されていないと判断された場合、マスタをユーザテスト環境２２０に投入する。

ステップ４０６では、新規作成・修正されるモジュールをテスト環境に投入する。以降、ステップ４０４、４０５、４０６において投入したモジュールを対象に、そのモジュールのプロパティ日付情報をテスト対策機能管理表（図５）の初期タイムスタンプ５００７に登録する。そして、ステップ４０８に機能毎テストの実施を開始する。

ステップ４０９では、テスト実施した回数をカウントし、テスト対策機能管理表（図５）のテスト回数５００６に登録する。テスト回数はプログラムを変更し、テスト実施した回数を示す指標である。

次に、ステップ４１０において、テスト対象の機能について、テストを行い、テスト要員が実行結果をテスト用のチェックリストに記載する想定結果と比較し、不具合の有無を判断する。不具合が生じた場合、プログラムの変更を実施した後に、ステップ４０８に戻り、テストを再実施する。不具合がない場合、ステップ４１２に進む。

ステップ４１２において、該当機能の各構成モジュールのプロパティ日付情報をテスト対策機能管理表（図５）の最終タイムスタンプ５００８に登録する。

次に、ステップ４１３で、テスト対策機能管理表（図５）の構成欄５００４からモジュールの新規か既存を判断し、新規であれば、ステップ４１５に進み、テスト対策機能管理表（図５）の確定フラグ５００９が有効であることを示すように記録する。

また、バージョンアップ前から存在する既存のモジュールであれば、ステップ４１４に進み、最終タイムスタンプ５００８と初期タイムスタンプ５００７が等しいかを判断する。異なった場合には、確定フラグ５００９を有効にする。確定フラグを有効にしたモジュールは変更されたことを意味している。ステップ４１６において、修正されたモジュールの情報を修正モジュール管理表（図７）に登録する。ここで、テスト対象機能を区別するための変更機能IDとモジュールIDのほか、モジュールの実体をテスト環境以外のリリース管理サーバ上の保存先に格納しておくディレクトリの情報を記憶する。

次に、ステップ４１７にマスタ管理表（図６）の変更機能ID６００７を登録する。そして、ステップ４１８にテスト要員がテスト項目を消化し、テスト完了を判断する。完了した場合、該当機能のテストにおいて、リリース構成を確定する（ステップ４１９）。

なお、上述した実施形態では、変更機能ＩＤを用いたが、これを省略したものも本発明の一態様に含まれる。つまり、ステップ４０３やステップ４１６、４１７を省略し、構成（既存、新規）、確定フラグおよびタイムスタンプを用いた処理であってもよい。

１００…保守環境、１１０…ネットワーク、１２０、１３０…ユーザ稼動環境、
２００…マスタ管理サーバ、２００１〜２００５…マスタ世代構成、２１０…リリース管理サーバ、２２０…ユーザテストサーバ、２３０…ネットワーク、２４０…ユーザ稼動サーバ、３００…リリース管理サーバ、３１０…テストサーバ、３２０…マスタ管理サーバ、３１１１、３１１２…テスト用端末、３３０１…ユーザＡ現用サーバ、３３０２ユーザＡ待機サーバ、３４０…ユーザＡ監視サーバ、３５０１、３５０２…ユーザ利用者端末、４０１〜４１９…フローチャート、５００１〜５００９…テスト対策機能管理表項目、
６００１〜６００７…マスタ管理表項目、７００１〜７００３…修正モジュール管理表項目

Claims (2)

1. 複数のモジュールで構成される業務システムにおけるバージョンアップ管理方法であって、前記業務システムのバージョンアップにおけるテスト単位であり、複数のモジュールがテストされるテスト環境を複数格納したテストサーバおよび前記テスト環境を利用してテストを行う利用者が利用するテスト端末と接続されたリリース管理サーバが以下の処理を実行するバージョンアップ管理方法において、
   前記テスト端末からの入力に従って、前記テストサーバに格納された複数のテスト環境から、テスト対象環境を特定し、
   特定されたテスト対象環境について、当該テスト対象環境のテストによりモジュールに修正があったかを、当該リリース管理サーバが有するテスト対策機能管理テーブルに格納された当該モジュールに対するタイムスタンプに基づいて判断し、
   当該判断の結果、修正があった場合、前記テスト対象環境を管理するテスト対象環境表の該当するモジュールについて、前記テスト対策機能管理テーブルへ修正があった旨の示す確定フラグを記録することを特徴とする業務システムにおけるバージョンアップ管理方法。
2. 請求項１に記載のバージョンアップ管理方法において、
   前記リリース管理サーバは、
   当該リリース管理サーバが有する各モジュールに関する情報を格納するマスタテーブルに対して、前記テストにおいてモジュールに修正があった場合、当該モジュールに対応付けて修正されたテストのテスト対象環境を識別する変更機能ＩＤを登録し、
   特定された前記テスト対象環境においてテストされるモジュールの修正の有無および修正が施されたテスト対象環境を、前記変更機能ＩＤを用いて判断し、
   修正があると判断された場合、修正が施されたテスト対象環境と当該モジュールを識別する識別子に基づいて、有効なモジュールを特定し、
   特定されたモジュールを含む情報を用いて前記テストを実行することを特徴とする業務システムにおけるバージョンアップ管理方法。

Images