"プログラムの改定バージョンに対するテストを支援するテストシステムであって、前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログを集積したオペレーションログ集積DBと、前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積DBから、テストデータを生成するテストデータ生成部と、前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータ生成部が生成したテストデータを投入しテストを自動実行させ、前記テスト環境それぞれからテスト結果を取得するテスト実行部と、前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに出力する差分比較部と、を備えることを特徴とするテストシステム。前記実環境でのオペレータによるオペレーションログとは別に、テスト環境でのテストオペレータによる新機能のオペレーションログを記録する新機能オペレーションログDBをさらに備え、前記テストデータ生成部は、前記新機能オペレーションログDBから、前記プログラムの新バージョンでのみサポートされている機能のテストデータを生成することを特徴とする請求項1に記載のテストシステム。前記差分比較部は、前記プログラムの新バージョンでのみ実行可能なテストデータを実行した際に、前記新バージョンでのテスト結果と、予め作成した新機能比較マスタDBを検索して得られた対応データとを比較し、前記差分比較結果テーブルに出力することを特徴とする。請求項2に記載のテストシステム。前記新バージョン入出力項目テーブルは、前記プログラムの旧バージョンから入出力項目に変更がない前記操作画面に対しては、前記旧バージョン入出力項目テーブルで代用することを特徴とする請求項1に記載のテストシステム。前記テスト実行部は、テスト環境でのプログラム実行日時を、前記オペレーションログに記録されたプログラムの実行日時に調整することを特徴とする請求項1に記載のテストシステム。前記差分比較部は、前記プログラムが前記操作画面を介して実行するトランザクション単位に1つのレコードが形成し、新バージョンのテスト結果と旧バージョンのテスト結果をレコード単位で比較し、差分があるレコードペアのみを差分比較結果テーブルに出力する請求項1に記載のテストシステム。前記差分比較部は、前記プログラムの新バージョンのテスト結果と旧バージョンのテスト結果を前記レコード単位で比較し、新旧バージョンで対応するレコードに対して差分がある出力項目の識別表示手段を前記差分比較結果テーブルに出力することを特徴とする請求項6に記載のテストシステム。プログラムの改定バージョンに対するテスト方法であって、前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログをオペレーションログ集積DBに集積するステップと、前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積DBから、テストデータを生成するステップと、前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータを生成するステップで生成したテストデータを投入しテストを自動実行させるステップと、前記テスト環境それぞれからテスト結果を取得するステップと、前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに保存するステップと、を有することを特徴とするテスト方法。特許文献1に記載のテスト方法は、プログラムの改正前後でプログラム実行結果を比較し差分をとる差分比較のテスト手法であり、あらかじめ改正前の被テストプログラムに対して、操作記録時に作成した比較元マスタとテスト実行時の出力結果を比較し、両者の差があればそれを仕様上の差分として比較除外としておき、その後、改正後のプログラムに対して改正前の出力結果との比較テストを行い、この比較除外を除いた真の差分のみを出力する。しかし、テストデータはテスト実施者等が入力することを前提としており、様々なバリエーションに対応するようなテストデータの作成には多くの時間を要するという課題がある。また、同じ改正前のプログラムに対しテストを2回行い、実行日時の違いにより生じた差分を比較除外としてしまうため、日付や時刻に依存するアプリケーションプログラム例えば、満期日や利子の計算などを扱うプログラムでは、必要な入出力項目が比較除外に含まれてしまいかねないといった課題もある。また、特許文献2に記載のテスト方法は、同じく差分比較のテスト手法であり、プログラムの出力結果を画面上の出力結果で比較し、不一致部分の画像を出力するものであるが、比較のための多くの画面画像を保存して比較する必要があり、テストシステムに負荷がかかるといった課題がある。また、プログラムの出力結果を画面上でなくデータベース上のデータとして他のシステムへのインプットとして渡すようなプログラムには適用できないという課題もある。プログラムのテストにおいて、様々な入力パラメータのバリエーションをすべてチェックすることは膨大な作業であり、特に既存機能を確認するためのリグレッションテストやデグレードテストは大変なわりに退屈な作業でもあるので、小規模なバージョンアップの際に毎回行うのは時間との兼ね合いで困難となる場合が多い。またパッケージソフトを購入して、システムに組み入れている場合には、入力と出力以外はブラックボックスであり、機能とプログラムモジュールの関係も不明なので、プログラムの一部の修正が、他の関係ない部分に影響し予想外の不具合が発生してないか確認する必要もある。したがって、本発明では、上記のような課題に鑑み、テストデータの作成の手間を大幅に軽減するため、様々なバリエーションのテストデータをプログラムが稼動実績のある多数の実環境から自動的に作成し、かつプログラムの出力結果を画面画像として保存する必要がなく、新旧バージョン改定後と改定前のプログラムの出力結果の差分を容易に比較することのできる差分比較テストシステム及びテスト方法を提供することを目的とする。上記課題を解決するため、本発明のテストシステムは、以下のような解決手段を提供する。プログラムの改定バージョンに対するテストを支援するテストシステムであって、前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログを集積したオペレーションログ集積DBと、前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積DBから、テストデータを生成するテストデータ生成部と、前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータ生成部が生成したテストデータを投入しテストを自動実行させ、前記テスト環境それぞれからテスト結果を取得するテスト実行部と、前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに出力する差分比較部と、を備えることを特徴とする。このような構成にすることで、プログラムの改定時バージョンアップやリリースアップ時におけるテストデータの作成を、プログラムの旧バージョン改定前バージョンが稼働している実績ある多数の実環境からのオペレーションログを集積したDBから自動的に作成することができる。このとき、操作画面を介しての新バージョン改定後バージョン及び旧バージョンのプログラムの入出力項目を定義した入出力項目テーブルが用いてテストのための入力データが作成される。また、生成した同じテストデータを、新旧バージョンプログラムを適用したテスト環境それぞれに投入してそのテスト結果を取得し、新バージョンのテスト結果が旧バージョンのテスト結果と比較される。テストの比較結果は、新旧バージョン入出力項目テーブルを再び用いて比較すべき項目を抽出した差分比較結果テーブル上に出力され、テスト結果の解析に用いられる。このようにすることで、設計時には想定しづらかった実環境での多くのバリエーションを含んだテストデータが豊富になり、テストカバレッジを広げることができる。かつ、新旧バージョンのテスト結果の差分比較を容易にすることでリグレッションテストやデグレードテストの作業が大幅に緩和することができる。また、上記のテストシステムは、下記のような特徴を更に備えるように構成してもよい。すなわち、前記実環境でのオペレータによるオペレーションログとは別に、テスト環境でのテストオペレータによる新機能のオペレーションログを記録する新機能オペレーションログDBをさらに備え、前記テストデータ生成部は、前記新機能オペレーションログDBから、前記プログラムの新バージョンでのみサポートされている機能のテストデータを生成することを特徴とする。すなわち、実環境でのオペレータによるオペレーションログとは別に、テスト環境でのテストオペレータテスターによる新機能を含んだオペレーションログを記録する新機能オペレーションログDBを備えることで、新機能のテストデータを、実環境のオペレーションログからの場合と同様の手順で生成することができる。また、上記のテストシステムの差分比較部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記差分比較部は、前記プログラムの新バージョンでのみ実行可能なテストデータを実行した際に、前記新バージョンでのテスト結果と、予め作成した新機能比較マスタDBを検索して得られた対応データとを比較し、前記差分比較結果テーブルに出力することを特徴とする。このように構成することで、新バージョンでのみサポートされる新機能のテストデータであって、旧バージョンのテスト結果が存在しない場合、予め作成した新機能比較マスタDBを検索し、そこから対応する正しい出力結果のデータが得られればそのデータと新バージョンテスト結果とを比較するので、従来機能のテストの場合と同じ形式で差分比較結果テーブルに出力することができる。実環境でのオペレーションログに基づいて生成したテストデータでは、新旧で同じ機能の部分については実績のある旧バージョンと新バージョンのテスト結果を比較すれば、新バージョンでの不具合デグレードを発見することができるが、新バージョンでのみサポートされている機能は、旧バージョンのテスト結果と比較することはできない。したがって、通常は新機能のテストは、人間が仕様から想定される正しいテスト結果比較マスタと呼ぶことにすると実際のテスト結果とを見比べて比較することになるが、本テストシステムでは、比較マスタを本テストシステムが対象とするプログラムが出力する形式で予め作成しておくことで、比較マスタと新バージョンでのテスト結果との比較が、同じ差分比較結果テーブルを用いた形で実現できる。また、上記のテストシステムは、下記のような特徴を更に備えるように構成してもよい。すなわち、前記新バージョン入出力項目テーブルは、前記プログラムの旧バージョンから入出力項目に変更がない前記操作画面に対しては、前記旧バージョン入出力項目テーブルで代用することを特徴とする。このように構成することで、操作画面によって新旧のバージョンで入出力項目に変更のないものについては、新バージョン入手出力項目テーブルの作成はせず、旧バージョン入出力項目で代用することで、項目の変更のあるなしに係らず、同じテスト操作を実行することができる。また、上記のテストシステムのテスト実行部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記テスト実行部は、テスト環境でのプログラム実行日時を、前記オペレーションログに記録されたプログラムの実行日時に調整することを特徴とする。このように構成することで、オペレーションログに記録されたプログラムの実行日時に合わせて、テスト環境の内部時計を一時的に調整し、テスト時のプログラム実行日時を一致させることで、実行日時によって出力結果が変動するプログラムに対しても、比較除外の手段などを用いなくとも、同じ差分比較の手法を適用することができる。また、上記のテストシステムの差分比較部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記差分比較部は、前記プログラムが前記操作画面を介して実行するトランザクション単位に1つのレコードを形成し、新バージョンのテスト結果と旧バージョンのテスト結果をレコード単位で比較し、差分があるレコードペアのみを差分比較結果テーブルに出力することを特徴とする。このように構成することで、操作画面を介して実行されるプログラムの処理単位であるトランザクション単位で新旧バージョンの入出力結果において差分のあるもののみが差分比較結果テーブルに出力され、比較し、解析を容易することができる。また、上記のテストシステムの差分比較部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記差分比較部は、前記プログラムの新バージョンのテスト結果と旧バージョンのテスト結果を前記レコード単位で比較し、新旧バージョンで対応するレコードに対して差分がある出力項目の識別表示手段を前記差分比較結果テーブルに出力することを特徴とする。このように構成することで、新旧で差分がある出力項目ごとにその差分を目立たせる識別表示手段フラグ、色、図形などを差分比較結果テーブルに出力するので、項目単位の差分の発見をさらに容易にすることができる。なお、本発明のテストシステムは、下記のようなテスト方法の発明と捉えることもでき、本発明のテストシステムと同様な作用効果を奏する。プログラムの改定バージョンに対するテスト方法であって、前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログをオペレーションログ集積DBに集積するステップと、前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積DBから、テストデータを生成するステップと、前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータを生成するステップで生成したテストデータを投入しテストを自動実行させるステップと、前記テスト環境それぞれからテスト結果を取得するステップと、前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに保存するステップと、を有することを特徴とするテスト方法。本発明によれば、テストデータの作成の手間を大幅に軽減するため、様々なバリエーションのテストデータをプログラムが稼動実績のある多数の実環境から自動的に作成し、かつプログラムの出力結果を画面画像として保存する必要がなく新旧バージョンのプログラムの出力結果の差分を容易に比較する差分比較テストシステム及びテスト方法を提供することができる。以下、添付図面を参照して、本発明を実施するための形態以下、実施形態について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。図1は、本発明の実施形態に係るテストシステム100の機能ブロックを示す図である。図示するように、本実施形態のテストシステム100は、プログラムテストを自動または半自動で行うことを支援するシステムであり、機能実行部として、オペレーションログからテストデータを生成するテストデータ生成部20,テストデータを被テストプログラムに投入するテスト実行部50,新旧バージョンプログラム出力結果を比較し、その差分を抽出する差分比較部70を含んでいる。また、テストシステム100は、データ格納部として、被テストプログラムの実環境200から得られるオペレーションログ220を集積したオペレーションログ集積DB10グローバルログ,新バージョンでのみサポートされる新機能をテストオペレータテスターが操作したログを記録する新機能オペレーションログDB11,オペレーションログから生成したテストデータを格納するテストデータDB40,新旧バージョンの被テストプログラムのテスト結果をそれぞれ格納する新旧バージョンテスト結果データDB90、91,及び新機能比較マスタDB92を含んで構成される。また、テストシステム100は、その他入力データとして、新旧バージョン入出力項目テーブル30、31を含み、また、差分比較部70の出力データとして、差分比較結果テーブル80を含んで構成されている。以下、各機能ブロックの働きについて順に説明する。実環境200は、既にリリースされた被テストプログラムの旧バージョンが実際に稼動しているシステム環境を示す。ここで扱う被テストプログラムは、実環境におけるオペレータが操作画面210から入力データをインプットし、出力結果を画面に表示させたり、DBに出力するようなアプリケーションプログラムを想定している。ただし、ここでオペレータとは専門の端末操作員だけでなく、無人店舗等で端末を操作する個人顧客等を含むものとする。実環境200は、具体的には被テストプログラムを操作可能な店舗や支店以下両者を合わせて拠点と呼ぶなど複数の場所に存在する。各拠点では、オペレータの操作手順、入力データ及び出力データが逐次記録されるオペレーションログ220を有している。各オペレーションログ220の内容は、テストシステム100のオペレーションログ集積DB10に所定のタイミングで集積される。テストデータ生成部20は、オペレーションログ集積DB10からオペレーションログの内容を解析し、被テストプログムが実行可能なテストデータテストファイルに加工し、テストデータDB40に格納する。この加工の際には、予め用意された旧バージョン入出力項目テーブル30が参照される。オペレーションログには、入力項目と出力項目が含まれるが、テストデータとして必要なのは入力項目のみである。入出力項目テーブルとは、被テストプログラムの操作画面ごとに入力項目入力フィールドと出力項目出力フィールドを定義したテーブルであり、通常は画面設計の際に作成される。また、テストデータ生成部20は、新バージョンでのみサポートされている機能の画面操作を記録した新機能オペレーションログDB11から、新バージョンでのみ実行可能可能なテストデータを生成することができる。この場合も生成されるテストデータの形式フォーマットは、同じである。テストデータの具体例については後述する。被テストプログラムのバージョンアップの際に入出力項目が変更になった場合には、新バージョン入出力項目テーブル31が用意される。新バージョン入出力項目テーブル31は、今回のバージョンアップで新たにサポートされた機能に対応する入出力項目や拡張されたパラメータ等を追加し、また、新バージョンではもはやサポートされない機能DiscontinueFunctionに対応する入出力項目を削除するなどして旧バージョン入出力項目テーブル30から作成される。入出力項目テーブルについて詳しくは後述する。テスト実行部50は、テストデータDB40に格納されたテストデータを読み出し、新旧の被テストプログラムの実行環境60,61にそれぞれ入力して被テストプログラムを実行させる機能を果す。また、テスト実行部50は、新旧バージョン適用被テストプログラム実行環境60,61からテストデータを投入して得られたテスト結果をそれぞれ新旧バージョンテスト結果データDB90,91に格納する機能も果す。すなわち、テスト実行部40はテストを自動実行する機能を果す。このようなテストの実行手段は市販のツールなどで実現される例えば、HP社のQTPなど。もちろん、テストデータの形式は、市販ツールでサポートされているものであれば任意のものであってよいが、本発明の実施における被テストプログラムは金融関係のプログラムであることから、後述するOFSOpenFinancialServiceファイルと呼ばれるテストデータ形式を利用している。差分比較部70は、新旧のバージョンのテスト結果をそれぞれ集積した新旧バージョンテスト結果データDB90,91からテスト結果データを読みだし、新旧バージョンのテスト結果データを、プログラムの処理の単位であるトランザクションレコード単位で比較し、新旧バージョンのテスト結果で異なっているレコードのみを入出力データと共に、差分比較結果テーブル80に出力する。ここで、差分比較結果テーブルの作成には、新旧バージョンの入出力項目テーブルが参照される。この場合には、入力項目だけでなく出力項目の欄も参照されるのはもちろんである。差分比較結果テーブル80は、詳しくは後述するが、テスト管理者やデバッグ担当者が解析しやすいように一般的な表形式で出力される。新バージョンでのみサポートされる新機能は、旧バージョンでは動作しないので、新バージョンテスト結果データDB91と予めテスト管理者等が仕様に基づき作成した新機能比較マスタDB92とが比較され、同様に差分比較結果テーブル80が出力される。上記の機能ブロックの構成は、あくまで一例であり、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、装置に内蔵されたCPUCentralProcessingUnitが、ROMReadOnlyMemoryまたはハードディスク等の記憶装置に格納されたコンピュータプログラムを読み出し、CPUにより実行されたコンピュータプログラムが、記憶装置に格納されたデータベースDBDataBaseやメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア例えば、入出力装置、表示装置、通信インターフェース装置を制御することによって実現される。また、本発明の実施形態におけるデータベースDBは、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わない。図2は、本発明の実施形態に係るオペレータ操作画面、入出力項目テーブル、オペレーションログを示す図である。オペレータ操作画面210は、被テストプラグラムに対するユーザインターフェースのひとつであり、案件毎にユーザ入力及びプログラムからの出力結果を表示する一または複数の画面である。図示するように、オペレータ操作画面210には、オペレータが入力する複数の入力項目、プログラムの実行結果である1または複数の出力項目、及びオペレータが操作する1または複数の操作ボタンを表示する。また、オペレータが入力せずとも自動的に表示される入力項目入力不可項目も表示される。例えば、現在日時,画面ID,顧客番号を入力した際に表示される顧客氏名なども入力不可項目となる。新旧バージョン入出力項目テーブル30、31は、画面ごとに含まれる各入出力項目に対して、項目ID,値範囲とりうる値が限定されている場合,備考入出力項目の説明テキスト,入力/出力入力か出力かの区別,表示/非表示画面上に表示されるか否かの区別をテーブル形式にまとめたものである。表示/非表示の区別を設けるのは、入出力の項目には必ずしも操作画面に表示する必要はないが被テストプログラムの入力/出力データとしては必要なものがあるからである。もっとも画面上には表示されるが、被テストプログラムの入力/出力データとして関係ない項目は入出力項目テーブルからは省略してもよい。例えば、ヘルプに対する表示や現在時刻の表示、またはログイン認証を被テストプログラムとは別のプログラムを、同じ操作画面から呼び出して行っている場合、そのパスワードや認証に必要なデータ等である。既に述べたように、被テストプログラムの新バージョンにおいて追加変更された入出力項目がある場合には、新バージョン入出力項目テーブル31を旧バージョン入出力項目テーブル30から予め変換して作成しておく。入出力項目に追加変更がなくとも値範囲パラメータ範囲に変更がある場合には新バージョン入出力項目テーブル31は作成される。新旧バージョンで追加変更がない場合には、その画面IDに対しては同じ旧バージョン入出力項目テーブル30が代用して使用される。オペレーションログ集積DB10に格納されたオペレーションログには、トランザクション毎に、使用した被テストプログラムのプログラム名,バージョン情報,プログラム実行日時,拠点ID操作画面入力箇所のID,画面IDが制御部11ヘッダ部に含まれ、データ部12には、各入出力項目ごとに入出力項目IDフィールドIDと、入力または出力項目に対する値が記録されている。その他、操作開始時刻、操作終了時刻、操作員のIDや承認者のID等の操作状況に関する付随情報が含まれていてもよい。図3は、本発明の実施形態に係るオペレーションログの具体例を示す図である。この具体例では、図示するようにオペレーションログは、タグ形式のテキストファイルであり、トランザクション毎に、プログラム実行日時を先頭にして制御部11のデータとして、プログラム名,バージョン名,トランザクションID,画面IDがそれぞれ、,,,のタグで前後を指定された形で記録される。またデータ部12の各入出力項目は、項目名がタグで前後を指定され、その項目に対して入力または出力された値がタグで前後を指定された形で記録される。各項目が記録される順序は、通常はオペレータが入力した順序であるが必ずしもそうでなくともよい。なお、ここでは図示していないが、入出力項目によっては、値が複数存在する場合に備えての後ろに、,をタグを定義し、1つの入出力項目に対するValueやさらにそのSubvalueの数を指定することもできる。単一のValueの場合、は1であり、このときはタグは存在しない。以降は、テスト対象のアプリケーションプログラムとして、金融機関の対顧客窓口サービスにおけるローン貸付業務を扱うプログラムを具体例にして説明する。このプログラムを操作した際のオペレーションログのデータ部12には、融資額,科目コード,通貨,顧客番号,満期日,適用金利,利息計算方法等、このプログラムが処理する具体的な入出力データが記録されている。これらの入出力データは必ずしも操作画面上に表示されるものだけでなく、内部処理で使用されるものも含んでいる。オペレーションログ集積DB10に集積されたオペレーションログ、または新機能オペレーションログDB11から、テストシステム100のテストデータ生成部20によって、テストデータが生成される。このとき、旧バージョン入出力項目テーブル30が参照されテストにとって必要なデータだけが抽出される。すなわち、この入出力項目テーブル中で画面上で入力と指定された項目フィールド名とその値だけが被テストプログラムに対してインプットされるべきテストデータとして使用される。オペレーションログ中の入力とテストデータのフォーマットとしては、具体的にはOFSファイルを用いている。OFSファイルは、各入出力項目とその値を、フィールド名:ms値の形式で表したテキストファイルである。ここでm、sは先に説明したmultiValueNumberとsubValueNumberの値であり、単一Valueの場合は、m、sとも1である。例えば、融資額フィールドにインプットされた値が1000000であれば、AMOUNT111000000のようにOFSファイル上は記載される。もちろん、テストデータに他のファイル形式を用いてもなんら支障はない。なお、新機能オペレーションログDB11についても同様の形式で作成される。このようにして生成された同じテストデータが新旧バージョン適用被テストプログラム実行環境60,61に投入される。ただし、旧バージョンのテストデータをそのまま新バージョンに投入する際には、新バージョンの画面のデザイン等により形式的な変換をする必要がある場合があるが、その場合には変換規則を記述した変換テーブルなどを別途用意する。図4は、本発明の実施形態に係る入出力項目テーブルの具体例を示す図である。入出力項目テーブルは、操作画面で処理されるすべての入力項目および出力項目をまとめたテーブルである。既に述べたように、プログラムの改定によって入力項目/出力項目が変更される場合があるので、改定前後のプログラムのバージョンに対応して、旧バージョン入出力項目テーブル30と新バージョン入出力項目テーブル31が存在する。先に挙げたローン貸付業務プログラムの一つの操作画面として、新規ローン受付画面を具体例に取り上げると、旧バージョン入出力項目テーブル30は具体的には図4上段のようになる。プログラムの改定によって入出力項目に変更があった場合には、新バージョン入出力項目テーブル31が作成され、例えば、図4下段のようになる。この例では、CURRENCYフィールドの値パラメータとして通貨KHR31aが追加され、また、ACCURUALPARAMフィールード31bが新設されて、新バージョンで新たな機能がサポートされたことを示している。なお、新バージョンではこのような機能拡張だけでなく、機能の整理統合により、旧バージョンの入出力項目が新バージョンでは削除されることもあり得る。新バージョンで追加されたフィールドやパラメータは、旧バージョンプログラムが実稼動している環境下でのオペレーションログ上には現れることはないのでテストデータの作成には旧バージョン入出力項目テーブル30のみが用いられる。ただし、差分比較結果テーブルの作成には新旧バージョンの入出力項目が必要となる。図5、図6は、本発明の実施形態に係るテスト実行手順を示す図である。図5は、基本テスト実行手順、図6は新機能テスト手順を示したものである。まず、図5のステップS10において、新バージョンでのみサポートされる新機能があるかどうかをテスト管理者からの指示を受ける。新機能がある場合は、ステップS11に移り新機能テストを行う。今回のテストが新機能を含まないバグ修正後のリグレッションテストのような場合は、ステップS11はスキップされる。新機能テストとは、旧バージョンでは存在せず、今回の新バージョンで新たに追加された機能が仕様に合致しているかどうかを調べるテストをいう。新機能テストでは、実環境においてのオペレーションログが存在しないので実環境から生成したテストデータの自動作成ができず、したがって旧バージョンのテスト結果との差分比較ができないので、以降のテストの前段階のテストとして行うものである。新機能テストでも、オペレーションログによるテストデータの自動生成が可能である。ただし、この場合、実環境のオペレーションログではなく、テストオペレータがテスト環境において、予め定められたテストシナリオに沿って操作画面での操作を行い、その操作内容とその結果を実環境でのオペレーションログと同じ形式で新機能オペレーションログDB11に記録することで、テストデータ生成部20は、新機能のテストデータを生成することができる。テストデータの生成には、新バージョン入出力項目テーブル31が利用される。このようにテストデータの形式を同じにすることで、テスト実行部50は、新機能テストデータと旧バージョンのテストデータを特に区別することなく被テストプログラム実行環境に投入することができる。ただし、新バージョンにおける新機能テストの結果は、既存機能のリグレッションとは異なり、旧バージョンでのテスト結果が存在しないので、テスト管理者等があらかじめ仕様に基づいて用意した新機能比較マスタDB92に格納された正しい出力結果と比較することになる。図6では、この新機能テストの手順を示しているが、基本的な流れは、以下で説明する図5の旧バージョンとの比較手順と上記の点を除いて大差はないので詳細な説明は省略する。図5に戻り、テストシステム100のテストデータ生成部20は、ステップS12において、新旧バージョン入出力項目テーブル30,31が読み込まれるが、新旧バージョンで入出力項目に変更がない場合には、旧バージョン入出力項目テーブル30のみが読み込まれる。さらに、テストデータ生成部20は、ステップS13において、オペレーションログ集積DB10よりテストデータを生成する。ここでは、すでに説明したとおり、OFSファイルのようなプログラムが自動実行可能な所定の形式のテストデータファイルを生成する。次に、テストシステム100のテスト実行部50は、ステップS14において、テスト環境におけるプログラム実行日時をテストデータに記録されたプログラム実行日時に合わせるように設定する。これは、同じ入力データであってもプログラムの実行する日時によって処理結果が異なることがあるからである。例えば、操作画面等に表示する現在日時はもちろんとして、ローンの満期日や利息等の計算では、プログラムの実行日処理日によって計算結果が異なるので、テストデータの元となったオペレーションログ中のプログラム実行日時にテストプログラムの実行日時を合わせるように内部時計を調整する必要がある。もちろん、このようなプログラムの実行日時等、出力結果に影響する日時データそのものをすべて入力データとして扱うようにプログラムが設計されていればステップS14の処理はスキップすることができる。次に、テスト実行部50は、ステップS15において、新旧バージョン適用被テストプログラム実行環境60,61それぞれに、テストデータ生成部20によって生成された同じテストデータを投入する。そして、ステップS16において、被テストプログラムの出力結果テストデータに対するアウトプットを新旧バージョンテスト結果データDB90,91に記録する。その結果、ステップS17において、テストシステム100の差分比較部70が、この新旧バージョンテスト結果データDB90,91を読み出し、差分比較結果テーブル80を作成する。このとき新旧バージョン入出力項目テーブル30,31が参照される。以上のステップS14~S17の処理をすべてのテストデータ画面ごと、及びトランザクションごとについて繰り返すステップS18。このようにして得られた差分比較結果テーブル80から、テスト管理者は、新バージョンのプログラムの不具合の有無を調べることができる。図7は、本発明の実施形態に係る差分比較結果テーブルの概略を示す図である。差分比較結果テーブル80は、すでに説明したように、新旧バージョンの被テストプログラムに対し、同じテストデータをインプットとして、その出力結果を入力データとともに比較して一覧表形式にまとめたテーブルである。図示するように、表中の2つの行のペア86a,86b,86cとして新旧バージョンの入出力結果が表示される。1つの行レコードは、被テストプログラムのトランザクション処理単位ごとに作成されるレコードである。欄81bは、Diffフラグと呼び、例えば記号があると、新旧のレコード中いずれかに違いがあることを示す。新旧の比較はすべてのトランザクションに対して行われるので、差があるものも、差がないものも、すべての比較結果を差分比較結果テーブル80に記載するようにしてもよいし、差分があるレコードのみを差分比較結果テーブル80に記載するようにしてもよい。欄82の新旧のみフラグとは、新バージョンまたは旧バージョンどちらかにしかそのトランザクションに対応するレコードが存在しなかったことを示す。例えば、新バージョンでしかサポートされない新機能のテストデータを誤って旧バージョンのプログラムに投入した場合には、旧バージョンのプログラムはエラーとなり、出力結果が得られないので新バージョンのレコードのみが存在することになる。この場合、新旧のみフラグがNEWONLYとなり、このレコードがテーブルに記載される。同様に、旧バージョンでサポートされていたが、新バージョンでサポートされていない機能DiscontinueFunctonのテストデータを新バージョンのプログラムに投入した場合には、新旧のみフラグがOLDONLYとなったレコードのみがテーブルに記載される。また、新旧のみフラグは、新旧のみフラグがNEWONLYとなったレコードに対応するレコードを新機能比較マスタDB92から検索し、対応するレコードがあればそれを比較対象として抽出させるための役割も果す。また、現場のオペレータでなく、テストが作成した新機能オペレーションログDB11から作成した新機能テストデータを検証する際にも役立つ。すなわち、新機能テストデータに含まれる入出力項目が差分比較結果テーブル80に正しく反映されるかどうかの確認等に利用できる。欄83トランザクションIDは、各処理単位ユニークなトランザクションIDを記載する欄である。通常は一つのトランザクションIDに対して新旧のレコードがそれぞれ存在することになる。欄84新旧レコードは、そのレコード行が新バージョンのプログラムのテスト結果NEWか、旧バージョンのテスト結果OLDかを示すフラグである。比較マスタを比較元とする場合には、新旧レコードはMASTERとすれば、レコードペアは、NEWとMASTERとなる。欄85は、画面毎に定義された入力項目、出力項目すべて、すなわち、新旧バージョン入出力項目テーブル30,31に定義された項目のすべてである。ただし、各出力項目の前には、Diffフラグ欄が存在し、対応する出力項目の出力結果が新旧あるいは新とMASTERで異なっていることを示す。例えば、86aのレコードでは、出力項目1の結果が異なっているので、出力項目1の直前のDiffフラグが、記号で示されることになる。このように、Diffフラグをレコード全体と各出力項目ごとに設けることで、新旧の相違点の発見を容易にすることができる。もちろん、Diffフラグの記号の代わりに、識別表示手段として、セルや文字の表示色やサイズを変えたり、図形表示を追加するなどしてもよい。図8は、本発明の実施形態に係る差分比較結果テーブルの具体例を示す図である。図は、ローンの利息計算をするプログラムをテスト対象の具体例としてテストの結果、その差分比較結果テーブル80の一部を示す。前図で説明したように、新旧の比較結果であるレコードペア86a,86b,86c,86d,86eに示されている。86fは、旧バージョンでしか結果が得られなかったレコード、86gは新バージョンでしか結果が得られなかったレコード、すなわち比較対象のバージョンのテスト結果が存在しなかったレコードを示している。この図では、各出力項目ごとに対応するDiffフラグの代わりに、太線四角枠で新旧バージョンのテスト結果が異なっている出力項目を表している。すなわち、レコードペア86aでは、元本金額、利息金額、処理日付が新旧で異なっているが、何らかの原因で融資スケジュールの処理日付の相違により、元本金額と利息金額の結果が異なってきているのではないかと考えられる。また、レコードペア86cでは、利息計算日数の相違により、利息金額の計算結果の差異が生じ、レコードペア86eでは、適用レートの相違により利息金額の計算結果が異なっているのではないかと考えられる。なお、レコードペア86gでは、比較されたレコードがNEWとMASTERになっており、新機能テストの場合の比較結果である実際には、旧バージョンとの比較テストと新機能テストは、別個に行われるので混在することはない。このように、新バージョンの被テストプログラムの出力結果と、実績のある旧バージョンの被テストプログラムの出力結果との比較が多くの入力データのバリエーションに対して容易に行えるので、不具合の早期発見、早期解決に役立たせることができる。特に、プログラムのバージョンアップの際、通常の機能テストではなかなか発見しづらい従来機能の思わぬ箇所の思わぬ不具合の発見に役立たせることができる。また、パッケージソフトなど内部がブラックボックスのプログラムを組み込んでシステムを構築する場合にも特に有用である。以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。"