JP2017021475A - ソフトウェア試験装置及びプログラム - Google Patents

Abstract

【課題】カスタマイズソフトウェアの自動テストを効率的に実行可能なソフトウェア試験装置及びプログラムを提供する。【解決手段】ソフトウェア試験装置の自動テスト実行部３０は、テスト基盤部３１と、自動化ライブラリ実行部３４とを有し、ソフトウェア試験装置の所定のフォルダ２１には、テスト対象アプリＡｐと、テスト対象アプリＡｐの設定内容を示す設定ファイルＦｏとが格納されている。テスト基盤部は、設定ファイルＦｏと、テスト対象Ａｐアプリとを抽出し、自動化ライブラリ実行部にテスト対象アプリＡｐをテスト対象端末３へインストールさせる。ソフトウェア試験装置の記憶部は、設定ファイルＦｏにおいて指定され得る各設定に対して必要なテストシナリオＴｓを記憶し、テスト基盤部は、読み込んだ設定ファイルＦｏにおいて指定された設定に基づき、実行すべきテストシナリオＴｓを判定する。【選択図】図２

Description

本発明は、ソフトウェアの自動テストの技術に関する。

従来から、ソフトウェアの作業効率化又は人的誤りの排除を目的としたテストの自動化手法が提案されている。例えば、特許文献１には、ソフトウェアの設計情報に基づいてテスト項目を自動生成する技術が開示されている。また、特許文献２には、ソフトウェアの実行結果の検証を自動化する技術が開示されている。

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

ソフトウェアソースコードとソフトウェアの機能を定義するファイルである設定ファイルとを入力としてビルドされ、設定ファイルの内容に応じてビルドされる機能が変化するソフトウェア（「カスタマイズソフトウェア」とも呼ぶ。）では、設定ファイルでの設定内容に応じてソフトウェアの機能が異なる。よって、異なる設定のカスタマイズソフトウェアには、異なるテスト項目を実行する必要があるため、自動テストプログラムの開発を個々に行う必要があった。

そこで、本発明は、カスタマイズソフトウェアの自動テストを効率的に実行可能なソフトウェア試験装置及びプログラムを提供することを主な課題とする。

本発明の１つの観点では、ソフトウェア試験装置は、実装する機能に関する設定を指定した設定ファイルを入力としてビルドされるソフトウェアの試験を行うソフトウェア試験装置であって、前記設定ファイルにおいて指定され得る各設定に対して必要な試験項目を記憶する記憶手段と、前記試験を行うソフトウェアの設定ファイルを取得するファイル取得手段と、前記設定ファイルにおいて指定された設定に基づき、前記記憶手段に記憶された試験項目のうち、実行すべき試験項目を判定する試験項目判定手段と、を有する。

上記ソフトウェア試験装置は、実装する機能に関する設定を指定した設定ファイルを入力としてビルドされるソフトウェアの試験を行う。ここで、「機能に関する設定」には、デザインに関する設定も含む。ソフトウェア試験装置は、記憶手段と、ファイル取得手段と、試験項目判定手段と、を有する。記憶手段は、設定ファイルにおいて指定され得る各設定に対して必要な試験項目を記憶する。ファイル取得手段は、試験を行うソフトウェアの設定ファイルを取得する。試験項目判定手段は、設定ファイルにおいて指定された設定に基づき、記憶手段に記憶された試験項目のうち、実行すべき試験項目を判定する。この態様により、ソフトウェア試験装置は、設定ファイルの設定内容に応じて試験項目を適切に抽出し、設定が異なるカスタマイズソフトウェアに対して必要な試験を的確に実行することができる。従って、この場合、ソフトウェア試験装置は、単一のテストプログラムにより、各カスタマイズソフトウェアに必要な試験を実行することができる。

上記ソフトウェア試験装置の一態様では、前記記憶手段は、前記試験項目として、一連の動作を規定するテストシナリオと、前記テストシナリオにおける個々の処理を規定するテストケースとを記憶し、前記試験項目判定手段は、前記設定ファイルにおいて指定された設定に基づき、実行すべきテストシナリオ及びテストケースを判定する。この態様により、ソフトウェア試験装置は、設定ファイルでの設定内容が異なるカスタマイズソフトウェアに対し、必要な試験を好適に実行することができる。

上記ソフトウェア試験装置の他の一態様では、ソフトウェア試験装置は、前記試験を行うソフトウェアの動作環境を認識する動作環境認識手段と、前記判定手段が実行すべきと判定した試験項目のコードを、前記動作環境に応じて変換する変換手段と、をさらに有する。ここで、「動作環境」は、ソフトウェアを実行するオペレーティングシステム（ＯＳ）を含む。この態様により、ソフトウェア試験装置は、ソフトウェアの動作環境ごとにテストプログラムを用意することなく、単一のテストプログラムにより、種々の動作環境で動作させるソフトウェアの試験を好適に実行することができる。

上記ソフトウェア試験装置の他の一態様では、前記記憶手段は、前記試験項目のコードにおいて記述されるオブジェクトを、所定の動作環境において機能する表記に変換するためのマップ情報を、前記ソフトウェアが実行され得る動作環境ごとに記憶し、前記変換手段は、前記動作環境認識手段が認識した動作環境に対応する前記マップ情報を参照し、前記試験項目のコード内のオブジェクトの表記を変換する。ここで、「オブジェクト」とは、表示や操作の対象となるユーザインターフェースの要素を表すものを指す。

一般に、ＯＳ等に依存する動作環境ごとにコードに記述するオブジェクトの表記が異なる。この場合であっても、ソフトウェア試験装置は、動作環境ごとにマップ情報を記憶し、試験を行う動作環境に対応するマップ情報を参照することで、動作環境ごとにテストプログラムを用意することなく、種々の動作環境でのソフトウェアの試験を好適に実行することができる。

上記ソフトウェア試験装置の他の一態様では、ソフトウェア試験装置は、前記判定手段が実行すべきと判定した試験項目の処理を実行するための情報を、前記ソフトウェアを実行する端末に入力する、又は、前記端末と同一の動作環境を模倣したエミュレータに入力する試験実行手段をさらに有する。これにより、ソフトウェア試験装置は、種々の動作環境下で必要なソフトウェアの試験を好適に行うことができる。

本発明の別の観点では、実装する機能に関する設定を指定した設定ファイルを入力としてビルドされるソフトウェアの試験を行い、前記設定ファイルにおいて指定され得る各設定に対して必要な試験項目を記憶する記憶手段を参照するコンピュータが実行するプログラムであって、前記試験を行うソフトウェアの設定ファイルを取得するファイル取得手段と、前記設定ファイルにおいて指定された設定に基づき、前記記憶手段に記憶された試験項目のうち、実行すべき試験項目を判定する試験項目判定手段として前記コンピュータを機能させる。コンピュータは、このプログラム実行することで、設定ファイルでの設定内容が異なるカスタマイズソフトウェアに対しても、各ソフトウェアに必要な試験を実行することができる。

本発明に係るソフトウェア試験装置によれば、設定ファイルでの設定内容が異なるカスタマイズソフトウェアに対しても、単一のテストプログラムを実行することで、各ソフトウェアに必要な試験を実行することができる。

実施形態に係るソフトウェア試験装置の構成例を示す。 自動テスト実行部の概略的な機能構成を示す。 設定ファイルのデータ構造を示す。 実行すべきテストシナリオ及びテストケースを抽出した例を示す。 自動テストの処理手順を示すフローチャートである。 テストシナリオ実行処理の手順を示すフローチャートである。 オブジェクトマップを選択する必要性を説明する図である。 図６のステップＳ２０３の処理内容を示す概要図である。 テスト基盤部によるテストケースの変換処理、及び、自動化ライブラリ実行部による変換処理の概要を示す図である。

以下、図面を参照しながら、本発明を実施するのに好適な実施形態について説明する。以後において、「カスタマイズソフトウェア」とは、ソフトウェアソースコードとソフトウェアの機能（デザインも含む）を定義するファイル（「設定ファイルＦｏ」とも呼ぶ。）とを入力としてビルドされ、設定ファイルＦｏの内容に応じてビルドされる機能が変化するソフトウェアを指す。

［ソフトウェア試験装置の構成］
図１は、本実施形態に係るソフトウェア試験装置１の構成例を示す。ソフトウェア試験装置１は、試験の対象となるカスタマイズソフトウェア（「テスト対象アプリＡｐ」とも呼ぶ。）の試験を設定ファイルＦｏの設定内容によらずに単一のテストプログラム（「自動テストプログラム」とも呼ぶ。）によって自動で実行する。ソフトウェア試験装置１は、ディスプレイなどの表示部１０と、キーボードやマウスなどの入力部１１と、記憶部１２と、制御部１３と、インターフェース１４とを備える。これらの各要素は、バスライン１９を介して相互に接続されている。

記憶部１２は、制御部１３が実行するプログラム及び当該プログラムの実行に必要な情報を記憶する。例えば、記憶部１２は、任意のプログラミング言語で作成された自動テストプログラムを記憶する。自動テストプログラムは、テスト対象アプリＡｐの試験（テスト）を行うプログラムであって、設定ファイルＦｏでの任意の設定内容に応じて実行するテスト項目を自動的に選択する。また、自動テストプログラムには、テスト対象アプリＡｐを実行するテスト対象端末３のＯＳの違いを吸収するためのａｐｐｉｕｍなどの自動化ライブラリも含まれている。また、記憶部１２は、テスト対象アプリＡｐと、当該テスト対象アプリＡｐの機能を定義した設定ファイルＦｏとの組を、所定のフォルダ（ディレクトリ）にまとめて記憶する。さらに、後述するように、記憶部１２は、ＯＳの種類（バージョンの違いも含む）ごとにコード内での表記が異なるボタン、ラベル、画像などのオブジェクトの表記について規定したマップ（「オブジェクトマップＭｐ」とも呼ぶ。）を記憶する。

インターフェース１４は、テスト対象アプリＡｐを実行する実機であるテスト対象端末３とソフトウェア試験装置１とが電気的に接続するためのインターフェースである。テスト対象端末３は、例えば、テスト対象アプリＡｐの実行環境となるＯＳの種類及びＯＳのバージョンごとに用意される。

制御部１３は、図示しないＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などを備え、ソフトウェア試験装置１の全体を制御する。本実施例では、制御部１３は、自動テストプログラムを実行することで所定の処理を実行する自動テスト実行部３０を有する。自動テスト実行部３０の処理内容については、後述する。制御部１３は、本発明における「ファイル取得手段」、「試験項目判定手段」、「動作環境認識手段」、「変換手段」、「試験実行手段」、及び本発明におけるプログラムを実行する「コンピュータ」の一例である。

［自動テストの概要］
図２は、自動テストプログラムに基づき動作する自動テスト実行部３０の概略的な機能構成を示す図である。図２の例では、自動テスト実行部３０は、テスト基盤部３１と、自動化ライブラリ実行部３４とを有する。また、ソフトウェア試験装置１の所定のフォルダ２１には、バイナリ形式等のテスト対象アプリＡｐと、当該テスト対象アプリＡｐの設定内容を示す設定ファイルＦｏとが格納されている。

テスト基盤部３１は、記憶部１２が記憶する予め指定されたフォルダ２１に含まれる設定ファイルＦｏと、テスト対象アプリＡｐとを抽出する。そして、テスト基盤部３１は、抽出したテスト対象アプリＡｐを自動化ライブラリ実行部３４へ供給し、自動化ライブラリ実行部３４に、供給されたテスト対象アプリＡｐをテスト対象端末３へインストールさせる。

また、テスト基盤部３１は、読み込んだ設定ファイルＦｏに基づき、実行すべきテスト項目の処理を記述したテストシナリオＴｓを選択する。ここで、テストシナリオＴｓは、テスト用の一連の動作を規定したプログラムコードであり、記憶部１２は、設定ファイルＦｏのあらゆる設定内容に対応して実行すべきテストシナリオＴｓを予め記憶している。そして、テスト基盤部３１は、設定ファイルＦｏに基づき、予め用意されたテストシナリオＴｓから、実行する必要があるテストシナリオＴｓを選択する。なお、後述するように、各テストシナリオＴｓは、複数のテストケースから構成される。

また、テスト基盤部３１は、テスト対象端末３のＯＳの種類及びバージョンの情報をテスト対象端末３または入力部１１への入力情報に基づき取得し、テスト対象端末３のＯＳの種類及びバージョンに対応するオブジェクトマップＭｐを取得する。ここで、オブジェクトマップＭｐは、自動テストプログラム上でのオブジェクトの表記名と、テスト対象アプリＡｐの実行環境となるＯＳの種類及びバージョンに準じた表記との対応関係を示すマップであって、テスト対象アプリＡｐの実行環境となるＯＳの種類及びバージョンごとに用意されている。そして、テスト基盤部３１は、選択したテストシナリオＴｓで用いられるオブジェクトの表記を、テスト対象端末３のＯＳの種類及びバージョンに対応するオブジェクトマップＭｐを参照して変換する。そして、テスト基盤部３１は、オブジェクトの表記を変換したコードを、自動化ライブラリ実行部３４へ供給する。

自動化ライブラリ実行部３４は、ＯＳの種類及びバージョンの違いを吸収するためのａｐｐｉｕｍなどの既存の自動化ライブラリに基づく処理を行う。具体的には、自動化ライブラリ実行部３４は、実行すべきテストシナリオＴｓのコードをテスト基盤部３１から受信し、テスト対象アプリＡｐを実行するテスト対象端末３のＯＳの種類及びバージョンに準拠した形式に変換する。この場合、自動化ライブラリ実行部３４は、例えば、テスト基盤部３１によってテスト対象端末３のＯＳの種類及びバージョンに対応するように変換されたオブジェクトを引数とする命令（関数）を、テスト対象端末３のＯＳが実行可能な形式に変換し、変換したコードをテスト対象端末３へ供給してテスト対象端末３に実行させる。

ここで、設定ファイルＦｏ及びテストシナリオＴｓの具体例について、図３及び図４を参照して説明する。

図３は、設定ファイルＦｏのデータ構造の一例である。設定ファイルＦｏは、例えばＸＭＬファイルであって、設定項目ごとに、設定内容が記述されている。設定ファイルＦｏでは、テスト対象アプリＡｐに付加可能なオプションの機能の要否が指定されている。例えば、図３の例では、デジタルクーポンの機能については、当該機能を付加する旨（「あり」）の設定となっており、デジタル会員証及びプッシュ通知の機能については、当該機能を付加しない旨（「なし」）の設定となっている。

また、テスト対象アプリＡｐに付加する設定となっている機能については、さらに詳細な設定を指定することが可能である。図３の例では、テスト対象アプリＡｐに機能を付加する設定となっているデジタルクーポンについては、利用回数及びデザインなどの種々の詳細項目について、設定内容が指定されている。そして、テスト対象アプリＡｐは、図３に示すような設定ファイルＦｏを入力としてビルドされることで生成される。

図４は、図３の設定ファイルＦｏによりビルドされたテスト対象アプリＡｐに対して実行すべきテストシナリオＴｓ及びテストケースを可視化した図である。ここで、テストケースは、テストシナリオＴｓに相当する一連の処理を構成する個々の処理に相当する。例えば、あるテストシナリオＴｓが「クーポンを表示する」という一連の画面遷移の動作を規定するものである場合、当該テストシナリオＴｓを構成するテストケースは、例えば、「クーポンの一覧表示画面を表示する処理」、「一覧から選択されたクーポンの詳細画面を表示する処理」、及び「詳細画面からクーポンのバーコードを表示させる処理」といった３つのテストケースから構成される。

図４では、テストシナリオＴｓがテストシナリオＴｓ１からテストシナリオＴｓｎまで存在し、そのうち、自動テスト実行部３０は、図３の設定ファイルＦｏに基づき、テストシナリオＴｓ１及びテストシナリオＴｓｎを含む複数のテストシナリオＴｓを実行すべきと判断する。また、図４の例では、テスト基盤部３１は、実行すべきテストシナリオＴｓ１に属するテストケースＡ１〜Ａ４のうち、テストケースＡ１、Ａ２を実行すべきと判断している。また、テスト基盤部３１は、実行すべきテストシナリオＴｓｎに属するテストケースＸ１〜Ｘ３のうち、テストケースＸ１、Ｘ３を実行すべきと判断している。

このように、あらゆる設定ファイルＦｏでの設定内容を想定したテストシナリオ及びテストケースを予め記憶部１２が記憶しておき、テスト基盤部３１は、読み込んだ設定ファイルＦｏから、実行すべきテストシナリオＴｓ及びテストケースを選択する。この場合、例えば、各テストシナリオＴｓ及びテストケースのコードには、設定ファイルＦｏの所定の設定項目を参照して実行要否を判定する部分が含まれている。これにより、テスト基盤部３１は、好適に設定ファイルＦｏに応じて実行すべきテストシナリオＴｓ及びテストケースを選択することができる。

［処理フロー］
図５は、テスト基盤部３１が実行する処理手順を示すフローチャートである。テスト基盤部３１は、所定のフォルダにテスト対象アプリＡｐと設定ファイルＦｏが配置された状態で、ユーザによる所定の入力に基づき図５のフローチャートの処理を開始する。

まず、テスト基盤部３１は、所定のフォルダに配置されたテスト対象アプリＡｐを抽出し、当該テスト対象アプリＡｐをテスト対象端末３へ供給することでテスト対象アプリＡｐをテスト対象端末３へインストールさせる（ステップＳ１０１）。さらに、テスト基盤部３１は、設定ファイルＦｏを上述のフォルダから読み込む（ステップＳ１０２）。

次に、テスト基盤部３１は、設定ファイルＦｏでの設定内容に基づき、テストシナリオＴｓの実行要否を判定する（ステップＳ１０３）。この場合、テスト基盤部３１は、設定ファイルＦｏで指定可能な全ての設定内容のバリエーションに対応した複数のテストシナリオＴｓのうち、各テストシナリオＴｓに対して上述の判定を行う。そして、テスト基盤部３１は、判定対象のテストシナリオＴｓを実行すべきと判断した場合（ステップＳ１０４；Ｙｅｓ）、当該テストシナリオＴｓを実行するためのテストシナリオ実行処理を行う（ステップＳ１０５）。テストシナリオ実行処理の詳細については、図６を参照して後述する。また、この場合、テスト基盤部３１は、テストシナリオ実行処理によりテスト対象端末３に実行させた処理の結果を示すデータを、テスト対象端末３から自動化ライブラリ実行部３４を介して受信する。一方、テスト基盤部３１は、判定対象のテストシナリオＴｓを実行する必要がないと判断した場合（ステップＳ１０４；Ｎｏ）、ステップＳ１０５を行うことなくステップＳ１０６へ処理を進める。

次に、テスト基盤部３１は、予め用意された全てのテストシナリオＴｓについて、ステップＳ１０３で実行要否を判定したか否か判定する（ステップＳ１０６）。そして、テスト基盤部３１は、予め用意された全てのテストシナリオＴｓについてステップＳ１０３で実行要否を判定したと判断した場合（ステップＳ１０６；Ｙｅｓ）、テストシナリオ実行処理によりテスト対象端末３に実行させた処理結果であるテスト結果のデータを出力する（ステップＳ１０７）。この場合、テスト基盤部３１は、表示部１０にテスト結果のデータを表示させてもよく、ファイル形式にして記憶部１２に記憶させてもよい。

一方、テスト基盤部３１は、全てのテストシナリオについてステップＳ１０３で実行可否を判定していないと判断した場合（ステップＳ１０６；Ｎｏ）、再びステップＳ１０３へ処理を戻し、用意された個々のテストシナリオについて実行可否を判定する。

図６は、ステップＳ１０５のテストシナリオ実行処理の手順を示すフローチャートである。

まず、テスト基盤部３１は、テスト対象アプリＡｐを実行するテスト対象端末３のＯＳの種類及びバージョンを認識する（ステップＳ２０１）。この場合、テスト基盤部３１は、入力部１１への入力に基づきテスト対象端末３のＯＳの種類及びバージョンを認識してもよく、テスト対象端末３からＯＳの情報を取得することで認識してもよい。

次に、テスト基盤部３１は、ステップＳ２０１で認識したＯＳの種類及びバージョンに対応するオブジェクトマップＭｐを選択する（ステップＳ２０２）。そして、テスト基盤部３１は、選択したオブジェクトマップＭｐを参照し、自動化ライブラリ実行部３４に渡すコードのオブジェクトの表記を、テスト対象端末３のＯＳの種類及びバージョンに対応した表記に変換する（ステップＳ２０３）。ステップＳ２０２及びステップＳ２０３の処理の詳細については図７及び図８を参照して後述する。これにより、テスト基盤部３１は、ボタン、ラベル、画像などの各オブジェクトの表記を、テスト対象端末３のＯＳの種類及びバージョンに対応した表記に変換することが可能となる。

そして、テスト基盤部３１は、オブジェクトの表記を変換したコードを、自動化ライブラリ実行部３４に供給する（ステップＳ２０４）。この処理の具体例については、図９を参照して後述する。この場合、実行するテストシナリオＴｓに対応する各命令（関数）の引数となるオブジェクトがテスト対象端末３のＯＳの種類及びバージョンに対応した表記に変換されている。よって、自動化ライブラリ実行部３４は、好適にテスト対象端末３が実行可能な形式にテストシナリオＴｓのコードを変換してテスト対象端末３に実行させることができる。

［テストシナリオ実行処理の詳細］
まず、図６のステップＳ２０２でテスト対象端末３のＯＳの種類及びバージョンに応じたオブジェクトマップＭｐを選択することの効果について、図７を参照してさらに補足説明する。

図７（Ａ）は、テスト対象端末３が表示する画面イメージ４０の例を示し、図７（Ｂ）は、Ａｎｄｒｏｉｄ（登録商標）に対応する図７（Ａ）の画面のソースコードを概略的に示し、図７（Ｃ）は、ｉＯＳ（登録商標）に対応する図７（Ａ）の画面のソースコードを概略的に示す。図７（Ａ）に示す画面イメージ４０は、画像４１、４２と、ボタン４３とを含む。図７（Ｂ）、（Ｃ）に示すように、同じ画面を表示する場合であっても、ソースコードの各オブジェクトの表記は全く異なる。このようなＯＳに依存したオブジェクトの表記の違いは、ａｐｐｉｕｍなどの既存の自動化ライブラリでは吸収することができない。

以上を勘案し、テスト基盤部３１は、図６のステップＳ２０２でテスト対象端末３のＯＳの種類及びバージョンに応じてオブジェクトマップＭｐを選択する。そして、ステップＳ２０３では、テスト基盤部３１は、選択したオブジェクトマップＭｐを参照することで、テストシナリオＴｓに記載の各オブジェクトをテスト対象端末３のＯＳの種類及びバージョンに適合した表記に変換する。これにより、テスト基盤部３１は、好適に各テストシナリオＴｓのコードをテスト対象端末３に実行させることができる。

次に、図６のステップＳ２０３で実行する処理の具体例について、図８を参照して説明する。

図８は、ステップＳ２０３の処理内容を示す概要図である。具体的には、図８は、テストケース５０に記載された命令（関数）を実行する際に、オブジェクトの表記を変換する処理の概要を示す。ここでは、ソフトウェア試験装置１は、オブジェクトマップＭｐとして、ＯＳ名「ｉＯＳ」のバージョン６に対応するオブジェクトマップＭｐ１と、ＯＳ名「Ａｎｄｒｏｉｄ（登録商標）」のバージョン４．２に対応するオブジェクトマップＭｐ２とを有するものとする。

テストケース５０には、ＯＳの種類やバージョンに依存しないオブジェクトの名前を使用した関数が記述されている。図８の例では、テストケース５０には、画面イメージ４０のボタン４３のオブジェクト名「ｂｕｔｔｏｎＡ」を含む関数「ｃｏｕｐｏｎ−ｄｅｔａｉｌｓ．ｂｕｔｔｏｎＡ．ｔａｐ（）」が記載されている。そして、上述の関数の実行時には、テスト基盤部３１は、ステップＳ２０２で選択したテスト対象端末３のＯＳの種類及びバージョンに応じたオブジェクトマップＭｐ（Ｍｐ１又はＭｐ２のいずれか）を参照し、テストケース５０を、テスト対象端末３のＯＳの種類及びバージョンに対応した表記に変換する。その後、ステップＳ２０４において、テスト基盤部３１は、変換後の関数のコードを、自動化ライブラリ実行部３４に供給する。

図９は、テスト基盤部３１によるテストケース５０の変換処理、及び、自動化ライブラリ実行部３４による変換処理の概要を示す図である。この例では、テスト基盤部３１は、ステップＳ２０２において、テスト対象端末３のＯＳの種類及びバージョンに応じたオブジェクトマップＭｐとして、図８に示すオブジェクトマップＭｐ１を選択したものとする。

この場合、テスト基盤部３１は、オブジェクトマップＭｐ１を参照し、テストケース５０を、オブジェクトの指定方法がテスト対象端末３の実行環境用に設定されたテストケースに変換する。図９の例では、テスト基盤部３１は、テストケース５０の各関数の表記を、テスト対象端末３のＯＳの種類及びバージョンに対応したオブジェクト位置（パス）の指定情報（単に「位置情報」とも呼ぶ。）と操作内容とを示すコードに変換している。例えば、テスト基盤部３１は、オブジェクトマップＭｐ１を参照し、テストケース５０に記載された関数「ｂｕｔｔｏｎＡ．ｔａｐ（）」のオブジェクト名「ｂｕｔｔｏｎＡ」の部分を、オブジェクトの位置情報「ｐａｔｈ（“‥／ＵＩＡＷｉｎｄｏｗ／ＵＩＡＢｕｔｔｏｎ［０］”）」に変換する。これにより、テスト基盤部３１は、テストケース５０を、ａｐｐｉｕｍなどの自動化ライブラリが提供するインターフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）に従って記述されたテストケースに変換することができる。なお、テストケース５０に記載された関数「ｂｕｔｔｏｎＡ．ｔａｐ（）」の「ｔａｐ（）」は、オブジェクトに対する操作内容を示す。

そして、自動化ライブラリ実行部３４は、テスト基盤部３１により変換されたテストケースを、テスト対象端末３の実行環境で実行可能なプログラムへ変換し、変換後のプログラムをテスト対象端末３に実行させる。この場合、まず、自動化ライブラリ実行部３４は、自動化ライブラリが提供するインターフェースに従って記述されたテストケースを、テスト対象端末３のＯＳの種類及びバージョンに対応したインターフェース（ＡＰＩ）に従って記述されたテストケースに変換する。図９の例では、自動化ライブラリ実行部３４は、位置情報「ｐａｔｈ（“‥／ＵＩＡＷｉｎｄｏｗ／ＵＩＡＢｕｔｔｏｎ［０］”）」を、「ｔａｒｇｅｔ．ｆｒｏｎｔＭｏｓｔＡｐｐ（）．ｍａｉｎＷｉｎｄｏｗ（）．ｂｕｔｔｏｎｓ（）［０］」に変換している。そして、自動化ライブラリ実行部３４は、テスト対象端末３のＯＳの種類及びバージョンに対応したインターフェース（ＡＰＩ）に従って記述されたテストケースを、テスト対象端末３に実行させる。

［ソフトウェア試験装置の作用効果］
本実施形態に係るソフトウェア試験装置１は、設定ファイルＦｏにおいて指定され得る各設定に対して必要なテストシナリオＴｓを記憶し、読み込んだ設定ファイルＦｏにおいて指定された設定に基づき、実行すべきテストシナリオＴｓを判定する。これにより、ソフトウェア試験装置１は、設定ファイルＦｏでの設定内容に応じて実装される機能が異なる各テスト対象アプリＡｐをテストする際に、単一の自動テストプログラムに基づき、必要な試験を実行することができる。即ち、この場合、ソフトウェア試験装置１は、自動テストプログラムを、テスト対象アプリＡｐごとに用意する必要がない。

また、ソフトウェア試験装置１は、テスト対象端末３のＯＳの種類及びバージョンに対応するオブジェクトマップＭｐを選択し、自動化ライブラリ実行部３４に渡すコード内のオブジェクトの表記を、テスト対象端末３のＯＳの種類及びバージョンに対応した表記に変換する。これにより、ソフトウェア試験装置１は、単一の自動テストプログラムにより、種々のＯＳの種類及びバージョンに対応するテスト対象端末３に対してテストシナリオＴｓを実行させることができる。

［変形例］
次に、上述の実施形態の変形例について説明する。以下の変形例は、組み合わせて上述の実施形態に適用してもよい。

（変形例１）
図１のソフトウェア試験装置１の構成例は、一例であり、本発明が適用可能な構成は、これに限定されない。例えば、ソフトウェア試験装置１は、テスト対象端末３とインターフェース１４を介して接続する代わりに、テスト対象端末３と同一の動作環境を模倣したエミュレータを起動し、当該エミュレータによりテストシナリオに基づくテストを実行してもよい。この場合、ソフトウェア試験装置１は、自動化ライブラリ実行部３４が出力する情報を、エミュレータに入力して実行する。

（変形例２）
実施例に基づくソフトウェア試験装置１の処理を、複数の装置が分散して実行してもよい。例えば、テスト基盤部３１の処理を実行する装置と、自動化ライブラリ実行部３４の処理を実行する装置とが通信を行うことで、実施例のソフトウェア試験装置１の処理を実行してもよい。

１…ソフトウェア試験装置
３…テスト対象端末
１０…表示部
１１…入力部
１２…記憶部
１３…制御部
１４…インターフェース

Claims (6)

1. 実装する機能に関する設定を指定した設定ファイルを入力としてビルドされるソフトウェアの試験を行うソフトウェア試験装置であって、
   前記設定ファイルにおいて指定され得る各設定に対して必要な試験項目を記憶する記憶手段と、
   前記試験を行うソフトウェアの設定ファイルを取得するファイル取得手段と、
   前記設定ファイルにおいて指定された設定に基づき、前記記憶手段に記憶された試験項目のうち、実行すべき試験項目を判定する試験項目判定手段と、
   を有することを特徴とするソフトウェア試験装置。
2. 前記記憶手段は、前記試験項目として、一連の動作を規定するテストシナリオと、前記テストシナリオにおける個々の処理を規定するテストケースとを記憶し、
   前記試験項目判定手段は、前記設定ファイルにおいて指定された設定に基づき、実行すべきテストシナリオ及びテストケースを判定することを特徴とする請求項１に記載のソフトウェア試験装置。
3. 前記試験を行うソフトウェアの動作環境を認識する動作環境認識手段と、
   前記判定手段が実行すべきと判定した試験項目のコードを、前記動作環境に応じて変換する変換手段と、
   をさらに有することを特徴とする請求項２に記載のソフトウェア試験装置。
4. 前記記憶手段は、前記試験項目のコードにおいて記述されるオブジェクトを、所定の動作環境において機能する表記に変換するためのマップ情報を、前記ソフトウェアが実行され得る動作環境ごとに記憶し、
   前記変換手段は、前記動作環境認識手段が認識した動作環境に対応する前記マップ情報を参照し、前記試験項目のコード内のオブジェクトの表記を変換することを特徴とする請求項３に記載のソフトウェア試験装置。
5. 前記判定手段が実行すべきと判定した試験項目の処理を実行するための情報を、前記ソフトウェアを実行する端末に入力する、又は、前記端末と同一の動作環境を模倣したエミュレータに入力する試験実行手段をさらに有することを特徴とする請求項１〜４のいずれか一項に記載のソフトウェア試験装置。
6. 実装する機能に関する設定を指定した設定ファイルを入力としてビルドされるソフトウェアの試験を行い、前記設定ファイルにおいて指定され得る各設定に対して必要な試験項目を記憶する記憶手段を参照するコンピュータが実行するプログラムであって、
   前記試験を行うソフトウェアの設定ファイルを取得するファイル取得手段と、
   前記設定ファイルにおいて指定された設定に基づき、前記記憶手段に記憶された試験項目のうち、実行すべき試験項目を判定する試験項目判定手段と、
   として前記コンピュータを機能させることを特徴とするプログラム。

Images