(57)【要約】【課題】システムの運用環境に影響を与えずに性能ボトルネックとその原因及び位置を識別するためにデータ収集するシステムテスト方法を提供する。  【０００８】    本発明は、プロセス制御ブロック（Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）の位置を識別するステップと、プロセス制御ブロックの位置に接近するステップと、プロセス制御ブロックの性能要素をモニタリングするステップとを含み、前記プロセス制御ブロックは、カーネルメモリ内部に位置することを特徴とする。。【選択図】図１
2013533553.tif 000002
【特許請求の範囲】
【請求項１】
プロセス制御ブロック（Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）の位置を識別するステップと、
前記プロセス制御ブロックの位置に接近するステップと、
前記プロセス制御ブロックの性能要素をモニタリングするステップと
を含むことを特徴とするシステムテスト方法。
【請求項２】
前記プロセス制御ブロックは
カーネルメモリ内部に位置することを特徴とする請求項１に記載のシステムテスト方法。
【請求項３】
前記プロセス制御ブロックの位置に接近するステップにおいて、
仮想ドライバを用いて前記カーネルメモリに接近することを特徴とする請求項２に記載のシステムテスト方法。
【請求項４】
前記プロセス制御ブロックの性能要素をモニタリングするステップにおいて、
予め設定された時間間隔ごとに前記プロセス制御ブロックの性能要素を測定することを特徴とする請求項１に記載のシステムテスト方法。
【請求項５】
前記プロセス制御ブロックの性能要素をモニタリングするステップにおいて、
前記プロセス制御ブロックのプロセス及びスレッド（Ｔｈｒｅａｄ）に対する性能要素を測定することを特徴とする請求項２に記載のシステムテスト方法。
【請求項６】
前記プロセス制御ブロックの性能要素は
プロセッサ使用量、メモリ使用量、ページフォールト（Ｐａｇｅ  Ｆａｕｌｔ）中一つ以上を含むことを特徴とする請求項５に記載のシステムテスト方法。
【請求項７】
前記プロセス制御ブロックのプロセス性能要素は
アイディー（ＩＤ）、プロセスの状態、プロセスの優先順位、ヒープ（Ｈｅａｐ）使用量、プロセスの動作時間、使用時間、カーネル使用時間中一つ以上を含むことを特徴とする請求項６に記載のシステムテスト方法。
【請求項８】
前記プロセス制御ブロックのスレッド性能要素は
アイディー、運営状態（Ｒｕｎ  Ｓｔａｔｅ）、基本優先順位、現在優先順位、使用時間、カーネル使用時間、コールスタック（Ｃａｌｌ  Ｓｔａｃｋ）中一つ以上を含むことを特徴とする請求項６に記載のシステムテスト方法。
【請求項９】
前記プロセス制御ブロックは
プロセスの識別子、レジスタコンテクスト（Ｃｏｎｔｅｘｔ）、プロセスのアドレス、メモリ使用量、共有関数リスト、プロセスの資源（Ｒｅｓｏｕｒｃｅ）、プロセスの優先順位、プロセスの状態中一つ以上に対する情報を格納することを特徴とする請求項１に記載のシステムテスト方法。
【請求項１０】
前記プロセス制御ブロックの性能要素をモニタリングするステップは
カーネルに分析コードを挿入して前記プロセス制御ブロックの性能要素をモニタリングすることを特徴とする請求項１に記載のシステムテスト方法。
【請求項１１】
前記プロセス制御ブロックの性能要素をモニタリングするステップは
シミュレーションプログラムを用いて前記プロセス制御ブロックの性能要素をモニタリングすることを特徴とする請求項１に記載のシステムテスト方法。
【請求項１２】
前記プロセス制御ブロックの性能要素をモニタリングするステップは
レジスタを含むハードウェアを用いて前記プロセス制御ブロックの性能要素をモニタリングすることを特徴とする請求項１に記載のシステムテスト方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムテスト方法に係り、より詳しくは、システムの運用環境に影響を与えずに、性能ネックとその原因及び位置を識別するためのデータを収集するシステムテスト方法に関する。
【背景技術】
【０００２】
最近自動車のような機械産業分野でも電子制御技術に対する関心が大きい。電子制御技術の核心はエンベデッドソフトウェアであり、これらソフトウェアの品質が全体製品の品質に大きな影響を及ぼす。
従来も品質の一助にするソフトウェアテスト技術とテスト道具等が開発された。しかし、エンベデッドソフトウェア固有の特徴等のため、これらをそのままエンベデッドソフトウェアテストに適用するには様々な問題があった。
【０００３】
第一に、エンベデッドソフトウェアは特定のハードウェアと機能に合わせて製作されるソフトウェアである。殆どのエンベデッドソフトウェアは、メモリのようなシステム資源に余裕のない制約的条件に最適化されて動作するように設計される。したがって、ターゲット環境で動作するエンベデッドソフトウェアは、ホスト環境で動作する一般のソフトウェアと比べた場合、システム運用時に資源の制約が甚だしいとの問題点がある。
【０００４】
第二に、エンベデッドソフトウェアは、メニュー選択のような使用者命令による動作よりも電子的シグナルや通信プロトコルのような多様な類型の外部入力による動作が大きな比率を占める。したがって、使用者命令によって主に動作する従来のソフトウェアテスト技術とテスト道具等をエンベデッドソフトウェアテストにそのまま適用し難いとの問題点がある。
【０００５】
第三に、従来のソフトウェアテスト技術は、性能テスト時に高いプロセッサ使用率が持続される場合にのみ性能ボトルネックを表す症侯と見做す。この場合、重要なコンポーネントのプロセッサ使用率が基本性能以下に落ちる場合は異常症候と判断しない。したがって、システムの性能を正確にテストすることができない問題点がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、システム運用時に必要な資源の使用を最小限にしてシステムの運用環境に影響を与えずに性能ボトルネックとその原因及び位置を識別するためのデータ収集するシステムテスト方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明は、プロセス制御ブロック（Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）の位置を識別するステップと、プロセス制御ブロックの位置に接近するステップと、プロセス制御ブロックの性能要素をモニタリングするステップとを含むことを特徴とする。
【発明の効果】
【０００８】
本発明によれば、システム運用に必要な資源を最小限用いてシステムの運用環境に影響を与えずにシステムをテストすることができる。
また、本発明はシステムの外部から入力されるデータに基づきシステムをテストすることができる長所がある。
さらに、本発明はプロセッサの使用率が基準以下に落ちる場合でもボトルネック現象なのか否かをテストすることができる長所がある。
【図面の簡単な説明】
【０００９】
【図１】本発明に係るシステムテスト方法を示すフローチャートである。
【図２】本発明に係るシステムテスト方法を具現するプログラムコードである。
【図３】本発明に係るシステムテスト方法を行うシステムの構造を示す図である。
【発明を実施するための形態】
【００１０】
本発明に係るシステムテスト方法は、プロセス制御ブロック（Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）の位置を識別するステップと、プロセス制御ブロックの位置に接近するステップと、プロセス制御ブロックの性能要素をモニタリングするステップとを含む。
以下、図を参照して、本発明の多様な実施形態を具体的に説明する。
本発明に係るシステムテスト方法で、プロセス制御ブロック（Ｐｒｏｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ）は運用体制がシステムに運用されているプロセス等の実行情報を管理する資料構造を意味する。
例えば、プロセス制御ブロックは、システムで運用中のプロセス等の最新実行情報を実時間で管理するカーネルの資料構造を意味する。
【００１１】
本発明に係るシステムテスト方法は、システムのメモリに発生した欠陥を見付けるため、プロセス制御ブロックを介しメモリと関連する関数テーブルをフッキングする。
特に、本発明に係るシステムテスト方法は、プロセス制御ブロックのデータのうち性能ボトルネックとその原因を分析するため、ページフォールト率とプロセッサ使用率のようなシステム実行情報等をハッキングしてシステム性能を分析することができる。
プロセス制御ブロックハッキングは、性能分析に必要なデータ収集をプロセス制御ブロック１ヶ所に集中させることにより、テストによるシステム性能低下を最小にすることができる。
さらに、本発明は、前記のようなシステム性能低下を最小にしながら、同時にシステム運用環境での性能テスト要求事項を満足させることができる。
【００１２】
例えば、本発明に係るシステムテスト方法は、次のような条件を仮定して行うことができる。
［システムテスト条件］
１．テスト範囲：全体システム内の全てのハードウェアとソフトウェアコンポーネント等が作動する状況のシステムに対する性能テスト。
２．テスト方式：システム実行方式を保障するためｒｅ−ｃｏｍｐｉｌｅ、ｒｅ−ｌｉｎｋ、ｒｅ−ｅｘｅｃｕｔｅされない方式でのランタイムテスト。
３．テスト対象：デバッギング情報のような付加的なコードを含まないテスト対象ソフトウェアの原本ソース／二進コードの変更なくシステムにローディングされたバイナリーコードを対象にしたテスト。
４．性能データ：性能ボトルネックの原因として、プロセッサだけでなくメモリ、Ｉ／Ｏ、ネットワーク資源まで考慮することができる性能データ収集。
【００１３】
５．ボトルネック位置追跡：性能ボトルネックの位置で関数のようにソースレベル分析が可能な位置データ収集。
６．ハードウェア独立性：テストのための別途のハードウェア追加や依存性なく、システム運用環境と同一のハードウェア条件でのテスト。
７．ソフトウェア独立性：テストのため特別に製作されたカーネル  （Ｉｎｓｔｒｕｍｅｎｔｅｄ  Ｋｅｒｎｅｌ）や仮想マシンを用いない、システム運用環境と同一のソフトウェア条件でのテスト。
８．  性能遅延率：実時間動作を保障するため、テストによるシステム性能遅延率最小化。
９．  コード追加率：制限された資源内で動作するため、テストによるコード追加率最小化。
【００１４】
しかし、このような条件は、システム運用環境に伴いいくらでも変更することができ、本発明は、このようなシステム運用環境に制限されずに適用できる。
プロセス制御ブロックは、システムに運用されるプロセスの実行情報を盛り込んでいるカーネル資料構造である。プロセス制御ブロックには、性能ボトルネックを判断するプロセッサ使用量と余裕メモリサイズのような性能要素等も含まれており、カーネルによりこれら値は常に一番最近の値に維持される。
本発明に係るシステムテスト方法は、この値等をハッキングするエージェント開発のための性能分析に用いられる。
【００１５】
以下、性能ボトルネックの原因を分析するために必要な性能要素及び関連したプロセス制御ブロック構造について説明する。
性能は、システムやコンポーネント等が与えられたシステムの制約条件内で機能を行う程度を意味する。性能テストは、特定性能要求事項をシステムが満足するかに関する評価である。
このような性能テストを通じて性能ボトルネックとその原因を分析し、これを解決することによりシステムの性能を改善することができる。
システムの性能ボトルネックはメモリ、Ｉ／Ｏ  デバイス、ネットワークのような制限された資源等に対する競争で、システムの性能が低下する現象である。システム性能ボトルネックの原因は、資源不足、共有資源競合、資源独占、資源の誤った構成、或いは資源の誤った動作のように多様である。
【００１６】
先ず、メモリが原因となる性能ボトルネックは、使用可能なメモリが不足する時に発生することがあり、メモリ不足症侯を識別することができる核心的なメモリ性能要素としてページフォールトとメモリ使用量がある。
本発明に係るシステムテスト方法は、多様な性能ボトルネック等を識別することができる。
先ず、本発明に係るシステムテスト方法は、ページフォールトを基準にメモリボトルネックを判断することができる。
【００１７】
例えば、ページフォールトが高いとメモリボトルネックであり得る。ページフォールトとは、プログラムが自分のアドレス空間には存在するものの、システムのメモリには現在ないデータやコードに接近を試みた場合に発生する現象である。ページフォールトが発生すると、運営体制はそのデータをメモリに持って来て恰もページフォールトが全然発生しないもののようにプログラムが引き続き作動するようにする。運営体制のページフォールトに対する例外処理のためアプリケーションの処理時間は遅延され、全体システム性能に影響を与える。
【００１８】
さらに、本発明に係るシステムテスト方法は、メモリ使用量を介し性能ボトルネックを識別することができる。システムのメモリは物理メモリ使用量、仮想メモリ使用量があり、プロセス別にヒープメモリ使用量で区分することができる。本発明に係るシステムテスト方法は、このようなメモリ使用量等の和を基準に性能ボトルネックを判断する。
さらに、本発明に係るシステムテスト方法は、プロセッサ使用量（或いはＣＰＵ使用量）を介し性能ボトルネックを識別することができる。
例えば、本発明に係るシステムテスト方法は、プロセッサ使用量が高く維持されながら余裕メモリのある場合はＣＰＵにボトルネックがあると判断することができる。その反面、プロセッサ使用量が高くメモリも枯渇したのであれば、性能問題はＣＰＵよりもメモリボトルネックと判断することができる。
【００１９】
さらに、本発明に係るシステムテスト方法は、プロセス使用量（Ｐｒｏｃｅｓｓｏｒ  Ｕｓａｇｅ）に従い性能ボトルネックを識別することができる。プロセス使用量はシステムの実行時間で、全体ＣＰＵ使用量から待機時間（Ｉｄｌｅ  Ｔｉｍｅ）を除いた時間を意味する。
さらに、本発明に係るシステムテスト方法は、使用時間（Ｕｓｅｒ  Ｔｉｍｅ）に従い性能ボトルネックを判断することができる。使用時間は、実行が使用者空間で留まった時間を意味し、まさにアプリケーションの実行時間を意味する。
【００２０】
さらに、本発明に係るシステムテスト方法は、カーネル使用時間（Ｋｅｒｎｅｌ  Ｔｉｍｅ）に従い性能ボトルネックを判断することができる。カーネル使用時間は実行がカーネル空間で留まった時間で、カーネルのサービス処理時間を意味する。    プロセス制御ブロックは、ランタイムにプロセス等を制御するための目的で運営体制カーネルが管理する資料構造である。一般に、プロセス制御ブロックにはプロセス識別子、レジスタコンテクスト、プロセスのアドレス空間、プロセスのメモリ使用量、共有関数リスト、プロセスが所有する資源等、プロセスの優先順位と状態などの実行情報が格納されている。
【００２１】
図１は、本発明に係るシステムテスト方法を示すフローチャートである。
図２は、本発明に係るシステムテスト方法を具現するプログラムコードである。
図１に示す通り、本発明に係るシステムテスト方法は、プロセス制御ブロックの位置を識別するステップ（Ｓ１００）と、プロセス制御ブロックに接近するステップ（Ｓ２００）と、プロセス制御ブロックの性能要素をモニタリングするステップ（Ｓ３００）とを含む。
【００２２】
プロセス制御ブロックの位置を識別するステップ（Ｓ１００）で、プロセスが生成され消滅する時、そのプロセス制御ブロックも共に生成され消滅するためプロセス制御ブロックが格納される位置は決定されていない。
しかし、プロセッサ（例えば、ＣＰＵ）を占有する現行プロセス（Ｃｕｒｒｅｎｔ  Ｐｒｏｃｅｓｓ）に関するプロセス制御ブロックのｂａｓｅ  ａｄｄｒｅｓｓは、特定メモリ空間に管理されるか、場合に応じて予め固定されたアドレスで管理されるため、現行プロセスのプロセス制御ブロック情報が分かる。
例えば、図２に示したプログラムコードのｌｉｎｅ  ７でのように現行プロセスのプロセス制御ブロックｂａｓｅ  ａｄｄｒｅｓｓをスタックポインタで計算し、ｌｉｎｅ  ３１のように全てのプロセスのプロセス制御ブロックに接近することができる。
プロセス制御ブロックの位置に接近するステップ（Ｓ２００）で、プロセス制御ブロックはカーネルメモリ空間に存在する。
【００２３】
この場合、カーネル空間には保安（Ｓｅｃｕｒｉｔｙ）次元で接近を許容しないこともある。このようにカーネル空間に対する接近が遮断される時、下記プログラムコードのようにｐｓｅｕｄｏ  ｃｏｄｅｓを、カーネルアドレス空間を共有することができるよう仮想ドライバ形態に具現し、カーネルメモリ空間に存在するプロセス制御ブロックに接近することができる。
プログラム制御ブロックの性能要素をモニタリングするステップ（Ｓ３００）で、図２に示したプログラムコードのｌｉｎｅ  ６１とｌｉｎｅ  ６５のようにｔｉｍｅｒ−ｉｎｔｅｒｒｕｐｔを用いて指定された時間間隔（ｅ．ｇ．１ｓｅｃ、１００ｍｓｅｃ）ごとに性能データを測定することができる。
【００２４】
さらに、本発明に係るシステム方法では、システム性能をシステム単位だけでなくプロセスとスレッドの単位にまで分析するため、図２に示したプログラムコードのｌｉｎｅ  ３１とｌｉｎｅ  ３３のように、プロセス制御ブロックのプロセスとスレッドリスト等を循環しながら性能要素を測定することができる。
この場合、システム性能ボトルネックが発生する位置を詳しく追跡するためスレッド別にコールスタック（Ｃａｌｌｓｔａｃｋ）情報を格納する。
【００２５】
各モニタリング単位別に測定する性能要素は次の通りである。
プロセス制御ブロックの性能要素はプロセッサ使用量、メモリ使用量、ページフォールト（Ｐａｇｅ  Ｆａｕｌｔ）中の一つ以上を含むことができる。
プロセス制御ブロックのプロセスに対する性能要素はアイディー（ＩＤ）、プロセスの状態、プロセスの優先順位、ヒープ（Ｈｅａｐ）使用量、プロセスの動作時間、使用時間、カーネル使用時間中一つ以上を含むことができる。
プロセス制御ブロックのスレッドに対する性能要素はアイディー、運営状態（Ｒｕｎ  Ｓｔａｔｅ）、基本優先順位、現在優先順位、使用時間、カーネル使用時間、コールスタック情報中一つ以上を含むことができる。
【００２６】
図３は、本発明に係るシステムテスト方法を行うシステムの構造を示す図である。
図３に示す通り、本発明に係るシステムテスト方法を行うシステムは、エージェント部１２０及びテスト管理部２１０を含む。
エージェント部１２０は、テストの対象となるターゲットシステムに含まれ、性能データを測定する役割を果たす。エージェント部１２０は、図１に示されたアルゴリズムを行う。
テスト管理部２１０は、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）のようなホストシステム２００に含まれ、エージェント部１２０から収集された性能データを分析して性能ボトルネックを検出しテストカバレッジを分析する。
【００２７】
具体的に、エージェント部１２０は、運用環境に配置されたターゲットシステムに共に搭載され、使用者のテスト開始と終了命令に従いシステムが運営されながら、周期的にシステム性能と関連するデータを測定する役割を果たす。
例えば、エージェント部１２０はＰｅｒｆＡｇｅｎｔ．ｄｌｌ及びＰｅｒｆＲＯＢＯ．ｅｘｅを含むことができる。
ＰｅｒｆＡｇｅｎｔ．ｄｌｌは、図１に示すアルゴリズムを具現する仮想のカーネルデバイスドライバで、性能テストのためカーネルのプロセス制御ブロック情報をハッキングする。
ＰｅｒｆＲＯＢＯ．ｅｘｅは、使用者のテスト開始と終了命令によりＰｅｒｆＡｇｅｎｔ．ｄｌｌの活性化可否を制御するテストサーバの役割を果たす。
テスト開始命令によりＰｅｒｆＡｇｅｎｔ．ｄｌｌが活性化されると、タイマ設定を介しシステム性能モニタリングモジュールを実行させ、使用者要求によりテストを終了する時も設定されたタイマを終了させることによりテストを終了する。
【００２８】
一方、テスト管理部２１０は、収集された性能データを指定された格納媒体に格納することができる。テスト管理部２１０は、ホストシステム２００ログファイルを分析して運営タイムに発生した性能ボトルネックを検出する役割を果たす。
例えば、テスト管理部２１０が性能データを格納媒体に二進コードで格納するとすれば、テスト管理部２１０はテスト対象に対する二進実行コードと収集されたプロファイリングデータを入力にし、テストカバレッジと性能情報を出力するとき、コールスタック情報に基づき何れの関数位置で問題が発生したのかの位置情報を共にディスプレイすることができる。
【００２９】
本発明に係るシステムテスト方法で、システムの性能をモニタリングする多様な方法が使用可能である。
先ず、カーネルに分析コードを挿入する方法が用いられる。この技術は、カーネルに分析コードを静的に或いは動的に挿入させる。
動的に挿入する技術ではランタイムにカーネルコードへ分析コードを挿入することができ、この場合、システムを再起動せずとも性能分析に必要なデータを収集するコードを挿入することができる。
静的に挿入する技術は、予め製作されたカーネルを用いる。
例えば、カーネル内部に重要なシステム性能要素をモニタリングする分析コードを植えておくことができる。性能モニタリングする場合、カーネル内部に予め挿入されている分析コードを介し性能データの送信を受ける。その結果、性能モニタリングするとき、プロセッサ使用量、メモリ使用量を含んで非常に多様なシステム性能要素の測定が可能である。
【００３０】
さらに、性能モニタリング技術としてシミュレータを利用する方法が用いられる。この方式は、開発段階初期のシステムの性能を検討する場合に有用である。
さらに、性能モニタリング技術としてハードウェアを用いることもできる。ハードウェア性能要素等は特に製作されたレジスタ集合を意味し、ソフトウェア基盤の性能要素に比べ少ないシステムオーバーヘッドでＣＰＵ、キャッシュ、メモリと関連した性能をモニタリングすることが可能である。この方式は、ソースコードや二進コードを修正しなくとも良い。
【産業上の利用可能性】
【００３１】
本発明は、システム運用に必要な資源の使用を最小限にしててシステムの運用環境に影響を与えずにシステムをテストすることができる。
【符号の説明】
【００３２】
１００  ターゲットシステム
１１０  プロセス制御ブロック
２００  ホストシステム
２１０  テスト管理部
【図１】
2013533553.tif 000003
【図２】
2013533553.tif 000004
【図３】
2013533553.tif 000005
【国際調査報告】
2013533553.tif 000006
2013533553.tif 000007
2013533553.tif 000008
2013533553.tif 000009