JP2021009605A - ソフトウェアの操作シナリオの生成を支援するプログラム、方法およびソフトウェアの操作シナリオの生成を支援する装置 - Google Patents

Abstract

【課題】効率的に可読性およびメンテナンス性の高い操作シナリオを生成する技術を提供する。【解決手段】ソフトウェアの操作コードを生成するプログラムは、コンピューターに、１以上のコントロールを含み、コンピューターのモニターに表示されているＧＵＩ（Graphical User Interface）の情報を取得するステップ（Ｓ１２３０）と、１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含むＧＵＩドライバーを選択するステップ（Ｓ１２４０）と、取得したＧＵＩの情報と、１以上のコントロールドライバーとに基づいて、１以上のコントロールの中から、キャプチャー対象となるコントロールを選択するステップ（Ｓ１２５０）と、選択されたコントロールが受け付けた操作をキャプチャーするステップ（Ｓ１２６０）と、キャプチャーの結果に基づいて、１以上のコントロールドライバーのいずれかに対応する操作コードを生成するステップ（Ｓ１２７０，Ｓ１２８０）とを実行させる。【選択図】図１２

Description

本開示は、ソフトウェアの操作シナリオの生成に関し、より特定的には、グラフィカルユーザーインターフェイスの操作シナリオの生成を支援する技術に関する。

ＰＣ（Personal Computer）、スマートフォンおよびタブレット等の機器には、多くのアプリケーションがインストールされる。これらの機器にインストールされるアプリケーションは、所謂ネイティブアプリケーションと呼ばれる。これらのネイティブアプリケーションは、一般的に、ＧＵＩ（Graphical User Interface）を含む。ＧＵＩは、入力フォームやボタン等を有し、視覚的および直感的に操作することができるユーザーインターフェイスである。

さらに、近年、ネットワークの高速化およびクラウドの発展等により、ウェブアプリケーションが多く使用されている。ウェブアプリケーションにおいて、サーバーは、ウェブアプリケーションの画面をユーザーの持つ機器に配信する。ユーザーは、配信された画面を操作することで、ウェブアプリケーションの機能を使用することができる。このようなウェブアプリケーションの画面は、ブラウザによって視覚的に表示されることが多い。

上記のように、近年、多くのソフトウェアは、ＧＵＩを含むことが多い。これ以降の説明では、ＧＵＩを含むネイティブアプリケーションおよびウェブアプリケーションを総称して、「ＧＵＩアプリケーション」と呼ぶ。プログラマーは、開発したＧＵＩアプリケーションおよびＧＵＩアプリケーションの操作に基づくアプリケーションの内部動作等をテストする必要がある。

ＧＵＩアプリケーションの自動テスト手法には、大きく分けて２種類あり、１つ目は、プログラマーが手書きの操作シナリオを用意する方法である。操作シナリオとは、複数のアプリケーションの操作コードを順次実行する一連の処理を指す。以降の説明では、アプリケーションのテストに使用される操作コードおよび操作シナリオをそれぞれ「テストコード」および「テストシナリオ」と呼ぶ。手書きのテストシナリオを作成する方法は、可読性の高いテストシナリオを生成できるという利点があるが、その反面、テストシナリオを作成できるプログラマーが限られるという問題があった。２つ目は、ＧＵＩ操作のキャプチャーリプレイソフトを使用する方法である。この方法は、手書きのテストコードを用意する方法と比較して、作業難易度は低くなるという利点はあるが、その反面、キャプチャーリプレイソフトが生成したテストコードは可読性が低く、メンテナンス性が低いという問題があった。そのため、より効率的なＧＵＩのテスト手法が求められている。

その他にも、近年、ＩＴ（Information Technology）業務の効率化が加速している。そのため、従来、職員がＧＵＩアプリケーションを使ってデータの入出力をしていた業務の自動化、所謂ＲＰＡ（Robotic Process Automation）が進んでいる。ＲＰＡにおいても、ＧＵＩアプリケーションの操作シナリオを効率よく作成する手段が求められている。

ＧＵＩの操作シナリオの作成手法に関し、例えば、特開２０１１−０４８７１４号公報（特許文献１）は、「グラフィカル・ユーザ・インターフェースの指定状態を検出するコマンドを付加した共通様式のシナリオを、グラフィカル・ユーザ・インターフェースに応じた様式のコマンドに変更して、指示するステップと、グラフィカル・ユーザ・インターフェースの状態が指定状態であるか判断するステップと、判断するステップで、グラフィカル・ユーザ・インターフェースが指定状態にあるとコマンドを実行するステップとを含む」テスト支援方法を開示している（［要約］参照）。

特開２０１１−０４８７１４号公報

特許文献１に開示された技術によると、効率的に可読性およびメンテナンス性の高い操作シナリオを生成することができない。したがって、効率的に可読性およびメンテナンス性の高い操作シナリオを生成する技術が必要とされている。

本開示は、上記のような背景に鑑みてなされたものであって、ある局面における目的は、効率的に可読性およびメンテナンス性の高い操作シナリオを生成する技術を提供することにある。

ある実施の形態に従うと、コンピューターを制御するプログラムが提供される。このプログラムはコンピューターに、１以上のコントロールを含み、コンピューターのモニターに表示されているＧＵＩ（Graphical User Interface）の情報を取得するステップと、１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含むＧＵＩドライバーを選択するステップと、取得したＧＵＩの情報と、１以上のコントロールドライバーとに基づいて、１以上のコントロールの中から、キャプチャー対象となるコントロールを選択するステップと、選択されたコントロールが受け付けた操作をキャプチャーするステップと、キャプチャーの結果に基づいて、１以上のコントロールドライバーのいずれかに対応する操作コードを生成するステップとを実行させる。

ある局面において、１以上のコントロールドライバーの各々は、１以上のコントロールの各々を外部から操作するクラスである。ＧＵＩドライバーは、１以上のコントロールドライバーをプロパティとして含むクラスであり、ＧＵＩの情報に含まれる１以上のコントロールの各々を指定する情報と、１以上のコントロールドライバーの各々とを関連付けている。操作コードは、１以上のコントロールドライバーのいずれかのメソッドまたはプロパティを含む。

ある局面において、１以上のコントロールドライバーは、ユーザーにより定義されたカスタムコントロールドライバーを含む。

ある局面において、プログラムはコンピューターに、１以上のコントロールドライバーを含む外部プログラムを読み込むステップをさらに実行させる。

ある局面において、プログラムはコンピューターに、１以上のコントロールドライバーの各々に対応する操作コード生成プログラムを呼び出すステップと、操作コード生成プログラムから、ＧＵＩのイベント発生時またはコントロールに関連するデータの変化時に、操作コード生成プログラムが生成する操作コードを受信するステップとをさらに実行させる。

ある局面において、プログラムはコンピューターに、操作コードを実行した場合の出力結果を確認するための確認コードを生成するステップをさらに実行させる。確認コードは、１以上のコントロールドライバーのいずれかのメソッドまたはプロパティを含む。

他の実施の形態に従うと、ソフトウェアの操作コードを生成する方法が提供される。この方法は、１以上のコントロールを含み、コンピューターのモニターに表示されているＧＵＩの情報を取得するステップと、１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含むＧＵＩドライバーを選択するステップと、取得したＧＵＩの情報と、１以上のコントロールドライバーとに基づいて、１以上のコントロールの中から、キャプチャー対象となるコントロールを選択するステップと、選択されたコントロールが受け付けた操作をキャプチャーするステップと、キャプチャーの結果に基づいて、１以上のコントロールドライバーのいずれかに対応する操作コードを生成するステップとを含む。

他の実施の形態に従うと、ソフトウェアの操作コードを生成する装置が提供される。この装置は、ユーザーからの操作を受け付ける入力部と、ＧＵＩを表示する表示部と、１以上のＧＵＩドライバーを格納するメモリーと、制御部とを備える。制御部は、表示部に表示されている１以上のコントロールを含むＧＵＩの情報を取得し、メモリーを参照し、１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含むＧＵＩドライバーを選択し、取得したＧＵＩの情報と、１以上のコントロールドライバーとに基づいて、１以上のコントロールの中から、キャプチャー対象となるコントロールを選択し、選択されたコントロールが入力部から受け付けた操作をキャプチャーし、キャプチャーの結果に基づいて、１以上のコントロールドライバーのいずれかに対応する操作コードを生成する。

本技術によれば、効率的に可読性およびメンテナンス性の高いソフトウェアの操作シナリオを生成することが可能である。

この発明の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解されるこの発明に関する次の詳細な説明から明らかとなるであろう。

ある実施の形態に従う自動化支援プログラムによるテストシナリオ生成の概要の一例を示す図である。 装置１００のハードウェア構成の一例を示す図である。 ある実施の形態に従う自動化支援プログラムの構成の一例を示す図である。 ＰＣで動作するネイティブアプリケーション４００の一例を示す図である。 ＧＵＩドライバー３０１の第１の例を示す図である。 ウェブアプリケーションのＧＵＩ６００の一例を示す図である。 ＧＵＩドライバー３０１の第２の例を示す図である。 キャプチャージェネレイター３０３の動作概要の一例を示す図である。 テストシナリオの一例を示す図である。 生成されたテストシナリオ１００１をエディタ等に貼り付けた例を示す図である。 自動化支援プログラム３００の通信処理の手順の一例を示す図である。 自動化支援プログラム３００のテストシナリオ生成の処理手順の一例を示す図である。

以下、図面を参照しつつ、本開示に係る技術思想の実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

以降の説明では、本実施の形態に従う自動化支援プログラムによるＧＵＩアプリケーションのテストコードおよびテストシナリオの作成手順について説明する。ＲＰＡ用（ＧＵＩアプリケーションの操作自動化用）の操作コードおよび操作シナリオに関しても、検証用コードが不要な点を除けば、同様の手順で作成可能である。

図１は、本実施の形態に従う自動化支援プログラムによるテストシナリオ生成の概要の一例を示す図である。本実施の形態に従う自動化支援プログラムは、アプリケーションに含まれるＧＵＩのテストを支援するためのものであり、従来よりも少ない工数で可読性およびメンテナンス性に優れたテストシナリオを生成し得る。

自動化支援プログラムは、単体で動作してもよいし、他のソフトウェアと連携して動作してもよい。一例として、他のソフトウェアは、アプリケーション開発用のエディタまたは統合開発環境（以下、ＩＤＥ（Integrated Development Environment）と呼ぶ）であってもよい。ある局面において、自動化支援プログラムは、ウェブアプリケーションとして提供されてもよい。以降の説明では、自動化支援プログラムがＩＤＥと連携してアプリケーション１０２のテストシナリオを生成する例を説明する。

装置１００は、自動化支援プログラムを実行する。ある局面において、装置１００は、ＰＣ、ワークステーション、タブレットまたはスマートフォン等であってもよい。他の局面において、装置１００は、サーバーまたはクラウド上で仮想的に構成された装置等であってもよい。

ＩＤＥ１０１は、エディタ、デバッガおよびコンパイラ等のアプリケーション開発に必要な機能を備えた開発用ソフトウェアである。ＩＤＥ１０１は、プラグインまたはエクステンション等と呼ばれるソフトウェアまたはファイルを読み込むことにより、機能を拡張することができる。本実施の形態においては、自動化支援プログラムは、プラグインとしてＩＤＥ１０１と連携するものとして説明するが、自動化支援プログラムの実現方法はこれに限られない。ある局面において、自動化支援プログラムは、ＩＤＥ１０１とは別に起動されるソフトウェアであってもよいし、自動化支援プログラムおよびＩＤＥ１０１が１つのアプリケーションとして提供されてもよい。

アプリケーション１０２は、テスト対象となる事前に開発されたアプリケーションであり、ＧＵＩを含む。アプリケーション１０２は、装置１００によりテスト実行される。ある局面において、アプリケーション１０２は、ＰＣ等で動作するスタンドアロンのネイティブアプリケーションであってもよい。他の局面において、アプリケーション１０２は、装置１００上でエミュレートされたスマートフォンまたはタブレット等の機器上で動作するＧＵＩを含むネイティブアプリケーションであってもよい。他の局面において、アプリケーション１０２は、ブラウザ等のＨＴＭＬ（Hyper Text Markup Language）を表示するソフトウェア上で実行されるウェブアプリケーションのフロント部分であってもよい。

アプリケーション１０２のＧＵＩは、操作可能なテキストボックス、ボタンおよびプルダウン等の各種部品を含む。本実施の形態において、これらの部品をコントロールと呼ぶ。ある局面において、コントロールは、ウェブアプリケーションのＨＴＭＬで表現されたテキストボックス、ボタンおよびプルダウン等の各種部品も包含する。

アプリケーション１０２は、上記のコントロールを貼り付けたパネルとして表現されることが多く、これらのコントロールを貼り付ける枠の役割を果たす部品をウィンドウと呼ぶこともある。これらの枠となる部品は、入れ子型に配置することもできる。アプリケーション１０２は、これらコントロールと、ウィンドウ等の枠となる部品との組み合わせによって実現され得る。ウェブアプリケーションは、ＨＴＭＬのタグによって構成されるウィンドウ等の枠に相当する部品を含み得る。

アプリケーション１０２のテストの手順は、大きく分けて、ドライバーの作成、キャプチャー、テストシナリオの実行の３つを含む。以下に、これらの３つの手順について概要を説明する。

（手順１ ドライバーの作成）
ここではアプリケーション１０２を操作するソフトウェアをドライバーと呼ぶ。ある局面において、ドライバーは、なんらかのプログラミング言語で定義されたクラスであってもよい。より具体的には、ドライバーは、各コントロールに対応するコントロールドライバーと、各ウィンドウまたは各ＧＵＩに対応するＧＵＩドライバー（ウィンドウドライバー）とを含む。以下、一例として、ドライバーは、クラスであるものとして説明する。

最初に、ユーザーは、アプリケーション１０２のＧＵＩに対応するＧＵＩドライバーを用意または定義する必要がある。自動化支援プログラムは、ＧＵＩドライバー作成のための半自動生成機能または完全な自動生成機能を提供し得る。

コントロールドライバーは、アプリケーション１０２のＧＵＩに含まれる個別のコントロールに対応する。より具体的には、コントロールドライバーは、他のアプリケーションのコントロールを外部から操作することができる。コントロールドライバーは、内部に当該コントロールドライバーに対応するコントロールを操作するためのメソッドまたはプロパティを含む。自動化支援プログラムは、コントロールドライバーのメソッドまたはプロパティを呼び出すことで、アプリケーション１０２の各コントロールを外部から操作することができる。一例として、ボタンのコントロールドライバーであれば、他のアプリケーション内のボタンを操作することができる。ボタン以外にも、テキストボックス、ラベル、チェックボックスおよびラジオボタン等の任意のコントロールに対応する複数のコントロールドライバーが定義され得る。

ある局面において、特定のＯＳ上で動作するアプリケーションに使用され得る全てまたは一部のコントロールの各々に対応する複数のコントロールドライバーがそれぞれ予めクラスとして定義されていてもよい。他の局面において、ウェブアプリケーションに使用され得る全てまたは一部のコントロールの各々に対応する複数のコントロールドライバーのそれぞれが予めクラスとして定義されていてもよい。

ＧＵＩドライバーは、テスト対象となるアプリケーションの個別のＧＵＩに対応し得る。一例として、アプリケーション１０２が、操作画面としてＧＵＩ（１）、ＧＵＩ（２）およびＧＵＩ（３）を含む場合、ＧＵＩ（１）、ＧＵＩ（２）およびＧＵＩ（３）の各々に対応したＧＵＩドライバーが定義され得る。

ＧＵＩドライバーは、当該ＧＵＩドライバーに対応するＧＵＩが含む１以上のコントロールに対応する１以上のコントロールドライバーをプロパティもしくはメソッドとして含み得る。ＧＵＩドライバーは、コントロールドライバーをクラスのプロパティとして含み得る。一例として、ＧＵＩドライバー（Ａ）は、ＧＵＩ（Ａ）に対応しているとする。ＧＵＩ（Ａ）が、コントロール（Ｘ），（Ｙ），（Ｚ）を含む場合、ＧＵＩドライバー（Ａ）は、コントロール（Ｘ），（Ｙ），（Ｚ）にそれぞれ対応するコントロールドライバー（Ｘ），（Ｙ），（Ｚ）をプロパティとして含み得る。ＧＵＩドライバー（Ａ）は、これらのコントロールドライバー（Ｘ）〜（Ｚ）を含むことにより、ＧＵＩ（Ａ）に含まれる各種コントロール（Ｘ）〜（Ｚ）を操作することが可能になる。さらに、ＧＵＩドライバーは、他のＧＵＩドライバーをプロパティもしくはメソッドとして含み得る。ある局面において、テスト対象のＧＵＩ（Ｍ）の画面の一部（Ｎ）に対応するＧＵＩドライバー（Ｎ）があるとする。この場合、ＧＵＩ（Ｍ）に対応するＧＵＩドライバー（Ｍ）は、ＧＵＩドライバー（Ｎ）を、プロパティもしくはメソッドとして含み得る。すなわち、画面全体に対応するＧＵＩドライバー（Ｍ）は、画面の一部に対応するＧＵＩドライバー（Ｎ）を含み得る。

ＧＵＩドライバーは、対応するＧＵＩが含む全てのコントロールの各々に対応するコントロールドライバーを含む必要は無く、ＧＵＩが含む一部のコントロールに対応するコントロールドライバーのみを含んでいてもよい。一例として、上記のＧＵＩドライバー（Ａ）は、コントロールドライバー（Ｘ）〜（Ｚ）をプロパティとして含み得るが、その一部であるコントロールドライバー（Ｘ）のみを含んでいてもよい。

さらに、ＧＵＩドライバーは、アプリケーション１０２の各コントロールをそれぞれ指定するための情報と、各コントロールドライバーとをそれぞれ関連付けている。一例として、Microsoft（商標登録）社のＷＰＦ（Windows Presentation Foundation）機能を使ったアプリケーション１０２であれば、ＷＰＦに関する情報が、各コントロールをそれぞれ指定するための情報として使用され得る。ウェブアプリケーションであれば、ＨＴＭＬタグに指定されるＩＤ（Identifier）等が各コントロールをそれぞれ指定するための情報として使用され得る。

ある局面において、各コントロールをそれぞれ指定するための情報は、各コントロールドライバーに引数として渡されてもよいが、関連付け方法はこれに限られない。各コントロールをそれぞれ指定するための情報と、各コントロールドライバーとの関連付けは、任意の方法によって実行され得る。

上記のように、ＧＵＩドライバーは、各コントロールをそれぞれ指定するための情報と、各コントロールドライバーとをそれぞれ関連付けることで、「各コントロールをそれぞれ指定するための情報」を隠蔽し得る。後述するテストコードは、ＧＵＩドライバーに含まれるコントロールドライバーのメソッドまたはプロパティを含む。そのため、ＧＵＩの仕様に変更が発生した場合でも、ユーザーはＧＵＩドライバー内部の記載を変更するだけでテストコードを使用することができ、テストコードは極めて高いメンテナンス性を有する。

さらに、コントロールドライバーは、「コントロールを直接操作する処理」をメソッドとして隠蔽し得る。ユーザーは、コントロールドライバーのインスタンス名、メソッド名等を自由に定義できる。そのため、コントロールドライバーのメソッドまたはプロパティを含むテストコードは、極めて高い可読性を有する。

ある局面において、コントロールドライバーは、ライブラリまたは外部リンクに含めて再利用可能な形式で提供され得る。ユーザーは、これらの提供されるコントロールドライバーを利用して、アプリケーション１０２のＧＵＩに対応するＧＵＩドライバーを定義し得る。さらに、ユーザーは、独自のコントロールドライバーを定義し得る。ユーザーは、任意のコントロールに対して、自身で定義したメソッドを含むコントロールドライバーを定義することができる。コントロールドライバーは、これらのユーザー定義のカスタムコントロールドライバーを含むことにより、任意のコントロールを操作することができる。

他の局面において、自動化支援プログラムは、各コントロールをそれぞれ指定するための情報と、予め用意されたコントロールドライバーとに基づいて、ＧＵＩドライバーを自動で生成してもよい。

自動化支援プログラムは、各コントロールをそれぞれ指定するための情報を取得するために、例えば、Ｃｏｄｅｅｒ社が提供するライブラリＦｒｉｅｎｄｌｙを用いてもよいし、Ｓｅｌｅｎｉｕｍを用いてもよい。自動化支援プログラムは、これらのソフトウェアを内部に組み込んでもよいし、これらのソフトウェアと連携してもよい。ユーザーは、生成されたＧＵＩドライバーをそのまま使用してもよいし、編集してもよい。具体的なＧＵＩ、コントロールドライバーおよびＧＵＩドライバーの例は後述する。

（手順２ キャプチャー）
次に、ユーザーは、アプリケーション１０２のＧＵＩをテストするためのテストシナリオを用意する。自動化支援プログラムは、テストシナリオ作成のためのキャプチャー機能を提供する。ここでのキャプチャーとは、テスト対象のＧＵＩの各コントロールの状態を取得することである。状態とは、イベントの発生または各コントロールに関連するデータ（入力フォームに入力された値等）の変化等を含み得る。

上述したように、テストシナリオは、テストコードを含む。テストコードは、アプリケーション１０２のＧＵＩに含まれるコントロールの操作および検証コードを定義する。テストシナリオは、これらコントロールの操作および検証コードを定義するテストコード以外にも、ユーザー定義の任意のコードを含み得る。一例として、テストコード（Ａ），（Ｂ），（Ｃ）を順番に実行するテストシナリオ（Ｔ１）があるとする。テストコード（Ａ）は、テキストボックス（Ａ）に何らかの文字列を書き込む機能を有する。テストコード（Ｂ）は、テキストボックス（Ｂ）にＥメールアドレスを書き込む機能を有する。テストコード（Ｃ）は、送信ボタン（Ｃ）を押す機能を有する。この場合、テストシナリオ（Ｔ１）は、アプリケーション１０２のＧＵＩに対して、メール本文と宛先アドレスとを設定して、メールを送信することになる。

ユーザーは、これらのテストコード（Ａ）〜（Ｃ）を含むテストシナリオ（Ｔ１）を手動で書くことも可能であるが、手動でテストシナリオを作成した場合、プログラマーの作業工数が増えてしまう。そこで、自動化支援プログラムは、アプリケーション１０２のＧＵＩの操作をキャプチャーし、当該操作に対応するテストコードを生成する機能を提供する。

ある局面において、自動化支援プログラムは、アプリケーション１０２のＧＵＩの操作をキャプチャーするとき、ＦｒｉｅｎｄｌｙまたはＳｅｌｅｎｉｕｍ等を用いて、操作されたコントロールに関する情報を取得してもよい。

自動化支援プログラムは、キャプチャー結果に基づいて、コントロールドライバーに基づくテストコードを生成する。より具体的には、コントロールドライバーのクラスに含まれるメソッドまたはプロパティを呼び出すテストコードを生成する。一例として、アプリケーション１０２のＧＵＩに含まれるボタンが押された場合、自動化支援プログラムは、ボタンを押すテストコードを生成する。このテストコードは、「ボタンに対応するコントロールドライバーのクラス」が有する「ボタンを押す操作を実行するメソッド」を呼び出す。

上記のように、自動化支援プログラムが生成するテストコードは、コントロールドライバー（クラス）のメソッドまたはプロパティを含むため、従来のキャプチャーリプレイソフトの生成するテストコードと比較して、極めて高い可読性を有する。さらに、ＧＵＩドライバーが、各コントロールをそれぞれ指定するための情報を隠蔽しているため、テストコードは、高いメンテナンス性も有する。自動化支援プログラムは、一連のキャプチャー結果に基づいて生成された複数のテストコードを含むテストシナリオをユーザーに提供する。具体的なテストコードの例は後述する。

（手順３ テストシナリオの実行）
次に、ユーザーは、装置１００にテストシナリオを実行させて、アプリケーション１０２の動作を確認する。装置１００は、手書きのテストシナリオと同様に、自動化支援プログラムによって生成されたテストシナリオを実行することができる。

ある局面において、自動化支援プログラムによって生成されたテストシナリオは、プログラミング用のエディタ、ＩＤＥまたはコンソールアプリケーション等によって実行されてもよい。他の局面において、自動化支援プログラムが、テストシナリオを実行してもよい。

図２は、装置１００のハードウェア構成の一例を示す図である。図２を参照して、装置１００のハードウェア構成と、各構成の機能とについて説明する。装置１００は、上述したとおり、例えば、ＰＣまたはワークステーション等である。ユーザーは、装置１００を用いて、アプリケーション１０２のテストを実行する。

装置１００は、制御装置２０１と、ＲＡＭ（Random Access Memory）２０２と、入力インターフェイス２０３と、出力インターフェイス２０４と、外部機器インターフェイス２０５と、通信インターフェイス２０６と、記憶装置２０７とを含む。

制御装置２０１は、装置１００を制御し、自動化支援プログラム、アプリケーション１０２および各種プログラミングツール等を実行する。制御装置２０１は、例えば、少なくとも１つの集積回路によって構成される。集積回路は、例えば、少なくとも１つのＣＰＵ（Central Processing Unit）、少なくとも１つのＡＳＩＣ（Application Specific Integrated Circuit）、少なくとも１つのＦＰＧＡ（Field-Programmable Gate Array）、またはこれらの組み合わせ等によって構成される。

ＲＡＭ２０２は、制御装置２０１によって実行されるプログラムと、制御装置２０１によって参照されるデータとを格納する。ある局面において、ＤＲＡＭ（Dynamic Random Access Memory）またはＳＲＡＭ（Static Random Access Memory）が、ＲＡＭ２０２として使用されてもよい。制御装置２０１は、アプリケーション１０２、自動化支援プログラムおよびその他のプログラミングツール等をＲＡＭ２０２から読み込んで実行する。

入力インターフェイス２０３は、キーボード、マウスまたはゲームパッド等の任意の入力装置に接続され得る。ある局面において、ＵＳＢ（Universal Serial Bus）端子、ＰＳ／２端子およびＢｌｕｅｔｏｏｔｈ（登録商標）モジュール等が入力インターフェイス２０３として使用されてもよい。ユーザーは、入力インターフェイス２０３を介して、自動化支援プログラムに対するキャプチャー実行命令等を装置１００に入力する。

出力インターフェイス２０４は、ブラウン管ディスプレイ、液晶ディスプレイまたは有機ＥＬ（electro-luminescence）ディスプレイ等の任意の出力装置に接続され得る。ある局面において、ＵＳＢ（Universal Serial Bus）端子、Ｄ−ｓｕｂ端子、ＤＶＩ端子およびＨＤＭＩ（登録商標）端子等が出力インターフェイス２０４として使用されてもよい。ユーザーは、出力インターフェイスを介して、液晶ディスプレイ等に表示されたアプリケーション１０２およびテストシナリオの実行結果等を確認することで、アプリケーション１０２の動作確認を行う。

外部機器インターフェイス２０５は、プリンター、スキャナーおよび外付けＨＤＤ（Hard Disk Drive）等の任意の外部機器に接続され得る。ある局面において、ＵＳＢ（Universal Serial Bus）端子等が外部機器インターフェイス２０５として使用されてもよい。

通信インターフェイス２０６は、有線または無線のネットワーク機器と接続される。ある局面において、有線ＬＡＮ（Local Area Network）ポートおよびＷｉ-Ｆｉ（登録商標）モジュール等が通信インターフェイス２０６として使用されてもよい。

記憶装置２０７は、不揮発性の記憶媒体であり、装置１００の電源が切れた後もデータを保存しておくことができる。記憶装置２０７は、制御装置２０１によって実行されるプログラムと、制御装置２０１によって参照されるデータとを格納する。ある局面において、ＨＤＤおよびＳＳＤ（Solid State Drive）が記憶装置２０７として使用されてもよい。自動化支援プログラムによって生成されたＧＵＩドライバーおよびテストシナリオ等は、記憶装置２０７に保存され得る。

図３は、本実施の形態に従う自動化支援プログラム３００の構成の一例を示す図である。自動化支援プログラム３００は、ＧＵＩドライバー３０１と、コントロールドライバー３０２と、キャプチャージェネレイター３０３とを含む。

ＧＵＩドライバー３０１は、上述したように、テスト対象となるアプリケーションの個別のＧＵＩに対応するクラスである。ＧＵＩドライバー３０１は、テスト対象となるアプリケーションのＧＵＩごとに作成される。そのため、ＧＵＩドライバー３０１は、テスト対象となるアプリケーションのＧＵＩの数だけ、自動または手動によって生成され得る。ある局面において、自動化支援プログラム３００は、全てまたは一部のＧＵＩドライバー３０１を外部プログラムとして読み込んでもよい。

コントロールドライバー３０２は、上述したように、ＧＵＩに含まれ得る個別のコントロールに対応するクラスである。特定のＯＳ上で動作するアプリケーションまたはウェブアプリケーションに使用される全てのコントロールの各々に対応する複数のコントロールドライバー３０２が事前に定義されてもよい。ある局面において、自動化支援プログラム３００は、コントロールドライバー３０２を外部プログラムとして読み込んでもよい。例えば、コントロールドライバー３０２は、各種コントロールという汎用的な部品に対応しており、ＤＬＬ（Dynamic Link Library）等に組み込まれて外部プログラムとして使用されることで、ユーザーの利便性が向上する。

キャプチャージェネレイター３０３は、テストコードを生成するプログラムであり、コントロールごとに定義され得る。各キャプチャージェネレイター３０３は、各コントロールドライバー３０２にそれぞれ対応する。一例として、ボタンのキャプチャージェネレイター３０３は、ボタンのコントロールドライバー３０２に対応する。他の例として、テキストボックスのキャプチャージェネレイター３０３は、テキストボックスのコントロールドライバー３０２に対応する。

ユーザーは、キャプチャージェネレイター３０３も、コントロールドライバー３０２と同様に独自に定義することができる。自動化支援プログラム３００は、ユーザー定義の任意のコントロールドライバー３０２およびキャプチャージェネレイター３０３を使用し得る。

キャプチャージェネレイター３０３は、テスト対象のアプリケーションのＧＵＩに含まれるコントロールが操作されたときに、当該操作に対応するテストコードを生成する。ある局面において、自動化支援プログラム３００は、テスト対象のアプリケーションにキャプチャージェネレイター３０３を送信してもよい。この場合、テスト対象のアプリケーションのＧＵＩに含まれるコントロールが操作されたとき（イベントが発生またはコントロールに関連するデータに変化が発生したとき）、テスト対象のアプリケーション内でキャプチャージェネレイター３０３が実行される。キャプチャージェネレイター３０３は、テストコードを生成し、当該テストコードを自動化支援プログラム３００に送信する。

他の局面において、自動化支援プログラム３００は、ＦｒｉｅｎｄｌｙまたはＳｅｌｅｎｉｕｍ等のソフトウェアの機能を利用して、テスト対象のアプリケーションのイベント発生またはコントロールに関連するデータの変化を常に監視てしておいてもよい。この場合、自動化支援プログラム３００は、テスト対象のアプリケーションのＧＵＩに含まれるコントロールが操作されたとき（イベントが発生またはコントロールに関連するデータに変化が発生したとき）、キャプチャージェネレイター３０３に当該操作に対応するテストコードを生成させる。

次に、図４〜図７を参照して、テスト対象のアプリケーションのＧＵＩ、ＧＵＩドライバー３０１およびコントロールドライバー３０２の詳細について説明する。以下の説明では、ＰＣ上で動作するネイティブアプリケーションおよびウェブアプリケーションを例示しているが、タブレットおよびスマートフォン等の他の機器で動作するＧＵＩアプリケーションについても同様の手法を適用できる。

図４は、ＰＣで動作するネイティブアプリケーション４００の一例を示す図である。ネイティブアプリケーション４００は、コントロールの一部として、名前のテキストボックス４０１と、カレンダー４０２と、数字入力ボックス４０３と、Ｅメールのテキストボックス４０４と、言語選択のプルダウンメニュー４０５と、性別選択のラジオボタン４０６と、エントリーボタン４０７と、キャンセルボタン４０８とを含む。ネイティブアプリケーション４００のＮａｍｅ、Ｂｉｒｔｈｄａｙ等のラベルおよび画面上部のメニュー等もコントロールであるが、以下の説明には関係しないため、詳細は説明しない。

テキストボックス４０１，４０４は、文字列の入力を受け付ける。カレンダー４０２は、年月日の選択操作を受け付ける。数字入力ボックス４０３は、数値の入力を受け付け、数値のカウントアップ、カウントダウンのボタンを含む。プルダウンメニュー４０５は、予め定められたメニューの選択操作を受け付ける。ラジオボタン４０６は、選択肢のうちの１つを選択する操作を受け付ける。エントリーボタン４０７およびキャンセルボタン４０８は、押下処理を受け付ける。

ユーザーは、上記のネイティブアプリケーション４００を作成し、テキストボックス４０１〜キャンセルボタン４０８までのコントロールを用いたテストを行いたいとする。その場合、一例として、図５に示すＧＵＩドライバー３０１のクラス５０１が必要になる。

図５は、ＧＵＩドライバー３０１の第１の例を示す図である。図５に示されるソースコードは、ＧＵＩドライバー３０１の一部分を示している。ある局面において、自動化支援プログラム３００は、ＧＵＩドライバー３０１を使用するとき、当該ＧＵＩドライバー３０１のソースファイルを読み込んでビルドしてもよい。他の局面において、自動化支援プログラム３００は、予めビルドされたＧＵＩドライバー３０１のバイナリファイルを読み込んでもよい。

クラス５０１は、ＧＵＩドライバー３０１を定義する。クラス５０１は、複数のコントロールドライバー３０２をコントロールプロパティ５０２として含み得る。より具体的には、クラス５０１は、テキストボックス４０１〜キャンセルボタン４０８までのコントロールの各々に対応する各コントロールドライバー３０２のインスタンスの作成処理を含む。

さらに、クラス５０１は、「各コントロールをそれぞれ指定するための情報」と、「各コントロールドライバー３０２のインスタンス」とを対応付けする。図５の例では、各コントロールをそれぞれ指定するための情報を各コントロールドライバー３０２に、引数として渡すことで、関連付けている。

以降の説明では、区別のために、コントロールドライバー３０２によって特定されるＧＵＩドライバー３０１内のインスタンスを「コントロールプロパティ」と呼ぶ。例えば、「Ｎａｍｅ」，「Ｂｉｒｔｈｄａｙ」はコントロールプロパティ５０２である。コントロールプロパティ５０２に割り当てられるクラスを「コントロールドライバー３０２」と呼ぶ。例えば、「ＷＰＦＴｅｘｔＢｏｘ」，「ＷＰＦＣａｌｅｎｄａｒ」はコントロールドライバー３０２である。

図５の例では、コントロールプロパティ５０２は、ＷＰＦを用いて作成されたコントロールを操作する機能を有するが、各コントロールドライバー３０２の機能はこれに限られない。ある局面において、各コントロールドライバー３０２は、任意のＯＳ、ウェブ等の各種プラットフォームのコントロールごとに定義され得る。

クラス５０１は、テキストボックス４０１〜キャンセルボタン４０８までのコントロールの各々に対応する各コントロールプロパティ５０２を含むことにより、外部からネイティブアプリケーション４００のコントロール（テキストボックス４０１〜キャンセルボタン４０８）を操作することができる。

各コントロールプロパティ５０２は、上述したように、任意のＯＳ、ウェブ等の各種プラットフォームのコントロールごとに定義される汎用的なコントロールドライバー３０２によって作成される。そのため、ユーザーは、ＧＵＩドライバー３０１に、自身の作成したネイティブアプリケーション４００に含まれるコントロールに対応するコントロールドライバー３０２のコントロールプロパティ５０２（インスタンス）の作成処理を追加するだけでよい。例えば、Ｎａｍｅ〜Ｃａｎｃｅｌまでのインスタンスは、全て事前に用意されているコントロールドライバー３０２から作成されている。

装置１００は、実際に自動化支援プログラム３００を実行するときに、各コントロールプロパティ５０２のインスタンス生成時のクラス名（コントロールドライバー３０２）および引数（各コントロールをそれぞれ指定するための情報）を参照することで、各コントロールプロパティ５０２が、いずれのコントロールを操作するのか判別することができる。一例として、「Ｅｍａｉｌ」は、「ＷＰＦＴｅｘｔＢｏｘ」クラスであり、テキストボックスを操作する。「Ｅｍａｉｌ」の引数（各コントロールをそれぞれ指定するための情報）は、「〜ByBinding("Mail.Value").Single()」となっており、「Ｅｍａｉｌ」は、Ｅメールのテキストボックス４０４を操作することがわかる。各コントロールをそれぞれ指定するための情報となる情報は、プラットフォームにより異なる。

上述のように、コントロールドライバー３０２は、ＧＵＩドライバー３０１内で汎用的な部品を操作するコントロールプロパティ５０２として使用され得る。さらに、自動化支援プログラム３００は、ユーザーによって作成された新しいコントロールをテストすることも可能である。自動化支援プログラム３００は、ユーザー定義のコントロールドライバー３０２を使用することで、ユーザー定義のコントロールドライバー３０２に対応する任意のコントロールのテストコードを生成できる。これらの新しく作成されたコントロールドライバー３０２は、ＤＬＬ等に含められて配信されることで、他のユーザーも使用し得る。このように、自動化支援プログラム３００は、汎用的なコントロールに対応するコントロールドライバー３０２以外にも、ユーザー定義のコントロールに対応するコントロールドライバー３０２を使用し得る。

後述するテストコードは、ＧＵＩドライバー３０１に定義された各コントロールプロパティ５０２のメソッドまたはプロパティを呼び出す。すなわち、本実施の形態において、ＧＵＩドライバー３０１およびコントロールプロパティ５０２の定義と、テストコードを含むテストシナリオとは分離されている。ＧＵＩドライバー３０１およびコントロールプロパティ５０２の定義と、テストシナリオとが分離されることにより、テストシナリオの可読性およびメンテナンス性が高くなる。

従来のテストシナリオを作成するキャプチャープログラムは、「各コントロールをそれぞれ指定するための情報」および「コントロールを直接操作する処理」を全て含んだ可読性およびメンテナンス性の低いテストコードを生成していた。そのため、アプリケーションの仕様変更が発生した場合、今までに生成された全てのテストコードは使用できなくなった。

これに対し、本実施の形態における自動化支援プログラム３００は、ネイティブアプリケーション４００の仕様が変更されたとしても、コントロールプロパティ５０２の定義（クラスの型、引数等（各コントロールをそれぞれ指定するための情報））等を変更するだけで、テストシナリオを利用することができる。

図６は、ウェブアプリケーションのＧＵＩ６００の一例を示す図である。ウェブアプリケーションは、ブラウザ等により実行されるため、様々な機器に配信されるアプリケーションとして使用されることも多い。自動化支援プログラム３００は、このようなウェブアプリケーションのＧＵＩに関しても、ネイティブアプリケーションのＧＵＩと同様にテストすることができる。

ウェブアプリケーション６００は、コントロールの一部として、タイトルのテキストボックス６０１と、放送開始日のテキストボックス６０２と、ジャンルのテキストボックス６０３と、値段のテキストボックス６０４と、保存ボタン６０５とを含む。

ユーザーは、上記のウェブアプリケーションのＧＵＩ６００を作成し、テキストボックス６０１〜保存ボタン６０５までのコントロールを用いたテストを行いたいとする。その場合、一例として、図７に示すＧＵＩドライバー３０１のクラス７０１が必要になる。

図７は、ＧＵＩドライバー３０１の第２の例を示す図である。図７に示すソースコードは、ＧＵＩドライバー３０１の一部分を示している。ある局面において、自動化支援プログラム３００は、ＧＵＩドライバー３０１を使用するとき、当該ＧＵＩドライバー３０１のソースファイルを読み込んでビルドしてもよい。他の局面において、自動化支援プログラム３００は、予めビルドされたＧＵＩドライバー３０１のバイナリファイルを読み込んでもよい。

クラス７０１は、ＧＵＩドライバー３０１を定義する。クラス７０１は、複数のコントロールドライバー３０２をコントロールプロパティ７０２として含み得る。より具体的には、クラス５０１は、テキストボックス６０１〜保存ボタン６０５までのコントロールの各々に対応するコントロールドライバー３０２のインスタンスの作成処理を含む。

図５と図７とを比較すると、コントロールプロパティ５０２およびコントロールプロパティ７０２の記述が異なることがわかる。コントロールプロパティ５０２は、ＷＰＦのコントロールを操作するコントロールドライバー３０２に、ＷＰＦに関する情報を渡している。一方で、コントロールプロパティ７０２は、ウェブアプリケーションのコントロールを操作するコントロールドライバー３０２に、ウェブアプリケーションに関する情報を渡している。すなわち、自動化支援プログラム３００は、ＧＵＩドライバー３０１内で使用するコントロールドライバー３０２および当該コントロールドライバー３０２に渡される情報（各コントロールをそれぞれ指定するための情報）を変更するだけで、様々なプラットフォームに対応することができる。

次に、図８〜図１０を参照して、テストシナリオの生成処理について説明する。以降の説明では、図４のネイティブアプリケーション４００を例に説明するが、自動化支援プログラム３００は、ウェブアプリケーション６００およびその他のプラットフォームのＧＵＩアプリケーションのテストに関しても、同様の手順でテストシナリオを作成できる。

図８は、キャプチャージェネレイター３０３の動作概要の一例を説明する。手順８０１において、自動化支援プログラム３００は、アプリケーション１０２に、キャプチャージェネレイター３０３を送信する。このとき、コントロールプロパティ５０２の各々に対応したキャプチャージェネレイター３０３が、アプリケーション１０２に送信される。キャプチャージェネレイター３０３は、アプリケーション１０２内部で実行される。

ある局面において、自動化支援プログラム３００は、ＧＵＩドライバー３０１としてクラス５０１を使用する場合、コントロールプロパティ５０２の各々に対応する各キャプチャージェネレイター３０３をアプリケーション１０２に送信してもよい。

他の局面において、キャプチャージェネレイター３０３は、同一のコントロールドライバー３０２によって定義された複数のコントロールプロパティ５０２に対応付けられていてもよい。例えば、コントロール（Ａ）〜（Ｃ）に対応するコントロールプロパティ（Ａ）〜（Ｃ）のいずれもが、「ＷＰＦＴｅｘｔＢｏｘ」クラスである場合、「ＷＰＦＴｅｘｔＢｏｘ」クラスに対応するキャプチャージェネレイター３０３（Ｘ）がコントロールプロパティ（Ａ）〜（Ｃ）に対応付けられてもよい。その場合、自動化支援プログラム３００は、コントロール（Ａ）〜（Ｃ）の操作をキャプチャーするために、キャプチャージェネレイター３０３（Ｘ）をアプリケーション１０２に送信し得る。

手順８０２において、送信された各キャプチャージェネレイター３０３は、アプリケーション１０２で発生したイベントまたはコントロールに関連するデータの変化を検知して、対応するテストコードを生成する。例えば、テキストボックス４０１を監視するキャプチャージェネレイター３０３（Ｙ）は、テキストボックス４０１の操作イベントの発生を検知して、当該操作イベントに対応するテストコードを生成する。テストコードは、実際に行われた操作と同じ処理になる。一例として、テキストボックス４０１に「たなか」と入力された場合、キャプチャージェネレイター３０３（Ｙ）は、テキストボックス４０１に「たなか」と入力するテストコードを生成する。自動化支援プログラム３００は、各キャプチャージェネレイター３０３によって生成されたテストコードを取得し、一つにまとめることによりテストシナリオ８０３を作成する。

ある局面において、自動化支援プログラム３００は、キャプチャージェネレイター３０３をアプリケーション１０２に送信する代わりに、Ｆｒｉｅｎｄｌｙ等の機能を用いてアプリケーション１０２の各コントロールの操作（イベント発生またはコントロールに関連するデータの変化）を監視するだけでもよい。自動化支援プログラム３００は、各コントロールの操作を検知したときに、キャプチャージェネレイター３０３にテストコードを生成させてもよい。

図９は、テストシナリオの一例を示す図である。テストシナリオは、生成されたテストコード９０１と、検証用コード９０２とを含む。テストコード９０１は、キャプチャージェネレイター３０３によって生成されたものであり、当該テストコード９０１は、アプリケーション１０２に対して、テスト操作を実行する。

検証用コード９０２は、テストコード９０１が実行されたときの各コントロールへの出力結果等を検証する。キャプチャージェネレイター３０３は、テストコードを生成したときの出力結果に基づいて、当該検証用コード９０２を生成し得る。検証用コード９０２は、本来と異なる出力結果が得られたときに例外を発生させ得る。検証用コード９０２は、テストコード９０１と同様に、コントロールドライバー３０２のメソッドまたはプロパティを含む。

各テストコード９０１および検証用コード９０２は、いずれもＧＵＩドライバー３０１のクラス５０１に含まれるコントロールプロパティ５０２のメソッドまたはプロパティを呼び出している。そのため、手書きコードと同様に可読性が高く、編集も容易である。さらに、ＧＵＩドライバー３０１のクラス５０１およびテストシナリオは分離されているので、コントロールプロパティ５０２の各コントロールをそれぞれ指定するための情報が変更されても、自動化支援プログラム３００は、問題無くテストシナリオを実行可能である。

図１０は、生成されたテストシナリオ１００１の例を示す図である。ユーザーは、ＩＤＥ等のビルド機能を有するソフトウェアがあれば、生成されたテストシナリオ１００１を実行することができる。

図１１は、自動化支援プログラム３００の通信処理の手順の一例を示す図である。図１１を参照して、自動化支援プログラム３００およびテスト対象のアプリケーション１０２の通信処理について説明する。ある局面において、アプリケーション１０２は、ネイティブアプリケーションでもよいし、ウェブアプリケーションのフロント部分であってもよい。他の局面において、制御装置２０１は、ＲＡＭ２０２に自動化支援プログラム３００を読み込んで、図１１の処理を実行してもよい。

処理は、主に、処理１１５０と、処理１１６０とに分けられる。処理１１５０は、ＧＵＩドライバー３０１を生成する処理であり、処理１１６０は、テストシナリオを作成する処理である。ステップＳ１１１０において、自動化支援プログラム３００は、ＦｒｉｅｎｄｌｙまたはＳｅｌｅｎｉｕｍ等と連携して、各コントロールをそれぞれ指定するためのアプリケーション１０２に関する情報を取得する。

ある局面において、自動化支援プログラム３００は、起動時に、テスト対象のアプリケーション１０２を示す情報を取得し得る。テスト対象のアプリケーション１０２を示す情報は、例えば、プロセスＩＤまたはＵＲＬ（Uniform Resource Locator）等の任意の情報であってよい。他の局面において、自動化支援プログラム３００は、テスト対象のアプリケーション１０２を起動させてもよいし、ブラウザを起動して、当該ブラウザにウェブアプリケーションのＧＵＩを表示させてもよい。

ステップＳ１１２０において、自動化支援プログラム３００は、アプリケーション１０２から、各コントロールをそれぞれ指定するための情報を受信する。各コントロールをそれぞれ指定するための情報は、各コントロールの種類に関する情報と、各コントロールを一意に特定する情報とを含み得る。自動化支援プログラム３００は、各コントロールをそれぞれ指定するための情報に基づいて、ＧＵＩドライバー３０１を自動生成し得る。ユーザーは、自動生成されたＧＵＩドライバー３０１を編集することができる。

ステップＳ１１３０において、自動化支援プログラム３００は、監視対象のコントロールに対応するキャプチャージェネレイター３０３をアプリケーション１０２に送信する。ステップＳ１１４０において、自動化支援プログラム３００は、アプリケーション１０２内で動作するキャプチャージェネレイター３０３から、テストコードを受信する。

図１２は、自動化支援プログラム３００のテストシナリオ生成の処理手順の一例を示す図である。図１２を参照して、自動化支援プログラム３００の内部処理について説明する。ある局面において、制御装置２０１は、ＲＡＭ２０２に自動化支援プログラム３００を読み込んで、図１２の処理を実行してもよい。

ステップＳ１２１０において、自動化支援プログラム３００は、ＧＵＩドライバー３０１を生成する。当該ステップは、処理１１５０に相当する。自動化支援プログラム３００は、テスト対象のアプリケーション１０２に関する情報を取得し、アプリケーション１０２が含むコントロールを判別する。自動化支援プログラム３００は、判別したコントロールに対応するコントロールドライバー３０２を用いて、コントロールプロパティを生成する。

ステップＳ１２２０において、自動化支援プログラム３００は、ユーザーからのＧＵＩドライバー３０１の編集処理を受け付ける。ある局面において、ユーザーは、他のエディタまたはＩＤＥ等でＧＵＩドライバー３０１を編集してもよい。他の局面において、ユーザーは、手動でＧＵＩドライバー３０１を定義してもよい。

ステップＳ１２３０において、自動化支援プログラム３００は、装置１００に表示されているアプリケーション１０２の情報を取得する。ある局面において、自動化支援プログラム３００は、起動時または実行中に、ユーザーからアプリケーション１０２を示す情報の入力を受け付けてもよい。アプリケーション１０２を示す情報は、一例として、プロセスＩＤまたはＵＲＬ等である。他の局面において、自動化支援プログラム３００は、ファイル上のパスまたはＵＲＬ等に基づいて、アプリケーション１０２を起動してもよい。

ステップＳ１２４０において、自動化支援プログラム３００は、アプリケーション１０２の情報に基づいて、予め作成されているＧＵＩドライバー３０１の中から、使用するＧＵＩドライバー３０１を選択する。

ステップＳ１２５０において、自動化支援プログラム３００は、ＧＵＩドライバー３０１のコントロールプロパティに基づいて、キャプチャー対象であるコントロールを特定する。より具体的には、自動化支援プログラム３００は、コントロールプロパティ（インスタンス）を生成するコントロールドライバー３０２の種類と、コントロールプロパティに渡される各コントロールをそれぞれ指定するための情報とに基づいて、キャプチャー対象であるコントロールを特定する。

ステップＳ１２６０において、自動化支援プログラム３００は、ステップＳ１２５０で特定したコントロールプロパティに対応するキャプチャージェネレイター３０３をアプリケーション１０２に送信し、アプリケーション１０２の受け付ける操作を監視する。キャプチャージェネレイター３０３は、アプリケーション１０２の操作に基づいて、テストコードを生成し、当該テストコードを自動化支援プログラム３００に送信する。

ステップＳ１２７０において、自動化支援プログラム３００は、テストコードを受信し、当該テストコードをテストシナリオに含める。ステップＳ１２８０において、自動化支援プログラム３００は、テストコードの出力結果を検証する検証用コードを生成し、テストシナリオに追加する。

以上説明したように、本実施の形態において、ＧＵＩドライバー３０１およびコントロールドライバー３０２がテストシナリオとは独立して定義される。ＧＵＩドライバー３０１は、コントロールドライバー３０２をコントロールプロパティとして含むことで、各コントロールをそれぞれ指定するための情報と、コントロールを直接操作する処理とを隠蔽する。さらに、自動化支援プログラム３００は、テスト対象のアプリケーションの操作のキャプチャー時に、コントロールドライバー３０２のメソッドまたはプロパティを呼び出すテストコードを生成する。当該処理により、自動化支援プログラム３００は、可読性およびメンテナンス性の高いテストコードを含むテストシナリオを作成し得る。さらに、自動化支援プログラム３００は、上記したテストシナリオの作成手順から検証用コードの追加処理を除くことにより、ＲＰＡ用のシナリオを生成することができる。

今回開示された実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内で全ての変更が含まれることが意図される。

１０，１００ 装置、１０１ ＩＤＥ、１０２ アプリケーション、２０１ 制御装置、２０２ ＲＡＭ、２０３ 入力インターフェイス、２０４ 出力インターフェイス、２０５ 外部機器インターフェイス、２０６ 通信インターフェイス、２０７ 記憶装置、３００ 自動化支援プログラム、３０１ ＧＵＩドライバー、３０２ コントロールドライバー、３０３ キャプチャージェネレイター、４００ ネイティブアプリケーション、４０１，４０４，６０１，６０２，６０３，６０４ テキストボックス、４０２ カレンダー、４０３ 数字入力ボックス、４０５ プルダウンメニュー、４０６ ラジオボタン、４０７ エントリーボタン、４０８ キャンセルボタン、５０１，７０１ クラス、５０２，７０２ コントロールプロパティ、６００ ウェブアプリケーション、６０５ 保存ボタン、８０３，１００１ テストシナリオ、９０１ テストコード、９０２ 検証用コード。

Claims (8)

1. コンピューターを制御するプログラムであって、前記プログラムは前記コンピューターに、
   １以上のコントロールを含み、前記コンピューターのモニターに表示されているＧＵＩ（Graphical User Interface）の情報を取得するステップと、
   前記１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含むＧＵＩドライバーを選択するステップと、
   取得した前記ＧＵＩの情報と、前記１以上のコントロールドライバーとに基づいて、前記１以上のコントロールの中から、キャプチャー対象となるコントロールを選択するステップと、
   前記選択されたコントロールが受け付けた操作をキャプチャーするステップと、
   前記キャプチャーの結果に基づいて、前記１以上のコントロールドライバーのいずれかに対応する操作コードを生成するステップとを実行させる、プログラム。
2. 前記１以上のコントロールドライバーの各々は、前記１以上のコントロールの各々を外部から操作するクラスであり、
   前記ＧＵＩドライバーは、
   前記１以上のコントロールドライバーをメソッドまたはプロパティとして含むクラスであり、
   前記ＧＵＩの情報に含まれる前記１以上のコントロールの各々を指定する情報と、前記１以上のコントロールドライバーの各々とを関連付けており、
   前記操作コードは、前記１以上のコントロールドライバーのいずれかのメソッドまたはプロパティを含む、請求項１に記載のプログラム。
3. 前記１以上のコントロールドライバーは、ユーザーにより定義されたカスタムコントロールドライバーを含む、請求項１または２に記載のプログラム。
4. 前記プログラムは前記コンピューターに、
   前記１以上のコントロールドライバーを含む外部プログラムを読み込むステップをさらに実行させる、請求項１〜３のいずれかに記載のプログラム。
5. 前記プログラムは前記コンピューターに、
   前記１以上のコントロールドライバーの各々に対応する操作コード生成プログラムを呼び出すステップと、
   前記操作コード生成プログラムから、前記ＧＵＩのイベント発生時または前記コントロールに関連するデータの変化時に、前記操作コード生成プログラムが生成する操作コードを受信するステップとをさらに実行させる、請求項１〜４のいずれかに記載のプログラム。
6. 前記プログラムは前記コンピューターに、
   前記操作コードを実行した場合の出力結果を確認するための確認コードを生成するステップをさらに実行させ、
   前記確認コードは、前記１以上のコントロールドライバーのいずれかのメソッドまたはプロパティを含む、請求項１〜５のいずれかに記載のプログラム。
7. ソフトウェアの操作コードを生成する方法であって、
   １以上のコントロールを含み、コンピューターのモニターに表示されているＧＵＩの情報を取得するステップと、
   前記１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含むＧＵＩドライバーを選択するステップと、
   取得した前記ＧＵＩの情報と、前記１以上のコントロールドライバーとに基づいて、前記１以上のコントロールの中から、キャプチャー対象となるコントロールを選択するステップと、
   前記選択されたコントロールが受け付けた操作をキャプチャーするステップと、
   前記キャプチャーの結果に基づいて、前記１以上のコントロールドライバーのいずれかに対応する操作コードを生成するステップとを含む、方法。
8. ユーザーからの操作を受け付ける入力部と、
   ＧＵＩを表示する表示部と、
   １以上のＧＵＩドライバーを格納するメモリーと、
   制御部とを備え、
   前記制御部は、
   前記表示部に表示されている１以上のコントロールを含む前記ＧＵＩの情報を取得し、
   前記メモリーを参照し、前記１以上のコントロールの各々をそれぞれ操作する１以上のコントロールドライバーを含む前記ＧＵＩドライバーを選択し、
   取得した前記ＧＵＩの情報と、前記１以上のコントロールドライバーとに基づいて、前記１以上のコントロールの中から、キャプチャー対象となるコントロールを選択し、
   前記選択されたコントロールが前記入力部から受け付けた操作をキャプチャーし、
   前記キャプチャーの結果に基づいて、前記１以上のコントロールドライバーのいずれかに対応する操作コードを生成する、装置。

Images