JP6897473B2 - テストプログラム、テスト方法、およびテスト装置 - Google Patents

Description

本発明は、テストプログラム、テスト方法、およびテスト装置に関する。

従来、システムの耐障害性を向上させるために、システムを運用するノードが冗長化され、例えば、運用ノードと待機ノードとがシステムに含まれることがある。システム内のソフトウェアは、通常時は運用ノードでシステムが運用され、運用ノードの障害時は待機ノードでシステムが運用されるように、システムを運用するノードを切り替える。このソフトウェアは、例えば、クラスタソフトウェアと呼ばれる。

先行技術としては、例えば、サブシステムのＣＰＵコアによるプログラムの実行が所定のブレーク条件と一致したことの検出に応じて、サブシステムのうち選択されたサブシステムの動作を停止させるものがある。また、例えば、各コンピュータ間で連携して動作する各アプリケーションプログラムの処理の同期を確立し、かつ、デバッガの動作処理の撹乱を抑止する技術がある。また、例えば、稼働中ノードの駆動管理部が、ユーザプログラムの処理を実行開始する度に、組込みノードに対して処理開始の通知を行う技術がある。

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

しかしながら、従来技術では、システムを運用するノードを運用ノードから待機ノードに切り替える切替処理を行うソフトウェアを精度よくテストすることが難しい。例えば、運用ノードまたは待機ノードの動作の結果が異常になるように設定してからソフトウェアのテストを開始した場合、切替処理より前にソフトウェアが行う処理でエラーが発生してしまい、切替処理をテストすることができないことがある。

１つの側面では、本発明は、ソフトウェアのテストの精度向上を図ることができるテストプログラム、テスト方法、およびテスト装置を提供することを目的とする。

１つの実施態様によれば、テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行するテストプログラム、テスト方法、およびテスト装置が提案される。

一態様によれば、ソフトウェアのテストの精度向上を図ることが可能になる。

図１は、実施の形態にかかるテスト方法の一実施例を示す説明図である。 図２は、テストシステム２００の一例を示す説明図である。 図３は、テストシステム２００の具体例を示す説明図である。 図４は、テスト装置１００のハードウェア構成例を示すブロック図である。 図５は、ステータステーブル５００の記憶内容の一例を示す説明図である。 図６は、送信側フラグテーブル６００の記憶内容の一例を示す説明図である。 図７は、受信側フラグテーブル７００の記憶内容の一例を示す説明図である。 図８は、作業域８００の記憶内容の一例を示す説明図である。 図９は、モード情報９００の記憶内容の一例を示す説明図である。 図１０は、エラーコードテーブル１０００の記憶内容の一例を示す説明図である。 図１１は、カウンタテーブル１１００の記憶内容の一例を示す説明図である。 図１２は、アクセスログ情報１２００の記憶内容の一例を示す説明図である。 図１３は、テスト装置１００の機能的構成例を示すブロック図である。 図１４は、要件１を示す説明図である。 図１５は、要件２を示す説明図である。 図１６は、テストシステム２００の動作例１の流れを示す説明図である。 図１７は、テストシステム２００の動作例１の一例を示す説明図である。 図１８は、テストシステム２００の動作例２の一例を示す説明図である。 図１９は、テストシステム２００の動作例３の一例を示す説明図である。 図２０は、テストシステム２００の動作例４の一例を示す説明図（その１）である。 図２１は、テストシステム２００の動作例４の一例を示す説明図（その２）である。 図２２は、テストシステム２００の動作例５の一例を示す説明図（その１）である。 図２３は、テストシステム２００の動作例５の一例を示す説明図（その２）である。 図２４は、監視処理手順の一例を示すフローチャートである。 図２５は、割込処理手順の一例を示すフローチャートである。 図２６は、送信処理手順の一例を示すフローチャート（その１）である。 図２７は、送信処理手順の一例を示すフローチャート（その２）である。 図２８は、シミュレーション処理手順の一例を示すフローチャートである。 図２９は、受信処理手順の一例を示すフローチャート（その１）である。 図３０は、受信処理手順の一例を示すフローチャート（その２）である。 図３１は、設定処理手順の一例を示すフローチャートである。 図３２は、応答処理手順の一例を示すフローチャートである。

以下に、図面を参照して、本発明にかかるテストプログラム、テスト方法、およびテスト装置の実施の形態を詳細に説明する。

（実施の形態にかかるテスト方法の一実施例）
図１は、実施の形態にかかるテスト方法の一実施例を示す説明図である。テスト装置１００は、所定のシステムを運用するノードを切り替える切替処理を行う、テスト対象のソフトウェアをテストするコンピュータである。システムは、例えば、システムを運用するノードが冗長化され、複数のノードを含む。ノードは、例えば、情報処理装置である。以下の説明では、ソフトウェアを「クラスタソフトウェア」と表記する場合がある。

ここで、クラスタソフトウェアについてテストすることが望まれる。例えば、クラスタソフトウェアが、切替処理の結果が正常であるか否かをテストすることが望まれる。また、例えば、クラスタソフトウェアは、切替処理を行った結果、切替処理の結果がエラーである場合、切替処理を再び試行することが好ましい。このため、クラスタソフトウェアが、切替処理を行った結果、切替処理の結果がエラーである場合、切替処理を再び試行することができるか否かをテストすることが望まれる。

また、例えば、クラスタソフトウェアは、切替処理を再び試行する際、切替処理に用いられる通信経路などを変更することが好ましい。このため、クラスタソフトウェアが、切替処理を再び試行する際、切替処理に用いられる通信経路などを変更することができるか否かをテストすることが望まれる。また、例えば、クラスタソフトウェアは、切替処理を複数回試行しても、切替処理の結果がエラーである場合、切替処理を中止することが好ましい。このため、クラスタソフトウェアが、切替処理を複数回試行しても、切替処理の結果がエラーである場合、切替処理を中止することができるか否かをテストすることが望まれる。

そして、切替処理の結果がエラーになる様々なケースがあるため、それぞれのケースにおけるクラスタソフトウェアの動作を確認し、クラスタソフトウェアについてテストすることが望まれる。例えば、切替処理の結果がエラーになる様々なケースを発生させ、それぞれのケースが発生しても、クラスタソフトウェアが、上述したように、切替処理を再び試行したり、切替処理を中止したりすることができるか否かをテストすることが望まれる。以下の説明では、切替処理の結果がエラーになるケースを「エラーケース」と表記する場合がある。

エラーケースは、例えば、切替処理に用いられる記憶リソースの不足によりエラーが発生するケースなどである。また、エラーケースは、例えば、システムを運用するノードを切り替える際に、切替元のノードに対するアクセスの失敗によりエラーが発生するケース、および、切替先のノードに対するアクセスの失敗によりエラーが発生するケースなどであってもよい。このような、クラスタソフトウェアのテストに望まれる要件については、具体的には、図１４を用いて後述する。

しかしながら、クラスタソフトウェアを精度よくテストすることは難しい。例えば、切替処理に関する様々なエラーケースを発生させることは難しく、切替処理に関する様々なエラーケースを発生させ、様々なエラーケースにおけるクラスタソフトウェアの動作を確認することができず、クラスタソフトウェアを精度よくテストすることができない。

例えば、システムに含まれるノードの動作の結果が異常になるように、システムに含まれるノードを設定してから、クラスタソフトウェアが切替処理を行うように制御することにより、クラスタソフトウェアをテストする場合が考えられる。しかしながら、この場合、切替処理より前にクラスタソフトウェアが行う処理でエラーが発生してしまうことがあり、切替処理に関するエラーケースを発生させることができず、クラスタソフトウェアを精度よくテストすることができないことがある。

そこで、本実施の形態では、クラスタソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたと判定したタイミングで、切替処理の結果をエラーにする制御を行うことができるテスト方法について説明する。これによれば、テスト方法は、切替処理より前にクラスタソフトウェアが行う処理でエラーが発生することを防止し、切替処理に関する様々なエラーケースを発生させ、クラスタソフトウェアのテストの精度向上を図ることができる。

図１の例では、テスト装置１００は、テスト対象のソフトウェア１０１を含む。ソフトウェア１０１は、例えば、クラスタソフトウェアである。ソフトウェア１０１は、情報処理装置を待機状態と運用状態とに切り替えることができ、システムを運用する情報処理装置を切り替える切替処理を行うことができるソフトウェアである。

以下の説明では、説明の簡略化のため、ソフトウェアを実行するコンピュータが、ソフトウェアの実行により何らかの処理を実行することを、単に「ソフトウェアが処理を行う」または「ソフトウェアが（処理の内容を）する」というように表記する場合がある。

ソフトウェア１０１は、例えば、待機状態である第１の情報処理装置１１０と、運用状態である第２の情報処理装置（不図示）とがある場合、第２の情報処理装置に障害があると判定したことに応じて、切替処理を行う。ソフトウェア１０１は、切替処理において、第１の情報処理装置１１０を待機状態から運用状態に切り替える一方で、第２の情報処理装置を運用状態から待機状態に切り替える。

テスト装置１００は、ソフトウェア１０１が第１の情報処理装置１１０を待機状態から運用状態に切り替える切替処理を開始したか否かを判定する。これにより、テスト装置１００は、切替処理の結果をエラーにする制御を行うことができ、切替処理に関するエラーケースを発生させることができるタイミングを特定することができる。

テスト装置１００は、ソフトウェア１０１の実行により切替処理が開始されたと判定したことに応じて、切替処理の結果をエラーにする処理を実行する。これにより、テスト装置１００は、切替処理より前にソフトウェア１０１が行う処理ではエラーを発生させず、切替処理に関するエラーケースを発生させることができ、ソフトウェア１０１のテストの精度向上を図ることができる。

ここで、ソフトウェア１０１は、具体的には、第２の情報処理装置に向けて応答要求を出力し、第２の情報処理装置からの応答を監視することにより、第２の情報処理装置の障害発生を監視する。障害は、例えば、ハングとも呼ばれる。

応答要求は、例えば、ｐｉｎｇである。ｐｉｎｇに対する応答は、例えば、ハートビート応答と呼ばれる。ｐｉｎｇに対して特定の時間待ってもハートビート応答がないという事象が、運用系２２０に障害が発生したことを示す。ハートビート応答がないという事象は、例えば、ハートビート断と呼ばれる。そして、ソフトウェア１０１は、第２の情報処理装置の障害発生に応じて切替処理を開始するように設計される傾向がある。

この傾向を利用し、テスト装置１００は、具体的には、ソフトウェア１０１が第２の情報処理装置に向けて出力する応答要求を参照することにより、第１の情報処理装置１１０を待機状態から運用状態に切り替える切替処理を開始したか否かを判定してもよい。これにより、テスト装置１００は、ソフトウェア１０１を改変しなくても、切替処理を開始したか否かを判定することができる。このため、テスト装置１００は、ソフトウェア１０１の性能や動作に与える影響を抑制して、ソフトウェア１０１をテストすることができ、ソフトウェア１０１のテストの精度向上を図ることができる。

また、ソフトウェア１０１は、切替処理に関する様々なエラーケースが発生し、第２の情報処理装置に障害があると判定したにも関わらず、第２の情報処理装置に対してアクセスしてしまうことがある。例えば、ソフトウェア１０１は、切替処理とともに切替処理とは異なる処理を行っている場合があり、切替処理とは異なる処理で第２の情報処理装置に対してアクセスしてしまう。また、例えば、ソフトウェア１０１は、ソフトウェア１０１の設計者が意図しないバグにより、第２の情報処理装置に対してアクセスしてしまう。この際、第２の情報処理装置に対するアクセスの結果は、正常である場合と異常である場合との両方があり、いずれの場合においても、ソフトウェア１０１は、ソフトウェア１０１の設計者が想定する動作を行うことが望まれる。

このため、ソフトウェア１０１が第２の情報処理装置に対してアクセスする場合についても、ソフトウェア１０１をテストすることが望まれる。例えば、第２の情報処理装置に対するアクセスの結果が、正常である場合と異常である場合との両方について、ソフトウェア１０１をテストすることが望まれる。このような、ソフトウェア１０１のテストに望まれる新たな要件については、具体的には、図１５を用いて後述する。

これに対し、テスト装置１００は、第２の情報処理装置に対するアクセスの結果が、正常である場合と、異常である場合とが発生するように、第２の情報処理装置を制御するようにしてもよい。これにより、テスト装置１００は、ソフトウェア１０１が第２の情報処理装置にアクセスする場合について、ソフトウェア１０１をテストすることができる。テスト装置１００は、例えば、ソフトウェア１０１から第２の情報処理装置に対するアクセスの結果が、正常である場合と、異常である場合との両方について、ソフトウェア１０１をテストすることができ、ソフトウェア１０１のテストの精度向上を図ることができる。

（テストシステム２００の一例）
次に、図２を用いて、図１に示したテスト装置１００を適用した、テストシステム２００の一例について説明する。

図２は、テストシステム２００の一例を示す説明図である。図２において、テストシステム２００は、テスト装置１００と、複数の情報処理装置２１０，２２０と、端末装置２０１とを含む。

テストシステム２００において、テスト装置１００と情報処理装置２１０，２２０と、端末装置２０１とは、有線または無線のネットワーク２３０を介して接続される。ネットワーク２３０は、例えば、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどである。

テスト装置１００は、テストシステム２００を運用する情報処理装置を切り替える切替処理を行うテスト対象のソフトウェアを有し、テスト対象のソフトウェアをテストするコンピュータである。テスト対象のソフトウェアは、例えば、クラスタソフトウェアである。テスト装置１００は、例えば、サーバ、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などである。

複数の情報処理装置２１０，２２０は、それぞれ、テストシステム２００を運用可能なコンピュータである。複数の情報処理装置２１０，２２０は、通常時にはテストシステム２００を運用しない待機状態である情報処理装置２１０と、通常時にテストシステム２００を運用する運用状態である情報処理装置２２０とを含む。通常時に待機状態である情報処理装置２１０は、通常時に運用状態である情報処理装置２２０に障害がある場合に、待機状態から運用状態に切り替えられ、テストシステム２００を運用する。情報処理装置２１０，２２０は、例えば、サーバ、ＰＣなどである。

端末装置２０１は、テスト対象のソフトウェアのテストを実施するユーザの操作入力に基づいて、テスト装置１００と、複数の情報処理装置２１０，２２０とに、テスト対象のソフトウェアのテスト開始指示を送信する。以下の説明では、テスト対象のソフトウェアのテストを実施するユーザを「テスター」と表記する場合がある。端末装置２０１は、例えば、サーバ、ＰＣ、タブレット端末、スマートフォン、ウェアラブル端末などである。

また、テスト装置１００は、通常時には待機状態である情報処理装置２１０としても動作可能である場合があってもよい。また、テストシステム２００は、通常時には待機状態である情報処理装置２１０を２以上含んでもよい。以下の説明では、通常時には待機状態である情報処理装置２１０を「待機系２１０」と表記する場合がある。また、以下の説明では、通常時に運用状態である情報処理装置２２０を「運用系２２０」と表記する場合がある。

（テストシステム２００の具体例）
次に、図３を用いて、図２に示したテストシステム２００の具体例について説明する。

図３は、テストシステム２００の具体例を示す説明図である。図３において、テスト装置１００は、受付プログラム３１０と、ネットワークドライバ３１１と、ネットワークドライバ３１２と、ネットワークドライバ３１３と、ディスクドライバ３１４と、テスト対象のソフトウェア３１５とを含む。テスト装置１００は、待機系２１０としても動作可能である。

待機系２１０は、受付プログラム３２０と、ネットワークドライバ３２１と、ネットワークドライバ３２２と、ディスクドライバ３２３と、テスト対象のソフトウェア３２４とを含む。運用系２２０は、受付プログラム３３０と、ネットワークドライバ３３１と、ネットワークドライバ３３２とを含む。

また、テストシステム２００は、さらに、待機系２１０外に、待機系２１０に関する情報を記憶するシステムディスクを含んでいる場合があってもよい。また、テストシステム２００は、さらに、運用系２２０外に、運用系２２０に関する情報を記憶するシステムディスクを含んでいる場合があってもよい。また、テストシステム２００は、さらに、テスト装置１００、待機系２１０、運用系２２０からアクセス可能な、共用ディスクを含んでいる場合があってもよい。

（テスト装置１００のハードウェア構成例）
次に、図４を用いて、図１に示したテスト装置１００のハードウェア構成例について説明する。

図４は、テスト装置１００のハードウェア構成例を示すブロック図である。図４において、テスト装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０１と、メモリ４０２と、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）４０３と、記録媒体Ｉ／Ｆ４０４と、記録媒体４０５とを有する。また、各構成部は、バス４００によってそれぞれ接続される。

ここで、ＣＰＵ４０１は、テスト装置１００の全体の制御を司る。メモリ４０２は、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、例えば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ４０１のワークエリアとして使用される。メモリ４０２に記憶されるプログラムは、ＣＰＵ４０１にロードされることで、コーディングされている処理をＣＰＵ４０１に実行させる。

ネットワークＩ／Ｆ４０３は、通信回線を通じてネットワーク２３０に接続され、ネットワーク２３０を介して他のコンピュータに接続される。そして、ネットワークＩ／Ｆ４０３は、ネットワーク２３０と内部のインターフェースを司り、他のコンピュータからのデータの入出力を制御する。ネットワークＩ／Ｆ４０３には、例えば、モデムやＬＡＮアダプタなどを採用することができる。

記録媒体Ｉ／Ｆ４０４は、ＣＰＵ４０１の制御に従って記録媒体４０５に対するデータのリード／ライトを制御する。記録媒体Ｉ／Ｆ４０４は、例えば、ディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポートなどである。記録媒体４０５は、記録媒体Ｉ／Ｆ４０４の制御で書き込まれたデータを記憶する不揮発メモリである。記録媒体４０５は、例えば、ディスク、半導体メモリ、ＵＳＢメモリなどである。記録媒体４０５は、テスト装置１００から着脱可能であってもよい。

テスト装置１００は、上述した構成部のほか、例えば、キーボード、マウス、ディスプレイ、プリンタ、スキャナ、マイク、スピーカーなどを有してもよい。また、テスト装置１００は、記録媒体Ｉ／Ｆ４０４や記録媒体４０５を複数有していてもよい。また、テスト装置１００は、記録媒体Ｉ／Ｆ４０４や記録媒体４０５を有していなくてもよい。

（待機系２１０のハードウェア構成例および運用系２２０のハードウェア構成例）
待機系２１０のハードウェア構成例および運用系２２０のハードウェア構成例は、図４に示したテスト装置１００のハードウェア構成例と同様であるため、説明を省略する。

（ステータステーブル５００の記憶内容）
次に、図５を用いて、テスト装置１００によって記憶される、ステータステーブル５００の記憶内容について説明する。ステータステーブル５００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。

図５は、ステータステーブル５００の記憶内容の一例を示す説明図である。図５に示すように、ステータステーブル５００は、クラスタと、ＩＰアドレスと、時刻とのフィールドを有する。ステータステーブル５００は、ｐｉｎｇ送信依頼の依頼元ごとに各フィールドに情報を設定することにより、ステータス情報がレコードとして記憶される。

クラスタのフィールドには、ｐｉｎｇ送信依頼の依頼元のプロセスであるクラスタソフトウェアを識別する情報が設定される。ＩＰアドレスのフィールドには、ｐｉｎｇ送信依頼が示すｐｉｎｇの相手先のＩＰアドレスが設定される。時刻のフィールドには、ｐｉｎｇ送信依頼を受け付ける都度、ｐｉｎｇ送信依頼を受け付けた時刻が設定され、ｐｉｎｇ送信依頼を受け付けた時刻が蓄積される。

（送信側フラグテーブル６００の記憶内容）
次に、図６を用いて、テスト装置１００、待機系２１０、および、運用系２２０によって記憶される、送信側フラグテーブル６００の記憶内容について説明する。送信側フラグテーブル６００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。送信側フラグテーブル６００は、例えば、待機系２１０や運用系２２０の記憶領域により実現されてもよい。

図６は、送信側フラグテーブル６００の記憶内容の一例を示す説明図である。図６に示すように、送信側フラグテーブル６００は、テスト準備中フラグと、ｐｉｎｇ受付待ちフラグと、エラーフラグと、正常復帰フラグとのフィールドを有する。送信側フラグテーブル６００は、各フィールドに情報を設定することにより、フラグ情報がレコードとして記憶される。

テスト準備中フラグのフィールドには、最初にＯＦＦが設定され、テスト対象のソフトウェアから初回のｐｉｎｇ送信依頼を受け付けるとＯＮが設定され、タイマーがタイムアウトするとＯＦＦが設定される。このため、テスト準備中フラグは、ｐｉｎｇ送信依頼が無応答になり始めた状態を示す。ｐｉｎｇ受付待ちフラグのフィールドには、最初にＯＦＦが設定され、テスト対象のソフトウェアから２回目のｐｉｎｇ送信依頼を受け付けるとＯＮが設定され、タイマーがタイムアウトするとＯＦＦが設定される。

エラーフラグのフィールドには、最初にＯＦＦが設定され、タイマーがタイムアウトし、クラスタソフトウェアが切替処理を開始したと判定するとＯＮが設定される。このため、エラーフラグは、クラスタソフトウェアがｐｉｎｇの相手先がハングであると判定している状態を示す。正常復帰フラグのフィールドには、クラスタソフトウェアからのアクセス要求の結果を正常にする制御を行うか否かを示すフラグが設定される。

送信側フラグテーブル６００は、複数のデバイスドライバから共通して参照可能であってもよい。デバイスドライバは、ネットワークドライバやディスクドライバである。

（受信側フラグテーブル７００の記憶内容）
次に、図７を用いて、テスト装置１００、待機系２１０、および、運用系２２０によって記憶される、受信側フラグテーブル７００の記憶内容について説明する。受信側フラグテーブル７００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。受信側フラグテーブル７００は、例えば、待機系２１０や運用系２２０の記憶領域により実現されてもよい。

図７は、受信側フラグテーブル７００の記憶内容の一例を示す説明図である。図７に示すように、受信側フラグテーブル７００は、テスト準備中フラグと、ｐｉｎｇ受付待ちフラグと、エラーフラグと、正常復帰フラグとのフィールドを有する。受信側フラグテーブル７００は、各フィールドに情報を設定することにより、フラグ情報がレコードとして記憶される。

テスト準備中フラグのフィールドには、送信側フラグテーブル６００のテスト準備中フラグのフィールドに設定されたフラグと同じフラグが設定される。ｐｉｎｇ受付待ちフラグのフィールドには、送信側フラグテーブル６００のｐｉｎｇ受付待ちフラグのフィールドに設定されたフラグと同じフラグが設定される。

エラーフラグのフィールドには、送信側フラグテーブル６００のエラーフラグのフィールドに設定されたフラグと同じフラグが設定される。正常復帰フラグのフィールドには、送信側フラグテーブル６００の正常復帰フラグのフィールドに設定されたフラグと同じフラグが設定される。

受信側フラグテーブル７００は、複数のデバイスドライバから共通して参照可能であってもよい。デバイスドライバは、ネットワークドライバやディスクドライバである。

（作業域８００の記憶内容）
次に、図８を用いて、テスト装置１００によって記憶される、作業域８００の記憶内容について説明する。作業域８００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。

図８は、作業域８００の記憶内容の一例を示す説明図である。図８に示すように、作業域８００は、ｐｉｎｇ間隔＝Ｔのフィールドを有する。作業域８００は、フィールドに情報を設定することにより、ｐｉｎｇ間隔がレコードとして記憶される。ｐｉｎｇ間隔のフィールドには、連続する２つのｐｉｎｇ送信依頼をテスト装置１００が受け付けた時点の間隔が設定される。

（モード情報９００の記憶内容）
次に、図９を用いて、テスト装置１００、待機系２１０、および、運用系２２０によって記憶される、モード情報９００の記憶内容について説明する。モード情報９００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。モード情報９００は、例えば、待機系２１０や運用系２２０の記憶領域により実現されてもよい。

図９は、モード情報９００の記憶内容の一例を示す説明図である。図９に示すように、モード情報９００は、モードフラグのフィールドを有する。モード情報９００は、フィールドに情報を設定することにより、モード情報９００がレコードとして記憶される。モードフラグのフィールドには、自装置のモードが特殊テストモードであるか否かを示すフラグが設定される。

（エラーコードテーブル１０００の記憶内容）
次に、図１０を用いて、テスト装置１００、待機系２１０、および、運用系２２０によって記憶される、エラーコードテーブル１０００の記憶内容について説明する。エラーコードテーブル１０００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。エラーコードテーブル１０００は、例えば、待機系２１０や運用系２２０の記憶領域により実現されてもよい。

図１０は、エラーコードテーブル１０００の記憶内容の一例を示す説明図である。図１０に示すように、エラーコードテーブル１０００は、デバイス番号と、エラーコードと、デバイス名称とのフィールドを有する。エラーコードテーブル１０００は、各フィールドに情報を設定することにより、エラーコード情報がレコードとして記憶される。

デバイス番号のフィールドには、デバイスを識別するデバイス番号が設定される。エラーコードのフィールドには、デバイス番号によって識別されるデバイスが出力するエラーコードが設定される。デバイス名称のフィールドには、デバイス番号によって識別されるデバイスの名称が設定される。

（カウンタテーブル１１００の記憶内容）
次に、図１１を用いて、テスト装置１００、待機系２１０、および、運用系２２０によって記憶される、カウンタテーブル１１００の記憶内容について説明する。カウンタテーブル１１００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。カウンタテーブル１１００は、例えば、待機系２１０や運用系２２０の記憶領域により実現されてもよい。

図１１は、カウンタテーブル１１００の記憶内容の一例を示す説明図である。図１１に示すように、カウンタテーブル１１００は、アクセスカウンタ（ハートビート断前）と、アクセスカウンタ（ハートビート断後）とのフィールドを有する。カウンタテーブル１１００は、各フィールドに情報を設定することにより、カウンタ情報がレコードとして記憶される。

アクセスカウンタ（ハートビート断前）のフィールドには、クラスタソフトウェアが切替処理を開始したとテスト装置１００が判定する前における、クラスタソフトウェアから自装置に対するアクセス回数が設定される。アクセスカウンタ（ハートビート断後）のフィールドには、クラスタソフトウェアが切替処理を開始したとテスト装置１００が判定した後における、クラスタソフトウェアから自装置に対するアクセス回数が設定される。

（アクセスログ情報１２００の記憶内容）
次に、図１２を用いて、テスト装置１００、待機系２１０、および、運用系２２０によって記憶される、アクセスログ情報１２００の記憶内容について説明する。アクセスログ情報１２００は、例えば、図４に示したテスト装置１００のメモリ４０２や記録媒体４０５などの記憶領域により実現される。アクセスログ情報１２００は、例えば、待機系２１０や運用系２２０の記憶領域により実現されてもよい。

図１２は、アクセスログ情報１２００の記憶内容の一例を示す説明図である。図１２に示すように、アクセスログ情報１２００は、アクセス記憶域（ハートビート断前）と、アクセス記憶域（ハートビート断後）とのフィールドを有する。アクセスログ情報１２００は、各フィールドに情報を設定することにより、アクセス内容がレコードとして記憶される。

アクセス記憶域（ハートビート断前）のフィールドは、アクセスカウンタ（ハートビート断前）と、ポートＮｏと、アクセス内容とのフィールドを有する。アクセスカウンタ（ハートビート断前）のフィールドには、アクセスカウンタ（ハートビート断前）が設定される。ポートＮｏのフィールドには、クラスタソフトウェアから自装置に対するアクセスに用いられたポートを識別するポートＮｏが設定される。アクセス内容のフィールドには、クラスタソフトウェアから自装置に対するアクセスの内容が設定される。

アクセス記憶域（ハートビート断後）のフィールドは、アクセスカウンタ（ハートビート断後）と、ポートＮｏと、アクセス内容とのフィールドを有する。アクセスカウンタ（ハートビート断後）のフィールドには、アクセスカウンタ（ハートビート断後）が設定される。ポートＮｏのフィールドには、クラスタソフトウェアから自装置に対するアクセスに用いられたポートを識別するポートＮｏが設定される。アクセス内容のフィールドには、クラスタソフトウェアから自装置に対するアクセスの内容が設定される。

（テスト装置１００の機能的構成例）
次に、図１３を用いて、テスト装置１００の機能的構成例について説明する。

図１３は、テスト装置１００の機能的構成例を示すブロック図である。テスト装置１００は、記憶部１３００と、取得部１３０１と、判定部１３０２と、管理部１３０３と、出力部１３０４とを含む。

記憶部１３００は、例えば、図４に示したメモリ４０２や記録媒体４０５などの記憶領域によって実現される。以下では、記憶部１３００が、テスト装置１００に含まれる場合について説明するが、これに限らない。例えば、記憶部１３００が、テスト装置１００とは異なる装置に含まれ、記憶部１３００の記憶内容がテスト装置１００から参照可能である場合があってもよい。

取得部１３０１〜出力部１３０４は、制御部となる機能である。取得部１３０１〜出力部１３０４は、具体的には、例えば、図４に示したメモリ４０２や記録媒体４０５などの記憶領域に記憶されたプログラムをＣＰＵ４０１に実行させることにより、または、ネットワークＩ／Ｆ４０３により、その機能を実現する。各機能部の処理結果は、例えば、図４に示したメモリ４０２や記録媒体４０５などの記憶領域に記憶される。

記憶部１３００は、各機能部の処理に用いられる各種情報を記憶する。記憶部１３００は、例えば、図５〜図１２に示した各種テーブルを記憶する。これにより、記憶部１３００は、各機能部の処理に用いられる各種情報を、各機能部が参照可能にすることができる。

取得部１３０１は、各機能部の処理に用いられる各種情報を記憶部１３００から取得し、各機能部に出力する。これにより、取得部１３０１は、各機能部の処理に用いられる各種情報を、各機能部に提供することができる。

取得部１３０１は、テストシステム２００に含まれる第１の情報処理装置と第２の情報処理装置とのうち、第２の情報処理装置に向けてテスト対象のソフトウェアが特定の間隔で出力する応答要求を取得する。ソフトウェアは、例えば、クラスタソフトウェアである。第１の情報処理装置は、通常時には待機状態である情報処理装置であり、例えば、待機系２１０、または、待機系２１０として動作可能であるテスト装置１００である。第２の情報処理装置は、待機系２１０が運用状態に切り替わる前、通常時には運用状態である情報処理装置であり、例えば、運用系２２０である。応答要求は、例えば、ｐｉｎｇ送信依頼である。

取得部１３０１は、例えば、ネットワークドライバにより、クラスタソフトウェアが出力するｐｉｎｇ送信依頼を取得する。これにより、取得部１３０１は、クラスタソフトウェアが切替処理を開始したか否かを判定する際に用いられる情報を取得し、判定部１３０２に提供することができる。切替処理は、待機系２１０を待機状態から運用状態に切り替える処理を含み、テストシステム２００を運用する情報処理装置を、運用系２２０から待機系２１０に切り替える処理である。

取得部１３０１は、運用系２２０に向けてクラスタソフトウェアが出力するアクセス要求を取得する。取得部１３０１は、例えば、ネットワークドライバにより、クラスタソフトウェアが出力するアクセス要求を取得する。これにより、取得部１３０１は、クラスタソフトウェアが出力したアクセス要求の結果が正常または異常になるように、管理部１３０３が制御可能にすることができる。

判定部１３０２は、クラスタソフトウェアの実行により切替処理が開始されたか否かを判定する。判定部１３０２は、運用系２２０に向けて、クラスタソフトウェアの実行により、特定の間隔で出力されるｐｉｎｇ送信依頼に基づいて、切替処理が開始されたか否かを判定する。これにより、判定部１３０２は、クラスタソフトウェアを改変しなくても、切替処理が開始されたか否かを判定することができ、クラスタソフトウェアの性能や動作に与える影響を抑制することができる。

判定部１３０２は、例えば、ｐｉｎｇ送信依頼に対して運用系２２０を無応答にする。そして、判定部１３０２は、運用系２２０を無応答にした後、クラスタソフトウェアがｐｉｎｇ送信依頼を出力してから、次のｐｉｎｇ送信依頼を出力せずに特定の時間が経過した場合、切替処理が開始されたと判定する。特定の時間は、クラスタソフトウェアがｐｉｎｇ送信依頼を出力するｐｉｎｇ間隔に応じた時間である。

これにより、判定部１３０２は、クラスタソフトウェアが、次のｐｉｎｇ送信依頼を出力せずに特定の時間が経過したため、ｐｉｎｇ送信依頼の出力を中止したと判断され、切替処理を開始したと判断されるタイミングを特定することができる。このため、判定部１３０２は、切替処理を開始したか否かを精度よく判定することができる。

ここで、判定部１３０２は、具体的には、自装置のネットワークドライバ、または、運用系２２０のネットワークドライバに、ｐｉｎｇ送信依頼の結果が異常になるように設定することにより、ｐｉｎｇ送信依頼に対して運用系２２０が無応答になるように制御する。

ここで、判定部１３０２は、クラスタソフトウェアがｐｉｎｇ送信依頼を出力してから、次のｐｉｎｇ送信依頼を出力するまでの時間を計測し、計測した時間を特定の時間に設定してもよい。これにより、判定部１３０２は、クラスタソフトウェアのｐｉｎｇ間隔を自動で特定して、特定の時間に設定することができる。

このため、判定部１３０２は、テスターがクラスタソフトウェアのｐｉｎｇ間隔を特定することができなくても、特定の時間を精度よく設定することができる。結果として、判定部１３０２は、クラスタソフトウェアが切替処理を開始したか否かを精度よく判定することができる。

また、運用系２２０がクラスタソフトウェアに向けて特定の間隔で信号を送信し、クラスタソフトウェアが、運用系２２０からの信号の出力が途絶えたことに応じて、運用系２２０の故障発生を監視する場合があってもよい。この場合、判定部１３０２は、運用系２２０が特定の間隔で出力する信号に基づいて、切替処理を開始したか否かを判定してもよい。

管理部１３０３は、判定部１３０２が切替処理が開始されたと判定したことに応じて、切替処理の結果をエラーにする制御を行う。管理部１３０３は、例えば、自装置のネットワークドライバやディスクドライバなどが、切替処理に関する処理の結果を異常にするように設定することにより、切替処理の結果がエラーになるように制御する。

管理部１３０３は、具体的には、図１６および図１７に後述する動作例１を実現する。これにより、管理部１３０３は、自装置のネットワークドライバやディスクドライバなどが原因である、切替処理に関するエラーケースを発生させることができる。結果として、管理部１３０３は、切替処理に関するエラーケースを発生させた場合について、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

管理部１３０３は、判定部１３０２が切替処理が開始されたと判定したことを、運用系２２０に通知することにより、切替処理に関する運用系２２０の動作の結果を異常にする制御を行うことにより、切替処理の結果をエラーにする。管理部１３０３は、例えば、運用系２２０のネットワークドライバやディスクドライバなどが、切替処理に関する処理の結果を異常にするように、運用系２２０に設定させることにより、切替処理の結果をエラーにする。

管理部１３０３は、具体的には、図１８に後述する動作例２を実現する。これにより、管理部１３０３は、運用系２２０のネットワークドライバやディスクドライバなどが原因である、切替処理に関するエラーケースを発生させることができる。結果として、管理部１３０３は、切替処理に関するエラーケースを発生させた場合について、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

管理部１３０３は、切替処理が開始されたと判定したことを、待機系２１０に通知することにより、切替処理に関する待機系２１０の動作の結果を異常にする制御を行うことにより、切替処理の結果をエラーにする。管理部１３０３は、例えば、自装置が待機系２１０ではない場合、待機系２１０のネットワークドライバやディスクドライバなどが、切替処理に関する処理の結果を異常にするように、待機系２１０に設定させることにより、切替処理の結果をエラーにする。

管理部１３０３は、具体的には、図１９に後述する動作例３を実現する。これにより、管理部１３０３は、待機系２１０のネットワークドライバやディスクドライバなどが原因である、切替処理に関するエラーケースを発生させることができる。結果として、管理部１３０３は、切替処理に関するエラーケースを発生させた場合について、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

管理部１３０３は、クラスタソフトウェアから待機系２１０または運用系２２０に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けたアクセス要求に応じた動作を行う。一定の時間は、例えば、テスターによって設定される。これにより、管理部１３０３は、切替処理が開始されたと判定してから、切替処理に関する待機系２１０または運用系２２０の動作の結果を異常にする制御を行うまでに、一定の時間がかかっても、クラスタソフトウェアを精度よくテストすることができる。

例えば、クラスタソフトウェアが切替処理を開始した後、アクセス要求を出力した時点では、まだ切替処理に関する待機系２１０または運用系２２０の動作の結果を異常にする制御が完了していないことがある。これに対し、テスト装置１００は、アクセス要求に応じた動作を一定の時間保留するため、切替処理に関する待機系２１０または運用系２２０の動作の結果を異常にする制御が完了してから、アクセス要求に応じた動作を行うことができる。

管理部１３０３は、運用系２２０を無応答にした後に、待機系２１０または運用系２２０に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けたアクセス要求に応じた動作を行う。管理部１３０３は、例えば、ｐｉｎｇ送信依頼に対して運用系２２０が無応答になるように制御した後に、待機系２１０または運用系２２０に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けたアクセス要求に応じた動作を行う。これにより、管理部１３０３は、運用系２２０を無応答にする前のアクセス要求に応じた動作を開始するタイミングが遅れてしまうことを防止することができる。

管理部１３０３は、運用系２２０を無応答にした後、クラスタソフトウェアから運用系２２０に対するアクセス要求を複数受け付けた場合、複数のアクセス要求のうち、第１のアクセス要求の結果を異常にする制御を行う。また、管理部１３０３は、運用系２２０を無応答にした後、クラスタソフトウェアから運用系２２０に対するアクセス要求を複数受け付けた場合、複数のアクセス要求のうち、第２のアクセス要求の結果を正常にする制御を行う。

管理部１３０３は、例えば、運用系２２０を無応答にしたことを、運用系２２０に通知することにより、アクセス要求に関する運用系２２０の動作の結果を、正常にしたり、異常にしたりする制御を行う。管理部１３０３は、例えば、通知により、運用系２２０のネットワークドライバやディスクドライバなどが、第１のアクセス要求に応じた動作の結果を異常にし、第２のアクセス要求に応じた動作の結果を正常にするように、運用系２２０に設定させる。

管理部１３０３は、具体的には、図２０および図２１に後述する動作例４を実現する。これにより、管理部１３０３は、クラスタソフトウェアから運用系２２０に対するアクセスの結果が、正常である場合と、異常である場合との両方について、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

管理部１３０３は、クラスタソフトウェアから運用系２２０に対するアクセス要求を受け付けた場合、受け付けたアクセス要求に関する対応情報を記憶する制御を行う。対応情報は、アクセス要求に関する情報と、アクセス要求を受け付けた時点が、切替処理が開始されたと判定した時点の前後のいずれかに関する情報とを対応付けた情報である。アクセス要求に関する情報は、例えば、アクセスされる記憶内容である。

管理部１３０３は、例えば、運用系２２０を無応答にしたことを、運用系２２０に通知し、切替処理が開始されたと判定したことを、運用系２２０に通知することにより、運用系２２０に対応情報を記憶させる制御を行う。管理部１３０３は、具体的には、図２２および図２３に後述する動作例５を実現する。これにより、管理部１３０３は、アクセス要求が、切替処理が開始した時点の前後のいずれに出力されたアクセス要求かを特定可能なように、アクセス要求に関する情報を記憶しておき、クラスタソフトウェアのテストに利用可能にすることができる。

管理部１３０３は、クラスタソフトウェアの動作を確認し、クラスタソフトウェアをテストする。管理部１３０３は、上述したように、切替処理に関するエラーケースを発生させつつ、クラスタソフトウェアをテストする。これにより、管理部１３０３は、クラスタソフトウェアが、クラスタソフトウェアの設計者が想定する動作を行っているかを判定することができる。

出力部１３０４は、管理部１３０３がクラスタソフトウェアをテストした結果を出力する。出力部１３０４は、各機能部の処理結果を出力する。出力形式は、例えば、ディスプレイへの表示、プリンタへの印刷出力、ネットワークＩ／Ｆ４０３による外部装置への送信、または、メモリ４０２や記録媒体４０５などの記憶領域への記憶である。これにより、出力部１３０４は、各機能部の処理結果を利用者に通知可能にし、テスト装置１００の管理や運用、例えば、テスト装置１００の設定値の更新などを支援することができ、テスト装置１００の利便性の向上を図ることができる。

（テストシステム２００の動作例）
次に、図１４〜図２３を用いて、クラスタソフトウェアのテストに望まれる要件１、および、要件２について説明し、テストシステム２００の動作例１、動作例２、動作例３、動作例４、および、動作例５について説明する。まず、図１４を用いて、クラスタソフトウェアのテストに望まれる要件１について説明する。

図１４は、要件１を示す説明図である。クラスタソフトウェアのテストに求められる要件として、例えば、要件１がある。要件１は、例えば、クラスタソフトウェアが切替処理を行っている最中に、切替処理に関するエラーケースを発生させることである。

テスト装置１００は、例えば、図１４に示す切替処理の流れにおいて、切替処理に関する処理の結果が異常になるように制御することにより、切替処理に関するエラーケースを発生させる。まず、図１４に示す切替処理の流れについて説明する。

図１４に示すように、（１４−１）クラスタソフトウェア１４１１は、運用系２２０にｐｉｎｇを送信することにより、運用系２２０の障害発生を監視する。ｐｉｎｇに対する応答は、例えば、ハートビート応答と呼ばれる。運用系２２０の障害発生を監視することは、例えば、ハートビート監視と呼ばれる。障害は、例えば、ハングとも呼ばれる。ｐｉｎｇに対して特定の時間待ってもハートビート応答がないという事象が、運用系２２０に障害が発生したことを示す。ハートビート応答がないという事象は、例えば、ハートビート断と呼ばれる。

クラスタソフトウェア１４１１は、例えば、テスト装置１００のネットワークドライバ１４１２と、運用系２２０のネットワークドライバ１４２３とを介して、運用系２２０のクラスタソフトウェア１４２１にｐｉｎｇを送信する。ここでは、クラスタソフトウェア１４１１は、ハートビートがあるため、運用系２２０に障害が発生していないと判定する。

（１４−２）運用系２２０において、アプリ１４２４は、共有ディスクのユーザデータにアクセスすることがある。（１４−３）同様に、アプリ１４２４は、共有ディスクのユーザデータにアクセスすることがある。

（１４−４）クラスタソフトウェア１４１１は、運用系２２０にｐｉｎｇを送信することにより、運用系２２０の障害発生を監視する。ここでは、クラスタソフトウェア１４１１は、ハートビートがなくなったため、運用系２２０に障害が発生したと判定する。そして、クラスタソフトウェア１４１１は、切替処理を開始する。

（１４−５）クラスタソフトウェア１４１１は、ｐｉｎｇとは異なる通信経路を介して、運用系２２０を停止させる。クラスタソフトウェア１４１１は、例えば、テスト装置１００のネットワークドライバ１４１３と、運用系２２０のネットワークドライバ１４２２とを介して、運用系２２０を停止させる。

これに対し、運用系２２０を停止させる通信経路に異常があるというエラーケースを発生させ、切替処理の結果がエラーになる場合について、クラスタソフトウェア１４１１をテストすることが望まれる。例えば、運用系２２０のネットワークドライバ１４２２に異常があるというエラーケースを発生させることが望まれる。

（１４−６）クラスタソフトウェア１４１１は、待機状態を運用状態に切り替えるために、システムディスク１４０３にアクセスする。クラスタソフトウェア１４１１は、例えば、ディスクドライバ１４１５を介して、システムディスク１４０３にアクセスする。

これに対し、システムディスク１４０３へのアクセスに異常があるというエラーケースを発生させ、切替処理の結果がエラーになる場合について、クラスタソフトウェア１４１１をテストすることが望まれる。例えば、ディスクドライバ１４１５に異常があるというエラーケースを発生させることが望まれる。

（１４−７）クラスタソフトウェア１４１１は、待機状態を運用状態に切り替えるために、アプリ１４１４に状態遷移スクリプトの実行指示を送信する。

これに対し、アプリ１４１４に異常があるというエラーケースを発生させ、切替処理の結果がエラーになる場合について、クラスタソフトウェア１４１１をテストすることが望まれる。

（１４−８）アプリ１４１４は、共有ディスクのユーザデータにアクセスする。上述したように、切替処理の結果がエラーになる様々なエラーケースにおける、クラスタソフトウェア１４１１の動作を確認し、クラスタソフトウェア１４１１についてテストすることが望まれる。例えば、様々なエラーケースが発生しても、クラスタソフトウェア１４１１が、切替処理を再び試行したり、切替処理を中止したりすることができるか否かをテストすることが望まれる。

このため、要件１として、クラスタソフトウェアが切替処理を行っている最中に、切替処理に関するエラーケースを発生させることが望まれる。ここで、切替処理が開始される前に、エラーケースを発生させることは好ましくないため、切替処理が開始されたことに応じて、エラーケースを発生させることが望まれる。

次に、図１５を用いて、クラスタソフトウェアのテストに望まれる要件２について説明する。

図１５は、要件２を示す説明図である。クラスタソフトウェアのテストに求められる要件として、例えば、要件２がある。要件２は、例えば、切替処理が行われる原因になった運用系２２０に対するクラスタソフトウェアからのアクセスの結果が、正常である場合と、異常である場合とについて、クラスタソフトウェアの動作を確認することである。

ここで、図１５に示すように、（１５−１）クラスタソフトウェア１５１２は、運用系２２０にｐｉｎｇを送信することにより、運用系２２０の障害発生を監視する。

（１５−２）クラスタソフトウェア１５１２は、運用系２２０の障害発生を検知したにも関わらず、運用系２２０にある情報を取得するために、運用系２２０に対してアクセスしてしまうことがある。クラスタソフトウェア１５１２は、例えば、クラスタソフトウェア１５１２の設計者が意図しないバグにより、運用系２２０に対してアクセスしてしまうことがある。

これに対し、運用系２２０が、ｐｉｎｇには応答しないが、アクセスに対しては正常に応答するような、異常が発生する場合がある。この場合、クラスタソフトウェア１５１２は、アクセスすることが好ましくない情報についてアクセスしてしまう結果になる場合がある。

このため、要件２として、切替処理が行われる原因になった運用系２２０に対するクラスタソフトウェアからのアクセスの結果が、正常である場合と、異常である場合とについて、クラスタソフトウェアの動作を確認することが望まれる。

（テストシステム２００の動作例１）
次に、図１６および図１７を用いて、テストシステム２００の動作例１について説明する。動作例１は、要件１を満たすように、クラスタソフトウェアをテストする一例である。図１６および図１７のテストシステム２００は、例えば、図３に示したテストシステム２００である。

図１６は、テストシステム２００の動作例１の流れを示す説明図である。図１６に示すように、（１６−１）クラスタソフトウェア３１５は、ネットワークドライバ３１１を介して、ｐｉｎｇを運用系２２０のネットワークドライバ３３１に送信するが、特定の時間が経過しても無応答である。

（１６−２）クラスタソフトウェア３１５は、ネットワークドライバ３１１を介して、ｐｉｎｇを運用系２２０のネットワークドライバ３３１に再び送信するが、特定の時間が経過しても無応答である。

（１６−３）クラスタソフトウェア３１５は、ハートビート断を検知し、運用系２２０がハングであると判定し、切替処理を開始する。

（１６−４）クラスタソフトウェア３１５は、切替処理において、ネットワークドライバ３１２を介して、運用系２２０に、切替処理に関する処理を行わせようとする。

（１６−５）テスト装置１００は、切替処理に関する処理の結果が異常になるように、ネットワークドライバ３３２を制御する。

これにより、テスト装置１００は、運用系２２０が原因である切替処理に関する第１のエラーケースを発生させ、クラスタソフトウェア３１５を精度よくテストすることができる。同様に、テスト装置１００は、自装置が原因である切替処理に関する第２のエラーケースを発生させることもできる。

ここでは、テスト装置１００が待機系２１０として動作する場合について説明したが、これに限らない。例えば、テスト装置１００とは異なる待機系２１０があり、テスト装置１００が、運用系２２０がハングしたと判定したことに応じて、待機系２１０と運用系２２０とに切替指示を送信することにより、切替処理を行う場合があってもよい。

この場合、運用系２２０における切替処理に関する処理の結果がエラーになるという第３のエラーケースを発生させることが望まれる。また、待機系２１０における切替処理に関する処理の結果がエラーになるという第４のエラーケースを発生させることが望まれる。また、テスト装置１００から運用系２２０への切替指示の結果がエラーになるという第５のエラーケースを発生させることが望まれる。また、テスト装置１００から待機系２１０への切替指示の結果がエラーになるという第６のエラーケースを発生させることが望まれる。

動作例１では、テスト装置１００が待機系２１０として動作する場合であり、テスト装置１００が原因である、切替処理に関する第２のエラーケースを発生させる場合について説明する。また、動作例２では、運用系２２０が原因である、切替処理に関する第１のエラーケースを発生させる場合について説明する。一方で、テスト装置１００とは異なる待機系２１０がある場合については、動作例３を用いて説明する。ここで、図１７の説明に移行する。

図１７は、テストシステム２００の動作例１の一例を示す説明図である。図１７の例では、端末装置２０１からのテスト開始指示に応じて、ネットワークドライバ３１１が、ｐｉｎｇ送信依頼を破棄し、運用系２２０が無応答な状態をシミュレーションするように設定される。ここで、ネットワークドライバ３１１は、ｐｉｎｇ送信依頼以外の信号については、運用系２２０に送信されるようにしてもよい。

図１７に示すように、（１７−１）クラスタソフトウェア３１５は、ネットワークドライバ３１１に対して、ｐｉｎｇを運用系２２０のネットワークドライバ３３１に送信するように、ｐｉｎｇ送信依頼を出力するが、特定の時間Ｔが経過しても無応答である。

（１７−２）クラスタソフトウェア３１５は、無応答であるため、ネットワークドライバ３１１に対して、ｐｉｎｇを運用系２２０のネットワークドライバ３３１に送信するように、ｐｉｎｇ送信依頼を再び出力するが、特定の時間Ｔが経過しても無応答である。

（１７−３）クラスタソフトウェア３１５は、ハートビート断を検知し、運用系２２０がハングであると判定し、切替処理を開始する。

（１７−４）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、エラーフラグ＝ＯＮを、ネットワークドライバ３１２，３１３に送信する。エラーフラグは、例えば、ＴＣＰヘッダのリザーブ域などを用いて送信される。同様に、ネットワークドライバ３１１は、エラーフラグ＝ＯＮを、ディスクドライバ３１４に送信する。

（１７−５）クラスタソフトウェア３１５は、切替処理において、ネットワークドライバ３１２を介して、運用系２２０に切替指示を送信しようとする。

（１７−６）ネットワークドライバ３１２は、受信したエラーフラグ＝ＯＮに基づいて、切替指示を破棄し、切替処理の結果がエラーになるようなエラーケースを発生させる。

これにより、テスト装置１００は、自装置のネットワークドライバ３１２，３１３やディスクドライバ３１４などが原因である、切替処理に関するエラーケースを発生させ、クラスタソフトウェア３１５をテストすることができる。このため、テスト装置１００は、クラスタソフトウェア３１５のテストの精度向上を図ることができる。

（テストシステム２００の動作例２）
次に、図１８を用いて、テストシステム２００の動作例２について説明する。動作例２は、動作例１と同様に、要件１を満たすように、クラスタソフトウェアをテストする一例である。図１８のテストシステム２００は、例えば、図３に示したテストシステム２００である。

図１８は、テストシステム２００の動作例２の一例を示す説明図である。図１８に示す（１８−１）〜（１８−３）は、例えば、図１７に示した（１７−１）〜（１７−３）と同様であるため、説明を省略する。

（１８−４）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、エラーフラグ＝ＯＮを、運用系２２０のネットワークドライバ３３１に送信する。ここで、ネットワークドライバ３３１は、受信したエラーフラグ＝ＯＮを、ネットワークドライバ３３２に転送しておく。

（１８−５）クラスタソフトウェア３１５は、切替処理において、ネットワークドライバ３１２を介して、運用系２２０に切替指示を送信しようとする。

（１８−６）ネットワークドライバ３３２は、受信したエラーフラグ＝ＯＮに基づいて、切替指示を破棄し、切替処理の結果がエラーになるようなエラーケースを発生させる。

これにより、テスト装置１００は、運用系２２０のネットワークドライバ３３１，３３２やディスクドライバ（不図示）などが原因である、切替処理に関するエラーケースを発生させ、クラスタソフトウェア３１５をテストすることができる。このため、テスト装置１００は、クラスタソフトウェア３１５のテストの精度向上を図ることができる。

（テストシステム２００の動作例３）
次に、図１９を用いて、テストシステム２００の動作例３について説明する。動作例３は、動作例１と同様に、要件１を満たすように、クラスタソフトウェアをテストする一例である。図１９のテストシステム２００は、例えば、図３に示したテストシステム２００である。

図１９は、テストシステム２００の動作例３の一例を示す説明図である。図１９に示す（１９−１）〜（１９−３）は、例えば、図１７に示した（１７−１）〜（１７−３）と同様であるため、説明を省略する。

（１９−４）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、エラーフラグ＝ＯＮを、ネットワークドライバ３１３に送信する。

（１９−５）クラスタソフトウェア３１５は、切替処理において、ネットワークドライバ３１２を介して、運用系２２０に切替指示を送信しようとする。ネットワークドライバ３３２は、切替指示を受信し、切替指示に応じた正常な動作を行う。

（１９−６）クラスタソフトウェア３１５は、切替処理において、ネットワークドライバ３１３を介して、待機系２１０に切替指示を送信しようとする。ネットワークドライバ３１３は、切替指示にエラーフラグ＝ＯＮを付与して、待機系２１０のネットワークドライバ３２１に送信する。ネットワークドライバ３２１は、受信したエラーフラグ＝ＯＮを、ネットワークドライバ３２２やディスクドライバ３２３に転送しておく。

（１９−７）ネットワークドライバ３３２は、受信した切替指示に付与されたエラーフラグ＝ＯＮに基づいて、切替指示を破棄し、切替処理の結果がエラーになるようなエラーケースを発生させる。

これにより、テスト装置１００は、自装置以外の待機系２１０のネットワークドライバ３２１，３２２やディスクドライバ３２３などが原因である、切替処理に関するエラーケースを発生させ、クラスタソフトウェア３１５をテストすることができる。このため、テスト装置１００は、クラスタソフトウェア３１５のテストの精度向上を図ることができる。

ここでは、ネットワークドライバ３１１と、ネットワークドライバ３１３とが異なるドライバである場合について説明したが、これに限らない。例えば、ネットワークドライバ３１１が、上述したネットワークドライバ３１３としても動作する場合があってもよい。

（テストシステム２００の動作例４）
次に、図２０および図２１を用いて、テストシステム２００の動作例４について説明する。動作例４は、要件２を満たすように、クラスタソフトウェアをテストする一例である。図２０および図２１のテストシステム２００は、例えば、図３に示したテストシステム２００である。

図２０および図２１は、テストシステム２００の動作例４の一例を示す説明図である。図１０の例では、運用系２２０のシステムディスクに、モード＝特殊テストモードを含むモード情報９００と、正常復帰フラグ＝ＯＦＦを含むステータステーブル５００とが含まれる。モード＝特殊テストモードを含むモード情報９００と、正常復帰フラグ＝ＯＦＦを含むステータステーブル５００とは、例えば、テスターによって設定される。

図２０に示す（２０−１）〜（２０−３）は、例えば、図１７に示した（１７−１）〜（１７−３）と同様であるため、説明を省略する。

（２０−４）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、エラーフラグ＝ＯＮを、運用系２２０のネットワークドライバ３３１に送信する。ここで、ネットワークドライバ３３１は、受信したエラーフラグ＝ＯＮを、ネットワークドライバ３３２に転送しておく。

（２０−５）クラスタソフトウェア３１５は、切替処理とは別に、バグにより、ネットワークドライバ３１１を介して、運用系２２０にアクセスしようとする。

バグは、例えば、ハートビート断前であり、クラスタソフトウェア３１５がハングと判定する前に行われる処理で、運用系２２０に対してアクセスしてしまう不具合である。バグは、例えば、ハートビート断後であり、クラスタソフトウェア３１５がハングと判定した後に行われる処理で、運用系２２０に対してアクセスしてしまう不具合である。

（２０−６）ネットワークドライバ３３１は、受信したエラーフラグ＝ＯＮであるが、モード＝特殊テストモードであり、正常復帰フラグ＝ＯＦＦであるため、一旦、アクセスの結果を正常にすると判定する。ネットワークドライバ３３１は、アクセスの結果が正常になるように、アクセスに応じた動作を行うと、正常復帰フラグ＝ＯＮに設定し、次回のアクセスの結果が異常になるようにする。

これにより、テスト装置１００は、運用系２２０に対するアクセスの結果が正常になる場合について、クラスタソフトウェア３１５をテストすることができる。このため、テスト装置１００は、クラスタソフトウェア３１５のテストの精度向上を図ることができる。次に、図２１の説明に移行する。

図２１に示す（２１−１）〜（２１−３）は、例えば、図１７に示した（１７−１）〜（１７−３）と同様であるため、説明を省略する。

（２１−４）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、エラーフラグ＝ＯＮを、運用系２２０のネットワークドライバ３３１に送信する。ここで、ネットワークドライバ３３１は、受信したエラーフラグ＝ＯＮを、ネットワークドライバ３３２に転送しておく。

（２１−５）クラスタソフトウェア３１５は、切替処理とは別に、バグにより、ネットワークドライバ３１１を介して、運用系２２０にアクセスしようとする。

（２１−６）ネットワークドライバ３３１は、受信したエラーフラグ＝ＯＮであり、正常復帰フラグ＝ＯＮであるため、アクセスの結果を異常にすると判定する。ネットワークドライバ３３１は、アクセスの結果が異常になるように、アクセスに応じた動作を行うと、正常復帰フラグ＝ＯＦＦに設定し、次回のアクセスの結果が正常になるようにする。

これにより、テスト装置１００は、運用系２２０に対するアクセスの結果が異常になる場合について、クラスタソフトウェア３１５をテストすることができる。このため、テスト装置１００は、クラスタソフトウェア３１５のテストの精度向上を図ることができる。

（テストシステム２００の動作例５）
次に、図２２および図２３を用いて、テストシステム２００の動作例５について説明する。動作例５は、要件２を満たすように、クラスタソフトウェアをテストする一例である。図２２および図２３のテストシステム２００は、例えば、図３に示したテストシステム２００である。

図２２および図２３は、テストシステム２００の動作例５の一例を示す説明図である。上述したように、クラスタソフトウェア３１５のバグは、例えば、ハートビート断前に行われる処理で運用系２２０に対してアクセスしてしまうバグと、ハートビート断後に行われる処理で運用系２２０に対してアクセスしてしまうバグとがある。

ハートビート断前におけるバグの原因は、例えば、切替処理とは独立して動作する処理において、運用系２２０にアクセスしてしまうことである。また、ハートビート断後におけるバグの原因は、例えば、切替処理において、ハートビート監視のロジックと独立して動作するロジックが、ハートビート断にも関わらず運用系２２０にアクセスしてしまうことである。

これに対し、クラスタソフトウェア３１５のテストでは、ハートビート断前の処理においてバグがあるのか、ハートビート断後の処理においてバグがあるのかを区別可能にし、クラスタソフトウェア３１５を修正しやすくすることが望まれる。このため、動作例５では、テスト装置１００は、ハートビート断前の運用系２２０に対するアクセスと、ハートビート断後の運用系２２０に対するアクセスとを区別して、アクセスに関する情報を記憶しておく。

図２２に示すように、（２２−１）クラスタソフトウェア３１５は、ネットワークドライバ３１１に対して、ｐｉｎｇを運用系２２０のネットワークドライバ３３１に送信するように、ｐｉｎｇ送信依頼を出力するが、特定の時間Ｔが経過しても無応答である。

ここで、ネットワークドライバ３１１は、ｐｉｎｇ送信依頼に応じて、ステータステーブル５００のテスト準備中フラグ＝ＯＮに設定し、テスト準備中フラグ＝ＯＮを、運用系２２０のネットワークドライバ３３１に送信する。

図２２に示す（２２−２）は、例えば、図１７に示した（１７−２）と同様であるため、説明を省略する。

（２２−３）クラスタソフトウェア３１５は、ネットワークドライバ３１１を介して、運用系２２０にアクセスしようとする。

（２２−４）ネットワークドライバ３３１は、テスト準備中フラグ＝ＯＮ、かつ、エラーフラグ＝ＯＦＦであるため、ハートビート断前であると判定する。ネットワークドライバ３３１は、ハートビート断前のアクセスについて、アクセス内容をアクセスログ情報１２００に記憶する。

図２２に示す（２２−５）は、例えば、図１７に示した（１７−３）と同様であるため、説明を省略する。

（２２−６）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、エラーフラグ＝ＯＮを、運用系２２０のネットワークドライバ３３１に送信する。

これにより、テスト装置１００は、ハートビート断前のアクセスについて、アクセス内容をアクセスログ情報１２００に記憶しておくことができる。例えば、クラスタソフトウェア３１５がハートビート断後には運用系２２０にアクセスしないように設計されており、クラスタソフトウェア３１５が正常に動作するかをテストする場合がある。この場合、テスト装置１００は、ハートビート断前のアクセスに基づいて、クラスタソフトウェア３１５が正常に動作していないと判定してしまうことを防止することができる。

また、テスト装置１００は、テスターにアクセスログ情報１２００を参照させ、テスターがクラスタソフトウェア３１５の動作を詳細に把握可能にすることができ、クラスタソフトウェア３１５のテストの精度向上を図ることができる。テスターは、例えば、クラスタソフトウェア３１５のバグが、ハートビート断前の処理に含まれることを把握することができる。次に、図２３の説明に移行する。

図２３に示すように、（２３−１）クラスタソフトウェア３１５は、ネットワークドライバ３１１に対して、ｐｉｎｇを運用系２２０のネットワークドライバ３３１に送信するように、ｐｉｎｇ送信依頼を出力するが、特定の時間Ｔが経過しても無応答である。

ここで、ネットワークドライバ３１１は、ｐｉｎｇ送信依頼に応じて、ステータステーブル５００のテスト準備中フラグ＝ＯＮに設定し、テスト準備中フラグ＝ＯＮを、運用系２２０のネットワークドライバ３３１に送信する。

図２３に示す（２３−２）および（２３−３）は、例えば、図１７に示した（１７−２）および（１７−３）と同様であるため、説明を省略する。

（２３−４）ネットワークドライバ３１１は、ｐｉｎｇ送信依頼を受け付けた後、特定の時間Ｔが経過しても、次のｐｉｎｇ送信依頼をクラスタソフトウェア３１５が出力しない場合、切替処理が開始されたと判定する。

ネットワークドライバ３１１は、切替処理が開始されたと判定すると、ステータステーブル５００のエラーフラグ＝ＯＮに設定し、テスト準備中フラグ＝ＯＦＦに設定する。ネットワークドライバ３１１は、エラーフラグ＝ＯＮと、テスト準備中フラグ＝ＯＦＦとを、運用系２２０のネットワークドライバ３３１に送信する。

（２３−５）クラスタソフトウェア３１５は、切替処理とは別に、バグにより、ネットワークドライバ３１１を介して、運用系２２０にアクセスしようとする。

（２３−６）ネットワークドライバ３３１は、テスト準備中フラグ＝ＯＦＦ、かつ、エラーフラグ＝ＯＮであるため、ハートビート断後であると判定する。ネットワークドライバ３３１は、ハートビート断後のアクセスについて、アクセス内容をアクセスログ情報１２００に記憶する。

これにより、テスト装置１００は、ハートビート断後のアクセスについて、アクセス内容をアクセスログ情報１２００に記憶しておくことができる。例えば、クラスタソフトウェア３１５がハートビート断後には運用系２２０にアクセスしないように設計されており、クラスタソフトウェア３１５が正常に動作するかをテストする場合がある。この場合、テスト装置１００は、ハートビート断後のアクセスに基づいて、クラスタソフトウェア３１５が正常に動作していないと判定することができる。

また、テスト装置１００は、テスターにアクセスログ情報１２００を参照させ、テスターがクラスタソフトウェア３１５の動作を詳細に把握可能にすることができ、クラスタソフトウェア３１５のテストの精度向上を図ることができる。テスターは、例えば、クラスタソフトウェア３１５のバグが、ハートビート断後の処理に含まれることを把握することができる。

テスト装置１００は、動作例１〜動作例５に示したように、自装置以外の待機系２１０や運用系２２０において行われる、クラスタソフトウェアの切替処理に関する処理の結果が異常になるようにすることができる。これにより、テスト装置１００は、クラスタソフトウェアの切替処理に関する様々なエラーケースを発生させることができる。テスト装置１００は、例えば、自装置以外の待機系２１０へのアクセス要求にエラーフラグを付与しておき、自装置以外の待機系２１０におけるエラーケースを発生させることができる。このため、テスト装置１００は、クラスタソフトウェアのテストの精度向上を図ることができる。

動作例１〜動作例５では、ネットワークドライバやディスクドライバなどが、切替指示やアクセス要求などを受け付けた際、切替指示やアクセス要求などに応じた処理を実行するまでに待ち時間を設けない場合について説明したが、これに限らない。

例えば、クラスタソフトウェアが運用系２２０がハングであるため切替処理を開始するタイミングは、ネットワークドライバやディスクドライバなどが「クラスタソフトウェアが切替処理を開始した」と判定するタイミングとラグがあり、一致しないことがある。例えば、切替処理と、ネットワークドライバやディスクドライバなどがエラーフラグを受信して設定する処理とが、ＯＳによってディスパッチされながら動作し、テスト装置１００の環境などにより実行順序が不安定になるため、ラグが生じることがある。

このため、ネットワークドライバやディスクドライバなどが、受け付けた切替指示やアクセス要求などに応じた処理を実行するまでに待ち時間を設け、エラーフラグを受信するかを待つようにする場合があってもよい。例えば、ネットワークドライバやディスクドライバなどは、テスト準備中フラグやエラーフラグに基づいて、運用系２２０が無応答にされた後に受け付けた切替指示やアクセス要求などに応じた処理を実行するまでに待ち時間を設ける。これにより、テスト装置１００は、クラスタソフトウェアのテストの精度向上を図ることができる。

（監視処理手順の一例）
次に、図２４を用いて、テスト装置１００のネットワークドライバによって実行される、監視処理手順の一例について説明する。監視処理は、テスト装置１００とは異なる待機系２１０や運用系２２０のネットワークドライバにおいても実行可能であってもよい。

図２４は、監視処理手順の一例を示すフローチャートである。図２４において、テスト装置１００は、ｐｉｎｇ送信依頼を受け付ける（ステップＳ２４０１）。

そして、テスト装置１００は、依頼元がテスト対象のソフトウェアであるか否かを判定する（ステップＳ２４０２）。ここで、テスト対象のソフトウェアではない場合（ステップＳ２４０２：Ｎｏ）、テスト装置１００は、ステップＳ２４０３の処理に移行する。一方で、テスト対象のソフトウェアである場合（ステップＳ２４０２：Ｙｅｓ）、テスト装置１００は、ステップＳ２４０４の処理に移行する。

ステップＳ２４０３では、テスト装置１００は、通常のｐｉｎｇ送信処理を実行する（ステップＳ２４０３）。そして、テスト装置１００は、監視処理を終了する。

ステップＳ２４０４では、テスト装置１００は、カウンタ（ｉ）をカウントアップする（ステップＳ２４０４）。次に、テスト装置１００は、現在時刻をＯＳから取得し、Ｔ（ｉ）に設定する（ステップＳ２４０５）。

そして、テスト装置１００は、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＦＦであるか否かに基づいて、初回のｐｉｎｇであるか否かを判定する（ステップＳ２４０６）。テスト装置１００は、例えば、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＦＦであれば、初回のｐｉｎｇであると判定する。ここで、初回のｐｉｎｇである場合（ステップＳ２４０６：Ｙｅｓ）、テスト装置１００は、ステップＳ２４０７の処理に移行する。一方で、初回のｐｉｎｇではない場合（ステップＳ２４０６：Ｎｏ）、テスト装置１００は、ステップＳ２４１０の処理に移行する。

ステップＳ２４０７では、テスト装置１００は、ステータステーブル５００に、依頼元のプロセス名と、ｐｉｎｇの相手先のアドレスと、現在時刻Ｔ（１）を記録する（ステップＳ２４０７）。次に、テスト装置１００は、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＮに設定する（ステップＳ２４０８）。そして、テスト装置１００は、送信側フラグテーブル６００を含む通知パケットを、ｐｉｎｇの相手先に送信する（ステップＳ２４０９）。その後、テスト装置１００は、監視処理を終了する。

ステップＳ２４１０では、テスト装置１００は、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＮ、かつ、ｐｉｎｇ受付待ちフラグ＝ＯＦＦであるか否かに基づいて、２回目以降のｐｉｎｇであるか否かを判定する（ステップＳ２４１０）。ここで、２回目以降のｐｉｎｇである場合（ステップＳ２４１０：Ｙｅｓ）、テスト装置１００は、ステップＳ２４１１の処理に移行する。一方で、２回目以降のｐｉｎｇではない場合（ステップＳ２４１０：Ｎｏ）、テスト装置１００は、ステップＳ２４１４の処理に移行する。

ステップＳ２４１１では、テスト装置１００は、ステータステーブル５００に、現在時刻Ｔ（１）を記録する（ステップＳ２４１１）。次に、テスト装置１００は、Ｔ（２）−Ｔ（１）からｐｉｎｇ間隔を算出し、作業域８００に記憶する（ステップＳ２４１２）。そして、テスト装置１００は、送信側フラグテーブル６００のｐｉｎｇ受付待ちフラグ＝ＯＮに設定する（ステップＳ２４１３）。その後、テスト装置１００は、ステップＳ２４１４の処理に移行する。

ステップＳ２４１４では、テスト装置１００は、ＯＳにタイムアウト値＝Ｔでタイマー割込依頼を出力し、タイムアウト時に図２５に後述する割込処理を実行する（ステップＳ２４１４）。テスト装置１００は、タイムアウト前に、新たにＯＳにタイムアウト値＝Ｔでタイマー割込依頼を出力する場合、直前のタイマー割込依頼はキャンセルする。

そして、テスト装置１００は、監視処理を終了する。これにより、テスト装置１００は、クラスタソフトウェアから初回のｐｉｎｇを受け付けると、通常の処理を行わずに、他のデバイスドライバとの共通域に記憶されたテスト準備中フラグ＝ＯＮに設定することができる。共通域は、例えば、システムディスクである。

また、テスト装置１００は、テスト準備中フラグ＝ＯＮ、かつ、ｐｉｎｇ受付待ちフラグ＝ＯＦＦの場合、ｐｉｎｇ受付待ちフラグ＝ＯＮに設定することができる。また、テスト装置１００は、クラスタソフトウェアからｐｉｎｇを受け付けると、ｐｉｎｇ間隔＝（Ｔ２−Ｔ１）を算出し、タイマー割込依頼を出力することができ、タイムアウトにより、クラスタソフトウェアの切替処理の開始を判定可能にすることができる。

また、テスト装置１００は、テスト準備中フラグ＝ＯＮ、かつ、ｐｉｎｇ受付待ちフラグ＝ＯＮの場合、クラスタソフトウェアからｐｉｎｇを受け付けると、タイマー割込依頼を再出力することができ、タイマーを計測し直させることができる。

（割込処理手順の一例）
次に、図２５を用いて、テスト装置１００のネットワークドライバによって実行される、割込処理手順の一例について説明する。割込処理は、テスト装置１００とは異なる待機系２１０や運用系２２０のネットワークドライバにおいても実行可能であってもよい。

図２５は、割込処理手順の一例を示すフローチャートである。図２５において、テスト装置１００は、送信側フラグテーブル６００のエラーフラグ＝ＯＮに設定する（ステップＳ２５０１）。

次に、テスト装置１００は、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＦＦ、ｐｉｎｇ受付待ちフラグ＝ＯＦＦに設定する（ステップＳ２５０２）。そして、テスト装置１００は、ステータステーブル５００からｐｉｎｇの相手先のアドレスを取得する（ステップＳ２５０３）。

次に、テスト装置１００は、送信側フラグテーブル６００を含む通知パケットを、ｐｉｎｇの相手先に送信する（ステップＳ２５０４）。そして、テスト装置１００は、割込処理を終了する。これにより、テスト装置１００は、タイマーのタイムアウトに応じて、クラスタソフトウェアの切替処理の開始を判定することができる。

テスト装置１００は、タイマーのタイムアウトによる割込が発生した場合、共通域に記憶されたエラーフラグ＝ＯＮに設定することができ、切替処理に関するエラーケースを発生可能なタイミングであることを特定することができる。また、テスト装置１００は、ｐｉｎｇの相手先に、エラーフラグや正常復帰フラグを送信し、切替処理に関するエラーケースを発生可能なタイミングであることを通知することができる。

（送信処理手順の一例）
次に、図２６および図２７を用いて、テスト装置１００のネットワークドライバによって実行される、送信処理手順の一例について説明する。送信処理は、テスト装置１００とは異なる待機系２１０や運用系２２０のネットワークドライバにおいても実行可能であってもよい。

図２６および図２７は、送信処理手順の一例を示すフローチャートである。図２６において、テスト装置１００は、アクセス要求の送信依頼を受け付ける（ステップＳ２６０１）。

そして、テスト装置１００は、依頼元がテスト対象のソフトウェアであるか否かを判定する（ステップＳ２６０２）。ここで、テスト対象のソフトウェアである場合（ステップＳ２６０２：Ｙｅｓ）、テスト装置１００は、ステップＳ２６０３の処理に移行する。一方で、テスト対象のソフトウェアではない場合（ステップＳ２６０２：Ｎｏ）、テスト装置１００は、図２７のステップＳ２７０９の処理に移行する。

ステップＳ２６０３では、テスト装置１００は、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＮであるか否かを判定する（ステップＳ２６０３）。ここで、テスト準備中フラグ＝ＯＮである場合（ステップＳ２６０３：Ｙｅｓ）、テスト装置１００は、ステップＳ２６０４の処理に移行する。一方で、テスト準備中フラグ＝ＯＮではない場合（ステップＳ２６０３：Ｎｏ）、テスト装置１００は、図２７のステップＳ２７０１の処理に移行する。

ステップＳ２６０４では、テスト装置１００は、ｔ時間スリープする（ステップＳ２６０４）。そして、テスト装置１００は、図２７のステップＳ２７０１の処理に移行する。

図２７において、テスト装置１００は、送信側フラグテーブル６００のエラーフラグ＝ＯＮであるか否かを判定する（ステップＳ２７０１）。ここで、エラーフラグ＝ＯＮである場合（ステップＳ２７０１：Ｙｅｓ）、テスト装置１００は、ステップＳ２７０２の処理に移行する。一方で、エラーフラグ＝ＯＮではない場合（ステップＳ２７０１：Ｎｏ）、テスト装置１００は、ステップＳ２７０９の処理に移行する。

ステップＳ２７０２では、テスト装置１００は、ステータステーブル５００からｐｉｎｇの相手先のアドレスを取得する（ステップＳ２７０２）。そして、テスト装置１００は、アクセス先がｐｉｎｇの相手先であるか否かを判定する（ステップＳ２７０３）。ここで、ｐｉｎｇの相手先である場合（ステップＳ２７０３：Ｙｅｓ）、テスト装置１００は、ステップＳ２７０４の処理に移行する。一方で、ｐｉｎｇの相手先ではない場合（ステップＳ２７０３：Ｎｏ）、テスト装置１００は、ステップＳ２７０５の処理に移行する。

ステップＳ２７０４では、テスト装置１００は、図２８に後述するシミュレーション処理を実行する（ステップＳ２７０４）。そして、テスト装置１００は、送信処理を終了する。

ステップＳ２７０５では、テスト装置１００は、送信側フラグテーブル６００のエラー情報送信済みフラグ＝ＯＦＦであるか否かを判定する（ステップＳ２７０５）。ここで、エラー情報送信済みフラグ＝ＯＦＦである場合（ステップＳ２７０５：Ｙｅｓ）、テスト装置１００は、ステップＳ２７０６の処理に移行する。一方で、エラー情報送信済みフラグ＝ＯＦＦではない場合（ステップＳ２７０５：Ｎｏ）、テスト装置１００は、送信処理を終了する。

ステップＳ２７０６では、テスト装置１００は、送信側フラグテーブル６００を含む通知パケットを、アクセス要求の送信先に送信する（ステップＳ２７０６）。次に、テスト装置１００は、送信側フラグテーブル６００のエラー情報送信済みフラグ＝ＯＮに設定する（ステップＳ２７０７）。そして、テスト装置１００は、通常の送信処理を実行する（ステップＳ２７０８）。その後、テスト装置１００は、送信処理を終了する。

ステップＳ２７０９では、テスト装置１００は、通常の送信処理を実行する（ステップＳ２７０９）。そして、テスト装置１００は、送信処理を終了する。これにより、テスト装置１００は、テスト準備中フラグ＝ＯＮであれば、アクセス要求に応じて、通常の処理は行わず、アクセス要求に応じた処理の開始を、一定の時間保留することができる。そして、テスト装置１００は、一定の時間が経過すると、エラーフラグ＝ＯＮであり、アクセス先が、ｐｉｎｇの相手先であれば、エラーケースをシミュレーションすることができる。また、テスト装置１００は、ｐｉｎｇの相手先に、エラーケースをシミュレーションさせることもできる。

（シミュレーション処理手順の一例）
次に、図２８を用いて、テスト装置１００のネットワークドライバによって実行される、シミュレーション処理手順の一例について説明する。シミュレーション処理は、テスト装置１００とは異なる待機系２１０や運用系２２０のネットワークドライバにおいても実行可能であってもよい。

図２８は、シミュレーション処理手順の一例を示すフローチャートである。図２８において、テスト装置１００は、通常の送信処理を実行する（ステップＳ２８０１）。そして、テスト装置１００は、シミュレーション処理を終了する。テスト装置１００は、通常の送信処理を実行することにより、送信先でエラーケースのシミュレーションを実行させる。テスト装置１００は、例えば、自装置でエラーケースのシミュレーションを実行してもよい。

（受信処理手順の一例）
次に、図２９および図３０を用いて、運用系２２０のネットワークドライバによって実行される、受信処理手順の一例について説明する。受信処理は、テスト装置１００、または、テスト装置１００とは異なる待機系２１０のネットワークドライバにおいても実行可能であってもよい。

図２９および図３０は、受信処理手順の一例を示すフローチャートである。図２９において、運用系２２０は、アクセス要求を受け付ける（ステップＳ２９０１）。

そして、運用系２２０は、受信側フラグテーブル７００のテスト準備中フラグ＝ＯＮ、または、エラーフラグ＝ＯＮであるか否かを判定する（ステップＳ２９０２）。ここで、受信側フラグテーブル７００のテスト準備中フラグ＝ＯＮ、または、エラーフラグ＝ＯＮである場合（ステップＳ２９０２：Ｙｅｓ）、運用系２２０は、ステップＳ２９０３の処理に移行する。

一方で、受信側フラグテーブル７００のテスト準備中フラグ＝ＯＦＦ、かつ、エラーフラグ＝ＯＦＦである場合（ステップＳ２９０２：Ｎｏ）、運用系２２０は、図３０のステップＳ３００８の処理に移行する。

ステップＳ２９０３では、運用系２２０は、受信側フラグテーブル７００のエラーフラグ＝ＯＦＦであるか否かを判定する（ステップＳ２９０３）。ここで、エラーフラグ＝ＯＦＦである場合（ステップＳ２９０３：Ｙｅｓ）、運用系２２０は、ステップＳ２９０４の処理に移行する。一方で、エラーフラグ＝ＯＦＦではない場合（ステップＳ２９０３：Ｎｏ）、運用系２２０は、ステップＳ２９０６の処理に移行する。

ステップＳ２９０４では、運用系２２０は、アクセスカウンタ（ハートビート断前）をカウントアップする（ステップＳ２９０４）。次に、運用系２２０は、アクセス記憶域（ハートビート断前）に、アクセスカウンタ（ハートビート断前）と、ポートＮｏと、アクセス内容とを記録する（ステップＳ２９０５）。そして、運用系２２０は、図３０のステップＳ３００１の処理に移行する。

ステップＳ２９０６では、運用系２２０は、アクセスカウンタ（ハートビート断後）をカウントアップする（ステップＳ２９０６）。次に、運用系２２０は、アクセス記憶域（ハートビート断後）に、アクセスカウンタ（ハートビート断後）と、ポートＮｏと、アクセス内容とを記録する（ステップＳ２９０７）。そして、運用系２２０は、図３０のステップＳ３００１の処理に移行する。

図３０において、運用系２２０は、モード＝特殊テストモードであるか否かを判定する（ステップＳ３００１）。ここで、特殊テストモードである場合（ステップＳ３００１：Ｙｅｓ）、運用系２２０は、ステップＳ３００２の処理に移行する。一方で、特殊テストモードではない場合（ステップＳ３００１：Ｎｏ）、運用系２２０は、ステップＳ３００８の処理に移行する。

ステップＳ３００２では、運用系２２０は、システムディスクから正常復帰フラグを取得する（ステップＳ３００２）。そして、運用系２２０は、取得した正常復帰フラグ＝ＯＦＦであるか否かを判定する（ステップＳ３００３）。ここで、正常復帰フラグ＝ＯＦＦである場合（ステップＳ３００３：Ｙｅｓ）、運用系２２０は、ステップＳ３００４の処理に移行する。一方で、正常復帰フラグ＝ＯＦＦではない場合（ステップＳ３００３：Ｎｏ）、運用系２２０は、ステップＳ３００６の処理に移行する。

ステップＳ３００４では、運用系２２０は、アクセス要求に応じた通常のアクセス処理を実行する（ステップＳ３００４）。次に、運用系２２０は、受信側フラグテーブル７００の正常復帰フラグ＝ＯＮに設定する（ステップＳ３００５）。そして、運用系２２０は、ステップＳ３００７の処理に移行する。

ステップＳ３００６では、運用系２２０は、受信側フラグテーブル７００の正常復帰フラグ＝ＯＦＦに設定する（ステップＳ３００６）。そして、運用系２２０は、ステップＳ３００７の処理に移行する。

ステップＳ３００７では、運用系２２０は、システムディスクの正常復帰フラグを更新する（ステップＳ３００７）。そして、運用系２２０は、受信処理を終了する。

ステップＳ３００８では、運用系２２０は、アクセス要求に応じた通常のアクセス処理を実行する（ステップＳ３００８）。そして、運用系２２０は、受信処理を終了する。これにより、運用系２２０は、モード＝特殊テストモードであれば、テスターからのテスト開始指示を受けると、システムディスクから正常復帰フラグを取得することができる。

そして、運用系２２０は、正常復帰フラグ＝ＯＦＦであれば、クラスタソフトウェアからのアクセス要求に応じて、アクセス内容を記録し、通常処理を行うことができる。一方で、運用系２２０は、正常復帰フラグ＝ＯＮであれば、クラスタソフトウェアからのアクセス要求に応じて、アクセス内容を記録し、無応答になるように制御することができる。

また、運用系２２０は、エラーフラグ＝ＯＦＦであれば、アクセスカウンター（ハートビート断前）をカウントアップし、ハートビート断前に対応付けて、アクセスカウンター、ポートＮｏ、アクセス内容などを記憶することができる。一方で、運用系２２０は、エラーフラグ＝ＯＮであれば、アクセスカウンター（ハートビート断後）をカウントアップし、ハートビート断後に対応付けて、アクセスカウンター、ポートＮｏ、アクセス内容などを記憶することができる。また、運用系２２０は、モード＝特殊テストモードでなければ、無応答になるように制御することができる。

（設定処理手順の一例）
次に、図３１を用いて、運用系２２０のネットワークドライバによって実行される、設定処理手順の一例について説明する。設定処理は、テスト装置１００、または、テスト装置１００とは異なる待機系２１０のネットワークドライバにおいても実行可能であってもよい。

図３１は、設定処理手順の一例を示すフローチャートである。図３１において、運用系２２０は、通知パケットを受け付ける（ステップＳ３１０１）。

次に、運用系２２０は、通知パケットから送信側フラグテーブル６００を取得する（ステップＳ３１０２）。そして、運用系２２０は、送信側フラグテーブル６００を受信側フラグテーブル７００に設定する（ステップＳ３１０３）。その後、運用系２２０は、設定処理を終了する。これにより、運用系２２０は、受信側フラグテーブル７００を、クラスタソフトウェアの最新の状態に対応する内容に更新することができる。

（応答処理手順の一例）
次に、図３２を用いて、運用系２２０のデバイスドライバによって実行される、応答処理手順の一例について説明する。デバイスドライバは、例えば、ネットワークドライバやディスクドライバである。応答処理は、テスト装置１００、または、テスト装置１００とは異なる待機系２１０のデバイスドライバにおいても実行可能であってもよい。

図３２は、応答処理手順の一例を示すフローチャートである。図３２において、運用系２２０は、アクセス要求を受け付ける（ステップＳ３２０１）。

そして、運用系２２０は、送信側フラグテーブル６００のテスト準備中フラグ＝ＯＮであるか否かを判定する（ステップＳ３２０２）。ここで、テスト準備中フラグ＝ＯＮである場合（ステップＳ３２０２：Ｙｅｓ）、運用系２２０は、ステップＳ３２０３の処理に移行する。一方で、テスト準備中フラグ＝ＯＮではない場合（ステップＳ３２０２：Ｎｏ）、運用系２２０は、ステップＳ３２０４の処理に移行する。

ステップＳ３２０３では、運用系２２０は、ｔ時間スリープする（ステップＳ３２０３）。そして、運用系２２０は、ステップＳ３２０４の処理に移行する。

ステップＳ３２０４では、運用系２２０は、送信側フラグテーブル６００のエラーフラグ＝ＯＮであるか否かを判定する（ステップＳ３２０４）。ここで、エラーフラグ＝ＯＮである場合（ステップＳ３２０４：Ｙｅｓ）、運用系２２０は、ステップＳ３２０５の処理に移行する。一方で、エラーフラグ＝ＯＮではない場合（ステップＳ３２０４：Ｎｏ）、運用系２２０は、ステップＳ３２０６の処理に移行する。

ステップＳ３２０５では、運用系２２０は、自装置のデバイス番号をキーにして、エラーコードテーブル１０００からエラーコードを取得し、復帰値にエラーコードを設定する（ステップＳ３２０５）。そして、運用系２２０は、応答処理を終了する。

ステップＳ３２０６では、運用系２２０は、アクセス要求に応じた通常のアクセス処理を実行する（ステップＳ３２０６）。そして、運用系２２０は、応答処理を終了する。これにより、運用系２２０は、アクセス要求に応じた処理を一定の時間保留することができ、エラーフラグが変更されることを待つことができ、クラスタソフトウェアのテストの精度向上を図ることができる。また、運用系２２０は、タイムアウト割込みが発生した場合、エラーフラグ＝ＯＮであれば、予めテスターによって定義されたエラーコードを用いて、アクセス要求の結果を異常にすることができる。

以上説明したように、テスト装置１００によれば、クラスタソフトウェアの実行により待機系２１０を待機状態から運用状態に切り替える切替処理が開始されたか否かを、判定することができる。テスト装置１００によれば、切替処理が開始されたと判定したことに応じて、切替処理の結果をエラーにする処理を実行することができる。これにより、テスト装置１００は、切替処理に関するエラーケースを発生させることができる。結果として、テスト装置１００は、切替処理に関するエラーケースを発生させた場合について、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

テスト装置１００によれば、運用系２２０に向けて、クラスタソフトウェアの実行により、特定の間隔で出力される応答要求に基づいて、切替処理を開始したか否かを判定することができる。これにより、テスト装置１００は、クラスタソフトウェアを改変しなくても、切替処理を開始したか否かを判定することができる。このため、テスト装置１００は、クラスタソフトウェアの性能や動作に与える影響を抑制して、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

テスト装置１００によれば、応答要求に対して運用系２２０を無応答にすることができる。テスト装置１００によれば、運用系２２０を無応答にした後、クラスタソフトウェアの実行により応答要求が出力されてから、次の応答要求が出力されずに特定の時間が経過した場合、切替処理が開始されたと判定することができる。これにより、テスト装置１００は、クラスタソフトウェアが、応答要求の出力を中止したと判断され、切替処理を開始したと判断されるタイミングを、精度よく特定することができる。

テスト装置１００によれば、クラスタソフトウェアの実行により応答要求が出力されてから、次の応答要求を出力するまでの時間を計測し、計測した時間を特定の時間に設定することができる。これにより、テスト装置１００は、クラスタソフトウェアの応答要求の間隔を自動で特定して、特定の時間に設定することができ、テスターが特定の時間を特定することができなくても、特定の時間を精度よく設定することができる。結果として、テスト装置１００は、クラスタソフトウェアが切替処理を開始したか否かを精度よく判定することができる。

テスト装置１００によれば、切替処理が開始されたと判定したことを示す情報を、運用系２２０に通知することにより、切替処理に関する運用系２２０の動作の結果を異常にする制御を行うことができる。これにより、テスト装置１００は、運用系２２０のネットワークドライバやディスクドライバなどが原因である、切替処理に関するエラーケースを発生させることができる。

テスト装置１００によれば、切替処理が開始されたと判定したことを示す情報を、待機系２１０に通知することにより、切替処理に関する待機系２１０の動作の結果を異常にする制御を行うことができる。これにより、テスト装置１００は、待機系２１０のネットワークドライバやディスクドライバなどが原因である、切替処理に関するエラーケースを発生させることができる。

テスト装置１００によれば、クラスタソフトウェアから待機系２１０または運用系２２０に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けたアクセス要求に応じた動作を行うことができる。これにより、テスト装置１００は、切替処理が開始されたと判定してから、切替処理に関する待機系２１０または運用系２２０の動作の結果を異常にする制御を行うまでに、一定の時間がかかっても、クラスタソフトウェアを精度よくテストすることができる。

テスト装置１００によれば、運用系２２０を無応答にした後に、待機系２１０または運用系２２０に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けたアクセス要求に応じた動作を行うことができる。これにより、テスト装置１００は、運用系２２０を無応答にする前のアクセス要求に応じた動作を開始するタイミングが遅れてしまうことを防止することができる。

テスト装置１００によれば、運用系２２０を無応答にした後、クラスタソフトウェアから運用系２２０に対するアクセス要求を複数受け付けた場合、複数のアクセス要求のうち、第１のアクセス要求の結果を異常にする制御を行い、第２のアクセス要求の結果を正常にする制御を行うことができる。これにより、テスト装置１００は、クラスタソフトウェアから運用系２２０に対するアクセスの結果が正常である場合と異常である場合との両方について、クラスタソフトウェアをテストすることができ、クラスタソフトウェアのテストの精度向上を図ることができる。

テスト装置１００によれば、アクセス要求の結果について制御を行う処理は、運用系２２０を無応答にしたことを示す情報を、運用系２２０に通知することにより、アクセス要求に関する運用系２２０の動作の結果を異常にする制御を行うことができる。これにより、テスト装置１００は、運用系２２０のネットワークドライバやディスクドライバなどが原因である、アクセス要求に関するエラーケースを発生させることができる。

テスト装置１００によれば、クラスタソフトウェアから運用系２２０に対するアクセス要求を受け付けた場合、受け付けたアクセス要求に関する情報と、受け付けた時点が切替処理が開始されたと判定した前後のいずれかに関する情報とを対応付けた対応情報を記憶する制御を行うことができる。これにより、テスト装置１００は、アクセス要求が、切替処理が開始した時点の前後のいずれに出力されたアクセス要求かを特定可能なように、アクセス要求に関する情報を記憶しておき、クラスタソフトウェアのテストに利用可能にすることができる。

テスト装置１００によれば、運用系２２０を無応答にしたことを示す情報を、運用系２２０に通知し、切替処理が開始されたと判定したことを示す情報を、運用系２２０に通知することにより、運用系２２０に対応情報を記憶させる制御を行うことができる。これにより、テスト装置１００は、運用系２２０において、アクセス要求を受け付けた時点が、切替処理が開始した時点の前後のいずれの時点であるかを特定可能にし、対応情報を生成可能にすることができる。

なお、本実施の形態で説明したテスト方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本実施の形態で説明したテストプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本実施の形態で説明したテストプログラムは、インターネット等のネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）コンピュータに、
テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、
前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行する、
処理を実行させることを特徴とするテストプログラム。

（付記２）前記コンピュータに、
前記応答要求に対して前記他の情報処理装置を無応答にする、処理を実行させ、
前記判定する処理は、前記他の情報処理装置を無応答にした後、前記ソフトウェアの実行により応答要求が出力されてから、次の応答要求が出力されずに特定の時間が経過した場合、前記切替処理が開始されたと判定する、ことを特徴とする付記１に記載のテストプログラム。

（付記３）前記コンピュータに、
前記ソフトウェアの実行により応答要求が出力されてから、次の応答要求を出力するまでの時間を計測し、計測した前記時間を前記特定の時間に設定する、
処理を実行させることを特徴とする付記２に記載のテストプログラム。

（付記４）前記実行する処理は、前記切替処理が開始されたと判定したことを示す情報を、前記他の情報処理装置に通知することにより、前記切替処理に関する前記他の情報処理装置の動作の結果を異常にする制御を行う、ことを特徴とする付記１〜３のいずれか一つに記載のテストプログラム。

（付記５）前記実行する処理は、前記切替処理が開始されたと判定したことを示す情報を、前記情報処理装置に通知することにより、前記切替処理に関する前記情報処理装置の動作の結果を異常にする制御を行う、ことを特徴とする付記１〜４のいずれか一つに記載のテストプログラム。

（付記６）前記コンピュータに、
前記ソフトウェアから前記情報処理装置または前記他の情報処理装置に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けた前記アクセス要求に応じた動作を行う、処理を実行させることを特徴とする付記２または３に記載のテストプログラム。

（付記７）前記動作を行う処理は、前記他の情報処理装置を無応答にした後に、前記情報処理装置または前記他の情報処理装置に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けた前記アクセス要求に応じた動作を行う、ことを特徴とする付記６に記載のテストプログラム。

（付記８）前記コンピュータに、
前記他の情報処理装置を無応答にした後、前記ソフトウェアから前記他の情報処理装置に対するアクセス要求を複数受け付けた場合、複数のアクセス要求のうち、第１のアクセス要求の結果を異常にする制御を行い、第２のアクセス要求の結果を正常にする制御を行う、処理を実行させることを特徴とする付記１〜７のいずれか一つに記載のテストプログラム。

（付記９）前記アクセス要求の結果について制御を行う処理は、前記他の情報処理装置を無応答にしたことを示す情報を、前記他の情報処理装置に通知することにより、前記アクセス要求に関する前記他の情報処理装置の動作の結果を異常にする制御を行う、ことを特徴とする付記８に記載のテストプログラム。

（付記１０）前記コンピュータに、
前記ソフトウェアから前記他の情報処理装置に対するアクセス要求を受け付けた場合、受け付けた前記アクセス要求に関する情報と、受け付けた時点が前記切替処理が開始されたと判定した前後のいずれかに関する情報とを対応付けた対応情報を記憶する制御を行う、処理を実行させることを特徴とする付記１〜９のいずれか一つに記載のテストプログラム。

（付記１１）前記記憶する制御は、前記他の情報処理装置を無応答にしたことを示す情報を、前記他の情報処理装置に通知し、前記切替処理が開始されたと判定したことを示す情報を、前記他の情報処理装置に通知することにより、前記他の情報処理装置に前記対応情報を記憶させる制御を行う、ことを特徴とする付記１０に記載のテストプログラム。

（付記１２）コンピュータが、
テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、
前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行する、
処理を実行することを特徴とするテスト方法。

（付記１３）テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、
前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行する、
制御部を有することを特徴とするテスト装置。

１００ テスト装置
１０１ ソフトウェア
１１０，２１０，２２０ 情報処理装置
２００ テストシステム
２０１ 端末装置
２１０ 待機系
２２０ 運用系
２３０ ネットワーク
３１０，３２０，３３０ 受付プログラム
３１１〜３１３，３２１，３２２，３３１，３３２，１４１２，１４１３，１４２２，１４２３ ネットワークドライバ
３１４，３２３，１４１５ ディスクドライバ
３１５，３２４，１４１１，１４２１，１５１２ クラスタソフトウェア
４００ バス
４０１ ＣＰＵ
４０２ メモリ
４０３ ネットワークＩ／Ｆ
４０４ 記録媒体Ｉ／Ｆ
４０５ 記録媒体
５００ ステータステーブル
６００ 送信側フラグテーブル
７００ 受信側フラグテーブル
８００ 作業域
９００ モード情報
１０００ エラーコードテーブル
１１００ カウンタテーブル
１２００ アクセスログ情報
１３００ 記憶部
１３０１ 取得部
１３０２ 判定部
１３０３ 管理部
１３０４ 出力部
１４０３ システムディスク
１４１４，１４２４ アプリ

Claims (11)

1. コンピュータに、
   テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、
   前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行する、
   処理を実行させることを特徴とするテストプログラム。
2. 前記コンピュータに、
   前記応答要求に対して前記他の情報処理装置を無応答にする、処理を実行させ、
   前記判定する処理は、前記他の情報処理装置を無応答にした後、前記ソフトウェアの実行により応答要求が出力されてから、次の応答要求が出力されずに特定の時間が経過した場合、前記切替処理が開始されたと判定する、ことを特徴とする請求項１に記載のテストプログラム。
3. 前記実行する処理は、前記切替処理が開始されたと判定したことを示す情報を、前記他の情報処理装置に通知することにより、前記切替処理に関する前記他の情報処理装置の動作の結果を異常にする制御を行う、ことを特徴とする請求項１または２に記載のテストプログラム。
4. 前記実行する処理は、前記切替処理が開始されたと判定したことを示す情報を、前記情報処理装置に通知することにより、前記切替処理に関する前記情報処理装置の動作の結果を異常にする制御を行う、ことを特徴とする請求項１〜３のいずれか一つに記載のテストプログラム。
5. 前記コンピュータに、
   前記ソフトウェアから前記情報処理装置または前記他の情報処理装置に対するアクセス要求を受け付けた場合、一定の時間が経過してから、受け付けた前記アクセス要求に応じた動作を行う、処理を実行させることを特徴とする請求項２に記載のテストプログラム。
6. 前記コンピュータに、
   前記他の情報処理装置を無応答にした後、前記ソフトウェアから前記他の情報処理装置に対するアクセス要求を複数受け付けた場合、複数のアクセス要求のうち、第１のアクセス要求の結果を異常にする制御を行い、第２のアクセス要求の結果を正常にする制御を行う、処理を実行させることを特徴とする請求項１〜５のいずれか一つに記載のテストプログラム。
7. 前記アクセス要求の結果について制御を行う処理は、前記他の情報処理装置を無応答にしたことを示す情報を、前記他の情報処理装置に通知することにより、前記アクセス要求に関する前記他の情報処理装置の動作の結果を異常にする制御を行う、ことを特徴とする請求項６に記載のテストプログラム。
8. 前記コンピュータに、
   前記ソフトウェアから前記他の情報処理装置に対するアクセス要求を受け付けた場合、受け付けた前記アクセス要求に関する情報と、受け付けた時点が前記切替処理が開始されたと判定した前後のいずれかに関する情報とを対応付けた対応情報を記憶する制御を行う、処理を実行させることを特徴とする請求項１〜７のいずれか一つに記載のテストプログラム。
9. 前記記憶する制御は、前記他の情報処理装置を無応答にしたことを示す情報を、前記他の情報処理装置に通知し、前記切替処理が開始されたと判定したことを示す情報を、前記他の情報処理装置に通知することにより、前記他の情報処理装置に前記対応情報を記憶させる制御を行う、ことを特徴とする請求項８に記載のテストプログラム。
10. コンピュータが、
    テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、
    前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行する、
    処理を実行することを特徴とするテスト方法。
11. テスト対象のソフトウェアの実行により情報処理装置を待機状態から運用状態に切り替える切替処理が開始されたか否かを、前記情報処理装置が運用状態に切り替わる前に運用状態である他の情報処理装置に向けて前記ソフトウェアが特定の間隔で出力する応答要求に基づいて判定し、
    前記切替処理が開始されたと判定したことに応じて、前記切替処理の結果をエラーにする処理を実行する、
    制御部を有することを特徴とするテスト装置。

Images