JP2010538401A - システムコールカバレッジ基準による試験スイート削減のための方法 - Google Patents

Abstract

【課題】システムコールカバレッジ基準による試験スイート削減のための優れた方法を得る。
【解決手段】試験事例が試験スイートの中に含められるべきかどうかを判定するための方法及び装置が、本明細書で開示される。一実施形態において、方法は、ソフトウェアアプリケーション試験の実行中に、ある試験事例の試験入力を使用してアプリケーションを実行すること、及び試験スイートの中の他の試験事例の実行から生成された観察可能なイベントのＦＳＭ（有限状態マシン）モデルを使用して、アプリケーションの将来の試験での使用のため当該試験事例を試験スイートの中に含めるかどうかを判定することを含む。
【選択図】なし

Description

本発明は、ソフトウェアテストにおける試験スイート削減の分野に関し、より詳細には、本発明は、観察可能なイベントに基づくカバレッジ基準を使用して、試験スイートにおける試験事例の数を減らすことに関する。

（優先権）
本特許出願は、２００７年９月７日に出願した「Ｍｅｔｈｏｄ ｆｏｒ Ｂｅｔｔｅｒ Ｔｅｓｔ Ｓｕｉｔｅ Ｒｅｄｕｃｔｉｏｎ Ｔｈｒｏｕｇｈ Ｓｙｓｔｅｍ Ｃａｌｌ Ｃｏｖｅｒａｇｅ Ｃｒｉｔｅｒｉｏｎ」という名称の対応する米国特許仮出願第６０／９７０８３１号明細書の優先権を主張し、第６０／９７０８３１号明細書を参照によって組み込む。

ソフトウェア試験は、開発サイクルの早期に障害を検出することを担い、ソフトウェア開発リソースの非常に大きい部分を消費する。ソフトウェア開発における大量のリソースが、ソフトウェアを検証すること、及び試験することに費やされる。ソフトウェア開発者及びソフトウェア試験者は、手作業で、又はランダムな試験技法若しくは他の体系的な探査技法を使用して、多数の試験事例を生成する。ますます多くの試験事例が、ソフトウェア開発ライフサイクルの様々な時点で追加されるにつれ、試験スイートのサイズは、相当に増大する可能性がある。

試験スイートを減らすこと、又は試験スイートに優先順位を付けることが、試験リソースを最大限に活用するのに、しばしば、必要である。試験スイート削減は、すべての試験事例ではなく、障害を明らかにする重要な試験事例に焦点を合わせることによって、試験リソースをよりうまく利用することに役立つソフトウェア保守活動の一部である。大きい試験スイートは、より小さい試験スイートに切り詰められ、したがって、開発者によるソフトウェアの頻繁な更新を試験するように、開発者は、そのより小さい試験スイートを、より頻繁に使用することができ（スモーク試験と呼ばれる）、その一方で、すべての試験事例を有する、より大きい試験スイートは、毎週、又は隔週に実行されて（夜間試験と呼ばれる）、生産性を向上させる。試験スイート削減は、通常、何らかのカバレッジ基準を使用して行われる。試験の世界においては、カバレッジ基準は、実行されている試験の量を測定するとともに、試験プロセスを導く定量的メトリックとして、通常、使用される。カバレッジ基準は、通常、ソースコードの人為結果に関して定義される。例えば、ステートメントカバレッジは、試験中のアプリケーションの各ステートメントが、試験スイートの中の少なくとも１つの試験事例によってカバーされる（つまり、実行される）ことを要求する。アプリケーションは、試験スイートが、ある基準に関して完全である場合、その基準に従って１００％カバーされているものと考えられる。カバレッジ基準の別の例が、端部カバレッジ基準である。この場合、アプリケーションソフトウェアの制御フローグラフの各端部が、試験スイートの中の少なくとも１つの試験事例によって実行されることが要求される。

カバレッジ基準は、一般に、試験事例生成を導くのに使用されるが、試験スイート削減の二重の問題においても使用される。しばしば、試験事例は、いずれのカバレッジ基準に従っても生成されない。例えば、バグが識別され、修正される場合、多くの試験事例が追加される。また、試験スイート全体が、ランダムに生成されていることも可能である。カバレッジ基準が使用される場合でさえ、そのカバレッジ基準が、手に負えない数の試験事例（パスカバレッジ）を生成することが可能である。これらの事例のそれぞれにおいて、試験スイートは、削減又は優先順位付けを必要とする可能性がある。

試験スイート削減は、あるカバレッジ基準に従って所与の試験スイートを削減することに焦点を合わせる。例えば、ステートメントカバレッジ基準に従って試験スイートを削減することは、試験スイートの中の他の試験事例によって既に実行されているステートメントを実行する試験事例を除外することを暗示する。このプロセスは、既存の試験スイートから始まるので、カバレッジ基準に関して完全である試験スイートをもたらさない可能性がある。試験スイートが、カバレッジ基準を使用して既に生成されている場合、試験スイート削減は、より少ない数の試験事例につながる可能性がある別のカバレッジ基準を使用して実行されることが可能である。

試験スイート削減技法は、異なる２つのタイプに分類されることが可能である。第１のタイプの試験スイート削減技法は、ソースコードを要求し、更に／又はソースコードの大がかりな計装を実行する。第２のタイプの試験スイート削減技法は、バイナリに直接に作用し、ほとんど又は全く計装を要求しない。

ソース計装を多用した試験スイート最小化のための以前のアプローチのいくつかが、存在する。１つの以前のアプローチは、全使用カバレッジ基準を使用して、試験スイートを最小限に抑える。全使用カバレッジ基準は、プログラムにおける各変数定義、及び各変数定義のすべての使用が、試験スイートの中の少なくとも１つの試験事例によってカバーされることを要求する。全使用カバレッジ基準を使用することによって、障害検出能力の低減は、ほとんどない。しかし、変数定義、及び変数定義の使用を常に把握しておくことは、ソースコードの大がかりな計装を要求する。

別のアプローチにおいて、端部カバレッジ基準が、試験事例を最小限に抑える基準として使用される。この基準は、試験中のアプリケーションの制御フローグラフのすべての端部が、少なくとも１つの試験事例によってカバーされなければならないことを要求する。端部カバレッジ基準を使用することによって、試験スイートサイズの低減は、障害検出能力の大幅な低減によって相殺された。しかし、この技法は、各制御フロー端部がたどられる際に、各制御フロー端部を記録するようにソースコードを計装することを要求する。

別のアプローチは、プログラム実行を介して観察される動的不変要素を使用して（動作抽象化と呼ばれる）、試験スイートを最小限に抑える。各試験に関して、動作抽象化及び検査が計算されて、その試験が現在の動作抽象化を変化させるかどうかが調べられる。変化させる場合、現在の動作抽象化は、その新たな情報で更新され、その試験は、その最小化された試験スイートの中に保持される。そうではなく、その試験が、現在の動作抽象化を変化させない場合、その試験事例は、破棄される。このアプローチにおける不変要素は、オンプログラム変数、並びに他の変数若しくは定数に対する、これらの変数の関係である。これらの不変要素を計算することは、ほとんどのプログラム変数、及びこれらの変数の使用に対する計装を要求する。したがって、このアプローチは遅い。

他の試験スイート削減技法は、バイナリに作用する。１つのそのようなアプローチは、バイナリに直接に作用し、試験中のアプリケーションのソースを要求しないコールスタックベースの試験スイート削減アプローチであった。定義によるコールスタックは、プログラム実行の任意の時点におけるスタック上の関数コールのシーケンスである。このアプローチは、スイート削減のためのカバレッジ基準として試験事例によって生成される最大深度コールスタック（他のいずれの関数も呼び出さないリーフ関数に関して観察されるコールスタック）のセットを使用する。試験事例によって生成された最大深度コールスタックのセットが、以前の試験事例によって生成された最大深度コールスタックのサブセットである場合、その試験事例は、冗長であると考えられ、破棄される。

試験事例が試験スイートに含められるべきかどうかを判定するための方法及び装置が、本明細書で開示される。一実施形態において、方法は、ソフトウェアアプリケーション試験の実行中に、ある試験事例の試験入力を使用してアプリケーションを実行すること、及び試験スイートの中の他の試験事例の実行から生成された観察可能なイベントのＦＳＭ（有限状態マシン）モデルを使用して、アプリケーションの将来の試験における使用のために、その試験事例を試験スイートの中に含めるかどうかを判定することを含む。

本発明は、後段で与えられる詳細な説明、及び本発明の様々な実施形態の添付の図面から、より完全に理解されるが、このことは、本発明を、それらの特定の実施形態に限定するものとして解釈されるべきではなく、単に説明及び理解だけを目的としている。

試験スイート削減プロセスの一実施形態を示す流れ図である。 試験スイート削減プロセスの別の実施形態を示す流れ図である。 コードスニペットを示す図である。 試験入力に対して実行される図３の例示的なスニペットに関して構築されたシステムコールＦＳＭ（有限状態マシン）モデルを示す図である。 ソフトウェア試験環境を示すブロック図である。 コンピュータシステムの一実施形態を示すブロック図である。

ソフトウェア試験スイートを削減するための方法及び装置が、開示される。一実施形態において、ソフトウェア試験スイートは、障害を検出する能力の多くを失うことなしに削減される。一実施形態では、外部から観察可能なイベント（例えば、システムコール）が追跡されて、ソースを要求することなく、計装も全く要求することなしに、ソフトウェア試験スイートを削減するプロセスが制御される。一実施形態において、計装を全く要求することなしに、アプリケーションによって成されたシステムコールトレースを使用して、試験中のプログラムのカバレッジが測定される。システムコールは、入力／出力を多用するアプリケーションに関するアプリケーションの振舞いを正確にモデル化する。

一実施形態において、本明細書で説明される試験スイート削減技法は、システムコールシーケンスを観察することによって、試験中のアプリケーションのモデルを構築することを含む。構築されたシステムコールモデルを更新しない試験事例は、冗長であると考えられ、除外される。システムコールのいくつかの既存のモデルが、試験スイート削減のために有効に使用されることが可能である。一実施形態において、ＦＳＭ（有限状態マシン）モデルが、プログラムカウンタを状態とし、更にシステムコールを遷移として使用される。

以下の説明において、本発明のより徹底的な説明を与える多数の詳細が、示される。しかし、本発明は、これらの特定の詳細なしに実施されてもよいことが当業者には明白であろう。その他、よく知られた構造及びデバイスは、本発明を不明瞭にするのを避けるため、詳細にではなく、ブロック図形態で示される。

以下の詳細な説明のいくつかの部分は、コンピュータメモリ内部のデータビットに対する操作のアルゴリズム及び記号表現の点で提示される。これらのアルゴリズム記述及びアルゴリズム表現は、データ処理技術分野の業者によって、他の当業者に自らの作業の内容を最も効果的に伝えるのに使用される手段である。アルゴリズムは、この場合、更に一般的にも、所望される結果につながるステップの自己矛盾のないシーケンスであると考えられる。これらのステップは、物理量の物理的操作を要求するステップである。通常、ただし、必然的にではないが、これらの量は、格納される、転送される、組み合わされる、比較される、更にそれ以外で操作されることが可能な電気信号又は磁気信号の形態をとる。ときとして、主に一般的な用法の理由で、これらの信号をビット、値、要素、シンボル、文字、項、数などと呼ぶことが好都合であることが判明している。しかし、これら、及び類似する用語のすべては、適切な物理量に関連付けられるべきであり、これらの量に適用された便利なラベルに過ぎないことに留意されたい。以下の説明から明白なとおり、特に明記しない限り、説明の全体にわたって、「処理すること」、又は「演算すること」、又は「計算すること」、又は「判定すること」、又は「表示すること」などの用語を利用する説明は、コンピュータシステムのレジスタ及びメモリの内部の物理（電子的）量として表されるデータを操作して、コンピュータシステムメモリ若しくはコンピュータシステムレジスタ、或いは他のそのような情報格納デバイス、情報伝送デバイス、又は情報表示デバイスの内部の物理量として同様に表される他のデータに変換する、コンピュータシステム、又は類似した電子コンピューティングデバイスのアクション及びプロセスを指すものと理解される。

また、本発明は、本明細書の動作を実行するための装置にも関する。この装置は、要求される目的で特別に構築されることが可能であり、或いはコンピュータの中に格納されたコンピュータプログラムによって選択的に活性化される、又は再構成される汎用コンピュータを備えることが可能である。そのようなコンピュータプログラムは、フレキシブルディスク、光ディスク、ＣＤ‐ＲＯＭ、及び光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ（読み取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード又は光カード、或いは電子命令を格納するのに適した任意のタイプの媒体などの、ただし、以上には限定されない、更にそれぞれがコンピュータシステムバスに結合されたコンピュータ可読記憶媒体の中に格納されることが可能である。

本明細書で提示されるアルゴリズム及び表示は、いずれの特定のコンピュータ、又は他の装置とも本来的に関係しない。様々な汎用システムが、本明細書の教示によるプログラムと一緒に使用されることが可能であり、或いは要求される方法ステップを実行する、より特化した装置を構築することが好都合であると判明する可能性もある。様々なこれらのシステムに関する要求される構造は、以下の説明から明白となろう。更に、本発明は、いずれの特定のプログラミング言語に関連しても説明されない。様々なプログラミング言語が、本明細書で説明されるとおり、本発明の教示を実施するのに使用されることが可能であることが理解されよう。マシン可読媒体は、マシン（例えば、コンピュータ）によって読み取り可能な形態で情報を格納するため、又は伝送するための任意の機構を含む。例えば、マシン可読媒体は、読み取り専用メモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリデバイスなどを含む。

概略
試験スイート削減を実行するのに、本発明の一実施形態は、試験事例に対して実行された際のプログラムの実行からのシステムコールトレースを獲得し、後でこれらのトレースを試験スイート削減のために使用する。例えば、プログラムが、ある試験事例に対して実行された際に、すべて以前に観察されている人為結果を生成した場合、その試験事例は、冗長であると考えられる。システムコールトレースは、いずれのアプリケーションにおけるＩ／Ｏ（入出力）操作もシステムコールを介して行われるため、試験スイート削減のための人為結果の正確なセットとして使用される。このため、システムコールトレースを捕捉することにより、プログラムのＩ／Ｏの振舞いの良好な近似がもたらされる。一実施形態において、プログラムの計算上の態様は、システムコール単独によっては捕捉されない。

ときとして、アプリケーションから直接にシステムコールトレースを使用することは、あまり利益をもたらさない可能性がある。例えば、ある試験事例が、あるシステムコールで、あるループをｎ回、呼び出し、別の試験事例が、同一のループをｎ＋１回、呼び出す場合、この２つの試験事例に関するシステムコールトレースは、異なり、削減は、全く可能でない。更に、プログラムにおけるループのため、システムコールトレースは、しばしば、長く、処理に関して手に負えない量のデータにつながる可能性がある。したがって、一実施形態では、システムコールトレースを分類するモデルが、使用された。一実施形態では、ＦＳＭ（有限状態マシン）モデルが、使用される。一実施形態において、使用されるＦＳＭモデルは、Ｓｅｋａｒ及び他、「Ａ Ｆａｓｔ Ａｕｔｏｍａｔｏｎ‐ｂａｓｅｄ Ｍｅｔｈｏｄ ｆｏｒ Ｄｅｔｅｃｔｉｎｇ Ａｎｏｍａｌｏｕｓ Ｐｒｏｇｒａｍ Ｂｅｈａｖｉｏｕｒｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００１ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、２００１年、１４４〜１５５ページにおいて説明される。しかし、システムコールをモデル化するための他のアプローチが、使用されることも可能である。

図１は、試験スイート削減プロセスの一実施形態の流れ図である。このプロセスは、ハードウェア（回路、専用ロジックなど）、ソフトウェア（汎用コンピュータシステム又は専用桟などの上で実行されるような）、或いはハードウェアとソフトウェアの組み合わせを備えることが可能な処理ロジックによって実行される。

図１を参照すると、プロセスは、処理ロジックが、アプリケーションの実行中に観察された、観察されたイベントのＦＳＭ（有限状態マシン）モデルを構築することから始まる（処理ブロック１０１）。このモデルは、カバレッジ基準として使用される。一実施形態において、観察されるイベントは、システムコールを含む。一実施形態において、ＦＳＭモデルにおける状態は、試験事例におけるシステムコールのプログラムカウンタ値を表し、更にＦＳＭモデルにおける遷移は、システムコールを表す。

次に、処理ロジックは、ソフトウェアアプリケーション試験を実行している間に、ある試験事例の試験入力を使用してアプリケーションを実行する（処理ブロック１０２）。

試験スイートの中の他の試験事例の実行からの観察されたイベントに基づくカバレッジ基準を使用して、処理ロジックは、アプリケーションの将来の試験において使用するために、その試験事例を試験スイートに追加すべきかどうかを判定する（処理ブロック１０３）。

その試験事例が追加されるべき場合、処理ロジックは、少なくとも１つの更なる遷移又は状態がＦＳＭモデルに以前に入っていなかった場合、その少なくとも１つの更なる遷移又は状態を含むようにＦＳＭモデルを更新する（処理ブロック１０４）。処理ロジックが、その試験事例を冗長であると識別した場合（その試験事例の振舞いが、カバレッジ基準によって示されるところにより、以前に観察されている場合）、処理ロジックは、その試験事例を試験スイートから除去する（処理ブロック１０５）。

次に、処理ロジックは、検査すべき更なる試験事例が存在するかどうかを判定する（処理ブロック１０６）。存在する場合、プロセスは、プロセスが繰り返される処理ブロック１０２に遷移する。存在しない場合、プロセスは、終了する。

図２は、試験スイート削減プロセスの別の実施形態の流れ図である。このプロセスは、ハードウェア（回路、専用ロジックなど）、ソフトウェア（汎用コンピュータシステム又は専用桟などの上で実行されるような）、或いはハードウェアとソフトウェアの組み合わせを備えることが可能な処理ロジックによって実行される。

図２を参照すると、プロセスは、処理ロジックが、試験中のソフトウェアアプリケーションのシステムコールカバレッジの表現を保持することから始まる（処理ブロック２０１）。この表現は、アプリケーション上で実行される試験スイートの中の１つ又は複数の試験事例のセットからの１つ又は複数のシステムコールトレースに基づいて、生成される。一実施形態において、この表現は、試験スイートの中の試験事例の実行中に生じたシステムコールシーケンスを観察することによって構築されたアプリケーションのモデルを含む。一実施形態において、このモデルは、ＦＳＭ（有限状態マシン）モデルを含む。一実施形態において、システムコールシーケンスは、アプリケーションのＩ／Ｏ（入出力）特性を捕捉する。

この表現（例えば、ＦＳＭモデル）を保持しながら、処理ロジックは、更なる試験事例の試験入力を使用してアプリケーションを実行し（処理ブロック２０２）、更にこれらの試験入力を使用してアプリケーションを実行している間に、その更なる試験事例に関連する少なくとも１つのシステムコールシーケンスをログ記録する（処理ブロック２０３）。システムコールシーケンスは、１つ又は複数のシステムコールを有する。

システムコールシーケンス（複数可）をログ記録した後、処理ロジックは、実行された更なる試験事例のシステムコールシーケンスにおける観察されたシステムコールで更新された場合に、システムコールカバレッジの表現が変化するかどうかに基づいて、その更なる試験事例を試験スイートの中に含めるべきかどうかを評価する（処理ブロック２０４）。

１つの実例において、処理ロジックは、更なる試験事例に関連する１つ又は複数のシステムコールで更新された場合に、アプリケーションに関するシステムコールカバレッジの表現に全く変化が生じない場合、その更なる試験事例が試験スイートの中に含められることを防止する（処理ブロック２０５）。

別の実例において、処理ロジックは、状態又は遷移が表現（例えば、ＦＳＭモデル）の中に以前に含められていなかった場合、更なる試験事例の実行に応答して、その状態又は遷移を追加するようにその表現を更新する（処理ブロック２０６）。

例示
これらの技法は、例を使用して説明することが可能である。図３は、コードスニペットを示す。図３を参照すると、コードスニペットは、Ｌ１でオープンシステムコールを行い、ループにおいてファイルからの読み取り、又はファイルへの書き込みを行い、最後にＬ４でファイルを閉じる。コードスニペット上でソフトウェア試験を実行している際、ＦＳＭ（有限状態マシン）モデル構築アルゴリズムが、ＦＳＭモデルを構築するのに使用される。一実施形態において、ＦＳＭモデル構築アルゴリズムは、参照により本明細書に組み込まれている、Ｓｅｋａｒ及び他、「Ａ Ｆａｓｔ Ａｕｔｏｍａｔｏｎ‐ｂａｓｅｄ Ｍｅｔｈｏｄ ｆｏｒ Ｄｅｔｅｃｔｉｎｇ Ａｎｏｍａｌｏｕｓ Ｐｒｏｇｒａｍ Ｂｅｈａｖｉｏｕｒｓ」、Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２００１ ＩＥＥＥ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、２００１年、１４４〜１５５ページにおいて説明されるアルゴリズムである。ＦＳＭモデル構築アルゴリズムは、プログラム実行中に観察されたシステムコールトレースからＦＳＭを構築する。そのような事例において、プログラムカウンタが、ＦＳＭに関する状態として使用され、更にシステムコールが、ＦＳＭに関する遷移として使用される。

一実施形態において、構築アルゴリズム自体は、相当に単純明快である。試験を実行しているシステムは、システムコールのたびにプログラムを停止し、ＦＳＭを構築するための以下に説明されるＦＳＭ構築手順を使用する。一実施形態において、この手順は、システムコールが行われた際に、プログラムカウンタ値をシステムコール番号と一緒に取り込む。本明細書に関して、ｐｒｅｖｉｏｕｓ＿ｐｃは、ＦＳＭが置かれていた前の状態（プログラムカウンタ値）を保持するグローバル変数であり、更にＡｄｄＴｒａｎｓｉｔｉｏｎ（ｐｃ１，ｐｃ２，ｓｙｓｃａｌｌ）手順は、ｐｃ１からｐｃ２への遷移をシステムコールと一緒に、遷移としてＦＳＭに追加する。
previous_pc= 0; /^* init state ^*/
ConstructFSM(unsignedProgramCounter, unsigned
SysCall){
AddTransition(previous_pc, ProgramCounter,
SysCall);
previous_pc = ProgramCounter;
}

ＦＳＭ構築アルゴリズム動作を説明するのに、実行例のための４つの試験事例から成る試験スイートを考慮されたい。このコードスニペットに関する４つの試験事例に関して生成されるシステムコールは、以下の表に示されるとおりであるものと想定されたい。第１の試験事例、Ｔｅｓｔ１が、ファイルを開き、ファイルから２回読み取り（ループのため）、その後、ファイルを閉じる。Ｔｅｓｔ２が、ファイルを開き、ファイルに２回書き込み、その後、ファイルを閉じる。Ｔｅｓｔ３が、ファイルを開き、ファイルから２回読み取り、その後、ファイルを閉じる。Ｔｅｓｔ４が、ファイルを開き、ファイルから３回読み取り、その後、ファイルを閉じる。

第１の試験事例に関して、この試験事例は、Ｌ１で、プログラムポイントを開き、Ｌ２で、プログラムポイントを読み取り（２回）、その後、Ｌ４で、クローズシステムコールを行うことに注目されたい。システムコールトレース及びプログラムカウンタ値を観察することによってソフトウェア試験システムによって構築されるＦＳＭが、図４に埋め込まれている。Ｔｅｓｔ２から、既存のＦＳＭは、Ｌ１からＬ３へ、Ｌ３からＬ４へ、更にＬ３からＬ３自らへの新たな遷移を追加することによって更新される。このため、試験事例ｔｅｓｔ１及びｔｅｓｔ２を使用することによって、図４に示される完全なＦＳＭが得られることが可能である。試験事例、ｔｅｓｔ３及びｔｅｓｔ４は、ＦＳＭにおいて新たな遷移を全くもたらさないことに留意されたい。

一実施形態において、試験スイート削減アルゴリズムは、前述したＦＳＭ構築アルゴリズムの拡張である。試験スイート削減を実行するため、以前の試験事例を使用して構築された現在のＦＳＭが、保持される。一実施形態において、現在のＦＳＭは、メモリの中に格納されることが可能であり、更にソフトウェア試験システムによってアクセス可能であり得る。それぞれの新たな試験事例に関して、プログラムは、その新たな試験事例に関連する試験入力に対して実行され、ＦＳＭの更新が試みられる。ＦＳＭの更新が存在しない（すなわち、新たな遷移又は新たな状態が全く追加されない）場合、その試験事例は、冗長であるという印を付けられる。この説明は、以下のステップとして要約されることが可能である。すなわち、
ＣｕｒｒｅｎｔＦＭＳ：＝φ
試験スイートの中の各試験事例に関して、
その試験入力に対してプログラムを実行し、
ＦＳＭ構築アルゴリズムを使用して現在のＦＳＭを更新し、更に、
更新が存在しない場合、その試験事例に冗長であるという印を付ける。

前述の例の場合、試験スイートが、試験事例、ｔｅｓｔ１、ｔｅｓｔ２、ｔｅｓｔ３、及びｔｅｓｔ４をこの順序で有していたと想定すると、試験事例、ｔｅｓｔ３及びｔｅｓｔ４は、図４に示されるとおり、ＦＳＭに全く更新を行わないので、冗長であるという印を付けられる。

以上に説明された試験スイート削減アルゴリズムは、一実施形態に過ぎず、その試験スイートの中でまず分析される試験事例寄りのバイアスを示す。一実施形態において、初めの試験スイート寄りのバイアスは、試験スイートから試験事例をランダムに選択することによって解消される。生成された試験スイートをカバーすることができる試験事例の、より最適に近いセットを得ることは、ＮＰ完全問題である。

一実施形態において、削減アルゴリズムは、Ｌｉｎｕｘ（Ｕｂｕｎｔｕ、Ｋｅｒｎｅｌ ２．６）において実施され、システムコールインターセプトのためにｅｔｒａｃｅパッケージが使用される。ｅｔｒａｃｅパッケージについての更なる情報に関しては、Ｊａｉｎ及びＳｅｋｅｒ、「Ｕｓｅｒ‐Ｌｅｖｅｌ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｆｏｒ Ｓｙｓｔｅｍ Ｃａｌｌ Ｉｎｔｅｒｐｏｓｉｔｉｏｎ：Ａ Ｐｌａｔｆｏｒｍ ｆｏｒ Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｃｏｎｆｉｎｅｍｅｎｔ」、ＩＳＯＣ Ｎｅｔｗｏｒｋ ａｎｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍ Ｓｅｃｕｒｉｔｙ、１９９９年、１９〜２４ページ掲載を参照されたい。ｅｔｒａｃｅパッケージは、システムコールインターセプトのためにｐｔｒａｃｅ機構を使用し、各システムコール後にプログラムを停止する。このことは、システムコールのタイプに関する情報、及びプログラムカウンタ値が収集されることを可能にする。このタイプのシステムコールインターセプト／割り込みは、割り込みが、異なるプロセスによってユーザレベルで行われるので、ユーザレベルシステムコール割り込みと呼ばれる。別の実施形態において、割り込みは、カーネルレベルモジュールを使用してカーネルレベルで実行される。この割り込みは、Ｆｒａｓｅｒ及び他、「Ｈａｒｄｅｎｉｎｇ ＣＯＴＳ Ｓｏｆｔｗａｒｅ ｗｉｔｈ Ｇｅｎｅｒｉｃ Ｓｏｆｔｗａｒｅ Ｗｒａｐｐｅｒｓ」、ＩＥＥＥ Ｓｙｍ．ｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、１９９９年、２〜１６ページにおいて説明される技法を使用して実施されることが可能である。カーネルオプションは、コンテキスト切り換えが存在しないため、ランタイムオーバーヘッドがより少ないが、ユーザレベルシステムコール割り込みの方が、実施すること、及びデバッグすることが容易である。

他の実施形態において、ウインドウズ（Ｗｉｎｄｏｗｓ）（登録商標）、ＭａｃＯＳ（登録商標）、ＢＳＤ（登録商標）のようなオペレーティングシステムはすべて、使用されることが可能なシステムコール（又は均等物）を有する。これらのオペレーティングシステムのすべてに関するシステムコールインターセプトツール／機構は、よく知られており、入手可能である。

プログラムは、ほとんど必ず、ライブラリ（例えば、標準のＣライブラリなど）からシステムコールを行う。プログラムカウンタ値が、システムコールの時点で、ＦＳＭにおける状態として使用される場合、ＦＳＭは、プログラムの振舞いではなく、ライブラリの振舞いを表す。この問題を解決するのに、まず、プログラムテキストに関する可能なアドレスのリストが、バイナリを静的に分析することによって記録される。何らかのシステムコールをインターセプトした後、スタックの一番上のリターンアドレスが検査されて、そのアドレスが、記録されたプログラムテキストに属するかどうかが調べられる。そのリターンアドレスが、記録されたプログラムテキストではない場合、スタックフレームを走査して、現在の関数の呼び出し元のリターンアドレスが探し出される。このプロセスは、プログラムテキストに属するリターンアドレスにヒットするまで繰り返され、更にそのアドレスが、ＦＳＭにおけるプログラムカウンタとして使用される。

前述したとおり、一実施形態において、データ値は、考慮されない。このことは、一部の計算上の誤りが、削減された試験スイートによって捕捉されないことを意味する可能性がある。システムコール引数やシステムコールリターン値のような少なくともいくつかのデータ値を考慮に入れるシステムコールモデルの精度を高めることによって、削減されたスイートは、より多くの計算上の誤りを捕捉することができる可能性がある。一実施形態において、そのようなコンテキスト情報が、試験スイート削減プロセスにおいて使用される。一実施形態において、コンテキスト情報は、システムコールが、侵入検出構築（例えば、Ｆｅｎｇ及び他、「Ａｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎ Ｕｓｉｎｇ Ｃａｌｌ Ｓｔａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ」、２００３年に記載されるとおりのプッシュダウンオートマトン、Ｂｈａｔｈａｒ及び他、「Ｄａｔａｆｌｏｗ Ａｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎ」、ＩＥＥＥ Ｓｙｍ．ｏｎ Ｓｅｃｕｒｉｔｙ ａｎｄ Ｐｒｉｖａｃｙ、カリフォルニア州オークランド、２００６年５月に記載されるデータフロー）のコンテキストに含められているのと同一の仕方で、ＦＳＭモデルにおいて使用される。このため、一実施形態において、ＦＳＭモデルは、これらのより正確なモデルのいずれかを捕捉するとともに、より良好な試験スイート削減を実現するように拡張される。

試験環境の一実施形態
図５は、試験環境の一実施形態のブロック図である。図５を参照すると、テスタ５０１が、メモリ５０２に結合されるのが示される。テスタ５０１は、メモリ５０２の中に格納された新たな試験事例５１０を使用して試験されるソフトウェアであるアプリケーション５２０を実行する。また、メモリ５０２は、試験スイート及びＦＳＭモデル５１２を格納する試験スイートフォルダ５１１も格納する。新たな試験事例５１０は、試験スイートフォルダ５１１の中の試験の１つであることが可能であることに留意されたい。また、１つだけしかメモリが示されていないものの、メモリ５０２は、複数のメモリを表すことが可能であることにも留意されたい。

テスタ５０１が、新たな試験事例５１０からの試験入力を使用してアプリケーション５２０を試験する一方で、システムコールのロガー５０３が、外部から観察可能なイベントをメモリの中にログ記録する。メモリは、ロガー５０３の一部であることも、ロガー５０３の外部のメモリ（例えば、メモリ５０２）であることも可能である。一実施形態において、外部から観察可能なイベントは、システムコールを含み、更にロガー５０３は、システムコールに関連するプログラムカウンタ値、及びシステムコール自体をログ記録する。

モデルチェッカ／アップデータ５０４が、メモリ５０２にアクセスして、ＦＳＭモデルファイル５１２を獲得し、更に、新たな試験事例５１０を使用したアプリケーション５２０の実行からのログ記録された情報に基づいて、ＦＳＭモデルファイル５１２を更新しようと試みる。モデルチェッカ／アップデータ５０４が、ＦＳＭモデルファイル５１２の更新が、ロガー５０３によってログ記録された、外部から観察されるイベント情報に関して全く生じないと判定した場合、モデルチェッカ／アップデータ５０４は、新たな試験事例５１０が試験スイート５１１の中に含められることを防止する試験状態更新機構５０５に通知する。そのような場合、一実施形態において、試験状態更新機構５０５は、新たな試験事例５１０が、試験スイートフィルタ５１１の中に格納された試験スイートに追加されないようにする。別の実施形態において、そのような場合、試験状態更新機構５０５は、新たな試験事例５１０が、試験スイートフォルダ５１１の中に格納された試験スイートから除去されるようにする。

モデルチェッカ／アップデータ５０４が、ＦＳＭモデルファイル５１２の更新が、ロガー５０３によってログ記録された、外部から観察されるイベント情報に関して生じると判定した（例えば、ログ記録された情報が、新たな状態、又は新たな遷移がＦＳＭモデルファイル５１２に追加されることを示す）場合、モデルチェッカ／アップデータ５０４は、このことを試験状態更新機構５０５に通知する。そのような場合、一実施形態において、試験状態更新機構５０５は、新たな試験事例５１０が、試験スイートフォルダ５１１の中に格納された試験スイートに追加されるようにする。別の実施形態において、そのような場合、試験状態更新機構５０５は、新たな試験事例５１０が、試験スイートフォルダ５１１の中に格納された試験スイートの中に留まるようにする。やはりそのような場合に、モデルチェッカ／アップデータ５０４は、ＦＳＭモデルファイル５１２を更新し、ＦＳＭモデルファイル５１２の更新されたバージョンをメモリ５０２の中に再び格納する。

コンピュータシステムの例
図６は、本明細書で説明される動作の１つ又は複数を実行することができる例示的なコンピュータシステムのブロック図である。図６を参照すると、コンピュータシステム６００が、例示的なクライアントコンピュータシステム又はサーバコンピュータシステムを備えることが可能である。コンピュータシステム６００は、情報を通信するための通信機構又は通信バス６１１と、情報を処理するためにバス６１１に結合されたプロセッサ６１２とを備える。プロセッサ６１２は、例えば、ペンティアム（Ｐｅｎｔｉｕｍ）（登録商標）、ＰｏｗｅｒＰＣ（登録商標）、Ａｌｐｈａ（登録商標）などのマイクロプロセッサを含むが、マイクロプロセッサには限定されない。

システム６００は、プロセッサ６１２によって実行されるべき情報及び命令を格納するためにバス６１１に結合されたＲＡＭ（ランダムアクセスメモリ）、又は他の動的ストレージデバイス６０４（メインメモリと呼ばれる）を更に備える。また、メインメモリ６０４は、プロセッサ６１２による命令の実行中に一時的な変数又は他の中間情報を格納するために使用されることも可能である。

また、コンピュータシステム６００は、プロセッサ６１２のために静的情報及び命令を格納するためにバス６１１に結合されたＲＯＭ（読み取り専用メモリ）、及び／又は他の静的ストレージデバイス６０６と、磁気ディスク又は光ディスク、及び対応するディスクドライブなどのデータストレージデバイス６０７とを備える。データストレージデバイス６０７は、情報及び命令を格納するためにバス６１１に結合される。

コンピュータシステム６００は、コンピュータユーザに情報を表示するためにバス６１１に結合された、ＣＲＴ（陰極線管）又はＬＣＤ（液晶ディスプレイ）などのディスプレイデバイス６２１に更に結合されることが可能である。また、英数字キー及び他のキーを含む英数字入力デバイス６２２が、情報及びコマンド選択をプロセッサ６１２に伝えるためにバス６１１に結合されることも可能である。更なるユーザ入力デバイスは、方向情報及びコマンド選択をプロセッサ６１２に伝えるため、及びディスプレイ６１２上のカーソルの動きを制御するためにバス６１１に結合された、マウス、トラックボール、トラックパッド、スタイラス、又はカーソル方向キーなどのカーソルコントロール６２３である。

バス６１１に結合されることが可能な別のデバイスは、紙、フィルム、又は類似したタイプの媒体などの媒体の上に情報を印すために使用されることが可能なハードコピーデバイス６２４である。バス６１１に結合されることが可能な別のデバイスは、電話機又はハンドヘルドパームデバイスに通信する有線／無線通信機能６２５である。システム６００の構成要素のいずれか、又はすべて、及び関連するハードウェアが、本発明において使用されることが可能であることに留意されたい。しかし、コンピュータシステムの他の構成は、これらのデバイスの一部又は全部を含むことが可能であることが理解され得る。

以上の説明を読んだ後、本発明の多数の変更及び変形が、間違いなく、当業者には明白となるが、例として図示され、説明されるいずれの特定の実施形態も、全く限定するものではないことを理解されたい。したがって、様々な実施形態の詳細について述べたことは、特許請求の範囲を限定することを意図しておらず、特許請求の範囲自体は、本発明に不可欠と見なされる特徴だけを記載する。

Claims (3)

1. ソフトウェアアプリケーション試験の実行中に、ある試験事例の試験入力を使用してアプリケーションを実行するステップと、
   試験スイートの中の他の試験事例の実行から生成された観察可能なイベントのＦＳＭ（有限状態マシン）モデルを使用して、前記アプリケーションの将来の試験での使用のため前記試験事例を前記試験スイートの中に含めるかどうかを判定するステップと、
   を含む方法。
2. 試験中のソフトウェアアプリケーションのシステムコールカバレッジのモデルを保持するステップであって、前記モデルが、前記アプリケーション上で実行された試験スイートの中の１つ又は複数の試験事例の実行中に生じたシステムコールシーケンスの観察に基づいて生成される、当該ステップと、
   更なる試験事例の試験入力を使用して前記アプリケーションを実行するステップと、
   前記更なる試験事例の実行中に観察された前記更なる試験事例の前記システムコールシーケンスにおける１つ又は複数のシステムコールで更新が行われた場合に、前記システムコールカバレッジの前記モデルが変化するかどうかに基づいて、前記試験スイートの中に前記更なる試験事例を含めることを評価するステップと、
   を含む方法。
3. 複数の命令を格納する１つ又は複数のコンピュータ可読記憶媒体を有する製造品であって、
   前記複数の命令がシステムによって実行されたときに、前記システムが、
   ソフトウェアアプリケーション試験の実行中に、ある試験事例の試験入力を使用してアプリケーションを実行するステップと、
   試験スイートの中の他の試験事例の実行から生成された観察可能なイベントのＦＳＭ（有限状態マシン）モデルを使用して、前記アプリケーションの将来の試験での使用のため前記試験事例を前記試験スイートの中に含めるかどうかを判定するステップと、
   を含む方法、
   を実行する、前記製造品。

Images