JP2012203580A - 移行テスト支援システム、移行テスト支援プログラム、移行テスト支援方法 - Google Patents

Abstract

【課題】システム移行テストにおいて、現行システムと新システムとの間の差分を解析するにあたり、アプリケーションが改修されている部分を解析対象から除外し、新旧システム間の相違原因を分析し易くすることを目的とする。
【解決手段】本発明に係る移行テスト支援システムは、アプリケーションが改修されている箇所を記述した改修タグをアプリケーションの実行結果トレースから読み込み、その部分を現行システムと新システムの間の比較対象から除外する。
【選択図】図１２

Description

本発明は、計算機のＯＳ（オペレーティングシステム）などを更改する際にともなうシステム移行を支援する技術に関する。

近年、ＰＣ（パーソナルコンピュータ）サーバの性能が向上するに伴い、従来メインフレームが担ってきた基幹系システムが、オープンシステムに移行されつつある。ＰＣサーバなどを用いて構成されているオープン系システムは、性能向上の進度が速く、次々と後継機種が登場し、製品の保証期間は例えば約５年程度と短い。これに対し、基幹系のようなサービスは、基本的なサービスであるためサービス内容が変わらないものが多いこと、稼働実績のあるサービスを更改することによる障害を起こしてはならないことなどの理由により、できる限り長期に稼働させたいというニーズがある。そのため、基幹系システムを移行する際には、例え同じハードウェアを交換する場合であっても、必ず移行テストが実施される。

下記特許文献１には、移行前後のシステムのトレース情報を比較し、関数の呼び出し順序、引数が異なる個所などを発見し、変更されたモジュール一覧から、どのモジュールにデグレーションの原因があるかを予測する手法が記載されている。

特開平１０−３２０２３４号公報

システム移行を実施する際には、ハードウェア、ソフトウェアともに、その時点で提供されているバージョンにアップデートされる場合が多い。したがって、システム側の動作が変化することは容易に想定できる。

基幹系のコンピュータシステムによるサービスは基本的なサービスであるので、コンピュータシステムが更改されてもサービス内容が変わらないことが要求される場合が多い。そのため、移行前のアプリケーションが移行後もそのまま動作するように新システムを構築することが重要である。もっとも、システムに対する入出力データが移行の前後で維持されていれば、システム内部の動作が変更されていたとしても、特段の支障はないと考えられる。したがって、アプリケーションには手を加えず、システム移行後も入出力データが移行前と同じであることを保証する必要がある。

しかし実際には、ユーザサイドにおいて、システム運用中にアプリケーションに修正や機能追加等の改修が実施されている場合がある。この場合、システム移行前後において入出力データに予期しない相違が生じる可能性がある。このとき、その相違がシステム移行に起因するものであるのか、それともアプリケーションの改修が原因となっているのかを切り分ける必要がある。

特許文献１に記載されている技術では、新旧システムの入出力ログやトレース情報を比較することにより、移行によって生じたシステム構成モジュールの相違点を抽出することはできるが、アプリケーション自体の更改も相違点として抽出するため、相違の原因を容易に切り分けることが難しい。

本発明は、上記のような課題を解決するためになされたものであり、システム移行テストにおいて、現行システムと新システムとの間の差分を解析するにあたり、アプリケーションが改修されている部分を解析対象から除外し、新旧システム間の相違原因を分析し易くすることを主な目的の一つとする。

本発明に係る移行テスト支援システムの一態様は、アプリケーションが改修されている箇所を記述した改修タグをアプリケーションの実行結果トレースから読み込み、その部分を現行システムと新システムの間の比較対象から除外する。

本発明に係る移行テスト支援システムによれば、アプリケーションの改修箇所を実行結果トレースから読み込むことにより、現行システムと新システムの間の相違がアプリケーションの改修によるものであるか否かを識別することができる。これにより、相違の原因を早期に発見することができる。

実施形態１に係る移行テスト支援システム１０００の構成図である。 テスト支援サーバ１００の詳細構成を示す図である。 ＷｅｂＡＰサーバ２１０の構成を示す図である。 アプリケーション２１１の実行結果トレースを生成する処理のフローチャートである。 新トレースログ１１２３の構成とデータ例を示す図である。 テスト支援サーバ１００の処理フローである。 ステップＳ６００の詳細を示す図である。 現行セッション管理テーブル１１１１の構成とデータ例を示す図である。 現行入出力ログ１１１２の構成とデータ例を示す図である。 リプレイテストシナリオ１１３の構成とデータ例を示す図である。 ステップＳ６０１の詳細を示すフローチャートである。 ステップＳ６０７の詳細を示すフローチャートである。

＜実施の形態１＞
図１は、本発明の実施形態１に係る移行テスト支援システム１０００の構成図である。移行テスト支援システム１０００は、テスト支援サーバ１００、現行システム２００、新システム３００及び端末４００を有する。これらはネットワークを介して接続されている。

テスト支援サーバ１００は、現行システム２００を新システム３００に移行する際に、アプリケーションの動作が変更されていないかをテストする移行テスト支援を実施するサーバ装置である。テスト支援サーバ１００は、現行システムログ１１１と新システムログ１１２に記録されているログに基づき、移行テスト支援を実施する。これらログ及びテスト支援サーバ１００の詳細は後述する。

現行システム２００は、Ｗｅｂ３階層モデルに準じたＷｅｂアプリケーションを実行する情報システムであり、ＷｅｂＡＰサーバ２１０及びＤＢＭＳ２２０を有する。ＷｅｂＡＰサーバ２１０は、Ｗｅｂアプリケーションとして実装されたアプリケーション（ＡＰ）２１１と、開発／実行環境２１２とを有する。開発／実行環境２１２は、アプリケーション開発を実施するための開発ソフトウェアなどを含むソフトウェア群である。詳細は後述する。ＤＢＭＳ２２０は、アプリケーション２１１が利用するデータベース（ＤＢ）へのアクセス等を管理する機能を有する。

新システム３００は、現行システム２００のうち、ＷｅｂＡＰサーバ２１０を新ＷｅｂＡＰサーバ３１０に置き換えたものである。これにともない、Ｗｅｂアプリケーションを提供するためのミドルウェアが新バージョンに置き換えられている。また、移行前におけるアプリケーション２１１は、新システム３００の下では改修アプリケーション３１１に置き換えられている場合もある。

新システム３００は、アプリケーション２１１の動作が現行システム２００との間で相違ないことを保証する必要がある。システム内部の動作は、現行システム２００と新システム３００の間で異なっていても問わないことにする。システム内部の動作とは、例えばＯＳやＷｅｂサーバなどのミドルウェアの動作がこれに相当する。

ＷｅｂＡＰサーバ２１０と新ＷｅｂＡＰサーバ３１０は、本実施形態１における「アプリケーション実行装置」に相当する。

図２は、テスト支援サーバ１００の詳細構成を示す図である。テスト支援サーバ１００は、記憶装置１１０、メモリ１２０、ネットワークインタフェース１３０、プロセッサ１４０、入力装置１５０、出力装置１６０及びバス１７０を備える。

記憶装置１１０は、ハードディスク装置などの不揮発性記憶装置であり、図１で説明した現行システムログ１１１と新システムログ１１２を格納する。これらログはメモリ１２０上に展開することもできる。図２では、記載の便宜上、メモリ１２０上にこれらログを展開した例を示した。

メモリ１２０は、プロセッサ１４０が実行するプログラム、現行システムログ１１１、新システムログ１１２及びリプレイテストシナリオ１１３を格納する記憶装置である。これらプログラム等については後述する。以下では記載の便宜上、各プログラムを動作主体として説明する場合があるが、実際にこれらプログラムを実行するのはプロセッサ１４０であることを付言しておく。

ネットワークインタフェース１３０は、テスト支援サーバ１００とネットワークを接続するインタフェースである。入力装置１５０は、ユーザがテスト支援サーバ１００を操作するためのキーボード、マウスなどの操作装置である。出力装置１６０は、テスト支援サーバ１００が実施した処理などを表示するディスプレイ等の画面出力装置である。バス１７０は、上記各機能部を接続する。

メモリ１２０は、プロセッサ１４０が実行する移行テスト支援プログラムとして、通信部１４１、リプレイテスト実行部１４２、トレース情報受信部１４３、新システムログ情報処理部１４４、現行システムログ情報取得部１４５及び差分抽出部１４６を格納する。これら機能部は一体的に構成してもよい。メモリ１２０はその他、現行システムログ１１１を構成する各ログとして、現行セッション管理テーブル１１１１、現行入出力ログ１１１２及び現行テストログ１１１３を格納する。また、新システムログ１１２を構成する各ログとして、新セッション管理テーブル１１２１、新入出力ログ１１２２、新トレースログ１１２３及び新テストログ１１２４を格納する。

通信部１４１は、ネットワークインタフェース１３０が受信したデータを取得し、リプレイテスト実行部１４２が送信するデータをネットワークインタフェース１３０へ出力する。

リプレイテスト実行部１４２は、現行システムログ情報取得部１４５が取得した現行セッション管理テーブル１１１１及び現行入出力ログ１１１２から、新システム３００に投入するリプレイテストシナリオ１１３を生成する。また、リプレイテストシナリオ１１３にしたがって、新システム３００へ入力データを送信し、新システム３００から出力データを受信して、これに基づき新セッション管理テーブル１１２１及び新入出力ログ１１２２を生成する。

トレース情報受信部１４３は、図３に後述する新システム３００の開発／実行環境２１２が出力するアプリケーション実行時の新トレースログ１１２３を取得し、新システムログ情報処理部１４４へ引き渡す。新トレースログ１１２３は、新システム３００を構成する少なくとも１つ以上のサーバミドルウェアが個別にあるいは連携して出力する。ここでいうサーバミドルウェアは、例えば新ＷｅｂＡＰサーバ３１０が実行するＷｅｂサーバ及びアプリケーションサーバ及びＤＢＭＳ２２０などがこれに相当する。

新システムログ情報処理部１４４は、リプレイテスト実行部１４２がリプレイテストを実行して得た新セッション管理テーブル１１２１及び新入出力ログ１１２２を受け取り、またトレース情報受信部１４３から新トレースログ１１２３を受け取る。

現行システムログ情報取得部１４５は、現行システム２００から現行システムログ１１１を取得し、差分抽出部１４６へ引き渡す。

差分抽出部１４６は、現行テストログ１１１３と新テストログ１１２４を比較し、差分を検出する。この際、新テストログ１１２４内にアプリケーション２１１を改修した旨を示す改修タグが付加されている場合は、その部分の処理については差分検出の対象から除外して両者を比較する。詳細は後述の図１２で説明する。

図３は、ＷｅｂＡＰサーバ２１０の構成を示す図である。新ＷｅｂＡＰサーバ３１０も同様の構成を有する。ＷｅｂＡＰサーバ２１０は、ＡＰ２１１と開発／実効環境２１２の他、メモリ２１３、プロセッサ２１４、記憶装置２１５、入力装置２１６、出力装置２１７、ネットワークインタフェース２１８及びバス２１９を備える。記憶装置２１５、入力装置２１６、出力装置２１７、ネットワークインタフェース２１８及びバス２１９の役割についてはテスト支援サーバ１００と同様であるため、説明を省略する。

開発／実行環境２１２は、プログラム開発ツール及びその実行モジュールなど、アプリケーション２１１を開発するために用いられるソフトウェアを集約したものである。開発／実行環境２１２は、スタンドアロンアプリケーションとして構成することもできるし、ＷｅｂＡＰサーバ２１０配下のアプリケーションとして構成することもできる。

メモリ２１３は、開発／実行環境２１２を構成するプログラムモジュールとして、通信部２１２１、アプリケーションコンパイル部２１２２、アプリケーション実行部２１２３、トレース情報送信部２１２４及びアプリケーションプログラミングインタフェース（ＡＰＩ）２１２５を格納する。新ＷｅｂＡＰサーバ３１０は、さらに新トレースログ１１２３を格納する。アプリケーションコンパイル部２１２２は、さらにアプリケーション改修検出部２１２２１と実行ファイル生成部２１２２２を有する。アプリケーション実行部２１２３は、さらに実行部２１２３１とトレース情報記録部２１２３２を有する。

通信部２１２１は、ネットワークインタフェース２１８から、アプリケーション２１１に対する入力データ及びテスト支援サーバ１００からのシステムログ取得要求を受信し、これらをアプリケーション２１１やトレース情報送信部２１２４に引き渡す。また、アプリケーション２１１が送信するデータや、アプリケーション２１１を実行して得られるトレース情報を、ネットワークインタフェース２１８へ出力する。

実行ファイル生成部２１２２２は、アプリケーションソースコードをコンパイルして実行ファイルを生成する。

アプリケーション改修検出部２１２２１は、実行ファイル生成部２１２２２がアプリケーション２１１のソースコードをコンパイルする時、ソースコードのうち改修されている部分及び改修されている部分を呼び出している部分に改修タグを付ける。改修タグを付ける処理は、ユーザがソースコードを改修した際にアプリケーション改修検出部２１２２１が自動的に実施してもよいし、ＡＰＩ２１２５を介してユーザが改修箇所を指定するようにしてもよい。

実行部２１２３１は、実行ファイル生成部２１２２２がソースコードをコンパイルすることによって生成したアプリケーション２１１の実行ファイルを起動して実行する。

トレース情報記録部２１２３２は、実行部２１２３１がアプリケーション２１１を実行する際、トレースＩＤ等の識別子を割り当て、アプリケーション２１１に対する入力から出力までのシステム内部動作をトレースした情報を記録する。

トレース情報送信部２１２４は、テスト支援サーバ１００からの要求に応じて、トレース情報記録部２１２３２が記録したトレース情報を送信する。

ＡＰＩ２１２５は、現行システム２００と新システム３００が有するシステム要素のうち、新バージョンに置き換えられているミドルウェア等が有するＡＰＩである。例えばＷｅｂアプリケーションを実行するために用いるミドルウェアやＤＢＭＳなどが提供するＡＰＩがこれに相当する。

以上、移行テスト支援システム１０００の構成について説明した。以下の図４〜図７では、移行テスト支援システム１０００の動作手順について説明する。

図４は、新システム３００におけるアプリケーションコンパイル部２１２２とアプリケーション実行部２１２３が、アプリケーション２１１（又は改修アプリケーション３１１、以下図４において同様）の実行結果トレースを生成する処理のフローチャートである。実行結果トレースは、アプリケーション２１１又は改修アプリケーション３１１の内部的な処理状態を記録するログである。実行結果トレースは特に、アプリケーションが改修されている箇所を示す改修タグを記録する意義がある。以下、図４の各ステップについて説明する。

（図４：ステップＳ４００）
アプリケーションコンパイル部２１２２は、例えばユーザの選択に基づき、アプリケーション２１１のソースコードをコンパイルするか、それともアプリケーション２１１を実行して実行結果トレースを生成するかを判断する。コンパイルを実施する場合はステップＳ４０１へ進み、実行結果トレースを生成する場合はステップＳ４０８へスキップする。

（図４：ステップＳ４０１〜Ｓ４０２）
アプリケーションコンパイル部２１２２は、アプリケーション２１１のソースコードを適当な分量（例えば１命令文）読み込む（Ｓ４０１）。アプリケーションコンパイル部２１２２は、ソースコード内に改修タグが付加されているかどうかを検出する（Ｓ４０２）。改修タグが付加されている場合はステップＳ４０３へ進み、付加されていない場合はステップＳ４０４へスキップする。

（図４：ステップＳ４０２：補足）
ソースコード内の改修タグは、ユーザがソースコードを改修するときに手動で付加してもよいし、ソースコードが改修された旨をプログラム開発ツールなどが自動検出して自動的に付加してもよい。

（図４：ステップＳ４０３）
アプリケーションコンパイル部２１２２は、アプリケーション２１１のソースコード内の改修されている箇所に、改修タグが付加されている旨のトレース情報を出力するプログラムコードを埋め込む。例えば、実行結果トレースのファイル名を指定し、ソースコード内の改修されている箇所の行番号、関数名などを実行結果トレースに書き込むようなコードを埋め込む。実行結果トレースの例は後述の図５で説明する。

（図４：ステップＳ４０４〜Ｓ４０５）
アプリケーションコンパイル部２１２２は、ステップＳ４０２で検出した、改修タグが付加されている箇所のプログラム命令のうち、ＡＰＩ２１２５を利用しているものがあるか否かを判定する（Ｓ４０４）。改修タグが付加されているプログラム命令のうちＡＰＩ２１２５を利用しているものがある場合はステップＳ４０６へ進み、ない場合はステップＳ４０７へスキップする（Ｓ４０５）。

（図４：ステップＳ４０４〜Ｓ４０５：補足）
本ステップは、アプリケーション２１１の改修された部分が、ＡＰＩ２１２５を介してミドルウェアと連結しているか否かを判定するための準備としての意義がある。改修された部分のプログラム命令がＡＰＩ２１２５を利用している場合は、その部分はＡＰＩ２１２５を介してミドルウェアの機能を利用しているため、ミドルウェアを更改するとその影響がアプリケーション２１１にも及ぶ可能性があると考えられる。アプリケーション２１１のうち動作がシステム移行前後で異なる場合、その部分がＡＰＩ２１２５を利用していなければ、動作の相違はアプリケーション２１１自体の改修によって生じたと推測することができる。

（図４：ステップＳ４０６）
アプリケーションコンパイル部２１２２は、改修タグが付加されているプログラム命令がＡＰＩ２１２５を使用している旨のトレース情報を出力するプログラムコードを埋め込む。例えばミドルウェア更改によってＡＰＩ２１２５に関連する部分が更改されたか否かなどの基準により、ミドルウェア更改の影響がアプリケーション２１１に及ぶか否かを推定し、その結果をトレース情報に出力してもよい。

（図４：ステップＳ４０７）
アプリケーションコンパイル部２１２２は、アプリケーション２１１のソースコードをコンパイルして実行コードを生成する。

（図４：ステップＳ４０８〜Ｓ４０９）
アプリケーション実行部２１２３は、例えばユーザの選択に基づき、アプリケーション２１１を実行するよう指示されているか否かを判断する。実行する場合はステップＳ４０９へ進んでアプリケーション２１１を起動し（Ｓ４０９）、実行しない場合は本処理フローを終了する。

（図４：ステップＳ４１０）
アプリケーション実行部２１２３は、アプリケーションコンパイル部２１２２が生成した実行コードを読み込んで実行する。

（図４：ステップＳ４１１〜Ｓ４１２）
アプリケーション実行部２１２３は、実行コード内に、アプリケーションコンパイル部２１２２がステップＳ４０３でソースコード内に埋め込んだプログラムコードが含まれているか否かを判定する（Ｓ４１２）。含まれている場合は、改修タグを記述したトレース情報を新トレースログ１１２３に記録する（Ｓ４１２）。

（図４：ステップＳ４１３〜Ｓ４１４）
アプリケーション実行部２１２３は、実行コード内に、アプリケーションコンパイル部２１２２がステップＳ４０６でソースコード内に埋め込んだプログラムコードが含まれているか否かを判定する（Ｓ４１３）。含まれている場合は、改修タグが付加されているプログラム命令がＡＰＩ２１２５を使用している旨のトレース情報を新トレースログ１１２３に記録する（Ｓ４１４）。

（図４：ステップＳ４１５）
アプリケーション実行部２１２３は、アプリケーション２１１が終了するまで、Ｓ４１０〜Ｓ４１４を繰り返し実行する。

図５は、新トレースログ１１２３の構成とデータ例を示す図である。新トレースログ１１２３は、アプリケーション実行部２１２３が図４で説明した処理フローにしたがって新システム３００におけるアプリケーション２１１（又は改修アプリケーション３１１、以下図５において同じ）を実行することによって得られる、アプリケーション２１１の内部的な動作ログである。現行テストログ１１１３及び新テストログ１１２４も、同様のフォーマットを有する。

新トレースログ１１２３は、１レコード内に、時刻情報１１２３０１、プロセスＩＤ１１２３０２、トレースＩＤ１１２３０３、セッションＩＤ１１２３０４、送信元アドレス１１２３０５、宛先アドレス１１２３０６、モジュール名１１２３０７、処理コード１１２３０８、ＡＰＩフラグ１１２３１２、改修タグ１１２３１３及びデータ１１２３１４を格納する。

時刻情報１１２３０１は、当該レコードが発生した時刻を保持する。プロセスＩＤ１１２３０２は、当該レコードを出力するプログラムのプロセス識別子を保持する。トレースＩＤ１１２３０３は、当該レコードがどの入力データに対するトレース情報であるのかを対応付けるための識別子を保持する。セッションＩＤ１１２３０４は、当該レコードを記録したアプリケーション２１１へその時点で割り当てられているセッション識別子を保持する。

送信元アドレス１１２３０５は、当該レコードが通信処理に関するものである場合、当該通信処理の送信元アドレスを保持する。宛先アドレス１１２３０６は、当該レコードが通信処理に関するものである場合、当該通信処理の宛先アドレスを保持する。

モジュール名１１２３０７は、当該レコードを出力したプログラムコードのモジュール名を保持する。処理コード１１２３０８は、当該レコードを出力したプログラムの関数名１１２３０９、入力引数１１２３１０、出力値１１２３１１を保持する。

ＡＰＩフラグ１１２３１２は、処理コード１１２３０８が指定するプログラムコードがＡＰＩ１１２５を利用しているか否かを示す値を保持する。改修タグ１１２３１３は、処理コード１１２３０８が指定するプログラムコードが改修されているか否かを示す値を保持する。例えば、改修タグ１１２３１３が“０”である場合は改修なしを、“１”である場合は当該コードが改修されていることを、“２”である場合は改修されたコードを利用していること等である。データ１１２３１４は、例えば当該レコードが通信処理に関するものである場合は、その通信データ、関係するメモリのデータ等を保持する。

図６は、テスト支援サーバ１００の処理フローである。以下、図６の各ステップについて説明する。
（図６：ステップＳ６００）
現行システムログ情報取得部１４５は、現行システムログ１１１を取得する。リプレイテスト実行部１４２は、現行システムログ１１１を用いて、リプレイテストシナリオ１１３を生成する。本ステップの詳細は、後述の図７で改めて説明する。

（図６：ステップＳ６０１）
リプレイテスト実行部１４２は、リプレイテストシナリオ１１３にしたがって、新システム３００のリプレイテストを実施する。リプレイテストは、新システム３００に対して現行システム２００と同様の入力データを与え、出力データを記録することにより、現行システム２００の動作を再現するテストである。本ステップの詳細は、後述の図１１で改めて説明する。

（図６：ステップＳ６０２〜Ｓ６０４）
リプレイテスト実行部１４２は、現行入出力ログ１１１２を読み込み（Ｓ６０２）、リプレイテストによって出力した新入出力ログ１１２２と比較する（Ｓ６０３）。現行入出力ログ１１１２における入力データと出力データの対応関係が、新入出力ログ１１２２における入力データと出力データの対応関係とは異なっている場合は、ステップＳ６０５へ進む。両者が同じである場合は、本処理フローを終了する（Ｓ６０４）。

（図６：ステップＳ６０３：補足）
現行入出力ログ１１１２と新入出力ログ１１２２の比較は、セッション識別子（セッションＩＤ）をキーとし、システムに対する入力データとシステムからの出力データとをそれぞれ比較することによって実施する。

（図６：ステップＳ６０５）
トレース情報受信部１４３は、新システム３００から新トレースログ１１２３を取得する。

（図６：ステップＳ６０６）
新システムログ情報処理部１４４は、新入出力ログ１１２２及び新トレースログ１１２３を、時刻情報１１２３０１やシステムがアプリケーション実行時に割り当てる識別子（例えば、プロセスＩＤ１１２３０２、トレースＩＤ１１２３０３、セッションＩＤ１１２３０４等）を基準として統合することにより、新テストログ１１２４を生成する。

（図６：ステップＳ６０７）
差分抽出部１４６は、現行テストログ１１１３におけるシステム入出力と、新テストログ１１２４におけるシステム入出力との間の差分を抽出する。本ステップの詳細は、後述の図１２で説明する。

（図６：ステップＳ６０８〜Ｓ６０９）
差分抽出部１４６は、現行テストログ１１１３と新テストログ１１２４の間に差分があるか否かを判断する（Ｓ６０８）。差分がある場合はその差分を記述した差分情報を記憶装置１１０に書き込み、差分がない場合は本処理フローを終了する（Ｓ６０９）。

図７は、ステップＳ６００の詳細を示す図である。以下、図７の各ステップについて説明する。
（図７：ステップＳ７００）
リプレイテスト実行部１４２は、後述の図８で説明する現行セッション管理テーブル１１１１を読み込む。現行セッション管理テーブル１１１１は、端末４００と現行システム２００の間の通信処理を、主にネットワークの観点から通信セッション単位で記録したデータテーブルである。すなわち本ステップは、端末４００と現行システム２００の間のデータ入出力を通信セッション単位で再現しようとするものである。

（図７：ステップＳ７０１〜Ｓ７０２）
リプレイテスト実行部１４２は、現行セッション管理テーブル１１１１から１レコード分の情報を読み取る（Ｓ７０１）。現行セッション管理テーブル１１１１にレコードが記録されていればその情報を取得し（Ｓ７０２）、記録されていなければステップＳ７０６へスキップする。

（図７：ステップＳ７０３）
現行システムログ情報取得部１４５は、後述の図９で説明する現行入出力ログ１１１２を読み込む。現行入出力ログ１１１２は、端末４００と現行システム２００の間の通信処理を、主にアプリケーション２１１に対する入出力データの観点から通信セッション単位で記録したデータテーブルである。現行セッション管理テーブル１１１１はネットワーク情報を記録しているのに対して、現行入出力ログ１１１２は入出力データを記録している点が異なる。すなわち、端末４００と現行システム２００の間の通信処理は、現行セッション管理テーブル１１１１と現行入出力ログ１１１２にまたがって記録されている。

（図７：ステップＳ７０４）
現行システムログ情報取得部１４５は、ステップＳ７０２で取得したレコード内に記録されているセッションＩＤをキーとして、現行入出力ログ１１１２の対応するレコードを特定し、そのレコードに記録されている入出力データを取得する。

（図７：ステップＳ７０５〜Ｓ７０６）
リプレイテスト実行部１４２は、ステップＳ７０２〜Ｓ７０４で取得した各情報を、後述の図１０で説明するリプレイテストシナリオ１１３に記録する（Ｓ７０５）。リプレイテスト実行部１４２は、現行セッション管理テーブル１１１１が他のセッション記録を保持していればステップＳ７０２に戻って同様の処理を繰り返し、保持していなければ本処理フローを終了する（Ｓ７０６）。

図８は、現行セッション管理テーブル１１１１の構成とデータ例を示す図である。新セッション管理テーブル１１２１も同様の構成を有する。現行セッション管理テーブル１１１１は、端末４００と現行システム２００の間の通信処理を通信セッション単位で記録したデータテーブルであり、新セッションＩＤ１１１１１、送信元アドレス１１１１２、宛先アドレス１１１１３、開始時刻１１１１４、終了時刻１１１１５、旧セッションＩＤ１１１１６を格納する。

新セッションＩＤ１１１１１は、新システム３００の新ＷｅｂＡＰサーバ３１０が端末４００に対して割り当てるセッション識別子を保持する。送信元アドレス１１１１２と宛先アドレス１１１１３は、新セッションＩＤ１１１１１の値で識別される通信セッションにおける通信元と通信先それぞれのアドレス情報を保持する。開始時刻１１１１４と終了時刻１１１１５は、新セッションＩＤ１１１１１の値で識別されるセッションが開始した時刻と終了した時刻をそれぞれ保持する。旧セッションＩＤ１１１１６は、現行システム２００のＷｅｂＡＰサーバ２１０が端末４００に対して割り当てるセッション識別子を保持する。

リプレイテストシナリオ１１３を作成する際には、あらかじめ現行システム２００を実行して現行システムログ１１１を生成し、現行セッション管理テーブル１１１１と現行入出力１１１２にレコードを格納しておく必要がある。ただしこの時点では、新セッションＩＤ１１１１１については空にしておく。テスト支援サーバ１００のリプレイテスト実行部１４２は、ステップＳ６０１のリプレイテストを実施する過程で、旧セッションＩＤ１１１１６に対応する新セッションＩＤ１１１１１の値をセットする。

図８の１行目のレコードは、旧セッションＩＤ１１１１６「46wetj3」に対応する現行入出力ログ１１１２のレコードを用いてリプレイテストを実施した結果、新システム３００においては同じ入出力データに対して新セッションＩＤ１１１１１「abcdef」が割り当てられたことが記録されている。

新セッションＩＤ１１１１１は、旧セッションＩＤ１１１１６に対応する通信セッションを新システム３００上で再現する際に新システム３００が割り当てるセッションＩＤである。新セッションＩＤ１１１１１の値は、現行セッション管理テーブル１１１１に記録してもよいし、新セッション管理テーブル１１２１に記録してもよいし、双方に記録してもよい。

図９は、現行入出力ログ１１１２の構成とデータ例を示す図である。新入出力ログ１１２２も同様の構成を有する。現行入出力ログ１１１２は、時刻情報１１１２１、セッションＩＤ１１１２２、送信元アドレス１１１２３、宛先アドレス１１１２４、シーケンス番号１１１２５、データ１１１２６を格納する。

時刻情報１１１２１は、現行システム２００に対する端末４００からのデータ入出力が発生した時点の時刻を保持する。セッションＩＤ１１１２２は、ＷｅｂＡＰサーバ２１０が端末４００に対して発行したセッション識別子を保持する。

送信元アドレス１１１２３と宛先アドレス１１１２４は、セッションＩＤ１１１２２の値で識別される通信セッションにおける通信元と通信先それぞれのアドレス情報を保持する。セッションＩＤ１１１２２の値が同じレコードは、端末４００が送信元になる場合とそれに対する応答としてＷｅｂＡＰサーバ２１０が送信元になる場合のいずれかを記録したものである。

シーケンス番号１１１２５は、セッションＩＤ１１１２２の値で識別される通信セッションのシーケンス番号を保持する。データ１１１２６は、セッションＩＤ１１１２２の値で識別される通信セッションにおける現行システム２００に対する入力データ又は現行システム２００からの出力データを保持する。

図９の１行目のレコードと３行目のレコードは、セッションＩＤ１１１２１がともに同じ「abcdef」であるため、いずれか一方が現行システム２００に対する入力、もう一方が現行システム２００からの出力を記録したレコードであると想定される。この場合は１行目のレコードがＷｅｂＡＰサーバ２１０に対するＨＴＴＰ ＰＯＳＴリクエストを記録したレコードであり、３行目のレコードがＷｅｂＡＰサーバ２１０からの応答を記録したレコードである。

図１０は、リプレイテストシナリオ１１３の構成とデータ例を示す図である。リプレイテストシナリオ１１３は、時間情報１１３１、セッションＩＤ１１３２、送信元アドレス１１３３、宛先アドレス１１３４、データ１１３５を格納する。

時間情報１１３１は、端末４００と新システム３００の間の通信セッションを開始する時刻を起点とした、端末４００と新システム３００の間のデータ入出力を再現実施する時間間隔を示す。セッションＩＤ１１３２は、セッション識別子を保持する。送信元アドレス１１３３と宛先アドレス１１３４は、セッションＩＤ１１３２の値で識別される通信セッションにおける通信元と通信先それぞれのアドレス情報を保持する。データ１１３５は、セッションＩＤ１１３２の値で識別される通信セッションにおける新システム３００に対する入力データ又は新システム３００からの出力データを保持する。

リプレイテスト実行部１４２は、現行入出力ログ１１１２からセッションＩＤ１１１２２の値をキーにして全ての通信セッションについての入出力データを抽出し、リプレイテストシナリオ１１３へ記録する。

図１１は、ステップＳ６０１の詳細を示すフローチャートである。以下、図１１の各ステップについて説明する。
（図１１：ステップＳ１１００）
テスト支援サーバ１００のリプレイテスト実行部１４２は、ステップＳ６００で生成したリプレイテストシナリオ１１３から、リプレイテストを実施していないレコードを１つ読み込む。

（図１１：ステップＳ１１０１）
リプレイテスト実行部１４２は、リプレイテストシナリオ１１３の記述にしたがって、新セッション管理テーブル１１２１の各項目に値をセットする。具体的には、セッションＩＤ１１３２を旧セッションＩＤ１１１１６へ、送信側のアドレス情報を送信元アドレス１１１１２へ、受信側のアドレス情報を宛先アドレス１１１１３へ、現在時刻を開始時刻１１１１４へ、それぞれ登録する。新セッションＩＤ１１１１１は、本ステップの時点では空にしておく。

（図１１：ステップＳ１１０２）
リプレイテスト実行部１４２は、リプレイシナリオ１１３が記述している入力データを新システム３００に新たに投入する場合はステップＳ１１０３へ進み、その結果を新システム３００から受け取る場合はステップＳ１１１０へ進む。

（図１１：ステップＳ１１０３）
リプレイテスト実行部１４２は、リプレイテストシナリオ１１３から１件分の入力データを読み取る。すなわち、送信元アドレス１１３３が端末４００のアドレスと一致するレコードのデータ１１３５を読み取る。

（図１１：ステップＳ１１０４）
リプレイテスト実行部１４２は、ステップＳ１１０３で取得した入力データに現行システム２００上で割り当てられたセッションＩＤが含まれており、かつ新システム３００上のセッションＩＤを既に取得している場合は、現行システム２００上で割り当てられたセッションＩＤを新システム３００上のセッションＩＤに書き換える。

（図１１：ステップＳ１１０５）
リプレイテスト実行部１４２は、現在時刻を取得する。

（図１１：ステップＳ１１０６）
リプレイテスト実行部１４２は、ステップＳ１１０３で取得したレコードの時間情報１１３１が指定する時刻になるまで待機した後、新ＷｅｂＡＰサーバ３１０へ入力データを送信することにより、現行システム２００に対するデータ入力処理を再現する。

（図１１：ステップＳ１１０７）
リプレイテスト実行部１４２は、ステップＳ１１０６で新ＷｅｂＡＰサーバ３１０へ送信した入力データを、新入出力ログ１１２２へ記録する。

（図１１：ステップＳ１１０８〜Ｓ１１０９）
リプレイテスト実行部１４２は、リプレイテストシナリオ１１３の件数カウントｎを１インクリメントする（Ｓ１１０８）。リプレイテストシナリオ１１３が記述している全ての通信セッションについてリプレイテストを完了した場合はステップＳ１１１２へ進み、残っている場合はステップＳ１１０２に戻って同様の処理を繰り返す。

（図１１：ステップＳ１１１０）
リプレイテスト実行部１４２は、現在時刻を取得する。

（図１１：ステップＳ１１１１）
リプレイテスト実行部１４２は、新ＷｅｂＡＰサーバ３１０がステップＳ１１０６に対する応答として出力したデータを受信し、新入出力ログ１１２２へ記録する。

（図１１：ステップＳ１１１２〜Ｓ１１１３）
リプレイテスト実行部１４２は、現在時刻を取得して新セッション管理テーブル１１２１へ記録する（Ｓ１１１２）。リプレイテストシナリオ１１３に登録されている全ての通信セッションのテストが終了もしくはユーザによりリプレイテストの終了が指示された場合は本処理フローを終了し、リプレイテストを継続する場合はステップＳ１１００に戻って同様の処理を繰り返す。

図１２は、ステップＳ６０７の詳細を示すフローチャートである。以下、図１２の各ステップについて説明する。なお、本処理フローを実施するに先立ち、あらかじめ現行システム２００と新システム３００からそれぞれ実行結果トレースを取得し、これらをまとめて現行テストログ１１１３と新テストログ１１２４を生成しておく必要がある。現行テストログ１１１３と新テストログ１１２４のフォーマットは図５で説明した新トレースログ１１２３と同様であるため、以下の説明において現行テストログ１１１３と新テストログ１１２４が備える各項目について言及するときは、新トレースログ１１２３が備える項目と同じ符号を用いる。

（図１２：ステップＳ１２００）
テスト支援サーバ１００の現行システムログ情報取得部１４５は、現行テストログ１１１３を取得する。

（図１２：ステップＳ１２０１〜Ｓ１２０２）
差分抽出部１４６は、現行テストログ１１１３から１レコード（１通信セッション）分のログデータを読み込む（Ｓ１２０１）。差分抽出部１４６は、ステップＳ１２０１で読み込んだログデータからセッションＩＤ１１２３０４を取得する（Ｓ１２０２）。

（図１２：ステップＳ１２０３）
差分抽出部１４６は、ステップＳ１２０２で取得したセッションＩＤをキーにして新セッション管理テーブル１１２１と新テストログ１１２４を検索し、対応するレコードを特定する。差分抽出部１４６は、特定したレコードを読み込む。

（図１２：ステップＳ１２０４）
差分抽出部１４６は、ステップＳ１２０３で読み込んだ新テストログ１１２４のレコードに改修タグ１１２３１３が記録されているかどうかをチェックする。改修タグ１１２３１３が記録されている場合はステップＳ１２０８へ進み、記録されていない場合はステップＳ１２０５へ進む。

（図１２：ステップＳ１２０５）
差分抽出部１４６は、ステップＳ１２０３で読み込んだ新テストログ１１２４のレコードにおけるモジュール名１１２３０７及び処理コード１１２３０８が、ステップＳ１２０１で読み込んだ現行テストログ１１１３のレコードにおけるモジュール名１１２３０７及び処理コード１１２３０８と同じであるか否かをチェックする。同じである場合はステップＳ１２０６へ進み、異なる場合はステップＳ１２０９へ進む。

（図１２：ステップＳ１２０６）
差分抽出部１４６は、ステップＳ１２０３で読み込んだ新テストログ１１２４のレコードにおける入力引数１１２３１０が、ステップＳ１２０１で読み込んだ現行テストログ１１１３のレコードにおける入力引数１１２３１０と同じであるか否かをチェックする。同じである場合はステップＳ１２０７へ進み、異なる場合はステップＳ１２０９へ進む。

（図１２：ステップＳ１２０７）
差分抽出部１４６は、ステップＳ１２０３で読み込んだ新テストログ１１２４のレコードにおける出力値１１２３１１が、ステップＳ１２０１で読み込んだ現行テストログ１１１３のレコードにおける出力値１１２３１１と同じであるか否かをチェックする。同じである場合はステップＳ１２０８へ進み、異なる場合はステップＳ１２０９へ進む。

（図１２：ステップＳ１２０８）
差分抽出部１４６は、ステップＳ１２０３で読み込んだ新テストログ１１２４のレコードを、現行テストログ１１１３と新テストログ１１２４の間の差分を比較する対象から除外する。差分抽出部１４６は、アプリケーション２１１のソースコードが修正されているか、又は修正されたソースコードが別の箇所で利用されていることを示すため、当該ログコードの差分情報として、アプリケーション２１１が改修されている旨の情報を記録する。

（図１２：ステップＳ１２０９）
差分抽出部１４６は、新テストログ１１２４と現行テストログ１１１３を、ＡＰＩフラグ１１２３１２が記録されているログデータまで読み込み、それまでのログデータを差分情報内に記録する。

（図１２：ステップＳ１２０９：補足）
本ステップは、現行入出力ログ１１１２と新入出力ログ１１２２が異なる部分のうち、改修タグが付加されていない部分についてのみ実施されるため、結果として現行システム２００と新システム３００の間の相違点のみを抽出して差分ログに記録することになる。

（図１２：ステップＳ１２１０）
差分抽出部１４６は、ステップＳ１２０１で読み込んだセッションＩＤに対応する全てのレコードについて比較完了するまで、ステップＳ１２０３〜Ｓ１２０９までの処理を繰り返し実行する。

＜実施の形態１：まとめ＞
以上のように、本実施形態１に係るテスト支援サーバ１００は、現行入出力ログ１１１２と新入出力ログ１１２２の間に差分がある場合は、実行結果トレース（現行テストログ１１１３と新テストログ１１２４）に基づき、アプリケーション２１１のソースコードが改修されているか否かを判定する。改修されている場合は、その改修部分については現行システム２００と新システム３００を比較する対象から除外する。これにより、現行システム２００と新システム３００の間の相違原因を特定するにあたり、アプリケーション２１１の改修による影響を切り分けることができる。特に、ユーザがアプリケーション２１１を改修した場合において、その部分の影響を除外することができる。

また、本実施形態１に係るテスト支援サーバ１００は、アプリケーション２１１のうち改修されている部分のコードが、所定のミドルウェア等のＡＰＩ２１２５を利用しているか否かを、実行結果トレースに基づき判定する。これにより、現行システム２００と新システム３００の間に相違がある場合、その相違が当該ミドルウェア等を更改したことによるものであるか否かを推定することができる。

また、本実施形態１に係るテスト支援サーバ１００は、現行システム２００が発行したセッションＩＤと新システム３００が発行したセッションＩＤの対応関係を、現行セッション管理テーブル１１１１又は新セッション管理テーブル１１２１に記録する。セッションＩＤは一般にランダムな文字列などを用いて作成されるため、現行システム２００と新システム３００は、入出力データが同じであってもそれぞれ異なるセッションＩＤを発行する可能性があるが、これらの対応関係を管理しておくことにより、セッションＩＤをキーにして両者を関連付け、同じ入出力処理を再現することができる。

＜実施の形態２＞
実施形態１では、現行システム２００と新システム３００がＷｅｂアプリケーションを提供する例を説明したが、その他の種類のアプリケーションについても、実施形態１と同様の手法を用いることができる。例えば、クライアント／サーバ型のアプリケーション、スタンドアロン型のアプリケーションなどについて、実施形態１の手法を用いることができる。

この場合、新トレースログ１１２３内のセッションＩＤ１１２３０４を用いて各入出力処理を特定することに代えて、例えばプロセスＩＤ１１２３０２などを用いて各入出力処理を特定することができる。

また、実施形態１ではミドルウェアのＡＰＩ２１２５を利用するか否かを判定しているが、これに限らずその他のＡＰＩを利用するか否かを判定するようにしてもよい。例えば新システム３００において新ＷｅｂＡＰサーバ３１０外のアプリケーションを更改する場合は、アプリケーション２１１がそのアプリケーションのＡＰＩを利用しているか否かを判定するようにしてもよい。

以上説明した各構成、機能、処理部などは、それらの全部又は一部を、例えば集積回路で設計することによりハードウェアとして実現することもできるし、プロセッサがそれぞれの機能を実現するプログラムを実行することによりソフトウェアとして実現することもできる。各機能を実現するプログラム、テーブルなどの情報は、メモリやハードディスクなどの記憶装置、ＩＣカード、ＤＶＤなどの記憶媒体に格納することができる。

以上、本発明者によってなされた発明を実施形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。

１００：テスト支援サーバ、１１０：記憶装置、１１１：現行システムログ、１１１１：現行セッション管理テーブル、１１１１１：新セッションＩＤ、１１１１２：送信元アドレス、１１１１３：宛先アドレス、１１１１４：開始時刻、１１１１５：終了時刻、１１１１６：旧セッションＩＤ、１１１２：現行入出力ログ、１１１２１：時刻情報、１１１２２：セッションＩＤ、１１１２３：送信元アドレス、１１１２４：宛先アドレス、１１１２５：シーケンス番号、１１１２６：データ、１１１３：現行テストログ、１１２：新システムログ、１１２１：新セッション管理テーブル、１１２２：新入出力ログ、１１２３：新トレースログ、１１２３０１：時刻情報、１１２３０２：プロセスＩＤ、１１２３０３：トレースＩＤ、１１２３０４：セッションＩＤ、１１２３０５：送信元アドレス、１１２３０６：宛先アドレス、１１２３０７：モジュール名、１１２３０８：処理コード、１１２３１２：ＡＰＩフラグ、１１２３１３：改修タグ、１１２３１４：データ、１１２４：新テストログ、１１３：リプレイテストシナリオ、１１３１：時間情報、１１３２：セッションＩＤ、１１３３：送信元アドレス、１１３４：宛先アドレス、１１３５：データ、１２０：メモリ、１３０：ネットワークインタフェース、１４０：プロセッサ、１４１：通信部、１４２：リプレイテスト実行部、１４３：トレース情報受信部、１４４：新システムログ情報処理部、１４５：現行システムログ情報取得部、１４６：差分抽出部、１５０：入力装置、１６０：出力装置、１７０：バス、２００：現行システム、２１０：ＷｅｂＡＰサーバ、２１１：アプリケーション、２１２：開発／実行環境、２１２１：通信部、２１２２：アプリケーションコンパイル部、２１２２１：アプリケーション改修検出部、２１２２２：実行ファイル生成部、２１２３：アプリケーション実行部、２１２３１：実行部、２１２３２：トレース情報記録部、２１２４：トレース情報送信部、２１２５：アプリケーションプログラミングインタフェース（ＡＰＩ）、２１３：メモリ、２１４：プロセッサ、２１５：記憶装置、２１６：入力装置、２１７：出力装置、２１８：ネットワークインタフェース、２１９：バス、２２０：ＤＢＭＳ、３００：新システム、３１０：新ＷｅｂＡＰサーバ、３１１：改修アプリケーション、４００：端末、１０００：移行テスト支援システム。

Claims (15)

1. 現行情報システムから新情報システムへアプリケーションを移行する際の移行テストを支援するシステムであって、
   前記現行情報システム上で動作するアプリケーションと前記新情報システム上で動作するアプリケーションを実行することによって前記アプリケーションの実行結果トレースを取得するアプリケーション実行装置と、
   前記現行情報システムの入出力データを記録した現行入出力ログと、前記新情報システムの入出力データを記録した新入出力ログとを比較して不一致箇所を特定する移行テスト支援装置と、
   を有し、
   前記移行テスト支援装置は、
   前記現行入出力ログと前記新入出力ログを読み込み、
   前記現行入出力ログにおける入力と出力の対応関係が、前記新入出力ログにおける入力と出力の対応関係に一致しているか否かを判定し、
   前記現行入出力ログにおける前記対応関係と前記新入出力ログにおける前記対応関係が一致していない場合は、その不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを、前記実行結果トレースに基づき判定し、
   前記アプリケーションが前記新情報システム上で改修されていると判定した場合は、前記現行情報システムと前記新情報システムを比較する対象から除外する箇所として前記不一致箇所を指定し、
   前記指定した前記不一致箇所を除いて、前記アプリケーションの動作が前記現行情報システム上と前記新情報システム上で異なる部分についての差分ログを出力する
   ことを特徴とする移行テスト支援システム。
2. 前記アプリケーション実行装置は、
   前記新情報システム上で動作するアプリケーションのソースコードを読み込み、
   前記現行情報システム上のアプリケーションが前記新情報システム上で改修されている場合は、その箇所を特定する改修タグを記述したトレースログを出力するステップを前記ソースコード内に埋め込み、
   前記ソースコードをコンパイルして実行することにより、前記実行結果トレースを取得し、
   前記移行テスト支援装置は、
   前記実行結果トレースが記述している前記改修タグに基づき、前記不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを判定する
   ことを特徴とする請求項１記載の移行テスト支援システム。
3. 前記アプリケーション実行装置は、
   前記移行によって置き換える特定のソフトウェアが提供するＡＰＩを前記アプリケーションが利用している場合は、その旨を示すＡＰＩ利用タグを記述したトレースログを出力するステップを前記ソースコード内に埋め込み、
   前記ソースコードをコンパイルして実行することにより、前記実行結果トレースを取得し、
   前記移行テスト支援装置は、
   前記実行結果トレースが記述している前記ＡＰＩ利用タグに基づき、前記アプリケーションが前記ＡＰＩを利用しているか否かを判定することにより、前記現行情報システム上の前記アプリケーションと前記新情報システム上の前記アプリケーションの間の差異が前記移行に起因するものであるか否かを推定し、その結果を前記差分ログに出力する
   ことを特徴とする請求項１記載の移行テスト支援システム。
4. 前記移行テスト支援装置は、
   前記現行情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる現行通信セッションＩＤを記述したセッション管理テーブルを読み込み、
   前記セッション管理テーブルが記述している前記現行通信セッションＩＤをキーにして、前記現行入出力ログ内の対応するレコードを特定し、その記述内容にしたがって前記新情報システム上で前記アプリケーションの動作を再現することにより、前記新入出力ログを作成する
   ことを特徴とする請求項１記載の移行テスト支援システム。
5. 前記移行テスト支援装置は、
   前記新情報システム上で前記アプリケーションの動作を再現する過程において、
   前記新情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる新通信セッションＩＤと、前記現行通信セッションＩＤとの対応関係を、前記セッション管理テーブルに記述する
   ことを特徴とする請求項４記載の移行テスト支援システム。
6. 現行情報システムから新情報システムへアプリケーションを移行する際の移行テストを支援する処理をコンピュータに実行させるプログラムであって、前記コンピュータに、
   前記現行情報システムの入出力データを記録した現行入出力ログと、前記新情報システムの入出力データを記録した新入出力ログとを読み込むステップ、
   前記現行入出力ログにおける入力と出力の対応関係が、前記新入出力ログにおける入力と出力の対応関係に一致しているか否かを判定するステップ、
   前記現行入出力ログにおける前記対応関係と前記新入出力ログにおける前記対応関係が一致していない場合は、その不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを、前記アプリケーションの実行結果トレースに基づき判定する改修判定ステップ、
   前記改修判定ステップにおいて、前記アプリケーションが前記新情報システム上で改修されていると判定した場合は、前記現行情報システムと前記新情報システムを比較する対象から除外する箇所として前記不一致箇所を指定する除外ステップ、
   前記除外ステップで指定した前記不一致箇所を除いて、前記アプリケーションの動作が前記現行情報システム上と前記新情報システム上で異なる部分についての差分ログを出力するステップ、
   を実行させることを特徴とする移行テスト支援プログラム。
7. 前記移行テスト支援プログラムは、前記コンピュータに、
   前記現行情報システム上のアプリケーションが前記新情報システム上で改修されている箇所を特定する改修タグを記述したトレースログを前記実行結果トレースから読み込むステップ、
   前記実行結果トレースが記述している前記改修タグに基づき、前記不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを判定するステップ、
   を実行させることを特徴とする請求項６記載の移行テスト支援プログラム。
8. 前記移行テスト支援プログラムは、前記コンピュータに、
   前記移行によって置き換える特定のソフトウェアが提供するＡＰＩを前記アプリケーションが利用している旨を示すＡＰＩ利用タグを記述したトレースログを前記実行結果トレースから読み込むステップ、
   前記実行結果トレースが記述している前記ＡＰＩ利用タグに基づき、前記アプリケーションが前記ＡＰＩを利用しているか否かを判定することにより、前記現行情報システム上の前記アプリケーションと前記新情報システム上の前記アプリケーションの間の差異が前記移行に起因するものであるか否かを推定し、その結果を前記差分ログに出力するステップ、
   を実行させることを特徴とする請求項６記載の移行テスト支援プログラム。
9. 前記移行テスト支援プログラムは、前記コンピュータに、
   前記現行情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる現行通信セッションＩＤを記述したセッション管理テーブルを読み込むステップ、
   前記セッション管理テーブルが記述している前記現行通信セッションＩＤをキーにして、前記現行入出力ログ内の対応するレコードを特定し、その記述内容にしたがって前記新情報システム上で前記アプリケーションの動作を再現することにより、前記新入出力ログを作成するステップ、
   を実行させることを特徴とする請求項６記載の移行テスト支援プログラム。
10. 前記移行テスト支援プログラムは、前記コンピュータに、
    前記新情報システム上で前記アプリケーションの動作を再現する過程において、前記新情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる新通信セッションＩＤと、前記現行通信セッションＩＤとの対応関係を、前記セッション管理テーブルに記述するステップを実行させる
    ことを特徴とする請求項９記載の移行テスト支援プログラム。
11. 現行情報システムから新情報システムへアプリケーションを移行する際の移行テストを支援する方法であって、
    前記現行情報システムの入出力データを記録した現行入出力ログと、前記新情報システムの入出力データを記録した新入出力ログとを読み込むステップ、
    前記現行入出力ログにおける入力と出力の対応関係が、前記新入出力ログにおける入力と出力の対応関係に一致しているか否かを判定するステップ、
    前記現行入出力ログにおける前記対応関係と前記新入出力ログにおける前記対応関係が一致していない場合は、その不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを、前記アプリケーションの実行結果トレースに基づき判定する改修判定ステップ、
    前記改修判定ステップにおいて、前記アプリケーションが前記新情報システム上で改修されていると判定した場合は、前記現行情報システムと前記新情報システムを比較する対象から除外する箇所として前記不一致箇所を指定する除外ステップ、
    前記除外ステップで指定した前記不一致箇所を除いて、前記アプリケーションの動作が前記現行情報システム上と前記新情報システム上で異なる部分についての差分ログを出力するステップ、
    を有することを特徴とする移行テスト支援方法。
12. 前記現行情報システム上のアプリケーションが前記新情報システム上で改修されている箇所を特定する改修タグを記述したトレースログを前記実行結果トレースから読み込むステップ、
    前記実行結果トレースが記述している前記改修タグに基づき、前記不一致箇所において前記現行情報システム上のアプリケーションが前記新情報システム上で改修されているか否かを判定するステップ、
    を有することを特徴とする請求項１１記載の移行テスト支援方法。
13. 前記移行によって置き換える特定のソフトウェアが提供するＡＰＩを前記アプリケーションが利用している旨を示すＡＰＩ利用タグを記述したトレースログを前記実行結果トレースから読み込むステップ、
    前記実行結果トレースが記述している前記ＡＰＩ利用タグに基づき、前記アプリケーションが前記ＡＰＩを利用しているか否かを判定することにより、前記現行情報システム上の前記アプリケーションと前記新情報システム上の前記アプリケーションの間の差異が前記移行に起因するものであるか否かを推定し、その結果を前記差分ログに出力するステップ、
    を有することを特徴とする請求項１１記載の移行テスト支援方法。
14. 前記現行情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる現行通信セッションＩＤを記述したセッション管理テーブルを読み込むステップ、
    前記セッション管理テーブルが記述している前記現行通信セッションＩＤをキーにして、前記現行入出力ログ内の対応するレコードを特定し、その記述内容にしたがって前記新情報システム上で前記アプリケーションの動作を再現することにより、前記新入出力ログを作成するステップ、
    を有することを特徴とする請求項１１記載の移行テスト支援方法。
15. 前記新情報システム上で前記アプリケーションの動作を再現する過程において、前記新情報システムが前記アプリケーションを実行する際に前記アプリケーションに割り当てる新通信セッションＩＤと、前記現行通信セッションＩＤとの対応関係を、前記セッション管理テーブルに記述するステップを有する
    ことを特徴とする請求項１４記載の移行テスト支援方法。

Images