JP2012103874A - ソフトウェアテスト装置 - Google Patents

ソフトウェアテスト装置 Download PDF

Info

Publication number
JP2012103874A
JP2012103874A JP2010251389A JP2010251389A JP2012103874A JP 2012103874 A JP2012103874 A JP 2012103874A JP 2010251389 A JP2010251389 A JP 2010251389A JP 2010251389 A JP2010251389 A JP 2010251389A JP 2012103874 A JP2012103874 A JP 2012103874A
Authority
JP
Japan
Prior art keywords
test
simulator
software
load
operating system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2010251389A
Other languages
English (en)
Inventor
Ken Yamoto
健 箭本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Communication Systems Ltd
Original Assignee
NEC Communication Systems Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Communication Systems Ltd filed Critical NEC Communication Systems Ltd
Priority to JP2010251389A priority Critical patent/JP2012103874A/ja
Publication of JP2012103874A publication Critical patent/JP2012103874A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

【課題】テスト対象ソフトウェアが正常動作しているにもかかわらず、テスト対象ソフトウェアとテストシミュレータとの処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させる。
【解決手段】テストシミュレータ41、テスト対象ソフトウェア44などは、プリエンティブなマルチタスクOS上で動作している。テストシミュレータ41は、テスト制御手段43から入力されたテストシナリオ45に従って、テスト対象ソフトウェア44の動作をテストする。その後、テスト制御手段43は、テストシミュレータ41に入力したテストシナリオ45の内、テスト失敗となったテストシナリオを再度テストシミュレータ41に入力すると共に、負荷変更手段42に対して上記マルチタスクOSにかかる負荷を変更するように指示する。
【選択図】図4

Description

本発明は、プリエンティブなマルチタスク・オペレーティングシステム(以下、マルチタスクOSと記す)を搭載したコンピュータ上で動作するソフトウェアの動作をテストするソフトウェアテスト装置に関する。
通信機器などのテスト対象の動作をテストする際、テストシナリオを利用するということが従来から行われている(例えば、特許文献1参照)。テストシナリオは、どのような擬似信号を、どのような順番でテスト対象に与えるか等のテスト手順を記述したものであり、このテストシナリオに記述されているテスト手順でテスト対象に擬似信号を与え、そのときのテスト対象の挙動に基づいてテスト対象が正常動作しているか否かを判定する。
また、プリエンティブなマルチタスクOS(単に、マルチタスクOSという場合もある)を搭載したコンピュータ上で動作するテストシミュレータに対してテスト手順を記述したテストシナリオを入力し、テスト対象ソフトウェアの動作をテストするということも従来から行われている。
図5を参照すると、上記したテストシミュレータを利用した、ソフトウェアのテスト方法の一例が示されている。この例は、信号Aを受信した際、それに応答して信号Bを送信するといった正しい動作を、テスト対象ソフトウェアが行うか否かをテストする場合についてのものである。尚、テストシナリオ1は、スクリプト言語で記述されたスクリプト形式のソフトウェアであり、テスト対象ソフトウェア3は、機械語で記述された実行形式のソフトウェアである。
テストシミュレータ2は、テストシナリオ1が入力されると、先ず、テストシナリオ1に記述されている信号Aの送信要求に従って、信号Aをテスト対象ソフトウェア3に対して送信する(S501,S502)。
その後、テストシミュレータ2は、テストシナリオ1に記述されている信号Bの受信待ち要求に従って信号Bの受信待ち状態になる(S503,S504)。
一方、テスト対象ソフトウェア3は、その動作が正常であれば、信号Aを受信すると、それに関する処理を行い、信号Bをテストシミュレータ2へ返送する(S505)。テストシミュレータ2は、図5に示すタイミングで信号Bを受信すると、信号Bの受信待ち状態(S504)において期待した信号Bを受信できたので、テストPass(テスト成功)と判定する(S506)。
これに対して、テスト対象ソフトウェア3が正常動作せず、信号Bを返送しなかった場合は、信号Bの受信待ち状態において信号Bを受信できないので、テストFail(テスト失敗)と判定される。
特開2006−352290号公報
図5に示すように、テスト対象ソフトウェア3が返送した信号Bをテストシミュレータ2が受信するためには、信号Bを受信する時刻よりも前に信号Bの受信待ち要求をテストシナリオ1から受信して信号Bの受信待ち状態になっている必要がある。そのためには、テストシナリオ1が信号Aの送信要求を行ってから信号Bの受信待ち要求を行うまでの処理時間t1と、テスト対象ソフトウェア3が信号Aを受信してから信号Bを送信するまでの処理時間t2との時間差Δt=(t2−t1)はある許容範囲内に収まっている必要がある。しかし、テストシナリオ1、テストシミュレータ2及びテスト対象ソフトウェア3を動作させるコンピュータの処理能力によっては、上記時間差Δtが許容範囲外となり、その結果、テスト対象ソフトウェア3が信号Bを返送しているにもかかわらず、テストシミュレータ2で受信されないために、テストFailと判定されてしまう場合がある。
図6を参照すると、上記時間差Δtが許容範囲外となったことが原因で、テストFailと判定されてしまう場合の一例が示されている。
テストシミュレータ2は、先ず、テストシナリオ1に記述されている信号Aの送信要求に従って、信号Aをテスト対象ソフトウェア3に対して送信し(S601,S602)、その後、信号Bの受信待ち要求に従って、信号Bの受信待ち状態になる(S604,S605)。
一方、テスト対象ソフトウェア3は、テストシミュレータ2からの信号Aを受信すると、信号Aの処理を行い、信号Bをテストシミュレータ2へ送信する(S603)。
本来、テストシナリオ1は、信号Bがテストシミュレータ2に届く前に、テストシミュレータ2に対して信号Bの受信待ち要求を行うべきだが、図6の例では、テスト対象ソフトウェア3の処理速度が期待した処理速度よりも速くなってしまい、信号Bがテストシミュレータ2に届いたときには、まだテストシナリオ1がテストシミュレータ2に対して信号Bの受信待ちを行っていない。言い換えれば、この例では、テストシナリオ1が信号Aの送信要求を行ってから信号Bの受信待ち要求を行うまでの処理時間t1と、テスト対象ソフトウェア3が信号Aを受信してから信号Bを送信するまでの処理時間t2との時間差Δt=t2−t1がマイナスとなり、許容範囲外となっている。このため、テストシミュレータ2は、信号Bの受信待ち状態において信号Bを受信できず、テストFailと判定してしまう。
テストシナリオ1の処理時間t1とテスト対象ソフトウェア3の処理時間t2との時間差Δtが許容範囲外となってしまう要因のひとつとして、スクリプト言語で記述されたスクリプト形式のテストシナリオ1がテストシミュレータ2で実行される一方で、テスト対象ソフトウェア3が機械語で記述された実行形式のソフトウェアであることがあげられる。一般的に、スクリプト形式のソフトウェアの処理の方が実行形式のソフトウェアの処理より遅いので、それらの処理時間t1,t2の時間差Δtはコンピュータ毎の処理能力差に大きく依存する。このため、テストを実施するコンピュータの処理能力が異なると、テストシナリオ1が意図した処理速度にてテスト対象ソフトウェア3が動作せず、両者の処理時間t1,t2の時間差Δtが許容範囲外となり、テストFailと判定されてしまう。
そこで、本願発明者は、テスト対象ソフトウェア3が正常動作しているにもかかわらず、テストシミュレータ2とテスト対象ソフトウェア3との処理時間の時間差が許容範囲外となってしまうことにより、テストFailと判定されてしまうという問題点を解決するため、テストFailと判定される度にプリエンティブなマルチタスクOSにかかる負荷を人手で変更し、再度テストを実施するという実験を行った。その結果、マルチタスクOSにかける負荷によっては、テストPassと判定される場合があることを分かった。この方法によれば、テスト対象ソフトウェア3が正常動作しているにもかかわらず、テストシミュレータ2とテスト対象ソフトウェア3との処理時間の時間差が原因でテストFailと判定されてしまう危険性を少なくすることはできるが、テスト担当者が試行錯誤を繰り返し、手作業でマルチタスクOSにかかる負荷を変更しなければならないので、テスト効率が悪いという問題がある。
そこで、本発明の目的は、テスト対象ソフトウェアが正常動作しているにもかかわらず、テストシナリオとテスト対象ソフトウェアとの処理時間の時間差が原因で誤ってテスト失敗と判定されてしまう危険性を小さくするために、マルチタスクOSにかかる負荷を人手で変更するようにすると、テスト効率が悪くなってしまうという課題を解決したソフトウェアテスト装置を提供することにある。
本発明のかかる第1のソフトウェアテスト装置は、
マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作しているテスト対象ソフトウェアに対して実施するテストシミュレータと、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段と、
前記テストシミュレータに入力したテストシナリオの内、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段とを備え、
前記負荷変更手段は、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。
本発明にかかるソフトウェアテスト方法は、
マルチタスク・オペレーティングシステムを搭載すると共に、テスト制御手段と、負荷変更手段と、前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータとを備えたコンピュータが実行するソフトウェアテスト方法であって、
前記テストシミュレータが、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施し、
前記テスト制御手段が、前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示し、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。
本発明にかかるプログラムは、
マルチタスク・オペレーティングシステムを搭載したコンピュータを、ソフトウェアテスト装置として機能させるためのプログラムであって、
前記コンピュータを、
前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施するテストシミュレータ、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段、
前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段として機能させ、且つ、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。
本発明によれば、テスト対象プログラムが正常動作しているにもかかわらず、テストシミュレータとテスト対象ソフトウェアとの処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。
本発明の第1の実施の形態にかかるソフトウェアテスト装置の構成例を示すブロック図である。 テスト結果保管部105の内容例を示す図である。 テスト制御プログラム101の処理例を示すフローチャートである。 本発明の第2の実施の形態にかかるソフトウェアテスト装置の構成例を示すブロック図である。 テストシナリオ1とテスト対象ソフトウェア3との処理時間の時間差が許容範囲内であり、正しいテスト結果が得られた場合の一例を示す図である。 テストシミュレータ2とテスト対象ソフトウェア3との処理時間の時間差が許容範囲外であり、正しいテスト結果が得られなかった場合の一例を示す図である。
次に、本発明の実施の形態について、図面を参照して詳細に説明する。
[本発明の第1の実施の形態]
図1を参照すると、本発明にかかるソフトウェアテスト装置100の第1の実施の形態は、テスト制御手段であるテスト制御プログラム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)が記録されている。図2は、テスト結果保管部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にかかる負荷を変更する。
[第1の実施の形態の動作の説明]
次に、本実施の形態の動作について図3のフローチャートを参照して詳細に説明する。
ソフトウェアテスト装置100内のテスト制御プログラム101は、テスト担当者によってテスト開始が指示されると、先ず、テスト結果保管部105に記録されている各テストシナリオT1〜Tnのテスト結果に基づいて、テストに使用するテストシナリオを選択する(ステップS31)。本実施の形態では、テスト結果がPassとなっていないテストシナリオを選択するようにしており、初期状態(テスト開始前)においては全てのテストシナリオT1〜Tnのテスト結果が「テスト未実施」となっているので、ステップS31では全てのテストシナリオT1〜Tnを選択する。
その後、テスト制御プログラム101は、ステップS31で選択したテストシナリオT1〜Tnをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。その後、テスト制御プログラム101は、テスト完了待ち状態となる(ステップS33)。
一方、テストシミュレータ103は、テスト制御プログラム101から入力されたテストシナリオT1〜Tnに従って、テスト対象ソフトウェア104の動作をテストし、テストシナリオ毎に、そのテスト結果をテスト結果保管部105に記録する。そして、入力された全てのテストシナリオT1〜Tnについて処理が完了すると、テスト制御プログラム101に対してテスト完了を通知する。
テスト制御プログラム101は、テストシミュレータ103からテスト完了が通知されると、テスト結果保管部105を検索し、テスト結果がFailとなっているテストシナリオが存在するか否かを調べる(ステップS34)。そして、テスト結果がFailとなっているテストシナリオが存在しない場合(ステップS34がNO)は、テスト制御プログラム101はその処理を終了する。これに対して、テスト結果がFailとなっているテストシナリオが存在する場合(ステップS34がYES)は、テストの実施回数が、テスト担当者によって予め設定されている所定回数に達しているか否かを判定する(ステップS35)。
そして、テスト実施回数が所定回数に達している場合(ステップS35がYES)は、テスト制御プログラム101は、その処理を終了する。これに対して、テスト実施回数が所定回数に達していない場合(ステップS35がNO)は、テスト制御プログラム101は、プリエンティブなマルチタスクOS200にかかる負荷を変更するための負荷量であって、負荷変更ソフトウェア106を利用して発生させる負荷量を決定する(ステップS36)。より具体的には、メモリ300へのデータの書き込み間隔を決定し、それを負荷変更ソフトウェア106を利用して発生させる負荷量とする。
書き込み間隔の決定方法としては、ランダムに書き込み間隔を決定する方法や、テスト担当者によって指定されているアルゴリズムに従って書き込み間隔を決定する方法などを採用することができる。また、書き込み間隔を決定するためのアルゴリズムとしては、例えば、複数の書き込み間隔を設定しておき、設定されている書き込み間隔を順番に使用するといったアルゴリズムや、書き込み間隔の初期値を設定しておき、テストを実施する度に書き込み間隔を所定値ずつ小さく或いは大きくしていくといったアルゴリズムや、書き込み間隔の初期値を設定しておき、テストを実施する度に書き込み間隔を所定の割合ずつ小さく或いは大きくしていくといったアルゴリズムを使用することができる。
そして、メモリ300への書き込み時間間隔を決定すると、テスト制御プログラム101は、負荷変更ソフトウェア106に対して書き込み間隔を通知する(ステップS37)。
これにより、負荷変更ソフトウェア106は、通知された書き込み間隔で、予め定められているダミーのデータをメモリ300に書き込む。これにより、プリエンティブなマルチタスクOS200にかかる負荷が変化し、それに伴ってテストシミュレータ103及びテスト対象ソフトウェア104の処理時間が変化すると共に、処理時間の時間差も変化する。このため、テスト対象ソフトウェア104が正常動作していれば、次回のテスト時に、テストシミュレータ103とテスト対象ソフトウェア104との処理時間の時間差が許容範囲内となり、テストPassと判定される可能性が出てくる。
その後、テスト制御プログラム101は、ステップS31の処理に戻り、テスト結果保管部105に記録されている各テストシナリオT1〜Tnのテスト結果に基づいて、テストに使用するテストシナリオを選択する。以後、テスト制御プログラム101は、テスト結果がFailのテストシナリオがなくなるか(ステップS34がNOとなるか)、或いはテスト実施回数が予め定められている所定回数に達するまで(ステップS35がYESとなるまで)、前述した処理を繰り返し行う。
なお、上述した実施の形態では、メモリ300に対するデータの書き込み間隔を変更することにより、プリエンティブなマルチタスクOS200にかかる負荷を変更するようにしたが、ディスク装置などの外部記憶装置に対するデータの書き込み間隔を変更するようにしても良い。ディスク装置などの外部記憶装置に対するデータの書き込み間隔を変更するようにすることにより、メモリ300に対するデータの書き込み間隔を変更する場合に比較して、プリエンティブなマルチタスクOSにかかる負荷を大きく変化させることが可能になる。
[第1の実施の形態の効果]
本実施の形態によれば、テスト対象プログラム104が正常動作しているにもかかわらず、テストシナリオT1〜Tnの処理時間とテスト対象ソフトウェア104の処理時間との時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。その理由は、テストシミュレータ103に入力したテストシナリオの内、テスト結果がFailとなったテストシナリオをテストシミュレータ103に再度入力すると共に、負荷変更ソフトウェア106に対してプリエンティブなマルチタスクOS200にかかる負荷を変更することを指示するテスト制御プログラム101を備えているからである。
[本発明の第2の実施の形態]
次に、本発明にかかるソフトウェアテスト装置の第2の実施の形態について説明する。
図4を参照すると、本実施の形態にかかるソフトウェアテスト装置は、テストシミュレータ41と、負荷変更手段42と、テスト制御手段43とを備えている。
テストシミュレータ41は、プリエンティブなマルチタスクOS(図示せず)上で動作するものであり、テスト制御手段43から入力されたスクリプト形式のテストシナリオ45に記述されている命令に従ったテストを、上記マルチタスクOS上で動作している実行形式のテスト対象ソフトウェア44に対して実施する。
テスト制御手段43は、テストシミュレータ41にテストシナリオ45を入力し、テスト対象ソフトウェア44の動作をテストさせる。そして、テストシミュレータ41に入力したテストシナリオの内、テスト結果が失敗(Fail)となったテストシナリオをテストシミュレータ41に再度入力すると共に、負荷変更手段42に対してマルチタスクOSにかかる負荷を変更することを指示する。この指示に応答して、負荷変更手段42は、マルチタスクOSにかかる負荷を変更する。
尚、上記したソフトウェアテスト装置は、コンピュータによって実現可能であり、コンピュータによって実現する場合は、例えば、次のようにする。コンピュータをソフトウェアテスト装置として機能させるためのプログラムを記録した半導体メモリ、ディスク、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、テストシミュレータ41、負荷変更手段42、及び、テスト制御手段43を実現する。
[第2の実施の形態の効果]
本実施の形態によれば、テスト対象プログラム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…テストシナリオ

Claims (7)

  1. マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作しているテスト対象ソフトウェアに対して実施するテストシミュレータと、
    前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段と、
    前記テストシミュレータに入力したテストシナリオの内、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段とを備え、
    前記負荷変更手段は、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするソフトウェアテスト装置。
  2. 請求項1記載のソフトウェアテスト装置において、
    前記テストシナリオは、スクリプト言語で記述され、
    前記テスト対象ソフトウェアは、機械語で記述されることを特徴とするソフトウェアテスト装置。
  3. 請求項1または2記載のソフトウェアテスト装置において、
    前記テスト制御手段は、前記負荷変更手段に対して負荷の変更を指示する際、記憶装置へのデータの書き込み間隔を指示し、
    前記負荷変更手段は、前記テスト制御手段から指示された書き込み間隔でデータを記憶装置に書き込むことを特徴とするソフトウェアテスト装置。
  4. 請求項3記載のソフトウェアテスト装置において、
    前記記憶装置は、メインメモリまたは外部記憶装置であることを特徴とするソフトウェアテスト装置。
  5. 請求項1乃至4の何れか1項に記載のソフトウェアテスト装置において、
    前記テスト制御手段は、予め定められている複数のテスト項目それぞれについて、そのテスト項目に関連するテストシナリオを前記テストシミュレータに入力し、前記テストシミュレータにおいて入力された全てのテストシナリオに従ったテストが完了する毎に、テスト結果が失敗となったテスト項目に対応するテストシナリオを前記テストシミュレータに入力する処理と前記負荷変更手段に対して負荷の変更を指示する処理とを、テスト回数が予め定められている回数となるか、またはテスト結果が失敗となってテスト項目がなくなるまで、繰り返し行うことを特徴とするソフトウェアテスト装置。
  6. マルチタスク・オペレーティングシステムを搭載すると共に、テスト制御手段と、負荷変更手段と、前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータとを備えたコンピュータが実行するソフトウェアテスト方法であって、
    前記テストシミュレータが、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施し、
    前記テスト制御手段が、前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示し、
    前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするソフトウェアテスト方法。
  7. マルチタスク・オペレーティングシステムを搭載したコンピュータを、ソフトウェアテスト装置として機能させるためのプログラムであって、
    前記コンピュータを、
    前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施するテストシミュレータ、
    前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段、
    前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段として機能させ、且つ、
    前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするプログラム。
JP2010251389A 2010-11-10 2010-11-10 ソフトウェアテスト装置 Pending JP2012103874A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010251389A JP2012103874A (ja) 2010-11-10 2010-11-10 ソフトウェアテスト装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010251389A JP2012103874A (ja) 2010-11-10 2010-11-10 ソフトウェアテスト装置

Publications (1)

Publication Number Publication Date
JP2012103874A true JP2012103874A (ja) 2012-05-31

Family

ID=46394197

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010251389A Pending JP2012103874A (ja) 2010-11-10 2010-11-10 ソフトウェアテスト装置

Country Status (1)

Country Link
JP (1) JP2012103874A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023024762A (ja) * 2019-06-14 2023-02-16 Jfeエンジニアリング株式会社 制御用ソフトウェアの自動テスト方法及び装置ならびにコンピュータプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023024762A (ja) * 2019-06-14 2023-02-16 Jfeエンジニアリング株式会社 制御用ソフトウェアの自動テスト方法及び装置ならびにコンピュータプログラム
JP7392821B2 (ja) 2019-06-14 2023-12-06 Jfeエンジニアリング株式会社 制御用ソフトウェアの自動テスト方法及び装置ならびにコンピュータプログラム

Similar Documents

Publication Publication Date Title
US20110145643A1 (en) Reproducible test framework for randomized stress test
JP5104958B2 (ja) 仮想計算機システムのテスト方法、テストプログラム並びにその記録媒体、仮想計算機システム
US11113183B2 (en) Automated device test triaging system and techniques
JP2014532914A (ja) プログラム可能な試験機器
US8645766B2 (en) Serialized error injection into a function under test
CN102831058B (zh) 一种测试方法和装置
CN110532182A (zh) 一种虚拟化平台的自动化测试方法及装置
US20100312541A1 (en) Program test device and program
US8874966B1 (en) Storage device error simulator tool
KR20200067474A (ko) Autosar 기반 차량 소프트웨어의 결함 테스트 방법 및 결함 테스트 시스템
US9218273B2 (en) Automatic generation of a resource reconfiguring test
US20120124425A1 (en) Method and Apparatus Useful In Manufacturing Test Case Operations
JPWO2008099657A1 (ja) 半導体集積回路、デバッグ・トレース回路、および半導体集積回路動作観測方法
JP6771413B2 (ja) ソフトウェア検証装置およびソフトウェア検証プログラム
JP2012103874A (ja) ソフトウェアテスト装置
US8639978B2 (en) Topology independent network-based automation infrastructure
JP2009104490A (ja) プログラムのテスト装置
CN114756293A (zh) 业务处理方法、装置、计算机设备和存储介质
JP5550578B2 (ja) エントリ書換装置及びエントリ書換プログラム
US8359456B2 (en) Generating random addresses for verification of distributed computerized devices
US20120123761A1 (en) Testing Software On A Computer System
JP2010102446A (ja) ソフトウェア自動試験装置
WO2012172682A1 (ja) 演算処理装置及び演算処理装置の制御方法
US11719749B1 (en) Method and system for saving and restoring of initialization actions on dut and corresponding test environment
JP6680980B2 (ja) テスト実行プログラム、テスト実行装置及びテスト実行方法

Legal Events

Date Code Title Description
RD07 Notification of extinguishment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7427

Effective date: 20120718