JP2011141631A - 現金自動取引装置及び現金自動取引装置の更新プログラムのテスト方法 - Google Patents

Abstract

【課題】実際の取引を模擬した環境で、更新プログラムの動作確認テストを行う。
【解決手段】現金自動取引装置１０であって、第１のＯＳ１２０と、第１のメモリ１３０と、を有し、現金自動取引が行われる実環境１００と、前記第１のＯＳ１２０と独立した第２のＯＳ２２０と、前記第１のメモリと独立した第２のメモリ２３０と、を有し、前記実環境１００から独立して前記実環境に適用する更新プログラム２３２のテストを行う仮想環境２００と、を備え、前記仮想環境２００は、前記実環境における稼働状況１３３を抽出し、前記第２のメモリ２３０に稼働履歴２３８として記録し、前記更新プログラム２３２に対し、前記稼働履歴２３８と同一の処理を実行させて、前記更新プログラム２３２のテストを行う。
【選択図】図２

Description

本発明は、現金自動取引装置（ＡＴＭ）の更新プログラムのテストに関する。

現金自動取引装置のファームウエアを更新するための技術が知られている（例えば特許文献１）。

特開２００６−２２７６７７号公報 特開２００６−３９７６３号公報

一般にＡＴＭのプログラムは、開発元において動作確認テストを行っている。しかし、開発元での動作確認テストでは、実際の取引と同一のテスト環境を模擬することは困難であった。

本発明は、上述の課題の少なくとも一部を解決し、実際の取引を模擬した環境で、更新プログラムのテストを行うことを目的とする。

本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。

［適用例１］
現金自動取引装置であって、第１のＯＳと、第１のメモリと、を有し、現金自動取引が行われる実環境と、前記第１のＯＳと独立した第２のＯＳと、前記第１のメモリと独立した第２のメモリと、を有し、前記実環境から独立して前記実環境に適用する更新プログラムのテストを行う仮想環境と、を備え、前記仮想環境は、前記実環境における稼働状況を抽出し、前記第２のメモリに稼働履歴として記録し、前記更新プログラムに対し、前記稼働履歴と同一の処理を実行させて、前記更新プログラムのテストを行う、現金自動取引装置。
この適用例によれば、実際の取引を模擬した環境で、更新プログラムのテストを行うことが可能となる。

［適用例２］
適用例１に記載の現金自動取引装置において、前記第２のメモリは、前記第１のメモリの稼働状況を前記第１のメモリから抽出して前記第２のメモリに稼働履歴として記録する抽出プログラムと、前記更新プログラムと、を格納しており、前記仮想環境は、前記更新プログラムに、前記第２のメモリに格納された前記稼働履歴と同一の処理を実行させて前記更新プログラムのテストを行う、現金自動取引装置。
この適用例によれば、抽出プログラムは、実環境のメモリから稼働履歴を抽出するだけなので、実環境１００に影響を与えない。

［適用例３］
適用例１または適用例２に記載の現金自動取引装置において、前記稼働履歴は、あらかじめ前記現金自動取引装置毎に、定期あるいは不定期に実行される処理の履歴と、前記現金自動取引装置に対して行われた取引の履歴と、を含む、現金自動取引装置。
この適用例によれば、顧客との取引に基づく稼働履歴の他に、現金自動取引装置毎に、定期あるいは不定期に実行される処理の履歴の両方を稼働履歴に反映させることが可能となる。

本発明は、種々の形態で実現することが可能であり、例えば、現金自動取引装置の他、現金自動取引装置のプログラムのテスト方法等、様々な形態で実現することができる。

プログラム更新における現金自動取引システムの構成を示す説明図である。 現金自動取引装置の構成を示す説明図である。 仮想レイヤー２５０の構成を示す説明図である。 稼働履歴１３３の一例を示す説明図である。 仮想環境における処理を示すフローチャートである。 テストシナリオと判定結果２３６の一部を示す説明図である。

図１は、プログラム更新における現金自動取引システムの構成を示す説明図である。現金自動取引システムは、現金自動取引装置１０（以下「ＡＴＭ１０」とも呼ぶ。）と、配布サーバー４０と、配布クライアント５０と、を備える。

現金自動取引装置１０は、実環境１００と、仮想環境２００と、表示パネル３００と、を備える。実環境１００は、利用者との間で様々な取引を行うために用いられる。ここで取引とは、例えば、預入、払戻、振込、残高照会、通帳記入等の取引を意味する。なお、ここに列挙したものは、取引の一例であり、ここに記載されていない取引を排除するものではない。仮想環境２００は、利用者との間の取引には用いられず、本実施例では、更新プログラムのテストのために用いられる。「更新プログラム」とは、自動取引装置１０の処理を実行するためのプログラムであって、更新された新たなプログラム（バージョンアップされたプログラム）である。本実施例では、仮想環境２００は、実環境１００における稼働状況を抽出して、稼働履歴を仮想環境２００内に作成する。そして、仮想環境２００は、稼働履歴を用いて更新プログラムのテストランを実行し、その処理結果が正常か否かを確認する。ここで、仮想環境２００による更新プログラムのテストの動作が実環境１００の動作に影響を与えないように、仮想環境２００は、実環境から独立して構成されている。表示パネル３００は、現金自動取引装置１０の稼働状態を、現金自動取引装置１０の管理者に知らせるために用いられるが、本実施例では、表示パネル３００は、更新プログラムのテスト結果を表示するためにも用いられる。なお、表示パネル３００は、現金自動取引装置１０の、利用者（顧客）から見えない位置、例えば背面に配置されることが好ましい。

更新プログラムのテスト結果には、様々な表示方法があり、ここでは、そのいくつかの例について説明する。
（１）パターン１：自動機の表示パネルに表示
パターン１では、上述したように、現金自動取引装置１０の表示パネル３００にテスト結果を表示する。この方法では、作業担当者は、現金自動取引装置１０の表示パネル３００にて、テスト結果を容易に確認することがが可能となる。

（２）パターン２：Ｐｕｓｈ型 (即時)
パターン２では、仮想環境２００は、テスト結果を、リアルタイムに指定の配布サーバー４０に接続されたの仮想データベース４５に格納する。この方法では、作業担当者は、配布クライアント５０を用いて、テスト結果を即座に確認することが可能となる。

（３）パターン３：Ｐｕｌｌ型
パターン３では、テスト結果は、フラッシュメモリ２３０に格納される。配布クライアント５０あるいは配布サーバー４０は、ネットワークを介して仮想環境２００のフラッシュメモリにアクセスし、テスト結果を取得する。この方法では、現金自動取引装置１０が通電されている状態であれば、配布クライアント５０あるいは配布サーバー４０は、２４時間３６５日いずれであってもテスト結果を取得することが可能である。また、パターン３では、現金自動取引装置１０稼動中のネットワーク負荷を考慮したテスト結果採取を可能である。

配布サーバー４０は、更新プログラムを現金自動取引装置１０に配布する。更新プログラムをテストする場合には、配布サーバー４０は、仮想環境２００に更新プログラムを配布する。更新プログラムが、テストされ、実環境１００に導入可能な状態までデバッグが完了している場合には、配布サーバー４０は、更新プログラムを実環境１００に配布する。なお、配布サーバー４０は、仮想環境２００により行われた更新プログラムのテストの結果を格納するための仮想データベース４５を備えていてもよい。

配布クライアント５０は、配布サーバー４０に対し、更新プログラムの配布を指示するための端末である。なお、現金自動取引装置１０の管理者は、配布クライアント５０を操作することにより、配布サーバー４０に格納された更新プログラムのテストの結果を取得することが可能である。

図２は、現金自動取引装置の構成を示す説明図である。現金自動取引装置１０は、上述のように、実環境１００と、仮想環境２００と、を備えている。実環境１００は、第１のコンピュータにより構成されており、ＣＰＵ１１０と、ＯＳ１２０と、ＲＡＭ１３０と、ハードディスク１４０とを備える。仮想環境２００は、第２のコンピュータにより構成されており、ＣＰＵ２１０と、ＯＳ２２０と、フラッシュメモリ２３０とを備える。以後、『実環境１００』を『第１のコンピュータ１００』とも呼び、『仮想環境２００』を『第２のコンピュータ２００』とも呼ぶ。なお、ＣＰＵ１１０、２１０は、実際には、同一のハードウエア（１個のＣＰＵ）であってもよく、あるいは、別個の独立した２つのＣＰＵとして実装されていてもよい。ハードディスク１４０は、実環境１００の更新前のバージョンのプログラム（以下「更新前プログラム１４１」と呼ぶ。）及び稼働シナリオ１４２を格納している。ＣＰＵ１１０は、この更新前プログラム１４１を実行することにより、実環境１００における取引処理を実行する。稼働シナリオ１４２は、現金自動取引装置１０の実環境１００における定期的なルーチンワークを規定する。

実環境１００は、仮想環境２００から独立して設けられており、仮想環境２００の処理が実環境１００の処理に影響を与えない。ＲＡＭ１３０、フラッシュメモリ２３０も独立して設けられている。ただし、ＲＡＭ１３０と、フラッシュメモリ２３０とは、仮想レイヤー２５０を形成している。仮想環境２００のＯＳ２２０は、仮想レイヤー２５０を介して、フラッシュメモリ２３０にアクセス可能である。すなわち、ＯＳ２２０上で実行される抽出プログラム（後述）が、ＲＡＭ１３０に格納されたデータの一部を抽出することが可能である。一方、実環境のＯＳ１２０は、フラッシュメモリ２３０にアクセスすることはできない。

図３は、仮想レイヤー２５０の構成を示す説明図である。仮想レイヤー２５０は、上述したように、ＲＡＭ１３０と、フラッシュメモリ２３０と、を備えている。ＲＡＭ１３０は、更新前プログラム１３１と、稼働シナリオ１３２と、稼働状況１３３とを格納している。ここで、更新前プログラム１３１と、稼働シナリオ１３２は、それぞれ、ハードディスク１４０の更新前プログラム１４１、稼働シナリオ１４２がコピーされてきたものである。稼働状況１３３は、取引処理１３４と、取引により生じたメモリの状態（例えばプロセス１３４、スレッド１３５）を含む。

フラッシュメモリ２３０は、抽出プログラム２３１と、更新プログラム２３２と、テスト実行プログラム２３３と、判定プログラム２３４と、通信プログラム２３５と、判定結果２３６、テストシナリオ２３７と、稼働記録２３８と、を格納している。抽出プログラム２３１は、実環境１００に影響を与えることなく、ＲＡＭ１３０から稼働状況１３３を抽出して稼働履歴２３８として記録する。このときの抽出タイミングは、例えば、稼働状況１３３に変化が生じたとき、すなわち、新たな取引や、ルーチン処理が行われたとき、あるいは、メモリ状態（プロセス１３５やスレッド１３６）に変化が生じたときが好ましい。

稼働履歴２３８は、取引履歴２３８ａと、ルーチン処理履歴２３８ｂと、メモリ状態履歴２３８ｃと、を含んでいる。取引履歴２３８ａは、利用者により行われる不定期な取引の処理の履歴であり、ルーチン処理履歴２３８ｂは、稼働シナリオ１３２に従って行われる定期的な処理の履歴である。メモリ状態履歴２３８ｃは、実環境１００のＲＡＭ１３０内の構成要素であるプロセス１３５やスレッド１３６の割り当て状態や稼働状態の履歴である。メモリ状態履歴２３８ｃは、プロセス１３５やスレッド１３６以外の情報（例えば、メモリ管理用の情報など）を含んでいてもよい。

図４は、稼働履歴２３８の一例を示す説明図である。稼働履歴２３８には、時刻を基準として、処理内容、処理結果が格納されている。例えば、図４に記載した処理のうち、出金処理、入金処理、通帳記入処理、振込処理、残高照会処理は、取引履歴１３４に相当し、処理Ａ、集計処理は、ルーチン処理履歴に相当する。

図３に示す更新プログラム２３２は、テストされるプログラムであり、配布サーバー４０から仮想環境２００に送信され、フラッシュメモリ２３０に格納されたものである。テストシナリオ２３７は、抽出した稼働履歴２３８を用いて構成されたものである。テスト実行プログラム２３３は、テストシナリオ２３７を用いて、更新プログラム２３２のテストランを実行する。判定プログラム２３４は、稼働履歴２３８と、更新プログラムのテストランの処理結果とを比較して、更新プログラム２３２の良否判定を行い、結果を判定結果２３６に格納する。通信プログラム２３５は、更新プログラム２３２を受信したり、判定結果２３６を配布サーバー４０に送信したりする場合に用いられる。

図５は、仮想環境における処理を示すフローチャートである。ステップＳ５００では、ＣＰＵ２１０は、配布サーバー４０から更新プログラムを受信し、フラッシュメモリ２３０に格納する。ステップＳ５１０では、ＣＰＵ２１０は、抽出プログラム２３１を実行し、実環境１００のＲＡＭ１３０から稼働状況１３３を抽出する。ＣＰＵ２１０は、ＲＡＭ１３０の稼働状況１３３が変化する度に抽出することが好ましい。また、抽出条件は、指定が可能であり、特定の処理に関する稼働状況１３３のみを抽出することも可能である。

ステップＳ５２０では、ＣＰＵ２１０は、抽出した稼働状況１３３を、フラッシュメモリ２３０中に稼働履歴２３８として格納する。ステップＳ５３０では、ＣＰＵ２１０は、テスト実行プログラム２３３を実行して、稼働履歴２３８を用いてテストシナリオ２３７を作成する。ステップＳ５４０では、ＣＰＵ２１０は、更新プログラム２３２に対し、テストシナリオ２３７に規定された動作を実行させることにより、実環境１００における動作を模擬したテストランを実行する。なお、ＣＰＵ２１０は、テストシナリオ２３７を作成する際に、稼働履歴２３８の内容に、更新前のプログラムでは実行していなかったルーチンワークの内容を加えてもよい。この追加するルーチンワークの内容は、例えば、配布サーバー４０から送信される。また、ルーチン処理履歴に記録された処理の内容を、異なる処理の内容に変更してもよい。

ステップＳ５５０では、ＣＰＵ２１０は、判定プログラム２３４を実行し、更新プログラム２３２のテストランの結果の良否を判定する。ＣＰＵ２１０は、抽出した稼働履歴２３８に格納された処理結果と、更新プログラム２３２のテストランの処理結果と、を比較することにより判定を行う。判定は、処理毎に行われることが好ましい。こうすれば、どの処理に対するプログラムにバグがあり、どの処理に対するプログラムにバグが無かったかが判る。したがって、プログラム開発者は、バグがあった処理に関する更新プログラム部分（例えばサブルーチンやダイナミンク・リンク・ライブラリー（ＤＬＬ））のデバッグを行えばよい。

ステップＳ５６０では、ＣＰＵ２１０は、判定結果２３６を表示パネル３００に表示する。この処理は、上述したパターン１の表示方法に相当する。ステップＳ５７０では、ＣＰＵ２１０は、判定結果２３６を配布サーバー４０に送信する。この処理は、上述したパターン２の表示方法に相当する。なお、ステップＳ５６０、Ｓ５７０は、いずれか一方のみの実行であってもよい。また、上述したパターン３の表示方法のように、配布サーバー４０が、現金自動取引装置１０に対し、判定結果を送信するように要求した場合に、ＣＰＵ２１０が、ステップＳ５６０を実行してもよい。

図６は、テストシナリオと判定結果２３６の一部を示す説明図である。上段がテストシナリオ２３７を示し、下段が判定結果２３６を示している。例えば、処理４０１は、実環境１００で毎週月曜日の１０：００に実行する処理を示す。ここでは指定条件が自動となっている。指定条件が自動の場合は、月曜日の１０：００に実環境１００で実行されると、その処理内容や処理結果は直ちに、仮想環境２００にコピーされ、仮想環境２００で直ちに実行される。この処理は正常に終了している。処理４０２は、金曜日の１０：００に１回のみ実行する処理を示している。ここでは指定条件が手動となっている。指定条件が手動の場合には、その処理は、実環境１００で実行されたものが自動的に取り込まれたものではなく、例えば配布サーバー４０において準備された新たな処理が、手動でテストシナリオ２３７に格納されたことを意味する。本実施例では、ＮＧとなっており、ＮＧの内容が判定結果２３６に書き込まれる。開発者は、この判定結果を考慮して、処理４０２に係る更新プログラム部分のデバッグを行うことができる。処理４０３は、土曜日の１０：００に処理Ａを行い、その結果を引き継いで１１：００に処理Ｂを実行する処理を示している。このように、複数の処理Ａ、Ｂを合わせて１トランザクションとしてプログラムの良否を判定することも可能である。

以上、本実施例によれば、現金自動取引装置１０は、実環境１００と仮想環境２００で、それぞれ独立したＯＳ１２０、２２０、メモリ（ＲＡＭ１３０、フラッシュメモリ２３０）を有している。そして、実環境１００は、稼働状況をＲＡＭ１３０に格納し、仮想環境２００は、実環境１００で行われた稼働状況１３３を抽出し、稼働状況１３３に基づいて、テストシナリオ２３７を作成し、更新プログラム２３２のテストランを行う。したがって、実際の取引を模擬した環境で、更新プログラム２３２のテストランを行うことが可能となる。また、本実施例では、仮想環境２００の抽出プログラム２３１は、実環境１００のＲＡＭ１３０から取引状況１３３を抽出するだけなので、実環境１００に影響を与えない。また、実環境１００で取引が有ったときは、すぐにその取引についての稼働状況１３３を抽出するので、１回ごとの抽出するデータ量が少ないので、データ抽出の負担が少ない。

以上、いくつかの実施例に基づいて本発明の実施の形態について説明してきたが、上記した発明の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得るとともに、本発明にはその等価物が含まれることはもちろんである。

１０…現金自動取引装置
４０…配布サーバー
４５…仮想ＤＢ
５０…配布クライアント
１００…実環境（第１のコンピュータ）
１１０…ＣＰＵ
１２０…ＯＳ
１３０…第１のメモリ
１３１…更新前プログラム
１３２…稼働シナリオ
１３３…稼働状況
１３４…取引処理
１３５…プロセス
１３６…スレッド
１４０…ハードディスク
１４１…更新前プログラム
１４２…稼働シナリオ
２００…仮想環境（第２のコンピュータ）
２１０…ＣＰＵ
２２０…ＯＳ
２３０…フラッシュメモリ
２３１…抽出プログラム
２３２…更新プログラム
２３３…テスト実行プログラム
２３４…判定プログラム
２３５…通信プログラム
２３６…判定結果
２３７…テストシナリオ
２３８…稼働履歴
２３８ａ…取引履歴
２３８ｂ…ルーチン処理履歴
２３８ｃ…メモリ状態履歴
２５０…仮想レイヤー
３００…表示パネル
４０１〜４０３…処理

Claims (4)

1. 現金自動取引装置であって、
   第１のＯＳと、第１のメモリと、を有し、現金自動取引が行われる実環境と、
   前記第１のＯＳと独立した第２のＯＳと、前記第１のメモリと独立した第２のメモリと、を有し、前記実環境から独立して前記実環境に適用する更新プログラムのテストを行う仮想環境と、
   を備え、
   前記仮想環境は、
   前記実環境における稼働状況を抽出し、
   前記第２のメモリに稼働履歴として記録し、
   前記更新プログラムに対し、前記稼働履歴と同一の処理を実行させて、前記更新プログラムのテストを行う、
   現金自動取引装置。
2. 請求項１に記載の現金自動取引装置において、
   前記第２のメモリは、
   前記第１のメモリの稼働状況を前記第１のメモリから抽出して前記第２のメモリに稼働履歴として記録する抽出プログラムと、
   前記更新プログラムと、
   を格納しており、
   前記仮想環境は、前記更新プログラムに、前記第２のメモリに格納された前記稼働履歴と同一の処理を実行させて前記更新プログラムのテストを行う、
   現金自動取引装置。
3. 請求項１または請求項２に記載の現金自動取引装置において、
   前記稼働履歴は、
   あらかじめ前記現金自動取引装置毎に、定期あるいは不定期に実行される処理の履歴と、
   前記現金自動取引装置に対して行われた取引の履歴と、
   を含む、
   現金自動取引装置。
4. 現金自動取引装置の更新プログラムのテスト方法であって、
   （ａ）現金自動取引装置内の実環境の稼働状況を第１のメモリに格納する工程と、
   （ｂ）前記稼働状況を前記第１のメモリから抽出し、前記現金自動取引装置内の仮想環境の第２のメモリであって、前記実環境からアクセス不能な第２のメモリに稼働履歴として格納する工程と、
   （ｃ）更新プログラムを前記第２のメモリに格納する工程と、
   （ｄ）前記更新プログラムに対し、前記稼働履歴と同一の処理を実行させて、前記更新プログラムのテストを行う工程と、
   を備える、現金自動取引装置の更新プログラムのテスト方法。

Images