JP2010218496A - アプリケーションプログラムをテストする方法及びプログラム及び記録媒体 - Google Patents

Abstract

【課題】アプリケーションプログラムの自動テスト方法において、テスト内容の変更があった場合に、テストプログラムの修正をより小さくし、従来よりテストを行いやすくしたテスト方法を提供する。
【解決手段】テストの内容に基づき、テスト実行のための情報であるＥＤＳファイルを作成する。コンピュータは、ＥＤＳ実行スクリプトを実行する。その結果、ＥＤＳファイルを読み込み、その内容に基づき、テストを実行する。ＥＤＳファイルは、テーブル形式で記述されているので、利用者はその内容を把握しやすい。さらに、ＥＤＳファイルは、仕様書の部分と、テスト内用を記載した部分とが、互いに対応しながら記載されているので、そのテスト内容が把握しやすい。その結果、テスト内容の修正を行いやすくなる。
【選択図】図１

Description

本発明は、アプリケーションプログラムの動作をテストするシステムに関する。特に、テスト効率の向上を図ることができるシステムに関する。

アプリケーションプログラムの動作をテストすることは、アプリケーションプログラムの開発に置いて極めて重要な事項である。そのため、従来から様々なテストシステム・テスト手法が開発・提案されてきた。特に、人間の操作を含めてシミュレーションを行うためのシステムは種々のものが開発されている。

従来の代表的なテスト手法の一つにテストスクリプトとテストデータを作成してテストの自動化を行う手法が知られている。この手法は、繰り返し実行されるテストの効率化に大きく寄与するものであり、広く活用されている。

テストは、一般的に、アプリケーションプログラムの単体テスト、結合テスト、システムテスト、を順に行っていく場合がある。この場合、一般的には、途中で、プログラムの修正や、仕様の変更等が発生する。これら修正や変更が発生すると、そのたびにテストスクリプトの変更が必要となる。このような変更は、一般に修正すべき箇所を発見し、人間が手作業で行っていたが、作業量が膨大になりがちであり、作業効率の減少を招いていた。その結果、スクリプトの修正が遅れ、テストの自動化による効率の向上にも一定も限界が表れていた。

この従来の手法の動作を表すフローチャートが図２５に示されている。

図２５に示すように、まず、ステップＳ２５−１においては、設計書によってテスト計画書の作成を行う。なお、テスト計画書には、単体テスト計画書、結合テスト計画書、システムテスト計画書、等がある。

結合テスト計画書の典型的な内容としては、例えば、以下のような内容が挙げられよう。

１．本書（結合テスト仕様書）の位置づけ
２．結合テストの概要説明
２．１結合テスト計画書の作成
２．２結合テストの作業内容
３．結合テストの体制と役割分担
３．１体制
３．２役割分担
４．作成資料
４．１結合テストチェックリスト
４．１．１記入項目
４．１．２テスト方法の説明
４．２結合テスト関連の作成資料
４．３完了報告書
５．テスト環境の設定
６．管理業務
７．結合テストの目標と完了
７．１品質目標
７．２完了基準
そして、上記結合テストチェックリストは、テスト仕様書の好適な一例に相当する。

また、システムテスト計画書の典型的な内容としては、例えば、以下のような内容が挙げられよう。

１．本書（システムテスト仕様書）の位置づけ
２．システムテストの概要説明
２．１システムテスト計画書の作成
２．２システムテストの作業内容
２．２．１機能テスト
２．２．２パフォーマンステスト
２．２．３負荷テスト
３．結合テストの体制と役割分担
３．１体制
３．２役割分担
４．作成資料
４．１テスト項目一覧表
４．２テストシナリオ
４．３テストシナリオ説明
４．４パフォーマンステスト仕様書
４．５負荷テスト仕様書
４．６テスト結果分析評価表
４．７完了報告書
５．テスト環境の設定
６．管理業務
７．システムテストの目標と完了
７．１目標
７．２完了宣言
次に、ステップＳ２５−２において、設計書からテスト仕様書の作成を行う。この仕様書によって、どのような内容のテストを行うかを決定する。

次に、ステップＳ２５−３においては、テストデータの作成を行う。アプリケーションプログラムに与えるテストデータを上記テスト仕様書に基づき作成していく。

ステップＳ２５−４においては、テストスクリプトの記録を行う。従来から、アプリケーションプログラムの動作に基づきテストスクリプトを自動で記録生成するシステムが知られている。

すなわち、テスト仕様書に従い、実際にキーボードからのデータの入力、キー、マウス等の操作を行い、その動作をテスト・スクリプトとして記録するのである。作成後に、結果の比較や、エラーが発生した場合の対応手法の指図などの自動チェックを行わせるためのスクリプトや、複数個のテストデータによる繰り返しテストを行う場合の所定のスクリプトの追加を行って、最終的なスクリプトが完成する（ステップＳ２５−５）。

例えば、上記の繰り返しテストにおいては、大量のデータを外部ファイルから与えて、それらのデータに基づいた繰り返しテストを行わせるためのプログラムを書き加える。このプログラムの中には、テストに供される外部データを準備するファイル名やそのロケーション、更に、テストの結果を格納するための結果データファイルのファイル名及びそのロケーション等を適宜定義していく必要がある。これらのリンクなどの定義や繰り返しテスト処理のプログラムを書き加えることによって、多くのデータを用いたテストを自動的に行わせることが可能である。

このようにして適宜修正を加えることによって作成されたテストスクリプト（ステップＳ２５−５）は、テスト項目が増えるにつれて膨大な分量となりがちである。従って、テスト項目が増えるに従って、その修正量も膨大なものとなりがちであり、作業効率が悪化する要因の一つとなっていた。

特に、テストスクリプト及びテストデータの何処を修正し、どのような機能を追加するか、をテストスクリプトの全体を見て行う必要があり、繁雑な作業となりがちであった。また、作業工数も大きなものとなりがちであった。

ステップＳ２５−６においては、このようにして作成したテストスクリプトを用いてテストを実行する。

ステップＳ２５−７においては、得られたテスト結果を調べる。テスト結果が所望の結果と合致すれば、テストは完了する（ステップＳ２５−８）。一方、テスト結果が所望の結果と合致しない場合は、一般に対象であるアプリケーションプログラムの修正が行われる（ステップＳ２５−９）。

また、アプリケーションプログラムの修正（ステップＳ２５−９）に際しては、同時にテスト仕様書の修正も行うことが好適である（ステップＳ２５−１０）。

次に、ステップＳ２５−１１においては、アプリケーションプログラムの修正に合わせて、テストデータの修正も行うことが多い。

そして、テストデータの修正に伴って、テストスクリプトも修正する。このようにして、テストデータ及びテストスクリプトの修正が完了する。

以上のようにして修正されたテストスクリプト及びテストデータを用いて、再び処理がステップＳ２５−６に移行し、テストが繰り返される。

従来のアプリケーションプログラムの動作検証においては、以上のような処理で検証が実行されてきた。

なお、テストスクリプトは、所定のコンピューター言語で記述される。例えば、いわゆるＶｉｓｕａｌＢａｓｉｃ等が用いられることが多い。また、テストデータは、外部データとして準備する場合は、所定のテキストデータ、ＣＳＶ形式のデータ等が用いられる。また、テストデータの種類が少ない場合は、テストスクリプト内部に埋め込まれて、適宜参照されるように構成されることも多い。

先行特許文献
下記特許文献１には、アプリケーションの動作確認を自動的に実行する自動実行ツールが開示されている。特に、入力条件と、環境条件とを組み合わせてテストすべき項目を決定するテスト項目表を作成して、このテスト項目に従ってテストスクリプトを生成することを特徴とする検証方法が開示されている。

下記特許文献２には、プログラムテストの所要時間を短縮することができるプログラムテストシステム及びプログラムテスト方法が開示されている。特に、データ生成プログラムが、オリジナルデータから実テーブルを作成し、データベースに記憶させる技術が開示されている。このように、実テーブルを作成ししているので、テストに使用するデータを容易に得ることができ、テストの所要時間の短縮が図れると記載されている。

下記特許文献３には、テスト条件の変更が容易な、計算機システムの模擬アプリケーション試験装置が開示されている。ここに記載されている模擬アプリケーション試験装置は、テストプログラムの動作条件を表すパラメータを設定する手段を設け、この手段でパラメータを設定することによって、テストプログラムの変更が不要となると記載されている。

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

以上、図２０で説明したように、従来のアプリケーションプログラムの動作検証方法では、テスト条件の変更があった場合に、テストプログラムの修正量が膨大なものとなり、プログラム設計者の負担が大であるという問題がある。

本発明は、上記課題に基づきなされたものであり、その目的は、テスト内容の変更があった場合に、テストプログラムの修正をより小さくし、従来よりテストを行いやすくしたテスト方法を提供することである。

（１）本発明は、上記課題を解決するために、アプリケーションプログラムをテストする方法において、テストの内容に基づき、テスト実行のための情報であるスクリプト実行情報を作成するスクリプト実行情報作成ステップと、インタプリタスクリプトが、前記スクリプト実行情報を読み出し、その内容に基づいて前記アプリケーションプログラムの動作をテストするテストステップと、を含むことを特徴とするアプリケーションプログラムをテストする方法である。

（２）また、本発明は、上記（１）記載のアプリケーションプログラムをテストする方法において、前記スクリプト実行情報は、テーブル形式で記述されていることを特徴とするアプリケーションプログラムをテストする方法である。

（３）また、本発明は、上記（１）又は（２）に記載のアプリケーションプログラムをテストする方法において、前記スクリプト実行情報は、テストの試験項目及び操作内容を記述した仕様部と、テスト動作を記述したデータ部と、から成ることを特徴とするアプリケーションプログラムをテストする方法である。

（４）また、本発明は、上記（１）又は（２）に記載のアプリケーションプログラムをテストする方法において用いられる前記スクリプト実行情報を格納した記録媒体において、前記スクリプト実行情報は、テストの試験項目及び操作内容を記述した仕様部と、テスト動作を記述したデータ部と、から成ることを特徴とするスクリプト実行情報を記録した記録媒体である。

（５）また、本発明は、上記（１）〜（３）記載のいずれか１項に記載のアプリケーションプログラムをテストする方法において、前記スクリプト実行情報は、マイクロソフト社のエクセルのデータファイルとして作成されていることを特徴とするアプリケーションプログラムをテストする方法である。

（６）また、本発明は、コンピュータに、上記（１）記載のアプリケーションプログラムをテストする方法中のテストステップを実行させるプログラムにおいて、前記コンピュータに、前記スクリプト実行情報を読み出させる読み出し手順と、前記読み出した前記スクリプト実行情報中からフラグを読み出し、そのフラグの内容に基づきテスト動作を実行する手順と、を実行させることを特徴とするプログラムである。

以上述べたように、本発明によれば、テスト内容に変更が生じても従来よりテストプログラムの修正が容易になった。したがって、アプリケーションプログラムのテストをより一層行いやすいテスト方法を提供することができた。

本実施の形態におけるアプリケーションプログラムの動作検証システムの動作を表すフローチャートである。 テストスクリプトに関する一般的な概念の説明図である。 テスト実行のための情報であるスクリプト実行情報の活用イメージを表す概念図である。 ＴｅｓｔＰａｒｔｎｅｒの処理の流れを表すタイムチャートである。 ＳＴＡＲ−ＴＳＴシステムにおける作業の流れを表すタイムチャートである。 ＥＤＳファイルをコンピュータ画面に表示した場合の様子を示す説明図である。 ＥＤＳのデータ部のサンプル（テスト内容を記述する部分）を表す説明図である。 キャプチャによって取得された画面内のオブジェクトを表す説明図である。 本実施の形態における自動テストの実行の様子を示す説明図である。 テストの連続実行用のＥＤＳファイルの様子を示す説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグの記述様式が記載された説明図である。 実行フラグのサンプルが記載されたサンプル図である。 アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。 アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。 アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。 アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。 アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。 アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。

アプリケーションプログラムの動作を検証する従来の手法と、ＥＤＳを使用する場合の方法とを比較した資料である。

以下、本発明の実施の形態を図面に基づいて説明する。

Ａ．基本動作の流れ
図１には、本実施の形態におけるアプリケーションプログラムの動作検証システムの動作を表すフローチャートが示されている。

図１のステップＳ１−１から、ステップＳ１−２までは、図２０の従来技術とまったく同様である。

すなわち、ステップＳ１−１においては、設計書によって、テスト計画書の作成を行う。また、ステップＳ１−２においては、設計書に基づいてテスト仕様書の作成を行う。

次に、ステップＳ１−３においては、テストするシステム全体で使用するテストスクリプトのパターン（キーボード、マウス操作、入力方法、データの取り込み、結果の比較、エラー時の対応方法など）をマクロとして作成する。

なお、作成したマクロは、ＥＤＳ実行スクリプトと呼ばれる。ここで、ＥＤＳとは、Ｅｘｃｅｌ Ｄａｔａ Ｓｈｅｅｔを意味する。Ｅｘｃｅｌは、マイクロソフト社の表計算ソフトの商品名である。

本実施の形態において特徴的なことは、このようにテストスクリプトを、表データ（いわゆるテーブルのデータ）として構築したことである。この結果、テストスクリプトの読み取り性、記述容易性が向上し、修正等を行いやすくなったものである。

従来から、アプリケーションソフトウェアを実際に操作し、その操作の記録をスクリプトとして記録するツールが知られている。例えば、ＶｉｓｕａｌＢａｓｉｃ等の言語で記述されたスクリプトを作成するツールが知られている。

従来のアプリケーションソフトウェアの典型的な動作テストは、このツールを用いて構築されたＶｉｓｕａｌＢａｓｉｃ等の言語で記述されたスクリプトを利用して、アプリケーションソフトウェアの自動実行を行ってテストが行われていた。

本願発明者は、新たにテーブル形式でスクリプトを作成する新規なツールを作り上げたのである。このようにテーブル形式で記述されたスクリプトを作成するツールは従来から知られていない。

次に、ステップＳ１−４において、作成したＥＤＳ用テストスクリプトを使用してテスト仕様書に基づきテスト内容を作成する。本実施の形態では、これをエクセルのデータシートを用いて作成するので、ＥＤＳと呼ぶ。テスト内容は、操作内容（アクション）、キー操作、入力データ、結果の期待値、エラー時の対応などを設定してＥＤＳを作成していく。

ＥＤＳは、複数個のテストデータの定義を行うのにも用いられる。ＥＤＳでテストデータを複数個定義した場合、従来のテストスクリプトと比較して、テスト内容がより見やすくすることができる。

ステップＳ１−５においては、このようにして作成したテストスクリプト・ＥＤＳを用いてテストを実行する。

ステップＳ１−６においては、得られたテスト結果を調べる。テスト結果が所望の結果と合致すれば、テストは完了する（ステップＳ１−７）。一方、テスト結果が所望の結果と合致しない場合は、一般に、テスト対象であるアプリケーションプログラムの修正が行われる（ステップＳ１−８）。

また、アプリケーションプログラムの修正（ステップＳ２５−９）に際しては、同時にテスト仕様書の修正も行うことが好適である（ステップＳ１−９）。

次に、ステップＳ１−１０においては、アプリケーションプログラムの修正に合わせて、ＥＤＳの修正が行われる。

その後、図１に示すように、再び、ステップＳ１−５に処理が移行し、テストが再び続けられる。

これらステップＳ１−９及びステップＳ１−１０は、従来の動作（図２０のステップＳ２５−９、ステップＳ２５−１０）と内容は同様である。しかし、ＥＤＳの修正は、従来の修正作業に比べて非常に容易になっているためテストの作業効率が向上する。以下、この点について詳細に説明する。

Ｂ．テスト内容の変更について
Ｂ−１ 従来技術
さて、テストの結果を受けて、発生するプログラムの変更、仕様書の変更に伴い、テスト内容の変更が必要となる。

従来の技術（図２０）においては、テストスクリプトが読み込むテストデータの変更を行う（ステップＳ２５−１１）。このテストデータは、データが記述されたデータファイルである。さらに、それに合わせてテストスクリプトの修正を行う必要がある（ステップＳ２５−１２）。

さて、テストスクリプトは、一般に多くのステップが存在する。従って、その中から修正ポイントを探し出し、修正を加えることは非常に大変な作業となる。ここで、修正ポイントとは、操作内容の変更や、入力データの変更、出力結果の比較、等である。

Ｂ−２ 本実施の形態で提案する方式
これに対して、本実施の形態で提案する方式では、テストの実施要素内容がスクリプトではなく、表計算ファイル（例えば、ＥＸＣＥＬのデータファイルのシート）上のデータ表となって一覧表示されており、修正するポイントを見つけることは容易である。したがって、本実施の形態で提案する方式によれば、テスト内容の変更作業が従来に比べて容易となり、大幅に効率化される（図１のステップＳ１−１０）。

Ｃ．ＥＤＳの作成の詳細
上述したように、本実施の形態においては、テストスクリプトを、表計算等で用いるテーブル形式で記述したので、その修正がしやすく、テスト効率の向上を図ることが可能である。

テストスクリプトに関する一般的な概念の説明図が図２に示されている。

この図に示すように、テスト対象であるアプリケーションプログラムを所定のコンピュータ上で動作させ、その様子をいわゆる自動テスティングツールが観察する。この自動テスティングツールはテスト対象を観察し、その動作をスクリプトとして記録する。このスクリプトは例えば、Ｖｉｓｕａｌ Ｂａｓｉｃ等の言語で記述され、このスクリプトを実行することによって、テスト対象の動作を模擬することができるのである。

従来から、いわゆる自動テストは、テスト対象となる処理動作をテストスクリプトとして記録（及び作成し）、それを自動再生により繰り返すことによって実行されてきた。ここで言う「処理動作」は、例えば、業務アプリケーションプログラムの場合は、業務プロセスとなる。

なお、テストスクリプトは、対象となるアプリケーションプログラムの仕様の改修、修正の度にメンテナンスを行う必要がある。具体的には、業務プログラムの場合は、対象業務の改修、修正があった場合がこれに相当する。

このように、いわゆるスクリプトは、重要なテスト資産であり、メンテナンス性の高いスクリプトを作成することは、テストの効率を向上するのに非常に有用であることは明らかである。

本願発明者は、新しいテストスクリプト作成ツールを構築し、メンテナンス性が向上したテストスクリプトに相当するものを構築した。この結果、本願発明者はテスト効率の高い自動テスト方法を実現できたものである。

Ｄ．本実施の形態の特徴
本実施の形態では、この新しいテストスクリプト作成ツールを用いて新しいテストスクリプトに相当するもの「スクリプト実行情報」を構築し、これを改修・修正動作する。この改修・修正動作等について、以下順次説明する。このスクリプト実行情報は、テスト実行のための情報である。

また、本実施の形態におけるテストスクリプトに相当するもの特徴としては、上で述べた特徴の他に以下のようなメリットがある。

・標準スクリプトを準備しているので、この標準スクリプトを、活用することで、個別に多くのスクリプトやデータの作成が不要で、標準構成に沿って効率的にテストデータを作成できる。

・作成後の改修に対応するテスト内容の修正も、テスト仕様書との関連が明確となっているため、効率的に行える。すなわち、スクリプト実行情報には、テスト仕様書の内容が含まれており、わかりやすくなっている。詳しくは後述する。

・テストスクリプトに相当するスクリプト実行情報を作成する時に、テスト対象の情報を含むテスト仕様書が、ガイド準拠標準フォームを利用すると、作成効率がさらに向上する。

Ｅ．スクリプト実行情報活用イメージ
テスト実行のための情報であるスクリプト実行情報の活用イメージを表す概念図が図３に示されている。この図３に示すように、まず、テンプレートフォーム（テンプレート標準）を利用して、テスト設計書、テストシナリオさらに画面定義情報から、スクリプト実行情報を作成し、データを定義する。これらテストのためのスクリプト実行情報とデータとは本実施の形態では、システムに「登録」を行っている。

本実施の形態では、このように、テンプレート標準を利用しているので、オプションによるフレームの自動生成や、チェックが可能となるという効果を奏する。

このようにして作成したテストのためのスクリプト実行情報は、ＴｅｓｔＰａｒｔｎｅｒ（登録商標）と呼ばれるインタプリタを用いて、テスト対象に対して自動実行（自動テスト）する。この際には、テンプレートインタプリタスクリプトが用いられる。下記実施例では、スクリプト実行情報の例として「ＥＤＳファイル」を用いているが、この場合には、テンプレートインタプリタは「ＥＤＳ実行スクリプト」と呼ばれる。詳しくは後の実施例において述べる。

この自動実行（自動テスト）を行うことによって、テスト結果が得られる。このテスト結果に基づき、アプリケーションプログラムの修正や、仕様書の修正を行うことは既に述べたとおりである（図１参照）。

Ｆ．テストの効率化について
Ｆ−１．問題点
さて、本実施の形態では、テストを効率化するツールとしてＴｅｓｔＰａｒｔｎｅｒを用いているが、テストにおいては以下のような問題点がある。

・同じテストを繰り返すケースが多いにもかかわらず、その都度手入力でテストを行っている。

・大量のテスト操作を手作業で繰り返すことは困難なため、網羅的なテストに抜けができる場合もあり、結果としてシステム・トラブルに繋がる場合もある。

・アプリケーションプログラムの開発者は、発生するトラブルに関する報告書作成に貴重な時間を費やさなければならない場合もある。

・テスト管理者は全テストの進捗状況を把握して、テスト工程を管理しなければならないが、この管理負担が過重な負担となる場合もある。

Ｆ−２．問題点解決のための主要な機能
このような問題に対して、テスト効率化ツールであるＴｅｓｔｐａｒｔｎｅｒは、以下のような機能を備えている。

・テストの自動実行
初回のテスト時にテスト手順が記録され、次回のテスト時にテストを自動実行することができる。

・外部データとの連動
テスト用入力データ、テスト結果の期待値用データと連動することによって、自動化スクリプトを作成する際の利用者（スクリプト作成者）の負担を軽減することができる。

但し、本実施の形態では、上述したように、従来の「テストスクリプト」の役割を果たすものとして「スクリプト実行情報」を用いている。

・テスト結果の自動判定
処理結果と期待値を比較して、正常・異常を自動判定する。

・テストレポートの自動作成
テスト結果のログを記録し、レポートを自動作成する。

Ｆ−３．テスト作業全般の支援
ＴｅｓｔＰａｒｔｎｅｒは、業務に応じたテストケース、テスト項目の洗い出しから、テスト自動化のための技術支援まで、テストに関する一貫した支援を提供することができる。

このＴｅｓｔＰａｒｔｎｅｒの処理の流れを表すタイムチャートが図４に示されている。この図に示すように、まず、準備段階１０においては、Ｔｅｓｔｐａｒｔｎｅｒのプロジェクトが作成される。次に、記録段階１２においては、ＶｉｓｕａｌＮａｖｉｇａｔｏｒでスクリプトの記録を行。これは、いわゆるＧＵＩの操作を記録することによって、テスト手順の記録を行うものである。記録されたものがテストスクリプトであり、ここではＶＢＡ（ＶｉｓｕａｌＢａｓｉｃ ｆｏｒ Ａｐｌｉｃａｔｉｏｎ）で記述されている例を説明する。また、テストスクリプトの修正段階１４においては、記録したテストスクリプトを適宜修正する。この修正は、図４に示すように、例えば、ＶＢＡで記述されたテストスクリプトをテストに合わせて追加・修正することを含む。また、例えば、イベントの追加・修正を含むものである。また、例えば、チェックの追加・修正を含むものである。

さらに、この修正は、以下のような修正を含む。

・単体モジュール、共有モジュール、クラスモジュール等を、追加・修正すること
・ユーザーフォームの追加・修正を行うこと
・オブジェクトマップの追加・修正を行うこと
その他、実行したいテストに合わせて適宜修正を行った後、図４の再生段階１６において、処理（行為、操作等も含む）の再生を行い、自動的にアプリケーションプログラムのテストを行う。

図４の結果ログ段階１８においては、結果のログが出力され、その結果に応じて、種々の処理が行われる。

例えば、再帰録を行う必要がある場合は、記録段階１２に再び処理が移行する。また、テストスクリプトの修正を行う必要がある場合は、修正段階１４に処理が移行する。また、再生を再び行う必要がある場合は、再び再生を行うために、再生段階１８に処理が移行する。

Ｆ−４．Ｔｅｓｔｐａｒｔｎｅｒのテスト対象
このように、Ｔｅｓｔｐａｒｔｎｅｒを用いることによって、テストの効率化が行われるわけであるが、その対象は、種々のアプリケーションプログラムである。

例えば、Ｗｅｂアプリケーションプログラムでもよい。すなわち、ＨＴＭＬ、ＤＨＴＭＬ、Ｊａｖａｓｃｒｉｐｔ（Ｊａｖａは登録商標）でもかまわない。さらに、デスクトップアプリケーションプログラムでもよい。すなわち、ＮＥＴプラットフォームのアプリケーションプログラムや、種々のＷｉｎｄｏｗｓ（登録商標）アプリケーションプログラム、また、いわゆるＷｉｎ３２アプリケーションを対照することができる。Ｗｉｎ３２アプリケーションとしては、ＶＢ４からＶＢ６で記述されたアプリケーションや、ＶＣ＋＋、ＪＡＶＡ（登録商標）等で記述されたアプリケーションを対象とすることが可能である。なお、ここで、ＶＢとは、ＶｉｓｕａｌＢａｓｉｃを表し、ＶＣは、ＶｉｓｕａｌＣを表す。

Ｇ．ＴｅｓｔＰａｒｔｎｅｒをより効率的に活用する手法
本実施の形態において特徴的なことの一つは、上述したように、テストスクリプトの役割を果たすものとしてより修正しやすいものを利用したことである。これが上述したスクリプト実行情報である。スクリプト実行情報はテスト実行のための情報である。

例えば、テスト実行中に、画面や帳票の表示項目や処理内容の変更などが発生するケースがある。それらの変更にしたがって、アプリケーションプログラムが変更になり、合わせてテストスクリプトも変更になる。そこで、テストスクリプト中の改修ポイントを見つけて適切に改修することは、テストの実行者にとってかなり大きな負担となっていることはよく知られている。

このように、一度作成したテストスクリプトを改修する作業を容易にし、負担軽減を図ることは従来から広く望まれてきたことである。

本実施の形態において、本願発明者は、このような要望に答えるために、ＳＴＡＲ−ＴＳＴ（商品名）と呼ばれるシステムを開発した。

図５には、このＳＴＡＲ−ＴＳＴシステムにおける作業の流れを表すタイムチャートが示されている。

この図に示すように、アプリケーションプログラムの開発作業は、要件定義２０、設計作業２２、ＰＧ（プログラム）開発２４、設計・ＰＧ（プログラム）修正２６、等の各ステップから構成される。

この開発作業に合わせて、テスト作業も順次進められる。すなわち、要件定義２０に合わせてテスト計画３０が立てられる。また、設計作業２２に合わせてテスト仕様書作成３２、及びテストデータの作成３４が行われる。また、ＰＧ（プログラム）開発２４と並行してＥＤＳの作成３６が行われる。このＥＤＳの作成３６は既に作成したテスト仕様書とテストデータが適宜利用される。

このＥＤＳは、上述したスクリプト実行情報の具体的で好適な一例であり、本実施の形態において特徴的な構成である。なお、ＥＤＳは、Ｅｘｃｅｌ Ｄａｔａ Ｓｈｅｅｔを意味する。

さて、ＥＤＳが作成されれば、テストを実行することが可能である。プログラムが完成した後、結合テスト実施３８がなされる。このテストの結果に基づき、アプリケーションの仕様変更や、ＰＧ修正２６が行われる。それと同時にＥＤＳの改修４０が行われる。

このようにして改修したＥＤＳに基づき、同様に改修されたアプリケーションプログラムについてシステムテスト実施４２がなされる。

このテストの結果に基づき、再び、設計・ＰＧ（プログラム）改修がなされ、再びテストが繰り返される。これらの処理を繰り返すことによって、良質のアプリケーションプログラムが生産されるのである。

このようなシステムを採用した結果、本実施の形態では、以下の効果が得られる。

・アプリケーションプログラムの変更があった場合に、ＥＤＳ（Ｅｘｃｅｌ Ｄａｔａ Ｓｈｅｅｔ）の実行コマンドとデータとを追加、変更、削除するだけで対応することができる。

・アプリケーションプログラムの作成者がＥＤＳを読むことによって、どのようなテストが実施されているのかを容易に把握することができる。

Ｈ．ＥＤＳ（Ｅｘｃｅｌ Ｄａｔａ Ｓｈｅｅｔ）の詳細な説明
これまで述べたように、本実施の形態において特徴的な構成の一つは、テストスクリプトに代わるものの一つとしてＥＤＳを採用したことである。以下、このＥＤＳについて詳細に説明する。

Ｈ−１．ＥＤＳデータドリブン構造のスクリプトについて
本実施の形態において、特徴的なことの一つは、従来の「テストスクリプトの実行」を、ＥＤＳ実行スクリプトがＥＤＳの実行コマンドとデータを読み、プログラムテストを実行することである。ＥＤＳ実行スクリプトとは、上述したテンプレートインタプリタスクリプトの好適な一例であり、ＥＤＳファイルを読み取り、その内容に従って、テストを事項するものである。

従来技術においては、テストスクリプトを実行することによって、テストを実行していた。一方、本実施の形態においては、ＥＤＳ実行スクリプトを実行することによって、テストを実行する。テストの具体的な内容は、「ＥＤＳ」及び「データ」ファイルに記載されている。

つまり、本実施の形態において特徴的なことは、テストの内容その物は、ＥＤＳ及びデータ（ファイル）に記述しておき、別途、その内容を読み取りその内容に基づいてテストを実行する「ＥＤＳ実行スクリプト」を準備して用いたことである。

このような構成によって、ＥＤＳ及びデータ（ファイル）の内容を修正するだけで、テスト内容を容易に変更することができ、アプリケーションプログラムの動作テストを効率的に行うことが可能となる。

Ｈ−２．比較
以下、従来のテストスクリプトと、本実施の形態とを詳細に比較する。

従来のスクリプト：
自動テストツールにおいては、対象業務プロセスをテストスクリプトとして記録・作成し、それを自動再生することによって、繰り返しテストを行うことを可能としている。アプリケーション画面の改修が生じれば、テストスクリプトの修正が必要となり、スクリプト記録機能を用いて録りなおす（再記録を行う）か、又は、直接、利用者が手作業でスクリプトの修正を行う必要があった。

本実施の形態：
本実施の形態で説明するＳＴＡＲ・ＴＳＴシステムにおいては、作成されたテスト仕様書に基づいて、ＥＤＳの実行コマンドとデータとをＥＤＳファイルに記録する。アプリケーション画面の改修が生じた場合は、ＥＤＳファイル上の画面改修分のＥＤＳ実行コマンドとそれに対応するデータとを修正するだけで基本的には対応することが可能である。

画面の改修の場合は、ＥＤＳ中にそのデータが記述されている場合が多いと考えられるが、繰り返しテスト等の場合は、データを外部のファイルで持つ場合もある。外部のデータファイルを持つ場合は、データのみが記載されているので、改修すべきデータを見つけて改修することは容易である。

Ｈ−３．ＥＤＳファイル
実際のＥＤＳファイルをコンピュータ画面に表示した場合の様子を示す説明図が図６に示されている。

本実施の形態におけるＥＤＳファイルの特徴的な事項の一つは、テスト仕様書の部分（左部）と、テスト内容を記述する部分（右部）と、の２部から構成されていることである。さらに、テスト仕様書の部分と、内容を記述する部分とは互いに対応しながら記述されている。従って、テスト仕様を確認しながら、その右側を見ることによってその具体的なテスト動作の記述を確認することが可能である。

本実施の形態では、テスト仕様を左部に記し、テスト内容を右部に記したが、左右はどちらでもかまわず、この記載の左右が逆の記載であっても同様の作用・効果を奏する。

図６中、Ａ、Ｂ、Ｃ列は、いわばテスト仕様書に相当する部分であり、Ｄ列以降は、テストの内容が記載されている。このように、本実施の形態におけるＥＤＳファイルは、単なるテストの内容だけでなく、仕様書としての役割も果たしているため、利用者が読みやすく、且つ、その内容を把握し易いという効果を有する。図６の例で言えば、まず、Ａ列には、テストケース番号が記載されている。また、Ｂ列では、試験項目、実験項目が記載されている。さらに、Ｃ列では、操作概要が記載されている。

そして、図６中、Ｄ列以降は、具体的なテストの内容が記述されている。Ｄ列では、実行コマンドが記述されているが、その内容は後に詳述する。また、Ｅ列以降は、入力データ部であり、隣り合った２個のセルが、対象オブジェクトと実行データと、を組で設定している。また、このＥＤＳファイル中のスクリプトは、便宜上５行目から読み込みが開始される。

図７には、ＥＤＳのデータ部のサンプル（テスト内容を記述する部分）を表す説明図が示されている。このサンプルは、Ｄ列以降を取り出したものである。まず、１行目は、実行コマンド「ＡＴ」が記述されており、対象のフォームにアタッチすることが記述されている。２行目は、エディットボックス「Ａ」に「９９９（異常値）」を設定することが記述されている。また、３行目には、ポップアップのメッセージＩＤがエラー値Ｅ００００２との一致を確認することが記述されている。また、４行目には、エディットボックス「Ａ」に「１００」を設定し、保存ボタンを押下（正常終了）する旨が記述されている。

なお、図８には、キャプチャによって取得された画面内のオブジェクトを表す説明図が示されている。上述したＶｉｓｕａｌＮａｖｉｇａｔｏｒ等で動作記録を取った場合（キャプチャした場合）に、記録の一環としてオブジェクトの情報が記録される。

また、図９には、本実施の形態における自動テストの実行の様子を示す説明図が示されている。この図に示すように、本実施の形態においても従来と同様に「Ｔｅｓｔｐａｒｔｎｅｒ」を用いて自動テストを実行するが、その実行対象が、ＥＤＳ実行スクリプトである点で従来技術と顕著に相違する。

つまり、従来の「テストスクリプト」に変えて、「ＥＤＳ実行スクリプト」を実行するように構成したことが、本実施の形態に置いて特徴的な事項の一つである。このＥＤＳ実行スクリプトは、上述したＥＤＳファイルを読み取り、その中に記述されている実行コマンドやデータに基づき、テストを実行していくのである。

すなわち、本実施の形態では、テスト動作を記述した従来のテストスクリプトの代わりに、汎用的なＥＤＳ実行スクリプトを実行したのである。そして、テストの具体的な内容はＥＤＳファイル中に記述したのである。つまり、ＥＤＳ実行スクリプトは、ＥＤＳファイルを読み込み、そこに記載されているテスト内容を実行していくのである。

このような構成によれば、テスト内容に変更が生じても、対応するＥＤＳファイルの内容を変更するだけで、テスト内容の変更に対応することが可能である。その結果利用者の負担が減少し、より効率的な自動テストを実行することが可能となったものである。なお、データについては、上述のようにＥＤＳファイル中に記述することも好適であるが、外部にデータファイルを準備しておくことも好適である。

Ｉ．ＥＤＳファイルの詳細
以下、ＥＤＳファイルの内容について、製造業向けの生産管理システムなどのアプリケーションプログラムを例に挙げて、詳細に説明する。

Ｉ−１．はじめに
製造業向けの生産管理システムなどのアプリケーションプログラムのテスト作業を実施するに際して、上述した自動テストツール「ＴｅｓｔＰａｒｔｎｅｒ」（以下、ＴＰと略称する）を使用する。

まず、ＴＰでテストを実行する際に使用するテストデータの作成方法を説明する。本実施の形態で説明するデータ作成方法は、データファイルを変更するだけで、一度作成したスクリプトは一切変更しないでよいというメリットを有するものである。さらに、記述規則が明確に定義されているので、当業者であれば理解し易いというメリットも有する。

Ｉ−２．基本的な表の構成
テストデータとして作成する表、すなわちＥＤＳファイルのうち、単発実行用のＥＤＳファイルは既に図６において説明した通りのものである。一方、テストの連続実行用のＥＤＳファイルの様子が図１０に示されている。この図に示すように、連続実行の場合は、単発実行用とは異なり、単発実行用のファイル名を実行したい順番で第１列（図１０ではＡ列）に記入してある。

上述したように、ＥＤＳ実行スクリプトが、このＥＤＳファイルを読み込み、単発実行用のＥＤＳファイルであれば、そこに記載されているテスト内容に基づきテストを実行する。連続実行用のＥＤＳファイルの場合は、そこに記載されている単発用のＥＤＳファイルを順次実行していく。

Ｉ−３．スクリプトの基本動作
さて、スクリプトは最初の実行フラグがら読み込みを開始し、実行フラグに従って一行ずつ処理を実行していく。ここで、実行フラグとは、実行コマンドと同じ意味である。なお、最初の実行フラグは、本実施の形態では、便宜上５行目Ｄ列から始まるものとしているが（図６参照）、原理的にはどこが最初でもかまわない。

以下、各実行フラグにおいてどのような処理がなされるのかを説明していく。

（１）実行フラグ「↓」
実行フラグ「↓」の記述様式が図１１（１）に記載されている。この実行フラグの動作は、その行は無視して次の行に移るという動作である。テストデータにコメントを入れる場合等に利用される。

（２）実行フラグ「ＡＴ」
実行フラグ「ＡＴ」の記述様式が図１１（２）に記載されている。この実行フラグの動作は、対象Ａをアタッチするという動作である。アタッチとは、対象オブジェクト（主にフォーム）を決定し、テストパートナーに処理対象を宣言することを言う。ウィンドウ（フォーム）が切り替わる毎に、その都度指定する必要がある。

（３）実行フラグ「Ｆ」
実行フラグ「Ｆ」の記述様式が図１１（３）に記載されている。

対象Ａにフォーカスがある場合は、「成功」、無い場合は「失敗」を返却する。結果はログファイルにも出力される。対象オブジェクトのフォーカスの有無について試験したい場合に利用することが好適である。

（４）実行フラグ「ＣＯＭＰ」
実行フラグ「ＣＯＭＰ」の記述様式が図１１（４）に記載されている。

この図において、対象Ａの内容とデータＡの内容が一致する場合は「成功」、一致しない場合は、「失敗」を返却する。データＡの前に！を付した場合は、不一致の確認となり、返却する結果は逆となる。また、結果はログファイルにも出力される。データの比較を行いたい場合に利用することが好適である。

（５）実行フラグ「ＲＯＷＣＯＭＰ」
実行フラグ「ＲＯＷＣＯＭＰ」の記述様式が図１１（５）に記載されている。

この図において、対象Ａ（Ｇｒｉｄオブジェクト）の全行数とデータＡとを比較し、内容が一致する場合は「成功」、一致しない場合は、「失敗」を返却する。また、結果はログファイルにも出力される。

（５）−１
実行フラグ「ＲＯＷＣＯＭＰ」の記述例の１が図１２（１）に記載されている。

この図においては、後述する実行データ「ＲＯＷ」で取得した全行数と現在の行数とが比較される。

（５）−２
実行フラグ「ＲＯＷＣＯＭＰ」の記述例の２が図１２（２）に記載されている。

この図においては、「ＲＯＷ」で取得した全行数＋１と現在の行数とが比較される。新規登録時等に利用することが好適である。

（５）−３
実行フラグ「ＲＯＷＣＯＭＰ」の記述例の３が図１２（３）に記載されている。

この図においては、「ＲＯＷ」で取得した全行数−１と現在の行数とが比較される。削除時等に利用することが好適である。

（５）−４
実行フラグ「ＲＯＷＣＯＭＰ」の記述例の４が図１２（４）に記載されている。

この図においては、「ＦＳＴ」が利用されており、これによって、現在の選択行が先頭行か否かが確認される。

（５）−５
実行フラグ「ＲＯＷＣＯＭＰ」の記述例の５が図１２（５）に記載されている。

この図においては、「ＬＳＴ」が利用されており、これによって、現在の選択行が最終行か否かが確認される。

（５）−６
実行フラグ「ＲＯＷＣＯＭＰ」の記述例の６が図１２（６）に記載されている。

この図においては、「ＬＢＬ」が利用されており、これによって、画面に表示されている全行数（ｘｘ／全行数）と現在の行数とが比較される。このフラグは、画面中に行数表示が無い場合には使用することはできない。

（６）実行フラグ「ＰＯＰＣＯＭＰ」
実行フラグ「ＰＯＰＣＯＭＰ」の記述様式が図１３（１）に記載されている。

このＰＯＰＣＯＭＰは、図１３（１）の対象Ａ（ポップアップウィンドウ）に対して実行データ（データＡ）の処理を行う。なお、ポップウィンドウへのアタッチ及び元のウィンドウへのアタッチは自動的に実行される。各実行データの例が図１３（２）〜に描かれている。

（６）−１
実行フラグ「ＰＯＰＣＯＭＰ」のデータ例の１が図１３（２）に記載されている。

この図においては、対象Ａ（ポップアップウィンドウ）の「はい」ボタンを押下する。「はい」ボタンがない場合は、使用することはできない。

（６）−２
実行フラグ「ＰＯＰＣＯＭＰ」のデータ例の２が図１３（３）に記載されている。

この図においては、対象Ａ（ポップアップウィンドウ）の「いいえ」ボタンを押下する。「いいえ」ボタンがない場合は、使用することはできない。

（６）−３
実行フラグ「ＰＯＰＣＯＭＰ」のデータ例の３が図１３（４）に記載されている。

この図においては、対象Ａ（ポップアップウィンドウ）の「ＯＫ」ボタンを押下する。「ＯＫ」ボタンがない場合は、使用することはできない。

（６）−４
実行フラグ「ＰＯＰＣＯＭＰ」のデータ例の４が図１３（５）に記載されている。

この図においては、これまで述べたデータ例以外の例が示されており、対象Ａ（ポップアップウィンドウ）に表示されるメッセージＩＤとデータＡとを比較し、一致する場合はポップアップに表示されたメッセージを、一致しない場合は、「失敗」をログファイルに出力する。エラー時のメッセージＩＤを試験するために用いられる。

（７）実行フラグ「ＧＲＩＤＣＯＭＰ」
実行フラグ「ＧＲＩＤＣＯＭＰ」の記述様式が図１４（１）に記載されている。

このＧＲＩＤＣＯＭＰは、対象Ａ（データグリッド）に対象列から検索を行い、結果をいログファイルに出力する。データＡには「対象列！検索ワード」設定する。

例えば、品名の列（２列目）から製品１を検索する場合は「２！製品１」と設定する。

（８）実行フラグ「ＤＢＣＯＭＰ」
実行フラグ「ＤＢＣＯＭＰ」の記述様式が図１４（２）に記載されている。

このＤＢＣＯＭＰは、いわゆるＳＱＬ文で、対象テーブルの該当レコードを指定し、そのレコードの対象項目と期待値（データＡ）とを比較し、内容が一致しない場合、または検索されない場合は、「失敗」を返す。その結果は。ログファイルに出力される。なお、該当レコードが一件となるように絞り込んで使用する。

例えば、以下のようにして用いる。

ＳＱＬサンプル ｓｅｌｅｃｔ＊ｆｒｏｍ（テーブル名）ｗｈｅｒｅ（検索条件）
ｓｅｌｅｃｔ＊ｆｒｏｍ Ｍ＿ＣＵＳＴＯＭＥＲ
ｗｈｅｒｅ ｎａｍｅ＿ｗ ＝ ”得意先 ７０５”
（９）実行フラグ「ＤＢＳＱＬ」
実行フラグ「ＤＢＳＱＬ」の記述様式が図１４（３）に記載されている。

このＤＢＳＱＬは、指定したいわゆるＳＱＬ文を実行するものである。

例えば、以下のようにして用いる。

ＳＱＬサンプル ｕｐｄａｔｅｓ（テーブル名）ｓｅｔ（変更内容）
ｗｈｅｒｅ（変更対象条件）
ｕｐｄａｔｅ 商品表 ｓｅｔ 単価 ＝ ２５００
ｗｈｅｒｅ 商品コード ＝ ”０００４”
（１０）実行フラグ「→」
実行フラグ「→」の記述様式が図１５（１）に記載されている。

この図１５（１）の実行フラグ「→」は、対象Ａに対して実行データ（データＡ）の処理を行う。さらに、次のデータ（対象ＢとデータＢ）を同時に実行し、データ空欄になるまでスクリプトを連続実行する。複数の入力処理や様々な処理を行うときに使用することが好適である。各実行データの例が図１５（２）〜（６）、図１６（１）〜（５）に描かれている。

（１０）−１
実行フラグ「→」のデータ例の１が図１５（２）に記載されている。

この図においては、データが「→」である場合の例が示されている。この場合は、処理を行わず、次の対象Ｂへの処理へ移る。これは、入力データの列を揃える場合等に仕様得ることが好適である。

（１０）−２
実行フラグ「→」のデータ例の２が図１５（３）に記載されている。

この図においては、対象Ａをクリックする動作が実行される。ボタンを押下した時、ラジオボタン選択時等に使用することが好適である。なお、ラジオボタンは、選択する方の項目ＩＤを対象Ａとして設定する。

（１０）−３
実行フラグ「→」のデータ例の３が図１５（４）に記載されている。

この図においては、対象Ａの内容を退避バッファに保存する。後にバッファのデータを活用することができるので、データを別の用途に用いたい場合に有用である。

（１０）−４
実行フラグ「→」のデータ例の４が図１５（５）に記載されている。

この図においては、対象Ａ（Ｇｒｉｄオブジェクト）の現在の全行数を取得する。これは、実行フラグ「ＲＯＷＣＯＭＰ」の実行前に使用することが好適である。

（１０）−５
実行フラグ「→」のデータ例の５が図１５（６）に記載されている。

この図においては、対象Ａ（ポップアップウィンドウ）の内容を検証せずに、クローズする。なお、アタッチは自動的に実行される。

（１０）−６
実行フラグ「→」のデータ例の６が図１６（１）に記載されている。

この図においては、取得データをログファイルに出力する。ここで、出力される情報は、「実行エクセルファイル名」「実行エクセル行」「アタッチ名」、「オブジェクト名」「退避バッファ情報」、であり、対象となるアプリケーションプログラムのデバッグにおおいて有用な情報を提供することができる。

（１０）−７
実行フラグ「→」のデータ例の７が図１６（２）に記載されている。

この図においては、スクリーンショットが保存される。

（１０）−８
実行フラグ「→」のデータ例の８が図１６（３）に記載されている。

この図においては、「ファイル出力」ボタンを押下し、データを保存する。「ファイル出力」ボタンがない場所では使用することはできない。この図において、対象Ａにはファイル保存時に表示されているダイアログのアタッチ名を指定する。

例えば、以下のように記述する。

部門マスタ検索画面の場合 → Ｗｉｎｄｏｗ（”部門マスタ検索ファイル出力 Ｗｉｎｄｏｗ”）
（１０）−９
実行フラグ「→」のデータ例の９が図１６（４）に記載されている。

この図においては、対象Ａに対するアタッチが行われる。実行フラグの「ＡＴ」と同様である。

（１０）−１０
実行フラグ「→」のデータ例の１０が図１６（５）に記載されている。

この図においては、画面のメニューから項目名を選択します。階層間は半角「~」で区切る。例えば、以下のように記述する。

編集メニューからコピーを選ぶ場合 → 項目名「編集（Ｅ）~コピー（Ｃ）」
（１０）−１１
実行フラグ「→」のデータ例の１１が図１７（１）に記載されている。

この図においては、指定日で指定した日にシステム日付を変更する。単独実行の最後に自動的に実行日へ戻す。また、指定日に「ＴＯＤＡＹ」と記述すると、実行日をすることができる。例えば、以下のように記述する。

２０００年元旦にする場合 → ”２００８／０１／０１”
スクリプトを実行した日が２００８／０４／０１であれば、実行後に自動的に戻る。

（１０）−１２
実行フラグ「→」のデータ例の１２が図１７（２）に記載されている。

この図においては、ファイルのコピーが行われる。ファイル名は、コピー元ファイル名とコピー先ファイル名（既存ファイルと重複しないもの）をパス込みで併記して指定する。２個のファイル名の区切りは、半角の「|」を使用する。例えば、以下のように記述する。

Ｌｏｇ．ｔｘｔをコピーする場合
”Ｃ：￥ＴｅｓｔＰａｒｔｎｅｒ￥Ｌｏｇ．ｔｘｔ |
Ｃ：￥ＴｅｓｔＰａｒｔｎｅｒ￥Ｌｏｇｃｏｐｙ．ｔｘｔ
（１０）−１３
実行フラグ「→」のデータ例の１３が図１７（３）に記載されている。

この図においては、ファイル名で指定したファイルを削除する。

（１０）−１４
実行フラグ「→」のデータ例の１４が図１７（４）に記載されている。

この図においては、対象Ａのオブジェクトが存在するか、又は、活性化しているかを判定し、その結果をログファイルに出力する。

（１０）−１５
実行フラグ「→」のデータ例の１５が図１８（１）に記載されている。

この図においては、対象Ａ（Ｇｒｉｄオブジェクト）に対して処理を行う。対象行、対象列に「ＢＵＦＦ」と記述すると、退避バッファの値が代入される。また、対象行に「ＮＯＷ」と記述すると現在指定している行が代入される。

これを読み込む場合は、「！ＣＥＬＬ，（対象行），（対象列）」の形で記述する。例えば、１行２列目のセルを読み込む動作は、以下の通りとなる。

！ＣＥＬＬ，１，２
但し、読み込みデータは退避バッファに格納する。

また、書き込む場合は、「！ＣＥＬＬ，（対象行），（対象列），データ」の形で記述する。例えば、２行３列目のセルに「１００」と入力する場合は、
！ＣＥＬＬ２，３，１００
と記述する。

セルの中のを操作するにはデータに「！ＯＮ」「！ＯＦＦ」の形で記述する。例えば、３行３列目のセルのあるチェックボックスをＯＮにするには、
！ＣＥＬＬ，３，３，！ＯＮ
と記述する。

セルの内容と期待値とを比較する場合は、データに「！ＣＯＭＰ，比較データ」の形で記述する。その結果はログ（ログファイル）に出力される。例えば、１行１列目のセルの内容が「ＡＢＣ」であるかどうかを確認するには、
！ＣＥＬＬ，１，１，！ＣＯＭＰ，ＡＢＣ
と記述する。また、指定セルを選択する場合は、データに「！ＳＬＣＴ」の形で記述する。例えば、３行１列目を選択するには、
！ＣＥＬＬ，３，１，！ＳＬＣＴ
と記述する。

（１０）−１６
実行フラグ「→」のデータ例の１６が図１８（２）に記載されている。

この図においては、対象Ａ（構成マスタの構成図）に対して処理を行う。検索ワードのある行を選択する場合は、「！ＯＢＪ，（検索ワード）、」と記述する。検索ワードはユニークな値を用いる必要がある。

（１０）−１７
実行フラグ「→」のデータ例の１７が図１８（３）に記載されている。

この図においては、対象ＡにデータＡを書き込む。なお、対象がコンボボックスの場合は選択肢のインデックスを指定する。対象がチェックボックスの場合は、チェックするときは「１」、チェックを外すときは「０」を指定する。また、対象がタブコントロールの場合は、データＡのタブが選択される。

（構成マスタの構成図）に対して処理を行う。検索ワードのある行を選択する場合は、「！ＯＢＪ，（検索ワード）、」と記述する。検索ワードはユニークな値を用いる必要がある。

Ｉ−４． 注意事項
（１）テストの実行に必要となるので、テスト用の所定の名称のフォルダを作成しておくことが好ましい。例えばログファイルはこのフォルダにＴＰ＿ＬＯＧ．ｔｘｔというファイル名で出力することが好ましい。作成したテストデータを格納したファイルもこのフォルダに格納しておくことが好適である。テストデータを格納したファイルも、表形式で構成しておくことが好ましい。行番号と、列番号とで、データの位置を指定し易くなるためである。例えばマイクロソフト社のＥＸＣＥＬ等のファイル形式を利用することが好適である。

また、上記フォルダの下に、画像を保管するための「ＪＰＧ」フォルダや、データを保管するための「ＣＳＶ」フォルダを設けておくことが好適である。例えば、テストの途中のスクリーンショットなどの画像データを上記「ＪＰＧ」フォルダに格納し、テストの中間値データを、上記「ＣＳＶ」フォルダに格納することなどが好適である。

（２）対象オブジェクト名は、画面オブジェクト一覧等を参照して選択する。

（３）規定の実行フラグ、実行データは、全て大文字のアルファベットで記述することがわかりやすさの点から好ましいが、内容が明らかであれば、小文字や記号が含まれていても良い。

（４）空欄（ＮＵＬＬ）のデータを入力したい場合は、「！ＮＵＬＬ」と記述する。

（５）退避バッファのデータを使用する場合は、「！ＢＵＦＦ」と記述する。

（６）本実施の形態では、実行フラグがＤ列、データ開始行が５行目である例を示したが、目的・用途に応じてどこから記載してもかまわない。

（７）本実施の形態では、従来のテストスクリプトの実行に変えて、ＥＤＳ実行スクリプトが、ＥＤＳファイル中に記述されたテスト内容を実行する。そのため、ＥＤＳファイルの名称は重要である。

したがって、本実施の形態において、スクリプトの実行を行うと、上記ＥＤＳ実行スクリプトが参照するＥＤＳファイル名が必要となる。そこで、この使用するＥＤＳファイル（エクセルファイル）名を求めるダイアログが表示される。利用者はこのダイアログに対して、実行したいテスト内容を記述したＥＤＳファイルのファイル名を入力する。

次に、本実施の形態におけるテストシステムにおいては、指定されたファイル名のＥＤＳファイルが連続実行用のファイルか否かを聞くダイアログを表示する。もし、指定したファイル名が連続実行用のファイルであれば、利用者が、「ＹＥＳ」を選択（例えばクリック）し、単発実行用であれば、「ＮＯ」を選択する必要がある。なお、単発実行用のファイルであった場合は、ＥＤＳファイル中のどの行から開始するかその開始行を指定するためのダイアログが表示されるので、適宜、利用者は所望の行番号を入力する。なお、このダイアログにおいて、デフォルト値は「５」であり、そのまま「ＯＫ」ボタンをクリックすれば、その５がそのまま入力される。他の行から始めたい場合は、デフォルト値の５を適宜他の値に変更してから「ＯＫ」ボタンをクリックすることが好ましい。

Ｉ−５．サンプルデータの一例
図１９には、サンプルデータの好適な一例が示されている。この図は、上述したＥＤＳファイル中のＤ列以降、Ｈ列までの例である。また、この図には、第５行から８行までが描かれている。

まず、第１行目には、対象のフォームにアタッチする旨のフラグ及びその対象物の項目等が記述されている。ＥＤＳ実行ファイルは、この内容を読みとって、対象のフォームにアタッチすることを自動的に実行する。このような自動的に実行することによって、テストを自動的に行うことが可能である。

次に、第２行目には、エディットボックス「Ａ」に、「９９９（異常値）」を設定し、保存ボタンを押下する。これはエラーのポップアップを自動的に出させるという主旨がある。つまり、エラーポップアップのテストである。

また次に、第３行目には図に示すようにポップアップのメッセージＩＤがＥ０００００２と一致するか否かが確認される。

第４行目には、エディットボックス「Ａ」に「１００」を設定し、保存ボタンを押下し、正常終了することを表している。

J. 従来のテストスクリプトと、本実施の形態のＥＤＳファイルとの相違。

上述したように、本実施の形態において特徴的なことは、従来のテストスクリプトを、ＥＤＳ実行ファイルと、ＥＤＳファイルとで代替したことである。特に、ＥＤＳファイルは、テーブル形式（表形式）を採用しており、そのテストの動作内容が容易に理解することができる。

以下、このＥＤＳファイルと、従来のテストスクリプトとを具体的に比較してその相違を詳細に説明する。

Ｊ−１． ＥＤＳファイルと従来のテストスクリプト
まず、図２０には、経費の計算のアプリケーションプログラムの動作テストのためのＥＤＳファイル（１−１）と、従来のテストスクリプト（１−２）とが示されている。

このテストは、経費入力画面の入力と、その結果を確認するシナリオに基づき行われる。このテストの具体的なテスト事例のテスト手順シナリオとしては、次のような手順を想定している。

（ａ）支出内容にアタッチ
（ｂ）実施日の入力
（ｃ）行き先・訪問先入力
（ｄ）用件選択
（ｅ）用件内容入力
（ｆ）交通費入力（電車：１０００円、タクシー：１２００円、→小計２２００円
このような内容に基づき、ＥＤＳファイルを構成すれば、上記１動作がほぼ１行の動作記述に相当する。

本来、ＥＤＳファイルは、図２０において左側の３列がテスト仕様書としての役割を果たしており、そのテスト仕様書の内容をその右側の各行に記述していった形式を採用する。したがって、その各行の動作は、テスト仕様書の各動作、利用者の各動作に対応したものであり、かつ、並んで配置されているため、その対応が一目瞭然である。

これに対して、従来のテストスクリプトは、典型的には、コンピュータの動作を記録したプログラムである。例えばＶＢＡ等のプログラム言語で記述されたものであり、コンピュータの動作が記録されている。このプログラムを実行すれば、当然記録された動作と土曜の動作を再現することが可能である。このように従来のテストスクリプトはコンピュータの動作の記録をしているものであるから、使用者の動作毎、シナリオに記載された各動作毎の記述とは成らずに、より細かい（いわゆるより低レベルの動作）の記述が続いている。

したがって、ＥＤＳファイルの方がよりシナリオに記述された各概念に近い上位概念を記述しているので、全体の量が少なくすることが可能である。さらに、テスト仕様書の動作に対応して記述されているので、どのような動作が記述されているのかを一目瞭然に知ることが可能である。

Ｊ−２．テスト結果の確認の追加
次に、小計金額の表示値と、期待値との比較を上記図２０に追加する。

追加した図が、図２１に示されている。図２１（２−１）は、試験項目として、計算チェックが設けられ、操作概要として結果表示の比較が記されている。これらがテスト仕様書としての役割を果たしている。更にそれら「仕様書」の右側にはコマンド「ＣＯＭＰ」や、対象オブジェクト、及び、入力値が記載されており、これらに基づき、各動作を実行することが可能である。

一方、従来のテストツールでは、チェック比較の、ツールに依存したチェック設定が可能であるが、図２１の例ではＶＢＡによる判定ルーチンを追加してある（図２１（２−２）参照）。

結局の所、従来のテストスクリプトは、一般的なコンピュータ言語であり、新しく、値の比較、及び、その結果の表示のためのルーチンを作成して、原プログラムに挿入されている（図２１参照）。

Ｊ−３．データ追加・ボタン操作の追加テスト
次に、データの追加と、ボタン操作の追加の例を説明する（図２２）。

追加した図が、図２２に示されている。図２２（３−１）には、図２１に対して試験項目として、ボタンを押下するという動作が付け加えられ、かつ、実施日や、行き先等のデータの追加がなされている様子が示されている。

一方、図２２（３−２）には、従来のテストスクリプトに対して、同様にボタン操作等を追加した例が示されている。

このように、従来のテストスクリプトにおいては、ボタン操作の追加のために２行追加されるが、ＥＤＳファイル形式によれば、「ボタンを押す」という項目に対応したコマンドを１行追加するだけで、テスト内容の調整が可能である。

Ｊ−４．データベースへの更新内容の確認
次に、外部のデータベースのレコードの更新内容の確認等を追加する例を説明する（図２３）。

まず、図２３（４−１）には、ＥＤＳファイルの例が示されている。ＥＤＳ形式において、データベースに書き込まれたデータをチェックするロジックが準備されているので、そのロジックに基づいたコマンドと、比較データとをＥＤＳファイルに追加するだけで、外部のデータベースの交信内容の確認作業をテストに含めることができる。

一方、図２３（４−２）には、従来のテストスクリプトに対して、同様にデータベースの更新内容を確認する動作を追加した様子を示す説明図が示されている。この図に示されているように、まず、データベースの読み込みチェックのルーチンを作成する必要がある。その上で、モジュールのデータベースチェックを行う箇所に、この新たに作成したルーチンをコールする文を挿入する。

このような動作によって、従来のテストスクリプトにおいては、新たにサブルーチンを作成し、且つ、テストプログラムから読み出し（コール）を行う必要があるが、ＥＤＳファイルによれば対応するコマンドと比較データとを入れるだけで、データベースの更新内容を確認するテストを容易に実行することが可能である。

Ｊ−５．チェック対象項目の追加又は削除
次に、テストにおけるチェック対象項目（画面オブジェクト）の追加、削除の例を説明する（図２４）。

まず、図２４（５−１）には、ＥＤＳファイルの例が示されている。図２４に記載されているとおり、支出内容入力２が、支出内容入力２’に変わる例を説明する。この場合、図２４（５−１）の通り、
行先・訪問先入力が、目的選択に変更
用件選択が、目的内容入力に変更
用件内容入力が、利用店名入力に変更
交通費等入力が、属性選択、出席者・区分選択、出席者・会社名入力、出席者・姓入力、出席者・名入力、出席者・属性選択、合計人数入力、支出金額入力に変更
このような、項目の削除、追加を反映し、図２４（５−１）に記載の通り、項目が適宜「削除」「追加」されている。各画面オブジェクトが１行に対応するため、削除された項目、追加された項目が極めてわかりやすい。

一方、図２４（５−２）には、従来のテストスクリプトに対して、同様にチェック対象項目（画面オブジェクト）を追加、削除した例が示されている。この図に示されているように、ＥＤＳファイルの場合と同様に、各オブジェクト毎に。削除・追加が行われることになる。

Ｊ−６．テストの開始時期
本実施の形態の手法によれば、従来の方式よりより早くテストを開始することができ、開発期間の短縮化を図ることができる。図２６には、その様子を説明する説明図が示されている。

この図に示すように、ＴｅｓｔＰａｒｔｎｅｒ（ＴＰ）のみ使用した場合の作業の流れでは、プログラムの開発の後、プログラムの改修の段階から画面操作等のＴＰスクリプトの取得が行われる。そして、このＴＰスクリプトによる繰り返しテストの実施が行われる。

一方、本実施の形態のＥＤＳを使用した場合の作業の流れでは、プログラム開発の段階から、テスト仕様書の作成及びＥＤＳの作成が開始される。そのため、プログラムの改修と共にＥＤＳを実行することができ、早期にテストを開始することができる。

すなわち、設計・プログラム仕様書作成後にプログラム開発と並行してＥＤＳの作成をおこなうことができる。ＴｅｓｔＰａｒｔｎｅｒのみ使用した場合のようにスクリプトを取得することがなく、すぐにテストを開始することができるので、極めて効率的にテストをすすめることが可能である。

Ｋ．変形例・応用例
（１）上述した実施の形態では、エクセルのデータフォーマットを用いたＥＤＳファイルを利用したが、テーブル形式・表形式であれば、他の形式のフォーマットを用いることも好適であり、同様の作用・効果を奏する。

（２）また、ＥＤＳファイルは、一般的にはコンピュータ内部のハードディスク等に記録しておくことが好ましいが、各種半導体メモリや、各種光学式ディスク・磁気ディスク記録媒体に記録しておくことも好適である。コンピュータがこれら記録媒体に記録されたＥＤＳファイルを適宜読み出して利用する。

（３）また、ＥＤＳファイルは、本請求の範囲のスクリプト実行情報の好適な一例に相当する。

（４）本実施の形態のＥＤＳ実行スクリプトは、例えばＶＢＡで記述されるが、他の言語で記述されていても良い。いずれの場合もコンピュータがこのＥＤＳ実行スクリプトを実行することによって、ＥＤＳファイルの内容を読み出し、そこに記載されているテストを実行していく。

（５）ＥＤＳ実行スクリプトは、一般的にはコンピュータ内部のハードディスク等に記録しておくことが好ましいが、各種半導体メモリや、各種光学式ディスク・磁気ディスク記録媒体に記録しておくことも好適である。コンピュータがこれら記録媒体に記録されたＥＤＳ実行スクリプトを実行すると、ＥＤＳファイルの内容を読み出してそこに記載されているテストを順次実行していく。

（６）また、ＥＤＳ実行スクリプトは、請求の範囲のインタプリタスクリプトの好適な一例に相当する。

１０ 準備段階
１２ 記録段階
１４ 修正段階
１６ 再生段階
１８ 結果ログ段階
２０ 要件定義
２２ 設計作業
２４ ＰＧ開発
２６ 設計・ＰＧ修正
３０ テスト計画
３２ テスト仕様書
３４ テストデータ作成
３６ ＥＤＳ作成
３８ 結合テスト実施
４０ ＥＤＳ改修
４２ システムテスト実施

Claims (6)

1. アプリケーションプログラムをテストする方法において、
   テストの内容に基づき、テスト実行のための情報であるスクリプト実行情報を作成するスクリプト実行情報作成ステップと、
   インタプリタスクリプトが、前記スクリプト実行情報を読み出し、その内容に基づいて前記アプリケーションプログラムの動作をテストするテストステップと、
   を含むことを特徴とするアプリケーションプログラムをテスト方法。
2. 請求項１記載のアプリケーションプログラムをテストする方法において、
   前記スクリプト実行情報は、テーブル形式で記述されていることを特徴とするアプリケーションプログラムをテストする方法。
3. 請求項１又は２に記載のアプリケーションプログラムをテストする方法において、
   前記スクリプト実行情報は、
   テストの試験項目及び操作内容を記述した仕様部と、テスト動作を記述したデータ部と、から成ることを特徴とするアプリケーションプログラムをテストする方法。
4. 請求項１又は２に記載のアプリケーションプログラムをテストする方法において用いられる前記スクリプト実行情報を格納した記録媒体において、
   前記スクリプト実行情報は、
   テストの試験項目及び操作内容を記述した仕様部と、テスト動作を記述したデータ部と、から成ることを特徴とするスクリプト実行情報を記録した記録媒体。
5. 請求項１〜３記載のいずれか１項に記載のアプリケーションプログラムをテストする方法において、
   前記スクリプト実行情報は、マイクロソフト社のエクセルのデータファイルとして作成されていることを特徴とするアプリケーションプログラムをテストする方法。
6. コンピュータに、請求項１記載のアプリケーションプログラムをテストする方法中のテストステップを実行させるプログラムにおいて、
   前記コンピュータに、
   前記スクリプト実行情報を読み出させる読み出し手順と、
   前記読み出した前記スクリプト実行情報中からフラグを読み出し、そのフラグの内容に基づきテスト動作を実行する手順と、
   を実行させることを特徴とするプログラム。

Images