JP2013535069A - システムテスト装置 - Google Patents

Abstract

本発明は、システムテスト装置であって、プロセス制御ブロックにテストエージェントを挿入する挿入モジュールと、テスト対象と関連したイベントが発生する場合、前記テストエージェントを利用してテスト対象をテストコードにフッキングするフッキングモジュールと、前記テスト対象がフッキングされた場合、前記テスト対象と関連するイベントが発生したプロセスに対するテスト情報を収集するスキャニングモジュールと、前記スキャニングモジュールにより収集されたテスト情報を格納するロギングモジュールを含む。
【選択図】図２

Description

本発明はシステムテスト装置に係り、より詳しくは、システムの実行情報を含むプロセス制御ブロックを利用してシステムに対するテスト情報を実時間で収集するシステムテスト装置に関する。

多様なソフトウェア及びハードウェアを含むエンベデッドシステムにおいて、システムの運営環境で相互作用（ｉｎｔｅｒａｃｔｉｏｎ）する動作が重要である。したがって、ソフトウェアのみで構成されたテストのため仮想データでない、システムが実際運営されながら得ることになる実際データ（ｌｉｖｅ ｅｎｖｉｒｏｎｍｅｎｔ ｗｉｔｈ ｒｅａｌ ｄａｔａ）を利用する動作が重要なので、システムをテストしようとする場合にも、実際運用データを利用してシステムテストを行ってこそ潜在的欠陥、又は実際運用上発生する運用上欠陥を効果的に探し出すことができる方案が求められる。

さらに、システムを構成するソフトウェアそれぞれを別途独立的にテストするためには、連結される相対コンポーネントを代替するための装備を備えなければならないなど、テスト資源と費用が多く要するため、システムに含まれた全てのプロセスを実時間でテストすることができ、メモリ空間のオーバーヘッド又は当該コード遂行による性能オーバーヘッドを最小化するテスト装置が求められる。

本発明は、フッキング技術を利用してシステムに対するメモリ誤謬テスト、性能テスト、及びシステムの内部に含まれたプロセス間の通信テストを行うことにより、実際運営されるシステムに対するテストが可能であり、システムのランタイム状況でも動的テストを行うことができ、システムが動作する間発生する欠陥を確認することができるシステムテスト装置を提供することにその目的がある。

本発明はシステムテスト装置であって、プロセス制御ブロックにテストエージェントを挿入する挿入モジュールと、テスト対象と関連したイベントが発生する場合、前記テストエージェントを利用してテスト対象をテストコードにフッキングするフッキングモジュールと、前記テストコードにフッキングされた場合、前記テスト対象と関連するイベントが発生したプロセスに対するテスト情報を収集するスキャニングモジュールと、前記スキャニングモジュールにより収集されたテスト情報を格納するロギングモジュールを含む。

さらに、本発明はシステムテストシステムであって、システムを駆動させるための信号の入力を受ける入力装置と、前記入力装置を介し入力された信号により前記システムが動作する間、前記プロセス制御ブロックにテストエージェントを挿入し、前記テストエージェントを利用してテスト対象をテストコードにフッキングし、前記複数のプロセス中テスト対象と関連するイベントが発生したプロセスに対するテスト情報を収集するシステムテスト装置と、前記システムテスト装置により収集されたテスト情報を分析する分析装置とを含む。

本発明によれば、ソースコードでない実際運営されるコードを対象にするので、システムが実際に運用される間にもシステムに対するテストを行うことができる。したがって、システムが実際動作する間メモリ誤謬、システム性能、プロセス間の通信をテストすることができる。
さらに、それぞれのプロセスに対する個別的なコード挿入でない、プロセス制御ブロックに含まれた情報を活用したフッキング方法を利用するので、システムオーバーヘッドを最小化することができ、動作するシステムを妨ぐことなくシステムに対するテストを行うことができる。
さらに、プロセス間の共有資源が制限された場合も、実時間でテスト情報を収集しテスト結果を確認することができる。

本発明の一実施形態に係るシステムテスト装置が利用される全体システムを示す図である。 本発明の一実施形態に係るシステムテスト装置の構成を示す図である。 本発明の一実施形態に係るシステムテスト方法を示すフローチャートである。 本発明の一実施形態に係るメモリテスト方法、性能テスト方法及びプロセス間の通信テスト方法を示すフローチャートである。 本発明の一実施形態に係るメモリテスト方法、性能テスト方法及びプロセス間の通信テスト方法を示すフローチャートである。 本発明の一実施形態に係るメモリテスト方法、性能テスト方法及びプロセス間の通信テスト方法を示すフローチャートである。

以下、添付の図面を参照して、本発明の好ましい実施例を説明する。

本発明は、システムが実際運営される環境でのテストであり、システムが開始され終了されるまでの動的状況でシステムをテストすることができる装置及び方法に関する。本発明は、フッキング技法を利用して、システム内で動作する全てのプロセスに対するテストを行うことができる。

図１は、本発明の一実施形態に係るシステムテスト装置が利用される全体システムを示す図である。図１に示す通り、全体システムはシステムテスト装置１００、システム２００、入力装置３００、分析装置４００及び出力装置５００を含む。システムテスト装置１００は、システム２００に対するメモリ欠陥、システム２００の性能又はシステム２００に含まれた２つ以上のプロセス間の通信をテストするための装置である。システムテスト装置１００は、図１に示す通り、システム２００と独立的に備えられてもよく、システム２００の内部に含まれる形態に具現されてもよい。

システム２００は、システムテスト装置１００のテスト対象となるシステムであって、多様なソフトウェア及びハードウェアが統合されたエンベデッドシステムである。システムテスト装置１００のテスト対象となるシステムは、複数のプロセスを含む１つ以上のシステムを意味する。したがって、複数のシステムのメモリ欠陥又はシステム性能もテスト対象となり得、１つのシステムに含まれる複数のプロセス間の通信だけでなく、互いに異なるシステムに含まれたプロセス等の間の通信もシステムテスト装置１００のテスト対象となり得る。

前記システム２００は、マルチプロセスが通信する全てのエンベデッドシステム及びコンピュータシステムであって、例えば、インフォテインメントシステム、マルチメディアシステム、有無線ネットワークシステムなどになり得る。例えば、システム２００が車両インフォテインメントシステムの場合、システム２００はＡＶＮ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｎａｖｉｇａｔｉｏｎ）機能を中心にＴＤＭＢ（Ｔｅｒｒｅｓｔｒｉａｌ Ｄｉｇｉｔａｌ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔｉｎｇ）、ＴＰＥＧ（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）、ＩＰＯＤ、ＵＳＢ、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ(登録商標)）、ＶＲ（Ｖｏｉｃｅ Ｒｅｃｏｇｎｉｔｉｏｎ）、ＰＧＳ（Ｐａｒｋｉｎｇ Ｇｕｉｄａｎｃｅ Ｓｙｓｔｅｍ）、ＲＤＳ（Ｒａｄｉｏ Ｄａｔａ Ｓｙｓｔｅｍ）、ＶＣＤＣ（Ｖｅｈｉｃｌｅ ＣＤＣ）、ＤＩＳ（Ｄｒｉｖｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ）、ＲＳＥ（Ｒｅａｒ Ｓｅａｔ Ｅｎｔｅｒｔａｉｎｍｅｎｔ）、ＨＥＶ（Ｈｙｂｒｉｄ Ｅｌｅｃｔｒｉｃ Ｖｅｈｉｃｌｅ）ｄｉｓｐｌａｙ、ＡＨＵ（Ａｉｒ Ｈａｎｄｌｉｎｇ Ｕｎｉｔ）ｄｉｓｐｌａｙなどを含む。

入力装置３００は、システムテスト装置１００及びシステム２００を駆動させるための使用者入力装置である。入力装置３００は、キーボード又はタッチスクリーンに具現されてもよく、入力装置３００を介し入力される信号に応じてシステム２００が駆動される。さらに、入力装置３００を介し入力される信号に応じてシステムテスト装置１００がシステムテストのための動作を行う。

分析装置４００は、システムテスト装置１００により収集されたテスト情報を分析しシステム２００のテスト結果を確認する。前記システムテスト装置１００は分析装置４００と１つの装置に具現され、テスト情報を収集すると共に、収集されたテスト情報を分析しテスト結果を確認することもできる。

出力装置５００は、システムテスト装置１００により収集されたテスト情報、又は分析装置４００により分析されたテスト結果をイメージ又は音声で出力する装置である。出力装置５００を介し、使用者はシステムテスト結果を確認することができる。

図２は、本発明の一実施形態に係るシステムテスト装置の構成を示す図である。図２に示す通り、システムテスト装置１００は挿入モジュール１０１、フッキングモジュール１０３、スキャニングモジュール１０５及びロギングモジュール１０７を含む。図２で、システムテスト装置１００と連結されテスト対象となるシステム２００は、２つ以上のプロセスを含む１つのシステムと仮定する。

システム２００は、プロセス制御ブロック（Ｐｒｏｃｅｓｓ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）２０１を含む。プロセス制御ブロック２０１は、システム２００に含まれた全てのプロセスに対するランタイム実行情報を有する。ここで、ランタイム実行情報とは、システム２００が動作する間全てのプロセス間の実行情報を意味する。したがって、プロセス制御ブロック２０１は、システム２００に含まれた全てのプロセスに対する資源使用現況、プロセス状態、優先順位、関数テーブルなどを含むことができる。より詳しくは、プロセスＩＤ、プロセス名、現行プロセス、現行スレッド、システムで行われているプロセスリスト、モジュールリスト、システムページサイズ、使用可能な物理メモリサイズ、ＣＰＵ使用量、使用中の資源リスト、要請中のＩ／Ｏデバイス状態、オープンされたファイル情報、レジスタ情報などを含むことができる。したがって、全てのシステム内で前記言及された情報を含むデータ構造又は装置は、本発明で意味するプロセス制御ブロックに該当する。

挿入モジュール１０１は、プロセス制御ブロック２０１にテストエージェントを挿入する。テストエージェントは、プロセス制御ブロック２０１に含まれた情報に基づきテスト対象をテストコードにフッキングし、テスト情報を収集することができる。テストコードがフッキングされるテスト位置は、欠陥の類型に従い定義され得る。本発明で、テストコードにフッキングされるテスト対象は、テスト対象となるメモリ領域、システムの性能情報を含むコード、又は通信関連イベントを発生させるコードなどになり得る。本発明で、テストエージェントがプロセス制御ブロック２０１に挿入される前に、先ずシステム２００は正常に動作しており、システム２００はシステムテスト装置１００の動作により影響を受けず正常に動作する。

さらに、挿入モジュール１０１は、システム２００で動作しているプロセスリストを確認し、確認されたプロセスリストに基づきテストエージェントを挿入することができる。フッキングモジュール１０３は、前記挿入モジュール１０１により挿入されたテストエージェントを利用してテスト対象をテストコードにフッキングする。前記テストコードはテストしようとする対象及び欠陥の類型に従い変更される。即ち、メモリ欠陥テスト、性能テスト及び通信テストに従いテストコードがそれぞれ変化し、通信テストにおいてもテストしようとする欠陥の類型に従いテストコードが変化し得る。さらに、フッキングモジュール１０３は、テスト対象がテストコードにフッキングされるテスト位置を変更することができる。

テストコードがフッキングされるとのことは、動作しているシステム２００内でテスト対象と関連イベントが発生する場合、挿入されたテストエージェントが原本コードの動作を含むテストコードが行われるようＯＳのプロセス制御ブロックをフッキングするとのことを意味する。プロセス制御ブロックに含まれる情報から、フッキングモジュール１０３はテスト対象と関連するイベントが発生するのか確認することができる。

スキャニングモジュール１０５は、テストコードがフッキングされた場合、前記テスト対象と関連するイベントが発生したプロセスに対するテスト情報を収集する。ここで、テスト情報は、既に発生したイベントに対する情報だけでなく、テストコードフッキングに伴い新たに発生するイベントまで含むことができる。収集されるテスト情報はテスト段階、テスト目的、テストしようとする欠陥の類型に従い変化する。したがって、スキャニングモジュール１０５は、システムテスト結果の分析に必要なシステム動的状態情報、例えば、関数パラメータ及び返還値、性能測定値、共有資源使用リストなどを収集する。

ロギングモジュール１０７は、前記スキャニングモジュール１０５により収集されたテスト情報を格納空間に格納する。格納空間はロギングモジュール１０７に備えられてもよく、ロギングモジュール１０７と別個の装置に具現されてもよい。図１に示した分析装置４００は、スキャニングモジュール１０５により収集されたテスト情報、又はロギングモジュール１０７により格納されたテスト情報を分析することができる。

図３は、本発明の一実施形態に係るシステムテスト方法を示すフローチャートである。図３に示す通り、テスト対象となるシステム２００のプロセス制御ブロック２０１にテストエージェントが挿入される（Ｓ１１０）。システム２００は、テストエージェントが挿入される前から正常に動作している。

次に、テスト対象と関連するイベントが発生する場合、挿入されたテストエージェントを介しテスト対象がテストコードにフッキングされる（Ｓ１２０）。テスト対象がテストコードにフッキングされることにより、前記イベントが発生したプロセスの代わりにテストコードが行われ得る。次に、テスト対象がテストコードにフッキングされた場合、前記テスト対象と関連するイベントが発生したプロセスに対するテスト情報が収集される（Ｓ１３０）。次に、収集されたテスト情報は格納される（Ｓ１４０）。ここで、テスト情報は、テスト対象がテストコードにフッキングされている間にのみ収集され得、テスト対象がテストコードにフッキングされた後、システムが動作する間全て収集されることもある。

図４は、本発明の一実施形態に係るメモリ欠陥テスト方法、性能テスト方法及びプロセス間の通信テスト方法を示すフローチャートである。図４ａは、メモリ欠陥テストを行うためのシステムテスト方法を示す図である。先ず、欠陥モデルが定義される（Ｓ１５０）。ここで、欠陥モデルとは、欠陥の類型に従いテストされなければならないメモリ位置及び欠陥の発見／復旧のためのテスト情報を意味する。定義された欠陥モデルに従い、システム２００が正常に動作する間テスト情報を収集することができるテストコードが生成され得る。

次に、システム２００のプロセス制御ブロック２０１にテストエージェントが挿入される（Ｓ１５１）。テストエージェントは、システム２００で動作しているプロセスリスト中少なくとも１つに挿入され得る。次に、フッキングモジュール１０３は、プロセス制御ブロック２０１に含まれた情報及び欠陥モデルに基づきフッキングするメモリ領域を識別し、識別されたメモリ領域にテストコードをフッキングする（Ｓ１５２）。メモリ領域を識別した結果、テスト位置がＳＹＳＴＥＭ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｃｅｓｓ Ｉｎｔｅｒｆａｃｅ）関数の場合、フッキングモジュール１０３はプロセス制御ブロック２０１のＡＰＩＳｅｔをフッキング領域と識別する。テスト位置がＤＬＬ（Ｄｙｎａｍｉｃ Ｌｉｎｋｉｎｇ Ｌｉｂｒａｒｙ）ＥＸＰＯＲＴ関数の場合、フッキングモジュール１０３はプロセス制御ブロック２０１のＩＡＴ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ）をフッキング領域と識別する。その他の場合、フッキングモジュール１０３はプロセス制御ブロック２０１のコード空間をフッキング領域と識別する。

図４ａで、テストコードがフッキングされるとのことは、動作しているシステム２００内でテスト対象であるメモリ位置に、メモリに対する書込み、読取り、接近などのイベントが発生する場合、挿入されたテストエージェントが原本コードの動作を含むテストコードが行われるようＯＳのプロセス制御ブロックをフッキングするとのことを意味する。

次に、テスト対象であるメモリ状態に対する情報が収集される（Ｓ１５３）。例えば、欠陥原因の識別に必要なプログラム実行情報が収集され、欠陥位置の識別に必要なプロセスコンテクスト情報が収集され、メモリ性能分析に必要なシステム状態情報が収集され得る。次に、Ｓ１５３段階で収集されたテスト情報が格納される（Ｓ１５４）。

図４ｂは、性能テストを行うためのシステムテスト方法を示す図である。本発明に係るシステムテスト方法は、性能ボトルネックとその原因を分析するため、プロセス制御ブロック２０１のデータ中ページフォールト率、プロセッサ使用率のようなシステム実行情報等をフッキングしシステム性能を分析することができる。ここで、性能は、システムやコンポーネント等が与えられたシステムの制約条件下で機能を行う程度を意味する。性能テストは、特定性能の要求事項をシステムが満足するのかに関する評価である。このような性能テストを介して性能ボトルネックとその原因を分析し、これを解決することによりシステムの性能を改善することができる。

システムの性能ボトルネックは、メモリ、Ｉ／Ｏデバイス、ネットワークのような制限された資源等に対する競争でシステムの性能が低下する現象である。システム性能ボトルネックの原因は、資源不足、共有資源競合、資源独占、資源の誤った構成、又は資源の誤った動作のように多様である。先ず、欠陥モデルが定義される（Ｓ１６０）。ここで、欠陥モデルとは、欠陥の類型に従いテストされなければならない性能ボトルネックの位置及び性能ボトルネックを判定するシステム状態を表すテスト情報を意味する。定義された欠陥モデルに従い、システム２００が正常に動作する間テスト情報を収集することができるテストコードが生成され得る。

挿入モジュール１０１は、プロセス制御ブロック２０１にテストエージェントを挿入する（Ｓ１６１）。挿入モジュール１０１は、システム２００で動作しているプロセスリストを確認し、確認されたプロセスリストに基づきテストエージェントを挿入することができる。即ち、現行プロセス（Ｃｕｒｒｅｎｔ Ｐｒｏｃｅｓｓ）に関するプロセス制御ブロック２０１のｂａｓｅ ａｄｄｒｅｓｓは、特定のメモリ空間に管理されるか、場合に応じて予め固定されたアドレスに管理されるため、現行プロセスのプロセス制御ブロック２０１の情報が分かる。

次に、フッキングモジュール１０３は、テスト対象にテストコードをフッキングする（Ｓ１６２）。テスト対象がテストコードにフッキングされた場合、スキャニングモジュール１０５はシステムの性能情報を収集する（Ｓ１６３）。例えば、ｔｉｍｅｒ−ｉｎｔｅｒｒｕｐｔを用いて指定された時間間隔（ｅ．ｇ．１ｓｅｃ、１００ｍｓｅｃ）ごとに性能データを測定することができる。さらに、システム性能をシステム単位だけでなく、プロセスとスレッドの単位にまで分析するため、プロセス制御ブロック２０１のプロセスとスレッドリスト等を循環しながら性能情報を測定することができる。

システム性能ボトルネックが発生する位置を詳しく追跡するため、スキャニングモジュール１０５はスレッド別にコールスタック（Ｃａｌｌ−ｓｔａｃｋ）情報を格納することができ、各モニタリング単位別に測定される性能情報は、次の通りである。プロセス制御ブロック２０１の性能情報は、プロセッサ使用量、メモリ使用量、ページフォールト（Ｐａｇｅ Ｆａｕｌｔ）、プロセスコンテクスト情報、プロセスコールスタック、プロセスヒープ使用量、プロセス状態、プロセス優先順位中１つ以上を含むことができる。プロセス制御ブロック２０１のプロセスに対する性能情報は、アイディー（ＩＤ）、プロセスの状態、プロセスの優先順位、ヒープ（Ｈｅａｐ）使用量、プロセスの動作時間、使用時間、カーネル使用時間中１つ以上を含むことができる。さらに、プロセス制御ブロック２０１のスレッドに対する性能情報は、アイディー、運営状態（Ｒｕｎ Ｓｔａｔｅ）、基本優先順位、現在優先順位、使用時間、カーネル使用時間、コールスタック情報中１つ以上を含むことができる。

次に、ロギングモジュール１０７は、収集されたテスト情報を格納空間に格納する（Ｓ１６４）。性能テストを行うためのシステムテスト方法は、ページフォールトを基準にメモリボトルネックを判断することができる。例えば、ページフォールトが高ければメモリボトルネックであり得る。ページフォールトとは、プログラムが自分のアドレス空間には存在するがシステムのメモリには現在ないデータやコードに接近を試みた場合に発生する現象である。ページフォールトが発生すれば、運営体制はそのデータをメモリに持って来て、まるでページフォールトが全く発生しなかったもののようにプログラムが継続的に作動するようにする。運営体制のページフォールトに対する例外処理のためアプリケーションの処理時間は遅延され、全体システム性能に影響を及ぼす。

さらに、本発明に係るシステムテスト方法は、メモリ使用量を介し性能ボトルネックを識別することができる。システムのメモリは物理メモリ使用量、仮想メモリ使用量があり、プロセス別にヒープメモリ使用量で区分することができる。本発明に係るシステムテスト方法は、このようなメモリ使用量等の合計を基準に性能ボトルネックを判断する。

さらに、本発明に係るシステムテスト方法は、プロセッサ使用量（或いはＣＰＵ使用量）を介し性能ボトルネックを識別することができる。例えば、本発明に係るシステムテスト方法は、プロセッサ使用量が高く維持されながら余裕メモリがある場合は、ＣＰＵにボトルネックがあると判断することができる。その反面、プロセッサ使用量が高くメモリも枯渇していれば、性能問題はＣＰＵよりメモリボトルネックと判断することができる。

さらに、本発明に係るシステムテスト方法は、プロセス使用量（Ｐｒｏｃｅｓｓｏｒ Ｕｓａｇｅ）に基づき性能ボトルネックを識別することができる。プロセス使用量はシステムの実行時間であって、全体ＣＰＵ使用量から待機時間（Ｉｄｌｅ Ｔｉｍｅ）を除いた時間を意味する。さらに、本発明に係るシステムテスト方法は、使用時間（Ｕｓｅｒ Ｔｉｍｅ）に従い性能ボトルネックを判断することができる。使用時間は、実行が使用者空間で留まった時間を意味し、即ちアプリケーションの実行時間を意味する。さらに、本発明に係るシステムテスト方法は、カーネル使用時間 （Ｋｅｒｎｅｌ Ｔｉｍｅ）に従い性能ボトルネックを判断することができる。カーネル使用時間は、実行がカーネル空間で留まった時間であって、カーネルのサービス処理時間を意味する。

図４ｃは、複数のプロセス間の通信に対するテストを行うためのシステムテスト方法を示す図である。図４ｃに係るシステム方法を行うシステムテスト装置１００は、システム２００に含まれた全てのプロセス間の資源共有及び意思伝達が正確になされるのかを判断可能なテスト情報を収集することができる。

先ず、欠陥モデルが定義される（Ｓ１７０）。ここで、欠陥モデルとは、欠陥の類型に従いテストされなければならないプロセス間の通信位置及び欠陥の発見／復旧のためのテスト情報を意味する。定義された欠陥モデルに従い、システム２００が正常に動作する間テスト情報を収集することができるテストコードが生成され得る。テスト対象となるシステム２００のプロセス制御ブロック２０１にテストエージェントが挿入される（Ｓ１７１）。挿入モジュール１０１は、前記プロセスリスト中２つ以上のプロセスをテスト対象に選定し、選定されたプロセス間の通信をテストするためのテストエージェントを挿入することもできる。

次に、複数のプロセス間に通信関連イベントが発生する場合、挿入されたテストエージェントを利用しテスト対象がテストコードにフッキングされる（Ｓ１７２）。テスト対象がテストコードにフッキングされるとのことは、動作しているシステム２００内で複数のプロセス間に通信関連イベントが発生する場合、挿入されたテストエージェントが原本コードの動作を含むテストコードが行われるようＯＳのプロセス制御ブロックをフッキングするとのことを意味する。プロセス制御ブロックに含まれる情報から、フッキングモジュール１０３は如何なるプロセスの間に如何なる類型の通信関連イベントが発生するのかを確認することができる。ここで、通信関連イベントとは、複数のプロセス間にメッセージ送信、共有データ送信、共有メモリ使用、メッセージキュー使用、同期化客体使用などを意味する。

テストコードは、前記複数のプロセス間のメッセージ送信、メッセージキュー、共有メモリ又は同期化客体と関連する欠陥の類型を確認するためのコードである。例えば、テストコードはＳｅｎｄＭｅｓｓａｇｅ（）、ＰｏｓｔＭｅｓｓａｇｅ（）のような第１の関数、及びテストしようとする欠陥の類型に従い必要な第２の関数を含み、システムに含まれたプロセス等はそれぞれ第１の関数を含む。したがって、第１のプロセス及び第２のプロセスの間に通信関連イベントが発生する場合、フッキングモジュール１０３は、挿入された通信エージェントを利用し第１のプロセス及び第２のプロセスで第１の関数が行われる段階で、第１のプロセス及び第２のプロセスの第１の関数に代えてテストコードを行わせることにより、テストコードをフッキングする。第１のプロセス及び第２のプロセスで第１の関数が行われる段階は、プロセス制御ブロックに含まれた情報から確認される。一方、テスト対象が複数のプロセス間の通信なので、テストしようとする欠陥の類型に従い送信側又は受信側に該当する一方のプロセスにのみテストコードをフッキングすることもできる。

次に、スキャニングモジュール１０５は、テスト対象がフッキングされた場合、前記通信関連イベントが発生した複数のプロセス間の通信に対するテスト情報を収集する（Ｓ１７４）。ここで、複数のプロセス間の通信とは、既に発生した通信関連イベントだけでなく、テストコードフッキングに従い発生する通信関連イベントまで含む。収集されるテスト情報はテスト段階、テスト目的、テストしようとする欠陥の類型に従い変化する。したがって、スキャニングモジュール１０５は、複数のプロセス間の通信に対し欠陥の判定に必要なシステム動的状態情報、例えば、関数パラメータ及び返還値、性能測定値、共有資源使用リストなどを収集する。テスト情報は、前記複数のプロセスのコールスタック情報、前記複数のプロセス間に送受信される通信類型、通信アイディー、通信データ、前記複数のプロセス間の通信で発生した遅延時間などを含むことができる。

次に、ロギングモジュール１０７は、前記スキャニングモジュール１０５により収集されたテスト情報を格納空間に格納する（Ｓ１７５）。格納空間は、ロギングモジュール１０７に備えられてもよく、ロギングモジュール１０７と別個の装置に具現されてもよい。図１に示した分析装置４００は、スキャニングモジュール１０５により収集されたテスト情報又はロギングモジュール１０７により格納されたテスト情報を分析することができる。

複数のプロセス間の通信に対するテストを行うため利用されるテストコードは、プロセス間のメッセージ送信、メッセージキュー、共有メモリ又は同期化客体と関連する欠陥の類型を確認するためのコードになり得る。メッセージ送信（Ｍｅｓｓａｇｅ Ｐａｓｓｉｎｇ）と関連する欠陥の類型は、指定時間内メッセージ送信失敗（同期）、メッセージデッドロック（同期）、メッセージ処理遅延（同期）、メッセージ損失（同期）、メッセージ変更（同期）、メッセージキューへの挿入失敗（非同期）、メッセージ処理遅延（非同期）、メッセージ損失（非同期）、又はメッセージ変更（非同期）に分類され得る。

メッセージキュー（Ｍｅｓｓａｇｅ Ｑｕｅｕｅ）と関連する欠陥の類型は、メッセージキュー生成失敗、メッセージキュー閉じ失敗、メッセージキューからの読取り失敗、又はメッセージキューへの書込み失敗に分類され得る。共有メモリ（Ｓｈａｒｅｄ Ｍｅｍｏｒｙ）と関連する欠陥の類型は、共有メモリ生成失敗でもあり得る。同期化客体（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｏｂｊｅｃｔ）と関連する欠陥の類型は、生成していない同期化客体使用、生成した同期化客体使用しない、又は使用した同期化客体解除しないに分類され得る。したがって、各欠陥の類型に従いテストコードが変更される。

前記のように、本発明に係るシステムテスト装置１００は、動作しているシステム２００に影響を与えずともテストエージェント挿入、テストコードフッキング、テスト情報収集を実施することができ、前記システムテスト装置１００によるシステムテストは、システムに含まれたプロセス制御ブロックに含まれた情報に基づき実施される。

本発明は、プロセッサが読取り可能な記録媒体にプロセッサが読取り可能なコードとして具現することが可能である。プロセッサが読取り可能な記録媒体は、プロセッサにより読み取られ得るデータが格納される全ての種類の記録装置を含む。プロセッサが読取り可能な記録媒体の例にはＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、エムティー、フロッピー(登録商標)、光データ格納装置などがある。さらに、プロセッサが読取り可能な記録媒体はネットワークで連結されたコンピュータシステムに分散され、分散方式でプロセッサが読取り可能なコードが格納され行われ得る。

本発明は、前述の一実施形態に限定されず、請求の範囲で請求する本発明の要旨を外れることがなく、当該発明の属する技術分野で通常の知識を有する者により多様な変形実施が可能であり、このような変形実施等は、本発明の技術的思想や展望から個別的に理解されてはならないはずである。

本発明は、システムが実際に動作する間メモリ誤謬、システム性能、プロセス間の通信をテストすることができる。

Claims (20)

1. 複数のプロセス及び前記複数のプロセスに対するランタイム実行情報を含むプロセス制御ブロックを含むシステムに対するシステムテスト装置において、
   前記プロセス制御ブロックにテストエージェントを挿入する挿入モジュールと、
   テスト対象と関連したイベントが発生する場合、前記テストエージェントを利用してテスト対象をテストコードにフッキングするフッキングモジュールと、
   前記テスト対象がフッキングされた場合、前記テスト対象と関連するイベントが発生したプロセスに対するテスト情報を収集するスキャニングモジュールと、
   前記スキャニングモジュールにより収集されたテスト情報を格納するロギングモジュールと、を含むシステムテスト装置。
   
2. 前記プロセス制御ブロックは、前記複数のプロセスに対する資源使用現況、プロセス状態、優先順位及び関数テーブルのうち少なくとも１つを含むことを特徴とする請求項１に記載のシステムテスト装置。
   
3. 前記テストコードは、欠陥の類型に従い定義されることを特徴とする請求項２に記載のシステムテスト装置。
   
4. 前記フッキングモジュールは、前記欠陥の類型に伴うテスト位置に従いメモリ領域を識別し、識別されたメモリ領域をテストコードにフッキングすることを特徴とする請求項３に記載のシステムテスト装置。
   
5. 前記テスト情報は、プログラム実行情報、プロセスコンテクスト情報及びシステム状態情報のうち少なくとも１つであることを特徴とする請求項３に記載のシステムテスト装置。
   
6. 前記スキャニングモジュールは、前記プロセス制御ブロックの性能情報を測定することを特徴とする請求項２に記載のシステムテスト装置。
   
7. 前記プロセス制御ブロックの性能情報は、プロセッサ使用量、メモリ使用量、ページフォールト（Ｐａｇｅ Ｆａｕｌｔ）、プロセスコンテクスト情報、プロセスコールスタック、プロセスヒープ使用量、プロセス状態、プロセス優先順位のうち少なくとも１つであることを特徴である請求項６に記載のシステムテスト装置。
   
8. 予め設定された時間間隔ごとに前記プロセス制御ブロックの性能情報を測定することを特徴とする請求項６に記載のシステムテスト装置。
   
9. 前記プロセス制御ブロックのプロセス及びスレッド（Ｔｈｒｅａｄ）に対する性能情報を測定することを特徴とする請求項６に記載のシステムテスト装置。
   
10. 前記プロセス制御ブロックのプロセスに対する性能要素は、アイディー（ＩＤ）、プロセスの状態、プロセスの優先順位、ヒープ（Ｈｅａｐ）使用量、プロセスの動作時間、使用時間、カーネル使用時間中１つ以上を含むことを特徴とする請求項９に記載のシステムテスト装置。
    
11. 前記プロセス制御ブロックのスレッドに対する性能要素は、アイディー、運営状態（Ｒｕｎ Ｓｔａｔｅ）、基本優先順位、現在優先順位、使用時間、カーネル使用時間、コールスタック（Ｃａｌｌ Ｓｔａｃｋ）中１つ以上を含むことを特徴とする請求項９に記載のシステムテスト装置。
    
12. 前記テスト対象と関連するイベントは、前記複数のプロセス間のメッセージ送信、共有データ送信、共有メモリ使用、メッセージキュー使用、同期化客体使用のうち少なくとも１つであることを特徴とする請求項２に記載のシステムテスト装置。
    
13. 前記テストコードは、前記複数のプロセス間のメッセージ送信、メッセージキュー、共有メモリ及び同期化客体のうち少なくとも１つの欠陥の類型を確認するためのコードであることを特徴とする請求項１２に記載のシステムテスト装置。
    
14. 前記テスト情報は、前記複数のプロセスのコールスタック情報、前記複数のプロセス間に送受信される通信類型、通信アイディー、通信データ及び前記複数のプロセス間の通信で発生した遅延時間のうち少なくとも１つであることを特徴とする請求項１２に記載のシステムテスト装置。
    
15. 前記テスト情報は、システム動的状態情報、プロセス状態情報、及び前記複数のプロセス間の通信情報を含むことを特徴とする請求項１２に記載のシステムテスト装置。
    
16. 複数のプロセス及び前記複数のプロセスに対するランタイム実行情報を含むプロセス制御ブロックを含むシステムに対するシステムテストシステムにおいて、
    前記システムを駆動させるための信号の入力を受ける入力装置と、
    前記入力装置を介し入力された信号により前記システムが動作する間、前記プロセス制御ブロックにテストエージェントを挿入し、前記テストエージェントを利用してテスト対象をテストコードにフッキングし、前記複数のプロセスのうちテスト対象と関連するイベントが発生したプロセスに対するテスト情報を収集するシステムテスト装置と、
    前記システムテスト装置により収集されたテスト情報を分析する分析装置と、を含むシステムテストシステム。
    
17. 前記プロセス制御ブロックは、前記複数のプロセスに対する資源使用現況、プロセス状態、優先順位及び関数テーブルのうち少なくとも１つを含むことを特徴とする請求項１６に記載のシステムテストシステム。
    
18. 前記テストコードがフッキングされるテスト位置は、欠陥の類型に従い変更され得ることを特徴とする請求項１６に記載のシステムテストシステム。
    
19. 前記テスト情報は、プログラム実行情報、プロセスコンテクスト情報、システム状態情報、プロセッサ使用量、メモリ使用量、ページフォールト（Ｐａｇｅ Ｆａｕｌｔ）、前記複数のプロセスのコールスタック情報、前記複数のプロセス間に送受信される通信類型、通信アイディー、通信データ及び前記複数のプロセス間の通信で発生した遅延時間のうち少なくとも１つであることを特徴とする請求項１６に記載のシステムテストシステム。
    
20. 前記分析装置により分析されたテスト結果をイメージ又は音声で出力する出力装置をさらに含む請求項１６に記載のシステムテストシステム。

Images