特許 5703195 プログラムの新旧バージョンに対する差分比較テストシステム及びテスト方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5703195

(24)【登録日】2015年2月27日

(45)【発行日】2015年4月15日

(54)【発明の名称】プログラムの新旧バージョンに対する差分比較テストシステム及びテスト方法

(51)【国際特許分類】

   G06F 11/28 20060101AFI20150326BHJP

   G06F 11/34 20060101ALI20150326BHJP

【ＦＩ】

   G06F11/28 340A

   G06F11/34 A

【請求項の数】8

【全頁数】16

(21)【出願番号】特願2011-249358(P2011-249358)

(22)【出願日】2011年11月15日

(65)【公開番号】特開2013-105358(P2013-105358A)

(43)【公開日】2013年5月30日

【審査請求日】2014年6月18日

(73)【特許権者】

【識別番号】302064762

【氏名又は名称】株式会社日本総合研究所

(74)【代理人】

【識別番号】100144048

【弁理士】

【氏名又は名称】坂本 智弘

(72)【発明者】

【氏名】織田 哲典

(72)【発明者】

【氏名】平松 久

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２０１１−１４１６３１（ＪＰ，Ａ）

【文献】 特開２００５−２７６０４０（ＪＰ，Ａ）

【文献】 特開２００３−０９９２８４（ＪＰ，Ａ）

【文献】 特開平５−１３４８９６（ＪＰ，Ａ）

【文献】 特開平５−１２００６９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ１１／２８−１１／３６

(57)【特許請求の範囲】

【請求項1】

プログラムの改定バージョンに対するテストを支援するテストシステムであって、
前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログを集積したオペレーションログ集積ＤＢと、
前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積ＤＢから、テストデータを生成するテストデータ生成部と、
前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータ生成部が生成したテストデータを投入しテストを自動実行させ、前記テスト環境それぞれからテスト結果を取得するテスト実行部と、
前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに出力する差分比較部と、
を備えることを特徴とするテストシステム。

【請求項2】

前記実環境でのオペレータによるオペレーションログとは別に、テスト環境でのテストオペレータによる新機能のオペレーションログを記録する新機能オペレーションログＤＢをさらに備え、
前記テストデータ生成部は、前記新機能オペレーションログＤＢから、前記プログラムの新バージョンでのみサポートされている機能のテストデータを生成することを特徴とする請求項１に記載のテストシステム。

【請求項3】

前記差分比較部は、前記プログラムの新バージョンでのみ実行可能なテストデータを実行した際に、前記新バージョンでのテスト結果と、予め作成した新機能比較マスタＤＢを検索して得られた対応データとを比較し、前記差分比較結果テーブルに出力することを特徴とする。請求項２に記載のテストシステム。

【請求項4】

前記新バージョン入出力項目テーブルは、前記プログラムの旧バージョンから入出力項目に変更がない前記操作画面に対しては、前記旧バージョン入出力項目テーブルで代用することを特徴とする請求項１に記載のテストシステム。

【請求項5】

前記テスト実行部は、テスト環境でのプログラム実行日時を、前記オペレーションログに記録されたプログラムの実行日時に調整することを特徴とする請求項１に記載のテストシステム。

【請求項6】

前記差分比較部は、前記プログラムが前記操作画面を介して実行するトランザクション単位に１つのレコードが形成し、新バージョンのテスト結果と旧バージョンのテスト結果をレコード単位で比較し、差分があるレコードペアのみを差分比較結果テーブルに出力する請求項１に記載のテストシステム。

【請求項7】

前記差分比較部は、前記プログラムの新バージョンのテスト結果と旧バージョンのテスト結果を前記レコード単位で比較し、新旧バージョンで対応するレコードに対して差分がある出力項目の識別表示手段を前記差分比較結果テーブルに出力することを特徴とする請求項６に記載のテストシステム。

【請求項8】

プログラムの改定バージョンに対するテスト方法であって、
前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログをオペレーションログ集積ＤＢに集積するステップと、
前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積ＤＢから、テストデータを生成するステップと、
前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータを生成するステップで生成したテストデータを投入しテストを自動実行させるステップと、
前記テスト環境それぞれからテスト結果を取得するステップと、
前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに保存するステップと、
を有することを特徴とするテスト方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、プログラムのテスト方法に関し、特にプログラムの新旧バージョンに対する出力結果の差分を比較することによる差分比較テストシステム及びテスト方法に関する。

【背景技術】

【0002】

従来、プログラムテストにおいては、被テストプログラムの出力結果と正しい出力結果と比較して不具合を発見するテスト手法が広く行われている。しかし、プログラムの改定時や不具合修正時には、修正した箇所とは別の箇所におもわぬ不具合が発生することが多々あり、新機能や修正箇所のテストだけでなく、既存機能に悪影響を及ぼしていないかどうかを確認するための、いわゆるデグレードテストやリグレッションテストと呼ばれるテストを行うことが欠かせない。

【0003】

このためプログラム改定時のテストを効率的に行うためのテスト手法が多数考案されている。例えば、特許文献１に記載のテスト方法においては、被テストプログラムに対するテスト操作手順とその操作手順に対する被テストプログラムの出力結果を記録し、同じ被テストプログラムに対して、記録したテスト操作手順を再生し、その出力結果と記録した出力結果との差分を取り、これを比較除外データとして設定する。そして被テストプログラムを改正した後、その改正後被テストプログラムに対して、前に記録したテスト操作手順を再生し、その出力結果と記録した出力結果との差分を取り、さらに前記比較除外データに存在しない差分を真の差分として出力することを特徴としている。

【0004】

また、特許文献２に記載のテスト方法においては、ウェブページに対するデータ入力操作を検出して操作内容ファイルに記録し、操作内容ファイルに応じてプログラムコードを設定することにより、ウェブページに対して実行された一連の操作を再現するためのテスト・プログラムを生成し、テスト・プログラム実行後のウェブページをテスト結果データとして記録する。そして、前回のテスト・プログラム実行後の前回テスト結果データと、今回のテスト・プログラム実行後の今回テスト結果データとを比較し、比較の結果、不一致部分を識別表示した比較結果画像を出力することを特徴としている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００１−２８２５７８号公報

【特許文献2】特開２０１１−１６４７８３号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

特許文献１に記載のテスト方法は、プログラムの改正前後でプログラム実行結果を比較し差分をとる差分比較のテスト手法であり、あらかじめ改正前の被テストプログラムに対して、操作記録時に作成した比較元マスタとテスト実行時の出力結果を比較し、両者の差があればそれを仕様上の差分として比較除外としておき、その後、改正後のプログラムに対して改正前の出力結果との比較テストを行い、この比較除外を除いた真の差分のみを出力する。しかし、テストデータはテスト実施者等が入力することを前提としており、様々なバリエーションに対応するようなテストデータの作成には多くの時間を要するという課題がある。また、同じ改正前のプログラムに対しテストを２回行い、実行日時の違いにより生じた差分を比較除外としてしまうため、日付や時刻に依存するアプリケーション・プログラム（例えば、満期日や利子の計算などを扱うプログラム）では、必要な入出力項目が比較除外に含まれてしまいかねないといった課題もある。

【0007】

また、特許文献２に記載のテスト方法は、同じく差分比較のテスト手法であり、プログラムの出力結果を画面上の出力結果で比較し、不一致部分の画像を出力するものであるが、比較のための多くの画面画像を保存して比較する必要があり、テストシステムに負荷がかかるといった課題がある。また、プログラムの出力結果を画面上でなくデータベース上のデータとして他のシステムへのインプットとして渡すようなプログラムには適用できないという課題もある。

【0008】

プログラムのテストにおいて、様々な入力パラメータのバリエーションをすべてチェックすることは膨大な作業であり、特に既存機能を確認するためのリグレッションテストやデグレードテストは大変なわりに退屈な作業でもあるので、小規模なバージョンアップの際に毎回行うのは時間との兼ね合いで困難となる場合が多い。またパッケージソフトを購入して、システムに組み入れている場合には、入力と出力以外はブラックボックスであり、機能とプログラムモジュールの関係も不明なので、プログラムの一部の修正が、他の関係ない部分に影響し予想外の不具合が発生してないか確認する必要もある。

【0009】

したがって、本発明では、上記のような課題に鑑み、テストデータの作成の手間を大幅に軽減するため、様々なバリエーションのテストデータをプログラムが稼動実績のある多数の実環境から自動的に作成し、かつプログラムの出力結果を画面画像として保存する必要がなく、新旧バージョン（改定後と改定前）のプログラムの出力結果の差分を容易に比較することのできる差分比較テストシステム及びテスト方法を提供することを目的とする。

【課題を解決するための手段】

【0010】

上記課題を解決するため、本発明のテストシステムは、以下のような解決手段を提供する。

【0011】

プログラムの改定バージョンに対するテストを支援するテストシステムであって、前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログを集積したオペレーションログ集積ＤＢと、前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積ＤＢから、テストデータを生成するテストデータ生成部と、前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータ生成部が生成したテストデータを投入しテストを自動実行させ、前記テスト環境それぞれからテスト結果を取得するテスト実行部と、前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに出力する差分比較部と、を備えることを特徴とする。

【0012】

このような構成にすることで、プログラムの改定時（バージョンアップやリリースアップ時）におけるテストデータの作成を、プログラムの旧バージョン（改定前バージョン）が稼働している実績ある多数の実環境からのオペレーションログを集積したＤＢから自動的に作成することができる。このとき、操作画面を介しての新バージョン（改定後バージョン）及び旧バージョンのプログラムの入出力項目を定義した入出力項目テーブルが用いてテストのための入力データが作成される。また、生成した同じテストデータを、新旧バージョンプログラムを適用したテスト環境それぞれに投入してそのテスト結果を取得し、新バージョンのテスト結果が旧バージョンのテスト結果と比較される。テストの比較結果は、新旧バージョン入出力項目テーブルを再び用いて比較すべき項目を抽出した差分比較結果テーブル上に出力され、テスト結果の解析に用いられる。

【0013】

このようにすることで、設計時には想定しづらかった実環境での多くのバリエーションを含んだテストデータが豊富になり、テストカバレッジを広げることができる。かつ、新旧バージョンのテスト結果の差分比較を容易にすることでリグレッションテストやデグレードテストの作業が大幅に緩和することができる。

【0014】

また、上記のテストシステムは、下記のような特徴を更に備えるように構成してもよい。すなわち、前記実環境でのオペレータによるオペレーションログとは別に、テスト環境でのテストオペレータによる新機能のオペレーションログを記録する新機能オペレーションログＤＢをさらに備え、前記テストデータ生成部は、前記新機能オペレーションログＤＢから、前記プログラムの新バージョンでのみサポートされている機能のテストデータを生成することを特徴とする。

【0015】

すなわち、実環境でのオペレータによるオペレーションログとは別に、テスト環境でのテストオペレータ（テスター）による新機能を含んだオペレーションログを記録する新機能オペレーションログＤＢを備えることで、新機能のテストデータを、実環境のオペレーションログからの場合と同様の手順で生成することができる。

【0016】

また、上記のテストシステムの差分比較部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記差分比較部は、前記プログラムの新バージョンでのみ実行可能なテストデータを実行した際に、前記新バージョンでのテスト結果と、予め作成した新機能比較マスタＤＢを検索して得られた対応データとを比較し、前記差分比較結果テーブルに出力することを特徴とする。

【0017】

このように構成することで、新バージョンでのみサポートされる新機能のテストデータであって、旧バージョンのテスト結果が存在しない場合、予め作成した新機能比較マスタＤＢを検索し、そこから対応する正しい出力結果のデータが得られればそのデータと新バージョンテスト結果とを比較するので、従来機能のテストの場合と同じ形式で差分比較結果テーブルに出力することができる。実環境でのオペレーションログに基づいて生成したテストデータでは、新旧で同じ機能の部分については実績のある旧バージョンと新バージョンのテスト結果を比較すれば、新バージョンでの不具合（デグレード）を発見することができるが、新バージョンでのみサポートされている機能は、旧バージョンのテスト結果と比較することはできない。したがって、通常は新機能のテストは、人間が仕様から想定される正しいテスト結果（比較マスタと呼ぶことにする）と実際のテスト結果とを見比べて比較することになるが、本テストシステムでは、比較マスタを本テストシステムが対象とするプログラムが出力する形式で予め作成しておくことで、比較マスタと新バージョンでのテスト結果との比較が、同じ差分比較結果テーブルを用いた形で実現できる。

【0018】

また、上記のテストシステムは、下記のような特徴を更に備えるように構成してもよい。すなわち、前記新バージョン入出力項目テーブルは、前記プログラムの旧バージョンから入出力項目に変更がない前記操作画面に対しては、前記旧バージョン入出力項目テーブルで代用することを特徴とする。

【0019】

このように構成することで、操作画面によって新旧のバージョンで入出力項目に変更のないものについては、新バージョン入手出力項目テーブルの作成はせず、旧バージョン入出力項目で代用することで、項目の変更のあるなしに係らず、同じテスト操作を実行することができる。

【0020】

また、上記のテストシステムのテスト実行部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記テスト実行部は、テスト環境でのプログラム実行日時を、前記オペレーションログに記録されたプログラムの実行日時に調整することを特徴とする。

【0021】

このように構成することで、オペレーションログに記録されたプログラムの実行日時に合わせて、テスト環境の内部時計を一時的に調整し、テスト時のプログラム実行日時を一致させることで、実行日時によって出力結果が変動するプログラムに対しても、比較除外の手段などを用いなくとも、同じ差分比較の手法を適用することができる。

【0022】

また、上記のテストシステムの差分比較部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記差分比較部は、前記プログラムが前記操作画面を介して実行するトランザクション単位に１つのレコードを形成し、新バージョンのテスト結果と旧バージョンのテスト結果をレコード単位で比較し、差分があるレコードペアのみを差分比較結果テーブルに出力することを特徴とする。

【0023】

このように構成することで、操作画面を介して実行されるプログラムの処理単位であるトランザクション単位で新旧バージョンの入出力結果において差分のあるもののみが差分比較結果テーブルに出力され、比較し、解析を容易することができる。

【0024】

また、上記のテストシステムの差分比較部は、下記のような特徴を更に備えるように構成してもよい。すなわち、前記差分比較部は、前記プログラムの新バージョンのテスト結果と旧バージョンのテスト結果を前記レコード単位で比較し、新旧バージョンで対応するレコードに対して差分がある出力項目の識別表示手段を前記差分比較結果テーブルに出力することを特徴とする。

【0025】

このように構成することで、新旧で差分がある出力項目ごとにその差分を目立たせる識別表示手段（フラグ、色、図形など）を差分比較結果テーブルに出力するので、項目単位の差分の発見をさらに容易にすることができる。

【0026】

なお、本発明のテストシステムは、下記のようなテスト方法の発明と捉えることもでき、本発明のテストシステムと同様な作用効果を奏する。

【0027】

プログラムの改定バージョンに対するテスト方法であって、前記プログラムの改定前バージョンが稼動する実環境において、操作画面を介しての入出力を記録したオペレーションログをオペレーションログ集積ＤＢに集積するステップと、前記プログラムの改定前及び改定後バージョンにおける入出力項目をそれぞれ定義した旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて、前記オペレーションログ集積ＤＢから、テストデータを生成するステップと、前記プログラムの改定後のバージョンと改定前のバージョンを適用したテスト環境それぞれに対して、前記テストデータを生成するステップで生成したテストデータを投入しテストを自動実行させるステップと、前記テスト環境それぞれからテスト結果を取得するステップと、前記テスト結果から、前記旧バージョン入出力項目テーブル及び新バージョン入出力項目テーブルを用いて比較項目を取り出し、旧バージョンテスト結果と新バージョンテスト結果の差分を抽出して差分比較結果テーブルに保存するステップと、を有することを特徴とするテスト方法。

【発明の効果】

【0028】

本発明によれば、テストデータの作成の手間を大幅に軽減するため、様々なバリエーションのテストデータをプログラムが稼動実績のある多数の実環境から自動的に作成し、かつプログラムの出力結果を画面画像として保存する必要がなく新旧バージョンのプログラムの出力結果の差分を容易に比較する差分比較テストシステム及びテスト方法を提供することができる。

【図面の簡単な説明】

【0029】

【図1】本発明の実施形態に係るテストシステム１００の機能ブロックを示す図である。

【図2】本発明の実施形態に係るオペレータ操作画面、入出力項目テーブル、オペレーションログの概略を示す図である。

【図3】本発明の実施形態に係るオペレーションログの具体例を示す図である。

【図4】本発明の実施形態に係る入出力項目テーブルの具体例を示す図である。

【図5】本発明の実施形態に係るテスト実行手順を示す図である。

【図6】本発明の実施形態に係る新機能テスト実行手順を示す図である。

【図7】本発明の実施形態に係る差分比較結果テーブルの概略を示す図である。

【図8】本発明の実施形態に係る差分比較結果テーブルの具体例を示す図である。

【発明を実施するための形態】

【0030】

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。なお、実施形態の説明の全体を通して同じ要素には同じ番号を付している。

【0031】

図１は、本発明の実施形態に係るテストシステム１００の機能ブロックを示す図である。図示するように、本実施形態のテストシステム１００は、プログラムテストを自動または半自動で行うことを支援するシステムであり、機能実行部として、オペレーションログからテストデータを生成するテストデータ生成部２０，テストデータを被テストプログラムに投入するテスト実行部５０，新旧バージョンプログラム出力結果を比較し、その差分を抽出する差分比較部７０を含んでいる。

【0032】

また、テストシステム１００は、データ格納部として、被テストプログラムの実環境２００から得られるオペレーションログ２２０を集積したオペレーションログ集積ＤＢ１０（グローバルログ），新バージョンでのみサポートされる新機能をテストオペレータ（テスター）が操作したログを記録する新機能オペレーションログＤＢ１１，オペレーションログから生成したテストデータを格納するテストデータＤＢ４０，新旧バージョンの被テストプログラムのテスト結果をそれぞれ格納する新旧バージョンテスト結果データＤＢ９０、９１，及び新機能比較マスタＤＢ９２を含んで構成される。また、テストシステム１００は、その他入力データとして、新旧バージョン入出力項目テーブル３０、３１を含み、また、差分比較部７０の出力データとして、差分比較結果テーブル８０を含んで構成されている。以下、各機能ブロックの働きについて順に説明する。

【0033】

実環境２００は、既にリリースされた被テストプログラムの旧バージョンが実際に稼動しているシステム環境を示す。ここで扱う被テストプログラムは、実環境におけるオペレータが操作画面２１０から入力データをインプットし、出力結果を画面に表示させたり、ＤＢに出力するようなアプリケーション・プログラムを想定している。ただし、ここでオペレータとは専門の端末操作員だけでなく、無人店舗等で端末を操作する個人顧客等を含むものとする。実環境２００は、具体的には被テストプログラムを操作可能な店舗や支店（以下両者を合わせて拠点と呼ぶ）など複数の場所に存在する。各拠点では、オペレータの操作手順、入力データ及び出力データが逐次記録されるオペレーションログ２２０を有している。各オペレーションログ２２０の内容は、テストシステム１００のオペレーションログ集積ＤＢ１０に所定のタイミングで集積される。

【0034】

テストデータ生成部２０は、オペレーションログ集積ＤＢ１０からオペレーションログの内容を解析し、被テストプログムが実行可能なテストデータ（テストファイル）に加工し、テストデータＤＢ４０に格納する。この加工の際には、予め用意された旧バージョン入出力項目テーブル３０が参照される。オペレーションログには、入力項目と出力項目が含まれるが、テストデータとして必要なのは入力項目のみである。入出力項目テーブルとは、被テストプログラムの操作画面ごとに入力項目（入力フィールド）と出力項目（出力フィールド）を定義したテーブルであり、通常は画面設計の際に作成される。

【0035】

また、テストデータ生成部２０は、新バージョンでのみサポートされている機能の画面操作を記録した新機能オペレーションログＤＢ１１から、新バージョンでのみ実行可能可能なテストデータを生成することができる。この場合も生成されるテストデータの形式（フォーマット）は、同じである。テストデータの具体例については後述する。

【0036】

被テストプログラムのバージョンアップの際に入出力項目が変更になった場合には、新バージョン入出力項目テーブル３１が用意される。新バージョン入出力項目テーブル３１は、今回のバージョンアップで新たにサポートされた機能(New Function)に対応する入出力項目や拡張されたパラメータ等を追加し、また、新バージョンではもはやサポートされない機能（Discontinue Function）に対応する入出力項目を削除するなどして旧バージョン入出力項目テーブル３０から作成される。入出力項目テーブルについて詳しくは後述する。

【0037】

テスト実行部５０は、テストデータＤＢ４０に格納されたテストデータを読み出し、新旧の被テストプログラムの実行環境６０，６１にそれぞれ入力して被テストプログラムを実行させる機能を果す。また、テスト実行部５０は、新旧バージョン適用被テストプログラム実行環境６０，６１からテストデータを投入して得られたテスト結果をそれぞれ新旧バージョンテスト結果データＤＢ９０，９１に格納する機能も果す。すなわち、テスト実行部４０はテストを自動実行する機能を果す。このようなテストの実行手段は市販のツールなどで実現される（例えば、ＨＰ社のＱＴＰなど）。もちろん、テストデータの形式は、市販ツールでサポートされているものであれば任意のものであってよいが、本発明の実施における被テストプログラムは金融関係のプログラムであることから、後述するＯＦＳ（Open Financial Service）ファイルと呼ばれるテストデータ形式を利用している。

【0038】

差分比較部７０は、新旧のバージョンのテスト結果をそれぞれ集積した新旧バージョンテスト結果データＤＢ９０，９１からテスト結果データを読みだし、新旧バージョンのテスト結果データを、プログラムの処理の単位であるトランザクションレコード単位で比較し、新旧バージョンのテスト結果で異なっているレコードのみを入出力データと共に、差分比較結果テーブル８０に出力する。ここで、差分比較結果テーブルの作成には、新旧バージョンの入出力項目テーブルが参照される。この場合には、入力項目だけでなく出力項目の欄も参照されるのはもちろんである。差分比較結果テーブル８０は、詳しくは後述するが、テスト管理者やデバッグ担当者が解析しやすいように一般的な表形式で出力される。新バージョンでのみサポートされる新機能は、旧バージョンでは動作しないので、新バージョンテスト結果データＤＢ９１と予めテスト管理者等が仕様に基づき作成した新機能比較マスタＤＢ９２とが比較され、同様に差分比較結果テーブル８０が出力される。

【0039】

上記の機能ブロックの構成は、あくまで一例であり、一つの機能部を更に分割したり、複数の機能部をまとめて一つの機能部として構成してもよい。各機能部は、装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only
Memory）またはハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わない。

【0040】

図２は、本発明の実施形態に係るオペレータ操作画面、入出力項目テーブル、オペレーションログを示す図である。オペレータ操作画面２１０は、被テストプラグラムに対するユーザインターフェースのひとつであり、案件毎にユーザ入力及びプログラムからの出力結果を表示する一または複数の画面である。図示するように、オペレータ操作画面２１０には、オペレータが入力する複数の入力項目、プログラムの実行結果である１または複数の出力項目、及びオペレータが操作する１または複数の操作ボタンを表示する。また、オペレータが入力せずとも自動的に表示される入力項目（入力不可項目）も表示される。例えば、現在日時，画面ＩＤ，顧客番号を入力した際に表示される顧客氏名なども入力不可項目となる。

【0041】

新旧バージョン入出力項目テーブル３０、３１は、画面ごとに含まれる各入出力項目に対して、項目ＩＤ，値範囲（とりうる値が限定されている場合），備考（入出力項目の説明テキスト），入力／出力（入力か出力かの区別），表示／非表示（画面上に表示されるか否かの区別）をテーブル形式にまとめたものである。表示／非表示の区別を設けるのは、入出力の項目には必ずしも操作画面に表示する必要はないが被テストプログラムの入力／出力データとしては必要なものがあるからである。もっとも画面上には表示されるが、被テストプログラムの入力／出力データとして関係ない項目は入出力項目テーブルからは省略してもよい。例えば、ヘルプに対する表示や現在時刻の表示、またはログイン認証を被テストプログラムとは別のプログラムを、同じ操作画面から呼び出して行っている場合、そのパスワードや認証に必要なデータ等である。既に述べたように、被テストプログラムの新バージョンにおいて追加・変更された入出力項目がある場合には、新バージョン入出力項目テーブル３１を旧バージョン入出力項目テーブル３０から予め変換して作成しておく。入出力項目に追加・変更がなくとも値範囲（パラメータ範囲）に変更がある場合には新バージョン入出力項目テーブル３１は作成される。新旧バージョンで追加・変更がない場合には、その画面ＩＤに対しては同じ旧バージョン入出力項目テーブル３０が代用して使用される。

【0042】

オペレーションログ集積ＤＢ１０に格納されたオペレーションログには、トランザクション毎に、使用した被テストプログラムのプログラム名，バージョン情報，プログラム実行日時，拠点ＩＤ（操作画面入力箇所のＩＤ），画面ＩＤが制御部１１（ヘッダ部）に含まれ、データ部１２には、各入出力項目ごとに入出力項目ＩＤ（フィールドＩＤ）と、入力または出力項目に対する値が記録されている。その他、操作開始時刻、操作終了時刻、操作員のＩＤや承認者のＩＤ等の操作状況に関する付随情報が含まれていてもよい。

【0043】

図３は、本発明の実施形態に係るオペレーションログの具体例を示す図である。この具体例では、図示するようにオペレーションログは、タグ形式のテキストファイルであり、トランザクション毎に、プログラム実行日時を先頭にして制御部１１のデータとして、プログラム名，バージョン名，トランザクションＩＤ，画面ＩＤがそれぞれ、<application>，<version>，<transactionID>，<windowName>のタグで前後を指定された形で記録される。またデータ部１２の各入出力項目は、項目名が<fieldName>タグで前後を指定され、その項目に対して入力または出力された値が<value>タグで前後を指定された形で記録される。各項目が記録される順序は、通常はオペレータが入力した順序であるが必ずしもそうでなくともよい。なお、ここでは図示していないが、入出力項目によっては、値(Value)が複数存在する場合に備えて<fieldName>の後ろに、<mutiValueNumer>，<subValueNumber>をタグを定義し、１つの入出力項目に対するValueやさらにそのSubvalueの数を指定することもできる。単一のValueの場合、<mutiValueNumer>は１であり、このときは<subValueNumber>タグは存在しない。

【0044】

以降は、テスト対象のアプリケーション・プログラムとして、金融機関の対顧客窓口サービスにおけるローン貸付業務を扱うプログラムを具体例にして説明する。このプログラムを操作した際のオペレーションログのデータ部１２には、融資額，科目コード，通貨，顧客番号，満期日，適用金利，利息計算方法等、このプログラムが処理する具体的な入出力データが記録されている。これらの入出力データは必ずしも操作画面上に表示されるものだけでなく、内部処理で使用されるものも含んでいる。

【0045】

オペレーションログ集積ＤＢ１０に集積されたオペレーションログ、または新機能オペレーションログＤＢ１１から、テストシステム１００のテストデータ生成部２０によって、テストデータが生成される。このとき、旧バージョン入出力項目テーブル３０が参照されテストにとって必要なデータだけが抽出される。すなわち、この入出力項目テーブル中で画面上で「入力」と指定された項目（フィールド名とその値）だけが被テストプログラムに対してインプットされるべきテストデータとして使用される。オペレーションログ中の入力とテストデータのフォーマットとしては、具体的にはＯＦＳ(Open Financial Service)ファイルを用いている。ＯＦＳファイルは、各入出力項目とその値を、「フィールド名」：ｍ:ｓ=「値」の形式で表したテキストファイルである。ここで「ｍ」、「ｓ」は先に説明した「multiValueNumber」と「subValueNumber」の値であり、単一Valueの場合は、「ｍ」、「ｓ」とも１である。例えば、「融資額」フィールドにインプットされた値が1000,000であれば、AMOUNT:1:1=1000,000のようにＯＦＳファイル上は記載される。もちろん、テストデータに他のファイル形式を用いてもなんら支障はない。なお、新機能オペレーションログＤＢ１１についても同様の形式で作成される。

【0046】

このようにして生成された同じテストデータが新旧バージョン適用被テストプログラム実行環境６０，６１に投入される。ただし、旧バージョンのテストデータをそのまま新バージョンに投入する際には、新バージョンの画面のデザイン等により形式的な変換をする必要がある場合があるが、その場合には変換規則を記述した変換テーブルなどを別途用意する。

【0047】

図４は、本発明の実施形態に係る入出力項目テーブルの具体例を示す図である。入出力項目テーブルは、操作画面で処理されるすべての入力項目および出力項目をまとめたテーブルである。既に述べたように、プログラムの改定によって入力項目／出力項目が変更される場合があるので、改定前後のプログラムのバージョンに対応して、旧バージョン入出力項目テーブル３０と新バージョン入出力項目テーブル３１が存在する。

【0048】

先に挙げたローン貸付業務プログラムの一つの操作画面として、新規ローン受付画面を具体例に取り上げると、旧バージョン入出力項目テーブル３０は具体的には図４上段のようになる。プログラムの改定によって入出力項目に変更があった場合には、新バージョン入出力項目テーブル３１が作成され、例えば、図４下段のようになる。この例では、「CURRENCY」フィールドの値（パラメータ）として通貨「KHR」（３１ａ）が追加され、また、「ACCURUAL.PARAM」フィールード（３１ｂ）が新設されて、新バージョンで新たな機能がサポートされたことを示している。なお、新バージョンではこのような機能拡張だけでなく、機能の整理統合により、旧バージョンの入出力項目が新バージョンでは削除されることもあり得る。

【0049】

新バージョンで追加されたフィールドやパラメータは、旧バージョンプログラムが実稼動している環境下でのオペレーションログ上には現れることはないのでテストデータの作成には旧バージョン入出力項目テーブル３０のみが用いられる。ただし、差分比較結果テーブルの作成には新旧バージョンの入出力項目が必要となる。

【0050】

図５、図６は、本発明の実施形態に係るテスト実行手順を示す図である。図５は、基本テスト実行手順、図６は新機能テスト手順を示したものである。まず、図５のステップＳ１０において、新バージョンでのみサポートされる新機能があるかどうかをテスト管理者からの指示を受ける。新機能がある場合は、ステップＳ１１に移り新機能テストを行う。今回のテストが新機能を含まないバグ修正後のリグレッションテストのような場合は、ステップＳ１１はスキップされる。新機能テストとは、旧バージョンでは存在せず、今回の新バージョンで新たに追加された機能が仕様に合致しているかどうかを調べるテストをいう。新機能テストでは、実環境においてのオペレーションログが存在しないので実環境から生成したテストデータの自動作成ができず、したがって旧バージョンのテスト結果との差分比較ができないので、以降のテストの前段階のテストとして行うものである。

【0051】

新機能テストでも、オペレーションログによるテストデータの自動生成が可能である。ただし、この場合、実環境のオペレーションログではなく、テストオペレータがテスト環境において、予め定められたテストシナリオに沿って操作画面での操作を行い、その操作内容とその結果を実環境でのオペレーションログと同じ形式で新機能オペレーションログＤＢ１１に記録することで、テストデータ生成部２０は、新機能のテストデータを生成することができる。テストデータの生成には、新バージョン入出力項目テーブル３１が利用される。このようにテストデータの形式を同じにすることで、テスト実行部５０は、新機能テストデータと旧バージョンのテストデータを特に区別することなく被テストプログラム実行環境に投入することができる。ただし、新バージョンにおける新機能テストの結果は、既存機能のリグレッションとは異なり、旧バージョンでのテスト結果が存在しないので、テスト管理者等があらかじめ仕様に基づいて用意した新機能比較マスタＤＢ９２に格納された正しい出力結果と比較することになる。

【0052】

図６では、この新機能テストの手順を示しているが、基本的な流れは、以下で説明する図５の旧バージョンとの比較手順と上記の点を除いて大差はないので詳細な説明は省略する。

【0053】

図５に戻り、テストシステム１００のテストデータ生成部２０は、ステップＳ１２において、新旧バージョン入出力項目テーブル３０，３１が読み込まれるが、新旧バージョンで入出力項目に変更がない場合には、旧バージョン入出力項目テーブル３０のみが読み込まれる。さらに、テストデータ生成部２０は、ステップＳ１３において、オペレーションログ集積ＤＢ１０よりテストデータを生成する。ここでは、すでに説明したとおり、ＯＦＳファイルのようなプログラムが自動実行可能な所定の形式のテストデータファイルを生成する。

【0054】

次に、テストシステム１００のテスト実行部５０は、ステップＳ１４において、テスト環境におけるプログラム実行日時をテストデータに記録されたプログラム実行日時に合わせるように設定する。これは、同じ入力データであってもプログラムの実行する日時によって処理結果が異なることがあるからである。例えば、操作画面等に表示する現在日時はもちろんとして、ローンの満期日や利息等の計算では、プログラムの実行日（処理日）によって計算結果が異なるので、テストデータの元となったオペレーションログ中のプログラム実行日時にテストプログラムの実行日時を合わせるように内部時計を調整する必要がある。もちろん、このようなプログラムの実行日時等、出力結果に影響する日時データそのものをすべて入力データとして扱うようにプログラムが設計されていればステップＳ１４の処理はスキップすることができる。

【0055】

次に、テスト実行部５０は、ステップＳ１５において、新旧バージョン適用被テストプログラム実行環境６０，６１それぞれに、テストデータ生成部２０によって生成された同じテストデータを投入する。そして、ステップＳ１６において、被テストプログラムの出力結果（テストデータに対するアウトプット）を新旧バージョンテスト結果データＤＢ９０，９１に記録する。

【0056】

その結果、ステップＳ１７において、テストシステム１００の差分比較部７０が、この新旧バージョンテスト結果データＤＢ９０，９１を読み出し、差分比較結果テーブル８０を作成する。このとき新旧バージョン入出力項目テーブル３０，３１が参照される。以上のステップＳ１４〜Ｓ１７の処理をすべてのテストデータ（画面ごと、及びトランザクションごと）について繰り返す（ステップＳ１８）。このようにして得られた差分比較結果テーブル８０から、テスト管理者は、新バージョンのプログラムの不具合の有無を調べることができる。

【0057】

図７は、本発明の実施形態に係る差分比較結果テーブルの概略を示す図である。差分比較結果テーブル８０は、すでに説明したように、新旧バージョンの被テストプログラムに対し、同じテストデータをインプットとして、その出力結果を入力データとともに比較して一覧表形式にまとめたテーブルである。

【0058】

図示するように、表中の２つの行のペア（８６ａ，８６ｂ，８６ｃ・・・）として新旧バージョンの入出力結果が表示される。１つの行（レコード）は、被テストプログラムのトランザクション（処理単位）ごとに作成されるレコードである。欄８１ｂは、「Ｄｉｆｆフラグ」と呼び、例えば記号「＊」があると、新旧のレコード中いずれかに違いがあることを示す。新旧の比較はすべてのトランザクションに対して行われるので、差があるものも、差がないものも、すべての比較結果を差分比較結果テーブル８０に記載するようにしてもよいし、差分があるレコードのみを差分比較結果テーブル８０に記載するようにしてもよい。

【0059】

欄８２の「新旧のみフラグ」とは、新バージョンまたは旧バージョンどちらかにしかそのトランザクションに対応するレコードが存在しなかったことを示す。例えば、新バージョンでしかサポートされない新機能のテストデータを誤って旧バージョンのプログラムに投入した場合には、旧バージョンのプログラムはエラーとなり、出力結果が得られないので新バージョンのレコードのみが存在することになる。この場合、「新旧のみフラグ」が「ＮＥＷ ＯＮＬＹ」となり、このレコードがテーブルに記載される。同様に、旧バージョンでサポートされていたが、新バージョンでサポートされていない機能（Discontinue Functon）のテストデータを新バージョンのプログラムに投入した場合には、「新旧のみフラグ」が「ＯＬＤ ＯＮＬＹ」となったレコードのみがテーブルに記載される。

【0060】

また、「新旧のみフラグ」は、「新旧のみフラグ」が「ＮＥＷ ＯＮＬＹ」となったレコードに対応するレコードを新機能比較マスタＤＢ９２から検索し、対応するレコードがあればそれを比較対象として抽出させるための役割も果す。また、現場のオペレータでなく、テストが作成した新機能オペレーションログＤＢ１１から作成した新機能テストデータを検証する際にも役立つ。すなわち、新機能テストデータに含まれる入出力項目が差分比較結果テーブル８０に正しく反映されるかどうかの確認等に利用できる。

【0061】

欄８３「トランザクションＩＤ」は、各処理単位ユニークなトランザクションＩＤを記載する欄である。通常は一つのトランザクションＩＤに対して新旧のレコードがそれぞれ存在することになる。欄８４「新旧レコード」は、そのレコード行が新バージョンのプログラムのテスト結果（ＮＥＷ）か、旧バージョンのテスト結果（ＯＬＤ）かを示すフラグである。比較マスタを比較元とする場合には、「新旧レコード」は「ＭＡＳＴＥＲ」とすれば、レコードペアは、「ＮＥＷ」と「ＭＡＳＴＥＲ」となる。欄８５は、画面毎に定義された入力項目、出力項目すべて、すなわち、新旧バージョン入出力項目テーブル３０，３１に定義された項目のすべてである。ただし、各出力項目の前には、「Ｄｉｆｆフラグ」欄が存在し、対応する出力項目の出力結果が新旧（あるいは新とＭＡＳＴＥＲ）で異なっていることを示す。例えば、８６ａのレコードでは、出力項目１の結果が異なっているので、出力項目１の直前の「Ｄｉｆｆフラグ」が、記号「＊」で示されることになる。このように、「Ｄｉｆｆフラグ」をレコード全体と各出力項目ごとに設けることで、新旧の相違点の発見を容易にすることができる。もちろん、「Ｄｉｆｆフラグ」の記号の代わりに、識別表示手段として、セルや文字の表示色やサイズを変えたり、図形表示を追加するなどしてもよい。

【0062】

図８は、本発明の実施形態に係る差分比較結果テーブルの具体例を示す図である。図は、ローンの利息計算をするプログラムをテスト対象の具体例としてテストの結果、その差分比較結果テーブル８０の一部を示す。前図で説明したように、新旧の比較結果であるレコードペア８６ａ，８６ｂ，８６ｃ，８６ｄ，８６ｅに示されている。８６ｆは、旧バージョンでしか結果が得られなかったレコード、８６ｇは新バージョンでしか結果が得られなかったレコード、すなわち比較対象のバージョンのテスト結果が存在しなかったレコードを示している。

【0063】

この図では、各出力項目ごとに対応する「Ｄｉｆｆフラグ」の代わりに、太線四角枠で新旧バージョンのテスト結果が異なっている出力項目を表している。すなわち、レコードペア８６ａでは、「元本金額」、「利息金額」、「処理日付」が新旧で異なっているが、何らかの原因で融資スケジュールの「処理日付」の相違により、「元本金額」と「利息金額」の結果が異なってきているのではないかと考えられる。また、レコードペア８６ｃでは、「利息計算日数」の相違により、利息金額の計算結果の差異が生じ、レコードペア８６ｅでは、「適用レート」の相違により「利息金額」の計算結果が異なっているのではないかと考えられる。なお、レコードペア８６ｇでは、比較されたレコードが「ＮＥＷ」と「ＭＡＳＴＥＲ」になっており、新機能テストの場合の比較結果である（実際には、旧バージョンとの比較テストと新機能テストは、別個に行われるので混在することはない）。

【0064】

このように、新バージョンの被テストプログラムの出力結果と、実績のある旧バージョンの被テストプログラムの出力結果との比較が多くの入力データのバリエーションに対して容易に行えるので、不具合の早期発見、早期解決に役立たせることができる。特に、プログラムのバージョンアップの際、通常の機能テストではなかなか発見しづらい従来機能の思わぬ箇所の思わぬ不具合の発見に役立たせることができる。また、パッケージソフトなど内部がブラックボックスのプログラムを組み込んでシステムを構築する場合にも特に有用である。

【0065】

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

【符号の説明】

【0066】

１０ オペレーションログ集積ＤＢ
１１ 新機能オペレーションログＤＢ
２０ テストデータ生成部
３０ 旧バージョン入出力項目テーブル
３１ 新バーション入出力項目テーブル
４０ テストデータＤＢ
５０ テスト実行部
６０ 旧バージョン適用被テストプログラム実行環境
６１ 新バージョン適用被テストプログラム実行環境
７０ 差分比較部
８０ 差分比較結果テーブル
９０ 旧バージョンテスト結果データＤＢ
９１ 新バージョンテスト結果データＤＢ
９２ 新機能比較マスタＤＢ
１００ テストシステム
２００ 実環境
２１０ オペレータ操作画面
２２０ オペレーションログ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】