JP2008186103A - 被テストプログラム資源競合テスト方法及び競合プログラム - Google Patents

Abstract

【課題】従来は、目視によるリソースの使用状態を監視しながら同時走行プログラムの走行パラメータや、多重起動、ループ回数等の設定を駆使し、微調整しながら手動で制御していたため、テスト担当者のスキルに依存しており、かつ、同一条件の再現性や長時間安定性、問題時の再現性においても、テストの信頼性に欠けていた。
【解決手段】コンピュータ上で動作するテスト対象の被テストプログラム２に対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、コンピュータ資源に対して意図的に該当資源を使用することで、コンピュータ資源の競合状態を作り出す機能を有する競合プログラム４により、被テストプログラム２の処理に外乱を与えて前記動作検証を行う。
【選択図】図１

Description

本発明は、コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法及びコンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する際に使用する競合プログラムに関するものである。

特に、本発明では、被テストプログラムと他のプログラムがシステムリソース（コンピュータ資源）を競合している環境下での被テストプログラムのテスト方法及び前記テストに使用する競合プログラムに関するものである。

(1) ：従来例１
従来、コンピュータのシステムリソース（コンピュータ資源）競合状態のテストでは、テスト対象の被テストプログラムと単純なステップで構成されたプログラムやスクリプト作成したり、又はメジャーなアプリケーションプログラムでシステムリソース競合発生の代用として、被テストプログラムと同時走行させることでテスト環境を構築していた。

また、目的とするシステムリソース競合条件の発生方法は、目視で各システムリソースの使用状態をシステムが持っているパフォーマンス機能等で目視で監視しながら、同時走行プログラムの走行パラメータや、多重起動、ループ回数等の設定をテストの実施者が駆使し、微調整しながら手動で制御していた。

図１３は従来のテストによるリソース使用率例である。図１３において、横軸はリソース名（コンピュータのハード資源名）、縦軸はリソース使用率（％）である。この場合、前記リソース名は、ＣＰＵ、メモリ、Ｉ／Ｏ、ネットワーク等のハード資源が含まれる。また、図１３中、Ａ、Ｂ、Ｃ、Ｄはそれぞれ変動率（％）を示す。

従来例１のテストでは、目視によるリソースの使用状態を監視しながら同時走行プログラムの走行パラメータや、多重起動、ループ回数等の設定を駆使し、微調整しながら手動で制御していたため、テスト担当者のスキルに依存しており、かつ、同一条件の再現性や長時間安定性、問題時の再現性においても、テストの信頼性に欠けていた。

信頼性に欠けていた理由は次の通りである。

(a) ：ツールが狙ったリソースを使用するか不明である。

(b) ：ツールがリソースを適当なタイミングで使用するため、競合状態が変動する。

(c) ：テスト担当者のツールの内容の理解度にバラツキがある。

(d) ：被テストプログラムとツール（プログラム）のタイミングが取れない（人手によるため）。

従って、リソースの使用率は、競合させるプログラムにより大きく変動する。図１３の例は、サーバのデータ上を表計算アプリケーションプログラムで操作（グラフ作成）するような場合の例であり、時間的にみると大きく変動している（図のＡ乃至Ｄの変動率を参照）。すなわち、図１３の例では、各リソースの使用率が全体の半分以上変動していることが明らかである。

(2) ：従来例２
以下、特許文献１を従来例２として説明する。従来例２には次のような内容が記載されている。

(a) ：「この発明は、試験環境に対する負荷量を自動調整することを目的とする。」・・・要約の欄を参照。

(b) ：「情報処理機器にて性能測定処理実行手段を実行し、負荷処理実行手段は、情報処理機器に対して負荷情報記憶手段に記憶された任意の負荷プログラムを同時実行数分、並行して実行する。エラー状態確認手段では、負荷プログラムによる負荷によって情報処理機器でエラーが起きていないかをチェックする。エラーが発生していなかった場合には、事前性能予測手段は、再度同時実行数に加減値を加算する処理に戻る。逆にエラーが発生していた場合には、事前性能予測手段は、先ず、同時実行数を一つ前の状態に戻す。次に、前回用いた加減値を半分にする。その結果、加減値が０となった場合には、同時実行数を評価時に掛ける負荷量と予測する。」・・・要約の欄を参照。

(3) ：従来例３
以下、特許文献２を従来例３として説明する。従来例３には次のような内容が記載されている。

(a) ：「負荷を適用することによってコンピュータシステムをテストする。」・・・要約の欄を参照。

(b) ：「負荷仕様を受け取ることであって、当該負荷仕様が、システムの少なくとも１つの資源を特定し、かつ、当該資源に適用される負荷を指定する。負荷仕様を受け取ることと、および負荷仕様で特定された各資源について、対応する指定された負荷を当該資源に適用することとを含む。」・・・要約の欄を参照。

(4) ：従来例４
以下、特許文献３を従来例４として説明する。従来例４には次のような内容が記載されている。

(a) ：「人手操作無しに、自動的に試験プログラムの組合わせの制御を行い、計算機内部の該バスの負荷を自動的に変動させて試験の効率化を図る、バス負荷試験方法の提供。」・・・要約の欄を参照。

(b) ：「システムバス、ＩＯバス等の複数のバスを含む計算機システムのバス負荷試験方法において、各バス毎に、該バスに負荷を与えるプログラムの組合わせを予め記述した組合わせ記述データをバス負荷試験条件に対応して記憶しておき、バス負荷試験時に前記組合わせ記述データを順次読み込み、今回読み込んだ組合わせ記述データと前回読込んだ組合わせ記述データとの差分を抽出して、この差分から終了させるべきプログラムを終了し、起動させるべきプログラムを起動する。」・・・要約の欄を参照。
特開２００４−３２６３８６号公報 特開２００５−１８２８１３号公報 特開平１１−２４９５４号公報

(1) ：従来例１では、目視によるリソースの使用状態を監視しながら同時走行プログラムの走行パラメータや、多重起動、ループ回数等の設定を駆使し、微調整しながら手動で制御していたため、テスト担当者のスキルに依存しており、かつ、同一条件の再現性や長時間安定性、問題時の再現性においても、テストの信頼性に欠けていた。

(2) ：従来例２には、試験環境に対する負荷量を自動調整することが記載されている。しかし、従来例２はシステムリソースのテストであって、本発明の参考程度の技術である。

(3) ：従来例３には、負荷を適用することによってコンピュータシステムをテストすることが記載されている。しかし、従来例３はシステムリソース（ハード資源）のテストであって、本発明の参考程度の技術である。

(4) ：従来例４には、人手操作無しに、自動的に試験プログラムの組合わせの制御を行い、計算機内部の該バスの負荷を自動的に変動させて試験の効率化を図る、バス負荷試験方法が記載されている。しかし、従来例４には、本発明のような被テストプログラムのテストに関しては記載されておらず、本発明の参考程度の技術である。

(5) ：従来、一般に、プログラムのテストでは、テスト環境の構築内容により、テストで問題を検出できる範囲（テストカバレッジ）が左右され、また、問題発生時の原因調査の容易さに大きく影響する。

このため、テストカバレッジを明確にしたテストの場合、および問題の原因特定に主眼を置いた場合、競合プログラムとして次の条件が求められる。

(a) ：テスト環境には同一条件の再現性があること。

(b) ：テスト環境の状態を長時間、安定させることができること。

(c) ：テスト環境の構築が、担当者のスキルに依存せず、誰でも均一な環境が構築できること。

(d) ：システムのハード性能に合わせテスト環境を調整できること。

しかし、従来のテストでは、前記条件を満たしていなかった。

本発明は従来の課題を解決するためになされたものであり、競合プログラムとして、前記(a) 乃至(d) の条件を満たすようにすることで、効率良く、効果的なテスト環境を提供することを目的とする。

本発明は前記の目的を達成するため、次のように構成した。

(1) ：コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、前記コンピュータ資源に対して、意図的に該当資源を使用することで、前記コンピュータ資源の競合状態を作り出す機能を有する競合プログラムにより、前記被テストプログラムの処理に外乱を与えて前記動作検証を行うことを特徴とする。

(2) ：コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、前記被テストプログラムが使用するコンピュータ資源のアクセスパターンを測定し、前記測定したアクセスパターンを狙って、意図的に該当資源を使用することでコンピュータ資源の競合状態を作り出す機能を有する競合プログラムにより、前記被テストプログラムの処理に外乱を与えて前記動作検証を行うことを特徴とする。

(3) ：コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、前記コンピュータ資源の使用率の設定値と測定した使用率を比較し、各コンピュータ資源の使用率を調整及び制御を行う機能を有する競合プログラムを用い、前記被テストプログラムが使用するコンピュータ資源に対し、前記競合プログラムの資源使用率を意図した値に制御することで、狙った割合の競合状態を生成し、前記被テストプログラムの処理に、狙った外乱を与えて前記動作検証を行うことを特徴とする。

(4) ：コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する際に使用する競合プログラムであって、全体の制御を行う機能を有する競合発生制御部と、コンピュータ資源の使用率を測定する機能を有する使用率測定モジュールと、コンピュータ資源の使用率の設定値と測定した使用率を比較し、コンピュータ資源の使用率を調整及び制御する機能を有する使用率制御モジュールと、スケジュールに従い、競合の発生を制御する機能を有するスケジュール制御モジュールと、コンピュータ資源の実測した使用率と競合発生モジュールの対応テーブルであるリソース使用率測定テーブルと、コンピュータ資源の競合を発生させる機能を有する複数の競合発生モジュールで構成された競合発生モジュール群と、被テストプログラムのコンピュータ資源アクセスをトレースし、アクセスパターンをテーブル化する機能を有する被テストプログラム測定モジュールとを備えていることを特徴とする競合プログラム。

（作用）
以下、前記構成に基づく本発明の作用を説明する。

(a) ：前記(1) の作用
コンピュータ資源に対して、意図的に該当資源を使用することで、コンピュータ資源の競合状態を作り出す機能を有する競合プログラムにより、被テストプログラムの処理に外乱を与えて動作検証を行う。このようにすれば、競合プログラムとして、前記「発明が解決しようとする課題」の(a) 乃至(d) に記載した条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

すなわち、前記(1) では、(a) ：テスト環境には同一条件の再現性があること、(b) ：テスト環境の状態を長時間、安定させることができること、(c) ：テスト環境の構築が、担当者のスキルに依存せず、誰でも均一な環境が構築できること、(d) ：システムのハード性能に合わせテスト環境を調整できること、の各条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

(b) ：前記(2) の作用
被テストプログラムが使用するコンピュータ資源のアクセスパターンを測定し、前記測定したアクセスパターンを狙って、意図的に該当資源を使用することでコンピュータ資源の競合状態を作り出す機能を有する競合プログラムにより、被テストプログラムの処理に外乱を与えて前記動作検証を行う。

このようにすれば、競合プログラムとして、前記「発明が解決しようとする課題」の(a) 乃至(d) に記載した条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

(c) ：前記(3) の作用
コンピュータ資源の使用率の設定値と測定した使用率を比較し、各コンピュータ資源の使用率を調整及び制御を行う機能を有する競合プログラムを用い、前記被テストプログラムが使用するコンピュータ資源に対し、前記競合プログラムの資源使用率を意図した値に制御することで、狙った割合の競合状態を生成し、前記被テストプログラムの処理に、狙った外乱を与えて動作検証を行う。

このようにすれば、競合プログラムとして、前記「発明が解決しようとする課題」の(a) 乃至(d) に記載した条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

(d) ：前記(4) の作用
コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する際に使用する競合プログラムは、全体の制御を行う機能を有する競合発生制御部と、コンピュータ資源の使用率を測定する機能を有する使用率測定モジュールと、コンピュータ資源の使用率の設定値と測定した使用率を比較し、コンピュータ資源の使用率を調整及び制御する機能を有する使用率制御モジュールと、スケジュールに従い、競合の発生を制御する機能を有するスケジュール制御モジュールと、コンピュータ資源の実測した使用率と競合発生モジュールの対応テーブルであるリソース使用率測定テーブルと、コンピュータ資源の競合を発生させる機能を有する複数の競合発生モジュールで構成された競合発生モジュール群と、被テストプログラムのコンピュータ資源アクセスをトレースし、アクセスパターンをテーブル化する機能を有する被テストプログラム測定モジュールとを備えている。

従って、このような競合プログラムを使用して被テストプログラムの資源競合状態を発生させて動作検証を行うことができるので、競合プログラムとして、前記「発明が解決しようとする課題」の(a) 乃至(d) に記載した条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

本発明は請求項１乃至４により次のような効果がある。

(1) ：競合プログラムとして、前記「発明が解決しようとする課題」の(a) 乃至(d) に記載した条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

すなわち、本発明は、(a) ：テスト環境には同一条件の再現性があること、(b) ：テスト環境の状態を長時間、安定させることができること、(c) ：テスト環境の構築が、担当者のスキルに依存せず、誰でも均一な環境が構築できること、(d) ：システムのハード性能に合わせテスト環境を調整できること、の各条件を満たすので、効率良く、効果的なテスト環境を提供することができる。

(2) ：競合プログラムの競合モジュール構造と制御により、環境は同一条件の再現性が高い。

(3) ：競合プログラムの競合モジュール構造と制御により、競合状態は長時間安定している。

(4) ：競合プログラムによりリソース使用率を自動制御するため、環境の構築は担当者のスキルに依存しない。

(5) ：競合プログラムによりリソース使用率を測定するため、ハード性能に合わせて調整可能である。

(6) ：競合プログラムを使用することにより、各リソース毎のリソース競合状態使用率の変動は、従来例に比べて極めて少なくなっており、変動は最少である。

(7) ：競合プログラムを使用することにより、テスト環境の競合状態を予めスケジュールし、スケジュール制御モジュールと連携することで、テストの自動化が容易になる。

§１：テストの概要説明
図１は本発明の原理説明図である。以下、図１に基づいてテストの概要を説明する。

(1) ：被テストプログラム資源競合テスト方法は、コンピュータ上で動作するテスト対象の被テストプログラム２（ハードディスク装置２６内に格納されている）に対し、コンピュータ資源の競合に関して動作検証する。この場合、コンピュータ資源（例えば、ＣＰＵ２５、メモリ２７、Ｉ／Ｏ制御部２８、通信制御部２９を含むハードウエア資源）に対して、意図的に該当資源を使用することで、コンピュータ資源の競合状態を作り出す機能を有する競合プログラム４により、被テストプログラム２の処理に外乱を与えて動作検証を行う。

(2) ：被テストプログラム資源競合テスト方法は、コンピュータ上で動作するテスト対象の被テストプログラム２（ハードディスク装置２６内に格納されている）に対し、コンピュータ資源の競合に関して動作検証する。この場合、被テストプログラム２が使用するコンピュータ資源（例えば、ＣＰＵ２５、メモリ２７、Ｉ／Ｏ制御部２８、通信制御部２９を含むハードウエア資源）のアクセスパターンを測定し、前記測定したアクセスパターンを狙って、意図的に該当資源を使用することでコンピュータ資源の競合状態を作り出す機能を有する競合プログラム４により、前記被テストプログラム２の処理に外乱を与えて動作検証を行う。

(3) ：被テストプログラム資源競合テスト方法は、コンピュータ上で動作するテスト対象の被テストプログラム２（ハードディスク装置２６内に格納されている）に対し、コンピュータ資源の競合に関して動作検証する。この場合、コンピュータ資源（例えば、ＣＰＵ２５、メモリ２７、Ｉ／Ｏ制御部２８、通信制御部２９を含むハードウエア資源）の使用率の設定値と測定した使用率を比較し、各コンピュータ資源の使用率を調整及び制御を行う機能を有する競合プログラム４を用い、被テストプログラム２が使用するコンピュータ資源に対し、競合プログラム４の資源使用率を意図した値に制御することで、狙った割合の競合状態を生成し、被テストプログラム２の処理に、狙った外乱を与えて前記動作検証を行う。

(4) ：コンピュータ上で動作するテスト対象の被テストプログラム２（ハードディスク装置２６内に格納されている）に対し、コンピュータ資源（例えば、ＣＰＵ２５、メモリ２７、Ｉ／Ｏ制御部２８、通信制御部２９を含むハードウエア資源）の競合に関して動作検証する際に使用する競合プログラム４は、全体の制御を行う機能を有する競合発生制御部１１と、コンピュータ資源の使用率を測定する機能を有する使用率測定モジュール１２と、コンピュータ資源の使用率の設定値と測定した使用率を比較し、コンピュータ資源の使用率を調整及び制御する機能を有する使用率制御モジュール１３と、スケジュールに従い、競合の発生を制御する機能を有するスケジュール制御モジュール１４と、コンピュータ資源の実測した使用率と競合発生モジュールの対応テーブルであるリソース使用率測定テーブル１５と、コンピュータ資源の競合を発生させる機能を有する複数の競合発生モジュールで構成された競合発生モジュール群１６と、被テストプログラムのコンピュータ資源アクセスをトレースし、アクセスパターンをテーブル化する機能を有する被テストプログラム測定モジュール１７とを備えている。

なお、前記「コンピュータ資源」という用語は、コンピュータ上の資源（ＣＰＵ２５、メモリ２７、Ｉ／Ｏ制御部２８、通信制御部２９を含む資源）を対象とした用語であり、資源、コンピュータ資源、システムリソース、リソース等の用語で呼ばれることもあるが、以下の説明では、「リソース」という用語を用いて説明する。また、前記「被テストプログラム資源競合テスト方法」のことを、単に「テスト方法」とも記す。

§２：テスト方法の概念の説明
図２はテスト方法の概念図である。以下、図２に基づいて、テスト方法の概念を説明する。

一般にコンピュータ１上では、複数のプログラムが同時に動作しており、コンピュータ１の各種リソース（ＣＰＵ、メモリ、Ｉ／Ｏ、ネットワーク等）を取り合いながら処理を続けている。しかし、プログラム（被テストプログラム２）はリソース３の競合状態においても、正しく処理する安定性が求められており、プログラムの動作検証（以降も「テスト」と記す）においては、コンピュータ１の各種リソース競合状態における機能の安定性をテストする事は重要事項である。

図２は、このリソース競合状態におけるテスト方法の概念図であるが、被テストプログラム２に対して、リソース３の競合状態を発生させる競合プログラム４を同時に走行させてテストを行うものである。競合プログラム４としては、テストの狙いとするリソース３の競合状態を発生させる機能が必要になる。この場合、競合プログラム４が対象とするリソース３の競合は、ＣＰＵ、メモリ、Ｉ／Ｏ、ネットワーク等のハード資源である。

§３：コンピュータの構成例の説明
図３はコンピュータの構成例である。この例では、コンピュータ１（コンピュータ本体）には入力部２１、表示装置２２やネットワーク等が接続されている。また、コンピュータ１の内部には、ＣＰＵ２５、メモリ２７、Ｉ／Ｏ制御部２８、通信制御部２９、ハードディスク装置（ＨＤＤ）２６等のリソース（資源）が設けてある。そして、前記ハードディスク装置２６の記憶媒体（ハードディスク）には、ＤＢ（データベース）５、被テストプログラム２、競合プログラム４等が格納されている。

§４：競合プログラムの説明
(1) ：競合プログラムの構成の説明
図４は競合プログラムの構成例である。図４に示したように、競合プログラム４には、競合発生制御部１１と、使用率測定モジュール１２と、使用率制御モジュール１３と、スケジュール制御モジュール１４と、リソース使用率測定テーブル１５と、競合発生モジュール群１６と、被テストプログラム測定モジュール１７が設けてある。前記各部の機能等は次の通りである。

(a) ：競合発生モジュール群１６は、各リソース（ＣＰＵ、メモリ、Ｉ／Ｏ、ネットワーク等の資源）の競合を発生させる機能を有する複数の競合発生モジュールで構成されている。

(b) ：使用率測定モジュール１２は、各リソース（ＣＰＵ、メモリ、Ｉ／Ｏ、ネットワーク等の資源）の使用率を測定する機能を有する。

(c) ：使用率制御モジュール１３は、使用率の設定値と測定した使用率を比較し、各リソース（ＣＰＵ、メモリ、Ｉ／Ｏ、ネットワーク等の資源）の使用率を調整及び制御する機能を有する。

(d) ：スケジュール制御モジュール１４は、スケジュールに従い、競合の発生を制御する機能を有する。

(e) ：リソース使用率測定テーブル１５は、実測した使用率と使用率測定モジュール１２の対応テーブルである。

(f) ：被テストプログラム測定モジュール１７は、被テストプログラム２のリソースアクセスをトレースし、アクセスパターンをテーブル化するものである。

(2) ：競合プログラムの動作の説明
競合プログラムの動作は次の通りである。

競合発生制御部１１は、テスト実施者が期待する競合状態（競合プログラム４のリソース使用状態）の指示に従い、使用率制御モジュール１３に対し指示を出す。使用率制御モジュール１３は、使用率測定モジュール１２により、リソース使用率を監視し、競合発生モジュール群１６を制御することで、リソース使用率が指示値になるようにする。

ここで、競合発生モジュール群１６の各競合発生モジュールは、各リソースに対して単純な使用をするもので、ＣＰＵ２５は外部アクセスしない演算命令列（数キロステップ程度）、メモリ２７では連続領域の参照（数キロバイト程度）、Ｉ／Ｏ（Ｉ／Ｏ制御部２８）ではレコードの読み込み（数レコード程度）、ネットワークではＰＩＮＧ（数回程度）の単純な構成として、リソースの大小の制御は、例えば、同時実行プログラムの多重度で制御するものとする。

(3) ：競合プログラムの特徴の説明
以上の通り、各競合発生モジュールをリソース使用に特化し、かつ単純に構成し、繰り返すのみとして余計な動作をしない事で、次のような特徴が得られる。

(a) ：同一条件の再現性が高められる。

(b) ：リソース使用状態が長時間安定している。

また、リソース使用率は、自動的に行われるため、競合環境の構築は競合プログラム４への指示に統一され、特にスキルに依存しない。

なお、リソース使用率は、ハードウェア性能に依存することから、予め競合発生モジュールの走行条件とリソース使用率の関係を測定し、リソース使用率測定テーブル１５に記録する。テスト実施時に、競合プログラム４は指示されたリソース使用率に該当する条件を、リソース使用率測定テーブル１５から読み出し、競合発生モジュール群１６を制御する。

以上のことをまとめると、次のような特徴が得られる。

(a) ：競合モジュール構造と制御により、環境は同一条件の再現性が高い。

(b) ：競合モジュール構造と制御により、競合状態は長時間安定している。

(c) ：リソース使用率を自動制御するため、環境の構築は担当者のスキルに依存しない。

(d) ：リソース使用率を測定するため、ハード性能に合わせて調整可能である。

(4) ：リソース使用率等の説明
図５は本発明のテストによるリソース使用率例である。図５において、横軸はリソース名（ハード資源名）、縦軸は各リソース毎のリソース使用率（％）を示す。また、図５のＡ、Ｂ、Ｃ、Ｄはそれぞれ変動率（％）を示している。

図５から明らかなように、各リソース毎のリソース競合状態使用率の変動は、従来例に比べて極めて少なくなっており、変動は最少である。

更に、テスト環境の競合状態を予めスケジュールし、スケジュール制御モジュール１４と連携することで、テストの自動化が容易になる。

(5) ：その他の説明
被テストプログラム２はブラックボックスであるため、リソースへのアクセスがどのように行われるかが不明であり、競合プログラム４のみでは狙いとするリソース競合状態を起こすことはできない。

そこで、被テストプログラム２のリソースへのアクセスパターンを知るために、被テストプログラム２を単独で走行させ、この時のリソースアクセスを競合プログラム４がトレースして記録し、記録されたトレースデータからリソースのアクセスパターンを得て、このパターンを基に競合プログラム４を制御することで、リソースへのアクセス競合を発生させるものである。

図６はアクセスパターンテーブル例、アクセスパターン例及びスケジュール機能による競合環境の変化例であり、図６のＡ図はアクセスパターンのテーブル例である。

被テストプログラム測定モジュール１７は、被テストプログラム２が各リソースへのアクセス時間（時間）、アクセス間隔（時間）、データの方向（読み／書き）、データの大きさ（バイト）、等のトレースを測定し、このトレースデータをアクセスパターンとしてテーブル化するものである。

競合プログラム４によるリソースアクセス競合のテスト時は、スケジュール制御モジュール１４が、アクセスパターンのテーブルの値をパラメータとして入力し、競合発生モジュール群１６を制御して、リソースの競合を発生させる。

§５：テスト時における競合プログラムの処理等の概要説明
競合プログラムの処理は以降に説明する（図７〜図１２参照）に示すが、テスト時において競合プログラムは、次のような処理を行う。この例では、テストの順番を、Ａ：リソース使用率測定、Ｂ：競合発生、Ｃ：被テストプログラム測定の３つに分けている。以下、これらの処理について説明する。

Ａ：リソース使用率測定の概要
この処理では、先ず、リソース使用率がハードウェアの環境に依存するため、テストの初めに、リソース使用率の測定を実施し、テストで使用する各種のリソース使用率が発生する条件を、リソースの使用率測定テーブル１５に記録する処理を行う。

使用率測定テーブル１５の各項の若い順に、使用率条件を期待値として、競合発生モジュール群１６内の指示した競合発生モジュールを走行させながらリソース使用率測定を行い、リソース使用率が期待値になる様に競合発生モジュール群１６を追加起動させる（例では、多重度を制御する）。期待したリソース使用率条件に達したところで、この時の発生条件をリソース使用率測定テーブル１５に記録し、次の項の測定を行う。テーブルを全部埋めたところで、測定を完了する。

Ｂ：競合発生の概要
次に、競合発生であるが、発生させたい競合状態（リソースの使用率）に対応して、競合発生モジュール群１６内の競合発生モジュールの走行条件（本例では、多重度）がリソース使用率測定テーブル１５に作成してあり、該当の条件でスケジュール制御モジュール１４が起動する。

Ｃ：被テストプログラム測定の概要
更に、競合発生モジュール群１６の競合発生モジュールは、アクセス時間やアクセス間隔、ライト／リード（Ｗｒｉｔｅ／Ｒｅａｄ）、データ長のパラメータをスケジュール制御モジュール１４から渡され、そのパラメータに従って動作する。

§６：テスト時における競合プログラムの処理等の具体例の説明
(1) ：被テストプログラム測定の具体例
図６のＢ図はアクセスパターン例を示した図、図６のＣ図はスケジュール機能による競合環境の変化例である。

例として、或る特定のリソースに対して、図６のＢ図の（Ａ）のようなリソースアクセスがトレースされた場合、トレーステーブル（図１２のＡ図参照）の各要素を最大／最少／平均等の丸め処理により、アクセスパターンテーブル（図６のＡ図参照）には、図６のＢ図の（Ｂ）や図６のＢ図の（Ｃ）のようなアクセスパターンが生成される。

なお、リソースアクセスのトレースからアクセスパターンテーブルに変換する処理をより緻密に行い、アクセスパターンテーブルの各値（パラメータ）を増やす等の処理を行うことで、より正確なリソースのアクセス競合状態が実現できる。

また、この例の発展例として、以下の機能も考えられる。

(a) ：予め、リソース使用率測定はせずに、競合発生時点で使用率測定を行いながら使用率条件に近づける制御方法。（測定時間の短縮効果が期待できる。）
(b) ：競合発生モジュールの内部動作に、リソースの使用方法等制御できる機能を持ち、外部から指示するパラメータで制御できるようにし、使用率測定時にパラメータ設定することでリソース使用率の条件をきめ細かく制御できる方法。（テスト精度の向上ができる。）
(c) ：競合発生の制御部に、スケジュール機能を持たせ、予め作ったスケジュールに従い、競合条件を制御する方法。（各種競合条件のテストが自動化され、テストの効率化が期待できる。）（図６のＣ図参照）

§７：競合プログラムのフローチャート等による説明
図７は競合プログラムの処理フローチャート（その１）、図８は競合プログラムの処理フローチャート（その２）、図９は競合プログラムの処理フローチャート（その３）、図１０はリソース使用率測定テーブル例／競合モジュール群の説明図であり、図１０のＡ図はリソース使用率測定テーブル例、図１０のＢ図は競合発生モジュール群の説明図である。

以下、図７乃至図１０に基づいて、競合プログラムの処理を説明する。なお、図７乃至図１０において、Ｓ１〜Ｓ２０は各処理ステップを示す。また、Ｓ１乃至Ｓ６の処理は使用率制御モジュール１３が行う競合状態生成の処理であり、Ｓ７乃至Ｓ２０は使用率測定モジュール１２が行うリソース使用率測定処理である。

先ず、リソース使用率測定か否かを判定し（Ｓ１）、リソース使用率測定でなければ、テストか否かを判定する（Ｓ２）。その結果、テストでなければ、被テストプログラム測定（後述する処理を参照）を行い、テストであれば、外部から指示されたリソース使用率に該当する項をリソース使用率測定テーブル１５から探す（Ｓ３）。

次に、アクセスパターンテーブルの値を、競合発生モジュール群１６の走行条件としてパラメータ渡しする（Ｓ４）。次に、リソース使用率測定テーブル１５の条件に従い、競合発生モジュール群１６から選択し、起動する（Ｓ５）。そして、競合状態の生成完了となる（Ｓ６）。

また、Ｓ１の処理で、リソース使用率測定であると判断した場合には、次のようにリソース使用率測定の処理を行う。先ず、リソース使用率測定テーブル１５を初期化し（Ｓ７）、リソース使用率測定テーブル１５のポインタの初期化を行い（Ｓ８）、競合発生モジュール群１６のポインタを初期化する（Ｓ９）。

次に、競合発生モジュール群１６のポインタが指す競合発生モジュールを起動し（Ｓ１０）、リソース使用率測定を行う（Ｓ１１）。次に、リソース使用率は予定より低いかどうかを判断し（Ｓ１２）、リソース使用率が予定より低い場合には、同じ競合発生モジュールを起動し（Ｓ１３）、Ｓ１０の処理へ移行する。

また、Ｓ１２の処理において、リソース使用率が予定より低くない場合には、リソース使用率測定テーブル１５にモジュール数（多重度）を記録し（Ｓ１４）、競合発生モジュール群１６のポインタが指す競合発生モジュールを停止する（Ｓ１５）。

次に、リソース使用率測定ポインタを更新し（Ｓ１６）、競合発生モジュール群１６のポインタを更新する（Ｓ１７）。次に、競合発生モジュール群１６のポインタが指す競合発生モジュールを起動する（Ｓ１８）。そして、競合発生モジュール群１６のポインタは最後まで終わったかを判断し（Ｓ１９）、最後まで終わっていなければ、Ｓ１０の処理へ移行し、最後まで終わっていれば、リソース使用率測定完了とする（Ｓ２０）。

前記リソース使用率測定テーブル例は図１０のＡ図に示した通りである。この例では、項が１乃至ｎで、各項毎に、リソース使用率（％）と、各リソース（ハード資源）毎の多重度のデータが記載されるようになっている。そして、ポインタ（リソース使用率測定テーブルのポインタ）がどの項を選択するかを示している。なお、意図した値は、ｎ項の１００％である。

また、図１０のＢ図に示すように、競合発生モジュール群１６には複数の競合発生モジュールが含まれており、どの競合発生モジュールを選択するかを指定するためにポインタが設けてある。すなわち、このポインタ（競合発生モジュール群１６のポインタ）により選択する競合発生モジュールを指定できるようになっている。

§８：被テストプログラムの測定処理フローチャート等による説明
図１１は被テストプログラムの測定処理フローチャートである。また、図１２はトレーステーブル例／アクセスパターンテーブル例であり、図１２のＡ図はトレーステーブル例、図１２のＢ図はアクセスパターンテーブル例である。

以下、図１１、図１２に基づいて、被テストプログラムの測定処理を説明する。なお、図１１において、Ｓ３１〜Ｓ４０は各処理ステップを示す。また、以下の処理は、被テストプログラム測定モジュール１７が行う処理である。

先ず、トレーステーブル（図１２のＡ図参照）を初期化し（Ｓ３１）、リソースアクセスのシステムコールをフックする（Ｓ３２）。次に、フックされて得られたパラメータからリソースを特定し、かつ、ライト／リード（Ｗｒｉｔｅ／Ｒｅａｄ）及びデータ長を求め、トレーステーブルに記録する（Ｓ３３）。

そして、トレーステーブルを更新し（Ｓ３４）、測定（被テストプログラムの測定）完了かどうかを判定する（Ｓ３５）。その結果、測定完了でなければＳ３３の処理へ移行し、測定完了ならば、アクセスパターンテーブル（図１２のＢ図参照）を初期化し（Ｓ３６）、トレーステーブルから同じリソースを抽出（ソート）する（Ｓ３７）。

次に、同じリソースの平均／最大／最小アクセス時間及びアクセス間隔、ライト／リード（Ｗｒｉｔｅ／Ｒｅａｄ）、データ長（最大／平均／最小）を求め、アクセスパターンテーブルに記録し（Ｓ３８）、テーブルは終わりか否かを判断する（Ｓ３９）。その結果、テーブルが終わりでなければＳ３８の処理へ移行し、テーブルが終わりであれば測定完了とする（Ｓ４０）。

なお、トレーステーブル例は図１２のＡ図の通りであり、アクセスパターンテーブル例は図１２のＢ図に示す。前記トレーステーブル例では、リソース名、データ方向、データ長、時刻の項目が設けてあり、各項目毎にデータが記録されている。例えば、リソース名＝リソース−ａでは、データ方向＝Ｗｒｉｔｅ、データ長＝Ｌ１、時刻＝Ｔ１となっており、リソース名＝リソース−ｂでは、データ方向＝Ｗｒｉｔｅ、データ長＝Ｌ２、時刻＝Ｔ２となっており、以下同様にして各項目毎にデータが記録されている。

また、アクセスパターンテーブル例では、リソース名、アクセス時間、アクセス間隔、データ方向、データ長の各項目が設けてあり、各項目毎にデータが記録されている。例えば、リソース名＝リソース−ａでは、アクセス時間＝ｔ１、アクセス間隔＝Ａ１、データ方向＝ライト（Ｗｒｉｔｅ）、データ長＝Ｓ１となっており、リソース名＝リソース−ｂでは、アクセス時間＝ｔ２、アクセス間隔＝Ａ２、データ方向＝ライト（Ｗｒｉｔｅ）、データ長＝Ｓ２となっており、以下同様にして各項目毎にデータが記録されている。

本発明の原理説明図である。 実施の形態におけるテスト方法の概念図である。 実施の形態におけるコンピュータの構成例である。 実施の形態における競合プログラムの構成例である。 実施の形態における本発明のテストによるリソース使用率例である。 実施の形態におけるアクセスパターンテーブル例、アクセスパターン例及びスケジュール機能による競合環境の変化例である。 実施の形態における競合プログラムの処理フローチャート（その１）である。 実施の形態における競合プログラムの処理フローチャート（その２）である。 実施の形態における競合プログラムの処理フローチャート（その３）である。 実施の形態におけるリソース使用率測定テーブル例／競合モジュール群の説明図であり、Ａ図はリソース使用率測定テーブル例、Ｂ図は競合発生モジュール群の説明図である。 実施の形態における被テストプログラム測定処理フローチャートである。 実施の形態におけるトレーステーブル例／アクセスパターンテーブル例であり、Ａ図はトレーステーブル例、Ｂ図はアクセスパターンテーブル例である。 従来のテストによるリソース使用率例である。

符号の説明

１ コンピュータ
２ 被テストプログラム
３ リソース（コンピュータ資源）
４ 競合プログラム
１１ 競合発生制御部
１２ 使用率測定モジュール
１３ 使用率制御モジュール
１４ スケジュール制御モジュール
１５ リソース使用率測定テーブル
１６ 競合発生モジュール群
１７ 被テストプログラム測定モジュール
２１ 入力部
２２ 表示装置
２５ ＣＰＵ
２６ ハードディスク装置
２７ メモリ
２８ Ｉ／Ｏ制御部
２９ 通信制御部

Claims (4)

1. コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、
   前記コンピュータ資源に対して、意図的に該当資源を使用することで、前記コンピュータ資源の競合状態を作り出す機能を有する競合プログラムにより、前記被テストプログラムの処理に外乱を与えて前記動作検証を行うことを特徴とする被テストプログラム資源競合テスト方法。
2. コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、
   前記被テストプログラムが使用するコンピュータ資源のアクセスパターンを測定し、前記測定したアクセスパターンを狙って、意図的に該当資源を使用することでコンピュータ資源の競合状態を作り出す機能を有する競合プログラムにより、前記被テストプログラムの処理に外乱を与えて前記動作検証を行うことを特徴とする被テストプログラム資源競合テスト方法。
3. コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する被テストプログラム資源競合テスト方法において、
   前記コンピュータ資源の使用率の設定値と測定した使用率を比較し、各コンピュータ資源の使用率を調整及び制御を行う機能を有する競合プログラムを用い、
   前記被テストプログラムが使用するコンピュータ資源に対し、前記競合プログラムの資源使用率を意図した値に制御することで、狙った割合の競合状態を生成し、前記被テストプログラムの処理に、狙った外乱を与えて前記動作検証を行うことを特徴とする被テストプログラム資源競合テスト方法。
4. コンピュータ上で動作するテスト対象の被テストプログラムに対し、コンピュータ資源の競合に関して動作検証する際に使用する競合プログラムであって、
   全体の制御を行う機能を有する競合発生制御部と、
   コンピュータ資源の使用率を測定する機能を有する使用率測定モジュールと、
   コンピュータ資源の使用率の設定値と測定した使用率を比較し、コンピュータ資源の使用率を調整及び制御する機能を有する使用率制御モジュールと、
   スケジュールに従い、競合の発生を制御する機能を有するスケジュール制御モジュールと、
   コンピュータ資源の実測した使用率と競合発生モジュールの対応テーブルであるリソース使用率測定テーブルと、
   コンピュータ資源の競合を発生させる機能を有する複数の競合発生モジュールで構成された競合発生モジュール群と、
   被テストプログラムのコンピュータ資源アクセスをトレースし、アクセスパターンをテーブル化する機能を有する被テストプログラム測定モジュールと、
   を備えていることを特徴とする競合プログラム。

Images