JP6597133B2 - エラー再現プログラム、エラー再現方法、及びエラー再現装置 - Google Patents

Description

本発明は，エラー再現プログラム、エラー再現方法、及びエラー再現装置に関する。

プログラムは、新規に開発された場合、バージョンアップした場合、また修正用のパッチファイルを作成した場合などに、その動作をテストされる。プログラムの動作テストは、情報処理装置（またはコンピュータ）がテスト用入力に基づいてテスト対象プログラム（またはテスト対象プロセス）を実行し、動作に異常がないか否かをチェックする作業である。

プログラムの動作テストにおいて、プログラムの動作中にある条件下である処理を実行した時にある現象が発生し、異常が発生する場合がある。このような異常が検出された場合、どんな条件下でどんな処理が実行されまたはどんな現象が発生したときに問題となる異常が発生するのかを、追求する必要がある。そのために、プログラムの動作テストでは、注目しているある条件下でのある処理の実行や現象の発生を再現させて、同じ異常が繰り返されるか否かによって、異常の原因が注目している条件、処理または現象であることを検証する。

注目する条件と処理の実行や現象の発生の一例として、ある処理を実行した際のエラーの発生がある。プログラムは、一般にエラーが発生した場合エラールーチンを実行する。エラールーチンは、ある処理を実行したときにエラーが発生すると、エラー発生時のログを採取し、その処理をリトライするなどの機能を有する。したがって、エラールーチンのバグを見つけるためには、動作テストでエラーを再現してエラールーチンを実行させることが必要である。

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

しかしながら、プログラムの動作テストでは、コンピュータが様々に変化する条件下でテスト対象プログラムを実行する。そのため、複数回の動作テストで、注目している条件下でのある処理の実行やある現象の発生を毎回再現することは、必ずしも容易ではない。上記の例では、プログラムの動作テストにおいて、ある処理に対するエラーを毎回再現することは、必ずしも容易ではない。エラーはある特定の状況にならないと発生しないからである。

そこで，実施の形態の第１の側面の目的は，複数回実行される処理における処理エラーの再現性を向上させることにある。

第１の態様は，プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測し、
前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶し、
前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う、
処理をコンピュータに実行させるエラー再現プログラムである。

第１の側面では，複数回実行される処理における処理エラーの再現性を向上させることができる。

本実施の形態におけるプログラムの動作テストを実行するエラー再現装置の構成を示す図である。 テスト対象プログラム（またはテスト対象プロセス）とネットワークインターフェースのドライバの一例を示す図である。 テスト対象プログラム（以下テスト対象プロセスと称する。）ＰＵＴの動作テストの第１の例を示すシーケンス図である。 テスト対象プログラム（以下テスト対象プロセス）の動作テストの第１の例を示すシーケンス図である。 本実施の形態における第１の動作テストの概略を示すフローチャート図である。 テスト対象プロセスPUTの動作テストの初回テストの一例を示すシーケンス図である。 ２回目以降の再現テストの一例を示すシーケンス図である。 本実施の形態における第２の動作テストの概略を示すフローチャート図である。 初回テストのための準備処理と初回テストの処理シーケンスを示す図である。 プロセステーブルと各プロセスに対応して作成されるカウンタとを示す図である。 ドライバDRVの初回テストでの処理S39のフローチャート図である。 ロギングプログラムLGのテストでの処理S40を示すフローチャート図である。 再現テストのための準備処理と再現テストの処理シーケンスを示す図である。 ログファイル、再現対象ログファイル、エラー再現条件テーブルの一例を示す図である。 ドライバDRVでの再現テストの処理S80のフローチャート図である。 ネットワークアクセスの種類が送信の場合のエラー応答の再現か否かのチェックのフローチャート図である。 ネットワークアクセスの種類が受信の場合のエラー応答の再現か否かのチェックのフローチャート図である。 ネットワークアクセスの種類がセッション確立と解放の場合のエラー応答の再現か否かのチェックのフローチャート図である。

図１は、本実施の形態におけるプログラムの動作テストを実行するエラー再現装置の構成を示す図である。図１のエラー再現装置は、情報処理装置（またはコンピュータ）である。エラー再現装置は、ＣＰＵ(Central Processing Unit)１０と、高速のメインメモリ１２と、ネットワークインターフェース（またはＮＩＣ：Network Interface Card）１４と、大容量で不揮発性の補助メモリ２０〜２８を有する。ネットワークインターフェース１４には、ネットワークＮＷが接続される。また、ネットワークインターフェース１４は、外部のストレージとのインターフェースであるＩＯドライバ回路を含み、ＩＯドライバ回路は、ネットワークＮＷの先に接続されているストレージ装置へのＩＯアクセスを実行する。このＩＯアクセスも、ネットワークＮＷを介するアクセスであるので、本実施の形態のネットワークアクセスに含まれる。

補助メモリ２０〜２８内には、テスト対象プログラムであるテスト対象プロセスＰＵＴと、テスト対象プロセスＰＵＴの動作テストを制御するテストプログラムＴＰと、テスト対象プロセスＰＵＴを実行したときのログを格納するログファイル２５を生成するロギングプログラムＬＰと、プログラムである複数のプロセスやテーブルやライブラリ等２６と、オペレーティングシステム（ＯＳ：Operating System）２２などが格納される。ＯＳには、ネットワークインターフェース１４をドライブするドライバ（またはドライバプログラム）ＤＲＶが含まれる。ＣＰＵ１０は、上記のプログラム、ＯＳ、プロセスをメインメモリ１２内に展開し、実行する。

図２は、テスト対象プログラム（またはテスト対象プロセス）とネットワークインターフェースのドライバの一例を示す図である。テスト対象プロセスＰＵＴは、行番号０１〜１４のメインルーチン３１と、メインルーチン３１で呼び出されるエラールーチン３２とを有する。また、図２には、メインルーチン３１がネットワークアクセスを実行するときに呼び出すネットワークインターフェース１４のドライバＤＲＶも示される。

この例のテスト対象プログラムＰＵＴは、メインルーチン３１が、処理Ｘを実行し（行番号０１）、ネットワークアクセスのためにセッション確立を実行し（行番号０３）、確立したセッション内で、電文Ａ，Ｂ，Ｃ等を送信し（行番号０７）、最後にセッション解放を実行する（行番号１１）。セッション確立とセッション解放は、ネットワークアクセス先のノードとネゴシエーションなどを行うので一種のネットワークアクセスである。また、図２の例ではデータの送信しか実行していないが、データの受信が含まれても良く、データの送信と受信はネットワークアクセスの一つである。

また、この例のテスト対象プログラムＰＵＴは、ネットワークアクセスであるセッション確立と、データ送信と、セッション解放の前後で、ネットワークアクセスに必要なメモリ領域を獲得するメモリ獲得（行番号０２，０６，１０）と、獲得したメモリを解放するメモリ解放（行番号０５，０９，１３）を有する。さらに、各ネットワークアクセス（行番号０３，０７，１１）の直後に、ドライバが戻り値（または復帰値）「エラー応答」でリターンした場合にエラールーチンを呼び出す命令（行番号０４，０８，１２）を有する。

そして、この例のテスト対象プログラムＰＵＴでは、行番号０６−０９をＭ回繰り返すが、Ｍ回の繰り返しを示すコードは省略されている。

一方、メインルーチン３１から呼び出されるエラールーチン３２は、ネットワークアクセスでエラーが発生している間且つエラー回数がＮに達するまで、ロギングルーチンの呼び出し（行番号２１）、メモリ解放（行番号２３）、メモリ獲得（行番号２４）、ネットワークアクセスのリトライ（行番号２５）を繰り返す。

そして、ネットワークインターフェースドライバＤＲＶは、呼び出されたネットワークアクセス（セッション確立、セッション解放、送信、受信など）を実行し（行番号３１）、ネットワークアクセスが正常に終了した場合に戻り値を「正常」にし（行番号３２）、ネットワークアクセスに異常が発生した場合に戻り値を「エラー応答」にして（行番号３３）、呼び出し元のプロセスにリターンする。

ロギングプログラムＬＰは、図示しないが、テスト対象プログラムＰＵＴのエラールーチン３２でロギングルーチンを呼び出されると、呼び出し元のテスト対象プログラムから引き渡される引数に含まれるプロセスＩＤ、ログコード、エラー詳細情報などをログファイル２５に格納する。プロセスＩＤは、テスト対象プログラム（テスト対象プロセス）の識別情報であり、ログコードは、発生した現象の識別コードである。また、エラー詳細情報は、例えば、エラーを発生させたネットワークアクセスの種類（セッション確立、セッション解放、送信、受信）、送信または受信の電文などが含まれる。

図３は、テスト対象プログラム（以下テスト対象プロセスと称する。）ＰＵＴの動作テストの第１の例を示すシーケンス図である。テストプログラムＴＰがテスト開始をテスト対象プロセスＰＵＴに指示すると（Ｓ１）、ＣＰＵがテスト対象プロセスの実行を開始する。

図３の例では、テスト対象プロセスＰＵＴは、図２で示したとおり、処理Ｘを実行した後、セッション確立を実行する（Ｓ２）。このセッション確立の実行は、ＯＳのドライバＤＲＶをコールすることで行われ、コールされたドライバＤＲＶは、ネットワークインターフェースを介してネットワークＮＷにアクセスしセッションを確立する。この例では、セッション確立が正常に終了し、ドライバＤＲＶは呼び出し元のテスト対象プロセスに戻り値「正常」で応答する。そして、テスト対象プロセスは、セッション確立Ｓ２の前でメモリ獲得を実行し、セッション確立が正常に終了したため、セッション確立の後でメモリ解放を実施する。

同様に、テスト対象プロセスＰＵＴは、電文Ａの送信Ｓ３と、電文Ｂの送信Ｓ４と、電文Ｃの送信Ｓ５を実行し、最後にセッション解放Ｓ６を実行する。送信Ｓ３，Ｓ４，Ｓ５とセッション解放Ｓ６は、それぞれドライバＤＲＶをコールしてそれぞれのネットワークアクセスを実行させる。また、それぞれのネットワークアクセスの前でメモリ獲得を実行し、それぞれのネットワークアクセスが正常に終了したため、その後でメモリ解放を実行している。

最後に、テストプログラムＴＰは、テスト終了をテスト対象プロセスに指示すると（Ｓ７）、テスト対象プロセスＰＵＴの実行が終了する。

図３の動作例では、ネットワークアクセスが全て正常に終了したため、エラーが発生せず、エラールーチンが呼び出されることがなく、ネットワークアクセスのリトライも発生していない。そして、各ネットワークアクセスの前後でメモリ獲得とメモリ解放が実行されたため、テスト対象プロセスの動作テストが終了した時点で、メインメモリ１２の空きメモリ領域が不足する状況には至っていないことが検出される（Ｓ８）。

図４は、テスト対象プログラム（以下テスト対象プロセス）の動作テストの第１の例を示すシーケンス図である。図４において、テストプログラムＴＰによるテスト開始の指示Ｓ１と、テスト対象プロセスＰＵＴのセッション確立Ｓ２、電文Ａの送信Ｓ３、電文Ｂの送信Ｓ４、及びテストプログラムのテスト終了指示Ｓ７は、図３と同じである。

しかし、図４では、テスト対象プロセスの電文Ｃの送信Ｓ５でコールされたドライバＤＲＶによる電文Ｃの送信は、ネットワークＮＷ等の何らかの事情で異常が発生し、ドライバＤＲＶは戻り値「エラー応答」で呼び出し元のテスト対象プロセスＰＵＴにリターンしている。その結果、テスト対象プロセスは、エラールーチン（図２の３２）を実行し、ロギングルーチンをコールしてロギングプログラムＬＧにエラー応答が発生した時の、プロセスＩＤ、ログコード、エラー詳細情報をログファイル２５に記憶させ、さらにリトライを実行している（Ｓ５＿１）。そして、エラールーチンは、このリトライで、ドライバＤＲＶを呼び出し電文Ｃの送信を再度実行するが、再度異常が発生し、ドライバＤＲＶは戻り値「エラー応答」でエラールーチンにリターンしている。その結果、エラールーチンが繰り返し実行され、ロギングプログラムＬＧにエラー応答が発生した時の前述の情報をログファイル２５に記憶させている。

図４では、その後のテスト終了までの処理については、省略している。そして、図４のテスト終了後に、メインメモリの空きメモリ領域が不足する状況になっていることが検出される（Ｓ９）。

ここで、図４で動作テスト終了時に空きメモリ領域が不足する状況になった原因は、（１）ネットワークアクセスの異常によるエラー応答で動作したエラールーチン３２に、メモリ解放の命令コードが記述されてないバグがあったためエラー応答のたびに獲得済みのメモリ領域が解放されないままになった、（２）偶然にエラー応答のときに他のプロセスによるある命令実行でメモリ解放が実行されなかった、などが予測されるものと仮定する。

上記の場合、原因（１）の空きメモリ領域不足の原因がエラールーチンのバグによる可能性が高いことを検証するためには、図４の動作と同じネットワークアクセスでのエラー応答を再現し、エラールーチンを実行させる動作テストを繰り返し行い、原因（２）の偶然に発生した現象が発生しない場合に空きメモリ領域不足が発生するか否かをチェックすることが一つの方法である。

しかしながら、動作テストを実行するコンピュータシステムのネットワークＮＷの状態は、刻一刻変化するので、必ずしも図４の動作と同じように同じネットワークアクセスでエラー応答を再現できるとは限らない。

そこで、本実施の形態では、ネットワークインターフェースドライバＤＲＶとロギングプログラムＬＧに改良を加えて、上記のエラー応答を毎回再現できるようにする。

図５は、本実施の形態における第１の動作テストの概略を示すフローチャート図である。動作テストは、初回テストS10-S13と、２回目以降の再現テストS14-S17と、再現テストを繰り返した後の検証工程S18と、デバッグ工程S19などを有する。

まず、初回テストでテスト対象プロセスを実行開始し（S10）、テスト対象プロセスの実行中に累積アクセス数をカウンタで計測し、ドライバDRVからのエラー応答が発生したときに、ロギングルーチンがテスト対象プロセスの累積アクセス数を計測するカウント値をログに記憶する（S11）。テスト対象プロセスが実行中、エラー発生時の累積アクセス数のカウント値を記憶するロギング処理S11を繰り返す。そして、テスト対象プロセスの実行終了後に所定の不具合（例えばメインメモリの空きメモリ領域不足）が発生していないかを調べる。所定の不具合が発生していることを検出すると（S12のYES）、テストプログラムTPは、ロギングルーチンに、注目するエラー発生時のカウント値でエラーが再現されるようにドライバDRVに設定させる（S13）。一例として、注目するエラー発生時のカウント値をログファイルから抽出し、ドライバDRVに通知させる。この処理S13は、テストプログラムTPが実行してもよい。

図６は、テスト対象プロセスPUTの動作テストの初回テストの一例を示すシーケンス図である。図６の初回テストでのテスト対象プロセスPUTの動作は、図４の例と同様に、テスト開始して（S1）、テスト対象プロセスPUTが、セッション確立S2、送信（電文A）S3、送信（電文B）S4のネットワークアクセスの実行時にドライバDRVをそれぞれコールしてそれらのアクセスを実行させ、すべて正常に終了し、但し、送信（電文C）S5でネットワークアクセスは異常終了してドライバDRVがエラー応答し、その後のリトライS5_1でもドライバがエラー応答している。

動作テスト開始前に、ドライバDRVにテスト対象プロセスのネットワークアクセスに対応するカウンタが設定され、ドライバDRVはテスト対象プロセスの実行開始からそのプロセスでのネットワークアクセスの実行回数をカウントする。全てのネットワークアクセスを単一のカウンタでカウントしても良いが、望ましくは、ネットワークアクセスの種類（セッション確立、データ送信、データ受信、セッション解放）別にカウンタを設定しそれぞれの回数をカウントする。図６中、セッション確立のカウント値CNT_1は１回、送信のカウント値CNT_2は３回カウントされ、受信のカウント値とセッション解放のカウント値は示されていない。

ネットワークアクセスのリトライの回数はカウントしないのが望ましい。前述のとおり、テスト対象プロセスでは、ネットワークアクセスで異常が発生してエラー応答が発生すると、リトライが行われる。しかし、ネットワークアクセスの異常は、ネットワーク自体の異常以外に様々な要因で発生する。したがって、初回テストでのリトライ発生と、２回目以降の再現テストでのリトライ発生とは必ずしも一致しない。したがって、リトライの回数はカウントせずに、テスト対象プロセスで記述されているネットワークアクセスの実行回数だけをカウントする。それにより、初回テストでのカウント値と再現テストでのカウント値が同じネットワークアクセスで一致する可能性が向上する。

また、動作テストでは、エラー応答が発生すると、テスト対象プロセスPUTのエラールーチンの実行により、ロギングプログラムLPをコールしてロギング依頼する（S11）。そして、動作テストでは、ロギングプログラムは、前述のプロセスＩＤ、ログコード（処理内容、エラー種類などのコード）、エラー詳細情報（アクセスの種類、電文）に加えて、カウント値もログファイルに記憶する（S11）。図６の例では、電文Cの送信S5とそのリトライS5_1に対するエラー応答の発生時に、ロギングプログラムが、プロセスID（図示せず）と、エラー応答のエラーコードと、アクセス種類と電文C（図示せず）と、送信のカウント値CNT_2＝３とをログファイルに記憶する。

図５に戻り、初回テストの実行後に、処理の不具合が発生していないかチェックする。このチェックはテストプログラムによって行われる。または、通常のＯＳ機能で状態をチェックしてもよい。たとえば、メインメモリの空きメモリ領域が不足している不具合がチェックされる。テスト対象プロセスの実行中のエラールーチンでメモリ領域の解放命令（図２のエラールーチン内の行番号２３）のバグ（解放命令なし）がある場合、メモリ領域の解放が行われず空きメモリ領域が不足する不具合が発生する。

そこで、上記の不具合が検出されると（S12）、ロギングプログラムが蓄積したログファイルからネットワークアクセスでのエラー応答時のカウント値を抽出し、そのカウント値（送信のカウント値CNT_2=3）をドライバDRVに通知して設定する（S13）。

次に、２回目以降の再現テストが実行開始されると（S14）、テスト対象プロセスPUTが実行され、初回テストと同様に、ドライバDRVがネットワークアクセスの実行回数をカウントし、各カウント値が初回テスト後に設定したカウント値と一致すると、ドライバはネットワークアクセスの実行を行うことなく、強制的にエラー応答でリターンする（S15）。つまり、初回テスト時と同じネットワークアクセスでエラー応答を再現する。そして、再現テストが終了した後、テストプログラムTPは、前述の所定の不具合（空きメモリ領域不足）が発生したか否かを確認する（S16）。このような再現テストが複数回（Ｋ回）繰り返されて（S17）、再現テストが終了する。

図７は、２回目以降の再現テストの一例を示すシーケンス図である。図７の再現テストでは、図６の初回テストと同様に、テスト対象プロセスPUTが、セッション確立S2、送信（電文A）S3、送信（電文B）S4のネットワークアクセスの実行時にドライバDRVをコールしてそれらのアクセスを実行させ、正常に終了している。その間、ドライバはそれぞれのアクセス種類別に回数をカウントする。

そして、送信（電文C）S5で呼び出された時、ドライバDRVは送信用のカウンタをカウントアップしてCNT_2=3となり、再現テスト前に設定したカウント値CNT_2=3と一致する。そこで、ドライバはネットワークアクセスを実行せずに、強制的にダミーのエラー応答の戻り値でテスト対象プロセスPUTにリターンする（S15）。この疑似エラー応答S15に応答して、テスト対象プロセスPUTのエラールーチンが実行される。さらに、リトライS5_1で呼び出されたときも、ドライバは同様にカウント値の一致により（CNT_2=3）、ネットワークアクセスせずに疑似エラー応答でリターンする（S15_1）。これに応答してエラールーチンが実行される。つまり、２回の疑似エラー応答を再現することで、初回テストと同様にエラー応答に対応するエラールーチンの実行が再現される。

そして、テストプログラムは、空きメモリ領域不足が発生しているか否かをチェックする（S16）。複数回（K回）再現テストを繰り返して、毎回空きメモリ領域不足が検出されると、ネットワークアクセスに対するエラー応答をトリガにして実行されるエラールーチンに何らかのバグが有る可能性が高いことが検証される。

すなわち、空きメモリ領域不足は、ネットワークアクセスのエラー応答以外の原因で偶発的に発生する場合もある。そのような偶発的に発生する空きメモリ領域不足を起こす現象は、例えば、ある時刻になると実行されるプロセスなどが考えられる。ただし、偶発的に発生する現象は、複数回の再現テストでも毎回偶然発生することはない。そこで、本実施の形態では、再現テストで注目しているネットワークアクセスのエラー応答を確実に再現し、偶発的に発生する現象に起因して空きメモリ領域不足が発生した可能性を排除できるか否か検証することを行う。複数回の再現テストで注目しているネットワークアクセスのエラー応答が毎回発生し、そのほとんどの再現テスト後に空きメモリ領域不足が発生すれば、ネットワークアクセスのエラー応答がその原因である可能性が高いと検証できる。

したがって、再現テストでは、再現するエラーまたは処理や現象を選択または絞りながら、それらが原因か否かを検証することが好ましい。

図５に示すとおり、所定の不具合（空きメモリ領域不足）の原因が注目しているネットワークアクセスのエラー応答であると検証できると（S18のYES）、その注目のエラー応答で実行される命令コードをデバッグする（S19）。この作業は、テストプログラムによるデバッグルーチンや人為的な作業により行われてよい。図２の場合は、エラー応答で実行されるエラールーチンがデバッグ対象になる。

このように、本実施の形態によれば、動作テストで注目している（または疑っている）現象を再現することができるので、デバッグ対象を絞り込むことができる。

［第２の動作テスト］
図８は、本実施の形態における第２の動作テストの概略を示すフローチャート図である。第２の動作テストも、図５の第１の動作テストと同様に、初回テストS10-S13と、２回目以降の再現テストS14-S17と、再現テストを繰り返した後の検証工程S18と、デバッグ工程S19などを有する。

図８の第２の動作テストで図５の第１の動作テストと異なる処理は、以下のとおり工程S11_A, S13_A, S15_Aである。それ以外の処理は図５と同じである。第２の動作テストでは、初回テスト実行時に、ロギングプログラムがエラー応答時のエラー詳細情報としてログコードとカウント値と処理内容（アクセス種類と電文）とをログファイルに記憶する（S11_A）。そして、初回テストが終了後、再現テストの準備処理S13_Aで、ロギングプログラム（またはテストプログラム）が、ログファイル内の注目するエラー応答時のカウント値と処理内容（アクセス種類と電文）をドライバDRVに通知し、そのアクセス種類に対応するカウント値と電文が一致すればエラー応答を発生するよう設定する（S13_A）。これにより、２回目以降の再現テストでは、実行中のプロセスでのネットワークアクセスのアクセス種類に対応するカウント値と処理内容（電文）とが、設定した同じアクセス種類に対応するカウント値と処理内容（電文）と一致すると、ドライバDRVがネットワークアクセスを実行することなく強制的にダミーのエラー応答を発生する（S15_A）。

初回テストと再現テストとでハードウエア資源状態（例えばメモリ容量、ネットワークの状態）に依存して、偶然にテスト対象プロセスとは無関係のプログラムが動作することもあり、初回テストと再現テストでの注目プロセスによるネットワークシーケンスが同じにならない場合がある。そこで、第２の動作テストによれば、初回テストでのエラー応答と再現テストでのエラー応答の原因をできるだけ同じにするために、再現テストでは、ネットワークアクセスのカウント値に加えて処理内容（電文）が一致するときに、ドライバがエラー応答を発生するようにする。

再現テストでカウント値は一致するが電文は一致しない場合、電文が一致してもカウント値は一致しないことが想定される。このような再現テストでは、初回テストと同じエラー応答を再現することはできない。しかし、複数回の再現テストを行うことで一定の割合で再現テストで初回テストと同じエラー応答を再現することができる。また、初回テストと異なるエラー応答の再現を抑制することができる。

なお、ネットワークアクセスが送信の場合はその送信電文、受信の場合は直前の受信電文などが、エラー応答を再現するか否かのチェック用電文として利用される。

［本実施の形態の詳細］
次に、本実施の形態の詳細に説明する。以下の詳細例では上記の第２の動作テストの例である。

［初回テスト］
図９は、初回テストのための準備処理と初回テストの処理シーケンスを示す図である。準備処理として、テストプログラムTPは、プロセス名に対応するプロセスIDをＯＳから取得しプロセステーブルに格納し(S31)、プロセステーブルをドライバDRVに通知する（S32）。テストプログラムTPやテスト対象プロセスPUTを実行する情報処理装置（図１参照）は、電源起動時にＯＳが電源起動動作に含まれる複数のプロセスの起動処理を完了済みである。したがって、テスト開始前に、ＯＳは起動処理した複数のプロセスのプロセスIDを管理している。そこで、本実施の形態では、プロセスの動作テストを制御するテストプログラムTPは、ＯＳから起動済みのプロセスのうち、テスト対象プロセスのプロセスIDを取得し、プロセステーブルに格納し、ドライバに通知する。ここで、プロセスとは例えばワードプロセッサや表計算プログラムなどである。

図１０は、プロセステーブルと各プロセスに対応して作成されるカウンタとを示す図である。プロセス名定義テーブル４１にプロセス名「mwproc」「Fileprv」が登録されている。それに対応して、プロセステーブル４２にそれらのプロセス名毎のプロセスID「１０１」「１１３」が登録されている。上記の工程S31では、テストプログラムTPが、プロセステーブル４２を生成し、ドライバDRVに通知する（S32）。これにより、テストプログラムTPは、テスト対象プロセスのプロセスIDをドライバDRVに通知する。

図９に戻り、次に、ドライバDRVは、プロセステーブル４２に基づいて、各プロセス毎に、ネットワークアクセスの種類別にカウンタを作成する（S33）。すなわち、図１０に示されるとおり、プロセステーブル４２に登録されているプロセスID毎に、ネットワークアクセスの種類（アクセス確立、アクセス解放、受信、送信）別にカウンタCNT_1、CNT_2、CNT_3、CNT_4を作成する。これらのカウンタは、具体的には例えばメインメモリ内に作成される。図１０には、プロセスID＝１０１、１１３それぞれに対して、カウンタCNT_1、CNT_2、CNT_3、CNT_4が作成されている。

図９に戻り、テストプログラムTPが初回テスト開始コマンドを実行し、初回テスト開始を、テストプロセスPUTとドライバDRVとロギングプログラムLGとに通知する（S34(図８内のS10)）。これに応答して、ドライバDRVは動作モードを初回テストに設定し、ロギングプログラムLGも動作モードを初回テストに設定し、テスト対象プロセスPUTが初回テスト動作を実行し（S38）、テスト対象プロセスPUTからの呼び出しに応答して、ドライバDRVが初回テストの処理を実行し（S39）、ロギングプログラムLGが初回テストの処理を実行する（S40）。やがて、テストプログラムTPが初回テスト終了コマンドを実行し、初回テスト終了をテストプロセスPUTとドライバDRVとロギングプログラムLGとに通知する（S41,S42）。初回テストが終了すると、ロギングプログラムLGが、ログファイル２５内に、ドライバDRVがネットワークアクセス処理に対応して発生するエラー応答発生時のプロセスID、ログコード、エラー詳細情報（アクセス種類、電文）とカウント値とを格納する。

図１１は、ドライバDRVの初回テストでの処理S39のフローチャート図である。ドライバDRVは、実行中のテスト対象プロセスからネットワークアクセスの呼び出しが発生すると処理を開始する（S51のYES）。図１１の処理は、初回テストでの処理であるので、動作モードが初回テストでない場合は実行されず（S52のNO）、動作モードが初回テストの場合に実行される（S52のYES）。

次に、ドライバDRVは、呼び出し元プロセスのプロセスIDを取得し（S53）、取得したプロセスIDがプロセステーブル４２内のプロセスIDと一致するか否かチェックする。呼び出し元プロセスのプロセスIDは、呼び出し関数の引数に含まれている。

そして、ドライバは、呼び出し元のプロセスIDがプロセステーブル内のプロセスIDと一致する場合（S54のYES）、リトライによるネットワークアクセスでなければ（S55のNO）、呼び出されたネットワークアクセスに対応するカウンタを＋１する（S56）。つまり、ネットワークアクセスがアクセス確立、解放、送信、受信のいずれかに応じて対応するカウンタをインクリメントする。リトライによるネットワークアクセスか否かの判定は、呼び出されたネットワークアクセスが、直前のネットワークアクセスと同じアクセス内容（アクセス種類（コマンドコード）と対応する電文）と同じか否かで判定する。図１１中、左下に示した前回の呼び出し内容レジスタ４３に、ネットワークアクセスのコマンドコードと電文とが記憶されている。前回の呼び出し内容レジスタ４３は、例えばメモリ領域などに生成される。

リトライによるネットワークアクセスの場合（S55のYES）、対応するカウンタのカウント値はインクリメントされない。これにより、初回テスト時と再現テスト時のネットワーク状態やその他の要因が異なることに起因してリトライの発生が異なっても、リトライ時の回数をカウントしないことにより、カウント値に基づいて初回テスト時と再現テスト時とで同じネットワークアクセスか否かの判定を高精度に行うことができる。

そして、ドライバは、呼び出されたネットワークアクセスを実行し（S57）、ネットワークインターフェース１４にそのネットワークアクセスを実行させる。さらに、ドライバは、今回の呼び出し内容（コマンドコードと電文）を、前述の前回の呼び出し内容レジスタ４３内に保存し（S58）、戻り値と共に呼び出し元のプロセスにリターンする。ドライバは、ネットワークアクセスが正常に終了すれば戻り値は「正常」応答でリターンし、異常が発生すれば戻り値は「エラー」応答でリターンする。

一方、ドライバは、呼び出し元のプロセスIDがプロセステーブル内のプロセスIDと不一致の場合（S54のNO）、通常のネットワークアクセスを実行する（S59）。この場合は、カウンタを＋１する処理はない。

上記のドライバDRVの初回テストでの処理により、テスト対象プロセスで発生したネットワークアクセスのアクセス種類毎の発生回数をそれぞれのカウンタによりカウントすることができる。

図１２は、ロギングプログラムLGのテストでの処理S40を示すフローチャート図である。ロギングプログラムLGは、テスト対象プロセスのエラールーチンなどによるロギングプログラムの呼び出しに応答して動作する（S61のYES）。ロギングプログラムは、呼び出されると、呼び出し元のプロセスID、ログコード（エラーの原因を示す識別コード）、エラー詳細情報（ネットワークアクセスの種類とそれに対応する電文）を引数で受領する（S62）。

そして、動作モードが「初回テスト」の場合は（S63のYES）、ロギングプログラムLGは、引数の呼び出し元プロセスIDとログコードを参照し、注目するプロセスIDで且つ注目するエラーのログコードか否かを判定する（S64）。図１２には、ログコードテーブル４４の一例としてネットワークエラーのエラーコード「１０２５」が示されている。このログコードテーブル４４には「１０２５」がテスト準備処理にて予め登録されている。

引数のプロセスIDとログコードとがプロセステーブルのプロセスIDとログコードテーブル４４のログコードとそれぞれ共に一致する場合（S64のYES）、ロギングプログラムLGは、引数に含まれているプロセスIDのネットワークアクセスの種類に対応するカウント値を、ドライバDRVから取得し（S65）、ログファイルに、日時、引数に含まれる情報、取得したカウント値を記録する（S66）。一方、引数のプロセスIDがプロセステーブルと不一致またはログコードがログコードテーブル４４のログコードと不一致の場合（S64のNO）、ロギングプログラムLGは、日時、引数に含まれる情報をログファイルに記録する（S67）。この処理は、通常のロギング処理である。

以上により、ロギングプログラムは、注目しているプロセスIDの注目しているエラーコードについてのログ情報を、ドライバがカウントしているカウント値とネットワークアクセスに対応する電文とを含めてログファイルに記録する。

［再現テスト］
図１３は、再現テストのための準備処理と再現テストの処理シーケンスを示す図である。準備処理として、テストプログラムTPは、ログファイル内のログから注目するエラー応答の再現タイミングのログに絞り（S71）、絞ったログからエラー再現条件テーブルを生成する（S72）。そして、テストプログラムは、ドライバDRVにエラー再現条件テーブルをエラー再現条件として通知すると（S73）、ドライバはエラー再現条件を設定する（S74)。

図１４は、ログファイル、再現対象ログファイル、エラー再現条件テーブルの一例を示す図である。ログファイル２５は、既に説明したとおり、ログの日時と、プロセスIDと、ログコードと、ネットワークアクセスの詳細内容であるアクセス種類と電文（図１４では電文データへのポインタ情報）と、カウント値を有する。プロセスIDの「１０１」は、図１０のプロセステーブル４２内のプロセスmwprocのプロセスIDであり、ログコード「１０２５」は、図１２のログコードテーブル内のネットワークエラーのログコードである。

但し、再現テストでは、ログファイル２５内の全てのログと一致するタイミングでエラーを再現させるのではなく、別の要因で絞られるログと一致するタイミングでエラーを再現させて、動作テストによって行おうとしている検証精度をより高めたい場合がある。例えば、メインメモリの使用状況を定期的にまたは所定のタイミングで記録していた場合、メインメモリの空きメモリ領域が急減した時刻を特定することができる。その場合は、再現テストでは、空きメモリ領域が急減した時刻直前に記録されたネットワークエラーに関するログに絞って、エラーを再現させたい場合がある。

そこで、テストプログラムTPは、ログファイル２５を取得し、絞り込みたい時刻や時間帯を指定して、注目するエラー応答の再現タイミングのログに絞り再現対象ログファイル５０を生成する（S71）。図１４の再現対象ログファイル５０は、ログファイル２５のカウント値が３２に達する時刻以降のログ（カウント値が３２と３３のログ）に絞られている。

そして、テストプログラムは、再現対象ログファイル５０内の絞ったログから、エラー再現条件テーブル５１を生成する（S72）。具体的には、エラー再現条件テーブル５１は、再現対象ログファイルログの発生時刻を除いた、プロセスIDと、ログコードと、アクセス種類と、電文と、カウント値を有するテーブルである。

上記のログファイルから注目するエラー応答の再現タイミングのログへの絞り込みは、単に、ログファイル内の注目するプロセスID「１０１」とログコード「１０２５」のログに絞り込むだけでもよい。少なくとも、ログにアクセス種類と電文情報とカウント値とが含まれるものに絞り込めば良い。

図１３に戻り、上記の再現テストのための準備処理（S72-S74）の後、テストプログラムTPは再現テスト開始コマンドを実行し（S75(図８のS14)）、テスト対象プロセスPUTとドライバDRVとロギングプログラムLGに再現テスト開始を通知する（S76）。

これに応答して、ドライバDRVは、カウンタのカウント値を初期化（ゼロに初期化）し（S77）、動作モードを「再現テスト」に設定する（S78）。また、ロギングプログラムLGも、動作モードを「再現テスト」に設定する（S79）。そして、テスト対象プロセスPUTが再現テスト動作を開始し（S80）、それから呼び出されるときにドライバDRVが再現テストの処理を実行し（S81）、ロギングプログラムLGがテストの処理を実行する（S40）。ロギングプログラムの処理は、図１２に示した処理S40と同じである。

図１５は、ドライバDRVでの再現テストの処理S80のフローチャート図である。ドライバは、初回テストと同様に、ネットワークアクセスの呼び出しに応答して以下の処理を行う（S91のYES）。また、動作モードが「再現テスト」に設定されている場合に以下の処理を行う（S92のYES）。

まず、ドライバは、ネットワークアクセスの呼び出しの引数から、呼び出し元プロセスのプロセスIDを取得し（S93）、そのプロセスIDがプロセステーブル内にあるか否かチェックする（S94）。取得したプロセスIDがプロセステーブル内にない場合は（S94のNO）、通常のネットワークアクセスを実行する（S102）。取得したプロセスIDがプロセステーブル内にある場合（S94のYES）、エラー応答を再現するか否かのチェックを実行する（S95）。エラー応答を再現するか否かのチェックは、ネットワークアクセスの種類（セッション確立、同解放、送信、受信）に応じて異なるので、別の図で説明する。

図１６は、ネットワークアクセスの種類が送信の場合のエラー応答の再現か否かのチェックのフローチャート図である。ドライバは、呼び出されたネットワークアクセスの種類に対応するドライバ内の送信カウント値に＋１加算した値が、エラー再現条件テーブル内の同じ種類に対応するカウント値と一致するか否かチェックする（S110）。例えば、送信カウント値に＋１加算した値が「０４」の場合は、図１４のエラー再現条件テーブル５１内の送信に対応するカウント値「３２」「３３」のいずれとも一致しないので、チェックルーチンの戻り値（復帰値）を「正常」に設定する（S113）。一方、送信カウント値に＋１加算した値が「３２」または「３３」の場合は一致するので（S111のYES）、電文がエラー発生条件の送信カウンタが一致した電文と一致するか否かチェックし、一致すれば（S111のYES）、戻り値（復帰値）を「エラー応答要」に設定する（S112）。送信カウント値が一致したが電文が不一致であれば（S111のNO）、戻り値（復帰値）を「正常」に設定する（S113）。そして、戻り値（復帰値）とともにドライバプログラムDRVにリターンする。

送信カウント値を＋１するのは、図１５に示されるとおり、現在のネットワークアクセスについて送信カウント値を加算していないからである。

図１７は、ネットワークアクセスの種類が受信の場合のエラー応答の再現か否かのチェックのフローチャート図である。ネットワークアクセスが受信の場合は、電文は受信が正常に完了した時点で判明するので、初回テストのロギングルーチンでは直前の受信の電文がログファイルに記録されている。

そこで、図１７での再現テストでは、受信カウント値が一致し（S120のYES）且つ直前の受信の電文が一致する場合（S121のYES）に、戻り値（復帰値）を「エラー応答要」に設定し（S122）、いずれかが不一致の場合は、戻り値（復帰値）を「正常」に設定する（S123）。

図１８は、ネットワークアクセスの種類がセッションの確立または解放の場合のエラー応答の再現か否かのチェックのフローチャート図である。ネットワークアクセスがセッションの確立または解放の場合は、確立または解放に対応する電文はない。したがって、確立または解放のカウンタ値が一致するだけでのエラー再現精度の低下を抑制するために、確立または解放の直前の受信（または送信）の電文が一致する場合に、エラー再現を行うようにするのが望ましい。但し、確立または解放のカウンタ値の一致だけでエラー再現を判定してもよい。

そこで、図１７での再現テストでは、初回テストのロギングルーチンで直前の受信の電文がログファイルに記録されている場合は、確立または解放カウンタ値が一致し（S130のYES）且つ直前の受信の電文が一致する場合（S131のYES）に、戻り値（復帰値）を「エラー応答要」に設定し（S132）、いずれかが不一致の場合は、戻り値（復帰値）を「正常」に設定する（S133）。

図１５に戻り、ドライバは、エラー応答の再現か否かのチェックルーチンS95の戻り値（復帰値）が「エラー応答要」の場合（S96のYES）、呼び出されたネットワークアクセスを実行せず、強制的にドライバの戻り値（復帰値）を「エラー応答」に設定する。これにより、ドライバが呼び出し元のプロセスにリターンする際、戻り値（復帰値）が「エラー応答」になり、強制的にエラー応答が再現される。

また、チェックルーチンS95の戻り値（復帰値）が「エラー応答要」でない場合、すなわち戻り値（復帰値）が「正常」の場合（S96のNO）、コールされたネットワークアクセスを実行し（S103）、エラー（異常）が発生すると（S104のYES）、ドライバはテスト対象プロセスに復帰せずに、コールされたネットワークアクセスをリトライする（S103）。このネットワークアクセスについてエラー（異常）が発生した場合は、リトライ回数が所定回数（例えば３回）に達するまで繰り返すことが好ましい。チェックルーチンS95の戻り値（復帰値）が「正常」の場合は、ネットワークアクセスがエラー応答を再現するタイミングでないアクセスであるので、通常のアクセスのようにエラー応答せず、ドライバがリトライを実行する。これにより、カウンタ値が＋１されることはなく、初回テストでのログに残したカウンタ値と、再現テストでログに残すカウンタ値とが同じ再現すべきタイミングで一致する可能性を高めることができる。

その後、ドライバは、今回の呼び出しの内容（コマンドコードと電文（直前の受信の電文））を、「前回呼び出し内容」レジスタに保存し（S98）、リトライでなければ（S99のNO）、ネットワークアクセスの種類に対応するカウンタ値を＋１し（S100）、戻り値（復帰値）と共に呼び出し元のプロセスにリターンする。このリトライでなければカウンタ値を＋１する処理は、図１１の初回テストでの工程S55,S56と同じである。よって、注目しているプロセスIDの注目しているネットワークアクセスでのカウンタ値は、初回テストでログに記憶したカウンタ値と再現テスト中にカウントしているカウンタ値とは一致する確率が高くなる。

再現テストでのロギングプログラムLGでの処理S40は、図１２の初回テストでの処理S40と同様である。

以上の通り、本実施の形態では、初回テスト時に発生したエラー応答を、再現テスト時に高い精度で再現することができる。それにより、初回テスト時に問題視された現象（例えばメインメモリの空き領域の不足）の原因と推測したエラー応答を再現テストで確実に再現することができるので、再現テストでも問題視された現象が繰り返されれば、推測したエラー応答が問題の現象の原因であると確証することができる。

本実施の形態におけるネットワークアクセスは、情報処理装置が実行するテスト対象プロセスが、ネットワークインターフェースを介してネットワーク経由でいずれかにアクセスする処理を含む。例えば、情報処理装置にIOバスを介して接続されたストレージ装置へのアクセスや、イントラネットやインターネットを介してアクセス可能なストレージ装置や他のサイトへのアクセスなどが含まれる。

以上の実施の形態をまとめると，次の付記のとおりである。

（付記１）
プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測し、
前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶し、
前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う、
処理をコンピュータに実行させるエラー再現プログラム。

（付記２）
前記ダミーのエラー応答を行うことは、前記ネットワークアセスを実行しないことを含む、付記１に記載のエラー再現プログラム。

（付記３）
前記ログを記憶部に記憶することは、前記ネットワークアクセスの内容も記憶することを含む、付記１に記載のエラー再現プログラム。

（付記４）
前記ネットワークアクセスの内容は、前記ネットワークアクセスの種類に加えて、前記ネットワークアクセスが送信の場合の送信電文、受信の場合の直前に受信した電文のいずれかを含む、付記３に記載のエラー再現プログラム。

（付記５）
前記累積アクセス数を計測することは、前記ネットワークアクセスのリトライは前記累積アクセス数として計測しないことを含む、付記１に記載にエラー再現プログラム。

（付記６）
さらに、
前記プロセスを新たに実行する前に、前記記憶部に記憶したログのうち、所望のログを抽出してエラー再現条件ログを生成し、
前記ダミーのエラー応答を行うことが、前記新たな実行開始からの累積アクセス数が、前記エラー再現条件ログに含まれる累積アクセス数と一致するか否か判定することを含む、付記１に記載のエラー再現プログラム。

（付記７）
前記プロセスを新たに実行する場合、前記プロセスによるネットワークアクセスの前記累積アクセス数が前記ログに含まれる累積アクセス数と不一致の場合、前記ネットワークアクセスを実行し、エラーが発生した場合累積アクセス数をカウントアップせずにリトライを実行する、付記１に記載のエラー再現プログラム。

（付記８）
さらに、
前記プロセスにより依頼された前記ネットワークアクセスを実行し、
前記ネットワークアクセスのエラーが発生した場合、エラー応答で前記ネットワークアクセスを終了し、
前記ネットワークアクセスが正常に完了した場合、正常応答で前記ネットワークアクセスを終了する、
処理をコンピュータに実行させる、付記１に記載のエラー再現プログラム。

（付記９）
プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測し、
前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶し、
前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う、
処理を有するエラー再現方法。

（付記１０）
プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測する手段と、
前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶する手段と、
前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う手段とを有する、エラー再現装置。

１４：ネットワークインターフェース
ＮＷ：ネットワーク
ＴＰ：テストプログラム
ＯＳ：オペレーティングシステム
ＤＲＶ：ドライバプログラム
ＬＰ：ロギングプログラム
ＰＵＴ：テスト対象プロセス
２５：ログファイル

Claims (8)

1. プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測し、
   前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶し、
   前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う、
   処理をコンピュータに実行させるエラー再現プログラム。
2. 前記ダミーのエラー応答を行うことは、前記ネットワークアクセスを実行しないことを含む、請求項１に記載のエラー再現プログラム。
3. 前記ログを記憶部に記憶することは、前記ネットワークアクセスの内容も記憶することを含む、請求項１に記載のエラー再現プログラム。
4. 前記ネットワークアクセスの内容は、前記ネットワークアクセスの種類に加えて、前記ネットワークアクセスが送信の場合の送信電文、受信の場合の直前に受信した電文のいずれかを含む、請求項３に記載のエラー再現プログラム。
5. 前記累積アクセス数を計測することは、前記ネットワークアクセスのリトライは前記累積アクセス数として計測しないことを含む、請求項１に記載のエラー再現プログラム。
6. さらに、
   前記プロセスを新たに実行する前に、前記記憶部に記憶したログのうち、所望のログを抽出してエラー再現条件ログを生成し、
   前記ダミーのエラー応答を行うことが、前記新たな実行開始からの累積アクセス数が、前記エラー再現条件ログに含まれる累積アクセス数と一致するか否か判定することを含む、請求項１に記載のエラー再現プログラム。
7. プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測し、
   前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶し、
   前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う、
   処理を有するエラー再現方法。
8. プロセスによるネットワークアクセスについて、前記のプロセスの実行開始からの累積アクセス数を計測する手段と、
   前記ネットワークアクセスのエラーの検知に応じて、前記検知時点の累積アクセス数を含むログを記憶部に記憶する手段と、
   前記プロセスが新たに実行された際に、前記プロセスによるネットワークアクセスを検知した際の前記プロセスの新たな実行開始からの累積アクセス数が、前記ログに含まれる累積アクセス数と一致する場合、前記プロセスに対してダミーのエラー応答を行う手段とを有する、エラー再現装置。

Images