(57)【要約】【課題】  ＧＵＩ画面のコンポーネントに対して操作が行われた際に、該ＧＵＩ画面上の配置を示す論理的な位置情報を用いて該操作を記録する装置及び方法を提供する。【解決手段】  ＧＵＩアプリケーションによりＧＵＩ画面上に表示されたコンポーネントに対してユーザの操作又は自動操作が行われた場合、そのコンポーネントのＧＵＩ画面上の配置を示す論理的な位置情報を生成する。そして、生成された論理的な位置情報を操作が行われたコンポーネントの操作記録として記録する。【選択図】      図１
2012018583.tif 000002
【特許請求の範囲】
【請求項１】
ＧＵＩアプリケーションによりＧＵＩ画面上に表示された複数のコンポーネントに対するユーザの操作又は自動操作を記録した操作記録を用いてソフトウェアの開発を支援するソフトウェア開発支援装置であって、
前記ユーザの操作又は自動操作が行われたコンポーネントの前記ＧＵＩ画面上の配置を示す論理的な位置情報を生成する生成手段と、
前記生成手段により生成された論理的な位置情報を前記操作が行われたコンポーネントの操作記録として記録する操作記録手段と、
を有することを特徴とするソフトウェア開発支援装置。
【請求項２】
前記操作記録手段により記録された論理的な位置情報に配置されたコンポーネントが操作可能であるかを他のコンポーネントとの重なり具合を元に検証する検証手段を更に有することを特徴とする請求項１に記載のソフトウェア開発支援装置。
【請求項３】
前記生成手段は、前記複数のコンポーネントの前記ＧＵＩ画面上の配置順及び親子関係により木構造の情報として前記操作が行われたコンポーネントの論理的な位置情報を生成することを特徴とする請求項１に記載のソフトウェア開発支援装置。
【請求項４】
前記操作記録は、各操作が行われた時間的な間隔や各操作の時刻を示す情報を更に含み、該操作記録を用いて前記複数のコンポーネントの検証を行うことを特徴とする請求項１又は２に記載のソフトウェア開発支援装置。
【請求項５】
ＧＵＩアプリケーションによりＧＵＩ画面上に表示された複数のコンポーネントに対するユーザの操作又は自動操作を記録した操作記録を用いてソフトウェアの開発を支援するソフトウェア開発支援装置の処理方法であって、
生成手段が、前記ユーザの操作又は自動操作が行われたコンポーネントの前記ＧＵＩ画面上の配置を示す論理的な位置情報を生成する生成工程と、
操作記録手段が、前記生成工程において生成された論理的な位置情報を前記操作が行われたコンポーネントの操作記録として記録する操作記録工程と、
を有することを特徴とするソフトウェア開発支援装置の処理方法。
【請求項６】
コンピュータを、請求項１乃至４の何れか１項に記載のソフトウェア開発支援装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアの開発を支援する技術に関する。
【背景技術】
【０００２】
従来、ＧＵＩアプリケーションのテスト自動化を行う技術としては、テストスクリプトを自動生成する技術が存在する（例えば、特許文献１参照）。
【０００３】
特許文献１に記載されたテストスクリプト（テスト記述書）の自動生成技術は、ＧＵＩアプリケーション全般の画面遷移に対して網羅テストを行うことに主眼が置かれている。また、ＧＵＩアプリケーションのプログラムのソースコードやＵＭＬなどの設計情報などを必要としている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許４１４８５２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来、ＧＵＩアプリケーションのテスト自動化システムの用途として、プログラムのソースコードやＵＭＬなどの設計情報を使用せずに、ブラックボックス的な回帰テストに利用するというものがある。
【０００６】
特に、最初にユーザがＧＵＩ画面上を操作し、その操作に関する情報を操作記録として保存し、その操作記録をテストスクリプトとして再生（自動操作）させる記録再生タイプのテスト自動化が広く利用されている。
【０００７】
上述の記録再生タイプのテスト自動化システムでは、ＧＵＩ画面上の操作をスクリーン座標系（ＸＹ座標系）を用いて記録している。これ以降、記録再生タイプのテスト自動化システムにおいて、スクリーン座標系を使った記録再生タイプのテスト自動化での課題について説明する。
【０００８】
操作記録を取得する際に、スクリーン座標系を用いて記録した場合、再生（自動操作）時に操作対象のＧＵＩコンポーネントの配置が異なっていると、記録された位置にＧＵＩコンポーネントが存在せず再生できないことがある。
【０００９】
再生（自動操作）できない具体例として、ＧＵＩコンポーネントの大きさが変更された場合や、異なる座標位置に描画された場合などが挙げられる。
【００１０】
そのため、ＧＵＩ画面のサイズの拡大・縮小や縦横比、見栄えなどのデザイン上の変更が生じると、画面遷移のパターンや処理フローに変更がなくても、全般的に操作を記録し直さなければならないという問題があった。
【００１１】
上述したように、スクリーン座標系を使った記録再生タイプのテスト自動化システムにおいて、表示デバイスの画面サイズやデザインの変更に柔軟に対応できないことが課題としてある。
【００１２】
また、ＧＵＩアプリケーションの多機能化及び高機能化に伴い、ＧＵＩ画面の画面遷移パターンが増大してきており、画面サイズの変更やデザイン変更の度に、操作記録を取り直すことに対するコストの問題もある。
【００１３】
一方、ＧＵＩプログラミングにおいては、Ｊａｖａ（登録商標）のようなオブジェクト指向言語で問題を生ずる場合がある。このオブジェクト指向言語は、抽象データ型の一つであるクラスの再利用性が高いため、サイズや配置の全く同じオブジェクトを誤って生成してしまうことがある。このような場合、ユーザが目視では検証できないため、内部的にはＣＰＵやメモリなどのリソースの無駄であり、更に、プログラムの可読性を低下させ、バグを誘発するコードを内包してしまうという課題があった。
【００１４】
更に、ＧＵＩ画面の構成が複雑化及び多様化するに伴い、ユーザ対話型のＧＵＩコンポーネントが増える場合があり、その際、操作イベントを検知するためのリスナー登録ミスが起きることがある。リスナーとは、ＧＵＩアプリケーション内の種々のイベントを処理するための仕組みであり、ユーザ対話型のＧＵＩコンポーネントの場合、操作イベントに応じたリスナーが登録されている必要がある。リスナーが登録されていないと、クリックしても実際には何の処理もされないボタンなどが存在することになり、ソースコードから間違いに気付くか、対象のＧＵＩコンポーネントを操作しないと発見できないという課題があった。
【００１５】
本発明は、ＧＵＩ画面のコンポーネントに対して操作が行われた際に、該ＧＵＩ画面上の配置を示す論理的な位置情報を用いて該操作を記録する装置及び方法を提供する。
【課題を解決するための手段】
【００１６】
本発明は、ＧＵＩアプリケーションによりＧＵＩ画面上に表示された複数のコンポーネントに対するユーザの操作又は自動操作を記録した操作記録を用いてソフトウェアの開発を支援するソフトウェア開発支援装置であって、
前記ユーザの操作又は自動操作が行われたコンポーネントの前記ＧＵＩ画面上の配置を示す論理的な位置情報を生成する生成手段と、
前記生成手段により生成された論理的な位置情報を前記操作が行われたコンポーネントの操作記録として記録する操作記録手段と、
を有することを特徴とする。
【発明の効果】
【００１７】
本発明によれば、ＧＵＩ画面のコンポーネントに対して操作が行われた際に、該ＧＵＩ画面上の配置を示す論理的な位置情報を用いて該操作を記録することができる。従って、画面サイズやデザイン変更を行う際に、操作記録を取り直す手間やコストを低減することができる。
【図面の簡単な説明】
【００１８】
【図１】本実施形態におけるシステムの構成を示すブロック図。
【図２】ソフトウェア開発支援装置のソフトウェア構成を示す図。
【図３】本実施形態における操作記録システムの処理を示すフローチャート。
【図４】テスト対象アプリケーションの表示部における表示例を示す図。
【図５】ＧＵＩコンポーネントの配置順と親子関係を木構造として示す図。
【図６】構造化言語のＸＭＬで表記した操作記録の一例を示す図。
【図７】本実施形態における自動操作システムのシステム構成を示す図。
【図８】被試験装置における自動操作プログラムＡ及びテスト対象のＧＵＩアプリケーションに関する処理を示すフローチャート。
【図９】リモート試験装置における自動操作プログラムＢの処理を示すフローチャート。
【図１０】（Ａ）はＧＵＩコンポーネントの操作記録を取得した時の配置を示す図、（Ｂ）は自動操作プログラムを実行した時の配置を示す図。
【図１１】記録分析プログラムの手順を示すフローチャート。
【図１２】ＧＵＩアプリケーションが表示するＧＵＩ画面の例を示す図。
【図１３】ＸＭＬで記述された操作結果の情報を示す図。
【図１４】記録分析プログラムの手順を示すフローチャート。
【図１５】ＸＭＬで記述された操作結果の情報を示す図。
【図１６】ＧＵＩコンポーネント種別の必須リスナーのテーブルを示す図。
【発明を実施するための形態】
【００１９】
以下、図面を参照しながら発明を実施するための形態について詳細に説明する。本発明に係るソフトウェア開発支援装置として、操作記録システム、自動操作システム及び記録分析システムを例に挙げて説明する。また、テスト対象のソフトウェアとしては、ＧＵＩアプリケーションを例に挙げて説明する。
【００２０】
図１は、本実施形態におけるシステムの構成を示すブロック図である。図１に示すように、システムはＣＰＵ１０１、ＲＡＭ１０２、外部記憶装置１０４、表示部１０５、操作部１０６を含み、それぞれバス１０３を介して接続されている。このシステムが操作記録システム、自動操作システム及び記録分析システムに適用される。
【００２１】
ＣＰＵ１０１はシステム全体を制御する。ＲＡＭ１０２は外部装置などから供給されるプログラムやデータベースから取得したデータ、或いはプログラム実行中の中間データを一時記憶する。外部記憶装置１０４はハードディスクや不揮発性半導体メモリなどであり、システムを制御するプログラム及びＲＡＭ１０２より取得した情報を記憶する。表示部１０５はユーザインタフェース画面などを表示する。操作部１０６はユーザの操作を受け付け、その操作に応じた情報を入力する。尚、この操作部１０６と表示部１０５とが一体となったタッチパネル付きディスプレイ等も考えられる。
【００２２】
ソフトウェア開発支援装置の適用例として、テスト対象ＧＵＩアプリケーションによりＧＵＩ画面上に表示された複数のＧＵＩコンポーネントに対するユーザの操作を記録する操作記録システムを説明する。
【００２３】
図２は、本発明に係るソフトウェア開発支援装置のソフトウェア構成を示す図である。ＧＵＩアプリケーションの操作記録システムでは、図２において「テスト対象アプリケーション」と「操作記録プログラム」に着眼する。
【００２４】
図３は、本実施形態における操作記録システムの処理を示すフローチャートである。図４は、テスト対象アプリケーションの表示部における表示例を示す図であり、テスト対象アプリケーションが表示部１０５上に構成したＧＵＩコンポーネントの配置イメージである。
【００２５】
先ず、図３において、ＣＰＵ１０１がテスト対象アプリケーションの実行を開始すると、Ｓ３０１において、アプリケーションのＧＵＩ画面を表示部１０５に表示する。テスト対象アプリケーションは、Ｓ３０２においてマウスクリックなどのユーザ操作が行われた場合やアプリケーションの実行により、ＧＵＩコンポーネントの配置が変更された場合に、Ｓ３０３において、イベントを発生する。
【００２６】
これ以降、ユーザ操作によって発生したイベントを「操作イベント」と表現し、配置の変更によって発生したイベントを「配置イベント」と表現する。そして、このテスト対象アプリケーションのＳ３０３で発生したこのイベントを図２に示す操作記録プログラムがＳ３０６で検知することにより、様々な操作の記録を行う。
【００２７】
その後、Ｓ３０４において、イベントがテスト対象アプリケーションの終了イベントであるか否かを判定し、操作を続けるのであればＳ３０２に遷移し、次のユーザ操作を待つ。また、終了イベントであればテスト対象アプリケーションを終了する。
【００２８】
一方、操作記録プログラムは、図３に示すように、テスト対象アプリケーションと同時に実行され、Ｓ３０５において、テスト対象アプリケーションからのイベント通知を待つ。続いて、Ｓ３０３において発生したイベントをＳ３０６において検出する。Ｓ３０３においてイベントを発生させる仕組みは、テスト対象アプリケーションが持つこともできるし、アプリケーション実行環境がその仕組みを内包することもできる。
【００２９】
また、イベントの発生の仕組みがアプリケーション実行環境にあるならば、テスト対象アプリケーションは、本実施形態を実現するにあたって何ら特別な仕組みを追加する必要はない。また、使用するアプリケーション実行環境がイベントをキューなどによって集中的に一元管理しているならば、操作記録プログラムのイベント検出処理の実現は容易にはなるが、必ずしもイベントは一元的にキューイングされる必要はない。
【００３０】
アプリケーション実行環境がイベントをキューなどによって集中的に一元管理している場合、Ｓ３０３で発生した全てのイベントは、アプリケーション実行環境の一つのキューに対するイベントの入出力を監視することで得られる。その場合、イベントの入出力を監視するイベント監視処理が、Ｓ３０３のイベント発生処理とＳ３０６のイベント検出処理の間におかれることもある。イベント監視処理では、キューに対するイベントが入力又は出力されるタイミングでイベントの情報を出力する仕組みを持ち、Ｓ３０６のイベント検出では、このイベント監視処理から得られた情報を取得することによって全てのイベントを検知することができる。
【００３１】
次に、Ｓ３０６で検出したイベントがＧＵＩアプリを構成するコンポーネントの配置が変化したことを示す配置イベントであるか、マウスクリックなどの操作イベントであるかをＳ３０７において判定する。判定の結果、配置イベントであればＳ３１３に遷移する。また、操作イベントであればＳ３０８に遷移する。
【００３２】
Ｓ３０６で検知したイベントが配置イベントの場合、Ｓ３１３において、イベントから配置イベント情報を取得する。この配置イベント情報は配置されたＧＵＩコンポーネントや親コンポーネントの識別子であり、ＧＵＩコンポーネントが追加されたのか、削除されたのかといった情報も含まれる。
【００３３】
Ｓ３１３で得られた情報を用いてＧＵＩコンポーネントの配置順と親子関係から図５に示すような木構造の情報である配置情報をＳ３１４において更新し、Ｓ３０５に遷移して次のイベントを待つ。
【００３４】
一方、Ｓ３０６で検知したイベントが操作イベントの場合、Ｓ３０８においてイベントから操作イベント情報を取得する。操作イベント情報はＧＵＩに対して操作がなされたかという情報であり、イベントの種類又は操作の種類に応じて、クリック、ダブルクリック、ドラッグ、キー入力などがある。
【００３５】
更に、Ｓ３０９において、イベントを受信したＧＵＩコンポーネントであるリスナーの情報を取得する。Ｓ３１０において、上述のＳ３１４で更新された配置情報とＳ３０９で取得されたリスナーの情報を用いてＧＵＩコンポーネントのアドレス情報を生成する。
【００３６】
ここで、論理的な位置情報であるアドレス情報の生成方法について説明する。具体的には、先ず、図５において、ｆｒａｍｅ０を表示部１０５上に配置されたＧＵＩ画面の基底の画面とし、この画面を木構造上の基点ととらえ、このノード位置をノードレベル０とする。
【００３７】
次に、ＧＵＩコンポーネントの親子関係の子に相当する向きを図の下方にとり、それらをノードレベル１、２、…とする。また、各ＧＵＩコンポーネントの配置順を０から順に正の整数値を付与したものをコンポーネントＩＤとする。即ち、図５に示すｂｕｔｔｏｎ３は、ノードレベル１にあるｐａｎｅｌ１の上のノードレベル２の０オリジン（０を原点として０、１、２、…と数える方法）で３（０を原点として４番目）のコンポーネントである。
【００３８】
更に、ｐａｎｅｌ１は、ｆｒａｍｅ０の上にあるノードレベル１の０オリジンで１（０を原点として２番目）のコンポーネントである（アドレス情報：０．１）。ｆｒａｍｅ０は、ノードレベル０の０オリジンで０（０を原点として１番目）のコンポーネントである（アドレス情報：０）。
【００３９】
このようにして、図５に示すｂｕｔｔｏｎ３のアドレス情報は、ノードレベルとコンポーネントＩＤを組み合わせ、０．１．３のようになる。アドレス情報の表現形式としては、上述のノードレベルとコンポーネントＩＤを組み合わせるだけでなく、コンポーネント名の文字列情報を付加して構成することも可能であるが、本実施形態の説明においては、文字列情報は使わずに数値的な表現とする。
【００４０】
ここで図３に戻り、Ｓ３１１において、上述のアドレス情報を配置情報、イベント情報、リスナー登録情報と紐付け、操作記録を出力する。本実施形態では、上述の操作記録のフォーマットとして構造化言語のＸＭＬ（Extensible Markup Language）を用いることとする。そして、Ｓ３１２において、操作記録を続けるかを判定し、記録の終わりに達するまで、Ｓ３０５〜Ｓ３１１の処理を繰り返す。
【００４１】
ここで、操作記録プログラムのＳ３１１において出力される操作記録を、図６を用いて説明する。図６は、構造化言語のＸＭＬで表記した操作記録の一例を示す図である。図６に示すａｄｄ要素６０１及びｒｅｍｏｖｅ要素６０３は、Ｓ３１４において得られた配置情報である。このａｄｄ要素６０１は、ＧＵＩ画面上に追加されたＧＵＩコンポーネントに関する情報を表している。ｃｏｍｐｏｎｅｎｔ属性は、ＧＵＩコンポーネントのクラス名であり、ｎａｍｅ属性は、コンポーネントＩＤである。また、ｉｄ属性は、Ｓ３１０において得られたアドレス情報（論理的な位置情報）を表している。そして、ｒｅｍｏｖｅ要素６０３は、ＧＵＩ画面上から削除されたＧＵＩコンポーネントに関する情報を表している。尚、配置情報は、追加（ａｄｄ）・削除（ｒｅｍｏｖｅ）の他にも可視・不可視といった情報もあり得るが説明の簡単のために省略する。
【００４２】
また、図６に示す６０２は、Ｓ３０８及びＳ３０９において得られた操作イベント情報及びリスナー情報に関する情報である。ｅｖｅｎｔ要素は、操作部１０６で操作された表示部１０５上のＧＵＩ画面上に発生したイベントに関する情報を表し、ｔｙｐｅ属性は、発生したイベントの種類を表している。
【００４３】
ｃｏｍｐｏｎｅｎｔ属性は、ＧＵＩコンポーネントのクラス名であり、ｎａｍｅ属性は、ＧＵＩコンポーネントの内部オブジェクト名である。また、ｉｄ属性は、Ｓ３１０において得られたアドレス情報（論理的な位置情報）、ｔｉｍｅ属性は、イベントが発生した時刻を表している。
【００４４】
更に、Ｓ３０９において得られたリスナー情報は、ｌｉｓｔｅｎｅｒ属性、ＡｃｔｉｏｎＬｉｓｔｅｎｅｒ属性、ＩｔｅｍＬｉｓｔｅｎｅｒ属性、ＦｏｃｕｓＬｉｓｔｅｎｅｒ属性などで表記されている。ｌｉｓｔｅｎｅｒ属性は、リスナー登録されているＧＵＩコンポーネントのアドレス情報である。
【００４５】
図６示す６０２では、ｌｉｓｔｅｎｅｒ＝“０．１”であるため、図５よりｐａｎｅｌ１となり、ｐａｎｅｌ１にリスナー登録されていることが分かる。また、ＡｃｔｉｏｎＬｉｓｔｅｎｅｒ属性は、アクションリスナーが登録されているか否かの有無、ＩｔｅｍＬｉｓｔｅｎｅｒ属性は、アイテムリスナーが登録されているか否かの有無である。更に、ＦｏｃｕｓＬｉｓｔｅｎｅｒ属性は、フォーカスリスナーが登録されているか否かの有無を表している。
【００４６】
上述したように、操作記録システムにおけるテスト対象アプリケーション及び操作記録プログラムによれば、スクリーン座標系を使わずに、ＧＵＩコンポーネントベースの操作記録を取得することが可能になる。
【００４７】
次に、ＧＵＩアプリケーションのテストを自動化するための自動操作システムについて述べる。自動操作システムでは、テスト対象のＧＵＩアプリケーションに与える外部からの影響を少なくするためにも、リモート操作を行う構成が望ましい。そのため、システム構成として、図７に示すように、テスト対象アプリケーション及び自動操作プログラムがネットワークを介して遠隔システム上にあるような構成で実施した場合を例に挙げて説明する。
【００４８】
図７は、本実施形態における自動操作システムのシステム構成を示す図である。この例では、自動操作システムの中核をなす自動操作プログラムを次の２種類に分ける。即ち、テスト対象のＧＵＩアプリケーションが実行されるシステムを被試験装置と称し、被試験装置上にある自動操作プログラムを自動操作プログラムＡとする。
【００４９】
一方、被試験装置とネットワークを介して接続されているリモートシステムをリモート試験装置と称し、リモート試験装置上にある自動操作プログラムを自動操作プログラムＢとする。
【００５０】
図８及び図９は、本実施形態における自動操作システムの処理を示すフローチャートである。図８は、被試験装置における自動操作プログラムＡ及びテスト対象のＧＵＩアプリケーションに関する処理を示すフローチャートである。一方、図９は、リモート試験装置における自動操作プログラムＢの処理を示すフローチャートである。
【００５１】
先ず、テストを実行する前に、上述の操作記録システムで記録されたアプリケーションの操作記録を予め取得しておく。操作記録は、毎回取得する必要はなく、既に取得済みの場合は、それを利用する。
【００５２】
Ｓ８０１において、被試験装置上でテスト対象のＧＵＩアプリケーションを実行し、Ｓ８０２において、自動操作プログラムＡを実行する。一方、Ｓ９０１において、リモート試験装置上で自動操作プログラムＢを起動し、Ｓ９０２において、操作記録を読み出す。次に、Ｓ９０３において、自動操作プログラムＢは、操作記録を解釈して１操作分を選択し、Ｓ９０４において、そのアドレス情報（論理的な位置情報）とイベントの種類とを自動操作プログラムＡに送信する。
【００５３】
次に、Ｓ８０３において、自動操作プログラムＡは自動操作プログラムＢから自動操作のための操作指示情報であるアドレス情報及びイベントの種類に関する情報を受信する。ここで、自動操作プログラムＡは、被試験装置上で実行中のＧＵＩアプリケーションにおけるＧＵＩコンポーネントの配置情報を収集し、Ｓ８０４において自動操作プログラムＢから送られてきたアドレス情報と一致するＧＵＩコンポーネントを選択する。
【００５４】
次に、Ｓ８０５において、自動操作プログラムＡは、選択されたＧＵＩコンポーネントについて、可視・不可視の状態及び他のＧＵＩコンポーネントの重なり具合（Ｚオーダーなどの配置順）などを調べ、操作可能であるかを検証する。Ｓ８０６において、操作可能であると検証された場合にはＳ８０７へ進み、現在実行中のＧＵＩアプリケーションからＧＵＩコンポーネントのスクリーン座標系における位置を算出する。
【００５５】
ここで、ｂｕｔｔｏｎ２の配置が、操作記録を取得した時には、図１０に示す（Ａ）のように配置されていたが、自動操作プログラムを実行した時には、図１０に示す（Ｂ）のように変更になっていたとする。
【００５６】
本実施形態では、操作記録時のＧＵＩコンポーネントのアドレス情報に基づいて自動操作時に対応するＧＵＩコンポーネントのスクリーン座標上の実際の位置を算出している。そのため、ＧＵＩコンポーネントの位置が変更されていても自動操作が可能となる。
【００５７】
このように、ＧＵＩコンポーネントが記録時のスクリーン座標系の位置とは異なっていても、ＧＵＩコンポーネントの論理的な位置情報（ＩＤ）が等しいＧＵＩコンポーネントであれば操作対象とみなすことができる。
【００５８】
続いて、Ｓ８０８において、自動操作プログラムＡは、操作対象となるＧＵＩコンポーネントを、Ｓ８０７において算出されたスクリーン座標に対してＳ８０３で取得したイベントを発行することで操作を実行する。次に、Ｓ８０９において、ＧＵＩコンポーネントから発生したイベント情報を結果として自動操作プログラムＢへ送信する。
【００５９】
自動操作プログラムＢは、Ｓ９０５において、自動操作プログラムＡから送られてきた結果を受信し、Ｓ９０６において、その受信されたイベント情報と操作記録に記述されている情報とを比較する。そして、Ｓ９０７において、比較した結果が同じであるかを判定し、同じであれば、Ｓ９０８へ進み、比較結果を出力する。そして、Ｓ９０９において、操作の終わりでなければ、Ｓ９０３に戻り、上述の処理を繰り返すが、操作の終わりであれば、この処理を終了する。また、Ｓ９０７において、比較結果が異なっていれば、この処理を終了する。
【００６０】
尚、自動操作システムでは、ＧＵＩアプリケーションのテストであることから、テストのシナリオ通りに処理が進まなかった場合、Ｓ９０７において処理を中断する。これは、ＧＵＩアプリケーションのテストでは、シナリオ通りに処理が進まないまま、続きの処理を継続すると、あるべきチェックボックスがない場合や、ないはずのボタンが表示されることがある。そのため、一つの操作に失敗しただけでも、続きのテストシナリオの継続に支障をきたすことが多いため、自動操作システムでは処理を中断している。
【００６１】
しかし、操作の失敗に対する対処法としては、操作の結果を無視して継続させることも可能であるし、擬似的にあるべき結果を発生させることも可能である。また、操作が失敗した時に、ユーザ（テスター）に対して次の処理を対話式に問い合わせる方法もある。
【００６２】
また、本実施形態では、自動操作プログラムＢにおいて、操作記録の中から１操作分を自動操作プログラムＡへ送るようにしたが、複数の操作をまとめた１シナリオ単位として送っても良いし、全操作記録をまとめて一度に送っても良い。
【００６３】
また、操作と操作の時間的な間隔などのタイミングについては説明していないが、操作記録を取得したときに各操作が行われた時刻を記録しておけば、記録された時刻から操作と操作の間隔も同じくして自動操作させることも可能である。
【００６４】
次に、ＧＵＩアプリケーションの操作記録を静的に分析することによりＧＵＩコンポーネントの重なりを検出する記録分析システムを説明する。この記録分析システムは、図２に示す記録分析プログラムが含まれ、図１１は、記録分析プログラムの手順を示すフローチャートである。
【００６５】
先ず、図１２に示すようなＧＵＩ画面を持つアプリケーションを起動する。ここで、ＧＵＩコンポーネントのｂｕｔｔｏｎ３は、ｂｕｔｔｏｎ２の背面に完全に隠れており操作できない状態になっている。尚、図１２では、ｂｕｔｔｏｎ３が背面にあることを分かりやすくするため、説明の便宜上、背面に完全に隠さず右下へずらして描かれている。
【００６６】
ユーザがＧＵＩアプリケーションのテストを行うため、上述の操作記録システムを使ってＧＵＩ画面上にある全てのユーザ対話型のＧＵＩコンポーネントに対して必要な操作の全てを網羅的に行う。若しくは、ユーザが操作するのではなく、ＧＵＩ画面全体を網羅的にクリックするツールを利用して自動操作を行わせても良い。その場合、操作の最小単位である１ドット単位で自動的にクリック操作を行わせることでＧＵＩ画面全体を網羅することができる。
【００６７】
ここでは、ユーザがＧＵＩ画面を操作する方法をとったとして、ユーザがｂｕｔｔｏｎ０、ｂｕｔｔｏｎ１、ｂｕｔｔｏｎ２をクリック操作する。ｂｕｔｔｏｎ３は、ｂｕｔｔｏｎ２の背面に完全に隠れているので、ユーザはｂｕｔｔｏｎ３を目視で確認できないため操作できない。
【００６８】
上述の操作の結果、図１３に示すようなＸＭＬで記述された情報を得ることができる。アプリケーションが生成したＧＵＩコンポーネントがａｄｄ要素１４０１として記述され、ユーザ操作がｅｖｅｎｔ要素１４０２として記述されている。
【００６９】
説明を簡単にするため、ａｄｄ要素１４０１は、ユーザ対話側のＧＵＩコンポーネントが配置された時の情報であり、ａｄｄ要素１４０１が生成された時は、ＧＵＩコンポーネントが配置（コンテナへの追加）及び可視化されて操作可能な状態であるとする。また、ｅｖｅｎｔ要素１４０２は、ユーザ操作時のＧＵＩコンポーネントの情報とする。
【００７０】
ここで、記録分析プログラムは、Ｓ１２０１において、上述した操作記録を読み取り、Ｓ１２０２及びＳ１２０３において、ａｄｄ要素１４０１及びｅｖｅｎｔ要素１４０２からアドレス情報を取得する。そして、Ｓ１２０４において、これら２つのアドレス情報を比較する。
【００７１】
比較の結果、ＧＵＩコンポーネントのｂｕｔｔｏｎ３は、ａｄｄ要素１４０１から取り出されたアドレス情報内には、０．１．３として記録されており、確かにＧＵＩ画面上に生成されていることがわかる。しかし、ユーザ操作の記録であるｅｖｅｎｔ要素１４０２には、０．１．３のアドレス情報の記述がない。そのため、このｂｕｔｔｏｎ３は、操作されていないＧＵＩコンポーネントであることがわかる。
【００７２】
操作されなかった原因は、そもそも不要なＧＵＩコンポーネントであるか、必要な処理が未実装か、若しくは、ユーザの操作漏れなどが考えられるため、Ｓ１２０５において、その結果を出力する。
【００７３】
多くのユーザ対話型のＧＵＩコンポーネントは、操作イベントを受け取り、イベントの種類に応じて何らかの処理を実行する仕組みになっている。そのため、ＧＵＩ画面を網羅的に操作しているにも関わらず操作イベントが発生しないＧＵＩコンポーネントは、上述のような問題を抱えている可能性がある。
【００７４】
以上のように、本実施形態による操作記録はＧＵＩコンポーネントの重なりを検出する分析にも利用できる。
【００７５】
続いて、ＧＵＩアプリケーションの操作記録を静的に分析することによりリスナー登録されていないコンポーネントを検出する記録分析システム（静的解析）を説明する。この記録分析システム（静的解析）は、図２に示す記録分析プログラムが含まれ、図１４は、記録分析プログラムの手順を示すフローチャートである。
【００７６】
先ず、図１２に示すようなＧＵＩ画面を持つアプリケーションを起動する。ここで、ユーザがＧＵＩアプリケーションのテストを行うため、上述した操作記録システムを使ってＧＵＩ画面上にある全てのユーザ対話型のＧＵＩコンポーネントに対して必要な操作の全てを網羅的に行う。若しくは、ユーザが操作するのではなく、ＧＵＩ画面全体を網羅的にクリックするツールを利用して自動操作を行わせても良い。この場合、操作の最小単位である１ドット単位で自動的にクリック操作を行わせることでＧＵＩ画面全体を網羅することができる。
【００７７】
操作の結果、図１５に示すようなＸＭＬで記述された情報が得られる。尚、ａｄｄ要素１６０１は、図１３に示すａｄｄ要素１４０１と同じである。ここで、リスナー情報は、ｅｖｅｎｔ要素１６０２の中のＡｃｔｉｏｎＬｉｓｔｅｎｅｒ属性、ＩｔｅｍＬｉｓｔｅｎｅｒ属性、ＦｏｃｕｓＬｉｓｔｅｎｅｒ属性として記述されている。そして、ＡｃｔｉｏｎＬｉｓｔｅｎｅｒ属性の内容は、リスナーが受信するようになっていれば、ｔｒｕｅとなる。受信するようになっていなければ、ｆａｌｓｅとなる。また同様に、ＩｔｅｍＬｉｓｔｅｎｅｒ属性やＦｏｃｕｓＬｉｓｔｅｎｅｒ属性が記録されている。
【００７８】
Ｓ１５０１において、記録分析プログラムは、操作記録を読み込み、Ｓ１５０２では、ｅｖｅｎｔ要素１６０２からｃｏｍｐｏｎｅｎｔ属性の情報を取得し、Ｓ１５０３では、ｅｖｅｎｔ要素１６０２からリスナー情報を取得する。図１６は、ＧＵＩコンポーネント種別の必須リスナーのテーブルを示す図である。ここでリスナーとは、ＧＵＩアプリケーション内の種々のイベントを処理するための仕組みであり、ユーザ対話型のＧＵＩコンポーネントには操作イベントに応じたリスナーが登録されている必要がある。
【００７９】
必須リスナーとは、特にユーザ対話型のＧＵＩコンポーネントにおいて、その種類毎に各機能を実現するために最低限必要とするリスナーのことである。ＧＵＩアプリケーションは、対応するリスナーを登録することにより操作イベントを検知することができる。
【００８０】
次に、Ｓ１５０４において、Ｓ１５０２で取得したｃｏｍｐｏｎｅｎｔ属性の情報を図１６に示すテーブルのComponent Class列から探し、対応するListener Nameを取得する。そして、Ｓ１５０５において、取得されたListener NameがＳ１５０３で取得したｅｖｅｎｔ要素１６０２においてｔｒｕｅとなっているか判定する。
【００８１】
必須リスナーが登録されていないＧＵＩコンポーネントは、操作イベントのリスナーがいないため、操作しても何の処理もされないので、Ｓ１５０６において、その結果を出力する。例えば、図１５に示すｂｕｔｔｏｎ１は、ｃｏｍｐｏｎｅｎｔ属性からｊａｖａ．ａｗｔ．Ｂｕｔｔｏｎという種類のコンポーネントであることが分かる。更に、図１６を参照すると、対応するリスナーとして、必ずＡｃｔｉｏｎＬｉｓｔｅｎｅｒが登録されている必要があることがわかる。
【００８２】
しかし、図１５に示すＡｃｔｉｏｎＬｉｓｔｅｎｅｒ属性の内容は、ｆａｌｓｅ（１６０３）であり、リスナー登録がされていないことがわかる。従って、そもそも不要なＧＵＩコンポーネントであるか、必要な処理が未実装などの理由が考えられるため、その結果を出力する。
【００８３】
これにより、ユーザはその出力結果に基づいて、不要なＧＵＩコンポーネントであればプログラム中から削除することができるし、また必要な処理が未実装であれば、その処理を実装することができる。
【００８４】
操作記録システム（静的解析）によれば、ＧＵＩコンポーネントのリスナー登録されていないコンポーネントを検出する分析にも利用できる。
【００８５】
本実施形態によれば、ＧＵＩアプリケーションのテスト自動化システムにおいて、スクリーン座標系ではなくＧＵＩコンポーネントに基づく記録方法を用いることにより、画面サイズやデザイン変更に柔軟に対応可能な操作記録を得ることができる。そのため、画面サイズやデザイン変更を行う際に、操作記録を取り直す手間やコストが低減される。また、前記記録方法により取得した情報によりＧＵＩプログラムの分析を容易せしめる効果がある。更に、操作記録を分析することによりＧＵＩプログラムの不具合を発見することが可能になる。
【００８６】
［他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2012018583.tif 000003
【図２】
2012018583.tif 000004
【図３】
2012018583.tif 000005
【図４】
2012018583.tif 000006
【図５】
2012018583.tif 000007
【図６】
2012018583.tif 000008
【図７】
2012018583.tif 000009
【図８】
2012018583.tif 000010
【図９】
2012018583.tif 000011
【図１０】
2012018583.tif 000012
【図１１】
2012018583.tif 000013
【図１２】
2012018583.tif 000014
【図１３】
2012018583.tif 000015
【図１４】
2012018583.tif 000016
【図１５】
2012018583.tif 000017
【図１６】
2012018583.tif 000018