JP2011048714A - テスト支援方法およびテスト支援装置 - Google Patents

Abstract

【課題】ＧＵＩに依存しないコマンド体系で記述することにより、ＧＵＩの違いを意識する必要のないＧＵＩを利用したソフトウェアのテストシナリオを提供すること。
【解決手段】グラフィカル・ユーザ・インターフェース（以下、ＧＵＩと略記する）を利用したソフトウェアのテストをコンピュータに実行させるためのものである。グラフィカル・ユーザ・インターフェースの指定状態を検出するコマンドを付加した共通様式のシナリオを、グラフィカル・ユーザ・インターフェースに応じた様式のコマンドに変更して、指示するステップと、グラフィカル・ユーザ・インターフェースの状態が指定状態であるか判断するステップと、判断するステップで、グラフィカル・ユーザ・インターフェースが指定状態にあるとコマンドを実行するステップとを含む。ＧＵＩの違いに依存しない共通書式でテストシナリオを記述してソフトウェアのテストを実行することができる。
【選択図】図２

Description

本願に開示の技術は、グラフィカル・ユーザ・インターフェースを利用したソフトウェアを検証するテスト支援方法およびテスト支援装置に関する。

近年、グラフィカル・ユーザ・インターフェース（以下、ＧＵＩと略記する）を利用したソフトウェアについては、種々の試みがなされている。たとえば、ＧＵＩを伴うアプリケーションのプログラムの作成工程からテスト工程までを支援し、一連のＧＵＩアプリケーション開発を効率的に行うことを目的とする技術が知られている。また、処理プロセスの稼働時に実施されるべき画面操作を、コマンド形式のシナリオに従って処理プロセスと切り離して実現する技術が知られている。また、ＧＵＩに伴うアプリケーションを表すためにユーザによって定義される構造仕様ファイル、状態遷移仕様ファイル、および個別状態仕様ファイルに従ってテストシナリオを生成する技術が知られている（特許文献１〜３など）。

特開２００７−２１３２４９号公報 特開平１０−１６１８５８号公報 特開平９−２２３０４０号公報 特開２００７−３２３５７３号公報

しかしながら、背景技術に例示された技術は、何れも、対象となるソフトウェアが利用するＧＵＩに応じてカスタマイズされるものである。当該ＧＵＩに適合するシナリオ言語に合わせて構築されるからである。ＧＵＩに適合するシナリオ言語ごとに個別にシナリオをカスタマイズせざるを得ず問題である。

本願に開示される技術は、上記の課題に鑑み提案されたものである。ＧＵＩに依存しないコマンド体系で記述することにより、ＧＵＩの違いを意識する必要のないＧＵＩを利用したソフトウェアのテスト支援方法およびテスト支援装置を提供することを目的とする。

本願に開示される技術に係るテスト支援方法は、グラフィカル・ユーザ・インターフェース（以下、ＧＵＩと略記する）を利用したソフトウェアのテストをコンピュータに実行させるためのものである。テスト支援方法では、グラフィカル・ユーザ・インターフェースの指定状態を検出するコマンドを付加した共通様式のシナリオを、グラフィカル・ユーザ・インターフェースに応じた様式のコマンドに変更して、指示するステップと、グラフィカル・ユーザ・インターフェースの状態が指定状態であるか判断するステップと、判断するステップで、グラフィカル・ユーザ・インターフェースが指定状態にあるとコマンドを実行するステップとを含む。

本願に開示の技術に係るテスト支援方法によれば、テスト対象のソフトウェアが利用するＧＵＩが異なりＧＵＩごとに稼働する操作記述の書式が異なる場合にも、ＧＵＩの違いに依存しない共通書式でテストシナリオを記述してソフトウェアのテストを実行することができる。ＧＵＩごとにテストシナリオをカスタマイズする必要がなく、ＧＵＩの違いを意識することなく共通の書式によりＧＵＩを利用したソフトウェアのテストシナリオを作成することができる。

ＧＵＩソフトウェアをテストする際の一般的な制御の流れを示す図である。 ＧＵＩソフトウェアをテストする際の実施形態での制御の流れを示す図である。 第１の実施形態の第1変換制御部の構成を示す図である。 第１の実施形態の第２変換制御部の構成を示す図である。 第２の実施形態の第１変換制御部の構成を示す図である。 第２の実施形態の第２変換制御部の構成を示す図である。 テストシナリオの処理の流れを示す図である。 論理／物理変換テーブルの一例である。 論理コマンドで記述したテストシナリオ（論理シナリオ）の一例である。 図９のテストシナリオを物理装置ＰＣ１向けに準物理コマンドに変換したシナリオ（準物理シナリオ）である。 図９のテストシナリオを物理装置ＰＣ２向けに準物理コマンドに変換したシナリオ（準物理シナリオ）である。 図９のテストシナリオを物理装置ＰＣ１向けに物理コマンドに変換したシナリオ（物理シナリオ）、および対応するＧＵＩ画面を示す図である。 図９のテストシナリオを物理装置ＰＣ２向けに物理コマンドに変換したシナリオ（物理シナリオ）、および対応するＧＵＩ画面を示す図である。

ＧＵＩを利用して動作するソフトウェアの実行指示は、マウスやキーボードで行われる。この場合、実行する際の条件や実行後の確認はＧＵＩ画面上の表示により行われることが通常である。また、マウスやキーボードによる実行指示は、ＧＵＩ画面上のボタンやチェックボックス等を操作することにより行われる。これらの操作はＧＵＩ画面上の表示や入力方法に依存して行われる。このため、ＧＵＩソフトウェアをテストする際のテストシナリオを作成する場合には、ＧＵＩごとに画面表示または／および実行指示の入力方法が異なる場合に、ＧＵＩごとの操作記述の仕様に応じてテストシナリオを作成する必要がある。特に、複数の装置が連携して動作するＧＵＩソフトウェアをテストする際、装置ごとＧＵＩごとの操作内容を機械化して遠隔操作により同期実行させることは複雑な制御が伴う場合もあり容易ではない。すなわち、装置ごとＧＵＩごとに制御方法およびその実行方法が異なる場合があり、更に、実行結果も、装置ごとＧＵＩごとに異なる場合も考えられる。装置数が増加し各装置で稼働するＧＵＩの種類が増えるに従い、実行方法が多様化し実行結果やＧＵＩの状態の判断も多様化する。これらの個々の実行方法と状態判断に対応しなければならなくなる。テストシナリオによる装置間の連携動作の制御を効率よく行うことが要請されている。

図１は、複数の装置ＰＣ１（１−５）、ＰＣ２（１−５’）で稼働するＧＵＩソフトウェアのテストを行う際の制御の流れを示す図である。

図１では、テスト対象として２つの装置ＰＣ１（１−５）、ＰＣ２（１−５’）でＧＵＩソフトウェアが稼働する場合である。装置ＰＣ１（１−５）、ＰＣ２（１−５’）を含むシステムで稼働するＧＵＩソフトウェアのテストは、テスト制御部（１−１）により制御される。

テスト制御部（１−１）は、ＧＵＩソフトウェアによる装置ＰＣ１（１−５）、ＰＣ２（１−５’）間の連携動作を制御するために連携実行制御部（１−３）を備えている。連携実行制御部（１−３）には、装置ＰＣ１（１−５）、ＰＣ２（１−５’）ごとに記述されたシナリオ（１−２）が入力され、連携実行制御部（１−３）からは、装置ＰＣ１（１−５）、ＰＣ２（１−５’）ごとの実行ログ（１−４）が出力される。

連携実行制御部（１−３）は、入力されたシナリオ（１−２）から、各装置ＰＣ１（１−５）、ＰＣ２（１−５’）の各々に適合したシナリオを選択して各装置ＰＣ１（１−５）、ＰＣ２（１−５’）に転送する。装置ＰＣ１（１−５）、ＰＣ２（１−５’）には、それぞれに適合したシナリオ１（１−６）、シナリオ２（１−６’）が転送される。転送されたシナリオ１（１−６）、シナリオ２（１−６’）は、それぞれ、実行制御部１（１−７）、実行制御部２（１−７’）で処理されてＧＵＩ１（１−８）、ＧＵＩ２（１−８’）を操作する。実行結果は、ＧＵＩ１（１−８）、ＧＵＩ２（１−８’）からそれぞれ、実行制御部１（１−７）、実行制御部２（１−７’）を経て、実行ログ１（１−９）、実行ログ２（１−９’）として、連携実行制御部（１−３）に返送される。その後、実行ログ（１−４）として蓄積される。

ここで、ＧＵＩ１（１−８）、ＧＵＩ２（１−８’）は、図示するように、それぞれ異なる画面構成をしており、操作方法、実行方法、状態表示、状態判断等はＧＵＩごとに異なるものとする。このため、それぞれのＧＵＩ１（１−８）、ＧＵＩ２（１−８’）にそれぞれ入力されるシナリオ１（１−６）、シナリオ２（１−６’）は異なっており、また、出力される実行ログ１（１−９）、実行ログ２（１−９’）も異なっている。

図１の制御では、連携実行制御部（１−３）において、装置ＰＣ１（１−５）、ＰＣ２（１−５’）ごとに、異なるシナリオ１（１−６）、シナリオ２（１−６’）を送信し、異なる実行ログ１（１−９）、実行ログ２（１−９’）を取得するように制御しなければならない。また、テスト制御部(１−１)では、装置ＰＣ１（１−５）、ＰＣ２（１−５’）間の連携制御を行うために、装置ごとにシナリオの入力タイミングや実行結果の取得タイミングを適合させねばならない。図１の制御では、テスト時間を考慮して装置間の連携動作のタイミングを余裕のないタイミングに設定すると、様々な装置間の状態を把握しながら制御する必要があるため複雑になり、連携動作が実行できない場合が生じる。また、装置間の連携動作のタイミングに余裕を持たせると、テスト動作の遅延を招来して、必要以上にテスト時間がかかりすぎることになる。

図２に示す制御は、図１の一般的な制御に代えて、実施形態での制御の流れを示す図である。

図２の実施形態では、図１のテスト制御部（１−１）に代えてテスト制御部（２−１）を備えている。また、図１の装置ＰＣ１（１−５）、ＰＣ２（１−５’）に代えて装置ＰＣ１（２−５）、ＰＣ２（２−５’）を備えている。

テスト制御部（２−１）では、装置ＰＣ１（２−５）、ＰＣ２（２−５’）に依存しない書式で記述された論理シナリオ（２−２）が第1変換制御部（２−３）に入力される。第1変換制御部（２−３）からは、装置ＰＣ１（２−５）、ＰＣ２（２−５’）に依存しない書式で記述された論理実行ログ（２−４）が出力される。

また、図示しない装置ＰＣ２（２−５’）の内部構成と同様に、装置ＰＣ１（２−５）には、第２変換制御部（２−１０）が、テスト制御部（２−１）の第１変換制御部（２−３）に接続される。第２変換制御部（２−１０）は、実行制御部１（１−７）に接続される。実行制御部１（１−７）は、ＧＵＩ１（１−８）に接続される。実行制御部１（１−７）とＧＵＩ１（１−８）とは図１の場合と同様である。

テスト制御部（２−１）には、装置ＰＣ１（２−５）、ＰＣ２（２−５’）の違いに依存しない論理シナリオ（２−２）が格納されている。論理シナリオ（２−２）は、装置の違いを吸収した書式により記述されるので、装置の別または／および装置で稼働するＧＵＩの別によらず、ＧＵＩ上での実行手順、ＧＵＩの状態判断、実行結果の取得などを統一的に記述することができる。論理シナリオ（２−２）は、複数の装置間または／およびＧＵＩ間での連携制御・同期実行を統一的に記述することができる。

論理シナリオ（２−２）は、第１変換制御部（２−３）により準物理シナリオに変換される。準物理シナリオは、装置または／およびＧＵＩに適合した書式で記述されたテストシナリオである。ＧＵＩ固有の書式である物理シナリオとは、装置または／およびＧＵＩ上の状態を把握し、取得されるＧＵＩの状態を保持する機能を有する点で準物理シナリオと異なっている。準物理シナリオは、各装置に備えられている第２変換制御部（２−１０）が受信する。第２変換制御部（２−１０）では、準物理シナリオ中に記述されている状態把握の指示や状態取得の指示に従い、ＧＵＩ上の状態の把握や取得〜保持が行われる。ＧＵＩ上の状態の把握がされることにより、テスト制御部（２−１）によるテストシナリオの遠隔制御によって個々の装置または／およびＧＵＩ間での連携制御を確実に行うことができる。また、簡易に状態把握・取得〜保持を行うことができる。各装置における制御状態を簡易に管理することができ、ＧＵＩ上の操作実行に不適格な状態や操作実行の失敗などを容易に検出することができる。準物理シナリオは、第２変換制御部（２−１０）で物理シナリオに変換され、実行制御部１（１−７）に転送される。

図３に第１の実施形態の第１変換制御部（２−３）の構成を例示する。先ず、論理シナリオ（２−２）が論理シナリオ読出部（２−３ａ）に入力される。論理シナリオ（２−２）は、
論理コマンド：論理コマンド名（論理装置名：状態 パラメータ１・・・パラメータｎ）・・（１）
の書式を有している。論理シナリオ読出部（２−３ａ）は、論理コマンド（１）を取り込む。次に、論理シナリオ実行部（２−３ｂ）において、論理コマンド（１）を、「論理コマンド名」、「論理装置名」、「状態」、「パラメータ１〜ｎ」に分解する。これにより、論理コマンド名を解釈し、物理コマンドへの変換の準備をする。具体的には、「状態」の有無、「パラメータ１〜ｎ」の数等をチェックする。

ここで、「論理コマンド名」は、ＧＵＩソフトウェアの指示を装置やＧＵＩの別に依存しない形式で記述したものである。指示とは、例えば、ボタンクリック、文字入力などである。「論理装置名」は、制御対象となる装置または／およびＧＵＩを識別する論理値である。同一の装置で複数のＧＵＩが稼働する場合は、ＧＵＩごとに異なる「論理装置名」が付与される。「状態」は、コマンドを実行するＧＵＩの制御状態を示し、例えば、コマンドがボタンクリックであれば、そのボタンが存在する状態、またはそのボタンを含む画面が存在する状態を示す。コマンドを実行する際のＧＵＩの状態を記述するものである。記述された「状態」においてコマンド実行が指示される。コマンド入力時に指定の「状態」になければ、シナリオの実行を中断してエラーメッセージ等を返す等の処理が行われる。変数を示す「パラメータ１〜ｎ」は、コマンド実行時の各種の指示情報である。例えば、コマンドがボタンクリック（&CLK_BTN（後述））であれば、マウスボタンの場合には左／右の何れのボタンであるか、またシングルクリックであるかダブルクリックであるか等が指示される。また、コマンドが状態取得コマンド（&ST_SET等（後述））であれば、検出すべきＧＵＩ上の状態と、その状態が検出された場合に変数あるいは状態を示す文字列として設定することが指定される。

シナリオ論理／物理変換部（２−３ｃ）では、論理コマンド（２−２）を、
準物理コマンド：物理コマンド名：状態 パラメータ１・・・パラメータｎ・・（２）
の書式に変換する。

具体的には、「論理装置名」を論理／物理変換テーブル（２−３ｆ）から検索して、検索された「論理装置名」に対応する物理装置の「ＩＰアドレス」、「ＧＵＩの物理コマンドおよびパラメータ群」を取得する。そして、「ＧＵＩの物理コマンドおよびパラメータ群」において、「論理コマンド名」に対応する「物理コマンド形式」を取得する。取得された「物理コマンド形式」に従い、準物理コマンド（２）を生成する。ここで、コマンドが状態取得コマンド（&ST_SET等（後述））である場合、ＧＵＩ上の制御状態が検出すべき状態である場合に、状態設定するパラメータとして、識別子「ＳＴ」と状態変数あるいは状態を示す文字列とにより「ＳＴ：状態」なるパラメータが付与される。準物理コマンド（２）は、「ＩＰアドレス」により指定された装置に送信される。

「ＩＰアドレス」により指定された装置に送信された準物理コマンド（２）は各装置に備えられている第２変換制御部で物理コマンドに変換される。図４は、第１の実施形態の第２変換制御部の構成を示す。また、図４は装置ＰＣ１（２−５）について記載しているが他の装置についても同様である。

第２変換制御部（２−１０）では、準物理コマンド（２）は物理シナリオ受信部（２−１０ａ）で受信される。準物理コマンド（２）は物理シナリオ実行部（２−１０ｂ）に転送される。物理シナリオ実行部（２−１０ｂ）では、論理シナリオ実行部（２−３ｂ）での場合と同様に、準物理コマンド（２）を各要素に分解する。「物理コマンド名」、「状態」、「パラメータ１〜ｎ」である。これにより、物理コマンド名を解釈し、ＧＵＩ上の「状態」を確認した上で物理コマンドに変換する準備をする。

状態管理判定部（２−１０ｃ）では、状態管理テーブル（２−１０ｆ）を参照して、準物理コマンド（２）から分解抽出された「状態」が状態管理テーブル（２−１０ｆ）に格納されている「状態」に一致するか否かが判断される。一致していれば「物理コマンド名」は実行可能なコマンドであると判断される。

状態管理判定部（２−１０ｃ）により実行可能であると判断されれば、準物理コマンド（２）は、
物理コマンド：物理コマンド名 パラメータ１・・・パラメータｎ・・（３）
の書式に変換され、実行制御部１（１−７）に転送される。その後、ＧＵＩ１（１−８）にて実行される。実行結果は、物理コマンド（３）ごとに実行状態管理部（２−１０ｄ）において、実行結果の良否の情報が設定される。

コマンドが状態取得コマンド（&ST_SET等（後述））である場合、準物理コマンド（２）においては、「ＳＴ：状態」なるパラメータが付与されている。ＧＵＩ１（１−８）において正常に実行がなされると、「ＳＴ：状態」なるパラメータに応じて、実行状態管理部（２−１０ｄ）において状態管理テーブル（２−１０ｆ）に「ＳＴ：状態」なるパラメータで指定された「状態」が保持される。

一方、状態管理判定部（２−１０ｃ）により、準物理コマンド（２）から分解抽出された「状態」が状態管理テーブル（２−１０ｆ）に格納されている「状態」と不一致であると判断されると、「物理コマンド名」は実行不可であると判断される。この場合、状態管理判定部（２−１０ｃ）は、実行不可の情報を実行状態管理部（２−１０ｄ）に設定する。

状態管理判定部（２−１０ｃ）では、「ＳＴ：状態」なるパラメータにより指定される「状態」を状態管理テーブル（２−１０ｆ）に保持すると共に、コマンドが実行された場合の実行結果の良否情報、コマンドの実行条件であるＧＵＩ上の状態の不一致による実行不可情報が収集される。収集された情報は、実行ログ、画面イメージ、画面情報ファイル等の実行に係る情報と合わせて、実行ログ送信部（２−１０ｅ）を介して第1変換制御部（２−３）の実行ログ論理／物理変換部（２−３ｄ）（図３）に送信される。

ＧＵＩ上の制御状態は、状態取得コマンド（&ST_SET等（後述））により取得されると、状態管理テーブル（２−１０ｆ）に状態変数あるいは制御状態を示す文字列の形態で保持される。これにより、コマンド実行の際にＧＵＩ上の制御状態を判断する必要のある場合、コマンドの実行ごとに制御状態を問い合わせる処理を行う必要がなくなる。単に、状態管理テーブル（２−１０ｆ）に対象となる状態変数あるいは制御状態を示す文字列が保持されているか否かの問い合わせを行えばよい。制御状態の確認処理といった処理の煩雑さを解消してテストシナリオを簡略化することができる。更に、状態確認を行う際の処理時間の短縮を図ることができる。一連のコマンド列を遅滞なく実行することができる。

図３に戻って、第２変換制御部（２−１０）から送信されてきた、物理実行ログは、実行ログ論理／物理変換部（２−３ｄ）により受信される。受信された物理実行ログは装置ごとに異なる書式で記載されている。このうち、コマンドごとの実行結果または／およびテスト結果（”TRUE”、”FALSE”、”Got result:OK”、”Got result:ERROR”）については、装置やＧＵＩに依存しない書式である論理実行ログ（”OK”、”ERROR”）に変換される。変換テーブルは論理／物理変換テーブル（２−３ｆ）に格納されている。その他の物理実行ログは変換されない。変換された論理実行ログ（”OK”、”ERROR”）および装置やＧＵＩごとの書式で記述された物理実行ログは、実行ログ記録部（２−３ｅ）により、論理実行ログ（２−４）（図２）として記録される。また、論理実行ログ（”OK”、”ERROR”）は、論理シナリオ実行部（２−３ｂ）にフィードバックされる。コマンドごとの実行結果または／およびテスト結果に応じて、後続のテストシナリオを制御することができる。

図５には、第２の実施形態の第１変換制御部の構成を例示する。図６は、第２の実施形態の第２変換制御部の構成を例示する。図５は、図４の第２変換制御の状態管理判定部（２−１０ｃ）、状態管理テーブル（２−１０ｆ）、実行状態管理部（２−１０ｄ）をＰＣ１側である第２変換制御部ではなく、テスト制御部（２−１）に移した例示である。図５、６では、図３と同じ構成のものは同じ番号で動作説明する。

また、図５の状態管理テーブル（２−３ｈ）は、ＰＣごとに対応したテーブルを備えている。論理シナリオ（２−２）は、複数の論理コマンドを備え、その論理コマンドが論理コマンド名（論路装置名：状態 パラメータ１・・・パラメータｎ）の書式を有している。論理シナリオ読出部（２−３ａ）は、論理シナリオ（２−２）から論理コマンドを順次読み取る。論理シナリオ実行部（２−３ｂ）は、論理シナリオ読出部（２−３ａ）で読み取った論理コマンドを「論理コマンド名」、「論理装置名」、「状態」、「パラメータ１〜ｎ」に分解する。この分解により、論理コマンド名を解釈し、物理コマンドへの変換の準備をする。具体的には、「状態」の有無、「パラメータ１〜ｎ」の数等をチェックする。シナリオ論理／物理変換部（２−３ｃ）は、論理コマンドを、準物理コマンド（物理コマンド名：状態 パラメータ１・・・パラメータｎ）という書式に変換し、状態管理判定部（２−３ｇ）と図６の物理シナリオ受信部（２−１０ａ）に出力する。

具体的には、「論理装置名」を論理／物理変換テーブル（２−３ｆ）から検索して、検索された「論理装置名」に対応する物理装置の「ＩＰアドレス」、「ＧＵＩの物理コマンドおよびパラメータ群」を取得する。そして、「ＧＵＩの物理コマンドおよびパラメータ群」において、「論理コマンド名」に対応する「物理コマンド形式」を取得する。取得された「物理コマンド形式」に従い、準物理コマンドを生成する。ここで、コマンドが状態取得コマンド（&ST_SET等（後述））である場合、ＧＵＩ上の状態が検出すべき状態である場合に、状態設定するパラメータとして、識別子「ＳＴ」と変数あるいは状態を示す文字列とにより「ＳＴ：状態」なるパラメータが付与される。

図６の物理シナリオ実行部（２−１０ｂ）は、物理シナリオ受信部（２−１０ａ）で受けた準物理コマンドを物理コマンドに変換し、実行制御部（１−７）へ送信する。実行制御部（１−７）は、物理コマンドをＧＵＩソフトウェア（１−８）で実行させる。実行制御部（１―７）は、ＧＵＩソフトウェア（１−８）で物理コマンドを実行した結果、画面イメージや画像および画像情報ファイルを実行ログ送信部（２−１０ｅ）に送る。実行ログ送信部（２−１０ｅ）は、実行した結果と画面イメージと画像情報ファイルを実行ログ論理/物理変換部（２−３ｄ）に送信する。

状態管理判定部（２−３ｇ）では、シナリオ論理／物理変換部（２−３ｃ）で変換された準物理コマンドから分解抽出された「状態」が、論理装置名から対象となるＰＣの状態管理テーブル（２−３ｈ）を参照して、状態管理テーブル（２−３ｈ）に格納されている「状態」と一致するか否かが判断される。状態管理判定部（２−３ｇ）では、一致していると判定すれば実行可能なコマンドであると判断し、準物理コマンドを第２変換制御（２−１０）へ転送される。

一方、状態管理判定部（２−３ｇ）は、準物理コマンドから分解抽出された「状態」と状態管理テーブル（２−３ｈ）に格納されている「状態」と不一致であると判断されると、「物理コマンド名」は実行不可であると判断される。この場合、状態管理判定部（２−３ｇ）は、実行不可のコマンド情報であることを実行状態管理部（２−３i）に通知する。実行状態管理部（２−３ｉ）は、実行ログ論理/物理変換部（２−３ｄ）へコマンドの実行不可を示す情報を送信する。

実行ログ論理／物理変換部（２−３ｄ）は、実行ログ送信部（２−１０e）からコマンド実行結果の良否情報、実行ログ、画面イメージおよび画面情報ファイル等の情報、実行状態管理部（２−３ｉ）からのコマンドの実行不可を示す情報を受ける。実行ログ/物理変換部（２−３ｄ）は、受けた情報のうち、コマンド実行結果の良否情報とコマンドの実行不可を示す情報を論理実行ログに変換して、その論理実行ログを論理シナリオ実行部（２−３ｂ）にフィードバックして、それ以外の実行ログ、画面イメージおよび画面情報ファイル等の情報を変換しないで、実行ログ記憶部（２−３ｅ）に送る。論理シナリオ実行部（２−３ｂ）は、実行ログ論理／物理変換部（２−３ｄ）からのコマンドごとの実行結果やコマンドの実行不可に応じて、後続のテストシナリオを制御することができる。

実行ログ記憶部（２−３ｅ）は、論理実行ログと論理変換されない実行ログ、画面イメージおよび画面情報ファイル等の情報とを論理実行ログ（２−４）に記録させる。

図７に、テストシナリオの処理の流れを示す。論理シナリオ（２−２）は、シナリオ論理／物理変換部（２−３ｃ）において、論理／物理変換テーブル（２−３ｆ）を参照して論理―物理シナリオ変換が行われる（Ａ）。これにより、準物理シナリオに変換される。準物理シナリオは、各装置ＰＣ１（２−５）、ＰＣ２（２−５’）に送信される。各装置ＰＣ１（２−５）、ＰＣ２（２−５’）の第２変換制御部（２−１０）（装置ＰＣ１（２−５）の場合。装置ＰＣ２（２−５’）についても同様。）において、準物理シナリオの構成する準物理コマンド（２）は物理コマンド（３）に変換される（Ｂ１、Ｂ２）。物理コマンドが、各装置ＰＣ１（２−５）、ＰＣ２（２−５’）の実行制御部１（１−７）、実行制御部２（１−７’）で実行される（Ｃ１、Ｃ２）。実行結果として装置ごとに書式の異なる物理実行ログが、実行状態管理部（２−１０ｅ）（装置ＰＣ１（２−５）の場合。装置ＰＣ２（２−５’）についても同様。）を経て、実行ログ送信部（２−１０ｅ）（装置ＰＣ１（２−５）の場合。装置ＰＣ２（２−５’）についても同様。）から送信される（Ｄ１、Ｄ２）。送信された物理実行ログは、第１変換制御部（２−３）の実行ログ論理／物理変換部（２−３ｄ）において受信される。受信された物理実行ログのうちコマンドごとの実行結果または／およびテスト結果が、論理／物理変換テーブル（２−３ｆ）により論理実行ログに変換される（Ｅ）。変換された論理実行ログおよびその他の物理実行ログは、実行ログ記録部（２−３ｅ）により論理実行ログ（２−４）として記録される。ＧＵＩソフトウェアの改変時の再テストにおいて、同じテストシナリオを使用してテスト行うことにより、新たに得られた実行ログと記録されている論理実行ログ（２−４）との比較をしてソフトウェアの検査を行うことができる。

図８は、論理／物理変換テーブルの一例である。論理装置名として［ＰＣ１］、［ＰＣ２］、［ＰＣ３_１］、［ＰＣ３_２］の各々について、ＩＰアドレス、稼働するＧＵＩの種別、および論理実行ログの定義を備えている。ここで、論理装置名［ＰＣ３_１］および［ＰＣ３_２］は、同じ装置ＰＣ３である。同じ装置ＰＣ３において２種類のＧＵＩ（ＧＵＩ１、ＧＵＩ２）が稼働するために、ＧＵＩごとに個別に論理装置名［ＰＣ３_１］、［ＰＣ３_２］が定義されている。

ＩＰアドレスは、論理装置名［ＰＣ１］、［ＰＣ２］で固有に定義されている。また、論理装置名［ＰＣ３_１］および［ＰＣ３_２］では、同じ装置ＰＣ３であるのでＩＰアドレスは同一である。ＧＵＩの種別は、論理装置名として［ＰＣ１］、［ＰＣ２］、および［ＰＣ３_１］については、ＧＵＩ１が定義されている。論理装置名として［ＰＣ３_２］については、ＧＵＩ２が定義されている。論理実行ログについては、［ＬＯＧ１］、［ＬＯＧ２］が定義されている。

また、種別ごとのＧＵＩ（ＧＵＩ１、ＧＵＩ２）の定義では、論理コマンドと物理コマンドとの対応関係が定義されている。論理コマンドの”ACTIVATE”、”CLK_BTN”、”EXEC”、”SENDSTR”、”ST_SET”のそれぞれについて、ＧＵＩ１では、物理コマンドの”Activate”、”ClkItem”、”Exec”、”SendStr”、”Visible”がＰ１、Ｐ２、Ｐ３のようなパラメータと共に定義されている。同様に、ＧＵＩ２では、”selectwindow”、”clk”、”openwindow”、”type”、”status”がパラメータと共に定義されている。

また、ＬＯＧ１の定義では、各コマンドに対して、正常実行であるか実行不可であるかを示す物理実行ログとして、正常実行の場合に”TRUE”、実行不可の場合に”FALSE”が定義されている。また、ＬＯＧ２の定義でも同様に、正常実行の場合に”Got result:OK”、実行不可の場合に”Got result:ERRPR”が定義されている。装置ごとＧＵＩごとに物理実行ログが異なる書式であっても論理実行ログとして統一されたログ（”OK”、”ERROR”）が返されることとなる。

図9乃至図１３には、テストシナリオの具体例を示す。図９は論理シナリオの一例である。図１０、１１は準物理シナリオの一例である。図１２、１３は物理シナリオの一例である。

図９の論理シナリオにおいて、０００１行−００１６行は定義規定の行である。０００１行−０００８行は装置ＰＣ１についての定義部分である。０００９行−００１６行は装置ＰＣ２についての定義部分である。各々の装置ＰＣ１、ＰＣ２で固有のファイル名、呼称などを予め登録しておく。

論理シナリオ（図９）の００１７行−００４１行が実行部分である。００１７行−００２３行、および００２５行−００３１行では、それぞれ、装置ＰＣ１、ＰＣ２に同様の操作を行う。論理シナリオ（図９）の００１７行−００２３行は装置ＰＣ１に関する準物理シナリオ（図１０）の１００１行−１００７行、および物理シナリオ（図１２）の１００１行−１００７行に対応する。また、論理シナリオ（図９）の００２５行−００３１行は装置ＰＣ２に関する準物理シナリオ（図１１）の２００１行−２００７行、および物理シナリオ（図１３）の２００１行−２００７行に対応する。

論理シナリオ（図９）の”&EXEC”（００１７、００２５）コマンドによりアプリケーションが起動される。”&EXEC”（００１７）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”Exec”（１００１）コマンドに変換される。”&EXEC”（００２５）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”openwindow”（２００１）コマンドに変換される。

論理シナリオ（図９）の”&ACTIVATE”（００１８、００２６）コマンドにより起動したアプリケーションのウィンドウをアクティブにする。” &ACTIVATE”（００１８）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”Activate”（１００２）コマンドに変換される。” &ACTIVATE”（００２６）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”selectwindow”（２００２）コマンドに変換される。

論理シナリオ（図９）の”&ST_SET”（００１９、００２７）コマンドによりアクティブとしたウィンドウの状態を取得し、取得した状態が”$TITLE1_LOGIN”（装置ＰＣ１）、”$TITLE2_LOGIN”（装置ＰＣ２）で定義した状態、即ち、“ログイン画面”（装置ＰＣ１）、“Login Page”（装置ＰＣ２）であれば、状態管理テーブルに”LOGIN”の状態変数あるいは文字列を保持する。” &ST_SET”（００１９）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”Visible”（１００３）コマンドに変換される。” &ST_SET”（００２７）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”status”（２００３）コマンドに変換される。

論理シナリオ（図９）の”&SENDSTR”（００２０−００２１、００２８−００２９）コマンドにより、装置ＰＣ１、装置ＰＣ２で起動したアプリケーションのウィンドウの状態が”LOGIN”の状態であることを条件としてユーザ名とパスワードを入力する。”&SENDSTR”（００２０−００２１）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”SendStr”（１００４−１００５）コマンドに変換される。” &SENDSTR”（００２８−００２９）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”type”（２００４−２００５）コマンドに変換される。

論理シナリオ（図９）の”&CLK_BTN”（００２２、００３０）コマンドにより、装置ＰＣ１、装置ＰＣ２で起動したアプリケーションのウィンドウの状態が”LOGIN”の状態であることを条件として”OK”ボタン（装置ＰＣ１）、”LOGIN”ボタン（装置ＰＣ２）を押下する。”&CLK_BTN”（００２２）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”ClkItem”（１００６）コマンドに変換される。” &CLK_BTN”（００３０）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”clk”（２００６）コマンドに変換される。

論理シナリオ（図９）の”&ST_SET”（００２３、００３１）コマンドにより、装置ＰＣ１、装置ＰＣ２で起動したアプリケーションのウィンドウの状態が”LOGIN”の状態であることを条件として、アクティブとしたウィンドウの制御状態を取得し、取得した制御状態が”$TITLE1_OPE”（装置ＰＣ１）、”$TITLE2_OPE”（装置ＰＣ２）で定義した制御状態、即ち、“操作画面”（装置ＰＣ１）、“Operation Page”（装置ＰＣ２）であれば、状態管理テーブルに”OPE”の状態変数あるいは文字列を保持する。”&ST_SET”（００２３）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”Visible”（１００７）コマンドに変換される。”&ST_SET”（００３１）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”status”（２００７）コマンドに変換される。

論理シナリオ（図９）の”&CLK_BTN”（００３３）コマンドにより、装置ＰＣ１で起動したアプリケーションのウィンドウの状態が”OPE”の状態であることを条件として、装置ＰＣ１のウィンドウの”BTN1”ボタンを押下する。” &CLK_BTN”（００３３）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”ClkItem”（１００８）コマンドに変換される。

論理シナリオ（図９）の”&ST_SET”（００３５）コマンドにより、装置ＰＣ２で起動したアプリケーションのウィンドウの状態が”OPE”の状態であることを条件として、装置ＰＣ２のウィンドウの”Status”が”オペ１“の状態であれば、状態管理テーブルに”OPE2”の状態変数あるいは文字列を保持する。”&ST_SET”（００３５）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”status”（２００８）コマンドに変換される。

論理シナリオ（図９）の”&CLK_BTN”（００３６）コマンドにより、装置ＰＣ２で起動したアプリケーションのウィンドウの状態が”OPE2”の状態であることを条件として、装置ＰＣ２のウィンドウの”OP1”ボタンを押下する。”&CLK_BTN”（００３６）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”clk”（２００９）コマンドに変換される。

論理シナリオ（図９）の”&ST_SET”（００３８）コマンドにより、装置ＰＣ１で起動したアプリケーションのウィンドウの状態が”OPE”の状態であることを条件として、装置ＰＣ１のウィンドウの“操作状態”が”Ope1”の状態であれば、状態管理テーブルに”OPE1”の状態変数あるいは文字列を保持する。”&ST_SET”（００３８）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”Visible”（１００９）コマンドに変換される。

論理シナリオ（図９）の”&CLK_BTN”（００３９）コマンドにより、装置ＰＣ１で起動したアプリケーションのウィンドウの状態が”OPE1”の状態であることを条件として、装置ＰＣ１のウィンドウの“終了”ボタンを押下する。”&CLK_BTN”（００３９）コマンドは、装置ＰＣ１について準物理シナリオ（図１０）および物理シナリオ（図１２）の”ClkItem”（１０１０）コマンドに変換される。

論理シナリオ（図９）の”&CLK_BTN”（００４１）コマンドにより、装置ＰＣ２で起動したアプリケーションのウィンドウの状態が”OPE2”の状態であることを条件として、装置ＰＣ２のウィンドウの”EXIT”ボタンを押下する。”&CLK_BTN”（００４１）コマンドは、装置ＰＣ２について準物理シナリオ（図１１）および物理シナリオ（図１３）の”clk”（２０１０）コマンドに変換される。

以上、詳細に説明したように、実施形態によれば、テスト制御部（２−１）には、装置または／およびＧＵＩの違いに依存しない論理シナリオ（２−２）が格納されており、装置または／およびＧＵＩの違いを吸収することができる。装置やＧＵＩの別によらず、ＧＵＩ上での実行手順、ＧＵＩの状態判断、実行結果の取得などを統一的に記述することができる。複数の装置間または／およびＧＵＩ間での連携制御・同期実行を統一的に記述することができる。

第２変換制御部（２−１０）では、準物理シナリオ中に記述されている状態把握の指示や状態取得の指示に従い、ＧＵＩ上の状態の把握や取得〜保持が行われる。テスト制御部（２−１）によるテストシナリオの遠隔制御においても、個々の装置やＧＵＩにおける状態を把握して連携制御を確実に行うことができる。また、取得された状態を状態管理テーブル（２−１０ｆ）に保持して、状態の把握を簡易に行うことができる。各装置やＧＵＩにおける制御状態を簡易に管理することができ、ＧＵＩ上の操作実行に不適格な状態や操作実行の失敗などを容易に検出することができる。

ここで、状態管理テーブル（２−１０ｆ）における状態の保持は、状態取得コマンド（&ST_SET等）により取得された状態を状態変数あるいは状態を示す文字列の形態で保持することにより行うことができる。これにより、コマンド実行の際にＧＵＩ上の状態の判断は、状態変数あるいは状態を示す文字列が保持されているか否かにより行うことができる。状態の確認処理といった処理の煩雑さを解消してテストシナリオを簡略化することができる。更に、状態確認を行う際の処理時間の短縮を図ることができる。一連のコマンド列を遅滞なく実行することができる。

尚、実施形態に開示された態様以外にも、種々の改良、変更が可能であることは言うまでもない。
例えば、実施形態では、複数の装置で構成されているＧＵＩソフトウェアをテストする場合について説明したが、本願はこれに限定されるものではない。単一の装置やＧＵＩに対しても適用することができる。即ち、装置上で稼働するＧＵＩの種別に関わらず、同じテストシナリオでテスト行うことができる。
また、実施形態では、１つのＧＵＩ上の状態を把握する場合について説明したが、複数の装置または／ＧＵＩの状態を取得してこれらの状態の組み合わせに応じてコマンドを実行する構成とすることができることは言うまでもない。

（１−１）、（２−１） テスト制御部
（１−５）、（２−５） 装置ＰＣ１
（１−５’）、（２−５’） 装置ＰＣ２
（１−７） 実行制御部１
（１−８） ＧＵＩ１
（１−８’） ＧＵＩ２
（２−２） 論理シナリオ
（２−３） 第1変換制御部
（２−３ａ） 論理シナリオ読出部
（２−３ｂ） 論理シナリオ実行部
（２−３ｃ） シナリオ論理／物理変換部
（２−３ｄ） 実行ログ論理／物理変換部
（２−３ｅ） 実行ログ記録部
（２−３ｆ） 論理／物理変換テーブル
（２−４） 論理実行ログ
（２−１０） 第２変換制御部
（２−１０ａ） 物理シナリオ受信部
（２−１０ｂ） 物理シナリオ実行部
（２−１０ｃ） 状態管理判定部
（２−１０ｄ） 実行状態管理部
（２−１０ｅ） 実行ログ送信部
（２−１０ｆ） 状態管理テーブル

Claims (5)

1. グラフィカル・ユーザ・インターフェースを利用したソフトウェアのテストをコンピュータに実行させるテスト支援方法であって、
   前記グラフィカル・ユーザ・インターフェースの指定状態を検出するコマンドを付加した共通様式のシナリオを、前記グラフィカル・ユーザ・インターフェースに応じた様式のコマンドに変更して、指示するステップと、
   前記グラフィカル・ユーザ・インターフェースの状態が前記指定状態であるか判断するステップと、
   前記判断するステップで、前記グラフィカル・ユーザ・インターフェースが前記指定状態にあると前記コマンドを実行するステップとが行われることを特徴とするテスト支援方法。
2. 前記ソフトウェアが複数の処理装置の間で連携して動作する場合、
   前記コマンドは、前記処理装置で稼働する前記グラフィカル・ユーザ・インターフェースを特定する識別子を備えることを特徴とする請求項１に記載のテスト支援方法。
3. 前記指示するステップでは、前記コマンドの書式を、前記グラフィカル・ユーザ・インターフェースに適合した固有書式に変換し、
   前記実行するステップにおける実行結果を、共通書式に変換して返送するステップを追加することを特徴とする請求項２に記載のテスト支援方法。
4. 前記グラフィカル・ユーザ・インターフェースの状態を状態変数として保持し、前記指定状態が、保持された前記前記状態変数と一致すれば、前記コマンドを実行するステップが行われることを特徴とする請求項１乃至３の少なくとも何れか１項に記載のテスト支援方法。
5. グラフィカル・ユーザ・インターフェースを利用したソフトウェアのテストをコンピュータに実行させるテスト支援装置であって、
   前記グラフィカル・ユーザ・インターフェースの指定状態を検出するコマンドを付加した共通様式のシナリオを、前記グラフィカル・ユーザ・インターフェースに応じた様式のコマンドに変更して、指示する変更指示部と、
   前記グラフィカル・ユーザ・インターフェースの状態が前記指定状態であるか判断する判断部と、
   前記判断するステップで、前記グラフィカル・ユーザ・インターフェースが前記指定状態にあると前記コマンドを実行する実行部とを備えたことを特徴とするテスト支援装置。

Images