JP6840656B2 - テストスクリプト修正装置及びプログラム - Google Patents

Description

本発明は、テストスクリプト修正装置及びプログラムに関する。

画面の操作を伴うテストを自動化するため手法として、キャプチャ＆リプレイやプログラミングを用いた手法が広く用いられている。

キャプチャ＆リプレイでは、ユーザが画面に対して操作を行うと、ユーザが行った操作がテストスクリプトとして記録される。次回以降のテストでは、当該テストスクリプトを実行することで、自動的にテストを行うことができる。キャプチャ＆リプレイの利点として、プログラミングスキルが無くても、画面操作で簡単にテストスクリプトを実装することができる点が挙げられる。欠点としては、テストスクリプトが操作の羅列として出力されるため、テストスクリプトの可読性が低い点や、テストスクリプトをモジュール化しにくい点が挙げられる。キャプチャ＆リプレイを行うためによく用いられるツールとしては、Selenium IDEや、Selenium Builder等が有る。

一方、プログラミングによる手法では、ＲｕｂｙやＪａｖａ（登録商標）といったプログラミング言語を用いてテストスクリプトの実装が行われる。画面を操作するためのＡＰＩを用いて、テストで行いたい操作を示すプログラムがテストスクリプトとして記述され、当該テストスクリプトを実行することで自動的にテストが行われる。プログラミングによる手法の利点として、柔軟性が高く、実装者のスキルによっては高い保守性が期待できる点が挙げられる。欠点としては、利用するためにプログラミング言語の理解が必要であり、テストスクリプトの質が実装者のスキルに依存してしまう点が挙げられる。Ｗｅｂ画面を操作するためのＡＰＩとして、Selenium WebDriverが有名である。

Maurizio Leotta, Andrea Stocco, Filippo Ricca, Paolo Tonella, Using Multi-Locators to Increase the Robustness of Web Test Cases Internaional Conference on Software Testing, Verification and Validation(ICST) 2015 Shauvik Roy Choudhary, Dan Zhao, Husayn Versee, Alessandro Orso、Water: Web Application TEst Repair、 Proceedings of the First International Workshop on End-to-End Test Script Engineering(ESTE) 2011 Why do Record/Replay Tests of Web Applications Break?, Mouna Hammoudi, Gregg Rothermel,Paolo Tonella, Software Testing, Verification and Validation (ICST) 2016

テストスクリプトは、回帰テストを効率化するために用いられる。回帰テストは、ソフトウェアに修正を施した際に、既存機能に悪影響が出ていないかを確認するためのテストである。回帰テスト実行を自動化することで、手動でテストを実行した際と比較して、工数の削減が期待できる。

しかし、ソフトウェアに修正を施した際に、当該修正に合わせてテストスクリプトにも修正が必要になる場合がある。テストスクリプトの修正作業に工数がかかると、期待した工数削減効果が得られない恐れがある。

上記で説明したキャプチャ＆リプレイやプログラミングを用いた手法のいずれを用いても、テストスクリプトの保守の問題は避けることができない。プログラミングによる手法を用いた場合、適切にモジュール化を行うことで、修正が必要になった場合の修正箇所を減らすことは可能である。

しかし、適切にモジュール化しても保守作業は必ず必要になる上、テスト担当者が必ずしもそのようなスキルを持っているとは限らない。したがって、誰でも簡単にテストスクリプトを保守できることが開発現場において強く求められている。

テストスクリプトが壊れる（回帰テストに利用できなくなる）原因として、ロケータの誤りと論理の誤りとの２通りの原因が存在する。

ロケータの誤りとは、テストスクリプトにおいて指定されているロケータがテスト対象の画面において使用されていない誤りをいう。これらは、アプリケーションのＵＩの変更や画面要素が持つ属性の変更により起こることが多い。ロケータの誤りを修正するためには、操作すべき画面要素を参照するように、ロケータを正しく設定し直す必要がある。

一方、論理の誤りとは、テストにおいて行うべき操作自体が異なっている、又は入力として与える値が異なっている誤りをいう。例えば、ユーザ登録時に確認のチェックボックスをクリックさせるような修正をアプリケーションに行った場合、テストスクリプトにもチェックボックスをクリックする操作命令を追加する必要があるが、斯かる追加が行われない場合に論理の誤りが発生する。論理の誤りは、アプリケーションの仕様変更や機能追加により起こることが多い。論理の誤りを修正するためには、テストシナリオを理解し、テストスクリプト中の適切な位置に操作を追加および削除する、又は適切な値を入力する必要がある。

ロケータの誤りについては、その修正を支援するための研究が存在するが（非特許文献１、２）、論理の誤りに関しては存在しない。テストスクリプトの自動修正を目指す場合、ロケータの誤りだけでなく、論理の誤りにも対応できる必要がある。

本発明は、上記の点に鑑みてなされたものであって、テストスクリプトの論理の誤りの修正の可能性を高めることを目的とする。

そこで上記課題を解決するため、テストスクリプト修正装置は、第１の画面に対するテストスクリプトに含まれる命令ごとに、当該命令の実行に応じたポップアップ画面の表示の有無を記憶部に記憶する記憶処理部と、前記テストスクリプトに含まれる命令のうち、第２の画面に対してエラーが発生した第１の命令について、前記記憶部を参照して、当該エラーの原因がポップアップ画面の追加又は削除であるか否かを判定する判定部と、前記判定部による判定結果に応じて、ポップアップ画面を操作する命令を前記テストスクリプトに追加する、又は前記第１の命令を前記テストスクリプトから削除する修正部とを有する。

テストスクリプトの論理の誤りの修正の可能性を高めることができる。

本発明の実施の形態におけるシステム構成例を説明するための図である。 本発明の実施の形態におけるテスト実行装置１０のハードウェア構成例を示す図である。 本発明の実施の形態におけるテスト実行装置１０の機能構成例を示す図である。 テスト実行装置１０が実行する処理手順の一例を説明するためのフローチャートである。 旧画面の画面要素情報の取得処理の処理手順の一例を説明するためのフローチャートである。 テストスクリプトの一例を説明するための図である。 画面要素情報記憶部１２２の構成例を示す図である。 新アプリケーションのテスト処理の処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を説明するための図である。図１において、サーバ装置２０及びテスト実行装置１０は、例えば、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して接続される。

サーバ装置２０は、画面を生成するアプリケーションを有するコンピュータである。サーバ装置２０には、当該アプリケーションの旧リビジョン及新リビジョンが実装されている。例えば、Ｗｅｂサーバが、サーバ装置２０として利用されてもよい。なお、リビジョン間において、画面の構成（すなわち、画面に含まれる画面要素の構成）は、必ずしも一致しない。また、画面に含まれる画面要素が定義されたデータ（例えば、ＨＴＭＬ（HyperText Markup Language）又はＸＭＬ（eXtensible Markup Language）等。以下、「画面定義データ」という）内において、リビジョンを跨いで同じ画面要素（対応する画面要素）に対して付与されているロケータの同一性は保証されていない。同じ画面要素（対応する画面要素）とは、例えば、機能及び用途（すなわち、意味）が同一であり、人から見たら同じであることが認識される画面要素の組をいう。

なお、画面要素とは、画面（Ｗｅｂ画面等）を構成するボタン、入力フォーム、リンクといった要素をいう。一つの画面要素は、例えば、１つのＨＴＭＬタグ又はＸＭＬタグで定義され、入れ子構造をとりうる。ロケータとは、画面定義データ内において、各画面要素に対して識別子として付与されている情報をいう。例えば、ｉｄ、ｎａｍｅ、ＸＰａｔｈ等がロケータとして用いられる。

テスト実行装置１０は、サーバ装置２０のアプリケーションについて、回帰テストを実行するコンピュータである。回帰テストは、旧リビジョンのアプリケーション（以下、「旧アプリケーション」という。）によって生成される画面に対して作成されたテストスクリプトを、新リビジョンのアプリケーション（以下、「新アプリケーション」という。）によって生成される画面に対して適用することで効率的に実行される。テストスクリプトとは、画面に対する操作手順が定義されたデータであり、命令ごとに、操作対象の画面要素のロケータ及び操作内容を示す情報等を含むデータである。なお、ＰＣ（Personal Computer）、スマートフォン、又はタブレット端末等がテスト実行装置１０として利用されてもよい。

図２は、本発明の実施の形態におけるテスト実行装置１０のハードウェア構成例を示す図である。図２のテスト実行装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６、及び入力装置１０７等を有する。

テスト実行装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってテスト実行装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力させるために用いられる。

図３は、本発明の実施の形態におけるテスト実行装置１０の機能構成例を示す図である。図３において、テスト実行装置１０は、テストスクリプト取得部１１、テスト実行部１２、画面表示制御部１３、要素情報取得部１４、エラー原因判定部１５及びテストスクリプト修正部１６等を有する。これら各部は、テスト実行装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

テスト実行装置１０は、また、テストスクリプト記憶部１２１及び画面要素情報記憶部１２２等を利用する。これら各記憶部は、例えば、補助記憶装置１０２、又はテスト実行装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

テストスクリプト取得部１１は、旧アプリケーションに対応するテストスクリプトをテストスクリプト記憶部１２１から取得する。

画面表示制御部１３は、旧アプリケーションの画面（以下、「旧画面」という。）及び新アプリケーションの画面（以下、「新画面」という。）のそれぞれを表示する。例えば、Ｗｅｂブラウザに基づいて画面表示制御部１３が実現されてもよい。

テスト実行部１２は、テストスクリプト取得部１１によって取得されたテストスクリプトを使用して、旧画面及び新画面のそれぞれについてテストを実行する。

要素情報取得部１４は、旧画面に対するテストスクリプトの命令の実行ごとに、ポップアップ画面の表示の有無を判定したり、操作対象の画面要素について、画面要素間の類似度を評価するための複数の指標の値（指標値）を取得したり、当該画面要素の表示範囲の画像データ等を取得したりする。判定結果、取得された指標値群及び画像データ等は、画面要素情報記憶部１２２に記憶される。

エラー原因判定部１５は、新アプリケーション（新画面）に対するテストスクリプトの実行中においてエラーが発生した場合に、エラーの原因を判定する。例えば、エラー原因判定部１５は、エラーの原因がＪａｖａｓｃｒｉｐｔ（登録商標）におけるポップアップ画面の追加又は削除によるものであるか否かを判定する。ポップアップ画面の追加とは、新アプリケーションにおいて、ポップアップ画面の表示処理が追加されることをいう。ポップアップ画面の削除とは、新アプリケーションにおいて、ポップアップ画面の表示処理が削除されることをいう。

テストスクリプト修正部１６は、エラー原因判定部１５による判定結果に基づいて、テストスクリプトを、新アプリケーション（新画面）に対応した状態へ修正する。なお、本実施の形態において、ポップアップ画面は、モーダルダイアログであるとする。したがって、ポップアップ画面が追加された場合、ポップアップ画面がクリックされないと先に進めないため、テスト実行時にエラーとなる。

なお、テスト実行装置１０が、サーバ装置２０の機能を有していてもよい。この場合、サーバ装置２０は配置されなくてもよい。

以下、テスト実行装置１０が実行する処理手順について説明する。図４は、テスト実行装置１０が実行する処理手順の一例を説明するためのフローチャートである。

ステップＳ１０１において、画面表示制御部１３は、サーバ装置２０の旧アプリケーションの画面（旧画面）を表示装置１０６に表示する。具体的には、画面表示制御部１３は、サーバ装置２０の旧アプリケーションにアクセスして、画面定義データをダウンロードし、当該画面定義データに基づいて、旧画面を表示する。

続いて、テストスクリプト取得部１１は、旧アプリケーションに対応するテストスクリプトを、テストスクリプト記憶部１２１から取得し、メモリ装置１０３に記憶する（Ｓ１０２）。以下において、「テストスクリプト」は、メモリ装置１０３に記憶されたテストスクリプトをいう。

続いて、テスト実行装置１０は、旧画面の画面要素情報の取得処理を実行する（Ｓ１０３）。ステップＳ１０３では、旧画面に対してテストスクリプトを実行しつつ、旧画面の画面要素群のうちテストスクリプトの各命令について、ポップアップ画面の表示の有無の判定、操作対象とされた画面要素に関する指標値群の取得、及び当該画面要素の表示範囲の画像データの取得等が実行される。判定結果、指標値群及び画像データは、画面要素情報記憶部１２２に記憶される。

続いて、テスト実行装置１０は、新アプリケーションのテスト処理を実行する（Ｓ１０４）。当該テスト処理では、旧画面に対応するテストスクリプトが新画面に適用されて、新アプリケーションについて回帰テストが実行される。回帰テストの過程において、エラーが発生し、当該エラーの原因がポップアップ画面の追加又は削除である場合、テストスクリプトが自動的に修正されて、回帰テストが継続される。

続いて、ステップＳ１０３の詳細について説明する。図５は、旧画面の画面要素情報の取得処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２０１において、テスト実行部１２は、テストスクリプト内に次の命令ｃが有るか否かを判定する。次の命令ｃとは、未実行の命令の中で実行順が先頭の命令をいう。

図６は、テストスクリプトの一例を説明するための図である。図６において、画面ｇ１は、表示される画面の一例である。画面定義データｈ１は、画面ｇ１の一部（画面要素ｅ１）についての画面定義データである。テーブルＴ１は、画面ｇ１に関するテストスクリプトを表形式で表現したものである。

テーブルＴ１において、各行が、１つの操作に対応する。すなわち、テストスクリプトは、操作ごとに、命令、ロケータ、及び値等を含む。命令は、操作の種別を示す情報である。図６では、「ｔｙｐｅ」、「ｃｌｉｃｋ」等が例示されている。「ｔｙｐｅ」は、操作対象の画面要素への値の入力を意味する。「ｃｌｉｃｋ」は、操作対象の画面要素のクリックを意味する。ロケータは、操作対象の画面要素のロケータである。値は、操作対象の画面要素に適用される値である。このように、テストスクリプトには、操作内容（命令及び値）と操作対象（ロケータ）とが操作ごとに含まれている。また、テストスクリプトには、各操作の順番も定義されている。例えば、テーブルＴ１では、上の行から先に実行される。

テストスクリプトに次の命令ｃが有る場合（Ｓ２０１でＹｅｓ）、テスト実行部１２は、旧画面において、命令ｃに対応する画面要素に対して命令ｃを実行する（Ｓ２０２）。

続いて、要素情報取得部１４は、命令ｃによって操作された画面要素（以下、「対象要素」とい。）を特定する（Ｓ２０３）。対象要素は、例えば、命令ｃに対応するロケータによって特定されてもよい。続いて、要素情報取得部１４は、対象要素に関する各指標値を、旧画面の画面定義データから取得する（Ｓ２０４）。ここでは、複数の指標の指標値が取得される。

指標は、例えば、画面要素の属性（ｉｄ、ｔｙｐｅ、ｃｌａｓｓ、ｎａｍｅ、タグ名等）、画面要素の位置情報（ＸＰａｔｈ、ｘ座標、ｙ座標、横幅、縦幅）、画面要素に関連するテキスト（リンクテキスト、近傍のテキスト、ＵＲＬ等）である。なお、リンクテキストは、画面要素がリンクである場合の指標であり、当該リンクが付与された文字列を示す。近傍のテキストとは、画面要素の表示範囲の周囲（例えば、上、下、左、右等の所定の画素数の範囲内）に表示されるテキストである。画面要素の表示範囲とは、例えば、当該画面要素の最小外接矩形でもよい。なお、２０種類程度の指標のそれぞれについて、指標値が取得されてもよい。

続いて、要素情報取得部１４は、取得された指標値群を、命令ｃ及び対象要素に関連付けて画面要素情報記憶部１２２に記憶する（Ｓ２０５）。

続いて、要素情報取得部１４は、命令ｃの実行に応じてポップアップ画面が表示されたか否かを判定し、当該判定結果を命令ｃに関連付けて画面要素情報記憶部１２２に記憶する（Ｓ２０６）。ポップアップ画面が表示されたか否かは、公知の方法により容易に判定可能である。

続いて、要素情報取得部１４は、旧画面のスクリーンショット（画像データ）を取得する（Ｓ２０７）。続いて、要素情報取得部１４は、当該スクリーンショットから、対象要素の表示範囲の画像データを取得する（切り出す）（Ｓ２０８）。なお、対象要素の表示範囲は、例えば、旧画面の画面定義データに含まれている、対象要素の位置情報等に基づいて特定可能である。続いて、要素情報取得部１４は、取得した画像データを、対象要素に関連付けて画面要素情報記憶部１２２に記憶する（Ｓ２０９）。

ステップＳ２０２以降が、テストスクリプトの全ての命令について実行されると（Ｓ２０１でＮｏ）、図５の処理手順は終了する。その結果、画面要素情報記憶部１２２には、旧画面の画面要素のうち、テストスクリプトの命令ごとに、操作された各画面要素の指標値群、画像データ、及びポップアップ画面の表示の有無が記憶される。

図７は、画面要素情報記憶部１２２の構成例を示す図である。図７に示されるように、画面要素情報記憶部１２２には、テストスクリプトにおいて実行された命令の順番で、「命令番号」、「画面要素」、「指標値群」、「画像データ」及び「ポップアップの有無」が記憶される。命令番号は、テストスクリプト中における命令の順番である。「画面要素」は、例えば、命令によって操作対象とされた画面要素のロケータである。「指標値群」及び「画像データ」は、当該画面要素に関して取得された指標値群又は画像データである。「ポップアップの有無」は、ポップアップ画面の表示の有無の判定結果である。

続いて、図４のステップＳ１０４の詳細について説明する。図８は、新アプリケーションのテスト処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、画面表示制御部１３は、サーバ装置２０の新アプリケーションの画面（新画面）を表示装置１０６に表示する。具体的には、画面表示制御部１３は、サーバ装置２０の新アプリケーションにアクセスして、画面定義データをダウンロードし、当該画面定義データに基づいて、新画面を表示する。

続いて、テストスクリプトの最初の命令から順に、ステップＳ３０２以降が実行される。当該テストスクリプトは、ステップＳ１０２においてメモリ装置１０３に記憶されたテストスクリプトである。すなわち、当該テストスクリプトは、旧アプリケーションに対応するテストスクリプトである。

ステップＳ３０２において、テスト実行部１２は、テストスクリプト内に次の命令ｃが有るか否かを判定する。テストスクリプトに次の命令ｃが有る場合（Ｓ３０２でＹｅｓ）、テスト実行部１２は、新画面において、命令ｃに対応する画面要素に対して命令ｃを実行する（Ｓ３０３）。

命令ｃが正常に実行されると（Ｓ３０４でＮｏ）、ステップＳ３０２以降が繰り返される。命令ｃの実行に応じてエラー（異常）が発生すると（すなわち、エラーが発生した命令が検出されると）（Ｓ３０４でＹｅｓ）、エラー原因判定部１５は、エラーの原因がポップアップ画面の追加であるかを判定する（Ｓ３０５）。具体的には、エラー原因判定部１５は、現時点において、ポップアップ画面が表示されているか否かを確認する。ポップアップ画面が表示されている場合、エラー原因判定部１５は、命令ｃの１つ前の命令（以下、「命令ｃ'」という。）について、画面要素情報記憶部１２２において「ポップアップの有無」に「無」が記憶されているか否かを確認する。すなわち、旧画面（旧アプリケーション）に対する命令ｃ'の実行によってポップアップ画面が表示されていなかったことが確認される。旧画面（旧アプリケーション）に対する命令ｃ'の実行によってポップアップ画面が表示されていない場合、エラー原因判定部１５は、エラーの原因がポップアップ画面の追加であると判定する。この場合、旧アプリケーションでは、命令ｃ'の実行によってポップアップ画面は表示されていなかったが、新アプリケーションでは、命令ｃ'の実行によってポップアップ画面が表示されるように変更され、当該ポップアップ画面が表示されていることにより、命令ｃの実行に失敗した可能性が高いからである。

エラーの原因がポップアップ画面の追加であると判定された場合（Ｓ３０５でＹｅｓ）、テストスクリプト修正部１６は、命令ｃ'と命令ｃとの間（すなわち、命令ｃの直前）に、現在表示中のポップアップ画面を操作する命令（すなわち、ポップアップ画面のボタンをクリックする命令）をテストスクリプトに挿入（追加）する（Ｓ３０６）。続いて、ステップＳ３０３以降が繰り返される。すなわち、実行に失敗した命令ｃが再実行される。

一方、エラー原因判定部１５は、エラーの原因がポップアップ画面の追加でないと判定すると（Ｓ３０５でＮｏ）、エラーの原因がポップアップ画面の削除であるかを判定する（Ｓ３０７）。具体的には、エラー原因判定部１５は、現時点において、ポップアップ画面が表示されているか否かを確認する。ポップアップ画面が表示されていない場合、エラー原因判定部１５は、命令ｃの１つ前の命令ｃ'について、画面要素情報記憶部１２２において「ポップアップの有無」に「有」が記憶されているか否かを確認する。すなわち、旧画面（旧アプリケーション）に対する命令ｃ'の実行によってポップアップ画面が表示されていたことが確認される。旧画面（旧アプリケーション）に対する命令ｃ'の実行によってポップアップ画面が表示されていた場合、エラー原因判定部１５は、エラーの原因がポップアップ画面の削除であると判定する。この場合、旧アプリケーションでは、命令ｃ'の実行によってポップアップ画面は表示されていたが、新アプリケーションでは、命令ｃ'の実行によってポップアップ画面が表示されないように変更され、当該ポップアップ画面が表示されないことにより、命令ｃの実行に失敗した可能性が高いからである。すなわち、命令ｃは、当該ポップアップ画面のボタンのクリックの命令である可能性が高いからである。

エラーの原因がポップアップ画面の削除であると判定された場合（Ｓ３０７でＹｅｓ）、テストスクリプト修正部１６は、テストスクリプトから命令ｃを削除する（Ｓ３０８）。続いて、ステップＳ３０２以降が実行される。

エラーの原因がポップアップ画面の削除であると判定されない場合（Ｓ３０７でＮｏ）、エラー原因判定部１５は、命令ｃのロケータが誤っているか否かを判定する（Ｓ３０９）。すなわち、当該ロケータに対応する画面要素が新画面に無いか否かが判定される。当該ロケータに対応する画面要素が新画面に無い場合（Ｓ３０９でＹｅｓ）、テストスクリプト修正部１６は、当該ロケータを自動修正する（Ｓ３１０）。なお、ロケータの自動修正は、非特許文献１又は２に開示された技術を用いて実行されてもよい。この場合、画面要素情報記憶部１２２が参照されてもよい。ステップＳ３１０に続いて、ステップＳ３０２以降が実行される。

なお、命令ｃのロケータが誤っていない場合（Ｓ３０９でＮｏ）、テストは終了する。また、テストスクリプトの全ての命令について実行されると（Ｓ３０２でＮｏ）、図８の処理手順は終了する。

上述したように、本実施の形態によれば、新アプリケーションにおいてポップアップ画面の追加又は削除が行われた場合であっても、旧アプリケーションに対応するテストスクリプトを自動的に修正することができる。ここで、非特許文献３によれば、ポップアップ画面の追加又は削除は、論理の誤りの約２０％を占めており、テストスクリプトの論理誤りにおいて重要な原因である。したがって、本実施の形態によれば、テストスクリプトの論理の誤りの修正の可能性を高めることができる。

また、ロケータだけでなく、論理の誤りについても一部対応が可能となることで、テストスクリプトの修正作業の負担を軽減することができる。

また、人間にとって修正が困難かつ頻度の多いＪａｖａｓｃｒｉｐｔ（登録商標）のポップアップの問題について、テストスクリプトの修正の支援を行うことができる。

なお、本実施の形態において、テスト実行装置１０は、テストスクリプト修正装置の一例である。旧画面は、第１の画面の一例である。新画面は、第２の画面の一例である。要素情報取得部１４は、記憶処理部の一例である。エラー原因判定部１５は、判定部の一例である。テストスクリプト修正部は、修正部の一例である。

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ テスト実行装置
１１ テストスクリプト取得部
１２ テスト実行部
１３ 画面表示制御部
１４ 要素情報取得部
１５ エラー原因判定部
１６ テストスクリプト修正部
２０ サーバ装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
１２１ テストスクリプト記憶部
１２２ 画面要素情報記憶部
Ｂ バス

Claims (4)

1. 第１の画面に対するテストスクリプトに含まれる命令ごとに、当該命令の実行に応じたポップアップ画面の表示の有無を記憶部に記憶する記憶処理部と、
   前記テストスクリプトに含まれる命令のうち、第２の画面に対してエラーが発生した第１の命令について、前記記憶部を参照して、当該エラーの原因がポップアップ画面の追加又は削除であるか否かを判定する判定部と、
   前記判定部による判定結果に応じて、ポップアップ画面を操作する命令を前記テストスクリプトに追加する、又は前記第１の命令を前記テストスクリプトから削除する修正部と、
   を有することを特徴とするテストスクリプト修正装置。
2. 前記判定部は、前記第２の画面に対する前記第１の命令の実行に応じてポップアップ画面が表示されており、前記第１の命令の１つ前の命令に関してポップアップ画面が表示されていないことが前記記憶部に記憶されている場合には、前記エラーの原因がポップアップ画面の追加であると判定し、
   前記修正部は、前記エラーの原因がポップアップ画面の追加であると判定された場合は、前記テストスクリプトにおいて前記第１の命令の直前に、ポップアップ画面を操作する命令を追加する、
   ことを特徴とする請求項１記載のテストスクリプト修正装置。
3. 前記判定部は、前記第２の画面に対する前記第１の命令の実行に応じてポップアップ画面が表示されておらず、前記第１の命令の１つ前の命令に関してポップアップ画面が表示されていることが前記記憶部に記憶されている場合には、前記エラーの原因がポップアップ画面の削除であると判定し、
   前記修正部は、前記エラーの原因がポップアップ画面の削除であると判定された場合は、前記テストスクリプトから前記第１の命令を削除する、
   ことを特徴とする請求項１又は２記載のテストスクリプト修正装置。
4. 第１の画面に対するテストスクリプトに含まれる命令ごとに、当該命令の実行に応じたポップアップ画面の表示の有無を記憶部に記憶する記憶手順と、
   前記テストスクリプトに含まれる命令のうち、第２の画面に対してエラーが発生した第１の命令について、前記記憶部を参照して、当該エラーの原因がポップアップ画面の追加又は削除であるか否かを判定する判定手順と、
   前記判定手順における判定結果に応じて、ポップアップ画面を操作する命令を前記テストスクリプトに追加する、又は前記第１の命令を前記テストスクリプトから削除する修正手順と、
   をコンピュータに実行させることを特徴とするプログラム。

Images