JP2009245383A - 情報処理装置およびプログラム解析方法 - Google Patents

Abstract

【課題】プログラムの処理内容と出力結果の更新特性を取得するのは容易でない。
【解決手段】ファイル解析部３８においてデータ形式解析部５２は、プログラムのソースコードをパターン解析することにより、入出力ファイルのレイアウト情報およびデータを特定するキーとなる項目を特定する。処理内容特定部５４は、プログラムの入力ファイルと出力ファイルにおけるデータの差分をデータを特定するキーの値ごとに取得することによりプログラムの処理内容を取得する。更新特性取得部５６は、所定期間分の処理内容に基づきデータの更新特性を取得し、データを特定するキーの値ごとに分類する。テストケース作成部５８は、更新特性に基づきプログラムをテストすべき条件および確認すべき項目を導出し出力部４２から出力する。比較処理管理部６０はテストの進捗度合いを管理する。
【選択図】図７

Description

本発明は情報処理技術に関し、特に入力ファイルを読み込みプログラムを実行して出力ファイルを生成する情報処理装置および当該装置に適用できるプログラム解析方法に関する。

近年の情報処理技術の発展およびネットワーク環境の充実化に伴い、様々な情報がネットワークを行き来し、企業、社内の部門など端末に入力された個々のデータを統括管理する組織には、入力された膨大なデータおよびシステムを厳密に管理する技術が必要不可欠となっている。

大規模なシステムなどでは特に、運用担当者が実行されるプログラムが個々にどのような処理を行っているかを詳細に把握していないことが多い。また以前に導入されたプログラムが今現在、システム内でどのような機能を果たしているか、わからなくなっていることも少なくない。このような状況で、プログラムの影響を解析する手法として、例えばソフトウェアの自動解析ツールが提案されている（例えば特許文献１参照）。
特開平１０−１８７４３１号公報

システムに導入済みのプログラムを修正したり、バッチ処理で運用されているジョブに新たなジョブを追加したりする際には、導入済みのプログラムや、新たなジョブで実行するプログラムが、出力結果にいかに作用するかをあらかじめ把握しておく必要がある。予想外の出力結果が得られた場合、システム全体に影響を及ぼす可能性があるためである。しかし上述のように、運用担当者がプログラムの処理内容を詳細に把握しているとは限らず、プログラムの修正や追加が個々の出力データに与える影響を詳細に予測することは困難であった。

また上述のソフトウェアの自動解析は、プログラム中のレーベルによる分析にとどまっているため、同一のレーベルに性質の異なるデータが混在していた場合でも、同一視して解析を行う。そのため、例えば更新のタイミングが異なるデータであっても、その更新特性の差を得ることは難しく、結果としてプログラムがデータに与える影響を詳細に解析することができなかった。

本発明はこうした状況に鑑みてなされたものであり、その目的は、プログラムの処理内容と出力されるデータの関係を詳細に把握することのできる情報処理技術を提供することにある。

本発明のある態様は、情報処理装置に関する。この情報処理装置は、入力ファイルに記録された複数の項目についてデータを生成するプログラムの出力ファイルにおける、項目およびデータの記載位置を表すレイアウト情報を取得するとともに、他の項目のデータを特定するデータキーの項目を特定するデータ形式取得部と、データキーの値ごとに、当該データキーに対応づけられた他の項目のデータの、入力ファイルと出力ファイル間の差分を取得することにより、前記プログラムの処理内容を特定する処理内容特定部と、を備えたことを特徴とする。

ここで「項目」とは対応するデータを総括する名称や識別情報などであり、文字列、数値、図形などいかなる態様の情報でもよい。「データ」も数値、文字列、図形などのいずれの情報でもよく、各項目に対して設定された値やプログラムが出力する値などである。

本発明の別の態様は、プログラム解析方法に関する。このプログラム解析方法は、入力ファイルに記録された複数の項目についてデータを生成するプログラムの出力ファイルにおける、項目およびデータの記載位置を表すレイアウト情報を取得するとともに、他の項目のデータを特定するデータキーの項目を特定するステップと、実際のプログラム実行により記憶された入力ファイルおよび出力ファイルの組をメモリより読み出し、データキーの値ごとに、当該データキーに対応づけられた他の項目のデータの、入力ファイルと出力ファイル間の差分を取得することにより、前記プログラムの処理内容を特定するステップと、を含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、プログラムの詳細な処理内容および出力データの更新特性を容易に取得することができる。

図１は本実施の形態を適用できるシステムの構成例を示している。同図においてジョブ処理システム１０は第１サーバ１２、第２サーバ１４の２つのサーバを含む。また第１サーバ１２はデータベース１７に接続している。ユーザは各サーバの端末などを操作し、設定、登録を行うことにより、所望のジョブを所望の時間に処理させる。なお、サーバやデータベースの数、データベースの接続先は図１に示したものに限らず、ジョブを処理できるシステムであればいかなる構成においても本実施の形態を適用できる。また各サーバにさらにクライアント端末などが接続していてもよい。

第１サーバ１２および第２サーバ１４はそれぞれ、一以上のＣＰＵとメモリ、記憶装置、入出力装置、表示装置など、あるいはそのいずれかの組み合わせを備えた一般的な情報処理装置であればよく、パーソナルコンピュータ、汎用大型コンピュータなどその規模は限定されない。同図は一例として第１サーバ１２がハードディスク１３を、第２サーバ１４がハードディスク１５をそれぞれ備えた構成を示している。また第１サーバ１２、第２サーバ１４はネットワーク２０に接続され、互いにデータを送受することができる。

ユーザは第１サーバ１２、第２サーバ１４のいずれかに対しジョブフロー、バッチ処理時の処理の順序、処理開始時間などの設定を行うことにより、ジョブ処理システム１０にジョブを処理させる。ここで「ジョブフロー」とは、ジョブごとの具体的な処理内容のことである。各ジョブを第１サーバ１２、第２サーバ１４のいずれかひとつのサーバで処理するようにしてもよいし、双方のサーバで並列に処理するようにしてもよい。ジョブをどのサーバでどのような順序で処理させるか、また、並列に複数のジョブを処理させるかどうかなどは、ＣＰＵの処理能力やネットワークの帯域など利用可能なリソースや、データベースへのアクセス順といった処理内容に鑑み、ユーザが設定を行う。これらの手続きは、ジョブのバッチ処理に際し行われる 一般的な手法を用いることができる。

ジョブ処理システム１０は、各種機能やサービスをユーザに提供する本番機でよい。すなわちジョブ処理システム１０は、ネットワーク２０を介してアクセスを行った端末（図示せず）などにサービスを提供したり、各支店から計上されるデータを当該支店の端末から取得してデータベース１７を更新したり、その他、一般的に実現されているいかなる機能を発揮してもよい。以後、ジョブ処理システム１０にはあらかじめジョブが登録されており、それを実行することにより、各種機能を発揮する実運用がなされているものとして説明する。

このような状態においてジョブ処理システム１０は、新たに導入すべき新規プログラム、修正プログラム、あるいは新規ジョブに関する情報の入力をユーザから受け付ける。そして実運用と並行して当該新規プログラムやジョブのテストを行い、必要な情報を比較する。比較結果をユーザに示すことにより、ユーザはまさに本番の環境に新規ジョブを導入した場合の問題点を抽出でき、効率よい開発や本格導入の可否判断を実現できる。

図２はジョブ処理システム１０でバッチ処理されるジョブの例を模式的に示している。同図の横方向が時間の経過を表し、最小単位の矩形が一のジョブを表している。上述の通り、ジョブ処理システム１０では実際のシステム運用が行われており、その際に実行される処理の例が同図上段の「本番処理」７２とする。すなわち本番処理７２においては、「ジョブＡ」、「ジョブＢ」、「ジョブＣ」、「ジョブＥ」がこの順で処理される。

このような状況において、本番処理７２に含まれる「ジョブＢ」に代わる、「ジョブｂ」、「ジョブｄ」なる新規ジョブのテストを行いたいとする。このときジョブ処理システム１０は、本番処理７２において「ジョブＡ」を処理した後、本番ジョブ７６として「ジョブＢ」を処理するとともに、テスト対象である「ジョブｂ」、「ジョブｃ」も処理する。以後、テスト対象である一連のジョブを「仮想ジョブ」７８と呼ぶ。なお以後の説明で各「ジョブ」は「プログラム」と置き換えることもできる。

同図の例で本番ジョブ７６である「ジョブＢ」では、ファイル名「ａａａ．ｔｘｔ」なるファイルを入力ファイルとし、データベース１７を参照して処理を行うことにより、ファイル名「ｂｂｂ．ｔｘｔ」なるファイルを出力している。一方、仮想ジョブ７８に含まれる「ジョブｂ」では、「ジョブＢ」と同じくファイル「ａａａ．ｔｘｔ」を入力ファイルとし、データベース１７を参照して処理を行い、ファイル名「ｃｃｃ．ｔｘｔ」なるファイルを中間ファイルとして出力する。その後、「ジョブｄ」が、例えば中間ファイル「ｃｃｃ．ｔｘｔ」を用いて処理を行い、ファイル名「ｄｄｄ．ｔｘｔ」なるファイルを出力する。本番ジョブ７６および仮想ジョブ７８の入力ファイル「ａａａ．ｔｘｔ」は「ジョブＡ」が出力するファイルでもよい。

ここで「ジョブｄ」が出力するファイル「ｄｄｄ．ｔｘｔ」は、仮想ジョブ７８のテスト結果が良好となり、本番ジョブ７６である「ジョブＢ」に代えて本格導入した場合に、「ジョブＢ」が出力するファイル「ｂｂｂ．ｔｘｔ」に代わるファイルである。従ってファイル「ｄｄｄ．ｔｘｔ」とファイル「ｂｂｂ．ｔｘｔ」を比較することにより、仮想ジョブ７８を導入した際の、出力結果に与える影響を確認することができる。以後、本番ジョブ７６の出力ファイルを「本番出力ファイル」、仮想ジョブ７８において出力され、本番出力ファイルと比較することのできるファイルを「仮想出力ファイル」と呼ぶ。

ジョブ処理システム１０は、仮想ジョブ７８の処理を行うのに先立ち、本番出力ファイル「ｂｂｂ．ｔｘｔ」と仮想出力ファイル「ｄｄｄ．ｔｘｔ」を比較する比較用ジョブ８０を生成させる。そして仮想ジョブ７８の処理後のいずれかのタイミングで比較用ジョブ８０を実行し、比較結果を出力する。ユーザは比較結果を参照し、本番出力ファイル「ｂｂｂ．ｔｘｔ」と仮想出力ファイル「ｄｄｄ．ｔｘｔ」の中身が同一であったり、それらの差分が予定されていたものであった場合など、所定の基準によって仮想ジョブ７８の本格導入を決定できる。

仮想ジョブ７８および比較用ジョブ８０は、ユーザが新規ジョブのテストを行いたい場合にのみ発生するジョブ群であり、以後、これらをまとめて「仮想処理」７４と呼ぶ。仮想処理７４を実行するために必要な情報、すなわち、「ジョブｂ」、「ジョブｄ」の処理内容を示すジョブフローの情報、各ジョブにおいて実行されるプログラム、各ジョブの処理順、比較用ジョブ８０において比較すべきファイルの情報などは、本番処理７２を実行するために必要な情報の記憶装置における格納先とは異なる記憶領域に格納する。以後、この記憶領域を「仮想ディレクトリ」と呼ぶ。仮想ディレクトリに格納された情報は、テスト終了と同時に削除する。これにより、テストの実行によって本番処理が予想外の影響を受けたり、記憶領域を圧迫したり、といったことを防止し、より安全にテストを実行することができるとともに、テスト終了後にジョブ処理システム１０を元の状態に復元できる。

図２の例では、仮想処理７４は、本番処理７２に含まれる「ジョブＡ」の処理終了後に、本番ジョブ７６と並列に行っている。このように仮想処理７４は本番処理７２といずれかのタイミングで並列に処理するようにしてもよいし、リソース上の制限などによっては一部あるいは全部の処理を、本番処理７２と別のタイミングで行ってもよい。いずれにしろ、本番処理７２に含まれる「ジョブＡ」の出力ファイルを仮想ジョブ７８に含まれる「ジョブｂ」の入力ファイルとするときは、実際に「ジョブＡ」が出力したファイルをコピーして入力することにより、出力ファイルを比較する際の正確性が増す。

図３は第１サーバ１２の構成をより詳細に示している。第２サーバ１４も同様の構成としてよい。第１サーバ１２は、本番処理７２および仮想処理７４の処理に必要なファイルおよび出力ファイルなどを記憶する前出のハードディスク１３の他、本番処理７２を構成するジョブの処理内容、処理順、仮想ジョブ７８の処理内容などの登録を受け付け、比較用ジョブ８０の生成に必要な情報を抽出するジョブ登録部２２、比較用ジョブ８０を生成する比較用ジョブ生成部２６、本番処理７２や仮想処理７４を実行するジョブ処理部２８、本番処理７２の各出力ファイルを解析し、テストに必要な環境を整えるファイル解析部３８、出力ファイルの比較の結果、仮想ジョブ７８の本格導入が決定した際、本格導入（以後、「リリース」）と呼ぶ）のための処理を行うリリース処理部４０、および、出力ファイルの比較結果やテストの進捗度合いなどを出力してユーザに通知する出力部４２を含む。

図３において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、演算やファイル操作、データベースへのアクセスを行うプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

ジョブ登録部２２は、本番処理７２に含まれるジョブのジョブフローやジョブの処理順など、ジョブの処理に必要な情報の登録の他、新規ジョブのテストを行いたい場合は当該新規ジョブのジョブフローや処理順の登録をユーザが行うためのインターフェースである。ジョブ登録部２２は、登録画面を表示した表示装置と、キーボード、ポインティングデバイスなど登録画面に対して入力を行う入力装置と、ＣＰＵなど各種演算を行う装置との組み合わせでよい。

登録された情報は、スクリプトコードやジョブネット図など所定の形式でハードディスク１３に格納する。またジョブ登録部２２は、登録を受け付けたジョブが処理するプログラム等をハードディスク１３に格納する。ハードディスク１３には前述のとおり、本番処理７２に含まれるジョブが処理するプログラム等を格納する記憶領域として本番ディレクトリ３４を、仮想処理７４に含まれるジョブが処理するプログラム等を格納する記憶領域として仮想ディレクトリ３６を用意する。本番ディレクトリ３４と仮想ディレクトリ３６は、実際には一のハードディスクに含まれていなくてよく、例えば仮想ディレクトリ３６をネットワーク２０に接続した別のハードディスク中に設けてもよい。

さらにジョブ登録部２２は、テストを行う新規ジョブが処理するプログラムを仮想ディレクトリ３６に格納する際、当該格納処理に係る情報を仮想リリースログとして記録し、仮想ディレクトリ３６に格納する。仮想リリースログは例えば、プログラム名、格納日時、格納先である仮想ディレクトリ３６配下の個別ディレクトリの名前とを対応付けたテーブルとして構成する。仮想リリースログを保持することにより、テスト対象のジョブが存在することをジョブ処理部２８が検知できるとともに、本番ジョブとしてリリースを行う際にリリース処理部４０が、リリース対象のジョブのみをもれなく本番ディレクトリ３４にコピーし、確実に本番リリースを行える。さらにテスト終了後の不要なデータを確実に削除できる。仮想リリースログの具体例は後に述べる。

新規ジョブのテストを行う場合、ジョブ登録部２２は、本番ジョブ７６と仮想ジョブ７８のジョブフローから、比較対象のファイル名などを抽出してファイル情報のテーブルを作成し、仮想ディレクトリ３６に格納する。あるいは、本番処理７２に含まれるジョブのファイル情報のテーブルを、各ジョブが登録された時点であらかじめ作成して本番ディレクトリ３４に格納しておき、新規ジョブのテストについて登録がなされた際に、当該ジョブのファイル情報のテーブルを別に作成して仮想ディレクトリ３６に格納してもよい。ファイル情報のテーブルは、本番ジョブ７６と仮想ジョブ７８に含まれる各ジョブの名前と、それがアクセスするリソース名やファイル名、入出力の区別などの情報を含むテーブルである。ファイル情報のテーブルの具体例は後に述べる。

比較用ジョブ生成部２６は、新規ジョブのテストを行う際、ジョブ登録部２２が作成したファイル情報のテーブルを読み出し、本番ジョブ７６と仮想ジョブ７８がそれぞれ出力するファイルから、比較を行うべきファイルを抽出して、比較用ジョブ８０のジョブフローを作成する。比較用ジョブ８０は図２に示すとおり、比較対象となる出力ファイルを読み出し、あらかじめ用意された比較用プログラムを実行することによりファイルの差分などを抽出した後、その情報を比較結果として出力する処理である。比較用プログラムは、必要な差分情報などを考慮してあらかじめ作成したものを仮想ディレクトリ３６等に格納しておく。作成された比較用ジョブのジョブフローも仮想ディレクトリ３６に格納しておく。

ジョブ処理部２８は、本番処理７２を実行する本番ジョブ処理部３０と、仮想ジョブ７８および比較用ジョブ８０を含む仮想処理７４を実行する仮想ジョブ処理部３２を含む。いずれの場合も、ジョブフロー、ジョブの処理順などの情報と、処理に必要なプログラムなどをハードディスク１３から読み出して実行する。本番ジョブ処理部３０は、本番処理７２の出力データを本番ディレクトリ３４に格納する。仮想ジョブ処理部３２は、前述の仮想リリースログを参照し、テスト対象となるジョブがあることを検知したら処理を開始し、仮想処理７４の出力データを仮想ディレクトリ３６に格納する。仮想処理７４に含まれる比較用ジョブ８０の出力データである比較結果も仮想ディレクトリ３６に格納する。

プログラム等、処理に必要なデータと出力データとは、実際には異なる記憶領域に分けて保存してもよいが、その場合も本番処理用のディレクトリと仮想処理用のディレクトリとで区別する。本番ジョブ処理部３０と仮想ジョブ処理部３２は、実際には一のＣＰＵユニットの処理時間をそれぞれに割り当てることにより実体化してもよい。

ジョブ処理部２８は、一般的に用いられるジョブスケジューラを起動し、環境変数を設定することによりジョブの処理を開始してもよい。この場合、新規ジョブのテストをする際は、仮想ディレクトリ３６を優先させて環境変数の設定を行うようジョブスケジューラを管理する。本番処理７２および仮想処理７４を並列で実行するか否かによって、本番ディレクトリ３４、仮想ディレクトリ３６の優先の度合いを適宜変化させる。

ファイル解析部３８は、ハードディスク１３に格納されたファイルを解析することにより、効率的かつ正確にテストが遂行されるように、仮想処理７４を行うタイミングなどの管理を行う。例えば、月末に日々の計上数値を集計する場合など、実行される日によってジョブの処理内容が異なる場合、ある１日のみテストを行って問題が発生しなかったとしても、別の日には問題となることがあり得る。従って、処理内容が変化するジョブの場合は、処理内容が異なる全ての日程でテストを行い、その結果を確認する必要がある。ファイル解析部３８は、本番ディレクトリ３４に蓄積して格納された、本番処理７２の出力ファイルを解析することによって、どのような日程でテストを行うべきかを割り出す。そしてジョブ処理部２８にその情報を通知することにより、仮想ジョブ処理部３２がその日程で仮想処理７４を実行する。

仮想ジョブ処理部３２が仮想処理７４を行う都度、ファイル解析部３８はテストが必要な全日程のうちどの程度の割合でテストが終了したかを管理し、ユーザに通知する。これにより、ユーザはリリースの見通しを正確に把握することができる。ファイル解析部３８は上述のとおり、本番処理７２の出力ファイルを解析することによりテストが必要な日程を割り出すことができるため、本番処理７２に含まれるジョブの詳細な処理内容をユーザが把握していない場合は特に有用となる。ファイル解析部３８は、テスト日程を割り出す前段階として、ジョブで実行されるプログラムが行う処理の内容を導出する。したがってこの機能を、単にプログラムの処理内容を把握したい場合に用いることもできる。さらに、ファイルの解析結果を利用して、比較用ジョブ８０が行った比較結果の解釈を行うこともできる。ファイル解析部３８の具体的な処理手順は後に述べる。

リリース処理部４０は、仮想ジョブのリリースを行う旨の指示入力をユーザから受け付け、リリースのための処理を行う。具体的には仮想リリースログを仮想ディレクトリ３６から読み出し、ユーザがリリースを許可したジョブが処理するプログラムを仮想ディレクトリ３６の格納先から本番ディレクトリ３４へコピーし、コピーしたプログラムを実行すべきジョブのジョブフローを本番ジョブ７６のジョブフローとして設定し直す。さらにジョブの処理順に係る情報を、当該ジョブを含むように設定し直す。

その後、リリース処理部４０は、本番ディレクトリ３４へコピーしたプログラムが格納されていた仮想ディレクトリ３６内の記憶領域から当該プログラムを削除するとともに、仮想ジョブ７８や比較用ジョブ８０のジョブフロー、仮想ジョブが出力したファイルも、仮想ディレクトリ３６から削除する。テスト終了後、リリースを行わない場合も同様の削除処理を行ってよい。リリース処理部４０は、入力装置と、ＣＰＵなど各種ファイル操作を行う装置との組み合わせでよい。

出力部４２は、仮想ジョブ処理部３２において実行された比較用ジョブ８０の出力データである、本番出力ファイルと仮想出力ファイルとの比較結果を出力する。さらに、ファイル解析部３８が割り出した、テストが必要な日程や、テストの進捗度合いなどの情報も出力する。出力部４２は一般的な表示装置やプリンタなどの出力装置でもよいし、電子メールやファクシミリなどの通信機器をさらに含んでもよい。

次に、これまで述べた構成によって実現できる、第１サーバ１２の動作を説明する。図４は第１サーバ１２が行う新規ジョブのテストの処理手順を示すフローチャートである。まずユーザがジョブ登録部２２に対し、新規ジョブのテストを行いたい旨の入力と、新規ジョブに係る情報の登録を行う（Ｓ１０）。このときユーザは、テストを行う新規ジョブと入れ替えたい本番処理７２に含まれるジョブ、すなわち本番ジョブ７６の指定も行う。

するとジョブ登録部２２は、新規ジョブを仮想ジョブ７８としてジョブフローや処理順などの情報、および当該ジョブが処理するプログラムを、仮想ディレクトリ３６に格納し、格納情報を仮想リリースログとして記録する（Ｓ１２）。既に別のジョブについてテスト中である場合など、仮想リリースログが既存の場合は更新する。また、新規ジョブと入れ替えるジョブとして指定された本番ジョブ７６の識別情報も仮想ディレクトリ３６に記録しておく。

次にジョブ登録部２２は、本番ジョブ７６および仮想ジョブ７８のジョブフローから、アクセスするファイル名や入出力の区別などの情報をそれぞれ抽出し、ファイル情報のテーブルを作成して仮想ディレクトリ３６に格納する（Ｓ１４）。上述のとおり本番ジョブ７６のファイル情報はあらかじめ本番ディレクトリ３４に格納しておいてもよい。その後、比較用ジョブ生成部２６は、ファイル情報のテーブルから、本番出力ファイルおよび仮想出力ファイルのファイル名とそれが格納される記憶領域を抽出して比較対象を特定し、比較用ジョブ８０のジョブフローを作成する（Ｓ１６）。

各ジョブの出力ファイルが複数存在する場合など、ジョブフローから比較対象となるファイルの特定が困難な場合は、出力部４２を制御してユーザに確認を促す出力を行ってもよい。あるいはジョブ登録部２２があらかじめ比較対象となるファイルを登録するようにユーザに求めるようにしてもよい。また仮想ジョブ７８が、本番処理７２において本番ジョブ７６の前に処理されるジョブ（図２の例では「ジョブＡ」）の出力ファイルを入力ファイル（図２の例では「ａａａ．ｔｘｔ」）とする処理を行う場合は、当該前に処理されるジョブのファイル情報も抽出しておく。本番ジョブ７６の前に処理されるジョブは、記憶しておいた本番ジョブ７６の識別情報と本番処理７２のジョブフローから特定できる。これにより、仮想ジョブ７８の入力ファイルを、本番処理７２で実際に出力されるファイルとして設定する処理を、ファイル情報のテーブルに基づき行うこともできる。

次にジョブ処理部２８は、本番処理７２および仮想処理７４を実行する（Ｓ１８）。ただし本実施の形態は本番機でのテストを想定しているため、本番処理７２は、元々設定されたスケジュールで実行する。一方、仮想処理７４は、ファイル解析部３８が導出した、テストが必要な日程で、本番処理７２と並列に、あるいは本番処理７２の処理後に実行する。一回のテストで十分であることが明らかな場合などは、ファイル解析部３８による処理を適宜省略してもよい。

ジョブ処理部２８の仮想ジョブ処理部３２は、仮想処理７４として、仮想ジョブ７８に続き比較用ジョブ８０を処理して、本番出力ファイルと仮想出力ファイルとを比較する（Ｓ２０）。比較結果は出力部４２を介してユーザに通知される。ユーザが比較結果を確認し、テスト結果が問題ない旨の入力を行ったら（Ｓ２２のＹ）、リリース処理部４０は、仮想ディレクトリ３６に格納されたプログラムを本番ディレクトリ３４にコピーし、本番ディレクトリ３４のジョブフローやジョブの処理順などを更新することにより、仮想ジョブ７８を本番環境に移行する（Ｓ２４）。そして、仮想ディレクトリ３６に格納された当該ジョブのプログラムや比較用ジョブ８０のジョブフロー、仮想出力ファイルなどを削除する（Ｓ２６）。

一方、出力ファイルの比較結果に問題があるなどして、仮想ジョブ７８をリリースせずにテストを終了したい旨の入力がユーザよりなされたら（Ｓ２２のＮ）、Ｓ２４の本番環境への移行処理を行わずに仮想ディレクトリ３６に格納されたデータのみ削除する（Ｓ２６）。ファイル解析部３８が解析した結果、別の日程で複数回のテストを行う必要がある場合は、Ｓ２４における本番環境への移行などのリリース処理は、全てのテストを終了した後に行う。なお後に述べるように、Ｓ２２においてテスト結果を問題なしと判断するのは、ファイル解析部３８が自動で行うこともできる。

図５は、ジョブ登録部２２が本番ジョブ７６および仮想ジョブ７８から抽出して作成する、ファイル情報のテーブルの例を示している。ファイル情報のテーブル１００は、ジョブ名欄１０２、利用リソース種類欄１０６、リソース詳細欄１０８、処理内容欄１１０、入力ファイル欄１１２、出力ファイル欄１１４、および比較対象欄１１６を含む。ジョブ名欄１０２にジョブ名が記載された各ジョブが利用するリソースの種類、具体的なリソースの識別情報、当該リソースに対し行う処理の内容、当該処理によって各ジョブに入力されるファイル名、出力されるファイル名、比較対象のファイルであるか否かの識別情報が、利用リソース種類欄１０６、リソース詳細欄１０８、処理内容欄１１０、入力ファイル欄１１２、出力ファイル欄１１４、および比較対象欄１１６を含む。ジョブ名欄１０２にそれぞれ記載される。

図５の例は、図２に示した本番ジョブ７６である「ジョブＢ」、および仮想ジョブ７８である「ジョブｂ」、「ジョブｄ」の処理をファイル情報のテーブルとしたものである。すなわち「ジョブＢ」は、利用するリソースとしてデータベース１７を表す「ＤＢＭＳ」およびハードディスク１３を表す「ＤＩＳＫ」が利用リソース種類欄１０６に記載され、具体的なリソースとしてデータベース１７中のデータベース名「会計ＤＢ」、およびハードディスク１３における「ドライブＤ」がリソース詳細欄１０８に記載される。また、データベースに対する処理は「会計ＤＢ」に対する「参照」であり、「ドライブＤ」に対する処理はファイル「ａａａ．ｔｘｔ」の読み出し（すなわちジョブに対する入力）およびファイル「ｂｂｂ．ｔｘｔ」の書き込み（すなわちジョブからの出力）であるため、処理内容欄１１０、入力ファイル欄１１２、出力ファイル欄１１４にはそれぞれそのように記載されている。

「ジョブｂ」および「ジョブｃ」に対しても同様の記載がなされている。また、比較対象欄１１６には、「ジョブＢ」が出力するファイル「ｂｂｂ．ｔｘｔ」および「ジョブｄ」が出力するファイル「ｄｄｄ．ｔｘｔ」が比較対象であることを識別する情報が記載されている。同図の例では双方に「１」が記載されているが、その他に比較対象の組が存在する場合は「２」などとすることにより組同士を識別できるようにする。前述のとおり、比較対象のファイルはユーザによって指定するようにしてもよいし、出力されるファイルを抽出したり、そのファイル名から類推したりして、ジョブ登録部２２が自動で判断を行うようにしてもよい。

自動で判断を行う場合、ファイル情報のテーブル１００に比較対象欄１１６を設けず、比較用ジョブ生成部２６が比較用ジョブ８０を作成する際に判断するようにしてもよい。その場合もファイル情報のテーブル１００を準備しておくことにより、以前に登録された本番ジョブ７６であっても、出力ファイルのファイル名や格納先などのファイル情報を容易に特定することができる。なおファイル情報のテーブルのデータ構造は、図５に示した欄に限定するものではなく、比較対象となるファイルが特定できればその形式はいかなるものでもよい。

図６はジョブ登録部２２が記録し、リリース処理部４０が更新する、仮想リリースログの、各処理段階における変化例を示している。まず、本番処理７２のみが登録され、実運用されている状態では、図６（ａ）に示すように、本番処理７２に含まれるジョブのプログラムが本番ディレクトリ３４にのみ、格納されている。この例では、「プログラムＡ」、「プログラムＢ」、「プログラムＣ」、「プログラムＥ」が格納されているが、これは図２の本番処理７２における「ジョブＡ」、「ジョブＢ」、「ジョブＣ」、「ジョブＥ」において実行されるプログラムと考えることができる。仮想リリースログにはプログラム名のほか、それをディレクトリに格納したタイムスタンプの日付を記録する。本番ディレクトリなどが複数存在する場合は、その場所を特定できるように所属するサーバ名やドライブ名などをさらに記録してもよい。

図６（ｂ）はテストを行いたい新規ジョブの登録を受け、仮想ディレクトリ３６に当該ジョブのプログラムを格納した後の仮想リリースログを示している。この例では、「プログラムＢ」の代替プログラムとして「プログラムｂ」および「プログラムｄ」が仮想ディレクトリ３６のいずれかのディレクトリ「第１ディレクトリ」に「７月１日」のタイムスタンプで格納されている。これらのプログラムはそれぞれ、図２における仮想ジョブ７８の「ジョブｂ」、「ジョブｄ」において実行されるプログラムと考えることができる。

図６（ｂ）のように仮想リリースログが記録されている場合、テストが必要な日程において、本番処理７２に加え、「プログラムＡ」を実行するジョブの処理の後、「プログラムｂ」を実行するジョブ、および「プログラムｄ」を実行するジョブを処理するよう、ジョブスケジューラなどが環境設定を行う。これにより本番ジョブ処理部３０および仮想ジョブ処理部３２では「プログラムＢ」と、「プログラムｂ」および「プログラムｄ」がそれぞれ実行される。「プログラムｄ」を実行するジョブの後、仮想ジョブ処理部３２は前述のとおり比較用ジョブ８０を処理する。本番ジョブ処理部３０は当然、「プログラムＢ」を処理するジョブの後、「プログラムＣ」、「プログラムＥ」を実行するジョブを処理する。

図６（ｃ）は、図６（ｂ）のような状況において、新たにテストを行いたい新規ジョブの追加登録がなされた場合を示している。同図の例では、「プログラムｅ」が「７月２日」のタイムスタンプで仮想ディレクトリ３６の「第１ディレクトリ」と異なるディレクトリ「第２ディレクトリ」に格納されている。このプログラムは本番処理７２に含まれる「プログラムＥ」の代替プログラムである。このように、テストを行いたい単位ごとに異なる記憶領域を仮想ディレクトリ３６内に設けることにより、世代別にテストを行い、比較結果をそれぞれ確認することができる。

同図の例では、「プログラムＡ」→「プログラムｂ」→「プログラムｄ」→「プログラムＣ」→「プログラムＥ」なる処理と、「プログラムＡ」→「プログラムｂ」→「プログラムｄ」→「プログラムＣ」→「プログラムｅ」なる処理とを個別のテストとして行える。すなわち、「プログラムｂ」と「プログラムｄ」がリリースされた後の世代として「プログラムｅ」のリリースの可否をテストする、という世代別のテストを個々に行うことができる。比較用ジョブ生成部２６は、それぞれのテスト対応する比較用ジョブのジョブフローを作成し、ジョブ処理部２８は各テストの後にそれぞれの比較用ジョブを処理する。

また、リリース処理も個別に行うことができる。図６（ｄ）は、「プログラムｂ」および「プログラムｄ」のテスト結果が良好だった場合に、当該プログラムを実行するジョブをリリースした後の仮想リリースログを示している。この段階では、図中、太字で示したように「プログラムｂ」および「プログラムｄ」が本番ディレクトリ３４に格納され、仮想ディレクトリ３６に残されているプログラムは「プログラムｅ」のみとなっている。図６（ｅ）はその後、ユーザの指示により、「プログラムｅ」を実行するジョブのリリースを行わずにテストを終了させた段階を示している。このとき「プログラムｅ」は仮想ディレクトリ３６から削除され、本番ディレクトリ３４のみに本番処理７２で処理されるプログラムが格納されている。

このように仮想リリースログを記録することにより、テストを行う単位が明確となり、リリースが許可された際も、もれなく本番環境への移行を行うことができる。なお図６に示した仮想リリースログは、理解を容易にするために本番ディレクトリ３４に格納されるプログラムも併記したが、実際には仮想ディレクトリ３６に格納されているプログラム、およびそのプログラムが本番ディレクトリ３４に格納されたどのプログラムの代替となるか、の情報のみをもって仮想リリースログとしてもよい。また場合によっては、別個に登録した複数の新規ジョブのテストを同時に行うような設定を受け付けてもよい。この場合、仮想ディレクトリ３６の同じ格納領域に当該複数の新規ジョブが実行するプログラムを全て格納することにより、上述と同様の手続きでテストを行うことができる。

次にファイル解析部３８の構成および動作について説明する。図７はファイル解析部３８の詳細な構成を示している。ファイル解析部３８は前述のとおり、プログラムの出力結果から当該プログラムの処理内容の特性を自動で取得し、テストを行うべき日程などを決定する。ファイル解析部３８は、プログラムのソースコードなどから出力ファイルのデータ形式を解析し、注目すべき項目を特定するデータ形式解析部５２、ハードディスク１３に蓄積された複数の出力ファイルの差分から更新内容を取得し、プログラムの処理内容を特定する処理内容特定部５４、更新内容をグルーピングして更新特性を取得する更新特性取得部５６を含む。

ファイル解析部３８はさらに、プログラムのテストを行う際に、テストを行うべき日程を決定するとともに、テスト結果において確認すべき項目を決定するテストケース作成部５８、テストを行うべき日程においてジョブ処理部２８に仮想処理７４を実行させるとともに、出力部４２から出力する、テストの進捗度合いなどの情報を作成する比較処理管理部６０を含む。

データ形式解析部５２は、プログラムのソースコードを解析して、当該プログラムの入力ファイル、出力ファイルのレイアウトおよびデータキーを特定する。ここで「データキー」とは、入力ファイルに記録された複数の項目に対応してプログラムが生成したデータを各項目と対応づけて記録した出力ファイルにおいて、データを特定する項目、またはその値をいう。例えば「従業員番号」と当該従業員の「給与支払い残高」とを対応づけた給与ファイルを例にとると、従業員番号から給与が特定できるため「データキー」となる。データキーは、その値を１つ選択すると、対応する値、すなわち支払い残高の数値データが定まる。

「ファイルのレイアウト」はファイルに含まれる項目と、それが記載されているファイル上の位置やアドレスなどとを対応付けた情報である。例えば「従業員番号」が１カラムめ、「給与支払い残高」が２カラムめに記載されている、などといったデータの並び方をいう。ファイルのレイアウトとデータキーを特定すると、解析対象プログラムの入力ファイルと出力ファイルのデータを同一のデータキーで比較して、差分を取得することができる。この差分がすなわち当該プログラムの処理内容を表すことになる。

ファイルのレイアウトとデータキーを特定するために、あらかじめプログラム解析用のロジックパターンを用意しておく。データ形式解析部５２は、このロジックパターンに基づきプログラムのソースコードを検索し、レイアウト定義を行っている箇所およびマッチング処理、ブレーク処理を行っている箇所をプログラムから抽出することにより出力ファイルのレイアウトおよびデータキーをそれぞれ特定する。通常、レイアウト定義やマッチング処理、ブレーク処理の記述式はフォーマットが限定的であるため、ロジックパターンでの抽出が可能である。なお出力ファイルのレイアウトが特殊な場合など、定義の記述を抽出できない場合は、ユーザにレイアウトに係る情報を入力させるようにしてもよい。

ここでマッチング処理とは、出力ファイルを生成するために複数の入力ファイルを突き合わせて同じ項目、すなわち同一のデータキーに対応づけられた数値データを抽出する処理である。前出の給与ファイルの例では、入力ファイルとして従業員番号と基本給とを対応づけたファイルａと、従業員番号と残業時間および時給を対応づけたファイルｂとをマッチング処理することにより、同じ従業員番号の基本給と（残業時間×時給）から算出される残業代を合計し、従業員番号と最終的な給与額とを対応付けた出力ファイルを生成できる。このような処理を行っている箇所をソースコードより抽出し、マッチングの根拠となっている項目を同定することにより、「従業員番号」がデータキーであることが特定できる。

ブレーク処理とは、一のファイル内のある項目、すなわちデータキーとして同じ値が連続して記載されているような場合にその範囲を特定し、範囲内の数値データを合計したりする際に行う処理である。前出の給与ファイルの例では、従業員番号ごとに各種手当金が複数行にわたり記載されているファイルｃから、同じ従業員番号について記載された行の範囲をブレーク処理で特定することにより、範囲内に記載された手当金を合計し、従業員番号と手当金の合計とを対応付けた出力ファイルを生成できる。以下にこの処理を行うコードの例を示す。

While
If Filec_Lavel_a = Sv_Lavel_a Then
Put_c += Filec_Lavel_d
Else
Put_a = Filec_lavel_a
Put_b = Filec_lavel_b
（中略）
sv_Lavel_a = Filec_Lavel_a
（中略）
End While

上記のコードでは、「Filec_Lavel_a」が上述の例の従業員番号、「Filec_Lavel_d」が手当金にあたる。ある従業員番号がループ内でセーブされ、以後、同じ項目の値がセーブされた値と比較されている。その結果が同一であれば、その行の数値データ、すなわち手当金を加算していく。このような処理の場合、ブレーク処理のキー、すなわち「Filec_Lavel_a」をデータキーとして特定できる。

また、パターンマッチングができないなど何らかの理由によりプログラムの解析でデータキーが特定できない場合は、入力ファイルと出力ファイルを統計分析してデータキーを特定してもよい。例えばデータキーは、入力ファイルと出力ファイルで同じ値のデータ数が、ｎを自然数としたとき、１対１に対応するか、ｎ対１に対応するか、１対ｎに対応するかのいずれかである場合が多い。この性質を利用して入力ファイルと出力ファイルの各カラムの値の個数を比較し、このような対応が見られるカラムを抽出することによってデータキーを特定する。またプログラムの解析でデータキーが特定できた場合でも、統計分析により再確認を行うことによりデータキー特定の精度を上げても良い。さらに、比較用ジョブ８０において本番出力ファイルと仮想出力ファイルを比較する際、プログラムの解析によって特定したデータキーが上記対応をなしていない場合、データキーの特定に一旦処理を戻し、統計分析も含めてデータキーを特定し直したうえ、出力ファイルの比較を行う、というスパイラルな処理を行うようにしてもよい。このようにすることで、比較の精度が向上する。

処理内容特定部５４は、解析対象のプログラムの入力ファイル、出力ファイルをハードディスク１３より読み出し、ファイルのレイアウトに基づき、データキーごとに、それに対応づけられた、同じ項目の数値データと突き合わせを行うことにより、当該数値データの差分を取得する。例えば従業員番号に対応づけられたある項目の数値データが、入力ファイルでは「０」の値であったものが出力ファイルでは０以外の数値であった場合、それを差分として抽出する。これにより、対象プログラムは当該差分を発生させる処理を行っている、ということが特定できる。

差分の取得時、別のデータキー、例えば別の従業員に対応付けられた数値データと比較しても意味がないため、データ形式解析部５２が特定するデータキーが必要となる。処理内容特定部５４は、実運用においてハードディスク１３に蓄積された、所定期間分の入出力ファイルのそれぞれから差分を抽出しておく。あるいは仮想処理７４における入出力ファイルを処理対象としてもよい。

更新特性取得部５６は、データキーの値と、それぞれに対応づけられた数値の更新内容、例えばどのプログラムによりいつどのように更新されたか、といった情報とを紐づけ、データ更新の特性によってデータキーの値を分類する。例えば出勤形態の異なる従業員の日給データのファイルの場合、従業員番号がデータキーであるから、従業員番号の具体的な値にそれぞれ対応付けられたデータの更新内容を取得することにより、上１桁が「９」の従業員番号に対応する数値データはプログラムＸにより毎日更新され、上１桁が「１」の従業員番号に対応する数値データはプログラムＹにより金曜日にのみ更新されている、というように分類できる。データキーが複数の項目からなる場合も同様に、単一の項目ごと、および当該複数の項目の値の組み合わせごとに更新特性の分類可否を解析する。

これには例えば、更新内容の各種情報をデータキーごとに順次取得していき、前に取得された更新内容のパターンと同様のパターンの更新内容を有するデータキーをまとめていくことによって実現できる。更新処理はデータ中に潜在的に混合する複数のグループの一部を更新していると仮定して解析し、プログラムが行う更新内容を順序立てて表現することが可能となる。それを出力部４２より出力すると、ユーザがプログラムの仕様を把握し易くなる。

テストケース作成部５８は更新特性取得部５６が取得した結果に基づき、テストを実行すべき日程と、各日程においてテストを実行した際、確認すべき項目を決定する。例えば上記の例では、上１桁が「９」の従業員番号のデータに関しては任意の日付、上１桁が「１」の従業員番号のデータに関しては金曜日に、各データを入力ファイルとする仮想処理７４を実行し、本番処理７２の結果と比較する必要がある。このように実運用において発生しうる状況を網羅するようにテストを実行することにより、リリース後に問題が発生するのを防止できる。また、テストの実行を必要最小限に抑えることができ、無駄なテストによって実運用に用いるリソースを圧迫したり、運用オペレータの負担を増やすことがなくなる。

比較処理管理部６０は、テストケース作成部５８が決定した内容を出力部４２から出力するとともに、ジョブ処理部２８を制御し、テストを実行すべき日に仮想処理７４を実行させる。実際には前述のジョブスケジューラに仮想処理７４を行うように要求してもよい。同時に、テストの進捗度合いの情報を出力部４２から出力する。

比較処理管理部６０はさらに、比較用ジョブ８０の比較結果を取得し、所定の基準によって本番出力ファイルと仮想出力ファイルとが不一致であることを検出すると、上述のデータキーの分類を利用して不一致の原因を予測してもよい。所定の基準とは全ての項目の値、あるいは所定の項目の値が一致している場合に、それを一致と判定するなど、あらかじめ処理内容に応じて設定しておく。一方、本番出力ファイルを統計処理してそれまでの各項目の値の傾向を算出し、不一致となった値が、それまでの傾向から著しく逸脱している場合に当該値を更新した処理を原因として導出する。ここで値の傾向は、不一致となった項目単独での発生確率、および、当該値と因果関係のある項目との複合条件による発生確率によって表す。

この際、上記データキーの更新特性による分類結果を利用する。具体的には、分類対象となったデータキーの値の範囲と範囲別の出現率、およびデータキーが各範囲にあるときの他の項目の値の範囲と範囲別の出現率を算出する。これにはベイジアンネットワークによる確率的な因果関係の解析手法と同様の手法を適用することができる。すなわち分類対象となったデータキーを親ノードとし、それ以外の項目を子ノードとしてリンクを張る。ここで子ノードの項目、すなわち分類対象となったデータキー以外の項目同士に因果関係が存在する場合はその項目同士もリンクを張る。そしてそれぞれの項目について値の範囲と出現率との組を算出しておく。

そして、不一致となった値を含む行について、親ノードから子ノードへリンクを辿ることにより、分類対象となったデータキーの範囲や因果関係のあるその他の項目の範囲を条件に含めた場合の、不一致となった項目の範囲別の確率を取得し、不一致となった値がどの程度の確率で発生し得るかを導出する。発生確率が低ければ当該項目の更新処理が不一致の原因である確率が高くなる。比較処理管理部６０は例えば、発生確率が所定のしきい値以下である項目やその更新処理を行っているプログラムなどを、不一致の原因として出力部４２を介してユーザに通知する。ただしユーザへの通知手法はこれに限らず、例えば発生確率を所定の換算式で原因確率に換算して出力するなどでもよい。

次にファイル解析部３８の動作について説明する。図８はファイル解析部３８が行うファイル解析およびテスト実行管理の処理手順を示すフローチャートである。まずハードディスク１３の仮想ディレクトリ３６に仮想ジョブ７８のプログラムが格納された、といったことを検出することにより、ファイル解析部３８はテストの開始を検知する（Ｓ２８）。あるいは、ユーザがテスト対象のプログラムの登録をジョブ登録部２２に対し行った際、ジョブ登録部２２から通知するようにしてもよい。

するとデータ形式解析部５２は、ハードディスク１３の本番ディレクトリ３４から本番ジョブ７６のプログラムのソースコードを読み出し、入出力ファイルのファイルレイアウトおよびデータキーを取得する（Ｓ３０）。Ｓ３０の処理は、プログラムが登録される都度、実行し、得られた情報を前もってハードディスク１３に格納しておくようにしてもよい。続いて処理内容特定部５４は、本番ディレクトリ３４から本番ジョブ７６で実行されるプログラムが出力した所定期間の出力ファイルを読み出し、上述のように入力ファイルと出力ファイルの差分を取得することでプログラムの処理内容を特定する（Ｓ３２、Ｓ３４、Ｓ３６）。本番ジョブ７６が複数のプログラム処理を含み、それらのプログラムの入出力ファイルが得られる場合は、プログラムごとに処理内容を特定する。テスト対象のプログラムによっては、通常出力しないファイルをテストのために出力するようにしてもよい。

次に更新特性取得部５６は、数値データの更新内容に基づきデータキーを分類する（Ｓ３８）。この際、各データキーに対応する数値データを更新しているプログラムとも紐づけを行うことにより、どのプログラムがどのような処理特性を有するかを特定する。するとテストケース作成部５８は、特定された処理特性に基づき、テストを実行すべき日程およびテスト結果において確認すべき項目を導出することによりテストケースを作成する（Ｓ４０）。確認すべき項目は、その日程で更新される項目と考えることができる。それらの情報を受け取ると比較処理管理部６０は、出力部４２より当該情報を出力してユーザに開示するとともに、ジョブ処理部２８を制御してテストを日程通りに実行させる。そして、テストの進捗度合いを管理し、出力部４２より出力する、といったテストの実行管理を行う（Ｓ４２）。

ユーザは、ジョブ処理部２８の仮想ジョブ処理部３２が出力部４２を介して出力した、本番出力ファイルと仮想出力ファイルとの比較結果のうち、比較処理管理部６０が出力した確認すべき項目を確認する。これによりリリースの可、不可を効率的に判断できる。また進捗度合いを確認することにより、リリースの見通しを立てることができる。あるいは前述の如く、比較処理管理部６０が、本番出力ファイルと仮想出力ファイルとの比較結果からリリースの可、不可を自動で判断してもよい。例えば、テストケース作成部５８が特定した、確認すべき項目の数値データが、本番出力ファイルと仮想出力ファイルとで差がなかった場合に、テスト対象のプログラムが問題ないと判断してもよい。また、別の判断基準をあらかじめ設定しておいてもよい。

さらに、上述のとおり本番出力ファイルと仮想出力ファイルとで不一致と判定したら、Ｓ３８における分類結果を利用して不一致の原因である値、その項目、更新しているプログラムの記載などを特定し、ユーザに通知してもよい。

以下、ファイル解析部３８の処理内容を具体例に沿って説明する。図９は以後の説明で想定する処理のフロー例と入出力ファイルの内容例を示している。処理のフロー例１７０では、「プログラムＡ」、「プログラムＢ」、「プログラムＣ」の３つのプログラムがこの順で処理される。これらのプログラムは実運用で実行されており、これらのプログラムに代わる３つのプログラムのテストに際し、ファイル解析部３８が解析を行う場合について説明する。

処理のフロー例１７０では、「プログラムＡ」は「勘定科目残高」ファイルと「外国通貨残高」ファイルを入力ファイルとし、「勘定科目残高」ファイルを更新する処理を行う。「プログラムＢ」は「プログラムＡ」の出力ファイルである「勘定科目残高」ファイルと「外国債券残高」ファイルを入力ファイルとし、「勘定科目残高」ファイルを更新する処理を行う。「プログラムＣ」は「プログラムＢ」の出力ファイルである「勘定科目残高」ファイルと「外国為替レート」ファイルを入力ファイルとし、「勘定科目残高」ファイルを更新する処理を行う。すなわち「勘定科目残高」ファイルが３つのプログラムによって順次更新されていく。同図の例では、「プログラムＡ」が外国通貨を取り込む処理、「プログラムＢ」が外国債券を取り込む処理、「プログラムＣ」が月間累計を算出する処理を行うが、そのような処理内容を把握していなくても処理内容に係る必要な情報を以下のように取得できる。

同図では、各プログラムに入出力される際の「勘定科目残高」ファイルの内容例を、破線矢印で対応づけて示している。「勘定科目残高」は種別欄１７２ａ、基準日付欄１７２ｂ、外国通貨欄１７２ｃ、および外国債券欄１７２ｄからなるデータ構造を有する。まず、「プログラムＡ」に入力される際の「勘定科目残高」ファイルは、データ１７２のように、データの種別として「日別明細」が種別欄１７２ａに、処理された日付として「２００７／７／１」が基準日付欄１７２ｂに記載されている。外国通貨欄１７２ｃ、および外国債券欄１７２ｄは書き込みがなされておらず初期値として「０」が記載されている。

次に「プログラムＡ」から出力され、「プログラムＢ」に入力される「勘定科目残高」ファイルは、データ１７４のように、データ１７２の外国通貨欄１７２ｃに値「１１１１１１．００」を書き込んだものである。次に「プログラムＢ」から出力され、「プログラムＣ」に入力される「勘定科目残高」ファイルは、データ１７６のように、データ１７４の外国債券欄１７２ｄに値「２２２２２２．２２」を書き込んだものである。そして「プログラムＣ」から出力される「勘定科目残高」ファイルは、データ１７８のように、新たなデータの種別として「月間累計」が種別欄１７２ａに、処理された日付として「２００７／７／１」が基準日付欄１７２ｂに、値「１１１１１１．００」が外国通貨欄１７２ｃに、値「２２２２２２．２２」が外国債券欄１７２ｄに記載された新たな行が追加されている。

このような状況において各プログラムに代わるプログラムのテストを行う際、まずデータ形式解析部５２は、各プログラムのソースコードを解析することにより、種別欄１７２ａおよび基準日付欄１７２ｂに記載された値がデータキーであり、それぞれの行の右２つの欄、すなわち外国通貨欄１７２ｃおよび外国債券欄１７２ｄに、データキーに対応する数値データが記載されることを特定する。すると処理内容特定部５４は、データ１７２、データ１７４、データ１７６、データ１７８のような内容を有する「勘定科目残高」ファイルをハードディスク１３より読み出す。

そして同日に処理された「勘定科目残高」ファイルの各段階の差分を取得する。図１０はファイルの差分を、各項目に対し生成、読み出し、更新、削除のいずれがなされたかを示すＣＲＵＤ（Create, Read, Update, Delete）として取得した場合の取得結果例を示している。同図のデータは図９に示した処理のフローを実行した際の「勘定科目残高」ファイルの差分を示している。差分データ１８０は、処理日欄１８２ａ、処理時刻欄１８２ｂ、プログラム欄１８２ｃ、種別欄１８２ｄ、基準日付欄１８２ｅ、外国通貨欄１８２ｆ、および外国債券欄１８２ｇを含む。処理日欄１８２ａ、処理時刻欄１８２ｂ、プログラム欄１８２ｃには、読み出されたファイルが各プログラムにより出力された日、時刻、および出力したプログラム名が記載される。ファイルとプログラムの紐付けは、ログを参照して取得してもよいし、ジョブが登録された際、入出力ファイル情報を抽出しておいてもよい。

そして種別欄１８２ｄ、基準日付欄１８２ｅ、外国通貨欄１８２ｆ、および外国債券欄１８２ｇには、「勘定科目残高」ファイルに含まれる各項目のＣＲＵＤが記載される。種別欄１８２ｄ、基準日付欄１８２ｅ、外国通貨欄１８２ｆ、および外国債券欄１８２ｇは当然、処理対象のファイルに含まれる項目名によって異なる名称となる。差分データ１８０の２行目は、図９の処理のフローを２００７年７月１日に処理した結果、記録された、データ１７２とデータ１７４との差分を表している。すなわち、「２００７／７／１」の「２２：１１：００」に「プログラムＡ」により、「外国通貨」の数値データが「Ｕ（更新）」されている。

同様に、３行目では「プログラムＢ］により、「外国債券」の数値データが「Ｕ（更新）」され、４行目では「プログラムＣ」により、「種別」、「基準日付」、「外国通貨」、「外国債券」の数値データが新たに「Ｃ（作成）」されていることが表されている。この差分データ１８０により、２００７年７月１日において、各プログラムがどのような処理を行ったかが取得できる。差分データ１８０は出力部４２から出力してユーザに開示するようにしてもよい。出力を表示装置に行い、差分データ１８０の特定の行をユーザが選択すると、元の「勘定科目残高」ファイルのサンプルデータが表示されるようにしてもよい。このようにすることで、ユーザは処理の内容をより具体的にイメージし易くなる。

このような差分データを例えば一ヶ月など所定の期間分、取得する。すると更新特性取得部５６は、前述のとおりデータキーの値を処理特性に応じて分類する。図９の例ではデータキーが種別欄１７２ａおよび基準日付欄１７２ｂに記載された値の２種類存在する。この場合は、分類する試行を繰り返すことにより、明確な分類が可能となる方を選択する。このようなルールはあらかじめ設定しておく。データキーが多数存在する場合でも、そのいくつかを無視して分類を行うことにより、一見、複雑な更新内容を系統立てて捉えることが可能となる。

上述の例では、例えば種別欄１７２ａの値に着目して分類するとする。種別欄１７２ａの値は、差分データ１８０における種別欄１８２ｄで「Ｃ」と記載されている際に新たに生成されているため、その処理に対応する「勘定科目残高」ファイルのデータ、すなわちデータ１７８などから特定することができる。図９に示した例では、種別欄１７２ａの値として「日別明細」と「月間累計」が存在する。

そして所定期間分の差分データ１８０と各「勘定科目残高」ファイルから、「日別明細」の処理特性、「月間累計」の処理特性を取得し、分類する。この例では分類対象が２つの値のみであるため、処理特性が異なるか否かで分類結果が決定されるが、３つ以上の値を有するデータキーの場合は、上述の従業員番号のように、どの処理特性に当てはまるかを順次シミュレーションしていくことにより分類する。図１１は、図９の例で更新特性取得部５６が行った分類結果例を示している。分類データ１９０は、分類欄１９０ａ、種別欄１９０ｂ、プログラム欄１９０ｃ、処理日欄１９０ｄ、対象欄１９０ｅ、処理内容欄１９０ｆを含む。

この例では、「日別明細」と「月間累計」の処理特性が分類できる場合を示している。そのため、分類欄１９０ａには、分類を識別する番号として「１」および「２」が記載され、種別欄１９０ｂにはそれぞれに対応して「日別明細」と「月間累計」が記載されている。なお種別欄１９０ｂは、分類対象となるデータキーによってその名称が異なる。続くプログラム欄１９０ｃ、処理日欄１９０ｄ、対象欄１９０ｅ、および処理内容欄１９０ｆは、分類の根拠となる処理特性を表す。この例では、分類が「１」である「日別明細」は、「プログラムＡ」および「プログラムＢ」によって対応する数値データ、すなわち「勘定科目残高」ファイルの外国通貨欄１７２ｃの「外国通貨」の値および外国債券欄１７２ｄの「外国債券」の値がそれぞれ、「毎日」「Ｕ（更新）」される、という処理特性を有する。

一方、分類が「２」である「月間累計」は、「プログラムＣ」によって、対応する「外国通貨」と「外国債券」の値が、「月初」に「Ｃ（作成）」され、さらに「毎日」「Ｕ（更新）」される、という処理特性を有する。なお上述の例は、「処理日」と「処理内容」によって処理特性を定義した場合を示しているが、処理内容や目的に応じて別の要素を処理特性として定義してもよい。

図１２は分類データ１９０等に基づきテストケース作成部５８が作成するテストケースの例を示している。図１１に示した分類データ１９０の場合、「プログラムＡ」による「日別明細」の「外国通貨」の数値データの更新、「プログラムＢ」による「日別明細」の「外国債券」の数値データの更新、「プログラムＣ」による「月間累計」の「外国通貨」と「外国債券」の作成および更新が全て正しく実行されていることが確認できれば、全ての状況を網羅したテストを行ったことになり、リリースを安全に行うことができる。ここで「プログラムＣ」による「外国通貨」と「外国債券」の作成は月初にのみ行われるため、「プログラムＣ」の当該動作を確認するテストは、月初に行う必要がある。

テストケース作成部５８はこのような観点からテストケースを作成する。図１２に示したテストケーステーブル１９２は、テストケース欄１９２ａ、プログラム欄１９２ｂ、テスト日欄１９２ｃ、確認項目欄１９２ｄ、および確認動作欄１９２ｅを含む。テストケース欄１９２ａに示されたテストケースの識別番号ごとに、テストを行うべきプログラムと日程、確認すべき項目と動作が、プログラム欄１９２ｂ、テスト日欄１９２ｃ、確認項目欄１９２ｄ、および確認動作欄１９２ｅに記載される。例えばテストケース「１」は、「月初」に「プログラムＣ」を仮想ジョブ７８として処理し、「外国通貨」と「外国債券」の「Ｃ（作成）」動作に異常がないかを確認するテストとなる。その他のテストケースも同様の情報を有する。この例では、「月初」および「月初翌営業日」の２回、仮想ジョブ７８を実行することにより、全テスト日程が終了することがわかる。

プログラム欄１９２ｂ、テスト日欄１９２ｃに記載された情報は、比較処理管理部６０を介してジョブ処理部２８の仮想ジョブ処理部３２に通知され、仮想ジョブ処理部３２は通知された日程で通知されたプログラムを含む仮想ジョブ７８を実行する。一方、テストケーステーブル１９２は出力部４２からユーザに開示され、ユーザはテストの内容を確認したり、比較用ジョブ８０が出力した比較結果のうち確認すべき内容を把握したりできる。

さらに比較処理管理部６０は、テストの進捗度合いを出力部４２から出力する。図１３はその際出力されるテストの進捗度合い情報の例を示している。進捗度合いテーブル１９４は、テストケース欄１９４ａ、確認予定日欄１９４ｂ、確認有無欄１９４ｃ、およびカバレッジ欄１９４ｄを含む。進捗度合いテーブル１９４は、例えばテストケーステーブル１９２と同一の画面内に表示することにより、テストケースごとに対応をとることができる。そのためテストケース欄１９４ａには、テストケーステーブル１９２のテストケース欄１９２ａに記載されたテストケースの識別番号が記載される。

そして確認予定日欄１９４ｂには、テストを実行する予定日が記載される。予定日は、テストケーステーブル１９２のテスト日欄１９２ｃに記載された情報と、予定を決定する日に基づき決定する。確認有無欄１９４ｃには、テストを実行した日付が記載される。図１３の例では、テストケース「２」、「３」、「４」はテストを実行済みであるため、確認予定日欄１９４ｂは空欄であり、実行した日が確認有無欄１９４ｃに記載されている。一方、テストケース「１」は未実行であるため、確認予定日欄１９４ｂに実行予定日が記載され、確認有無欄１９４ｃは空欄である。

またカバレッジ欄１９４ｄには、テストケースのうち実行済みのテストケースの割合がカバレッジとして記載される。図１３の例では、テストケース「１」のみ未実行で、テストケース「２」、「３」、「４」が実行済みであるため、カバレッジは「７５％」となる。カバレッジの定義はテストケースの割合以外に、日程の割合などでもよい。ユーザは進捗度合いテーブル１９４を確認することにより、リリースまでの見通しを確認できる。

比較処理管理部６０が本番出力ファイルと仮想出力ファイルとの比較結果からプログラムが正しく動作していることを自動で確認する場合は、上述の「実行済み」を「確認済み」と置き換えることができる。すなわち各テストを実行後、本番出力ファイルと仮想出力ファイルとで、テストケーステーブル１９２の確認項目欄１９２ｄに記載された項目に差がなかった場合に、テスト対象のプログラムに問題がなかったことを確認できたとして、確認有無欄１９４ｃに確認した日付を記載する。このような態様では、ユーザがテストを行いたいプログラムを登録するのみで、必要な日程でのテストの実行、結果の確認、リリース処理までを全て自動で行えるようになる。あるいは、ユーザが自ら確認を行った後、問題がなかった旨の入力をした際に、「確認済み」としてもよい。

図１４は、本番出力ファイルと仮想出力ファイルに差が生じていた場合に、比較処理管理部６０が原因を解析する際に生成する因果関係のリンク図を示している。リンク図１９６は「親ノード」と「子ノード」からなり、上述の例ではデータキーのうちデータの「種別」が分類されているため、「親ノード」は「種別」となる。そしてそれ以外の項目、すなわち「基準日付」と、「外国通貨」と、「外国債券」が「子ノード」となる。この例の場合、「子ノード」となる各項目には因果関係はないとし、「親ノード」と各「子ノード」にのみリンクが張られている。このような因果関係は、あらかじめユーザなどにより設定を行うか、データキーを元にして自動で作成してもよい。それを比較処理管理部６０リンク図１９６の形式とすることで、各種確率を算出する。

上述の例では、「種別」の値は「日別明細」と「月間累計」のみであるため、それ以外の値が発生していれば、「種別」もしくはその値を生成した処理が不一致の原因であると推測する。「種別」は一致しているが、「外国通貨」の値が不一致である場合は、まず、「外国通貨」単独での範囲別発生確率を参照して、不一致となった値の発生確率を求める。発生確率が所定のしきい値より低ければ、当該項目もしくはその操作が不一致の原因であると予測する。また、「外国通貨」単独での発生確率が所定のしきい値以上であったら、親ノードである「種別」の値との複合条件での範囲別発生確率を参照して、不一致となった値の発生確率を求める。発生確率が所定のしきい値より低ければ、当該項目もしくはその操作が不一致の原因であると予測する。ただしこの場合は、「外国通貨」単独条件での発生確率に対する判断より原因である確率は小さいと考えられるため、その差を認識できるようにユーザに通知する。例えば原因確率を数値で表すことにより、その差を反映させるようにしてもよい。

以上述べた本実施の形態によれば、新たなプログラムやジョブのテストを行いたい場合、本番機であるシステムに仮想ディレクトリを設けてプログラムなどを格納し、テスト対象のプログラムを本番処理と並行して実行するようにスケジューリングする。そして仮想ディレクトリ内のデータは、テスト終了後に削除する。これにより、本番機におけるテスト実行を安全に遂行することが可能になる。情報処理技術が発展しシステムの処理能力が増強するほど、本番機でテストを行う本実施の形態の効果が発揮される。

本番機でテストを行うことにより、開発機に入力データをコピーすることにより生じる、セキュリティ上の問題を回避できると同時に、コピーのための工数を削減できる。また、入力データをマスクする必要がなく、利用するリソースも本番処理と同様にできるため、実際のデータ、リソースを用いた正確なテストを行うことができる。さらに、一のシステム内で本番処理とテスト処理を実行するため、本番処理で得られる出力ファイルとテスト処理で得られる出力ファイルとを比較するジョブを生成でき、出力ファイルの比較を容易に行うことができる。また、テストを行いたいプログラムのみ仮想ジョブとして実行すれば、前後のジョブは本番処理と兼用できるため、テスト自体の工数も削減できる。

仮想ディレクトリにデータを格納する際は、仮想リリースログを記録しておく。仮想ディレクトリは、ユーザがテストを行う旨の登録を行う都度、個別に設けられるため、所望の単位でテストおよびリリースが可能である。ここで仮想リリースログを記録しておくことにより、リリース時の本番環境へのプログラムの移行や、テスト終了後のデータの削除を抜けなく行うことができる。

また、更新対象のプログラムと、その入出力ファイルを解析することにより、プログラムの処理内容と処理特性を特定する。具体的には、ファイルレイアウトとデータキーをプログラムから導出し、データキーごとに入出力ファイルの数値データをつきあわせることにより、プログラムの処理内容を特定する。これにより、処理内容が不確かなプログラムでも、出力ファイルにいかに作用しているかを把握することができる。

そしてデータキーの値ごとに処理特性を分類する。これにより、各プログラムの処理内容の特徴を系統立てて表現することができ、ユーザがプログラムの処理内容を把握し易くなる。さらにテストを実行すべき日程と、実行時に確認すべき項目を取得することができ、テストの実行と結果の確認を効率的かつ正確に行うことができる。また結果の確認を自動化することもできる。

プログラムを解析する既存の手法であるレーベルサーチでは、実際の出力ファイル上のデータとプログラムとを個々に結びつけることができないため、データキーの値ごとに影響を予測することが困難である。本実施の形態では、実際の出力結果からプログラムの処理内容を導出するため、プログラムの出力ファイルへの影響を詳細かつ正確に取得することができる。例えば作成されてから長時間経過したプログラムなどの場合、レーベルサーチでは検出されるが実際は動作していない機能が存在する場合がある。過去に扱っていた商品や過去に導入された雇用形態などが現在では存在しない場合がそれにあたる。

このような場合、当該機能に着目したテストを行うことは非効率的である。一方、本実施の形態では、実際の出力結果から処理内容を同定するため、必要な期間の出力結果を用いれば、現在動作している機能のみに着目したテストを行うことができ、効率的である。なお、レーベルサーチの上記性質を利用して、本実施の形態の処理内容解析結果と比較することにより、現在動作していない、あるいは希にしか動作しない機能を洗い出すことが可能である。このような機能が検出された場合、元のプログラムから該当する記述を削除するなどの修正案を導出することができる。

また、ユーザがプログラムの処理内容などを把握していなくてもテストを実行し、テスト後の処理を確実に行うことができるため、システムに関する知識の少ないオペレータなどでも安全にテストを遂行することが可能である。またプログラムの処理内容に関わらず同様にテストを実行できる。結果として、人件費やシステムごとの開発コストを抑制することができる。

さらに、テスト時の出力ファイルの比較を行った結果、不一致が発生していた場合に、その原因を統計的手法により導出する。これによりテストプログラムなどにおいて修正すべき箇所に関する情報をユーザに与えることができ、開発作業の効率性向上を支援することができる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば本実施の形態では、データベース１７は参照されるのみであり、出力はハードディスク１３への出力ファイルの格納のみであった。一方、テスト対象のプログラムの処理にデータベース１７への書き込み処理が含まれていてもよい。この場合、本番処理で書き込まれる本番データベースと同様の構造を有する仮想データベースを用意し、仮想ジョブによる書き込みは当該仮想データベースに対して行うようにする。まずテスト実行前に、本番データベースを停止させてスナップショットを取得し、仮想データベースに本番データベースの内容を反映させる。以前に同様のテストを行っている場合は、その時点からの更新分のみをコピーする。

そして仮想データベースのその時点でのチェックポイントを取得してから、本番ジョブと仮想ジョブを並列に処理し、それぞれのデータベースに書き込まれた内容を比較する。テスト終了後、取得しておいたチェックポイントまで仮想データベースをロールバックすることにより、仮想ジョブによって書き込まれたデータを削除した状態とする。これにより本実施の形態における仮想出力ファイルと同様、データベースへの書き込み結果を比較したうえ、仮想データベースをテスト前の状態へ戻すことができる。

また本実施の形態では、ファイル解析部３８におけるプログラムの処理内容や処理特性を特定する機能を、テストケースの作成やテスト結果の確認に用いた。一方、当該機能のみを有する解析装置を、プログラムの処理内容を取得する目的に用いてもよい。例えば刷新されずにファイルベースの処理のまま取り残されたレガシーシステムの中には、その処理仕様がブラックボックス化してしまったシステムも存在している。このような場合に同様の解析を行うことにより、処理内容や処理特性を特定でき、出力結果への影響や、新規プログラムとの比較などを行うことができる。

さらに、バッチ処理を行っている本番機に対する新規ジョブのテストでなく、単体のプログラムを実行する装置や開発機において修正プログラムをテストする際にファイル解析の機能を用いることもできる。このときも、本実施の形態と同様に、更新特性から想定すべき状況や確認すべき結果などを取得することにより、テストを効率的かつ正確に行うことができる。そして、テストの結果が問題ないことを自動で判定することができる。さらに、様々なシチュエーションを考慮した最適な入力データをテストケースとして作成することもできる。

本実施の形態を適用できるシステムの構成例を示す図である。 本実施の形態のジョブ処理システムでバッチ処理されるジョブの例を模式的に示す図である。 本実施の形態における第１サーバの構成をより詳細に示す図である。 本実施の形態において第１サーバが行う新規ジョブのテストの処理手順を示すフローチャートである。 本実施の形態においてジョブ登録部が本番ジョブおよび仮想ジョブから抽出して作成する、ファイル情報のテーブルの例を示す図である。 本実施の形態においてジョブ登録部が作成する仮想リリースログの、各処理段階における変化例を示す図である。 本実施の形態におけるファイル解析部の詳細な構成を示す図である。 本実施の形態においてファイル解析部が行うファイル解析およびテスト実行管理の処理手順を示すフローチャートである。 本実施の形態におけるファイル解析部の処理内容を説明するために想定する処理のフロー例と入出力ファイルの内容例を示す図である。 本実施の形態における処理内容特定部が取得するファイルの差分の取得結果例を示す図である。 本実施の形態における更新特性取得部が行う処理特性の分類結果例を示す図である。 本実施の形態におけるテストケース作成部が作成するテストケースの例を示す図である。 本実施の形態における比較処理管理部が出力部から出力するテストの進捗度合い情報の例を示す図である。 本実施の形態において比較処理管理部が本番出力ファイルと仮想出力ファイルの不一致の原因を解析する際に生成する項目の因果関係のリンク図を示している。

符号の説明

１０ ジョブ処理システム、１２ 第１サーバ、 １３ ハードディスク、 １４ 第２サーバ、 １７ データベース、 ２２ ジョブ登録部、 ２６ 比較用ジョブ生成部、 ２８ ジョブ処理部、 ３０ 本番ジョブ処理部、 ３２ 仮想ジョブ処理部、 ３４ 本番ディレクトリ、 ３６ 仮想ディレクトリ、 ３８ ファイル解析部、 ４０ リリース処理部、 ４２ 出力部、 ５２ データ形式解析部、 ５４ 処理内容特定部、 ５６ 更新特性取得部、 ５８ テストケース作成部、 ６０ 比較処理管理部、 １００ ファイル情報のテーブル。

Claims (11)

1. 入力ファイルに記録された複数の項目についてデータを生成するプログラムの出力ファイルにおける、前記項目およびデータの記載位置を表すレイアウト情報を取得するとともに、他の項目のデータを特定するデータキーの項目を特定するデータ形式取得部と、
   前記データキーの値ごとに、当該データキーに対応づけられた他の項目のデータの、入力ファイルと出力ファイル間の差分を取得することにより、前記プログラムの処理内容を特定する処理内容特定部と、
   を備えたことを特徴とする情報処理装置。
2. 前記データ形式取得部は、プログラムのソースコードのうち、項目およびデータの並び順を定義した箇所、およびマッチング・ブレーク処理を記述した箇所をパターン解析により抽出することにより、前記レイアウト情報を取得するとともに前記データキーの項目を特定することを特徴とする請求項１に記載の情報処理装置。
3. 前記データ形式取得部は、入力ファイルと出力ファイルにおける同じ値のデータ数が、ｎを自然数として、１対１、ｎ対１、１対ｎのいずれかの対応を有する項目を前記データキーの項目として特定することを特徴とする請求項１に記載の情報処理装置。
4. プログラムが実行される都度、その入力ファイルおよび出力ファイルを格納する記憶部をさらに備え、
   前記処理内容特定部は、所定期間に前記記憶部に格納された複数組の入力ファイルおよび出力ファイルの差分をそれぞれ取得することにより、前記所定期間におけるプログラムの処理内容を特定し、
   前記処理内容特定部が特定した所定期間におけるプログラムの処理内容から、各項目の時間的な更新特性を取得する更新特性取得部をさらに備えたことを特徴とする請求項１または２に記載の情報処理装置。
5. 前記更新特性取得部は、前記更新特性の特徴に基づき前記データキーの値を分類し、その結果を出力することにより、前記更新特性の特徴と前記データキーの値の対応をユーザに通知することを特徴とする請求項４に記載の情報処理装置。
6. プログラムのテストを行う状況において、前記更新特性取得部が特定した、各項目の時間的な更新特性に基づき、テストを行うタイミングとテスト結果において確認すべき項目の対応関係を導出するテストケース作成部をさらに備えたことを特徴とする請求項４に記載の情報処理装置。
7. 前記テストケース作成部が導出したテストを行うタイミングのうちテストが実行された割合を、テストの進捗度合いとして出力するテスト管理部をさらに備えたことを特徴とする請求項６に記載の情報処理装置。
8. 通常運用において実行されている運用プログラムの代替プログラムのテストを行った際、
   前記テスト管理部は、前記運用プログラムと前記代替プログラムの出力ファイルを比較した結果、いずれかの項目のデータが不一致であった場合、所定期間に前記記憶部に格納された前記運用プログラムの出力ファイルを統計分析することにより不一致となった値が発生する確率を算出し、当該確率に基づき、不一致の原因となっている項目を予測することを特徴とする請求項５に記載の情報処理装置。
9. 前記テスト管理部は、不一致となった値を含む項目と因果関係のある項目との複合条件により、不一致となった値が発生する確率を算出することを特徴とする請求項８に記載の情報処理装置。
10. 入力ファイルに記録された複数の項目についてデータを生成するプログラムの出力ファイルにおける、前記項目およびデータの記載位置を表すレイアウト情報を取得するとともに、他の項目のデータを特定するデータキーの項目を特定するステップと、
    実際のプログラム実行により記憶された入力ファイルおよび出力ファイルの組をメモリより読み出し、前記データキーの値ごとに、当該データキーに対応づけられた他の項目のデータの、入力ファイルと出力ファイル間の差分を取得することにより、前記プログラムの処理内容を特定するステップと、
    を含むことを特徴とするプログラム解析方法。
11. 前記処理内容を特定するステップは、所定期間に記録された複数組の入力ファイルおよび出力ファイルの差分をそれぞれ取得することにより、前記所定期間におけるプログラムの処理内容を特定し、
    前記所定期間におけるプログラムの処理内容から、各項目の時間的な更新特性を取得するステップをさらに含むことを特徴とする請求項１０に記載のプログラム解析方法。

Images