JP2012103874A - Software test device - Google Patents

Software test device 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
Japanese (ja)
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/en
Publication of JP2012103874A publication Critical patent/JP2012103874A/en
Pending legal-status Critical Current

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

PROBLEM TO BE SOLVED: To improve test efficiency while reducing a risk that, though test object software is normally operated, it is determined as a test failure due to a time difference of processing time between the test object software and a test simulator.SOLUTION: A test simulator 41, a test object software 44 and the like are operated on a preemptive multitask OS. The test simulator 41 tests the operation of the test object software 44 according to a test scenario 45 input from test control means 43. Then, the test control means 43 input again the test scenario that has failed in the test out of the test scenarios 45 input in the test simulator 41 and commands to load change means 42 to change a load applied to the multitask OS.

Description

本発明は、プリエンティブなマルチタスク・オペレーティングシステム（以下、マルチタスクOSと記す）を搭載したコンピュータ上で動作するソフトウェアの動作をテストするソフトウェアテスト装置に関する。   The present invention relates to a software test apparatus that tests the operation of software running on a computer equipped with a preemptive multitasking operating system (hereinafter referred to as a multitasking OS).

通信機器などのテスト対象の動作をテストする際、テストシナリオを利用するということが従来から行われている（例えば、特許文献１参照）。テストシナリオは、どのような擬似信号を、どのような順番でテスト対象に与えるか等のテスト手順を記述したものであり、このテストシナリオに記述されているテスト手順でテスト対象に擬似信号を与え、そのときのテスト対象の挙動に基づいてテスト対象が正常動作しているか否かを判定する。   Conventionally, when testing the operation of a test target such as a communication device, a test scenario is used (see, for example, Patent Document 1). The test scenario describes the test procedure such as what kind of pseudo signal is given to the test object and in what order, and the test procedure described in this test scenario gives the pseudo signal to the test object. Based on the behavior of the test object at that time, it is determined whether or not the test object is operating normally.

また、プリエンティブなマルチタスクOS（単に、マルチタスクOSという場合もある）を搭載したコンピュータ上で動作するテストシミュレータに対してテスト手順を記述したテストシナリオを入力し、テスト対象ソフトウェアの動作をテストするということも従来から行われている。   In addition, a test scenario describing the test procedure is input to a test simulator that runs on a computer equipped with a preemptive multitasking OS (sometimes simply called a multitasking OS) to test the operation of the software under test. It has also been done conventionally.

図５を参照すると、上記したテストシミュレータを利用した、ソフトウェアのテスト方法の一例が示されている。この例は、信号Ａを受信した際、それに応答して信号Ｂを送信するといった正しい動作を、テスト対象ソフトウェアが行うか否かをテストする場合についてのものである。尚、テストシナリオ１は、スクリプト言語で記述されたスクリプト形式のソフトウェアであり、テスト対象ソフトウェア３は、機械語で記述された実行形式のソフトウェアである。   Referring to FIG. 5, an example of a software test method using the test simulator described above is shown. In this example, when the test target software tests whether or not the correct operation of transmitting the signal B in response to receiving the signal A is performed. The test scenario 1 is script-format software described in a script language, and the test target software 3 is execution-format software described in a machine language.

テストシミュレータ２は、テストシナリオ１が入力されると、先ず、テストシナリオ１に記述されている信号Ａの送信要求に従って、信号Ａをテスト対象ソフトウェア３に対して送信する（S501,S502）。   When the test scenario 1 is input, the test simulator 2 first transmits the signal A to the test target software 3 in accordance with the transmission request for the signal A described in the test scenario 1 (S501, S502).

その後、テストシミュレータ２は、テストシナリオ１に記述されている信号Ｂの受信待ち要求に従って信号Ｂの受信待ち状態になる（S503,S504）。   Thereafter, the test simulator 2 enters a signal B reception waiting state in accordance with the signal B reception waiting request described in the test scenario 1 (S503, S504).

一方、テスト対象ソフトウェア３は、その動作が正常であれば、信号Ａを受信すると、それに関する処理を行い、信号Ｂをテストシミュレータ２へ返送する（S505）。テストシミュレータ２は、図５に示すタイミングで信号Ｂを受信すると、信号Ｂの受信待ち状態（S504）において期待した信号Ｂを受信できたので、テストPass（テスト成功）と判定する（S506）。   On the other hand, if the operation of the test target software 3 is normal, when the signal A is received, processing related thereto is performed, and the signal B is returned to the test simulator 2 (S505). When receiving the signal B at the timing shown in FIG. 5, the test simulator 2 has received the expected signal B in the signal B reception waiting state (S504), and therefore determines that the test is Pass (test success) (S506).

これに対して、テスト対象ソフトウェア３が正常動作せず、信号Ｂを返送しなかった場合は、信号Ｂの受信待ち状態において信号Ｂを受信できないので、テストFail（テスト失敗）と判定される。   On the other hand, when the test target software 3 does not operate normally and does not return the signal B, the signal B cannot be received in the signal B reception waiting state, so that it is determined as a test fail (test failure).

特開２００６−３５２２９０号公報JP 2006-352290 A

図５に示すように、テスト対象ソフトウェア３が返送した信号Ｂをテストシミュレータ２が受信するためには、信号Ｂを受信する時刻よりも前に信号Ｂの受信待ち要求をテストシナリオ１から受信して信号Ｂの受信待ち状態になっている必要がある。そのためには、テストシナリオ１が信号Ａの送信要求を行ってから信号Ｂの受信待ち要求を行うまでの処理時間t1と、テスト対象ソフトウェア３が信号Ａを受信してから信号Ｂを送信するまでの処理時間t2との時間差Δt＝（t2−t1）はある許容範囲内に収まっている必要がある。しかし、テストシナリオ１、テストシミュレータ２及びテスト対象ソフトウェア３を動作させるコンピュータの処理能力によっては、上記時間差Δtが許容範囲外となり、その結果、テスト対象ソフトウェア３が信号Ｂを返送しているにもかかわらず、テストシミュレータ２で受信されないために、テストFailと判定されてしまう場合がある。   As shown in FIG. 5, in order for the test simulator 2 to receive the signal B returned by the test target software 3, a signal B reception waiting request is received from the test scenario 1 before the time when the signal B is received. Therefore, it is necessary to be ready to receive signal B. For this purpose, the processing time t1 from when the test scenario 1 makes a transmission request for the signal A to when the reception waiting request for the signal B is made, and until the test target software 3 receives the signal A and transmits the signal B. The time difference Δt = (t2−t1) with respect to the processing time t2 needs to be within a certain allowable range. However, depending on the processing capacity of the computer that operates the test scenario 1, the test simulator 2, and the test target software 3, the time difference Δt is out of the allowable range, and as a result, the test target software 3 returns the signal B. Regardless, since the test simulator 2 does not receive it, it may be determined as a test fail.

図６を参照すると、上記時間差Δtが許容範囲外となったことが原因で、テストFailと判定されてしまう場合の一例が示されている。   Referring to FIG. 6, there is shown an example of a case where a test fail is determined because the time difference Δt is outside the allowable range.

テストシミュレータ２は、先ず、テストシナリオ１に記述されている信号Ａの送信要求に従って、信号Ａをテスト対象ソフトウェア３に対して送信し（S601,S602）、その後、信号Ｂの受信待ち要求に従って、信号Ｂの受信待ち状態になる（S604,S605）。   First, the test simulator 2 transmits the signal A to the test target software 3 according to the transmission request for the signal A described in the test scenario 1 (S601, S602), and then, according to the reception waiting request for the signal B, Reception of signal B is awaited (S604, S605).

一方、テスト対象ソフトウェア３は、テストシミュレータ２からの信号Ａを受信すると、信号Ａの処理を行い、信号Ｂをテストシミュレータ２へ送信する（S603）。   On the other hand, when the test target software 3 receives the signal A from the test simulator 2, the test target software 3 processes the signal A and transmits the signal B to the test simulator 2 (S603).

本来、テストシナリオ１は、信号Ｂがテストシミュレータ２に届く前に、テストシミュレータ２に対して信号Ｂの受信待ち要求を行うべきだが、図６の例では、テスト対象ソフトウェア３の処理速度が期待した処理速度よりも速くなってしまい、信号Ｂがテストシミュレータ２に届いたときには、まだテストシナリオ１がテストシミュレータ２に対して信号Ｂの受信待ちを行っていない。言い換えれば、この例では、テストシナリオ１が信号Ａの送信要求を行ってから信号Ｂの受信待ち要求を行うまでの処理時間t1と、テスト対象ソフトウェア３が信号Ａを受信してから信号Ｂを送信するまでの処理時間t2との時間差Δt＝t2−t1がマイナスとなり、許容範囲外となっている。このため、テストシミュレータ２は、信号Ｂの受信待ち状態において信号Ｂを受信できず、テストFailと判定してしまう。   Originally, in the test scenario 1, before the signal B reaches the test simulator 2, the test simulator 2 should be requested to receive the signal B. In the example of FIG. 6, the processing speed of the test target software 3 is expected. When the signal B reaches the test simulator 2, the test scenario 1 has not yet waited for the signal B to be received from the test simulator 2. In other words, in this example, the processing time t1 from when the test scenario 1 makes a transmission request for the signal A to when the reception waiting request for the signal B is made, and the signal B after the test target software 3 receives the signal A The time difference Δt = t2−t1 from the processing time t2 until transmission is negative, which is outside the allowable range. For this reason, the test simulator 2 cannot receive the signal B in the signal B reception waiting state, and determines that it is a test fail.

テストシナリオ１の処理時間t1とテスト対象ソフトウェア３の処理時間t2との時間差Δtが許容範囲外となってしまう要因のひとつとして、スクリプト言語で記述されたスクリプト形式のテストシナリオ１がテストシミュレータ２で実行される一方で、テスト対象ソフトウェア３が機械語で記述された実行形式のソフトウェアであることがあげられる。一般的に、スクリプト形式のソフトウェアの処理の方が実行形式のソフトウェアの処理より遅いので、それらの処理時間t1,t2の時間差Δtはコンピュータ毎の処理能力差に大きく依存する。このため、テストを実施するコンピュータの処理能力が異なると、テストシナリオ１が意図した処理速度にてテスト対象ソフトウェア３が動作せず、両者の処理時間t1,t2の時間差Δtが許容範囲外となり、テストFailと判定されてしまう。   As one of the factors that cause the time difference Δt between the processing time t1 of the test scenario 1 and the processing time t2 of the test target software 3 to be out of the allowable range, the test scenario 1 in the script format described in the script language is the test simulator 2 On the other hand, it can be mentioned that the test target software 3 is execution-format software written in machine language. In general, script-type software processing is slower than execution-type software processing, so the time difference Δt between the processing times t1 and t2 greatly depends on the processing capability difference between computers. For this reason, if the processing capacity of the computer performing the test is different, the test target software 3 does not operate at the processing speed intended by the test scenario 1, and the time difference Δt between the processing times t1 and t2 is outside the allowable range. The test fails.

そこで、本願発明者は、テスト対象ソフトウェア３が正常動作しているにもかかわらず、テストシミュレータ２とテスト対象ソフトウェア３との処理時間の時間差が許容範囲外となってしまうことにより、テストFailと判定されてしまうという問題点を解決するため、テストFailと判定される度にプリエンティブなマルチタスクOSにかかる負荷を人手で変更し、再度テストを実施するという実験を行った。その結果、マルチタスクOSにかける負荷によっては、テストPassと判定される場合があることを分かった。この方法によれば、テスト対象ソフトウェア３が正常動作しているにもかかわらず、テストシミュレータ２とテスト対象ソフトウェア３との処理時間の時間差が原因でテストFailと判定されてしまう危険性を少なくすることはできるが、テスト担当者が試行錯誤を繰り返し、手作業でマルチタスクOSにかかる負荷を変更しなければならないので、テスト効率が悪いという問題がある。   Therefore, the inventor of the present application determines that the test fail and the test fail are caused by the time difference between the processing times of the test simulator 2 and the test target software 3 being out of the allowable range even though the test target software 3 is operating normally. In order to solve the problem of being judged, an experiment was conducted in which the load on the preemptive multitasking OS was manually changed each time a test failure was judged and the test was performed again. As a result, it was found that the test pass might be judged depending on the load applied to the multitasking OS. According to this method, although the test target software 3 is operating normally, the risk of being judged as a test fail due to the time difference between the processing times of the test simulator 2 and the test target software 3 is reduced. Although it is possible, the tester must repeat trial and error, and the load on the multitasking OS must be changed manually.

そこで、本発明の目的は、テスト対象ソフトウェアが正常動作しているにもかかわらず、テストシナリオとテスト対象ソフトウェアとの処理時間の時間差が原因で誤ってテスト失敗と判定されてしまう危険性を小さくするために、マルチタスクOSにかかる負荷を人手で変更するようにすると、テスト効率が悪くなってしまうという課題を解決したソフトウェアテスト装置を提供することにある。   Therefore, an object of the present invention is to reduce the risk that a test failure will be erroneously determined due to a time difference between processing times of the test scenario and the test target software even though the test target software is operating normally. Therefore, an object of the present invention is to provide a software test apparatus that solves the problem that test efficiency deteriorates when the load on the multitasking OS is manually changed.

本発明のかかる第１のソフトウェアテスト装置は、
マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作しているテスト対象ソフトウェアに対して実施するテストシミュレータと、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段と、
前記テストシミュレータに入力したテストシナリオの内、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段とを備え、
前記負荷変更手段は、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。 The first software test apparatus according to the present invention includes:
A test simulator that operates on a multitasking operating system, and for each input test scenario, a test according to instructions described in the test scenario is operating on the multitasking operating system. A test simulator for the software under test,
Load changing means for changing a load applied to the multitasking operating system;
Of the test scenarios input to the test simulator, the test scenario whose test result has failed is input again to the test simulator, and the load applied to the multitask operating system is changed with respect to the load changing means. And a test control means for instructing
The load changing unit changes a load applied to the multitask operating system in accordance with an instruction from the test control unit.

本発明にかかるソフトウェアテスト方法は、
マルチタスク・オペレーティングシステムを搭載すると共に、テスト制御手段と、負荷変更手段と、前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータとを備えたコンピュータが実行するソフトウェアテスト方法であって、
前記テストシミュレータが、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施し、
前記テスト制御手段が、前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示し、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。 The software test method according to the present invention includes:
A software test method to be executed by a computer having a multitasking operating system, a test control means, a load changing means, and a test simulator operating on the multitasking operating system,
The test simulator performs a test in accordance with an instruction described in the test scenario for each of the input test scenarios, with respect to the test target software operating on the multitask operating system,
The test control means inputs again the test scenario in which the test result has failed among the test scenarios input to the test simulator to the test simulator, and also applies the multitask operating system to the load changing means. To change the load on the
The load changing unit changes a load applied to the multitask operating system in accordance with an instruction from the test control unit.

本発明にかかるプログラムは、
マルチタスク・オペレーティングシステムを搭載したコンピュータを、ソフトウェアテスト装置として機能させるためのプログラムであって、
前記コンピュータを、
前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施するテストシミュレータ、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段、
前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段として機能させ、且つ、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更する。 The program according to the present invention is:
A program for causing a computer equipped with a multitasking operating system to function as a software test device,
The computer,
A test simulator that operates on the multitasking operating system, and for each of the input test scenarios, a test that operates on the multitasking operating system is performed according to an instruction described in the test scenario. A test simulator for the target software,
Load changing means for changing the load applied to the multitasking operating system;
Of the test scenarios input to the test simulator, the test scenario whose test result has failed is input again to the test simulator, and the load applied to the multitask operating system is changed with respect to the load changing means. Function as a test control means for instructing, and
The load changing unit changes a load applied to the multitask operating system in accordance with an instruction from the test control unit.

本発明によれば、テスト対象プログラムが正常動作しているにもかかわらず、テストシミュレータとテスト対象ソフトウェアとの処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。   According to the present invention, although the test target program is operating normally, the test efficiency is improved while reducing the risk of being judged as a test failure due to the time difference between the test simulator and the test target software. Can be improved.

本発明の第１の実施の形態にかかるソフトウェアテスト装置の構成例を示すブロック図である。It is a block diagram which shows the structural example of the software test apparatus concerning the 1st Embodiment of this invention. テスト結果保管部105の内容例を示す図である。6 is a diagram showing an example of contents of a test result storage unit 105. FIG. テスト制御プログラム101の処理例を示すフローチャートである。3 is a flowchart showing a processing example of a test control program 101. 本発明の第２の実施の形態にかかるソフトウェアテスト装置の構成例を示すブロック図である。It is a block diagram which shows the structural example of the software test apparatus concerning the 2nd Embodiment of this invention. テストシナリオ１とテスト対象ソフトウェア３との処理時間の時間差が許容範囲内であり、正しいテスト結果が得られた場合の一例を示す図である。It is a figure which shows an example when the time difference of the processing time of the test scenario 1 and the test object software 3 is in an allowable range, and the correct test result is obtained. テストシミュレータ２とテスト対象ソフトウェア３との処理時間の時間差が許容範囲外であり、正しいテスト結果が得られなかった場合の一例を示す図である。It is a figure which shows an example when the time difference of the processing time of the test simulator 2 and the test object software 3 is outside an allowable range, and a correct test result is not obtained.

次に、本発明の実施の形態について、図面を参照して詳細に説明する。   Next, embodiments of the present invention will be described in detail with reference to the drawings.

[本発明の第１の実施の形態]
図１を参照すると、本発明にかかるソフトウェアテスト装置100の第１の実施の形態は、テスト制御手段であるテスト制御プログラム101と、テストシナリオ記憶部102と、テストシミュレータ103と、テスト対象ソフトウェア104と、テスト結果保管部105と、負荷変更手段である負荷変更ソフトウェア106とを備えている。尚、テスト制御プログラム101、テストシミュレータ103、テスト対象ソフトウェア104、及び、負荷変更ソフトウェア106は、プリエンティブなマルチタスクOS200を搭載したコンピュータ上で動作する。 [First embodiment of the present invention]
Referring to FIG. 1, a first embodiment of a software test apparatus 100 according to the present invention includes a test control program 101 as a test control means, a test scenario storage unit 102, a test simulator 103, and test target software 104. And a test result storage unit 105 and load change software 106 as load change means. Note that the test control program 101, the test simulator 103, the test target software 104, and the load change software 106 operate on a computer equipped with a preemptive multitask OS 200.

テストシナリオ記憶部102には、複数のテストシナリオT1〜Tnが記録されている。各テストシナリオT1〜Tnは、スクリプト言語で記述されており、各テストシナリオT1〜Tnは、それぞれ異なるテスト項目に対応している。   The test scenario storage unit 102 stores a plurality of test scenarios T1 to Tn. Each test scenario T1 to Tn is described in a script language, and each test scenario T1 to Tn corresponds to a different test item.

テスト対象ソフトウェア104は、テスト（例えば、回帰テストなど）の実施対象となるソフトウェアであり、機械語で記述されている。尚、テスト対象ソフトウェア104は任意のもので良く、例えば、組み込みソフトウェアをテストする場合には、リアルタイムOSをエミュレートしたOSおよび組み込みソフトウェアを組み込んだテスト対象ソフトウェア104を使用することができる。   The test target software 104 is software to be subjected to a test (for example, regression test), and is described in a machine language. Note that the test target software 104 may be arbitrary. For example, when testing embedded software, an OS emulating a real-time OS and the test target software 104 including the embedded software can be used.

テストシミュレータ103は、テスト制御プログラム101から入力されたテストシナリオに記述されている命令に従ってテスト対象ソフトウェア104の動作をテストし、テスト結果をテスト結果保管部105に記録する。   The test simulator 103 tests the operation of the test target software 104 in accordance with instructions described in the test scenario input from the test control program 101, and records the test result in the test result storage unit 105.

テスト結果保管部105には、テストシナリオを一意に識別する識別子に関連付けて、そのテストシナリオについてのテスト結果（Pass或いはFail）が記録されている。図２は、テスト結果保管部105の内容例を示す図であり、同図の例は、テストシナリオT1,T2によるテストは成功したが、テストシナリオT3によるテストは失敗したことなどを示している。尚、初期状態においては、テストシナリオT1〜Tnの識別子に関連付けて、テスト未実施を示す情報が記録されている。   The test result storage unit 105 records a test result (Pass or Fail) for the test scenario in association with an identifier for uniquely identifying the test scenario. FIG. 2 is a diagram showing an example of the contents of the test result storage unit 105. The example of the figure shows that the test using the test scenarios T1 and T2 succeeded, but the test using the test scenario T3 failed. . In the initial state, information indicating that the test has not been performed is recorded in association with the identifiers of the test scenarios T1 to Tn.

テスト制御プログラム101は、テスト結果保管部105に記録されているテスト結果に基づいて、テストシナリオT1〜Tnの中からテストに使用するテストシナリオを選択し、選択したテストシナリオをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。より具体的には、テスト制御プログラム101は、テスト結果保管部105に記録されているテスト結果がPassとなっていないテストシナリオ（テスト結果がFailまたはテスト未実施となっているテストシナリオ）を選択し、選択したテストシナリオをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。   The test control program 101 selects a test scenario to be used for the test from the test scenarios T1 to Tn based on the test result recorded in the test result storage unit 105, and the selected test scenario is stored in the test scenario storage unit 102. Is input to the test simulator 103. More specifically, the test control program 101 selects a test scenario in which the test result recorded in the test result storage unit 105 is not Pass (a test scenario in which the test result is Fail or the test has not been performed). The selected test scenario is read from the test scenario storage unit 102 and input to the test simulator 103.

また、テスト制御プログラム101は、テストシミュレータ103によるテストが完了すると、テスト結果がFailとなっているテストシナリオが存在するか否かを調べ、そのようなテストシナリオが存在する場合には、更に、テストの実施回数が予め定められている回数になったか否かを判定する。そして、テストの実施回数が予め定められている回数に達していない場合は、負荷変更ソフトウェア106の負荷量を決定して負荷変更ソフトウェア106に通知すると共に、テスト結果がPassとなっていないテストシナリオをテストシミュレータ103に入力して、再度テストを実施させる。ここで、負荷量としては、例えば、メモリ（メインメモリ）300へのデータの書き込み間隔を使用することができる。また、負荷量の決定方法としては、ランダムに負荷量を決定する方法や、予め定められているアルゴリズムに従って負荷量を決定する方法を採用することができる。   Further, when the test by the test simulator 103 is completed, the test control program 101 checks whether or not there is a test scenario whose test result is Fail, and when such a test scenario exists, It is determined whether the number of times the test has been performed has reached a predetermined number. If the number of test executions has not reached a predetermined number, the load amount of the load change software 106 is determined and notified to the load change software 106, and the test scenario in which the test result is not Pass Is input to the test simulator 103 to execute the test again. Here, as the load amount, for example, a data write interval to the memory (main memory) 300 can be used. Further, as a method for determining the load amount, a method for randomly determining the load amount or a method for determining the load amount according to a predetermined algorithm can be employed.

負荷変更ソフトウェア106は、テスト制御プログラム101から通知された書き込み間隔で、ダミーのデータをメモリ300に書き込むことにより、マルチタスクOS200にかかる負荷を変更する。   The load change software 106 changes the load applied to the multitask OS 200 by writing dummy data into the memory 300 at the write interval notified from the test control program 101.

[第１の実施の形態の動作の説明]
次に、本実施の形態の動作について図３のフローチャートを参照して詳細に説明する。 [Description of Operation of First Embodiment]
Next, the operation of the present embodiment will be described in detail with reference to the flowchart of FIG.

ソフトウェアテスト装置100内のテスト制御プログラム101は、テスト担当者によってテスト開始が指示されると、先ず、テスト結果保管部105に記録されている各テストシナリオT1〜Tnのテスト結果に基づいて、テストに使用するテストシナリオを選択する（ステップＳ31）。本実施の形態では、テスト結果がPassとなっていないテストシナリオを選択するようにしており、初期状態（テスト開始前）においては全てのテストシナリオT1〜Tnのテスト結果が「テスト未実施」となっているので、ステップＳ31では全てのテストシナリオT1〜Tnを選択する。   The test control program 101 in the software test apparatus 100, when instructed to start a test by a tester, first performs a test based on the test results of the test scenarios T1 to Tn recorded in the test result storage unit 105. A test scenario to be used is selected (step S31). In this embodiment, a test scenario whose test result is not Pass is selected, and in the initial state (before the test is started), the test results of all test scenarios T1 to Tn are “untested”. Therefore, in step S31, all test scenarios T1 to Tn are selected.

その後、テスト制御プログラム101は、ステップＳ31で選択したテストシナリオT1〜Tnをテストシナリオ記憶部102から読み出してテストシミュレータ103に入力する。その後、テスト制御プログラム101は、テスト完了待ち状態となる（ステップＳ33）。   Thereafter, the test control program 101 reads the test scenarios T1 to Tn selected in step S31 from the test scenario storage unit 102 and inputs them to the test simulator 103. Thereafter, the test control program 101 enters a test completion waiting state (step S33).

一方、テストシミュレータ103は、テスト制御プログラム101から入力されたテストシナリオT1〜Tnに従って、テスト対象ソフトウェア104の動作をテストし、テストシナリオ毎に、そのテスト結果をテスト結果保管部105に記録する。そして、入力された全てのテストシナリオT1〜Tnについて処理が完了すると、テスト制御プログラム101に対してテスト完了を通知する。   On the other hand, the test simulator 103 tests the operation of the test target software 104 according to the test scenarios T1 to Tn input from the test control program 101, and records the test result in the test result storage unit 105 for each test scenario. When the processing is completed for all the input test scenarios T1 to Tn, the test completion is notified to the test control program 101.

テスト制御プログラム101は、テストシミュレータ103からテスト完了が通知されると、テスト結果保管部105を検索し、テスト結果がFailとなっているテストシナリオが存在するか否かを調べる（ステップＳ34）。そして、テスト結果がFailとなっているテストシナリオが存在しない場合（ステップＳ34がNO）は、テスト制御プログラム101はその処理を終了する。これに対して、テスト結果がFailとなっているテストシナリオが存在する場合（ステップＳ34がYES）は、テストの実施回数が、テスト担当者によって予め設定されている所定回数に達しているか否かを判定する（ステップＳ35）。   When the test completion is notified from the test simulator 103, the test control program 101 searches the test result storage unit 105 to check whether there is a test scenario in which the test result is “Fail” (step S34). If there is no test scenario in which the test result is Fail (NO in step S34), the test control program 101 ends the process. On the other hand, if there is a test scenario in which the test result is Fail (YES in step S34), whether or not the number of test executions has reached a predetermined number set in advance by the tester. Is determined (step S35).

そして、テスト実施回数が所定回数に達している場合（ステップＳ35がYES）は、テスト制御プログラム101は、その処理を終了する。これに対して、テスト実施回数が所定回数に達していない場合（ステップＳ35がNO）は、テスト制御プログラム101は、プリエンティブなマルチタスクOS200にかかる負荷を変更するための負荷量であって、負荷変更ソフトウェア106を利用して発生させる負荷量を決定する（ステップＳ36）。より具体的には、メモリ300へのデータの書き込み間隔を決定し、それを負荷変更ソフトウェア106を利用して発生させる負荷量とする。   If the number of test executions has reached the predetermined number (YES in step S35), the test control program 101 ends the process. On the other hand, when the number of test executions has not reached the predetermined number (step S35 is NO), the test control program 101 has a load amount for changing the load applied to the preemptive multitask OS 200, A load amount to be generated is determined using the load change software 106 (step S36). More specifically, the interval for writing data to the memory 300 is determined, and this is the amount of load generated using the load change software 106.

書き込み間隔の決定方法としては、ランダムに書き込み間隔を決定する方法や、テスト担当者によって指定されているアルゴリズムに従って書き込み間隔を決定する方法などを採用することができる。また、書き込み間隔を決定するためのアルゴリズムとしては、例えば、複数の書き込み間隔を設定しておき、設定されている書き込み間隔を順番に使用するといったアルゴリズムや、書き込み間隔の初期値を設定しておき、テストを実施する度に書き込み間隔を所定値ずつ小さく或いは大きくしていくといったアルゴリズムや、書き込み間隔の初期値を設定しておき、テストを実施する度に書き込み間隔を所定の割合ずつ小さく或いは大きくしていくといったアルゴリズムを使用することができる。   As a method for determining the write interval, a method for randomly determining the write interval, a method for determining the write interval in accordance with an algorithm designated by a tester, or the like can be employed. In addition, as an algorithm for determining the write interval, for example, an algorithm in which a plurality of write intervals are set and the set write intervals are used in order, or an initial value of the write interval is set. An algorithm for decreasing or increasing the write interval by a predetermined value each time a test is performed, or an initial value of the write interval is set, and the write interval is decreased or increased by a predetermined ratio each time the test is performed. Can be used.

そして、メモリ300への書き込み時間間隔を決定すると、テスト制御プログラム101は、負荷変更ソフトウェア106に対して書き込み間隔を通知する（ステップＳ37）。   Then, when the write time interval to the memory 300 is determined, the test control program 101 notifies the load change software 106 of the write interval (step S37).

これにより、負荷変更ソフトウェア106は、通知された書き込み間隔で、予め定められているダミーのデータをメモリ300に書き込む。これにより、プリエンティブなマルチタスクOS200にかかる負荷が変化し、それに伴ってテストシミュレータ103及びテスト対象ソフトウェア104の処理時間が変化すると共に、処理時間の時間差も変化する。このため、テスト対象ソフトウェア104が正常動作していれば、次回のテスト時に、テストシミュレータ103とテスト対象ソフトウェア104との処理時間の時間差が許容範囲内となり、テストPassと判定される可能性が出てくる。   Thereby, the load changing software 106 writes predetermined dummy data in the memory 300 at the notified writing interval. As a result, the load on the preemptive multitasking OS 200 changes, and accordingly, the processing time of the test simulator 103 and the test target software 104 changes, and the time difference between the processing times also changes. For this reason, if the software under test 104 is operating normally, the time difference between the processing times of the test simulator 103 and the software under test 104 will be within the allowable range during the next test, and there is a possibility that it will be determined as a test pass. Come.

その後、テスト制御プログラム101は、ステップＳ31の処理に戻り、テスト結果保管部105に記録されている各テストシナリオT1〜Tnのテスト結果に基づいて、テストに使用するテストシナリオを選択する。以後、テスト制御プログラム101は、テスト結果がFailのテストシナリオがなくなるか（ステップＳ34がNOとなるか）、或いはテスト実施回数が予め定められている所定回数に達するまで（ステップＳ35がYESとなるまで）、前述した処理を繰り返し行う。   Thereafter, the test control program 101 returns to the process of step S31, and selects a test scenario to be used for the test based on the test results of the test scenarios T1 to Tn recorded in the test result storage unit 105. Thereafter, the test control program 101 determines that there is no test scenario whose test result is “Fail” (whether step S34 is NO) or the test execution count reaches a predetermined number of times (step S35 is YES). Until the above process is repeated.

なお、上述した実施の形態では、メモリ300に対するデータの書き込み間隔を変更することにより、プリエンティブなマルチタスクOS200にかかる負荷を変更するようにしたが、ディスク装置などの外部記憶装置に対するデータの書き込み間隔を変更するようにしても良い。ディスク装置などの外部記憶装置に対するデータの書き込み間隔を変更するようにすることにより、メモリ300に対するデータの書き込み間隔を変更する場合に比較して、プリエンティブなマルチタスクOSにかかる負荷を大きく変化させることが可能になる。   In the above-described embodiment, the load applied to the preemptive multitask OS 200 is changed by changing the data write interval to the memory 300. However, the data write to the external storage device such as a disk device is changed. The interval may be changed. By changing the data writing interval to the external storage device such as a disk device, the load on the preemptive multitasking OS is greatly changed compared to changing the data writing interval to the memory 300. It becomes possible.

［第１の実施の形態の効果］
本実施の形態によれば、テスト対象プログラム104が正常動作しているにもかかわらず、テストシナリオT1〜Tnの処理時間とテスト対象ソフトウェア104の処理時間との時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。その理由は、テストシミュレータ103に入力したテストシナリオの内、テスト結果がFailとなったテストシナリオをテストシミュレータ103に再度入力すると共に、負荷変更ソフトウェア106に対してプリエンティブなマルチタスクOS200にかかる負荷を変更することを指示するテスト制御プログラム101を備えているからである。 [Effect of the first embodiment]
According to the present embodiment, although the test target program 104 is operating normally, the test failure is determined due to the time difference between the processing time of the test scenarios T1 to Tn and the processing time of the test target software 104. Test efficiency can be improved while reducing the risk. The reason is that, among the test scenarios input to the test simulator 103, the test scenario whose test result is “Fail” is input again to the test simulator 103, and the load applied to the multitasking OS 200 preemptive to the load changing software 106. This is because the test control program 101 for instructing to change is provided.

［本発明の第２の実施の形態］
次に、本発明にかかるソフトウェアテスト装置の第２の実施の形態について説明する。 [Second embodiment of the present invention]
Next, a second embodiment of the software test apparatus according to the present invention will be described.

図４を参照すると、本実施の形態にかかるソフトウェアテスト装置は、テストシミュレータ41と、負荷変更手段42と、テスト制御手段43とを備えている。   Referring to FIG. 4, the software test apparatus according to the present embodiment includes a test simulator 41, a load changing unit 42, and a test control unit 43.

テストシミュレータ41は、プリエンティブなマルチタスクOS（図示せず）上で動作するものであり、テスト制御手段43から入力されたスクリプト形式のテストシナリオ45に記述されている命令に従ったテストを、上記マルチタスクOS上で動作している実行形式のテスト対象ソフトウェア44に対して実施する。   The test simulator 41 operates on a preemptive multitasking OS (not shown), and performs a test according to instructions described in a script-type test scenario 45 input from the test control means 43. The test is performed on the test target software 44 running on the multitask OS.

テスト制御手段43は、テストシミュレータ41にテストシナリオ45を入力し、テスト対象ソフトウェア44の動作をテストさせる。そして、テストシミュレータ41に入力したテストシナリオの内、テスト結果が失敗（Fail）となったテストシナリオをテストシミュレータ41に再度入力すると共に、負荷変更手段42に対してマルチタスクOSにかかる負荷を変更することを指示する。この指示に応答して、負荷変更手段42は、マルチタスクOSにかかる負荷を変更する。   The test control means 43 inputs a test scenario 45 to the test simulator 41 and causes the operation of the test target software 44 to be tested. Then, among the test scenarios input to the test simulator 41, the test scenario whose test result has failed (Fail) is input again to the test simulator 41, and the load on the multitask OS is changed to the load changing means 42 Instruct to do. In response to this instruction, the load changing unit 42 changes the load applied to the multitask OS.

尚、上記したソフトウェアテスト装置は、コンピュータによって実現可能であり、コンピュータによって実現する場合は、例えば、次のようにする。コンピュータをソフトウェアテスト装置として機能させるためのプログラムを記録した半導体メモリ、ディスク、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、テストシミュレータ41、負荷変更手段42、及び、テスト制御手段43を実現する。   The above-described software test apparatus can be realized by a computer, and when realized by a computer, for example, is as follows. A semiconductor memory, a disk, and other recording media storing a program for causing the computer to function as a software test apparatus are prepared, and the computer is caused to read the program. The computer realizes the test simulator 41, the load changing means 42, and the test control means 43 on its own computer by controlling its own operation according to the read program.

［第２の実施の形態の効果］
本実施の形態によれば、テスト対象プログラム45が正常動作しているにもかかわらず、テストシナリオT1〜Tnとテスト対象ソフトウェア45との処理時間の時間差によりテスト失敗と判定されてしまう危険性を少なくしつつ、テスト効率を向上させることができる。その理由は、テストシミュレータ41に入力したテストシナリオの内、テスト結果が失敗となったテストシナリオをテストシミュレータ41に再入力すると共に、負荷変更手段42に対してマルチタスクOSにかかる負荷の変更を指示するテスト制御手段43を備えているからである。 [Effect of the second embodiment]
According to the present embodiment, there is a risk that a test failure may be determined due to a time difference in processing time between the test scenarios T1 to Tn and the test target software 45 even though the test target program 45 is operating normally. The test efficiency can be improved while reducing the number. The reason is that, among the test scenarios input to the test simulator 41, the test scenario whose test result has failed is re-input to the test simulator 41 and the load on the multitask OS is changed to the load changing means 42. This is because the test control means 43 for instructing is provided.

本発明は、ソフトウェアの動作テスト、ソフトウェアの動作速度調整などに利用することができる。   The present invention can be used for software operation tests, software operation speed adjustments, and the like.

100…ソフトウェアテスト装置
101…テスト制御プログラム
102…テストシナリオ記憶部
T1〜Tn…テストシナリオ
103…テストシミュレータ
104…テスト対象ソフトウェア
105…テスト結果保管部
106…負荷変更ソフトウェア
200…プリエンティブなマルチタスクOS
300…メモリ
41…テストシミュレータ
42…負荷変更手段
43…テスト制御手段
44…テスト対象ソフトウェア
45…テストシナリオ 100 ... Software test equipment
101 ... Test control program
102 ... Test scenario storage
T1-Tn ... Test scenario
103 ... Test simulator
104 ... Test target software
105 ... Test result storage
106… Load change software
200 ... Preemptive multitasking OS
300 ... memory
41 ... Test simulator
42 ... Load change means
43 ... Test control means
44… Tested software
45… Test scenario

Claims (7)

マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作しているテスト対象ソフトウェアに対して実施するテストシミュレータと、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段と、
前記テストシミュレータに入力したテストシナリオの内、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段とを備え、
前記負荷変更手段は、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするソフトウェアテスト装置。 A test simulator that operates on a multitasking operating system, and for each input test scenario, a test according to instructions described in the test scenario is operating on the multitasking operating system. A test simulator for the software under test,
Load changing means for changing a load applied to the multitasking operating system;
Of the test scenarios input to the test simulator, the test scenario whose test result has failed is input again to the test simulator, and the load applied to the multitask operating system is changed with respect to the load changing means. And a test control means for instructing
The load changing means changes the load applied to the multitask operating system in accordance with an instruction from the test control means. 請求項１記載のソフトウェアテスト装置において、
前記テストシナリオは、スクリプト言語で記述され、
前記テスト対象ソフトウェアは、機械語で記述されることを特徴とするソフトウェアテスト装置。 The software test apparatus according to claim 1,
The test scenario is described in a script language,
The software to be tested is described in machine language. 請求項１または２記載のソフトウェアテスト装置において、
前記テスト制御手段は、前記負荷変更手段に対して負荷の変更を指示する際、記憶装置へのデータの書き込み間隔を指示し、
前記負荷変更手段は、前記テスト制御手段から指示された書き込み間隔でデータを記憶装置に書き込むことを特徴とするソフトウェアテスト装置。 The software test apparatus according to claim 1 or 2,
The test control means, when instructing the load change means to change the load, instructs the data write interval to the storage device,
The software testing apparatus, wherein the load changing unit writes data into a storage device at a write interval instructed by the test control unit. 請求項３記載のソフトウェアテスト装置において、
前記記憶装置は、メインメモリまたは外部記憶装置であることを特徴とするソフトウェアテスト装置。 The software test apparatus according to claim 3, wherein
A software test apparatus, wherein the storage device is a main memory or an external storage device. 請求項１乃至４の何れか１項に記載のソフトウェアテスト装置において、
前記テスト制御手段は、予め定められている複数のテスト項目それぞれについて、そのテスト項目に関連するテストシナリオを前記テストシミュレータに入力し、前記テストシミュレータにおいて入力された全てのテストシナリオに従ったテストが完了する毎に、テスト結果が失敗となったテスト項目に対応するテストシナリオを前記テストシミュレータに入力する処理と前記負荷変更手段に対して負荷の変更を指示する処理とを、テスト回数が予め定められている回数となるか、またはテスト結果が失敗となってテスト項目がなくなるまで、繰り返し行うことを特徴とするソフトウェアテスト装置。 The software test apparatus according to any one of claims 1 to 4,
The test control means inputs, for each of a plurality of predetermined test items, a test scenario related to the test item to the test simulator, and tests according to all the test scenarios input in the test simulator are performed. Each time the test is completed, the number of tests is determined in advance as a process for inputting a test scenario corresponding to a test item for which the test result has failed to the test simulator and a process for instructing the load changing means to change the load. The software test apparatus is characterized in that the test is repeated until the number of test items is reached or the test result fails and there are no more test items. マルチタスク・オペレーティングシステムを搭載すると共に、テスト制御手段と、負荷変更手段と、前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータとを備えたコンピュータが実行するソフトウェアテスト方法であって、
前記テストシミュレータが、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施し、
前記テスト制御手段が、前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示し、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするソフトウェアテスト方法。 A software test method to be executed by a computer having a multitasking operating system, a test control means, a load changing means, and a test simulator operating on the multitasking operating system,
The test simulator performs a test in accordance with an instruction described in the test scenario for each of the input test scenarios, with respect to the test target software operating on the multitask operating system,
The test control means inputs again the test scenario in which the test result has failed among the test scenarios input to the test simulator to the test simulator, and also applies the multitask operating system to the load changing means. To change the load on the
A software test method, wherein the load changing means changes a load applied to the multitask operating system in accordance with an instruction from the test control means. マルチタスク・オペレーティングシステムを搭載したコンピュータを、ソフトウェアテスト装置として機能させるためのプログラムであって、
前記コンピュータを、
前記マルチタスク・オペレーティングシステム上で動作するテストシミュレータであって、入力されたテストシナリオそれぞれについて、そのテストシナリオに記述されている命令に従ったテストを、前記マルチタスク・オペレーティングシステム上で動作するテスト対象ソフトウェアに対して実施するテストシミュレータ、
前記マルチタスク・オペレーティングシステムにかかる負荷を変更する負荷変更手段、
前記テストシミュレータに入力したテストシナリオの内の、テスト結果が失敗となったテストシナリオを前記テストシミュレータに再度入力すると共に、前記負荷変更手段に対して前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを指示するテスト制御手段として機能させ、且つ、
前記負荷変更手段が、前記テスト制御手段からの指示に従って前記マルチタスク・オペレーティングシステムにかかる負荷を変更することを特徴とするプログラム。 A program for causing a computer equipped with a multitasking operating system to function as a software test device,
The computer,
A test simulator that operates on the multitasking operating system, and for each of the input test scenarios, a test that operates on the multitasking operating system is performed according to an instruction described in the test scenario. A test simulator for the target software,
Load changing means for changing the load applied to the multitasking operating system;
Of the test scenarios input to the test simulator, the test scenario whose test result has failed is input again to the test simulator, and the load applied to the multitask operating system is changed with respect to the load changing means. Function as a test control means for instructing, and
The load changing means changes the load applied to the multitask operating system in accordance with an instruction from the test control means.
JP2010251389A 2010-11-10 2010-11-10 Software test device Pending JP2012103874A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010251389A JP2012103874A (en) 2010-11-10 2010-11-10 Software test device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010251389A JP2012103874A (en) 2010-11-10 2010-11-10 Software test device

Publications (1)

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

Family

ID=46394197

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010251389A Pending JP2012103874A (en) 2010-11-10 2010-11-10 Software test device

Country Status (1)

Country Link
JP (1) JP2012103874A (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023024762A (en) * 2019-06-14 2023-02-16 Ｊｆｅエンジニアリング株式会社 Method, device, and computer program for automatically testing control software

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023024762A (en) * 2019-06-14 2023-02-16 Ｊｆｅエンジニアリング株式会社 Method, device, and computer program for automatically testing control software
JP7392821B2 (en) 2019-06-14 2023-12-06 Ｊｆｅエンジニアリング株式会社 Automatic testing method and device for control software and computer program

Similar Documents

Publication Publication Date Title
US20110145643A1 (en) Reproducible test framework for randomized stress test
JP5104958B2 (en) Virtual computer system test method, test program, recording medium thereof, and virtual computer system
EP3602306B1 (en) Automated device test triaging system and techniques
JP2014532914A (en) Programmable test equipment
US8645766B2 (en) Serialized error injection into a function under test
CN102831058B (en) Testing method and testing device
CN109597653A (en) Method, BIOS and the BMC of BIOS and BMC command interaction
CN110532182A (en) A kind of automated testing method and device of virtual platform
US20100312541A1 (en) Program test device and program
US8874966B1 (en) Storage device error simulator tool
KR20200067474A (en) Fault injection test method and system for vehicle software based on autosar
US9218273B2 (en) Automatic generation of a resource reconfiguring test
US20120124425A1 (en) Method and Apparatus Useful In Manufacturing Test Case Operations
US20140278334A1 (en) Method to verify correctness of computer system software and hardware components and corresponding test environment
JPWO2008099657A1 (en) Semiconductor integrated circuit, debug / trace circuit, and semiconductor integrated circuit operation observation method
JP6771413B2 (en) Software verification device and software verification program
JP2012103874A (en) Software test device
US8639978B2 (en) Topology independent network-based automation infrastructure
JP2009104490A (en) Apparatus for testing program
CN114756293A (en) Service processing method, device, computer equipment and storage medium
JP5550578B2 (en) Entry rewriting device and entry rewriting program
US8359456B2 (en) Generating random addresses for verification of distributed computerized devices
US20120123761A1 (en) Testing Software On A Computer System
JP2010102446A (en) Automatic software test device
WO2012172682A1 (en) Arithmetic processing device and control method for arithmetic processing device

Legal Events

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

Free format text: JAPANESE INTERMEDIATE CODE: A7427

Effective date: 20120718