JP6635963B2 - モデル駆動手法による自動化されたユーザインターフェース（ｕｉ）テストのための方法およびシステム - Google Patents

Description

優先権の主張
本特許出願は、参照によりその全体が本願明細書に援用される、２０１６年３月２２出願のインド特許出願第２０１６２１０１００２９号の優先権を主張する。

技術分野
本願は、全般的に、ユーザインターフェース（ＵＩ：ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）のテストケースモデリングに関する。特に本願は、基礎をなすモデル駆動ＵＩ生成フレームワークを利用することでテストケースモデルを作成する方法およびシステムを提供する。

アプリケーションのユーザインターフェース（ＵＩ）は、ダイアログなどの多数の要素（例えばポップアップウィンドウ、画面など）を含み、それらはそれぞれ、テキスト領域またはテキストボックス、テキストを伴うボタンなどといった１つ以上のコントロールを含み得る。製品が開発されるとき、ＵＩ要素が変化し、欠陥またはバグをＵＩにもたらすことがあり得、これがアプリケーションの重大な障害を引き起こすことも十分にあり得る。この問題を悪化させるのが、アプリケーション開発者は、頻繁に、新機能の追加、ＵＩの更新、およびアプリケーションの新バージョンのリリースをするよう迫られているということである。結果として、当初のテストスクリプトが後の改訂されたアプリケーションを十分にテストできることは稀である。

既存の取り組みでは、ＵＩアプリケーションを手動でテストするのは、手間がかかり誤りが生じやすく、困難であることが認識された。したがって、既存のソリューションの大部分は、ＵＩアプリケーションのテストを自動化することに頼る。ＵＩアプリケーションのテストを自動化するために、テストエンジニアは、スクリプト言語（例えばＪａｖａＳｃｒｉｐｔ（登録商標）およびＶＢＳｃｒｉｐｔ）を使用してプログラムを書く。ＵＩオートメーションテストスクリプトを書くのは、テストケースを書くのに使用されるテストスクリプト言語の効果的かつ正しい知識を要求する難易度の高い作業である。さらに、ＵＩオートメーションテストケースを手動で書くには、かなりの試行錯誤および労力消費が要求される。さらに、テストスクリプト言語のシンタックスに何らかの更新もしくは修正があったり、または別のスクリプト言語でテストスクリプトを書く要求があったりした場合には、手直しのために相当量の労力が必要とされる。

さらに、従来の手法は、手動オートメーションテストケースのテストデータが、各テストケースに対し必ず手動で指定されるべきであると要求し、このことが、異なるテストデータを伴う同じテストケースを使用して回帰テストを作成することを、手間がかかり労力を消費する業務にしている。

前述のテストの問題は、同じアプリケーションがいくつかの異なるコンピュータオペレーティングシステム上で全く同じに動作することを期待されるという事実により複雑化している。例えば、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションは、典型的には世間一般に現在使用されている、すべてまたはほとんどのＭｉｃｒｏｓｏｆｔ（登録商標）オペレーティングシステムと協働することを期待される。

従来技術の文献には、ユーザインターフェースから直接にテストケースを生成することを開示するものもある。ユーザインターフェースから直接にテストケースを生成するプロセスは、技術またはプラットフォーム駆動型であり、技術またはプラットフォーム独立型ではなく、テストケースを実装、維持、または移行するのに要求される労力を大幅に増大させる。さらに、テストケースを実装、維持、または移行することは、ＵＩに変更が加えられる場合には難易度がより高くなる。

他の一連の従来技術文献は、テストスクリプトの生成に抽象モデルを利用し、すなわち、ソフトウェアテストのためにモデルベースのテストコード生成を実装する。しかしながら、従来技術の文献は、既存かつ既に実行中のアプリケーションから直接にテストスクリプトを生成する手法を実装する。実行中のアプリケーションから直接にテストスクリプトを生成することは、テストスクリプト実行のカスタマイズ性が低減するという欠点を有する。既存の技術のもう１つの障害は、実行時中にＵＩモデルをテストするためのテストケースの生成を自動化することにある。

モデル駆動生成手法を、テストケースの仕様が実装から分離されるような形で活用できれば有利であろう。技術、プラットフォーム、スクリプト言語などからの独立の点でより優れたカスタマイズ性を有するテストケースの生成を自動化するメカニズムを得るニーズがある。したがって、テストケースの自動的な生成および検証にモデル駆動手法を活用することは、依然としてこの技術領域の最大の課題の１つであると考えられる。

本発明によれば、主たる目的は、ＵＩモデルコンテンツからテストケースモデルを自動的に指定する方法およびシステムを提供することである。

本発明の１つの目的は、ＵＩモデル要素における関連する変化に対応するテストケースモデルを自動更新処理する方法およびシステムを提供することである。

本発明の別の目的は、テストケースモデルから任意の技術向けのオートメーションテストケースをシングルクリック生成する方法およびシステムを提供することである。

本発明のさらに別の目的は、ＵＩモデルとＵＩテストケースとをモデルレベルで自動的に同期させることにより、生成されたＵＩ画面上での生成されたテストスクリプトのシームレスな実行を促進する方法およびシステムを提供することである。

本発明の別の目的は、テストケースモデルを、技術から独立した形で指定および記憶することにより、任意の技術でテストケースを生成する方法およびシステムを提供することである。

以下の説明を添付の図面と併せて読むことで、本発明の他の目的および利点がより明らかとなる。図面は、本開示の範囲を限定するよう意図されてはいない。

本開示に明示的に示されない本発明の可能な実施形態は複数あり得るので、本発明は記載される特定のシステムおよび手順に限定されないということを、本方法、システム、およびハードウェアの実施可能性の説明の前に理解されたい。さらに、本記載で使用される用語は、特定のバージョンまたは実施形態を記載することのみを目的としており、添付の特許請求の範囲によってのみ限定される本発明の範囲を限定する意図はないということも理解されたい。

本願は、モデル駆動手法による自動化されたＵＩテストのための方法およびシステムを提供する。

或る実施形態において、モデル駆動手法による自動化されたＵＩテストのための方法が開示される。本方法は、ＵＩモデルを選択するように構成されたプロセッサを備え、プロセッサは、選択されたＵＩモデルのためのテストケースモデルを作成して作成されたテストケースモデルをテストケースエディタ（２２２）に投入するようさらに構成され、テストケースモデルは、選択されたＵＩモデルの構造パターンに基づくＵＩアクションのシーケンスとして作成され、プロセッサは、選択されたＵＩモデルのためのテストケースモデルを検証するようさらに構成される。さらに、プロセッサは、選択されたＵＩモデルのためのテストケースモデルからテストケーススクリプトを生成するように構成される。

別の実施形態において、本願は、モデル駆動手法による自動化されたＵＩテストのためのシステム（１０２）を開示する。システム（１０２）は、プロセッサ（２０２）と、前記プロセッサに接続されたメモリ（２０６）とを備え、システムは、ユーザインターフェース（ＵＩ）モデルを選択するように構成された選択モジュール（２１０）をさらに備える。システムは、選択されたＵＩモデルのためのテストケースモデルを作成して作成されたテストケースモデルをテストケースエディタ（２２２）に投入するように構成されたテストケースモデル作成モジュール（２１２）であって、テストケースモデルは、選択されたＵＩモデルの構造パターンに基づくＵＩアクションのシーケンスとして作成される、テストケースモデル作成モジュール（２１２）をさらに備える。システムは、選択されたＵＩモデルのためのテストケースモデルを検証するように構成された検証モジュール（２１４）をさらに備える。さらにシステムは、選択されたＵＩモデルのためのテストケースモデルからテストケーススクリプトを生成するように構成されたスクリプト生成モジュール（２１６）を備える。

前述の概要ならびに以下の好適な実施形態の詳細な説明は、添付の図面と併せて読まれるとよりよく理解される。本発明を説明する目的で、図面には、本発明の例示的な構成が示されているが、本発明は、開示される特定の方法およびシステムに限定されない。

モデル駆動手法による自動化されたＵＩテストのためのシステム（１０２）を示すネットワーク実装を示す。 モデル駆動手法による自動化されたＵＩテストのためのシステム（１０２）を示すブロック図を示す。 モデル駆動手法による自動化されたＵＩテストのための方法を示すフローチャートを示す。 選択されたＵＩモデルに対応するテストケースモデルをイベント中心型アプローチを利用して作成する高水準プロセスを示すフローチャートを示す。 選択されたＵＩモデルに対応するテストケースモデルをユーザインタラクション中心型アプローチを利用して作成する高水準プロセスを示すフローチャートを示す。

本発明のあらゆる特徴を示す、本発明のいくつかの実施形態を、以下に詳細に説明する。

「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「有する（ｈａｖｉｎｇ）」「含んでいる（ｃｏｎｔａｉｎｉｎｇ）」、および「含む（ｉｎｃｌｕｄｉｎｇ）」という語、ならびにこれらの他の形態は、意味において等価であるものとし、これらの語の任意のものに続く１つまたは複数の項目がそのような１つまたは複数の項目の網羅的な列挙としては意図されておらず、列挙された１つまたは複数の項目のみに限定されることも意図されていないという点で、オープンエンド型であるものとする。

さらに、本願明細書および添付の特許請求の範囲で使用される単数形の「ａ」、「ａｎ」および「ｔｈｅ」は、文脈により別段明確に規定されない限り、複数の指示を含むことに留意されたい。本願明細書に記載されるものに類似する、またはそれらと等価な任意のシステムおよび方法が、本発明の実施形態の実施またはテストにおいて使用され得るが、以下、好適なシステムおよび方法を記載する。

開示された実施形態は、単に本発明の例示に過ぎず、様々な形態で具現化され得る。

図面に示された要素は、さらに詳しく後述されるとおり、相互に作用する。なお、詳細な説明を記載する前に指摘しておくが、記載される特定の実装形態にかかわらず、下記の検討はすべて本質的に限定ではなく例示である。例えば、各実装の選択された側面、特徴、またはコンポーネントがメモリに記憶されるものとして示されるが、消耗警告システムおよび方法に適合するシステムおよび方法の全部または一部が、他の機械可読媒体に記憶、分散され、またはそれらから読み取られてもよい。

上述の手法は、プロセッサ、プロセッサにより読み取り可能および／または書き込み可能な記憶媒体（例えば揮発性および不揮発性のメモリおよび／または記憶要素を含む）、複数の入力ユニット、ならびに複数の出力デバイスのうちの任意数のものの任意の組み合わせを含むプログラマブルコンピュータ上で実行される（またはそれにより実行可能な）、１つ以上のコンピュータプログラムに実装されてもよい。プログラムコードは、記載される機能を実行するため、および複数の出力デバイスのいずれかに表示される出力を生成するために、複数の入力ユニットのいずれかを使用して入力される入力に適用されてもよい。

添付の特許請求の範囲に記載の範囲内の各コンピュータプログラムは、アセンブリ言語、機械語、高水準手続型プログラミング言語、またはオブジェクト指向プログラミング言語などの任意のプログラミング言語で実装されてもよい。プログラミング言語は、例えば、コンパイル型または解釈型のプログラミング言語であってもよい。そのようなコンピュータプログラムはそれぞれ、コンピュータプロセッサによる実行のために機械可読記憶デバイスに有形に具現化されたコンピュータプログラム製品に実装されてもよい。

本発明の方法ステップは、入力に作用して出力を生成することにより本発明の機能を実行するためにコンピュータ可読媒体上に有形に具現化されたプログラムを実行する１つ以上のコンピュータプロセッサにより実行されてもよい。適切なプロセッサは、例として、汎用および専用両方のマイクロプロセッサを含む。一般に、プロセッサは、メモリ（読み取り専用メモリおよび／またはランダムアクセスメモリなど）から命令およびデータを受信（読み取り）し、メモリに命令およびデータを書き込み（記憶）する。コンピュータプログラム命令およびデータを有形に具現化するのに適した記憶デバイスは、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、およびフラッシュメモリデバイスを含む半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能ディスクなどの磁気ディスク、光磁気ディスク、ならびにＣＤ−ＲＯＭなど、あらゆる形式の不揮発性メモリを含む。前述のもののうち任意のものは、特別に設計されたＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：特定用途向け集積回路）またはＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ：フィールドプログラマブルゲートアレイ）により補完されること、またはそれに組み込まれることが可能である。コンピュータは、一般に、内蔵ディスク（図示せず）または取り外し可能ディスクなどの非一時的コンピュータ可読記憶媒体からプログラムおよびデータを受信（読み取り）し、それにプログラムおよびデータを書き込み（記憶）することもできる。

本願明細書で開示される任意のデータは、例えば、非一時的コンピュータ可読媒体上に有形に記憶された１つ以上のデータ構造に実装されてもよい。本発明の実施形態は、当該データを当該データ構造（単数または複数）に記憶し、当該データを当該データ構造（単数または複数）から読み取ってもよい。

本願は、モデル駆動手法による自動化されたＵＩテストのためのコンピュータに実装された方法およびシステムを提供する。

図１は、本主題の実施形態による、モデル駆動手法による自動化されたＵＩテストのためのシステムのネットワーク実装を示す。本主題は、システム１０２がサーバ上に実装されているものと考えて説明されるが、当然のことながらシステム１０２は、ラップトップコンピュータ、デスクトップコンピュータ、ノートブック、ワークステーション、メインフレームコンピュータ、サーバ、ネットワークサーバなどの多様なコンピューティングシステムにも実装され得る。一実装形態において、システム１０２は、クラウドベースの環境に実装されてもよい。当然のことながら、システム１０２は、下記ではユーザデバイス１０４と総称される１つ以上のユーザデバイス１０４−１、１０４−２…１０４−Ｎ、またはユーザデバイス１０４上に存在するアプリケーションを介して、複数のユーザによりアクセスされてもよい。ユーザデバイス１０４の例は、ポータブルコンピュータ、携帯情報端末、ハンドヘルドデバイス、およびワークステーションを含み得るが、これらに限定はされない。ユーザデバイス１０４は、ネットワーク１０６を介して通信可能にシステム１０２に接続される。

一実装形態において、ネットワーク１０６は、無線ネットワーク、有線ネットワーク、またはそれらの組み合わせであってもよい。ネットワーク１０６は、イントラネット、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、インターネットなどといった様々なタイプのネットワークのうちの１つとして実装可能である。ネットワーク１０６は、専用ネットワークまたは共有ネットワークのいずれかとされ得る。共有ネットワークは、相互通信するために、例えばハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、無線アプリケーションプロトコル（ＷＡＰ：Ｗｉｒｅｌｅｓｓ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などの多様なプロトコルを使用する様々なタイプのネットワークのつながりを表す。さらにネットワーク１０６は、ルータ、ブリッジ、サーバ、コンピューティングデバイス、記憶デバイスなどを含む多様なネットワークデバイスを含んでもよい。

図２を参照しながら、開示される主題の実施形態による、システム１０２の様々なコンポーネントの詳細な機能について記載する。

図２を参照する本発明の一実施形態において、モデル駆動手法による自動化されたＵＩテストのためのシステムが開示される。一実施形態において、システム（１０２）は、メモリに記憶された命令を実行することにより機能を実行するプロセッサ（２０２）と、通信可能に前記プロセッサに接続されたメモリ（２０６）とを備える。別の実施形態において、システムは、ＵＩテストを要求するようなアプリケーションからのＵＩに対応するＵＩモデルを選択するように構成された選択モジュール（２１０）を備える。別の実施形態において、１つ以上のアプリケーションに対応するＵＩモデルは、記憶モジュール（２２４）に記憶されている。さらに、テストケースモデル作成モジュール（２１２）は、選択されたＵＩモデルのためのテストケースモデルを作成して、作成されたテストモデルをテストケースエディタ（２２２）に投入するように構成されてもよい。一側面において、テストケースモデルは、選択されたＵＩモデルの構造パターンに基づくＵＩアクションのシーケンスとして作成されてもよい。別の側面において、テストケースエディタ（２２２）は、テストケースモデルを表示してテストケースモデルを編集するように構成されてもよい。さらに別の側面において、テストケースエディタ（２２２）は、テストケースモデルの新たなステップを追加すること、既存のステップを修正すること、既存のステップを記録すること、および既存のステップを削除することによりテストケースモデルを編集するように構成されてもよい。

さらにシステムは、テストケースモデルを、対応するＵＩモデルと対照して検証するように構成された検証モジュール（２１４）を備える。テストケースモデルの検証は、ルールエンジン（２２０）に基づきテストケースモデルを評価することを含んでもよい。ルールエンジン（２２０）は、テストケースモデルの完全性、一貫性、および正当性を確保する一連の所定のルールおよび制約を備えてもよい。さらに、テストケースモデルの検証は、ＵＩモデルと対照したテストケースモデルの構文上および意味上の評価を含んでもよいが、これに限定はされない。或る実施形態では、前記ルールおよび制約は、実行されるとスクリプトにエンコードされた前記ルールおよび制約それぞれにテストケースモデルが忠実であるかどうかを評価する、該スクリプトにエンコードされてもよい。違反が発生した場合には、検証は失敗したとマークされる。例えば、整数値をとるフィールドは、文字列型のサービスパラメータにマッピングされることはできない。その後、スクリプト生成モジュール（２１６）は、検証されたテストケースモデルからターゲットプラットフォーム用のテストケーススクリプトを生成するように構成されていてもよい。さらに、生成されたテストスクリプトは、対応するＵＩアプリケーションをテストするために使用される。

或る実施形態において、テストケースモデル作成モジュール（２１２）が、指定されたＵＩモデルのためのテストケースモデルを作成してから、作成されたテストケースモデルをテストケースエディタ（２２２）に投入するように構成されてもよい。指定されたモデルのためのテストケースモデルの作成は、（ｉ）イベント中心型アプローチ、（ｉｉ）ユーザインタラクション中心型アプローチ、またはイベント中心型アプローチとユーザインタラクション中心型アプローチとの組み合わせに基づいてもよい。前記モデルの選択は、ユーザインターフェース（ＵＩ）が開発段階にあるかまたは開発済みであるかの考慮に基づいてもよい。好適な実施形態において、イベント中心型アプローチは、ＵＩ開発の間、進行中ＵＩ画面で個々のイベントを単体テストする必要性があるときに、テストケースのモデリングに使用されてもよい。別の好適な実施形態において、ユーザインタラクション中心型アプローチは、既に実装されたＵＩ画面をユーザインタラクション中心型アプローチからテストする必要性があるときに、テストケースのモデリングに使用されてもよい。本願の主題を提示する時点で当業者には明白であろうが、テストケースモデルは、図４および図５でそれぞれ明らかにされるようなイベント中心型アプローチおよびユーザインタラクション中心型アプローチに基づき実装され得るイベント中心型ステップおよびユーザインタラクション中心型ステップの組み合わせに基づき作成され得る。

別の実施形態では、同期モジュール（２１８）は、選択されたＵＩモデルのためのテストケースモデルと、選択されたＵＩモデルとを、選択されたＵＩモデルの構造パターンに基づくＵＩアクションのシーケンスとして同期させるように構成されてもよい。ＵＩアクションのランダム性が原因で、ＵＩモデルに変化が発生する。ＵＩモデルにおける変化と、選択されたＵＩモデルのためのテストケースモデルとが自動的に同期されることを保証するために、システムは同期モジュール（２１８）を実装する。さらに同期モジュール（２１８）は、ＵＩモデルにおける変化を監視し、その変化と、対応するテストケースモデルとを自動的に同期させるように構成される。

さらに別の実施形態では、テストケースエディタ（２２２）は、テストケースモデルを表示して、ユーザが新たなステップを追加し、既存のステップを修正し、既存のステップを記録し、既存のステップを削除するためのハンドルを提供するように構成されてもよい。さらに、テストケースエディタ（２２２）は、テストケースモデルの検証およびテストケースモデルからのテストスクリプトの生成をトリガするためのハンドルを提供する。さらにテストケースエディタ（２２２）は、自動的にリフレッシュして、ＵＩモデルの変化に対応してテストケースモデルにおいて発生する変化を反映するように構成されてもよい。

さらに別の実施形態において、モデル駆動ＵＩモデリング・生成フレームワークの一部としての記憶モジュール（２２４）は、１つ以上のアプリケーションに対応する１つ以上のＵＩモデルを記憶しそれにアクセスするように構成されてもよい。記憶モジュール（２２４）はさらに、テストケースモデルおよび編集されたテストケースモデルをＵＩモデルとともに記憶してそれにアクセスするように構成されてもよい。

或る実施形態では、検証されたテストケースモデルからスクリプト生成モジュール（２１６）を使用して生成されたテストスクリプトが、自動化された実行システムにおいて、テスト実行エンジンを使用して実行されてもよい。自動化された実行システムは、テストデータとともにテストスクリプトが実行されるであろう環境に適合するように構成される。テストスクリプトの実行はさらに、ＵＩアプリケーションが期待どおり実行することを証明するためにテスト結果を発生させる。

本主題の方法およびシステムの実施形態は、構造上の特徴および／または方法に特有の文言で記載されたが、当然のことながら、本主題は記載された特定の特徴または方法に必ずしも限定されない。むしろ、特定の特徴および方法は、本主題の例示的な実施形態として開示される。

図３は、本願明細書に開示された主題の実施形態に従った、モデル駆動手法による自動化されたＵＩテストのための方法を示すフローチャートである。図２の例示のとおり、自動ＵＩテストケースモデリング・生成フレームワークは、基礎をなすモデル駆動ＵＩ生成フレームワークを利用する。

プロセスはステップ３０２で開始し、記憶されたユーザインターフェース（ＵＩ）モデルの選択が実行される。選択されたＵＩモデルに対応するテストケースモデルが作成されることから、ＵＩモデルの選択は、テストケースモデルを作成するための最後から２番目のステップとしての機能を果たす。

ステップ３０４にて、選択されたＵＩモデルから作成されたテストケースモデルが、テストケースエディタに投入される。一側面において、テストケースモデルは、選択されたＵＩモデルの構造パターンに基づくＵＩアクションのシーケンスとして自動的に作成されてもよい。別の側面では、テストケースモデルは、一から作成されて編集されてもよい。さらに別の側面において、投入されたテストケースモデルを編集することは、テストケースモデルの新たなステップを追加すること、既存のステップを修正すること、既存のステップを記録すること、および既存のステップを削除することにより実行されてもよい。或る実施形態では、選択されたＵＩモデルに対応するテストケースモデルが作成され、テストケースモデルの作成は、（ｉ）イベント中心型アプローチ、（ｉｉ）ユーザインタラクション中心型アプローチ、またはイベント中心型アプローチとユーザインタラクション中心型アプローチとの双方の組み合わせに基づいてもよい。前記モデルの選択は、ユーザインターフェース（ＵＩ）が開発段階にあるかまたは開発済みであるかの考慮に基づいてもよい。好適な実施形態において、イベント中心型モデルは、ＵＩ開発の間、進行中ＵＩ画面で個々のイベントを単体テストする必要性があるときに、テストケースのモデリングに使用されてもよい。別の好適な実施形態において、ユーザインタラクション中心型モデルは、既に実装されたＵＩ画面をユーザインタラクション中心型アプローチからテストする必要性があるときに、テストケースのモデリングに使用されてもよい。別の実施形態では、選択されたＵＩモデルのためのテストケースモデルと、選択されたＵＩモデルとの同期が、選択されたＵＩモデルの構造パターンから得られたＵＩアクションのシーケンスに基づき実行される。ＵＩアクションのランダム性が原因で、ＵＩモデルに変化が発生する。ＵＩモデルにおける変化と、選択されたＵＩモデルに対応するテストケースモデルとが自動的に同期されることを保証するために、ＵＩモデルにおける変化が監視され、何らかの変化が観測された場合には、その変化と、対応するテストケースモデルとが自動的に同期されて、更新されたテストケースモデルをもたらす。

ステップ３０６にて、テストケースモデルが、対応するＵＩモデルと対照して検証される。テストケースモデルの検証は、テストケースモデルの完全性を保証する一連の所定のルールおよび制約に基づきテストケースモデルを評価することを含んでもよい。さらに、テストケースモデルの検証は、ＵＩモデルと対照したテストケースモデルの構文上および意味上の評価を含んでもよいが、これに限定はされない。或る実施形態では、前記ルールおよび制約は、実行されるとスクリプトにエンコードされた前記ルールおよび制約それぞれにテストケースモデルが忠実であるかどうかを評価する、該スクリプトにエンコードされてもよい。違反が発生した場合には、検証は失敗したとマークされる。例えば、整数値をとるフィールドは、文字列型のサービスパラメータにマッピングされることはできない。

プロセスはステップ３０８にて終了するが、ここで検証されたテストケースモデルから、ターゲットプラットフォームのためにテストスクリプトが生成されてもよい。さらに、生成されたテストスクリプトは、対応するＵＩアプリケーションをテストするために使用される。或る実施形態では、ＵＩモデル、テストケースモデル、および編集されたテストケースモデルは、記憶モジュール（２２４）に記憶およびアクセスされてもよい。

当業者であれば当然のことながら、図３の方法は開示された主題をもたらす方法を示すが、一方で本方法は、１つ以上のステップを省いて任意の順序で、または任意のステップを任意の順序で実行して使用されてもよく、それも開示される主題の一部をなす。

図４は、選択されたＵＩモデルに対応するテストケースモデルをイベント中心型アプローチを利用して作成する高水準プロセスを示すフローチャートである。

或る実施形態では、図４は、選択されたＵＩモデルに対応するテストケースモデルの作成のためのイベント中心型アプローチの応用の例示である。図４により示されるとおり、イベント中心型アプローチは、テストを作成することまたは既存のテストケースを開くことを含む。さらにこのプロセスは、前記作成されたテストケースまたは既存のテストケースにテストステップを追加することを伴う。テストステップは、テストケースのモデリングが完了するまでテストケースに追加される。テストケースモデリングが完了され、テストケースに追加すべきテストステップがそれ以上残っていない場合には、ＵＩアクションが保存される。テストケースモデリングが完了されない場合には、ＵＩアクションを作成するためにテストステップがテストケースに追加されてもよい。さらにこのプロセスは、データ指定、イベント指定、およびＵＩ要素指定の要求を確認するステップを含む。さらに、データ指定、イベント指定、および前記イベントをトリガするＵＩ要素のうちいずれか１つが要求される場合、前記要求に基づき、プロセスは、データ指定、イベント指定、およびＵＩ要素を指定するようユーザに促す。前記プロセスは、テストケースモデリングが完了されＵＩアクションが保存されるまで何度も繰り返す。

例示的な実施形態において、図４を参照しながら、イベント中心型アプローチにおける特定のＵＩアクションを明らかにする例示が提示される。例えば、サービスへの入力の１つとして機能するテキストボックスにデータをセットするＵＩアクションを作成するＵＩアクションは、（ｉ）ＵＩアクションを作成するステップ、（ｉｉ）テキストボックスにセットされるべきデータが指定されるステップ、（ｉｉｉ）データがセットされる必要のある要求されるテキストボックスを選択するステップを含む。プロセスは、テストケースモデリングが完了された場合にはテストケースの保存においてＵＩアクションを保存することで終了し、さもなければプロセスは、新たなＵＩアクション／テストステップを作成すること、または既存のＵＩアクション／テストステップを修正／削除することにより繰り返す。

例示的な別の実施形態において、図４を参照しながら、イベント中心型アプローチにおける特定のＵＩアクションを明らかにする例示が提示される。例えば、結果としてサービスを呼び出す、ボタンのクリックイベントをトリガするＵＩアクションは、（ｉ）ＵＩアクションを作成するステップ、（ｉｉ）イベント指定がクリックイベントとして指定されるステップ、（ｉｉｉ）イベントをトリガするＵＩ要素としてのボタンの選択のステップを含む。プロセスは、テストケースモデリングが完了された場合にはテストケースを保存することで終了し、さもなければプロセスは、新たなＵＩアクション／テストステップを作成すること、または既存のＵＩアクション／テストステップを修正／削除することにより繰り返す。

例示的なさらに別の実施形態において、図４を参照しながら、イベント中心型アプローチにおける特定のＵＩアクションを明らかにする例示が提示される。例えば、サービスによりデータセットをテキストボックス内にアサートするＵＩアクションは、（ｉ）ＵＩアクションを作成するステップ、（ｉｉ）サービスから予期されるデータを指定するステップ、（ｉｉｉ）サービスからのデータがセットされるテキストボックスを指定するステップを含む。プロセスは、テストケースモデリングが完了された場合にはテストケースを保存することで終了し、さもなければプロセスは、新たなＵＩアクション／テストステップを作成すること、または既存のＵＩアクション／テストステップを修正／削除することにより繰り返す。

図５は、ユーザインタラクション中心型アプローチを利用して選択されたＵＩモデルに対応するテストケースモデルを作成する高水準プロセスを示すフローチャートである。

或る実施形態では、図５は、選択されたＵＩモデルに対応するテストケースモデルの作成のためのユーザインタラクション中心型モデルの応用の例示である。図５により示されるとおり、ユーザインタラクション中心型アプローチは、テストケースを作成することまたは既存のテストケースを開くことを含む。さらにこのプロセスは、前記作成されたテストケースまたは既存のテストケースにテストステップを追加することを伴う。テストステップは、テストケースのモデリングが完了するまでテストケースに追加される。テストケースモデリングが完了され、テストケースに追加すべきテストステップがそれ以上残っていない場合には、ＵＩアクションが保存される。テストケースモデリングが完了されない場合には、ＵＩアクションを作成しＵＩアクションタイプを指定するためにテストステップがテストケースに追加されてもよい。さらにプロセスは、テストスコープデータの要求およびアクションターゲットの存在を確認するステップを含む。さらにプロセスは、テストスコープデータが要求される場合にはテストスコープデータを、さらにアクションターゲットが存在すると分かった場合にはＵＩアクションを呼び出すＵＩ要素指定を指定するようユーザに促すことを伴う。前記プロセスは、テストケースモデリングが完了されＵＩアクションが保存されるまで何度も繰り返す。

例示的な実施形態において、図５を参照しながら、ユーザインタラクション中心型アプローチにおける特定のＵＩアクションを明らかにする例示が提示される。例えば、サービスへの入力の１つとして機能するテキストボックスにデータをセットするＵＩアクションは、（ｉ）ＵＩアクションを作成するステップ、（ｉｉ）ＵＩアクションタイプとして「データをセット」を選択するステップ、（ｉｉｉ）要求されるテキストボックスをアクションターゲットとして選択するステップを含む。プロセスは、テストケースモデリングが完了された場合にはテストケースを保存することで終了し、さもなければプロセスは、新たなＵＩアクション／テストステップを作成すること、または既存のＵＩアクション／テストステップを修正／削除することにより繰り返す。

例示的な別の実施形態において、図５を参照しながら、ユーザインタラクション中心型アプローチにおける特定のＵＩアクションを明らかにする例示が提示される。例えば、ボタンをクリックするＵＩアクションは、（ｉ）ＵＩアクションを作成するステップ、（ｉｉ）ＵＩアクションタイプとして「クリック」を選択するステップ、（ｉｉｉ）クリックＵＩアクションタイプが呼び出されるアクションターゲットとしてボタンを選択するステップを含む。プロセスは、テストケースモデリングが完了された場合にはテストケースを保存することで終了し、さもなければプロセスは、新たなＵＩアクション／テストステップを作成すること、または既存のＵＩアクション／テストステップを修正／削除することにより繰り返す。

例示的なさらに別の実施形態において、図５を参照しながら、ユーザインタラクション中心型アプローチにおける特定のＵＩアクションを明らかにする例示が提示される。例えば、サービスによりデータセットをテキストボックス内にアサートするＵＩアクションは、（ｉ）ＵＩアクションを作成するステップ、（ｉｉ）ＵＩアクションタイプとして「データをアサート」を選択するステップ、（ｉｉｉ）予期されるデータがコンテンツにアサートされる要求されるテキストボックスをアクションターゲットとして選択するステップを含む。プロセスは、テストケースモデリングが完了された場合にはテストケースを保存することで終了し、さもなければプロセスは、新たなＵＩアクション／テストステップを作成すること、または既存のＵＩアクション／テストステップを修正／削除することにより繰り返す。

本願において開示されるような、所定の構造パターンを持つＵＩモデルからＵＩテストケースモデルを生成する手法は、テストケースモデルを手動で作成する労力および時間を節約する。さらに、ＵＩモデルからＵＩテストケースモデルを作成することは、ＵＩとテストケースとの間の同期を保証する。さらに、テストケースモデルからテストケーススクリプトを生成することは、テストケーススクリプト技術のアップグレードを行う間、またはより新たな技術に移行する間の手直しをなくす。開示された本方法およびシステムはさらに、テストケース実装者が、技術とは独立した形でテストケースの実装に集中することを促進し、必要なテストケース生成技術を選ぶ柔軟性をテストの専門家に提供する。

或る実施形態において、選択されたＵＩモデルのＵＩアクションの構造パターンから得られるＵＩアクションは、当技術分野で周知のＵＩアクションを含む。例えば、ＵＩアクションは、テスト中のアプリケーション内のテキスト、ツリーノード、およびコントロールのクリック、ダブルクリック、またはドラッグ、ウィンドウの最小化および最大化、フォーカス制御、テキストボックスに文字列をセットすること、ドロップダウンにデータをアサートすること、ボタンをクリックすること、ならびにその他標準的なＵＩアクションを含んでもよいが、これらに限定はされない。

或る実施形態では、自動化されたテストにおいて使用されるテストスクリプト言語は、ＪａｖａＳｃｒｉｐｔ（登録商標）、Ｐｅｒｌ、Ｐｙｔｈｏｎ、Ｒｕｂｙ、Ｔｃｌ、Ｕｎｉｘ（登録商標） Ｓｈｅｌｌスクリプト、ＶＢｓｃｒｉｐｔ、Ｓｉｋｕｌｉを含み得るがこれらに限定はされない。本発明は、ＵＩモデルからの（ＵＩ）テストスクリプトの自動化された生成のためのシステムおよび方法を実装する。テストスクリプトは、前述のスクリプト言語のいずれかを、当技術分野で周知の他のものとともに使用して書かれてもよい。

本開示および各例は、例示的でしかないとみなされ、開示された実施形態の真の範囲および意図は、添付の特許請求の範囲により示されるものとする。

Claims (13)

1. モデル駆動手法による自動化されたユーザインターフェース（ＵＩ）テストのための方法であって、前記方法は、プロセッサに実装される以下のステップ：
   選択モジュール（２１０）を使用してアプリケーションに対応するＵＩモデルを選択するステップと、
   テストケースモデル作成モジュール（２１２）を使用して、前記選択されたＵＩモデルのためのテストケースモデルを作成して前記作成されたテストケースモデルをテストケースエディタ（２２２）に投入するステップであって、前記テストケースモデルは、前記選択されたＵＩモデルの構造パターン上のＵＩアクションのシーケンスに基づいて作成される、ステップと、
   前記選択されたＵＩモデルのための前記テストケースモデルを、検証モジュール（２１４）を使用して検証するステップと、
   前記選択されたＵＩモデルのための前記テストケースモデルからテストケーススクリプトを、スクリプト生成モジュール（２１６）を使用して生成するステップと、
   前記ＵＩアクションのランダム性が原因で、前記選択されたＵＩモデルに発生する変化を監視し、前記変化と、対応するテストケースモデルとを自動的に同期させるステップと、
   を含む、方法。
2. 前記選択されたＵＩモデルのための前記テストケースモデルは、前記ＵＩアクションのシーケンスに基づいて作成され、前記ＵＩアクションのシーケンスは、イベント中心型アプローチおよびユーザインタラクション中心型アプローチのうちの少なくとも１つを備える、請求項１に記載の方法。
3. 前記検証は、ルールエンジン（２２０）が一連の所定のルールを備えるような前記ルールエンジン（２２０）に基づき、前記テストケースモデルを評価するステップを含む、請求項１に記載の方法。
4. 前記方法は、テストケースエディタ（２２２）を使用して前記テストケースモデルを表示して前記テストケースモデルを編集するステップをさらに含み、前記テストケースエディタ（２２２）は、前記テストケースモデルの新たなステップを追加すること、既存のステップを修正すること、既存のステップを記録すること、および既存のステップを削除することのうちの少なくとも１つにより前記テストケースモデルを編集する、請求項１に記載の方法。
5. モデル駆動手法による自動化されたユーザインターフェース（ＵＩ）テストのためのシステム（１０２）であって、前記システムは、プロセッサ（２０２）と、前記プロセッサに接続されたメモリ（２０６）とを備え、前記システムは、
   アプリケーションに対応するＵＩモデルを選択するように構成された選択モジュール（２１０）と、
   前記選択されたＵＩモデルのためのテストケースモデルを作成して前記作成されたテストケースモデルをテストケースエディタ（２２２）に投入するように構成されたテストケースモデル作成モジュール（２１２）であって、前記テストケースモデルは、前記選択されたＵＩモデルの構造パターン上のＵＩアクションのシーケンスに基づいて作成される、前記テストケースモデル作成モジュール（２１２）と、
   前記選択されたＵＩモデルのための前記テストケースモデルを検証するように構成された検証モジュール（２１４）と、
   前記選択されたＵＩモデルのための前記テストケースモデルからテストケーススクリプトを生成するように構成されたスクリプト生成モジュール（２１６）と、
   前記ＵＩアクションのランダム性が原因で、前記選択されたＵＩモデルに発生する変化を監視し、前記変化と、対応するテストケースモデルとを自動的に同期させるように構成された同期モジュール（２１８）と、
   を備える、システム。
6. 前記選択されたＵＩモデルのための前記テストケースモデルは、前記ＵＩアクションのシーケンスに基づいて作成され、前記ＵＩアクションのシーケンスは、イベント中心型アプローチおよびユーザインタラクション中心型アプローチのうちの少なくとも１つを備える、請求項５に記載のシステム。
7. 前記検証は、ルールエンジン（２２０）が一連の所定のルールを備えるような前記ルールエンジンに基づき、前記テストケースモデルを評価することを含む、請求項５に記載のシステム。
8. 前記システムは、前記テストケースモデルを表示して前記テストケースモデルを編集するように構成されたテストケースエディタ（２２２）をさらに備え、前記テストケースエディタ（２２２）は、前記テストケースモデルの新たなステップを追加すること、既存のステップを修正すること、既存のステップを記録すること、および既存のステップを削除することのうちの少なくとも１つにより前記テストケースモデルを編集する、請求項５に記載のシステム。
9. 前記ＵＩモデル、前記テストケースモデル、および編集されたテストケースモデルのうちの少なくとも１つを記憶およびアクセスするように構成された記憶モジュール（２２４）をさらに備える、請求項５に記載のシステム。
10. １つ以上の命令を備えた１つ以上の非一時的機械可読情報記憶媒体であって、前記命令は、１つ以上のハードウェアプロセッサにより実行されると、
    選択モジュール（２１０）を使用してアプリケーションに対応するＵＩモデルを選択することと、
    テストケースモデル作成モジュール（２１２）を使用して、前記選択されたＵＩモデルのためのテストケースモデルを作成して前記作成されたテストケースモデルをテストケースエディタ（２２２）に投入することであって、前記テストケースモデルは、前記選択されたＵＩモデルの構造パターン上のＵＩアクションのシーケンスに基づいて作成される、ことと、
    前記選択されたＵＩモデルのための前記テストケースモデルを、検証モジュール（２１４）を使用して検証することと、
    前記選択されたＵＩモデルのための前記テストケースモデルからテストケーススクリプトを、スクリプト生成モジュール（２１６）を使用して生成することと、
    前記ＵＩアクションのランダム性が原因で、前記選択されたＵＩモデルに発生する変化を監視し、前記変化と、対応するテストケースモデルとを自動的に同期させることと、
    を生じさせる、１つ以上の非一時的機械可読情報記憶媒体。
11. 前記選択されたＵＩモデルのための前記テストケースモデルは、前記ＵＩアクションのシーケンスに基づいて作成され、前記ＵＩアクションのシーケンスは、イベント中心型アプローチおよびユーザインタラクション中心型アプローチのうちの少なくとも１つを備える、請求項１０に記載の１つ以上の非一時的機械可読情報記憶媒体。
12. 前記検証は、ルールエンジン（２２０）が一連の所定のルールを備えるような前記ルールエンジン（２２０）に基づき、前記テストケースモデルを評価することを含む、請求項１０に記載の１つ以上の非一時的機械可読情報記憶媒体。
13. テストケースエディタ（２２２）を使用して前記テストケースモデルを表示し前記テストケースモデルを編集することをさらに含み、前記テストケースエディタ（２２２）は、前記テストケースモデルの新たなステップを追加すること、既存のステップを修正すること、既存のステップを記録すること、および既存のステップを削除することのうちの少なくとも１つにより前記テストケースモデルを編集する、請求項１０に記載の１つ以上の非一時的機械可読情報記憶媒体。

Images