(57)【要約】【課題】テスト対象ソフトウェアが正常動作しているにもかかわらず、テスト対象ソフトウェアとテストシミュレータとの処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させる。【解決手段】テストシミュレータ41、テスト対象ソフトウェア44などは、プリエンティブなマルチタスクOS上で動作している。テストシミュレータ41は、テスト制御手段43から入力されたテストシナリオ45に従って、テスト対象ソフトウェア44の動作をテストする。その後、テスト制御手段43は、テストシミュレータ41に入力したテストシナリオ45の内、テスト失敗となったテストシナリオを再度テストシミュレータ41に入力すると共に、負荷変更手段42に対して上記マルチタスクOSにかかる負荷を変更するように指示する。【選択図】図４
2012103874.tif 000002
【特許請求の範囲】
【請求項１】
マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作しているテスト対象ソフトウェアに対して実施するテストシミュレータと、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段と、
前記テストシミュレータに入力したテストシナリオの内、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段とを備え、
前記負荷変更手段は、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするソフトウェアテスト装置。
【請求項２】
請求項１記載のソフトウェアテスト装置において、
前記テストシナリオは、スクリプト言語で記述され、
前記テスト対象ソフトウェアは、機械語で記述されることを特徴とするソフトウェアテスト装置。
【請求項３】
請求項１または２記載のソフトウェアテスト装置において、
前記テスト制御手段は、前記負荷変更手段に対して負荷の変更を指示する際、記憶装置へのデータの書き込み間隔を指示し、
前記負荷変更手段は、前記テスト制御手段から指示された書き込み間隔でデータを記憶装置に書き込むことを特徴とするソフトウェアテスト装置。
【請求項４】
請求項３記載のソフトウェアテスト装置において、
前記記憶装置は、メインメモリまたは外部記憶装置であることを特徴とするソフトウェアテスト装置。
【請求項５】
請求項１乃至４の何れか１項に記載のソフトウェアテスト装置において、
前記テスト制御手段は、予め定められている複数のテスト項目それぞれについて、そのテスト項目に関連するテストシナリオを前記テストシミュレータに入力し、前記テストシミュレータにおいて入力された全てのテストシナリオに従ったテストが完了する毎に、テスト結果が失敗となったテスト項目に対応するテストシナリオを前記テストシミュレータに入力する処理と前記負荷変更手段に対して負荷の変更を指示する処理とを、テスト回数が予め定められている回数となるか、またはテスト結果が失敗となってテスト項目がなくなるまで、繰り返し行うことを特徴とするソフトウェアテスト装置。
【請求項６】
マルチタスク・オペレーティングシステムを搭載すると共に、テスト制御手段と、負荷変更手段と、前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータとを備えたコンピュータが実行するソフトウェアテスト方法であって、
前記テストシミュレータが、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施し、
前記テスト制御手段が、前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示し、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするソフトウェアテスト方法。
【請求項７】
マルチタスク・オペレーティングシステムを搭載したコンピュータを、ソフトウェアテスト装置として機能させるためのプログラムであって、
前記コンピュータを、
前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施するテストシミュレータ、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段、
前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段として機能させ、且つ、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プリエンティブなマルチタスク・オペレーティングシステム（以下、マルチタスクOSと記す）を搭載したコンピュータ上で動作するソフトウェアの動作をテストするソフトウェアテスト装置に関する。
【背景技術】
【０００２】
通信機器などのテスト対象の動作をテストする際、テストシナリオを利用するということが従来から行われている（例えば、特許文献１参照）。テストシナリオは、どのような擬似信号を、どのような順番でテスト対象に与えるか等のテスト手順を記述したものであり、このテストシナリオに記述されているテスト手順でテスト対象に擬似信号を与え、そのときのテスト対象の挙動に基づいてテスト対象が正常動作しているか否かを判定する。
【０００３】
また、プリエンティブなマルチタスクOS（単に、マルチタスクOSという場合もある）を搭載したコンピュータ上で動作するテストシミュレータに対してテスト手順を記述したテストシナリオを入力し、テスト対象ソフトウェアの動作をテストするということも従来から行われている。
【０００４】
図５を参照すると、上記したテストシミュレータを利用した、ソフトウェアのテスト方法の一例が示されている。この例は、信号Ａを受信した際、それに応答して信号Ｂを送信するといった正しい動作を、テスト対象ソフトウェアが行うか否かをテストする場合についてのものである。尚、テストシナリオ１は、スクリプト言語で記述されたスクリプト形式のソフトウェアであり、テスト対象ソフトウェア３は、機械語で記述された実行形式のソフトウェアである。
【０００５】
テストシミュレータ２は、テストシナリオ１が入力されると、先ず、テストシナリオ１に記述されている信号Ａの送信要求に従って、信号Ａをテスト対象ソフトウェア３に対して送信する（S501,S502）。
【０００６】
その後、テストシミュレータ２は、テストシナリオ１に記述されている信号Ｂの受信待ち要求に従って信号Ｂの受信待ち状態になる（S503,S504）。
【０００７】
一方、テスト対象ソフトウェア３は、その動作が正常であれば、信号Ａを受信すると、それに関する処理を行い、信号Ｂをテストシミュレータ２へ返送する（S505）。テストシミュレータ２は、図５に示すタイミングで信号Ｂを受信すると、信号Ｂの受信待ち状態（S504）において期待した信号Ｂを受信できたので、テストPass（テスト成功）と判定する（S506）。
【０００８】
これに対して、テスト対象ソフトウェア３が正常動作せず、信号Ｂを返送しなかった場合は、信号Ｂの受信待ち状態において信号Ｂを受信できないので、テストFail（テスト失敗）と判定される。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００６−３５２２９０号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
図５に示すように、テスト対象ソフトウェア３が返送した信号Ｂをテストシミュレータ２が受信するためには、信号Ｂを受信する時刻よりも前に信号Ｂの受信待ち要求をテストシナリオ１から受信して信号Ｂの受信待ち状態になっている必要がある。そのためには、テストシナリオ１が信号Ａの送信要求を行ってから信号Ｂの受信待ち要求を行うまでの処理時間t1と、テスト対象ソフトウェア３が信号Ａを受信してから信号Ｂを送信するまでの処理時間t2との時間差Δt＝（t2−t1）はある許容範囲内に収まっている必要がある。しかし、テストシナリオ１、テストシミュレータ２及びテスト対象ソフトウェア３を動作させるコンピュータの処理能力によっては、上記時間差Δtが許容範囲外となり、その結果、テスト対象ソフトウェア３が信号Ｂを返送しているにもかかわらず、テストシミュレータ２で受信されないために、テストFailと判定されてしまう場合がある。
【００１１】
図６を参照すると、上記時間差Δtが許容範囲外となったことが原因で、テストFailと判定されてしまう場合の一例が示されている。
【００１２】
テストシミュレータ２は、先ず、テストシナリオ１に記述されている信号Ａの送信要求に従って、信号Ａをテスト対象ソフトウェア３に対して送信し（S601,S602）、その後、信号Ｂの受信待ち要求に従って、信号Ｂの受信待ち状態になる（S604,S605）。
【００１３】
一方、テスト対象ソフトウェア３は、テストシミュレータ２からの信号Ａを受信すると、信号Ａの処理を行い、信号Ｂをテストシミュレータ２へ送信する（S603）。
【００１４】
本来、テストシナリオ１は、信号Ｂがテストシミュレータ２に届く前に、テストシミュレータ２に対して信号Ｂの受信待ち要求を行うべきだが、図６の例では、テスト対象ソフトウェア３の処理速度が期待した処理速度よりも速くなってしまい、信号Ｂがテストシミュレータ２に届いたときには、まだテストシナリオ１がテストシミュレータ２に対して信号Ｂの受信待ちを行っていない。言い換えれば、この例では、テストシナリオ１が信号Ａの送信要求を行ってから信号Ｂの受信待ち要求を行うまでの処理時間t1と、テスト対象ソフトウェア３が信号Ａを受信してから信号Ｂを送信するまでの処理時間t2との時間差Δt＝t2−t1がマイナスとなり、許容範囲外となっている。このため、テストシミュレータ２は、信号Ｂの受信待ち状態において信号Ｂを受信できず、テストFailと判定してしまう。
【００１５】
テストシナリオ１の処理時間t1とテスト対象ソフトウェア３の処理時間t2との時間差Δtが許容範囲外となってしまう要因のひとつとして、スクリプト言語で記述されたスクリプト形式のテストシナリオ１がテストシミュレータ２で実行される一方で、テスト対象ソフトウェア３が機械語で記述された実行形式のソフトウェアであることがあげられる。一般的に、スクリプト形式のソフトウェアの処理の方が実行形式のソフトウェアの処理より遅いので、それらの処理時間t1,t2の時間差Δtはコンピュータ毎の処理能力差に大きく依存する。このため、テストを実施するコンピュータの処理能力が異なると、テストシナリオ１が意図した処理速度にてテスト対象ソフトウェア３が動作せず、両者の処理時間t1,t2の時間差Δtが許容範囲外となり、テストFailと判定されてしまう。
【００１６】
そこで、本願発明者は、テスト対象ソフトウェア３が正常動作しているにもかかわらず、テストシミュレータ２とテスト対象ソフトウェア３との処理時間の時間差が許容範囲外となってしまうことにより、テストFailと判定されてしまうという問題点を解決するため、テストFailと判定される度にプリエンティブなマルチタスクOSにかかる負荷を人手で変更し、再度テストを実施するという実験を行った。その結果、マルチタスクOSにかける負荷によっては、テストPassと判定される場合があることを分かった。この方法によれば、テスト対象ソフトウェア３が正常動作しているにもかかわらず、テストシミュレータ２とテスト対象ソフトウェア３との処理時間の時間差が原因でテストFailと判定されてしまう危険性を少なくすることはできるが、テスト担当者が試行錯誤を繰り返し、手作業でマルチタスクOSにかかる負荷を変更しなければならないので、テスト効率が悪いという問題がある。
【００１７】
そこで、本発明の目的は、テスト対象ソフトウェアが正常動作しているにもかかわらず、テストシナリオとテスト対象ソフトウェアとの処理時間の時間差が原因で誤ってテスト失敗と判定されてしまう危険性を小さくするために、マルチタスクOSにかかる負荷を人手で変更するようにすると、テスト効率が悪くなってしまうという課題を解決したソフトウェアテスト装置を提供することにある。
【課題を解決するための手段】
【００１８】
本発明のかかる第１のソフトウェアテスト装置は、
マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作しているテスト対象ソフトウェアに対して実施するテストシミュレータと、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段と、
前記テストシミュレータに入力したテストシナリオの内、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段とを備え、
前記負荷変更手段は、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。
【００１９】
本発明にかかるソフトウェアテスト方法は、
マルチタスク・オペレーティングシステムを搭載すると共に、テスト制御手段と、負荷変更手段と、前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータとを備えたコンピュータが実行するソフトウェアテスト方法であって、
前記テストシミュレータが、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施し、
前記テスト制御手段が、前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示し、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。
【００２０】
本発明にかかるプログラムは、
マルチタスク・オペレーティングシステムを搭載したコンピュータを、ソフトウェアテスト装置として機能させるためのプログラムであって、
前記コンピュータを、
前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施するテストシミュレータ、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段、
前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段として機能させ、且つ、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。
【発明の効果】
【００２１】
本発明によれば、テスト対象プログラムが正常動作しているにもかかわらず、テストシミュレータとテスト対象ソフトウェアとの処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の第１の実施の形態にかかるソフトウェアテスト装置の構成例を示すブロック図である。
【図２】テスト結果保管部105の内容例を示す図である。
【図３】テスト制御プログラム101の処理例を示すフローチャートである。
【図４】本発明の第２の実施の形態にかかるソフトウェアテスト装置の構成例を示すブロック図である。
【図５】テストシナリオ１とテスト対象ソフトウェア３との処理時間の時間差が許容範囲内であり、正しいテスト結果が得られた場合の一例を示す図である。
【図６】テストシミュレータ２とテスト対象ソフトウェア３との処理時間の時間差が許容範囲外であり、正しいテスト結果が得られなかった場合の一例を示す図である。
【発明を実施するための形態】
【００２３】
次に、本発明の実施の形態について、図面を参照して詳細に説明する。
【００２４】
[本発明の第１の実施の形態]
図１を参照すると、本発明にかかるソフトウェアテスト装置100の第１の実施の形態は、テスト制御手段であるテスト制御プログラム101と、テストシナリオ記憶部102と、テストシミュレータ103と、テスト対象ソフトウェア104と、テスト結果保管部105と、負荷変更手段である負荷変更ソフトウェア106とを備えている。尚、テスト制御プログラム101、テストシミュレータ103、テスト対象ソフトウェア104、及び、負荷変更ソフトウェア106は、プリエンティブなマルチタスクOS200を搭載したコンピュータ上で動作する。
【００２５】
テストシナリオ記憶部102には、複数のテストシナリオT1〜Tnが記録されている。各テストシナリオT1〜Tnは、スクリプト言語で記述されており、各テストシナリオT1〜Tnは、それぞれ異なるテスト項目に対応している。
【００２６】
テスト対象ソフトウェア104は、テスト（例えば、回帰テストなど）の実施対象となるソフトウェアであり、機械語で記述されている。尚、テスト対象ソフトウェア104は任意のもので良く、例えば、組み込みソフトウェアをテストする場合には、リアルタイムOSをエミュレートしたOSおよび組み込みソフトウェアを組み込んだテスト対象ソフトウェア104を使用することができる。
【００２７】
テストシミュレータ103は、テスト制御プログラム101から入力されたテストシナリオに記述されている命令に従ってテスト対象ソフトウェア104の動作をテストし、テスト結果をテスト結果保管部105に記録する。
【００２８】
テスト結果保管部105には、テストシナリオを一意に識別する識別子に関連付けて、そのテストシナリオについてのテスト結果（Pass或いはFail）が記録されている。図２は、テスト結果保管部105の内容例を示す図であり、同図の例は、テストシナリオT1,T2によるテストは成功したが、テストシナリオT3によるテストは失敗したことなどを示している。尚、初期状態においては、テストシナリオT1〜Tnの識別子に関連付けて、テスト未実施を示す情報が記録されている。
【００２９】
テスト制御プログラム101は、テスト結果保管部105に記録されているテスト結果に基づいて、テストシナリオT1〜Tnの中からテストに使用するテストシナリオを選択し、選択したテストシナリオをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。より具体的には、テスト制御プログラム101は、テスト結果保管部105に記録されているテスト結果がPassとなっていないテストシナリオ（テスト結果がFailまたはテスト未実施となっているテストシナリオ）を選択し、選択したテストシナリオをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。
【００３０】
また、テスト制御プログラム101は、テストシミュレータ103によるテストが完了すると、テスト結果がFailとなっているテストシナリオが存在するか否かを調べ、そのようなテストシナリオが存在する場合には、更に、テストの実施回数が予め定められている回数になったか否かを判定する。そして、テストの実施回数が予め定められている回数に達していない場合は、負荷変更ソフトウェア106の負荷量を決定して負荷変更ソフトウェア106に通知すると共に、テスト結果がPassとなっていないテストシナリオをテストシミュレータ103に入力して、再度テストを実施させる。ここで、負荷量としては、例えば、メモリ（メインメモリ）300へのデータの書き込み間隔を使用することができる。また、負荷量の決定方法としては、ランダムに負荷量を決定する方法や、予め定められているアルゴリズムに従って負荷量を決定する方法を採用することができる。
【００３１】
負荷変更ソフトウェア106は、テスト制御プログラム101から通知された書き込み間隔で、ダミーのデータをメモリ300に書き込むことにより、マルチタスクOS200にかかる負荷を変更する。
【００３２】
[第１の実施の形態の動作の説明]
次に、本実施の形態の動作について図３のフローチャートを参照して詳細に説明する。
【００３３】
ソフトウェアテスト装置100内のテスト制御プログラム101は、テスト担当者によってテスト開始が指示されると、先ず、テスト結果保管部105に記録されている各テストシナリオT1〜Tnのテスト結果に基づいて、テストに使用するテストシナリオを選択する（ステップＳ31）。本実施の形態では、テスト結果がPassとなっていないテストシナリオを選択するようにしており、初期状態（テスト開始前）においては全てのテストシナリオT1〜Tnのテスト結果が「テスト未実施」となっているので、ステップＳ31では全てのテストシナリオT1〜Tnを選択する。
【００３４】
その後、テスト制御プログラム101は、ステップＳ31で選択したテストシナリオT1〜Tnをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。その後、テスト制御プログラム101は、テスト完了待ち状態となる（ステップＳ33）。
【００３５】
一方、テストシミュレータ103は、テスト制御プログラム101から入力されたテストシナリオT1〜Tnに従って、テスト対象ソフトウェア104の動作をテストし、テストシナリオ毎に、そのテスト結果をテスト結果保管部105に記録する。そして、入力された全てのテストシナリオT1〜Tnについて処理が完了すると、テスト制御プログラム101に対してテスト完了を通知する。
【００３６】
テスト制御プログラム101は、テストシミュレータ103からテスト完了が通知されると、テスト結果保管部105を検索し、テスト結果がFailとなっているテストシナリオが存在するか否かを調べる（ステップＳ34）。そして、テスト結果がFailとなっているテストシナリオが存在しない場合（ステップＳ34がNO）は、テスト制御プログラム101はその処理を終了する。これに対して、テスト結果がFailとなっているテストシナリオが存在する場合（ステップＳ34がYES）は、テストの実施回数が、テスト担当者によって予め設定されている所定回数に達しているか否かを判定する（ステップＳ35）。
【００３７】
そして、テスト実施回数が所定回数に達している場合（ステップＳ35がYES）は、テスト制御プログラム101は、その処理を終了する。これに対して、テスト実施回数が所定回数に達していない場合（ステップＳ35がNO）は、テスト制御プログラム101は、プリエンティブなマルチタスクOS200にかかる負荷を変更するための負荷量であって、負荷変更ソフトウェア106を利用して発生させる負荷量を決定する（ステップＳ36）。より具体的には、メモリ300へのデータの書き込み間隔を決定し、それを負荷変更ソフトウェア106を利用して発生させる負荷量とする。
【００３８】
書き込み間隔の決定方法としては、ランダムに書き込み間隔を決定する方法や、テスト担当者によって指定されているアルゴリズムに従って書き込み間隔を決定する方法などを採用することができる。また、書き込み間隔を決定するためのアルゴリズムとしては、例えば、複数の書き込み間隔を設定しておき、設定されている書き込み間隔を順番に使用するといったアルゴリズムや、書き込み間隔の初期値を設定しておき、テストを実施する度に書き込み間隔を所定値ずつ小さく或いは大きくしていくといったアルゴリズムや、書き込み間隔の初期値を設定しておき、テストを実施する度に書き込み間隔を所定の割合ずつ小さく或いは大きくしていくといったアルゴリズムを使用することができる。
【００３９】
そして、メモリ300への書き込み時間間隔を決定すると、テスト制御プログラム101は、負荷変更ソフトウェア106に対して書き込み間隔を通知する（ステップＳ37）。
【００４０】
これにより、負荷変更ソフトウェア106は、通知された書き込み間隔で、予め定められているダミーのデータをメモリ300に書き込む。これにより、プリエンティブなマルチタスクOS200にかかる負荷が変化し、それに伴ってテストシミュレータ103及びテスト対象ソフトウェア104の処理時間が変化すると共に、処理時間の時間差も変化する。このため、テスト対象ソフトウェア104が正常動作していれば、次回のテスト時に、テストシミュレータ103とテスト対象ソフトウェア104との処理時間の時間差が許容範囲内となり、テストPassと判定される可能性が出てくる。
【００４１】
その後、テスト制御プログラム101は、ステップＳ31の処理に戻り、テスト結果保管部105に記録されている各テストシナリオT1〜Tnのテスト結果に基づいて、テストに使用するテストシナリオを選択する。以後、テスト制御プログラム101は、テスト結果がFailのテストシナリオがなくなるか（ステップＳ34がNOとなるか）、或いはテスト実施回数が予め定められている所定回数に達するまで（ステップＳ35がYESとなるまで）、前述した処理を繰り返し行う。
【００４２】
なお、上述した実施の形態では、メモリ300に対するデータの書き込み間隔を変更することにより、プリエンティブなマルチタスクOS200にかかる負荷を変更するようにしたが、ディスク装置などの外部記憶装置に対するデータの書き込み間隔を変更するようにしても良い。ディスク装置などの外部記憶装置に対するデータの書き込み間隔を変更するようにすることにより、メモリ300に対するデータの書き込み間隔を変更する場合に比較して、プリエンティブなマルチタスクOSにかかる負荷を大きく変化させることが可能になる。
【００４３】
［第１の実施の形態の効果］
本実施の形態によれば、テスト対象プログラム104が正常動作しているにもかかわらず、テストシナリオT1〜Tnの処理時間とテスト対象ソフトウェア104の処理時間との時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。その理由は、テストシミュレータ103に入力したテストシナリオの内、テスト結果がFailとなったテストシナリオをテストシミュレータ103に再度入力すると共に、負荷変更ソフトウェア106に対してプリエンティブなマルチタスクOS200にかかる負荷を変更することを指示するテスト制御プログラム101を備えているからである。
【００４４】
［本発明の第２の実施の形態］
次に、本発明にかかるソフトウェアテスト装置の第２の実施の形態について説明する。
【００４５】
図４を参照すると、本実施の形態にかかるソフトウェアテスト装置は、テストシミュレータ41と、負荷変更手段42と、テスト制御手段43とを備えている。
【００４６】
テストシミュレータ41は、プリエンティブなマルチタスクOS（図示せず）上で動作するものであり、テスト制御手段43から入力されたスクリプト形式のテストシナリオ45に記述されている命令に従ったテストを、上記マルチタスクOS上で動作している実行形式のテスト対象ソフトウェア44に対して実施する。
【００４７】
テスト制御手段43は、テストシミュレータ41にテストシナリオ45を入力し、テスト対象ソフトウェア44の動作をテストさせる。そして、テストシミュレータ41に入力したテストシナリオの内、テスト結果が失敗（Fail）となったテストシナリオをテストシミュレータ41に再度入力すると共に、負荷変更手段42に対してマルチタスクOSにかかる負荷を変更することを指示する。この指示に応答して、負荷変更手段42は、マルチタスクOSにかかる負荷を変更する。
【００４８】
尚、上記したソフトウェアテスト装置は、コンピュータによって実現可能であり、コンピュータによって実現する場合は、例えば、次のようにする。コンピュータをソフトウェアテスト装置として機能させるためのプログラムを記録した半導体メモリ、ディスク、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、テストシミュレータ41、負荷変更手段42、及び、テスト制御手段43を実現する。
【００４９】
［第２の実施の形態の効果］
本実施の形態によれば、テスト対象プログラム45が正常動作しているにもかかわらず、テストシナリオT1〜Tnとテスト対象ソフトウェア45との処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。その理由は、テストシミュレータ41に入力したテストシナリオの内、テスト結果が失敗となったテストシナリオをテストシミュレータ41に再入力すると共に、負荷変更手段42に対してマルチタスクOSにかかる負荷の変更を指示するテスト制御手段43を備えているからである。
【産業上の利用可能性】
【００５０】
本発明は、ソフトウェアの動作テスト、ソフトウェアの動作速度調整などに利用することができる。
【符号の説明】
【００５１】
100…ソフトウェアテスト装置
101…テスト制御プログラム
102…テストシナリオ記憶部
T1〜Tn…テストシナリオ
103…テストシミュレータ
104…テスト対象ソフトウェア
105…テスト結果保管部
106…負荷変更ソフトウェア
200…プリエンティブなマルチタスクOS
300…メモリ
41…テストシミュレータ
42…負荷変更手段
43…テスト制御手段
44…テスト対象ソフトウェア
45…テストシナリオ
【図１】
2012103874.tif 000003
【図２】
2012103874.tif 000004
【図３】
2012103874.tif 000005
【図４】
2012103874.tif 000006
【図５】
2012103874.tif 000007
【図６】
2012103874.tif 000008