JP2023554057A - 隠れ変数、隠れ属性、および隠れ値検出を用いたシステム・テスト・インフラストラクチャ - Google Patents

Abstract

テスト対象システム（ＳＵＴ）への入力が、属性値ペアの集合としてモデル化される。テスト・ケースのセットは、属性値ペアの完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを用いて実行される。テスト・ケースの実行毎に、非バイナリ成功率（ＳＡＶ）が、バイナリ実行結果に基づいて属性値ペア毎に計算される。属性は、上記属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて選択される。テスト・ケースのセットが、選択された属性のための追加の値を使用するテスト・ベクトルの別のセットを用いて実行される。テスト・ケースのセットの実行毎に、第２の非バイナリ成功率（ＳＡＶ’）が、属性値ペア毎に記録される。ここで所定の閾値が満たされる場合、検出された属性のための追加の値がユーザに通知される。

Description

本発明は、コンピュータ・システムのテストに関し、より詳細には、テストされていないがテストすべきである、隠れ変数、隠れ属性、および隠れ属性値を識別し得るテスト・ケース・インフラストラクチャに関する。さらに、本発明は、例えば、そのような変数をテストするために追加のテスト・ケースを生成すること、実行しなければならないコード・パスを識別すること、などによって、識別された隠れ変数を使用して、テスト・インフラストラクチャを改善することに関する。

コンピュータ化デバイスは、文書を書くこと、信号機の制御、電子商取引の完了から有人宇宙船任務の制御まで、我々の生活のほとんど全ての側面を制御する。しかしながら、コンピュータ化デバイスは、エラーが生じ易いことが多く、したがって、エラーを発見し補正するテスト段階を必要とする。テスト段階は、コンピュータ化デバイスを設計する際の最も困難なタスクの１つと考えられる。エラーを発見しないことの代償は、コンピュータ化デバイスの利用方法次第では莫大であることがあるため、徹底的なテストが重要である。ソフトウェアをチェックするためのカバレッジ・ツールは、評価されているソフトウェアがテスト中にどのくらいうまく実行されているかの尺度を提供し、それによりソフトウェアが高品質であるという保証のレベルを与える。

本発明の１つまたは複数の実施形態によれば、テスト対象システム（ＳＵＴ）をテストするときに欠陥を検出および限局するための方法は、ＳＵＴへの入力を属性値ペアの集合としてモデル化することと、属性値ペアによって表されたテスト空間の完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、を含む。方法は、テスト・ベクトルの初期セットからテスト・ケースのセットを生成することをさらに含む。方法は、テスト・ケースのセットを実行して実行結果のセットを取得することであって、実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、テスト・ケースのセットが、複数回実行される、実行結果のセットを取得することをさらに含む。方法は、テスト・ケースのセットの実行毎に、実行結果に基づいて非バイナリ成功率（Ｓ_ＡＶ）を属性値ペア毎に更新することであって、属性値ペアの非バイナリ成功率が、上記属性値ペアを使用する各テスト・ケースの実行結果に基づく、更新することをさらに含む。方法は、属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて上記属性を選択することをさらに含む。選択される属性のための追加の値を含む、テスト・ベクトルの第２のセットが生成される。さらに、テスト・ケースのセットは、テスト・ベクトルの第２のセットを用いて実行結果の第２のセットを取得するために実行され、テスト・ケースのセットが、少なくとも所定の回数実行される。さらに、テスト・ケースのセットの実行毎に、第２の非バイナリ成功率（Ｓ_ＡＶ’）が、実行結果に基づいて属性値ペア毎に記録される。上記属性を含む属性値ペアのセットに対応する第２の成功率のセットが所定の閾値を満たすことに応じて、検出された属性のための追加の値がユーザに通知される。

本発明の１つまたは複数の実施形態によれば、システムは、メモリと、メモリに連結されたプロセッサと、を含み、プロセッサが、テスト対象システム（ＳＵＴ）をテストするときに欠陥を検出および限局する方法を実行する。方法は、ＳＵＴへの入力を属性値ペアの集合としてモデル化することと、属性値ペアによって表されたテスト空間の完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、を含む。方法は、テスト・ベクトルの初期セットからテスト・ケースのセットを生成することをさらに含む。方法は、テスト・ケースのセットを実行して実行結果のセットを取得することであって、実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、テスト・ケースのセットが、複数回実行される、実行結果のセットを取得することをさらに含む。方法は、テスト・ケースのセットの実行毎に、実行結果に基づいて非バイナリ成功率（Ｓ_ＡＶ）を属性値ペア毎に更新することであって、属性値ペアの非バイナリ成功率が、上記属性値ペアを使用する各テスト・ケースの実行結果に基づく、更新することをさらに含む。方法は、上記属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて属性を選択することをさらに含む。選択される属性のための追加の値を含む、テスト・ベクトルの第２のセットが生成される。さらに、テスト・ケースのセットは、テスト・ベクトルの第２のセットを用いて実行結果の第２のセットを取得するために実行され、テスト・ケースのセットが、少なくとも所定の回数実行される。さらに、テスト・ケースのセットの実行毎に、第２の非バイナリ成功率（Ｓ_ＡＶ’）が、実行結果に基づいて属性値ペア毎に記録される。上記属性を含む属性値ペアのセットに対応する第２の成功率のセットが所定の閾値を満たすことに応じて、検出された属性のための追加の値がユーザに通知される。

本発明の１つまたは複数の実施形態によれば、コンピュータ・プログラム製品は、プロセッサによる実行時にテスト対象システム（ＳＵＴ）をテストするときに欠陥を検出および限局する方法をプロセッサに実行させる、コンピュータ実行可能命令が記憶されたコンピュータ可読記憶媒体を含む。方法は、ＳＵＴへの入力を属性値ペアの集合としてモデル化することと、属性値ペアによって表されたテスト空間の完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、を含む。方法は、テスト・ベクトルの初期セットからテスト・ケースのセットを生成することをさらに含む。方法は、テスト・ケースのセットを実行して実行結果のセットを取得することであって、実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、テスト・ケースのセットが、複数回実行される、実行結果のセットを取得することをさらに含む。方法は、テスト・ケースのセットの実行毎に、実行結果に基づいて非バイナリ成功率（Ｓ_ＡＶ）を属性値ペア毎に更新することであって、属性値ペアの非バイナリ成功率が、上記属性値ペアを使用する各テスト・ケースの実行結果に基づく、更新することをさらに含む。方法は、上記属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて属性を選択することをさらに含む。選択される属性のための追加の値を含む、テスト・ベクトルの第２のセットが生成される。さらに、テスト・ケースのセットは、テスト・ベクトルの第２のセットを用いて実行結果の第２のセットを取得するために実行され、テスト・ケースのセットが、少なくとも所定の回数実行される。さらに、テスト・ケースのセットの実行毎に、第２の非バイナリ成功率（Ｓ_ＡＶ’）が、実行結果に基づいて属性値ペア毎に記録される。上記属性を含む属性値ペアのセットに対応する第２の成功率のセットが所定の閾値を満たすことに応じて、検出された属性のための追加の値がユーザに通知される。

追加の技術的特徴および利益が、本発明の技術を通して実現される。本発明の実施形態および態様が、本明細書において詳細に説明され、特許請求される主題の一部と考えられる。より良く理解するために、詳細な説明および図面を参照する。

本明細書で説明される排他的権利の詳細は、明細書の末尾における特許請求の範囲において詳細に指示され、明確に請求される。本発明の実施形態の、前述のおよびその他の特徴および利点は、添付図面と併せて用いられる以下の詳細な説明から明らかである。

本発明の１つまたは複数の実施形態による、コンピュータ化環境の概略図を示す。 本発明の実施形態による、テスト・インフラストラクチャを提供するモジュールを表すブロック図である。 本発明の１つまたは複数の実施形態による、組み合わせテスト設計（ＣＴＤ）を用いた欠陥検出および限局、ならびに検出された欠陥を顕在化させる失敗テスト・ケースの回帰バケットの生成を示す概略ハイブリッド・データ・フロー／ブロック図である。 本発明の１つまたは複数の実施形態による、例としてのＣＴＤベクトルのセットを示す。 本発明の１つまたは複数の実施形態による、例としてのＣＴＤベクトルを示す。 本発明の１つまたは複数の実施形態による、ＣＴＤ技術を用いてｎワイズ欠陥を検出および限局するため、ならびに検出されたｎワイズ欠陥を顕在化させる失敗テスト・ケースの回帰バケットを生成するための、例示的方法のプロセス・フロー図である。 本発明の１つまたは複数の実施形態による、テスト対象システムをテストするときに経時的な属性値ペアの成功率を用いてテスト・モデルの不備を検出する方法のフローチャートを示す。 本発明の１つまたは複数の実施形態による、属性値ペアの成功率（Ｓ_ＡＶ）の可視化の例を示す。 本発明の１つまたは複数の実施形態による、隠れ属性が現在のテスト・モデルに存在するかどうかを判断する方法のフローチャートを示す。 本発明の１つまたは複数の実施形態による、隠れ属性を駆動するテスト対象システムの部分を識別する方法のフローチャートを示す。 本発明の１つまたは複数の実施形態による、隠れ属性を駆動するＳＵＴの部分を識別する方法のフローチャートを示す。 本発明の１つまたは複数の実施形態による、コンピュータ・システムを示す。 本発明の１つまたは複数の実施形態による、クラウド・コンピューティング環境を示す。 本発明の１つまたは複数の実施形態による、抽象化モデル層を示す。

本明細書で示される図は、例示である。本発明の思想から逸脱することなく、図面またはそこに説明される動作に対して多くの変形が存在し得る。例えば、アクションは、異なる順序で実行されてもよく、またはアクションが、追加され、削除され、もしくは修正されてもよい。また、「連結される」という用語およびその変形は、２つの要素間に通信経路を有することを述べ、要素間に介在要素／接続のない要素間の直接接続を意味するものではない。これらの変形の全てが、明細書の一部と考えられる。

本発明の例示的実施形態は、特に、組み合わせテスト設計（ＣＴＤ）技術を用いて欠陥検出および限局を実行するため、ならびに検出された欠陥を顕在化させるテスト・ケースの回帰バケットを生成するための、デバイス、システム、方法、コンピュータ可読媒体、技術、および方法論に関する。本発明の例示的実施形態では、検出および限局された欠陥が、テスト対象システム（ＳＵＴ）において生じる。ＳＵＴは、ハードウェア・システムまたはソフトウェア・システムであってもよい。さらに、本発明の例示的実施形態では、欠陥検出および限局は、ＳＵＴに対するアーキテクチャ制限を遵守しながら実行され得る。

ＳＵＴの品質を査定するとき、ＳＵＴの「より脆弱な部分」を識別し、それらが存在する理由を理解することが必須である。この文脈における「より脆弱な部分」は、ＳＵＴに関連付けられた１つまたは複数のパラメータが変化するときにより失敗を起こし易い、ＳＵＴの部分であり得る。例えば、失敗を引き起こす「隠れ属性」が、ＳＵＴの脆弱部分と考えられ得る。ＳＵＴに関連付けられたパラメータは、ＳＵＴの設定可能な値、例えば、メモリの量、プロセッサの数、またはＳＵＴを形成する任意の他のそのようなハードウェア／ソフトウェア、およびＳＵＴのハードウェアまたはソフトウェアあるいはその両方に関連付けられた任意の設定を含み得る。加えて、ＳＵＴの成功／失敗、またはＳＵＴの１つもしくは複数のテスト・ケースの成功／失敗に影響を及ぼし得るＳＵＴのパラメータは、温度、湿度、電力、併せて実行されているソフトウェア・アプリケーションの組み合わせ、ＳＵＴによって併せて実行されているジョブの数／種類、およびＳＵＴのインスタンスによって変化し得る任意の他のそのような動的条件などの、ＳＵＴに関連付けられる動作条件を含み得る。

ＳＵＴのより脆弱な部分を識別する既存技術は、範囲が狭く、失敗またはエラーを引き起こすメトリックが十分述べられていない。ゆえに、メトリックは、１つまたは複数のそのような失敗の原因を説明するのに十分ではない。所与のテスト・ケースの成功率の計算のように、いくつかのそのような既存技術は、ＳＵＴでの根本的な問題を早期に警告する標識を提供し得る。しかしながら、根本的な問題の識別には、人手による介入、および当技術分野における深いスキルが必要である。

例えば、テスト・ケースの失敗は、バグなどのＳＵＴ自体の実装におけるエラーのせいである場合がある。代替的に、テスト・ケースの失敗は、間違ったユーザ入力のせいである場合がある。代替的に、テスト・ケースの失敗は、ＳＵＴを予期せぬ方式で動作させる、動作条件によって引き起こされる場合がある。さらに、テスト・ケースの失敗は、テスト・ケース内のテストされていない（ゆえに、調整されていない）属性、または値のせいである場合がある。加えて、テスト・ケースの失敗は、ある構成を有する第１のＳＵＴにおいて発生しているが、実質的に同一の構成を有する第２のＳＵＴにおいては発生していない場合がある。

ＳＵＴをテストすると、いくつかのエラーは、特定の環境またはタイミング状況の要件に起因して、一貫して表面化しないことが観測される。例えば、ソフトウェアＳＵＴの場合、状況は、ソフトウェアが実行されているコンピュータ・システムの１つまたは複数のパラメータを含み得る。例えば、パラメータは、コンピュータ・システムの設定、コンピュータ・システム上で実行されている他のソフトウェア、コンピュータ・システムのハードウェア構成などを含み得る。同様に、ハードウェアＳＵＴの場合、ハードウェアＳＵＴがその一部であるシステムの構成が、環境条件に影響を及ぼし得る。言い換えると、ＳＵＴにおける特定のエラーは、システム状態の結果であり、ＳＵＴ自体の品質ではない場合がある。いくつかのエラーは、「ソフト失敗」と呼ばれることがある。本明細書で「隠れ変数」と呼ばれる、ソフト失敗につながり得るそのような条件を識別することが、技術的課題である。追加的に、ソフト失敗を識別すること、即ち、エラーがソフト失敗であると判断することも、技術的課題であり得る。

ＳＵＴにおける隠れ変数がテストの結果に大きな影響を及ぼすとき、この困難度が特に悪化する。隠れ変数は、制御されていない因子である場合があり、場合によっては、テスト・ケース実行時に制御できないことがある。例えば、テスト・ケース自体によって構成されないがテスト・ケースを断続的に失敗させることがある、温度、湿度、ジョブの組み合わせ、利用可能なメモリなどのＳＵＴの動作条件のいずれかが、隠れ変数と考えられ得る。隠れ変数は、それらがＳＵＴの特定範囲外であるために、所与のテスト・インフラストラクチャに対して常に発見可能であるとは限らない。例えば、ストレス・テストは、様々なリソース（例えば、メモリ、計算サイクルなど）が制約された構成にＳＵＴを追い込んで、それによって、一貫して再現することが、不可能でないにしても困難な、ＳＵＴにおいて予測不能なエラーまたは失敗を引き起こし得る。これは、ストレス・テストが検証する特定の機能または特徴が安定しているとしても、ストレス・テストが依存するリソースによって、ＳＵＴが不適当に実行し、または失敗し得ることを意味する。

よって、技術的課題は、１つまたは複数の隠れ変数が所与のテスト・ケースの結果に一貫して影響を及ぼすと判断し、そのような隠れ変数をさらに識別するための、テスト・インフラストラクチャに存在する。さらに、リソースを調整し得るか、または新たなテスト・インフラストラクチャがそれに従って開発され得るように、テスト・インフラストラクチャ自体以上の因子に起因してテスト・ケースが失敗しているときに、そのような隠れ変数を識別するために、技術的課題が存在する。

本発明の実施形態は、コンピュータ・システムのためのテスト・インフラストラクチャでのそのような技術的課題に対処する。テスト・インフラストラクチャ自体が、メモリ・デバイス、処理ユニット、および１つまたは複数のコンピュータ実行可能命令を含むコンピュータ・システムを含むことに留意されたい。したがって、本発明の実施形態は、コンピューティング技術、テスト・インフラストラクチャ、およびＳＵＴに対する改善を容易にする。本発明の１つまたは複数の実施形態では、本発明の実施形態は、ハイティング代数などの疑似ブール代数を利用することによって、テスト・ベクトルの成功率を量子化しつつ、テスト・ケースの結果に一貫して影響を及ぼす隠れ変数をカプセル化し得る。例えば、テスト・ベクトル＜アンドリュー，青，３０＞について、これは、この場合、割り当てられた値の組み合わせを有する３つの属性＜名前，色，年齢＞を有し、成功率は、テスト・ケースがこの特定の値の組み合わせを用いる間に成功する頻度を示す。「属性値ペア」は、テスト・ケースによってテストされている特定の属性に割り当てられる、特定の値を表す。属性は、テスト中に複数の値を通して循環される。さらに、テストされる複数のそのような属性が存在し得る。属性値ペアの成功率の量子化は、品質保証エンジニアなどのユーザが、リソースを調整し得るか、または新たなテスト・インフラストラクチャがそれに従って開発され得るように、テスト・インフラストラクチャ自体以上の因子に起因してテスト・ケースが失敗しているときを確実に識別することを可能にする。この強化された成功メトリックは、ＳＵＴの全体的な安定性を改善するテストの取り組みの効率および確実性を改善するために使用され得る。したがって、本発明の実施形態は、コンピューティング技術、特にＳＵＴをテストするために使用されるテスト・インフラストラクチャにおける技術的課題に対する改善、実用化、および技術的解決策を提供する。

追加的に、ＳＵＴをテストするためのカバレッジ・ツールは、ＳＵＴがテスト中にどれだけうまく動作しているかの尺度を提供し、それによりＳＵＴが高品質であるというあるレベルの保証が得られる。ステートメント・カバレッジ、ライン・カバレッジ、条件カバレッジ、パス・カバレッジ、メソッド・カバレッジなどの、当技術分野において既知のいくつかの種類のカバレッジが存在する。１つのさらなるカバレッジ方法は、機能カバレッジである。機能カバレッジは、所定の機能的挙動を検査したテストの量、部分、または類似のメトリックを測定するように設計される。機能カバレッジが測定されると、品質保証（ＱＡ）要員は、テストされていない挙動を検査するための追加テストを設計し得る。

しかしながら、テスト・インフラストラクチャは、非常にコストがかかる場合があり、製品、テスト、および環境を絶え間なく最適化しなければ、テスト・サイクル毎のコストは増加する。多くのテストが追加されるにつれて、より多くのテスト・スイートが動作し、サポート・サービスの複雑性が、各テスト・サイクルのコストと共に増加する。テスト環境、テスト依存関係、およびテスト・スイートは、出荷されている製品（即ちＳＵＴ）と同一の厳密さで管理される必要がある。したがって、テスト・インフラストラクチャを管理することが技術的課題であり、同様に、テスト・インフラストラクチャの効率的な縮小が技術的課題である。テスト・インフラストラクチャの縮小は、ＳＵＴのテスト品質の低下を意味しないことに留意されたい。むしろ、技術的課題は、テスト品質がテスト・インフラストラクチャの縮小と共に改善されるべきであるということである。

本発明の実施形態は、そのような技術的課題に対処する。本発明の１つまたは複数の実施形態によれば、ＳＵＴのためのテスト・ケースの縮小セットが、システム上で実行される。システムはＳＵＴとは異なり、ＳＵＴは、システムを用いて実行されていることに留意されたい。テスト・ケースの縮小セットは、組み合わせテスト設計（ＣＴＤ）を用いて生成され得る。エラーは、その縮小セットから失敗するテストのサブセットに基づいて識別され得る。さらに、本発明の１つまたは複数の実施形態によれば、逆ＣＴＤが、システムにおける欠陥を限局するために使用される。

本発明の１つまたは複数の実施形態によれば、ＣＴＤは、ペアワイズ・インタラクション、ｎタプル・インタラクション、またはその他などのインタラクション要件に関して行われる。テスト計画は、インタラクション要件が満たされることを保証する十分なカバレッジ・タスクを提供し得る。いくつかの例示的実施形態では、テスト計画は、機能カバレッジ・モデルを用いたテスト空間のモデル化に基づく。テスト空間は、入力、シナリオ、構成、アプリケーションの内部状態、またはテストされる必要があり得る任意の他の態様を表し得る。機能カバレッジ・モデルは、機能属性のセットを含み得る。本発明の他の実施形態では、カバレッジ・モデルは、ステートメント・カバレッジ、ライン・カバレッジ、条件カバレッジ、パス・カバレッジ、メソッド・カバレッジなどの、当技術分野において既知のいくつかの種類のカバレッジから１つを含み得る。カバレッジの種類は、本明細書に記載されるテスト・インフラストラクチャ技術の縮小に影響を及ぼさない。

さらに、テスト計画に関して、テスト空間は、ＳＵＴ上で実行され得る潜在テストを定義し得る。テストは、カバレッジ・タスクとは対照的に、１つだけの潜在テストに関連付けられ得る。本発明のいくつかの例示的実施形態では、いくつかの異なるテストが、同一の潜在テストを保持し得る。

本発明のいくつかの例示的実施形態では、ＣＴＤの手法に対する動機付けは、大抵のエラーが少数の機能属性間のインタラクションに依存するということである。ＣＴＤアルゴリズムは、スケーラビリティの問題にも対処し得る。ＣＴＤアルゴリズムは、組み合わせ空間が大きすぎて明示的に表すことができないと仮定する場合があり、それらは、様々な技術を用いて、全ての可能な組み合わせを明示的に列挙することなく最適化されたテスト計画を生成しようと試みる。そのようなアルゴリズムの例が、直交配列または被覆配列問題への縮小であり得る。それらの技術は、値の組み合わせに与える制限の種類、または要求されるインタラクション・レベルの種類において制限され、モデル変数の数が増加するにつれてスケーラビリティの問題にやはりぶつかる。

本発明の１つまたは複数の実施形態では、ＳＵＴへの入力は、属性値ペアの集合としてモデル化される。より具体的には、ＳＵＴへの入力は、属性の集合としモデル化されてもよく、そのそれぞれが、１つまたは複数の対応する属性値をとり得る。本発明の１つまたは複数の実施形態では、属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間全体が、テスト空間全体の完全ｎワイズ・カバレッジを提供するテスト・ベクトルのより小さなセットに縮小され得る。例えば、４つの異なる属性Ａ、Ｂ、Ｃ、およびＤがモデル化されると仮定される場合、かつ属性Ａが４つの別個の値をとることができ、属性Ｂが３つの別個の値をとることができ、属性Ｃが３つの別個の値をとることができ、属性Ｄが２つの別個の値をとることができるとさらに仮定される場合、属性値ペアの可能な組み合わせの総数は、４×３×３×２＝７２となる。したがって、この例示的な例では、カルテシアン積空間全体が、属性値ペアの７２の異なる組み合わせを含む。前述した通り、属性値ペアのこれらの７２の異なる組み合わせは、カルテシアン積空間の完全ｎワイズ・カバレッジを依然として提供する組み合わせのより小さなセットに縮小され得る。例えば、上記で導入された同じ例を参照すると、完全ペアワイズ・カバレッジが求められる場合、７２の異なる組み合わせが、属性値のあらゆる可能なペアワイズ・インタラクションを一緒に含む、１２の別個の組み合わせに減少され得る。ｎワイズ・カバレッジを提供するために必要な、減少された数の組み合わせは、ｎが増加するにつれて対数的に増加し得る。

本発明の例示的実施形態では、属性値ペアの全ての組み合わせを含むカルテシアン積空間全体が、所望のｎについて完全ｎワイズ・カバレッジを提供するＣＴＤテスト・ベクトルのより小さなセットに縮小される。複雑なハードウェアまたはソフトウェア・システムにおいては、属性の総数および対応する候補属性値が極めて大きい場合があり、その場合、カルテシアン積空間全体を作り上げる属性値の可能な組み合わせの総数は、天文学的に大きくなることがあり、それによって、全ての可能な組み合わせをテストすることは事実上実行不可能となる。カルテシアン積空間全体を、完全ｎワイズ・カバレッジをやはり提供する大幅に小さな数のＣＴＤテスト・ベクトルに縮小することによって、テスト空間における全ての可能な組み合わせを直接テストしなくても、任意のｎワイズ（またはｍ＜ｎの場合にｍワイズ）欠陥が検出されることが可能となる。

本発明の例示的実施形態において、縮小を実行し、完全ｎワイズ・カバレッジを提供するＣＴＤベクトルの縮小セットを識別するために、二分決定図などが使用され得る。本発明の１つまたは複数の実施形態では、生成される各ＣＴＤテスト・ベクトルは、属性値の一意な組み合わせを含み、ＣＴＤテスト・ベクトルのセットは、属性値の全ての可能なｎワイズ・インタラクションを一緒に含む。特に、各ＣＴＤベクトルは、モデル化される属性の数に対応する次元を有し得る。その場合、ＣＴＤベクトルの各成分は、対応する属性のそれぞれの属性値である。しかしながら、生成されるＣＴＤベクトルのセットは、一意ではない場合がある。即ち、ＣＴＤベクトルの複数の異なるセットが存在することがあり、そのそれぞれが完全ｎワイズ・カバレッジを提供する。本発明の１つまたは複数の実施形態では、ＣＴＤベクトルが、完全ｎワイズ・カバレッジを依然として確保しながら、ランダムに選択され得る。他の１つまたは複数の実施形態では、ＣＴＤベクトルの初期セットは、例えば、ＣＴＤベクトルのセットの中の特定の属性値の表現を増加または減少させるなど考慮して特定の基準で選択され得る。

本発明の例示的実施形態では、ＣＴＤテスト・ベクトルの初期セットが一旦生成されると、それらは、テスト・ケースの対応するセットを生成するために使用される。例えば、ＣＴＤテスト・ベクトルのセットは、各ＣＴＤベクトルのためのそれぞれの対応するテスト・ケースを生成するように構成されるテスト・ケース生成ツールへの入力として、提供され得る。各テスト・ケースは、対応するＣＴＤベクトルに含まれる属性値の特定の組み合わせ間のインタラクションをテストするように設計され得る。

本発明の例示的実施形態では、次いで、テスト・ケースが実行される。各テスト・ケースの実行は、テスト・ケースに関連付けられた属性値の組み合わせがｎワイズ（もしくはｍ＜ｎの場合にｍワイズ）エラーを含まないことを示す成功の実行結果、またはテスト・ケースに関連付けられた属性値の組み合わせがｎワイズ（もしくはｍ＜ｎの場合にｍワイズ）エラーを含むことを示す失敗の実行結果のいずれかの結果をもたらす。本発明の１つまたは複数の実施形態では、特定の失敗テスト・ケースが次いで選択され、逆組み合わせ論が失敗テスト・ケースに適用されてバグを顕在化させることが可能なテスト・ケースの新たなセットを作り出す。本発明の例示的実施形態では、選択した失敗テスト・ケースへの逆組み合わせ論の適用は、属性毎にそれぞれの新たなテスト・ケースを生成することを含む。したがって、生成される新たなテスト・ケースの数は、属性の数に等しくなり得る。本発明の例示的実施形態では、それぞれの新たなテスト・ケースにおいて、選択した失敗テスト・ケース内の対応する属性の属性値が、どの失敗テスト・ケースにも存在しない属性についての属性値に変更され、他の各属性についてのそれぞれの属性値は、選択した失敗テスト・ケースに存在するものから変更されない。

成功の実行結果を生じるそれらの新たなテスト・ケースは、次いで、ｎワイズ（またはｍ＜ｎの場合にｍワイズ）エラーを検出および限局するために査定され得る。特に、エラーを引き起こす特定の属性値ペアは、実行が成功する新たなテスト・ケースに基づいて識別され得る。テスト・ケースの回帰バケットは、次いで、属性値ペアのエラーを生じさせる組み合わせに基づいて生成され得る。より具体的には、エラーを引き起こすと判断される属性値を含む属性値の全ての可能な組み合わせが判断されてもよく、これらの組み合わせをテストするための対応するテスト・ケースの回帰バケットが、例えば、手動テスタにより使用するために出力され得る。特に、本発明の１つまたは複数の実施形態では、回帰バケットに含まれる全てのテスト・ケースは、バグが修正されるまで実行時に失敗し、バグ修正後は、全ての回帰バケット・テスト・ケースが合格するはずである（即ち、成功の実行結果を生じる）。

本発明の例示的実施形態では、アーキテクチャ制限が、ＳＵＴに適用され得る。アーキテクチャ制限は、ＳＵＴへの入力に対する多様な制限のうちのいずれかを含み得る。例えば、例としての制限は、所与の属性が特定の属性値を有する場合に、１つまたは複数の他の属性が、ある属性値を有することから除外されることであってもよい。別の例としてのアーキテクチャ制限は、所与の属性が特定の属性値を有する場合に、１つまたは複数の他の属性が、ある属性値を有しなければならないということであってもよい。さらに別の例としてのアーキテクチャ制限は、特定の属性が特定の属性値を有する場合にのみ、新たな属性が導入されることであってもよい。アーキテクチャ制限の上記の例は、単なる例示であり、網羅的ではないことを理解されたい。

本発明の例示的実施形態では、所望の完全ｎワイズ・カバレッジを提供するＣＴＤベクトルの初期セットへのカルテシアン積空間全体の縮小を実行する前に、アーキテクチャ制限が考慮される。即ち、本発明の例示的実施形態では、任意のアーキテクチャ制限に違反する属性値の特定の組み合わせは、カルテシアン積空間から最初に除外され、次いで、所望の完全ｎワイズ・カバレッジを提供するＣＴＤベクトルのセットへの縮小が実行される。このようにして、アーキテクチャ制限に違反する属性値の組み合わせがＣＴＤベクトルの初期セットに含まれないことが保証され得る。さらに、本発明の例示的実施形態では、初期ＣＴＤベクトルに対応する選択したテスト・ケースが失敗し、かつｎワイズ・エラーを検出および限局するように設計された新たなテスト・ケースのセットを取得するための拡大のために選択されるとき、その拡大は、いかなるアーキテクチャ制限も考慮に入れることなく最初に実行され得る。次いで、アーキテクチャ制限に違反する任意の新たなテスト・ケースが除外され得る。このようにして、拡大は、失敗テスト・ケースの近傍におけるテスト空間の可能な限り多くのカバレッジを提供することが保証され得る。加えて、本発明の例示的実施形態では、失敗テスト・ケースの回帰バケットが、アーキテクチャ制限に関係なく最初に生成されてもよく、次いで、アーキテクチャ制限に違反する任意のテスト・ケースが、回帰バケットから除外されてもよい。即ち、ｎワイズ・エラーまたはより低い次数のエラーを引き起こす属性値の特定の組み合わせを含む、カルテシアン積テスト空間全体における全ての可能な組み合わせに対応するテスト・ケースが、最初に生成され、次いで制限に違反するいかなるテスト・ケースも除外するように縮小され得る。代替的に、回帰バケットに含まれるテスト・ケースは、ＣＴＤベクトルの初期セットが選択される、縮小されたカルテシアン積空間から選択されてもよく、その場合、回帰バケットは、エラーを引き起こす属性値のサブセットを含み、かついかなるアーキテクチャ制限にも違反しない、それらの属性値の組み合わせのみを含むように生成される。

本発明の１つまたは複数の実施形態は、コンピュータ技術に様々な改善をもたらす技術的効果を生じる様々な技術的特徴を含む。例えば、本発明の例示的実施形態は、選択した失敗テスト・ケースからテスト・ケースのセットを拡大するための、逆組み合わせ論の技術的特徴を含む。この技術的特徴は、ｎワイズ欠陥またはより低い次数の欠陥が、拡大の単一の繰り返しの中で検出および限局されることを可能にする。この技術的効果は、デバッグおよび欠陥検出コンピュータ技術に対する改善を表す。それは、欠陥の検出および限局を容易にするように特に設計された方式で、選択した失敗テスト・ケースの周囲の追加テスト・ケースの生成を自動化するからである。よって、本発明の１つまたは複数の実施形態による新たなテスト・ケースの自動生成は、手動によるテスト・ケース生成よりも効率的に欠陥を顕在化させることおよび基本的に異なる方法論を用いることを可能にする。本発明の例示的実施形態は、ｎワイズ欠陥を引き起こす属性値の特定のサブセットを含む属性値の全ての可能な組み合わせをテストする、テスト・ケースの回帰バケットを生成する技術的特徴も含む。よって、回帰バケットは、欠陥の補正前は全て失敗し、かつ欠陥の補正後に全て合格するテスト・ケースのみを含む。よって、本発明の１つまたは複数の実施形態による失敗テスト・ケースの回帰バケットの自動生成は、そのそれぞれが失敗することが確実である、テスト・ケースのセットを有するテスタまたは自動テスト・アルゴリズムを提供することによってコンピュータ技術に対する改善をもたらし、それによって、テスタまたは自動テスト・アルゴリズムが、テスト・ケースの回帰バケットを使用して、デバッグ実行後全てのテスト・ケースが最終的に合格するときに、欠陥が補正されていることを検証し得る。

ＳＵＴをテストする取り組みのライフサイクルの間、相当な時間およびリソースが、テスト・ケースを実行してＳＵＴを検証するために一貫したテスト・システムを提供する、持続可能な、信頼できるテスト・ケースおよびインフラストラクチャを構築することに費やされる。テスト・システム構築の最終結果は、特に、メンテナンスおよび更新が経時的に適用されるように、ＳＵＴの寿命全体を通してＳＵＴを連続的に検証するための確実で効率的な方法である。十分なテスト・カバレッジを確実にする一般的な方法は、ＣＴＤの使用を通してテスト・カバレッジが十分であることを保証することである。

このパラダイムを伴う技術的課題は、テスト・モデル設計者が、テストされるべきものから属性値を見落とすこと、またはテストされるべき属性の値に対して不十分な粒度を定義することのいずれかにある。このような場合、テスト・システムによる使用のために生成されるテスト・モデルは、不完全である場合があり、これがＳＵＴの不完全なテストにつながる。別の技術的課題は、テストを生成するために使用される特定のアルゴリズムに起因した、経時的な任意の１つのテスト属性変数値の偏った使用である。この場合も、属性値のいくつかが実行されない結果となり、さらにＳＵＴのテストが不完全なものとなる。欠落している属性値に加えて、前述した通り、技術的課題は、隠れ変数が、ＳＵＴで発生している場合がある失敗の根本原因をテストまたは識別できない、あるいはその両方のテスト・ケースを引き起こすことも含む。

「隠れ変数」が、ＳＵＴの温度などの、ＳＵＴと同時稼働する他のアプリケーション、ジョブ、またはサービスなどのパラメータを制御することが困難であることに起因して、断続的に失敗し得ることに留意されたい。「隠れ属性」は、より良好なテスト・ベクトルを生成するために、モデルに含まれるべき属性である。「隠れ属性値」は、より良好なテスト・ベクトルを生成するためにモデル内の属性に含まれるべきであるが、テスト・モデル生成時に欠落した／見落とされた値、またはユーザがテスト・モデル設計時に意識しなかった値である。一方、「隠れ値」は、１つまたは複数のテスト・ケースの結果に影響を及ぼす、環境因子／外的因子である。

本発明の実施形態は、ＣＴＤを用いて、ＳＵＴをテストするためのテスト・ケースを自動的に生成および選択すること、ならびに１つまたは複数のテスト・ケースの失敗を引き起こす１つまたは複数の隠れ変数を検出するためにハイティング代数、クリプキ代数、または任意の他の直観主義論理などの疑似ブール代数の使用をさらに容易にすることによって、そのような技術的課題に対処する。本発明の実施形態は、検出された隠れ変数を用いて、テスト・ケースの失敗を引き起こし得るエラーを検出するためにさらに診断する必要があり得る、ＳＵＴの１つまたは複数の部分を判断することをさらに容易にする。

本発明の１つまたは複数の実施形態では、テストされるべき欠落した属性／隠れ属性を認識するために、属性値ペア毎の経時的な成功率が、疑似ブール・アルゴリズムを用いて計算される。成功率の履歴は、そのとき、不規則に分散された視覚的表現を用いて視覚的に表示される。視覚的表現は、ＳＵＴをテストするために使用されたモデルのテスト・ベクトル属性値の不均一テーブルまたはヒートマップとも呼ばれ得る。代替的に、または加えて、履歴データに基づいて、所定の閾値を満たしていない成功率を有する値を含む、モデル内の属性が識別される。識別された属性は、少なくともその属性をテストするために使用された値のセットにおける深さ不足を識別し、明らかにするために用いられる。追加の値を属性および任意の他の関連属性に加えることによって、属性の成功率が、再び経時的にモニタリングされる。成功率閾値が満たされる場合、隠れ値または隠れ属性が、追加された値によって識別されていると見なされ得る。隠れ値は、その後、テスト・ケースのさらなるセットにおいて使用され得る。

ここで図１を参照すると、図１は、本発明の実施形態による、コンピュータ化環境の概略図を示す。コンピュータ化環境１００は、１つまたは複数のコンピュータ化ツールを含み得る。図はブロック図の１つの可能な例であること、およびいくつかのコンポーネントは明確化のために図示されないことがあることに留意されたい。

本発明の１つまたは複数の実施形態では、開発者、ＱＡスタッフ・メンバ、テスタ、設計者、検証エンジニアなどのユーザ１１０が、コンピュータ化環境１００と対話し得る。ユーザ１１０は、端末、ディスプレイ、キーボード、入力デバイスなどの、マンマシン・インターフェース（ＭＭＩ）１１２を利用し得る。

本発明のいくつかの例示的実施形態では、カバレッジ・モデル定義ツール１０２は、機能カバレッジ・モデルなどのテスト・カバレッジ・モデルを定義するために利用され得る。本発明のいくつかの例示的実施形態では、ユーザ１１０は、テストされる属性、例えば、機能カバレッジがテストされている場合は機能属性を定義し得る。本発明のいくつかの例示的実施形態では、類似のツールが、テスト空間を定義するために利用され得る。いくつかの例示的実施形態では、カバレッジ・モデルは、テスト・モデルとして利用されるように適合され得る。

本発明のいくつかの例示的実施形態では、テスト実行エンジン１０８は、ＳＵＴをテストするために利用され得る。ＳＵＴは、ハードウェア、ファームウェア、ソフトウェア、それらの組み合わせ、または任意の他の種類のコンピュータ化デバイスであってもよいことに留意されたい。テスト実行エンジン１０８は、シミュレーションベース検証ツール、テスト生成プラットフォームなどであってもよい。テスト実行エンジン１０８は、テスト計画ツール１０６に動作可能に連結され、テスト計画に従ってテストを実行するように構成され得る。いくつかの例示的実施形態では、テスト計画ツール１０６は、テスト実行エンジン１０８が実行するためのテストを提供し得る。動的検証は、ＳＵＴのテストよりも幅広い概念であり、テスト計画、カバレッジ分析などをさらに含むことに留意されたい。テスト実行エンジン１０８は、動的検証中に実行され得る動作範囲全体の態様１つだけを提供し、「動的検証」という用語をより狭く解釈するために使用されるべきではない。

本発明のいくつかの例示的実施態様では、カバレッジ分析ツール１０４は、テスト実行エンジン１０８によって実行される動的検証に基づいて、ＳＵＴのためのテスト空間のカバレッジを測定するように構成される。例えば、カバレッジ分析ツール１０４は、機能カバレッジ分析ツールであってもよい。カバレッジ分析ツール１０４は、テスト実行エンジン１０８によって実行される動的検証の間カバーされたカバレッジ・タスクを示す、カバレッジ・テスト空間または定義されたテスト計画の一部などのカバレッジ測定値を提供する。ユーザ１１０は、カバレッジ測定値またはカバーされたタスクのリストあるいはその両方をレビューし得る。

本発明のいくつかの例示的実施形態では、テスト計画ツール１０６は、カバーされるテスト計画を定義し得る。本発明のいくつかの例示的実施形態では、テスト計画は、カバーされるカバレッジ・タスクのセットであってもよい。本発明のいくつかの例示的実施形態では、テスト計画ツール１０６は、ＳＵＴの特定態様をカバーするように知られ／推定されるテストを含むデータストアに記憶されるテスト・ベンチマークなどに基づいて、テスト計画をカバーすると見られるテストを提供し得る。別の例として、テスト計画ツール１０６は、カバレッジ・タスクをカバーするようなテストを生成するように構成される。ユーザ１１０は、テスト計画、選択したテストなどをレビューし得る。本発明のいくつかの例示的実施形態では、ユーザ１１０は、テスト計画ツール１０６のためのパラメータを提供して、所望のインタラクション・レベルなどのテスト計画の目的を判断する際に使用し得る。本発明の実施形態は、生成されたテストにおけるいかなる冗長性の除去も可能にする。

図１の図示は、カバレッジ・モデル定義ツール１０２、カバレッジ分析ツール１０４、テスト計画ツール１０６、およびテスト実行エンジン１０８を含む特定のコンポーネントを用いて記載されているが、本発明の実施形態は、これらのコンポーネントまたはシステム構成に限定されず、より少ないまたは追加のコンポーネントを採用した他のシステム構成を用いて実施され得る。

図２は、本発明の実施形態による、テスト・インフラストラクチャを提供するモジュールを表すブロック図である。より具体的には、インフラストラクチャは、テスト生成器２０８を含む。テスト生成器２０８は、テスト・ケース２０２のリポジトリなどのテスト・インフラストラクチャにアクセスし、テスト・ケース２０２のリポジトリは、ＳＵＴ２１４の正当性を検証するために利用可能なテスト・ケースのスイートを記憶する。各テスト・ケースは、ＳＵＴ２１４に適用される入力、および（その正当な動作を示すための）この入力に応答して返されるべき予期される応答を指定する。典型的には、テスト・ケースは、セット（テスト・スイート）、例えばＳＵＴ２１４の異なるコンポーネントについての各テスト・スイートに編成される。

テスト生成器２０８は、ＳＵＴ２１４上のテストの実行毎に実行バケットを作成する。バケットは、（ＸＭＬベースなどの）機械可読言語における所望のテスト・ケースを実行させるために行われる動作を指定する。特に、完全テストの場合、利用可能なテスト・ケースの全てが、ＳＵＴ２１４の各コンポーネント上で実行され、逆に、回帰テストの場合、実行は、選択したテスト・ケースのサブセットに限定される。そのように取得されたバケットは、ファイルに保存され得る。

テスト実行エンジン１０８は、ファイルから読み出されるバケットの実行を制御する。バケット２１２の各テスト・ケースの場合、これは、ＳＵＴ２１４への対応する入力（属性値）の適用を伴う。それに応答して、ＳＵＴ２１４は、対応する出力をテスト実行エンジン１０８に返す。テスト実行エンジン１０８は、その出力を（例えば、ファイルから抽出される）対応する予期される応答と比較することによって、テスト・ケースの結果を判断する。テスト・ケースの結果（即ち、２つの値が合致するときは肯定的で、そうでないときは否定的）は、ログに保存される。例えば、これは、標準テスト・トラッキング・ツール（ＴＴＴ）を用いて実現され得る。テストの（現在の）実行結果が、それらの分析のためのログにおいて利用可能である。

大規模で複雑なＳＵＴ２１４の場合、テスト・ケース・インフラストラクチャ２０２は、大量の二重テスト・アクション／テスト・ケースを含み得る。本発明のある実施形態によれば、これらの課題に対処するために開発された１つの技術は、フィンガープリント・リポジトリ２０６の使用を、テスト・リポジトリ２０２に記憶された複数の回帰テストに対応するフィンガープリントのセットを含む情報のストアと組み合わせる。一実施形態では、フィンガープリントは、フィンガープリント生成器２０４によって生成される。例えば、フィンガープリント・リポジトリ２０６は、テスト・リポジトリ２０２に記憶されたテストの、全てではないがほとんどのフィンガープリントと、本の索引に類似した、テスト・インフラストラクチャ全体を通してテストのコピーが位置する場所への参照と、を含み得る。各フィンガープリントは、対応するテスト・ケースによってカバーされる特定のコード・パスを一意に識別する。このようにして、システムは、冗長かつ場合によっては二重である、フィンガープリント（および対応するテスト）を識別し得る。

本発明の実施形態によれば、テスト生成器２０８によって生成され、テスト実行エンジン１０８によって実行される回帰テストの結果２１６の処理は、それぞれの生成された回帰テストの実行中に通過するコード・パスの判断、およびコード・パスに少なくとも部分的に基づいて実行された回帰テスト・ケース毎のフィンガープリントの生成を含み得る。本発明のいくつかの実施形態では、これらのステップは、フィンガープリント生成器２０４によって実行され得る。ここで、テスト・ケースに関連付けられた「コード・パス」は、テスト・ケースによって実行されるＳＵＴ２１４の部分を指す。

冗長性分析器２１８は、テスト生成器２０８によって生成される全てのテスト・ケースに対応するフィンガープリントをフィンガープリント・リポジトリ２０６に記憶された複数のフィンガープリントと比較する。冗長性分析器２１８は、フィンガープリント・リポジトリ２０６に記憶された１つまたは複数のフィンガープリントと合致するフィンガープリントを有する、テスト生成器２０８によって生成された回帰テスト・ケースのリストを提供する。この情報は、（以下に記述されるように）テスト・リポジトリ２０２から二重テスト・ケースを選択および破棄するために使用される。

図３は、本発明の１つまたは複数の実施形態による、ＣＴＤ技術を用いた欠陥検出および限局、ならびに検出された欠陥を顕在化させる失敗テスト・ケースの回帰バケットの生成を示す、概略ハイブリッド・データ・フロー／ブロック図である。図６は、本発明の１つまたは複数の実施形態による、ＣＴＤ技術を用いてｎワイズ欠陥を検出および限局するため、ならびに検出されたｎワイズ欠陥を顕在化させる失敗テスト・ケースの回帰バケットを生成するための、例示的方法６００のプロセス・フロー図である。図６は、図１～図５と併せて説明される。

本発明の１つまたは複数の実施形態による例示的方法、ならびに方法を実行するための対応するデータ構造（例えば、モジュール、ユニット、および他のそのようなコンポーネント）が、ここで説明される。本明細書に記載された１つまたは複数の方法の各動作が、本明細書に記載されたモジュールなどのうちの１つまたは複数によって実行され得ることに留意されたい。これらのモジュールは、本明細書に記載されたハードウェア、ソフトウェア、またはファームウェア、あるいはそれらの組み合わせの任意の組み合わせで実施され得る。ある１つまたは複数の実施形態では、これらのモジュールのうちの１つまたは複数が、処理回路による実行時に１つまたは複数の動作を実行させるコンピュータ実行可能命令を含むソフトウェア・モジュールまたはファームウェア・モジュールあるいはその両方として少なくとも一部、実施され得る。１つまたは複数の実施形態を実施するように構成されているとして本明細書に記載されるシステムまたはデバイスは、１つまたは複数の処理回路を含んでもよく、そのそれぞれが、１つまたは複数の処理ユニットまたはノードを含み得る。コンピュータ実行可能命令は、処理ユニットによる実行時に、コンピュータ実行可能プログラム・コードに含まれるかまたはコンピュータ実行可能プログラム・コードによって参照される入力データが出力データをもたらすようにアクセスされ処理され得る、コンピュータ実行可能プログラム・コードを含み得る。

本発明の１つまたは複数の実施形態において、図３と併せて図６を参照すると、方法６００のブロック６０２において、ＳＵＴ２１４への入力が属性値ペア３０２の集合としてモデル化される。任意の数の属性が、ＳＵＴ入力をモデル化するために使用されてもよく、各属性は、任意の数の候補属性値をとり得る。ブロック６０４において、１つまたは複数のｎワイズ・カバレッジＣＴＤベクトル生成モジュール３０４のコンピュータ実行可能命令が、属性値ペア３０２の集合に関連付けられたカルテシアン積空間全体のｎワイズ・カバレッジを提供する、ＣＴＤベクトルの初期セット３０６を生成するために実行される。

特に、属性値ペア３０２の全ての可能な組み合わせを含むカルテシアン積空間全体が、テスト空間全体の完全ｎワイズ・カバレッジを提供するＣＴＤテスト・ベクトルのより小さなセット３０６に縮小される。本発明の１つまたは複数の実施形態では、ＣＴＤベクトルのセット３０６によって提供される完全ｎワイズ・カバレッジは、完全ペアワイズ・カバレッジであってもよい。例えば、３つの属性、即ち、図４に示される「名前」属性、「色」属性、および「形状」属性がモデル化されると仮定される場合、かつ「名前」属性が４つの別個の属性（デール、レイチェル、アンドリュー、およびライアン）をとることができ、「色」属性が２つの別個の属性（緑、青）をとることができ、「形状」属性が３つの別個の属性（円、四角、三角）をとることができるとさらに仮定される場合、属性値ペアの可能な組み合わせの総数は、４×３×２＝２４となる。したがって、この例示的な例では、カルテシアン積空間全体が、属性値ペアの２４の異なる組み合わせを含むことになる。

属性値ペアの２４の異なる組み合わせが、カルテシアン積空間の完全ｎワイズ・カバレッジをやはり提供する組み合わせのより小さなセット（即ち、ＣＴＤベクトルのセット３０６）に縮小され得る。例えば、完全ペアワイズ・カバレッジが求められる場合、２４の異なる組み合わせが、属性値の全ての可能なペアワイズ・インタラクションを共に含む１２の別個の組み合わせに縮小され得る。ＣＴＤベクトルの例としてのセット４００が、図４に示される。ＣＴＤベクトルの例としてのセット４００は、属性「名前」、「色」、および「形状」の属性値間の全てのペアワイズ・インタラクションを含む。

縮小を実行し、完全ｎワイズ・カバレッジを提供するＣＴＤベクトルの縮小セット３０６を識別するために、二分決定図などが使用され得る。ＣＴＤベクトルのセット３０６内の各ＣＴＤベクトルは属性値の一意な組み合わせを含むが、ＣＴＤベクトルのセット３０６自体が、一意ではないことがある。即ち、ＣＴＤベクトルの複数の異なるセットが存在してもよく、そのそれぞれが、完全ｎワイズ・カバレッジを提供する。例えば、図４は、記載された例としての属性および属性値についてのＣＴＤベクトルの例としてのセット４００を示しているが、属性値の異なる組み合わせを含むＣＴＤベクトルの代替セットが完全ｎワイズ・カバレッジも独立して提供し得ることを理解されたい。ＣＴＤベクトルの例としてのセット４００が完全ペアワイズ・カバレッジおよび部分的３ワイズ・カバレッジを提供するが、より大きな数のＣＴＤベクトルが、完全３ワイズ・カバレッジを提供するために必要であることを、さらに理解されたい。さらに概して述べると、ｎが増加するにつれて、完全ｎワイズ・カバレッジを提供するために必要なＣＴＤベクトルの数が、ｎと共に対数的に増加する。

図５は、ＣＴＤベクトルのセット３０６に含まれ得る種類の例としてのＣＴＤベクトル５００を示す。例としてのＣＴＤベクトル５００は、複数の属性５０２を含む。前述の通り、属性５０２は、ＳＵＴ２１４への入力をモデル化するために使用され得る。属性５０２は、属性値５０４に関連付けられ得る。特に、各属性５０２は、対応する属性値５０４を有してもよく、属性値５０４は、属性がとることが可能な１つまたは複数の候補属性値のうちの１つであってもよい。

本発明の１つまたは複数の実施形態では、アーキテクチャ制限は、所望の完全ｎワイズ・カバレッジを提供するＣＴＤベクトルの初期セット３０６へのカルテシアン積空間全体の縮小を実行する前に、方法６００において考慮される。即ち、任意のアーキテクチャ制限に違反する属性値の特定の組み合わせは、カルテシアン積空間から最初に除外され、次いで、所望の完全ｎワイズ・カバレッジを提供するＣＴＤベクトルのセット３０６への縮小が実行される。このようにして、アーキテクチャ制限に違反する属性値の組み合わせがＣＴＤベクトルの初期セット３０６に含まれないことが保証され得る。

アーキテクチャ制限は、ＳＵＴ２１４への入力に対する多様な制限のうちのいずれかを含み得る。例えば、例としての制限は、所与の属性が特定の属性値を有する場合に、１つまたは複数の他の属性が、ある属性値を有することから除外されるということであってもよい。別の例としてのアーキテクチャ制限は、所与の属性が特定の属性値を有する場合に、１つまたは複数の他の属性が、ある属性値を有しなければならないということであってもよい。さらに別の例としてのアーキテクチャ制限は、特定の属性が特定の属性値を有する場合およびその場合にのみ、新たな属性が導入されるということであってもよい。アーキテクチャ制限の上記の例は、単なる例示であり、網羅的ではないことを理解されたい。

再び図６を参照すると、方法６００のブロック６０６において、本発明の１つまたは複数の実施形態では、テスト・ケース生成モジュール２０８は、ＣＴＤテスト・ベクトルの初期セット３０６から、テスト・ケース２０２の対応するセットを生成するために実行されてもよく、テスト・ケース２０２の対応するセットは、次いで、テスト・ケース実行モジュール１０８によって実行されて、テスト・ケース毎の実行結果（合格または失敗）がもたらされる。

例えば、ＣＴＤテスト・ベクトルのセット３０６は、ＣＴＤベクトル毎のそれぞれの対応するテスト・ケースを生成するテスト・ケース生成ツール２０８への入力として提供され得る。テスト・ケース２０２のセット内の各テスト・ケースは、ＣＴＤベクトルのセット３０６の対応するＣＴＤベクトルに含まれる属性値の特定の組み合わせ間のインタラクションをテストする。ＣＴＤベクトルのセットおよびそれらの対応するテスト・ケースが、ここでの時点において、交換可能に説明または図示され、あるいはその両方が行われ得ることを理解されたい。例えば、図４に示されるＣＴＤベクトルの例としてのセット４００は、ＣＴＤベクトルのセット４００によって表される属性値の特定の組み合わせをテストする、テスト・ケースの対応するセットとして交換可能に考えられ得る。

方法６００のブロック６０８において、テスト・ケース実行モジュール１０８のコンピュータ実行可能命令が、テスト・ケース２０２のセット内の任意のテスト・ケースが失敗したかどうかを判断するために実行される。本発明の１つまたは複数の実施形態において、各テスト・ケース２０２の実行は、対応するＣＴＤベクトル３０６に含まれる属性値の組み合わせがｎワイズ（もしくはｍ＜ｎの場合にｍワイズ）エラーを含まないことを示す成功の実行結果、または対応するＣＴＤベクトル３０６における属性値の組み合わせがｎワイズ（もしくはｍ＜ｎの場合にｍワイズ）エラーを含むことを示す失敗の実行結果のいずれかの結果をもたらす。

図４に示される例を参照すると、ＣＴＤベクトルの例としてのセット４００に対応するテスト・ケースは、ブロック６０６において実行されて、テスト・ケース毎のそれぞれの実行結果をもたらす。特に、２つのテスト・ケース４０２および４０４は、失敗をもたらすとして図４に例示的に示されている。失敗テスト・ケース４０２は、属性値の以下の組み合わせ、デール、青、三角をテストする。デール、青、三角は、それぞれ名前属性、色属性、および形状属性に対応する。失敗テスト・ケース４０４は、属性値の以下の組み合わせ、デール、青、円をテストする。デール、青、円は、それぞれ名前属性、色属性、および形状属性に対応する。「デール」および「青」は、失敗テスト・ケース４０２に対応するＣＴＤベクトル、および失敗テスト・ケース４０４に対応するＣＴＤベクトルの両方に存在するが、「デール」および「青」がペアワイズ・エラーを生成しているかどうか、「デール」および（「三角」もしくは「円」）がペアワイズ・エラーを生成しているかどうか、または「青」および（「三角」または「円」）がペアワイズ・エラーを生成しているかどうかについては、プロセスのこの段階では不明確である。方法６００の後続動作は、逆組み合わせ論を利用して、ｎワイズ・エラー（図４に示される例の場合のペアワイズ・エラー）を引き起こしている属性値の特定の組み合わせを検出および限局するために、選択した失敗テスト・ケースの周りのテスト空間を拡大し得る。

ブロック６０８における否定的な判断に応答して、テスト・ケース２０２の初期セットのいずれも失敗しなかったため、方法６００は終了し得る。ＣＴＤベクトルの初期セット３０６（それに基づいてテスト・ケース２０２のセットが生成される）は、完全ｎワイズ・カバレッジを提供したため、それは、ｎワイズ・エラーまたはより低い次数のエラーが存在しないことが保証され得る。しかしながら、テスト・ケース２０２の初期セット内の全てのテスト・ケースの実行成功は、より高い次数のエラー（ｋ＞ｎの場合にｋワイズ）が存在しないことを保証しない。

一方、ブロック６０８の肯定的判断が、テスト・ケース２０２のセットの実行が１つまたは複数の失敗テスト・ケース３１４をもたらすことを示すことに応答して、方法６００は、逆ＣＴＤテスト・ケース生成モジュール３１６を用いて、特定の失敗テスト・ケース３１４を実行および選択し、選択した失敗テスト・ケース３１４に逆組み合わせ論を適用してｎワイズ・エラーまたはより低い次数のエラーを引き起こしている属性値の組み合わせを検出および限局するために使用されることが可能なテスト・ケース３１８の新たなセットを作り出すことを含む。

本発明の１つまたは複数の実施形態では、選択した失敗テスト・ケース３１４への逆組み合わせ論の適用は、属性毎にそれぞれの新たなテスト・ケース３１８を生成することを含む。したがって、生成される新たなテスト・ケースの数は、属性の数に等しくなり得る。１つまたは複数の実施形態では、それぞれの新たなテスト・ケース３１８において、対応する属性の選択した失敗テスト・ケース３１４における属性値は、いかなる他の失敗テスト・ケースにも存在しない属性についての属性値に変更され、他の各属性についてのそれぞれの属性値は、選択した失敗テスト・ケース３１４に存在するものから変更されない。

図４に示される例を再び参照して、失敗テスト・ケース４０２がブロック６１０において選択されると仮定すると、新たなテスト・ケース４０６の例としてのセットが生成され得る。本発明の１つまたは複数の実施形態では、それぞれの例としての新たなテスト・ケース４０６は、選択した失敗テスト・ケース４０２内の対応する属性の属性値を任意の他の失敗テスト・ケースに存在しない異なる値に変更することによって生成され得る。例えば、ＣＴＤベクトル＜アンドリュー、青、三角＞に対応する第１の新たなテスト・ケースは、失敗テスト・ケース４０２における「名前」属性の属性値を「デール」から「アンドリュー」へ変更する一方、他の属性についての属性値を失敗テスト・ケース４０２と同一に保つことによって取得される。同様に、ＣＴＤベクトル＜デール、緑、三角＞に対応する第２の新たなテスト・ケースは、失敗テスト・ケース４０２における「色」属性の属性値を「青」から「緑」へ変更する一方、他の属性についての属性値を失敗テスト・ケース４０２と同一に保つことによって取得される。最後に、ＣＴＤベクトル＜デール、青、四角＞に対応する第３の新たなテスト・ケースは、失敗テスト・ケース４０２における「形状」属性の属性値を「三角」から「四角」へ変更する一方、他の属性についての属性値を失敗テスト・ケース４０２と同一に保つことによって取得される。

それぞれの新たなテスト・ケース４０６を取得するために変更されるそれぞれの属性値が、選択した失敗テスト・ケース４０２には明らかに存在しないことを理解されたい。さらに、それぞれの変更された属性値は、いかなる他の失敗テスト・ケース（例えば、失敗テスト・ケース４０４）にも存在しない。具体的には、第１の新たなテスト・ケースについて変更された属性値「アンドリュー」は、どの失敗テスト・ケースにも存在せず、第２の新たなテスト・ケースについて変更された属性値「緑」は、どの失敗テスト・ケースにも存在せず、第３の新たなテスト・ケースについて変更された属性値「四角」は、どの失敗テスト・ケースにも存在しない。

選択した失敗テスト・ケース３１４に対して逆組み合わせ論を実行することによって新たなテスト・ケース３１８のセットを生成した後、テスト・ケース実行モジュール１０８は、方法６００のブロック６１２において、新たなテスト・ケース３１８を実行するために使用される。さらに、ブロック６１４において、１つまたは複数のｎワイズ・エラー限局モジュール３２２は、変更すると合格する新たなテスト・ケースをもたらす、選択した失敗テスト・ケース３１４内の属性およびそれらの対応する元の失敗属性値に基づいて、ｎワイズ・エラーまたはより低い次数のエラーを検出および限局する。特に、ｎワイズ・エラー限局モジュール３２２のコンピュータ実行可能命令は、新たなテスト・ケース３１８のセットについての実行結果３２０を評価して成功の実行結果をもたらす新たなテスト・ケースに基づいてｎワイズ・エラーまたはより低い次数のエラーを検出および限局するために、実行される。本明細書で使用される、より低い次数のエラーは、ＣＴＤベクトルのセット３０６による完全ｎワイズ・カバレッジを想定して、ｍ＜ｎの場合のｍワイズ・エラーを指している。

ペアワイズ・エラーの検出および限局を想定する図４に示される例を再び参照すると、新たなテスト・ケース４０６のセットの実行は、ＣＴＤベクトル＜アンドリュー、青、三角＞に対応する第１の新たなテスト・ケースが合格し、ＣＴＤベクトル＜デール、緑、三角＞に対応する第２の新たなテスト・ケースが合格し、ＣＴＤベクトル＜デール、青、四角＞に対応する第３の新たなテスト・ケースが失敗するという結果になる。１つまたは複数の実施形態では、失敗テスト４０２の「三角」から第３の新たなテスト・ケースの「四角」に属性値を変更することによって失敗の結果が続くため、ｎワイズ・エラー限局モジュール３２２は、第３の新たなテスト・ケースについての失敗の実行結果に基づいて、「形状」属性はペアワイズ・エラーの一因ではないと判断する。

一方、ｎワイズ・エラー限局モジュール３２２は、実行が合格した新たなテスト・ケースを取得するために属性値が変更された属性が、ペアワイズ・エラーの一因であると判断し得る。具体的には、本発明の１つまたは複数の実施形態では、ＣＴＤベクトル＜アンドリュー、青、三角＞に対応する第１の新たなテスト・ケースについての成功の実行結果に基づいて、ｎワイズ・エラー限局モジュール３２２は、「名前」属性および元の失敗属性値「デール」がペアワイズ・エラーの一因であると判断する。同様に、１つまたは複数の実施形態では、ＣＴＤベクトル＜デール、緑、三角＞に対応する第２の新たなテスト・ケースについての成功の実行結果に基づいて、ｎワイズ・エラー限局モジュール３２２は、「色」属性および元の失敗属性値「青」もペアワイズ・エラーの一因であると判断する。

よって、新たなテスト・ケース３１８のセットについての実行結果３２０に基づいて、ｎワイズ・エラー限局モジュール３２２は、図４に示される例において、属性値「デール」および「青」をそれぞれ有する属性「名前」および「色」が、ペアワイズ・エラーの原因であると判断し得る。さらに概して述べると、ｎワイズ・エラー限局モジュール３２２は、新たなケース３１８のセットについての実行結果３２０の評価に基づいて、ｎワイズ・エラーまたはより低い次数のエラーを引き起こす特定の属性値ペア、より具体的には、合格する新たなテスト・ケースを取得するために選択した失敗テスト・ケースにおいて変更された元の属性値を判断し得る。

図４に示される例は、完全ペアワイズ・カバレッジを提供するＣＴＤベクトルの初期セット４００を想定し、その場合に、ペアワイズ・エラーまたはより低い次数のエラー（例えば、エラーを引き起こす単一属性値）は、選択した失敗テスト・ケースに逆組み合わせ論を適用するただ１つの合格において検出および限局されて、新たなテスト・ケース３１８のセットを取得し得る。概して、ＣＴＤベクトルの初期セット３０６がｎワイズ・カバレッジを提供する場合、選択した失敗テスト・ケースに対して逆組み合わせ論を適用するただ１つの合格が、ｎワイズ・エラーまたはより低い次数のエラーを明らかにする。ｋ＞ｎの場合のｋワイズ・エラーは、完全ｎワイズ・カバレッジを提供するＣＴＤベクトルの初期セットを用いて検出可能であってもよいが、ＣＴＤベクトルの初期セット３０６は全てのｋワイズ・インタラクションを含まないため、これは保証できない。しかしながら、完全ｎワイズ・カバレッジ（例えば、完全ペアワイズ・カバレッジ）を提供するＣＴＤベクトルの初期セット３０６は、ｋ＞ｎの場合にある程度のｋワイズ・カバレッジ（例えば、３ワイズ・カバレッジ）を提供してもよく、よって、選択される特定のＣＴＤベクトルに基づいて、方法６００は、選択した失敗テスト・ケースに逆組み合わせ論を提供するただ１つの合格において、または複数の合格後に、ｋワイズ・エラーを明らかにし得る。

再び図６を参照すると、方法６００のブロック６１６において、１つまたは複数の回帰バケット生成モジュール３２６のコンピュータ実行可能命令が、元の失敗属性値ペアを含むカルテシアン積空間における全ての可能な組み合わせを含む失敗テスト・ケースの回帰バケット２１２を生成および出力するために実行される。回帰バケット生成モジュール３２６は、本発明の１つまたは複数の実施形態において、属性値ペアのエラー生成サブセット３２４の標識を入力として受信し、検出されたエラーを引き起こしている特定の属性値を含むカルテシアン積空間における全ての可能な組み合わせに対応するテスト・ケースのみを含む、回帰バケット２１２を判断および出力する。

図４の例を再び参照すると、回帰バケット生成モジュール３２６は、ペアワイズ・エラーを引き起こしている属性「名前」および「色」ならびに対応する属性値「デール」および「青」を入力として受信し、「デール」および「青」を含むカルテシアン積空間における全ての属性値組み合わせを判断し、これらの組み合わせの全てに対応するテスト・ケースを回帰バケット２１２に投入する。この例では、回帰バケット２１２は、以下のテスト・ケース、（デール、青、三角）、（デール、青、円）、および（デール、青、四角）を含む。回帰バケット２１２内のテスト・ケースのそれぞれが、属性「名前」および「色」に対して属性値「デール」および「青」をそれぞれ含み、それらは共に、検出されたペアワイズ・エラーの原因となっており、回帰バケット２１２内の各テスト・ケースは、失敗することが保証されている。本発明の１つまたは複数の実施形態では、回帰バケット２１２は、手動によるテスタまたは別の自動デバッグ・アルゴリズムにより使用するために出力され得る。失敗テスト・ケースの回帰バケット２１２は、エラーが修正されたときにのみ、回帰バケット２１２に含まれる全てのテスト・ケースが合格するため、検出されたエラーが補正されているかどうかを検証するために使用され得る。よって、回帰バケット２１２内の任意のテスト・ケースが、エラーを補正するための試みにおいてＳＵＴ２１４に対して行われた修正にも関わらず失敗し続ける場合、これは、エラーが完全に解決されていないことを示す。

図７は、本発明の１つまたは複数の実施形態による、ＳＵＴをテストするときに経時的な属性値ペアの成功率を用いてテスト・モデルの不備を検出する方法のフローチャートを示す。方法７００は、ブロック７０２において、ＳＵＴ２１４をテストするための属性値ペアをモデル化することを含む。モデル化は、方法６００において実行されるものと同様であり、テスト・ケースの全ての組み合わせを生成するために使用され得る属性およびそれらの対応する値の辞書を生成する。

ブロック７０４において、ｎワイズ・カバレッジＣＴＤベクトル生成モジュール３０４は、モデルを用いてｎワイズ・カバレッジでＳＵＴ２１４をテストするために、ＣＴＤベクトル３０６のセットを生成する。本発明の１つまたは複数の実施形態では、ＣＴＤベクトル３０６は、ＳＵＴ２１４についてテストされる属性のカルテシアン積空間全体から生成される。本発明の例としての実施形態では、各ＣＴＤベクトル３０６は、ＳＵＴ２１４のアーキテクチャ制限に違反する属性値の無効な組み合わせを除外する、縮小テスト空間からのみ選択される。例えば、ＣＴＤベクトル生成モジュール３０４は、ＳＵＴ２１４に関連付けられたアーキテクチャ制限を遵守しない組み合わせを識別し除外することによって、属性値ペア３０２の集合に関連付けられたカルテシアン積空間全体を縮小する。

ブロック７０６において、テスト・ケース２０２のセットは、ＣＴＤベクトル３０６の初期セットから生成され、方法６００のブロック６０６と同様に実行される。本発明の１つまたは複数の実施形態では、テスト・ケース２０２を生成および実行することは、１つまたは複数の失敗テスト・ケース２０２に基づく逆組み合わせ理論を使用して、追加テスト・ケース２０２を生成することを含み得る。

ブロック７０８において、各テスト・ケース２０２の結果は、テスト・ケース２０２の少なくとも所定回数の実行、即ち、テスト・ケース２０２の同一セットの反復実行に対して記録される。テスト・ケース２０２の実行回数は、１０回、１００回、１０００回などの所定回数の実行を用いて、または所定の期間、例えば、時間、日、週、月などにわたる実行を用いて、制限され得る。

テスト・ケース実行の結果は、バイナリ、即ち、合格または失敗である。それに応じて、ＳＵＴ２１４の所与の構成について、いかなる構成変更もなく、テスト・ケース２０２の結果が複数の実行にわたって変化しないことが予期され得る。しかしながら、前述の通り、隠れ属性のために、ＳＵＴ２１４の特定の構成を用いたある実行において合格（または失敗）する同一のテスト・ケースが、同一構成を用いた別の実行において失敗（または合格）することがある。したがって、ブロック７１０において、テスト・ケース２０２の結果が、結果を記憶する前に、非バイナリ形式に変換される。

テスト・ケース２０２の結果を非バイナリ形式に変換することは、テスト・ケースによって使用される属性値ペアの成功率を計算することによって実行される。本発明の１つまたは複数の実施形態では、成功率は、成功／失敗テスト・ケースを表すブール結果のベクトルを量子化するために、ハイティング代数などの疑似ブール代数を用いて計算される。本発明の１つまたは複数の実施形態では、テスト・モデルのテスト・ケースによって使用される属性値ペア毎に計算される成功率（即ち、ハイティング値）に基づいて、固有値が計算される。テスト・モデルの計算された成功率の全てが、固有ベクトル内に集合され、固有ベクトルは、次いで固有値を計算するために使用される。各属性値ペアの成功率（または失敗率）（Ｓ_ＡＶ）は、各テスト・ケースの実行に基づいて計算される。よって、属性値ペアの成功率（Ｓ_ＡＶ）は、所与の属性値ペアの経時的な成功率／失敗率を記述する非バイナリ値であり、その場合に、成功率は疑似ブール代数を用いて計算される。属性値ペアを用いたテスト・ケースの複数の実行の結果を含むベクトルは、Ｓ_ＡＶ＝ｆ（ｔ１，ｔ２．．．ｔｎ）と量子化され得る。ここで、Ｓ_ＡＶ＝属性値ペアの成功率、ｔｉ＝テスト・ケースｉの成功／失敗に基づく１／０、ｎ＝テスト・ケース実行回数、およびｆ＝ブール値ｔｉを非バイナリＳ_ＡＶに変換する疑似ブール代数関数である。ここで、ｎは、属性値ペアを使用するテスト・ケースの数、およびテスト・ケースが実行される回数であってもよい。

加えて、テスト・ケース毎の成功率（Ｓ_Ｔ）（または失敗率）もまた、非バイナリ値としてモニタリングおよび記録される。テスト・ケースの成功率（Ｓ_Ｔ）は、経時的なテスト・ケース実行結果のベクトルを量子化するために、疑似ブール代数を用いて計算される。例えば、テスト・ケースの複数の実行の結果を含むベクトルは、Ｓ_Ｔ＝ｇ（ｔ１，ｔ２．．．ｔｎ）と量子化され得る。ここで、Ｓ_Ｔ＝テスト・ケースの成功率、ｔｉ＝テスト・ケースｉの成功／失敗に基づく１／０、ｎ＝テスト・ケース実行回数、およびｇ＝ブール値ｔｉを非バイナリＳ_Ｔに変換する疑似ブール代数関数である。ここで、ｎは、テスト・ケースが実行される回数であってもよい。本発明の１つまたは複数の実施形態では、テスト・モデルのテスト・ベクトル（即ち、テスト・ケース）毎に計算される成功率（即ち、ハイティング値）に基づいて、固有値が計算される。テスト・モデルの計算された成功率の全てが、固有ベクトル内に集合され、固有ベクトルは、次いで固有値を計算するために使用される。

表１および表２は、例としてのテスト・ベクトルを示し、ここで、テストされている属性は、＜名前，色，州，年齢＞を含み、使用される値は、表１に示されるセットからのものである。これは単なる一例であり、本発明の他の実施形態では、テスト・ベクトルは、異なる属性またはテスト・ベクトル内の異なる数の属性あるいはその両方を含み得ると、理解されたい。また、属性の値は、本明細書に示されるものから変化し得る。表１は、属性値ペア毎の成功率を示し、表２は、テスト・ケース毎の成功率を示す。テスト・ケースの成功率は、テスト・ベクトルの成功率と同一であってもよい。表２の最後の列は、疑似ブール代数の固有ベクトルであり、成功率の全てを含む。固有値は、固有ベクトルの数値表現である。

「隠れ変数」が、ＳＵＴ２１４の温度などの、ＳＵＴ２１４と同時稼働する他のアプリケーション、ジョブ、またはサービスなどのソフト失敗に対する困難に起因して、テスト・ケースを断続的に失敗させ得ることに留意されたい。「隠れ属性」は、属性の異なる組み合わせを有するテスト・ベクトルを生成するために、モデルに含まれるべき属性である。さらに、「隠れ属性値」は、モデル内に既にある属性をテストするために含まれるべき値である。即ち、属性の組み合わせが変化せず、ＳＵＴ２１４をテストするために使用される属性値の組み合わせが変更される。「隠れ値」は、１つまたは複数のテスト・ケースの結果に影響を及ぼす、環境因子／外的因子である。隠れ変数は、隠れ値の種類である。

表２の例では、テスト・ベクトル＃１によって表された属性値の組み合わせを用いたテスト・ケースが、５０％の確率で失敗し、テスト・ベクトル＃２および＃５が、テスト・ケースが１００％の確率で合格する結果となる。テスト・ベクトル＃１、＃２、および＃５は、図示されるように、単一の値だけ互いに異なる。

この例のために、属性値＜色，黒＞および＜州，コネチカット＞の組み合わせによってテスト・ケースが失敗すると仮定する。もしそうであれば、疑似ブール代数毎に、テスト・ベクトル＃２および＃５を有するテスト・ケースもまた、成功率５０％で失敗するはずであった（ベクトル＃１と同一）と見なされ得る。しかし、ここではそうでないため、モデルが、即ち、例えば未知の環境条件によって引き起こされるソフト失敗に対する制御を行わない「隠れ変数」が存在するとみなされ得る。さらに、３つの全てのテスト・ベクトル＃１、＃２、および＃５が結果的に５０％の成功率となった場合、追加テスト・ベクトルを生成するために使用されなければならない「隠れ属性」が存在すると見なされ得る。さらにそれでも、１つまたは複数の値を属性の範囲に追加すること、および新たな属性値の経時的な成功率をモニタリングすることによって、１つまたは複数の追加の値を使用することによって成功率閾値が満たされる場合に、「隠れ属性値」が検出され得る。また、隠れ変数が存在し、かつテスト・ケースが実行されると断続的な失敗を引き起こすとき、特定のテスト・ベクトルの成功率は、経時的に変化し得る。

ブロック７１２において、属性値ペアの成功率（Ｓ_ＡＶ）は、カルノー図、ヒートマップ、または属性の傾向を経時的に検出するために分析され得る不均一データ構造の任意の他の形式などの、データ構造に記憶される。各属性が、テストされる異なる数の値を有し得るため、データ構造は不均一である。

図８は、本発明の１つまたは複数の実施形態による、属性値ペアの成功率（Ｓ_ＡＶ）の可視化の例を示す。可視化８００は、ヒートマップ、多角形、または成功率（Ｓ_ＡＶ）の不均一テーブルを可視化する任意の他の表現などの技術を用いて、成功率（Ｓ_ＡＶ）を記憶するために用いられるデータ構造に基づいて、生成され得る。可視化８００は、不均一ヒートマップであり、各正方形８０２の色またはシェーディングがその正方形８０２に対応する属性値ペアの成功率（Ｓ_ＡＶ）を表す。図示される特定の例では、正方形が暗いほど、成功率（Ｓ_ＡＶ）が低く、逆に、正方形が明るいほど、対応する属性値ペアの成功率（Ｓ_ＡＶ）が高い。しかしながら、ヒートマップ８００は、他の実施形態では異なるルールを用いてシェーディングされ得ると理解されたい。代替的に、または加えて、成功率（Ｓ_ＡＶ）は、色以外の、可視化の異なる特性を用いて表現されてもよく、例えばサイズが用いられてもよい。さらに、可視化８００は２Ｄ描写であるが、本発明の他の実施形態では、可視化が、３Ｄなどの異なる次数を使用し得ると理解されたい。

可視化８００を用いて、特定範囲の属性を分析することによって、各属性の有効性が、モデルの属性値における深さ不足を明らかにし得る。例えば、可視化８００における属性「年齢」が、属性値ペア毎に閾値を超える（または下回る）成功率（Ｓ_ＡＶ）を示す場合、属性をテストするために使用される値の範囲が、発達不十分である場合がある。そうでなければ、追加の値を属性に追加することが、少なくとも所定の閾値によって可視化８００（即ち、基礎となる成功率）を変更しない場合、属性は、十分に探索されると見なされる。

ブロック７１４において、成功率は、テスト・モデルまたはデータあるいはその両方の不備を判断するために分析される。不備は、隠れ変数、隠れ属性、または隠れ属性値、あるいはそれらの組み合わせを含み得る。本発明の１つまたは複数の実施形態では、テスト・モデルは、動作され得るテスト・バケットを生成するために使用される。結果を用いて、失敗したテスト・ベクトル毎の逆組み合わせセットが、計算され得る。逆組み合わせ理論は、既知の技術であり、全ての失敗テスト・ベクトルを識別することを容易にする。失敗テスト・ベクトル毎に、逆組み合わせセットが生成される。逆組み合わせセット毎に、ＳＵＴをテストおよび診断して失敗テスト・ケースの原因を判断するために、新たなテスト・バケットが生成される。さらに、本発明の１つまたは複数の実施形態では、逆テスト・ケースが動作され、その結果が、根本原因分析を実行するために用いられる。それによって、元のテスト・モデルにおける失敗のソースを特定する結果となる。

本発明の１つまたは複数の実施形態では、分析は、テスト・ケース２０２の成功率（Ｓ_Ｔ）に基づいて固有値および固有ベクトルを計算することを含む。例えば、Ｓ＝＜Ｓ_Ｔ１，Ｓ_Ｔ２．．．Ｓ_ＴＮ＞は、テスト・ケース２０２の経時的な成功率のベクトルを表す。固有値および固有ベクトルは、ベクトルＳに対して計算される。

本発明の１つまたは複数の実施形態では、固有ベクトルは、線グラフなどの複数の方法で可視化され得る。固有ベクトルおよび固有値は、経時的に、テスト・プロセスの改善および劣化を示し、また、テスト・ケース２０２の実行＃ｎ＋１についての焦点も強調する。本発明の１つまたは複数の実施形態では、テスト・ケースの成功率を表す固有ベクトルは、経時的なテスト・モデル・カバレッジを表す単位ベクトルを生成するために使用され得る。さらに、固有ベクトルおよび固有値は、既存のテスト・ケースに対する変更、新たなテスト・ケースの生成、ＳＵＴ２１４に対する変更、または任意の他の変更による結果の品質の変化をモニタリング／追跡するために使用され得る。したがって、固有値および固有ベクトルは、ＳＵＴ２１４およびテスト環境１００が変化すると、テスト・ケース品質の定量化およびモニタリングを容易にし得る。これは、テスト・インフラストラクチャを維持および強化するための新たなメトリックをユーザに提供する。

本発明の１つまたは複数の実施形態では、成功率（Ｓ_ＡＶ）は、カルノー図、または可視化８００のための任意の他のデータ構造の形式で記憶される。カルノー図の表面極小値および極大値は、それぞれ、現在のモデルによるテストにおける属性値ペアの不備、および堅牢性で逆にカバーされる属性値ペアを識別し得る。本発明の１つまたは複数の実施形態では、テスト環境１００は、より多くのリソースまたは異なるリソースが、ＳＵＴ２１４を適切にテストし、またはストレスを与える必要があり得ることを示し得る。さらに、複数のテスト・ケース実行にわたって得られた複数のそのような可視化８００が、ＳＵＴ２１４を査定するために用いられ得る。例えば、可視化８００は、ＳＵＴ２１４またはテスト・インフラストラクチャ１００あるいはその両方がどのくらい成熟し変化したかを示すために、パターンを経時的に隔離するための可視化８００の１つまたは複数のバージョンと比較され得る。比較のために用いられる基準バージョンは、ＳＵＴ２１４自体を用いて生成される１つまたは複数の可視化８００であってもよい。代替的に、または加えて、基準可視化８００は、ＳＵＴ２１４の異なるインスタンスを用いてオフラインで生成された参照可視化を含み得る。

本発明の１つまたは複数の実施形態では、ＳＵＴ２１４の各リリース・バージョンにおける可視化８００の各セットに対してクラスタリングが実行され、あるクラスタからそれらのピアの移行とは異なる別のクラスタに移行する、個々のマップを識別し得る。例えば、隠れ属性がトリガされると、限局されたホットスポットが移行することがあり、これは、類似属性／テスト範囲を査定して、失敗を引き起こす同一属性が複数のビューの下で表面化するかどうかを判断することに関連する。

さらに、分析は、テスト・ベクトル（例えば、表１内のベクトル＃１）の値の第１の組み合わせの成功率Ｓ_Ｔが、同一のテスト・ベクトル（例えば、表１内のベクトル＃２および＃５）の値の他の組み合わせから逸脱するかどうかを判断することを含む。この条件が満たされる場合、隠れ変数は、第１のテスト・ベクトルを使用するテスト・ケース２０２に関連付けられると見なされ得る。例えば、テスト・ベクトルについての属性値の第１の組み合わせが第１の成功率、例えば５０％を有し、かつ属性値の他の全ての組み合わせが第２の成功率、例えば１００％を有する場合、第１の組み合わせが、ソフト失敗をトリガすると見なされる。本発明の１つまたは複数の実施形態では、ブロック７１６において、テスト・ケース２０２、テスト・ベクトル、およびそのようなソフト失敗をトリガする属性値の組み合わせが、ユーザに通知され得る。

追加的に、特定のテスト・ケースの成功率Ｓ_Ｔが、所定回数のテスト実行（または期間）にわたって所定の閾値、例えば５０％未満である場合、ブロック７１８において、１つまたは複数の値を属性値の範囲に追加すること、および新たな属性値の経時的な成功率Ｓ_Ｔ’をモニタリングすることにより１つまたは複数の追加の値を用いて、成功率閾値Ｓ_Ｔが満たされる場合に、「隠れ属性値」が検出され得る。

代替的に、または加えて、ブロック７１８において、隠れ属性値は、全て所定の閾値未満である、属性に関連付けられた属性値ペアのセットに対応する成功率（Ｓ_ＡＶ）のセットに基づいて検出され得る。属性は、次いで、追加の属性値を用いてより多くのテスト・ベクトルを追加すること、および追加の属性値を用いてテスト・ケースを実行することによって、さらに診断され得る。追加の属性値を用いて実行されたテスト・ケースの成功率Ｓ_ＡＶ’が、所定の閾値を満たす場合、隠れ属性値条件が識別されており、隠れ値が発見されている。それに応じてユーザに通知が行われる。

成功率閾値が満たされない場合、ブロック７２０において、隠れ属性が存在するかどうかの判断に基づいて、ユーザに、隠れ属性が通知され得るかまたはＳＵＴ２１４を診断するように通知され得る。即ち、追加の属性は、特定のテスト・ベクトルでテスト・ケースを失敗させている、コード・パスを実行する必要があり得る。

図９は、本発明の１つまたは複数の実施形態による、隠れ属性が現在のテスト・モデルに存在するかどうかを判断する方法のフローチャートを示す。方法９００は、テスト・ケースの成功率Ｓ_Ｔが所定の閾値、例えば５０％未満であることを検出することに応じて、トリガされる。Ｓ_Ｔ＝０％は、テスト・ケースが一貫して失敗していることを示すため、本明細書の全ての例における成功率Ｓ_Ｔは、明示的に述べられた場合を除いて、０％を超えることに留意されたい。ここで、テスト・ケースが断続的に成功および失敗しており、ゆえに、欠陥がＳＵＴ２１４、テスト・ケース、環境（ソフト失敗）、または任意の他の因子にあるかどうかを判断するという技術的課題がある。

方法９００は、ブロック９０２において、現在のモデル、テスト・ベクトルからの属性値ペア、および断続的に失敗するテスト・ケース２０２に基づいて、逆組み合わせテスト・ケースのセット全体を生成することを含む。逆ＣＴＤの既知の技術が、テスト・ケースのセットを生成するために使用され得る。生成されるテスト・ケースのセットは、断続的に失敗するテスト・ケース２０２と同数のテスト・ケースを有し、テスト・ケースの元のセットからのテスト・ケースＡと逆組み合わせテスト・ケース内の対応するテスト・ケースＡ’との間に１対１対応を有する。

逆組み合わせセットは、１つの属性値が元のテスト・モデルからの別の値と置換される、変化したテスト・ベクトルのセットとして定義される。最小限の変化の場合、ｎ個のテスト・ベクトルが生成され、ここで、ｎは、初期失敗テスト・ベクトル内の属性の数である。例えば、失敗したテスト・ベクトルが＜アンドリュー，黒，ニューヨーク，２０，０＞（表２参照）である場合、最大の逆組み合わせセットは、

この例での最小逆組み合わせセットは、

ブロック９０４において、逆組み合わせテスト・ケースのセットが、少なくとも所定の回数実行される。ブロック９０６において、逆組み合わせテスト・ケースのセットの成功率Ｓ_Ｔ’が、記録および記憶される。逆組み合わせテスト・ケースのセットの成功率Ｓ_Ｔ’は、元のテスト・ケースの成功率と同じ方式で、疑似ブール代数を用いて計算される。

ブロック９０８において、逆組み合わせテスト・ケースの成功率Ｓ_Ｔ’は、断続的に失敗するテスト・ケース、即ち元のテスト・ケースの対応する成功率Ｓ_Ｔと比較される。本発明の１つまたは複数の実施形態では、成功率Ｓ_Ｔ’のベクトルの固有値を成功率Ｓ_Ｔのベクトルの固有値と比較することによって、比較が実行され得る。

逆組み合わせテスト・ケース内の失敗テストの全てが、テスト・ケースの元のセットにおけるものと同じ割合で失敗する場合、ブロック９１０において、テスト・モデルに不具合があると見なされ得る。例えば、２つの固有値が同一である場合、テスト・ケースの２つのセットが、同じ割合で失敗していると見なされる。ブロック９１２において、この場合にテスト・モデルが診断および改訂される必要があることが、ユーザに通知される。

代替的に、ブロック９１４および９１６において、逆組み合わせテスト・ケースのセット内のどのテスト・ケースも失敗しない場合、隠れモデル属性がモデルに追加されるべきであると見なされ、それに応じてユーザに通知が行われる。テスト・ケースの失敗率が異なり、かつ逆組み合わせテスト・ケースのセット内のテスト・ケースの少なくともいくつかが失敗する場合、ブロック９１８において、失敗テスト・ケースの原因を判断するためにＳＵＴ２１４が診断される必要があることが、ユーザに通知される。

図１０は、本発明の１つまたは複数の実施形態による、隠れ属性を駆動するＳＵＴの部分を識別する方法のフローチャートを示す。ここまで説明した通り、疑似ブール代数、固有ベクトル、および不均一テーブル・ヒートマップを用いることによって、モデルが１つまたは複数の属性、即ち隠れ属性を欠落していることを明らかにするテスト・ケースを識別する助けとなり得る。次の技術的課題は、これらの隠れ属性のどれが所与のモデルのためのものであるかを判断することである。本発明の実施形態は、疑似ブール代数、固有ベクトル、および不均一テーブル・ヒートマップを用いて、テスト・ケースの元のセット内のより低い疑似ブール値に対応するパスを駆動する、追加テスト・ケースを識別および生成することによって、これらの技術的課題に対処する。所定の閾値未満の成功率の値を有する属性値ペアを表す、可視化８００のより暗い領域は、モデル内の隠れ属性を明らかにするテスト・ケースを示す。

図１０の方法１０００および図１１の方法１１００などの本発明の実施形態は、ブレークポイントを用いてテスト・ケースの成功および失敗動作のコード・パスを追跡して、それらのテスト・ケースを実行する部分、例えばコード・パスを隔離することを容易にする。ＳＵＴ２１４の１つまたは複数の部分、例えば、コード・パスは、システム構成およびタイミング・ウィンドウに基づいて隠れ属性を識別するためにさらに調査するための領域として識別および強調される。

方法１０００は、ブロック１００２において、所定の閾値未満の成功率（Ｓ_ＡＶ）を有する属性値ペアのセットを識別することを含む。属性値ペアは、可視化８００においてより暗いシェーディングで表されるものであり、可視化８００において、成功率（Ｓ_ＡＶ）は正方形のシェーディングを判断するために使用され、Ｓ_ＡＶが低いほど正方形がより暗くなる。本発明の１つまたは複数の実施形態では、ユーザは、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を用いてさらに調査されるべき可視化８００内の１つまたは複数の正方形を選択する。代替的に、または加えて、ユーザは、閾値より低い（またはより大きい）Ｓ_ＡＶを有する正方形を選択するために閾値Ｓ_ＡＶを提供し得る。

さらに、ブロック１００４において、実行されるテスト・ケース２０２からのテスト・ケースのサブセットが識別され、サブセットからのテスト・ケースは、属性値ペアの識別されたセットから属性値ペアの少なくとも１つを使用する。テスト・ケースのサブセットを識別することは、テスト・ケース２０２をスキャンして、識別された属性値ペアのいずれかを用いるテスト・ケースを識別することによって、実行され得る。代替的に、テスト実行エンジン１０８またはテスト生成器２０８は、テスト・ケースおよび対応する属性値ペアの記録を保持する。

ブロック１００６において、テスト・ケースのサブセットに関連付けられたコード・パスが判断される。コード・パスは、サブセット内の各テスト・ケースに関連付けられたフィンガープリント２０６を用いて判断され得る。

ブロック１００８において、コード・パスの交差領域が判断される。交差領域は、テスト・ケース２０２のほとんどの断続的な成功／失敗を引き起こしているＳＵＴ２１４の部分にさらにズームし、または焦点を合わせる。本発明の１つまたは複数の実施形態では、ブロック１０１０において、コード・パスの交差領域が、ＳＵＴ２１４のソース・コードにおいて強調される。

本発明の１つまたは複数の実施形態では、ブロック１０１２において、デバッグ・コードが、この方式で識別されるＳＵＴ２１４の部分を診断するために生成される。デバッグ・コードは、テスト・ケースの断続的な成功／失敗を引き起こすソフト失敗または任意の他の不具合に適用および診断するためにユーザに提供され得る。例えば、ＳＵＴ２１４がｚ／ＯＳ（登録商標）に基づく場合、ＳＬＩＰなどのコマンド、または性能関連問題を調査するために使用される任意の他のそのようなコマンドが、デバッグ・コードを生成するために使用され得る。ＳＵＴ２１４が任意の他のアーキテクチャまたはオペレーティング・システムを使用している場合に、そのアーキテクチャからの性能関連コマンドが、デバッグ・コードを生成するために使用されると理解されたい。

図１１は、本発明の１つまたは複数の実施形態による、隠れ属性を駆動するＳＵＴの部分を識別する方法のフローチャートを示す。方法１１００は、ブロック１１０２において、所定の閾値未満の成功率（Ｓ_ＡＶ）を有する属性値ペアのセットを識別することを含む。属性値ペアは、可視化８００においてより暗いシェーディングで表されるものであり、可視化８００において、成功率（Ｓ_ＡＶ）は正方形のシェーディングを判断するために使用され、Ｓ_ＡＶが低いほど正方形がより暗くなる。本発明の１つまたは複数の実施形態では、ユーザは、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を用いてさらに調査されるべき可視化８００内の１つまたは複数の正方形を選択する。代替的に、または加えて、ユーザは、閾値より低い（またはより大きい）Ｓ_ＡＶを有する正方形を選択するために閾値Ｓ_ＡＶを提供し得る。

さらに、ブロック１１０４において、実行されるテスト・ケース２０２からのテスト・ケースのサブセットが識別され、サブセットからのテスト・ケースは、属性値ペアの識別されたセットから属性値ペアの少なくとも１つを使用する。テスト・ケースのサブセットを識別することは、テスト・ケース２０２をスキャンして、識別された属性値ペアのいずれかを用いるテスト・ケースを識別することによって、実行され得る。代替的に、テスト実行エンジン１０８またはテスト生成器２０８は、テスト・ケースおよび対応する属性値ペアの記録を保持する。

テスト・ケースのサブセット内のテスト・ケース毎に、ブロック１１０６において、テスト・ケースの成功した実行に関連付けられる第１のコード・パスを判断し、テスト・ケースの失敗した実行に関連付けられる第２のコード・パスを判断する。コード・パスは、サブセット内の各テスト・ケースに関連付けられたフィンガープリント２０６を用いて判断され得る。

ブロック１１０８において、第１のコード・パスおよび第２のコード・パスは、異なるコード・パスの部分を識別するために比較され、それらの部分は、ユーザによる検査のために強調される。コード・パスは、本発明の１つまたは複数の実施形態において、コード・パス内にあるソース・コードを比較するために、テキスト比較を用いて比較され得る。コード・パスの部分の強調は、マークおよび強調されるべきソース・コードの部分を識別するコマンドをグラフィカル・ユーザ・インターフェースに送信することによって、実行され得る。

本発明の１つまたは複数の実施形態では、ブロック１１１０において、デバッグ・コードが、この方式で識別されるＳＵＴ２１４の部分を診断するために生成される。デバッグ・コードは、テスト・ケースの断続的な成功／失敗を引き起こすソフト失敗または任意の他の不具合に適用および診断するためにユーザに提供され得る。例えば、ＳＵＴ２１４がｚ／ＯＳ（登録商標）に基づく場合、ＳＬＩＰなどのコマンド、または性能関連問題を調査するために使用される任意の他のそのようなコマンドが、デバッグ・コードを生成するために使用され得る。ＳＵＴ２１４が任意の他のアーキテクチャまたはオペレーティング・システムを使用している場合に、そのアーキテクチャからの性能関連コマンドが、デバッグ・コードを生成するために使用されると理解されたい。

本発明の実施形態は、したがって、それらの領域が、可視化８００の他の領域と比較して、テスト・ケースをより断続的に成功／失敗させる不具合を強調するため、可視化８００内のより暗い（またはより明るい）領域にアーティスティック・テストを集中させることを容易にする。本発明の実施形態は、ブレークポイント、フィンガープリント、または他の技術を用いて、弱点が示される可視化８００に基づいて、さらに調査されるべきＳＵＴ２１４のソース・コード内の領域を強調することを、さらに容易にする。

ハイティング代数などの疑似ブール代数を利用して、テスト・システム１００は、テスト・ケースの成功率を量子化するとともに、テスト・ケースの結果に一貫して影響を及ぼす隠れ変数をカプセル化し得る。これによって、リソースを調整し得るか、または新たなテスト・インフラストラクチャがそれに従って開発され得るように、テスト・インフラストラクチャ自体以上の因子に起因してテスト・ケースが失敗しているときにユーザがより確実に識別することが可能となる。この強化された成功メトリックは、ＳＵＴ２１４の安定性テストの効率および確実性を改善するために使用され得る。

ここで図１２を参照すると、コンピュータ・システム１２００は、概して、本発明の実施形態に従って示されている。コンピュータ・システム１２００は、本明細書に記載されるように、様々な通信技術を利用する任意の数および組み合わせのコンピューティング・デバイスおよびネットワークを含むかまたは利用し、あるいはその両方である、電子コンピュータ・フレームワークであり得る。コンピュータ・システム１２００は、異なるサービスに変更し、またはそれ以外から独立していくつかの特徴を再構成する能力を用いて、容易にスケール可能であり、拡張可能であり、モジュール式であり得る。コンピュータ・システム１２００は、例えば、サーバ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、またはスマートフォンであってもよい。いくつかの例では、コンピュータ・システム１２００は、クラウド・コンピューティング・ノードであってもよい。コンピュータ・システム１２００は、コンピュータ・システムによって実行されている、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈において説明され得る。概して、プログラム・モジュールは、特定のタスクを実行し、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造などを含み得る。コンピュータ・システム１２００は、通信ネットワークを通してリンクされたリモート処理デバイスによってタスクが実行される、分散型クラウド・コンピューティング環境において実施され得る。分散型クラウド・コンピューティング環境では、プログラム・モジュールが、メモリ記憶デバイスを含むローカルおよびリモート両方のコンピュータ・システム記憶媒体に位置し得る。

図１２に示されるように、コンピュータ・システム１２００は、１つまたは複数の中央処理装置（ＣＰＵ）１２０１ａ、１２０１ｂ、１２０１ｃなど（まとめて、または概してプロセッサ１２０１と呼ばれる）を有する。プロセッサ１２０１は、シングルコア・プロセッサ、マルチコア・プロセッサ、コンピューティング・クラスタ、または任意の数の他の構成であってもよい。プロセッサ１２０１は、処理回路とも呼ばれ、システム・バス１２０２を介してシステム・メモリ１２０３および様々な他のコンポーネントに連結される。システム・メモリ１２０３は、読み取り専用メモリ（ＲＯＭ）１２０４およびランダム・アクセス・メモリ（ＲＡＭ）１２０５を含み得る。ＲＯＭ１２０４は、システム・バス１２０２に連結され、基本入出力システム（ＢＩＯＳ）を含んでもよく、ＢＩＯＳは、コンピュータ・システム１２００のある基本機能を制御する。ＲＡＭは、プロセッサ１２０１により使用するために、システム・バス１２０２に連結された読み取り書き込み用メモリである。システム・メモリ１２０３は、動作中に上記命令の動作のための一時メモリ空間を提供する。システム・メモリ１２０３は、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ、フラッシュ・メモリ、または任意の他の適当なメモリ・システムを含み得る。

コンピュータ・システム１２００は、システム・バス１２０２に連結された入力／出力（Ｉ／Ｏ）アダプタ１２０６および通信アダプタ１２０７を含む。Ｉ／Ｏアダプタ１２０６は、ハード・ディスク１２０８または任意の他の類似のコンポーネントあるいはその両方と通信するスモール・コンピュータ・システム・インターフェース（ＳＣＳＩ）・アダプタであってもよい。Ｉ／Ｏアダプタ１２０６およびハード・ディスク１２０８は、本明細書では大規模ストレージ１２１０とまとめて呼ばれる。

コンピュータ・システム１２００上で実行するためのソフトウェア１２１１は、大規模ストレージ１２１０に記憶され得る。大規模ストレージ１２１０は、プロセッサ１２０１により読み取り可能な有形記憶媒体の例である。ソフトウェア１２１１は、様々な図面に関して本明細書で以下に記載されるように、コンピュータ・システム１２００を動作させる、プロセッサ１２０１による実行のための命令として記憶される。コンピュータ・プログラム製品の例およびそのような命令の実行は、本明細書でより詳細に論じられる。通信アダプタ１２０７は、システム・バス１２０２をネットワーク１２１２と相互接続し、ネットワーク１２１２は、外部ネットワークであってもよく、コンピュータ・システム１２００が他のそのようなシステムと通信することを可能にする。一実施形態では、システム・メモリ１２０３および大規模ストレージ１２１０の一部が、オペレーティング・システムを集合的に記憶し、オペレーティング・システムは、図１２に示される様々なコンポーネントの機能を協調させるための、ＩＢＭ（登録商標） Ｃｏｒｐｏｒａｔｉｏｎのｚ／ＯＳ（登録商標）またはＡＩＸ（登録商標）オペレーティング・システムなどの任意の適当なオペレーティング・システムであってもよい。

追加入力／出力デバイスが、ディスプレイ・アダプタ１２１５およびインターフェース・アダプタ１２１６を介してシステム・バス１２０２に接続されるように示される。一実施形態では、アダプタ１２０６、１２０７、１２１５、および１２１６は、中間バス・ブリッジ（図示せず）を介してシステム・バス１２０２に接続される１つまたは複数のＩ／Ｏバスに接続され得る。ディスプレイ１２１９（例えば、スクリーンまたはディスプレイ・モニタ）は、ディスプレイ・アダプタ１２１５によってシステム・バス１２０２に接続され、ディスプレイ・アダプタ１２１５は、グラフィックス集約型アプリケーションおよびビデオ・コントローラの性能を改善するためのグラフィックス・コントローラを含み得る。キーボード１２２１、マウス１２２２、スピーカ１２２３などが、インターフェース・アダプタ１２１６を介してシステム・バス１２０２に相互接続され得る。インターフェース・アダプタ１２１６は、例えば複数のデバイス・アダプタを単一の集積回路に統合するスーパーＩ／Ｏチップを含み得る。ハード・ディスク・コントローラ、ネットワーク・アダプタ、およびグラフィックス・アダプタなどの周辺デバイスを接続するための適当なＩ／Ｏバスは、典型的には、ペリフェラル・コンポーネント・インターコネクト（ＰＣＩ）などの共通プロトコルを含む。よって、図１２に構成されるように、コンピュータ・システム１２００は、プロセッサ１２０１の形態の処理ケイパビリティ、システム・メモリ１２０３および大規模ストレージ１２１０を含むストレージ・ケイパビリティ、キーボード１２２１およびマウス１２２２などの入力手段、ならびにスピーカ１２２３およびディスプレイ１２１９を含む出力ケイパビリティを含む。

いくつかの実施形態では、通信アダプタ１２０７は、特にインターネット・スモール・コンピュータ・システム・インターフェースなどの任意の適当なインターフェースまたはプロトコルを用いてデータを送信し得る。ネットワーク１２１２は、特に、セルラー・ネットワーク、無線ネットワーク、ワイド・エリア・ネットワーク（ＷＡＮ）、ローカル・エリア・ネットワーク（ＬＡＮ）、またはインターネットであってもよい。外部コンピューティング・デバイスは、ネットワーク１２１２を通してコンピュータ・システム１２００に接続し得る。いくつかの例では、外部コンピューティング・デバイスは、外部ウェブサーバまたはクラウド・コンピューティング・ノードであってもよい。

図１２のブロック図は、コンピュータ・システム１２００が図１２に示されるコンポーネントの全てを含むことを示すように意図されないことを理解されたい。むしろ、コンピュータ・システム１２００は、図１２に示されない、任意の適切な、より少ないまたは追加のコンポーネント（例えば、追加メモリ・コンポーネント、組み込みコントローラ、モジュール、追加ネットワーク・インターフェースなど）を含み得る。さらに、コンピュータ・システム１２００に関して本明細書に記載された実施形態は、任意の適切なロジックで実施され得る。ロジックは、本明細書に参照されるように、様々な実施形態において、任意の適当なハードウェア（例えば、特にプロセッサ、組み込みコントローラ、もしくは特定用途向け集積回路）、ソフトウェア（例えば、特にアプリケーション）、ファームウェア、またはハードウェア、ソフトウェア、およびファームウェアの任意の適当な組み合わせを含み得る。

本開示は、クラウド・コンピューティングについての詳細な説明を含むが、本明細書に列挙する教示の実施態様は、クラウド・コンピューティング環境に限定されないと理解されたい。むしろ、本発明の実施形態は、現在既知の、または後に開発される任意の他の種類のコンピューティング環境と併せて実装されることが可能である。

クラウド・コンピューティングは、最小の管理労力またはサービス・プロバイダとの対話で迅速に供給され、解放され得る、構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想機械、およびサービス）の共有プールへの便利なオンデマンド・ネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも５つの特性、少なくとも３つのサービス・モデル、および少なくとも４つの展開モデルを含み得る。

特性は、以下の通りである。
オンデマンド・セルフサービス：クラウド消費者は、サービス・プロバイダと人との対話を必要とすることなく、必要に応じて自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング・ケイパビリティを一方的に供給し得る。
幅広いネットワーク・アクセス：ケイパビリティは、ネットワーク上で利用可能であり、異種シン・クライアントまたはシック・クライアント・プラットフォーム（例えば、携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準的なメカニズムを通してアクセスされる。
リソースの共用：プロバイダのコンピューティング・リソースが、マルチテナント型モデルを使用して複数の消費者にサービスするためにプールされ、異なる物理リソースおよび仮想リソースが要求に従って動的に割り当ておよび再割り当てされる。消費者が、概して、提供されるリソースの正確な場所に対する制御または知識を有しないが、より高い抽象レベル（例えば、国、州、またはデータセンタ）において場所を指定することが可能であり得るという点において、位置独立の意味がある。
迅速な順応性：ケイパビリティは、場合によっては自動的に、即座にスケール・アウトするように迅速かつ弾力的に供給され、即座にスケール・インするように迅速に解放され得る。消費者に対しては、供給に利用可能なケイパビリティが、多くの場合無制限であるように見え、いつでも任意の量で購入可能である。
サービスが計測可能であること：クラウド・システムは、サービスの種類（例えば、ストレージ、処理、帯域幅、アクティブ・ユーザ・アカウント）に適したある抽象レベルにおいて計測ケイパビリティを活用することによって、リソース使用を自動的に制御し、最適化する。リソース使用量は、モニタリングされ、制御され、報告されて、利用サービスのプロバイダおよび消費者の両方に透明性をもたらし得る。

サービス・モデルは、以下の通りである。
サービスとしてのソフトウェア（ＳａａＳ）：消費者に提供されるケイパビリティは、クラウド・インフラストラクチャ上で実行中のプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース（例えば、ウェブ・ベースの電子メール）を通して、様々なクライアント・デバイスからアクセス可能である。消費者は、限定されたユーザ固有アプリケーションの構成設定は例外である可能性があるが、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション・ケイパビリティでさえも含む、基礎となるクラウド・インフラストラクチャを管理または制御しない。
サービスとしてのプラットフォーム（ＰａａＳ）：消費者に提供されるケイパビリティは、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、消費者が作成したアプリケーションまたは消費者が取得したアプリケーションを、クラウド・インフラストラクチャ上に展開することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎的なクラウド・インフラストラクチャを管理または制御しないが、展開されたアプリケーション、および、可能な限りアプリケーション・ホスティング環境構成に対して制御を行う。
サービスとしてのインフラストラクチャ（ＩａａＳ）：消費者に提供されるケイパビリティは、処理、ストレージ、ネットワーク、ならびに消費者がオペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアを展開および実行することが可能な、他の基本コンピューティング・リソースを供給することである。消費者は、基礎となるクラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、ストレージ、展開されたアプリケーションに対して制御を行い、かつ可能な限り選択ネットワーキング・コンポーネント（例えば、ホスト・ファイアウォール）の限定的な制御を行う。

展開モデルは、以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは、組織のためだけに運用される。クラウド・インフラストラクチャは、その組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスに存在し得る。
コミュニティ・クラウド：クラウド・インフラストラクチャは、複数の組織によって共有され、共有の関心事（例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスの考慮事項）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、その組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスに存在し得る。
パブリック・クラウド：クラウド・インフラストラクチャは、一般公衆または大きな業界団体に利用可能とされ、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、一意なエンティティのままであるが、データおよびアプリケーション・ポータビリティを可能にする標準化技術または独自技術（例えば、クラウド間のロード・バランシングのためのクラウド・バースティング）によって結合された、２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の合成物である。

クラウド・コンピューティング環境は、無国籍、低結合、モジュール性、および意味相互運用性を中心としたサービス指向型である。クラウド・コンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。

ここで図１３を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示するように、クラウド・コンピューティング環境５０は、クラウド消費者によって使用されるローカル・コンピューティング・デバイス、例えば、携帯情報端末（ＰＤＡ）もしくは携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、または自動車コンピュータ・システム５４Ｎ、あるいはそれらの組み合わせが通信し得る、１つまたは複数のクラウド・コンピューティング・ノード１０を含む。ノード１０は、互いに通信し得る。それらは、上述のようなプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、もしくはハイブリッド・クラウド、またはそれらの組み合わせなどの、１つまたは複数のネットワーク内で物理的または仮想的にグループ化され得る（図示せず）。これによって、クラウド・コンピューティング環境５０が、インフラストラクチャ、プラットフォーム、またはソフトウェア、あるいはそれらの組み合わせを、クラウド消費者がローカル・コンピューティング・デバイス上でリソースを維持する必要がないサービスとして提案することが可能となる。図１３に示されるコンピューティング・デバイス５４Ａ～Ｎの種類は、単なる例示であることを意図し、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意の種類のネットワークまたはネットワーク・アドレス可能な接続あるいはその両方を経て（例えば、ウェブ・ブラウザを用いて）、任意の種類のコンピュータ化デバイスと通信し得ると理解されたい。

ここで図１４を参照すると、クラウド・コンピューティング環境５０（図１３）によって提供される機能抽象層のセットが示されている。図１４に示されるコンポーネント、層、および機能は、単なる例示であるように意図され、本発明の実施形態は、それらに限定されないと、予め理解されたい。図示されるように、以下の層および対応する機能が提供される。

ハードウェア層およびソフトウェア層６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例は、メインフレーム６１、ＲＩＳＣ（Reduced Instruction Set Computer）アーキテクチャ・ベース・サーバ６２、サーバ６３、ブレード・サーバ６４、記憶デバイス６５、ならびにネットワークおよびネットワーキング・コンポーネント６６を含む。いくつかの実施形態において、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化層７０は、仮想エンティティの以下の例、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５が提供され得る、抽象層を提供する。

一例では、管理層８０は、後述の機能を提供し得る。リソース供給８１は、クラウド・コンピューティング環境内でタスクを実行するために利用される、コンピューティング・リソースおよび他のリソースの動的な調達を提供する。測定および価格設定８２は、リソースが、クラウド・コンピューティング環境内で利用され、これらのリソースの消費に対して課金または請求されるときに、コスト追跡を提供する。１つの例では、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含み得る。セキュリティは、データおよび他のリソースについての保護だけでなく、クラウド消費者およびタスクのための本人確認を提供する。ユーザ・ポータル８３は、消費者およびシステム管理者にクラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理８４は、要求されるサービス・レベルが満たされるように、クラウド・コンピューティング・リソース割り当ておよび管理を提供する。サービス水準合意（ＳＬＡ）計画および遂行８５は、ＳＬＡに従って将来の要件が予期されるクラウド・コンピューティング・リソースの事前配置および調達を提供する。

ワークロード層９０は、クラウド・コンピューティング環境が利用され得る機能性の例を提供する。この層から提供され得るワークロードおよび機能の例は、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想クラスルーム教育配信９３、データ解析処理９４、トランザクション処理９５、ならびにテスト９６を含む。

本発明の１つまたは複数の実施形態では、コンピュータ・システムは、ＳＵＴ２１４がコンピュータ・システムによって使用されているコンピュータ・プログラムまたはハードウェア・コンポーネントである環境１００であってもよい。本発明の１つまたは複数の実施形態では、コンピュータ・システムは、ＳＵＴ２１４であってもよく、ＳＵＴ２１４は、サーバ・クラスタの一部である。

本発明は、任意の可能な統合の技術的詳細レベルにおけるシステム、方法、またはコンピュータ・プログラム製品、あるいはそれらの組み合わせであってもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令をその上に有する、コンピュータ可読記憶媒体（または複数の媒体）を含み得る。

コンピュータ可読記憶媒体は、命令実行デバイスにより使用するための命令を保持および記憶し得る有形デバイスであり得る。コンピュータ可読記憶媒体は、例えば、電子記憶デバイス、磁気記憶デバイス、光学記憶デバイス、電磁気記憶デバイス、半導体記憶デバイス、または前述したものの任意の適当な組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な実施例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリ・スティック（登録商標）、フロッピー（登録商標）・ディスク、パンチカードまたは命令をその上に記録させる溝内の隆起構造などの機械的に符号化されたデバイス、および前述したものの任意の適当な組み合わせを含む。本明細書で用いられるコンピュータ可読記憶媒体は、電波もしくは他の自由伝播する電磁波、導波管もしくは他の送信媒体を通って伝播する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、または電線を通って送信される電気信号などの、一過性信号それ自体であると解釈されるべきではない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくは無線ネットワーク、またはそれらの組み合わせを介して外部コンピュータまたは外部記憶デバイスに、ダウンロードされ得る。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはそれらの組み合わせを含み得る。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、コンピュータ可読プログラム命令をネットワークから受信し、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体の記憶用にコンピュータ可読プログラム命令を転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用の構成データ、またはＳｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは類似のプログラミング言語などの手続き型プログラミング言語を含む、１つもしくは複数のプログラミング言語の任意の組み合わせで書かれたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で完全に、ユーザのコンピュータ上で部分的に、スタンドアロン・ソフトウェア・パッケージとして、ユーザのコンピュータ上で部分的にかつリモート・コンピュータ上で部分的に、またはリモート・コンピュータもしくはサーバ上で完全に、実行してもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを通してユーザのコンピュータに接続されてもよく、または、接続は、（例えば、インターネット・サービス・プロバイダを用いてインターネットを通して）外部コンピュータに対して行われてもよい。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む電子回路は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路を個別化することによって、コンピュータ可読プログラム命令を実行し得る。

本発明の態様は、本発明の実施形態による、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して、本明細書において説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、およびフローチャート図またはブロック図あるいはその両方のブロックの組み合わせが、コンピュータ可読プログラム命令によって実施され得ると理解されたい。

コンピュータまたは他のプログラマブル・データ処理装置のプロセッサによって実行する命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／動作を実施する手段を作成するように、これらのコンピュータ可読プログラム命令は、汎用コンピュータ、専用コンピュータ、または機械を製造するための他のプログラマブル・データ処理装置のプロセッサに提供されてもよい。命令が記憶されたコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／動作の態様を実施する命令を含む製品を含むように、これらのコンピュータ可読プログラム命令は、また、コンピュータ、プログラマブル・データ処理装置、または他のデバイス、あるいはそれらの組み合わせに特定の方式で機能するように指示し得る、コンピュータ可読記憶媒体に記憶されてもよい。

コンピュータ、他のプログラマブル装置、または他のデバイス上で実行する命令が、フローチャートまたはブロック図あるいはその両方の１つまたは複数のブロックにおいて指定される機能／動作を実施するように、コンピュータ可読プログラム命令は、また、コンピュータ、他のプログラマブル装置、または他のデバイス上で一連の動作ステップを実行させてコンピュータ実施プロセスを生み出すために、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードされてもよい。

図面中のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の考えられる実施態様のアーキテクチャ、機能性、および動作を例示する。この点に関して、フローチャートまたはブロック図内の各ブロックは、指定された論理機能を実施するための１つまたは複数の実行可能命令を含む、モジュール、セグメント、または命令の一部を表し得る。いくつかの代替実施態様において、ブロック内に記載された機能は、図面中に記載された順序以外で発生してもよい。例えば、連続して示される２つのブロックが、実際には、実質的に同時に実行されてもよく、または、ブロックが、関係する機能性次第で逆の順序で実行されることがあってもよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、およびブロック図またはフローチャート図あるいはその両方におけるブロックの組み合わせが、指定された機能もしくは動作を実行し、または専用ハードウェアおよびコンピュータ命令の組み合わせを実行する専用ハードウェア・ベース・システムによって実施され得ることにも留意されたい。

本発明の様々な実施形態の説明は、例示の目的で提示されているが、網羅的であること、または開示される実施形態に限定することを意図するものではない。多くの修正および変形が、説明された実施形態の範囲および思想から逸脱することなく当業者には明らかであろう。本明細書で使用される用語は、実施形態の原理、実際の用途、もしくは市場で発見される技術を超える技術的改善を最もよく説明するため、または他の当業者が本明細書で説明された実施形態を理解できるようにするために、選択された。

本発明の様々な実施形態が、関連する図面を参照して本明細書において説明される。本発明の代替実施形態は、この発明の範囲から逸脱することなく考案され得る。様々な接続および位置関係（例えば、上、下、隣接など）が、以下の説明および図面における要素間で述べられている。これらの接続または位置関係あるいはその両方が、特段の指定がない限り、直接または間接であってもよく、本発明は、この点に関して限定することを意図するものではない。したがって、要素の連結は、直接連結または間接連結のいずれかを指してもよく、要素間の位置関係は、直接または間接の位置関係であってもよい。さらに、本明細書で説明される様々なタスクおよび処理ステップは、本明細書で詳細に説明されない追加ステップまたは機能性を有する、より包括的な手続きまたはプロセスに組み込まれ得る。

以下の定義および略称は、特許請求の範囲および明細書の解釈のために使用されるものとする。本明細書で使用される、「備える（comprises）」、「備えている（comprising）」、「含む（includes）」、「含んでいる（including）」、「有する（has）」、「有している（having）」、「包含する（contains）」、もしくは「包含している（containing）」という用語、またはそれらの任意の他の変形は、非排他的包含を含むように意図するものである。例えば、要素のリストを含む合成物、混合物、プロセス、方法、物品、または装置は、必ずしもそれらの要素だけに限定されず、明示的に列挙されない他の要素、またはそのような合成物、混合物、プロセス、方法、物品、もしくは装置に固有の他の要素を含み得る。

追加的に、「例示的」という用語は、「例、事例、または例示として機能すること」を意味するために、本明細書において使用される。本明細書において「例示的」と説明される任意の実施形態または設計は、必ずしも他の実施形態または設計よりも好適または有利であると解釈されるべきではない。「少なくとも１つの」および「１つまたは複数の」という用語は、１以上の任意の整数、即ち、１、２、３、４などを含むように理解され得る。「複数の」という用語は、２以上の任意の整数、即ち、２、３、４、５などを含むように理解され得る。「接続」という用語は、間接「接続」および直接「接続」の両方を含み得る。

「約」、「実質的に」、「ほぼ」という用語およびそれらの変形は、本出願の出願時点に入手可能な機器に基づく特定の数量の測定値に関連する誤差の程度を含むことを意図するものである。例えば、「約」は、所与の値の±８％、または５％、または２％の範囲を含み得る。

簡潔さのために、本発明の態様を作成し使用することに関連する従来技術は、本明細書において詳細に説明されるとは限らない。特に、本明細書で説明される様々な技術的特徴を実施するコンピューティング・システムおよび特定のコンピュータ・プログラムの様々な態様は、周知である。したがって、簡潔にするために、多くの従来の実施態様の詳細は、本明細書で簡潔に述べられるだけであり、あるいは周知のシステムもしくはプロセスまたはその両方の詳細を提供することなく完全に省略される。

Claims (20)

1. テスト対象システム（ＳＵＴ）をテストするときに欠陥を検出および限局する方法であって、
   前記ＳＵＴへの入力を属性値ペアの集合としてモデル化することと、
   前記属性値ペアによって表されたテスト空間の完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
   前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
   前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
   前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率（Ｓ_ＡＶ）を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
   属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
   選択される前記属性のための追加の値を含むテスト・ベクトルの第２のセットを生成することと、
   前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第２のセットを用いて実行結果の第２のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第２のセットを取得することと、
   前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第２の非バイナリ成功率（Ｓ_ＡＶ’）を属性値ペア毎に記録することと、
   前記属性を含む前記属性値ペアのセットに対応する第２の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知することと、
   を含む、方法。
2. 前記非バイナリ成功率Ｓ_ＡＶが、疑似ブール代数を用いて計算される、請求項１に記載の方法。
3. 前記属性を含む前記属性値ペアのセットに対応する前記第２の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する１つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記１つまたは複数のテスト・ケースが、前記ＳＵＴに関連付けられたソフト失敗を診断するために使用される、請求項１に記載の方法。
4. ソフト失敗が、前記ＳＵＴの１つまたは複数の動作条件によって引き起こされる、請求項３に記載の方法。
5. 前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項１に記載の方法。
6. 前記カルテシアン積空間が、前記ＳＵＴのアーキテクチャ制限に基づいてさらに縮小される、請求項５に記載の方法。
7. 前記アーキテクチャ制限が、第２の属性が特定の属性値を有する場合に第１の属性が１つもしくは複数の候補属性値をとることができないという要件、前記第２の属性が前記特定の属性値を有する場合に前記第１の属性が特定の候補属性値をとらなければならないという要件、または前記第２の属性が前記特定の属性値を有する場合に第３の属性を導入するための要件のうちの少なくとも１つを含む、請求項６に記載の方法。
8. システムであって、
   メモリと、
   前記メモリに連結されたプロセッサであって、前記プロセッサが、テスト対象システム（ＳＵＴ）をテストするときに欠陥を検出および限局する方法を実行するように構成され、前記方法が、
   前記ＳＵＴへの入力を属性値ペアの集合としてモデル化することと、
   前記属性値ペアによって表されたテスト空間の完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
   前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
   前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
   前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率（Ｓ_ＡＶ）を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
   属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
   選択される前記属性のための追加の値を含むテスト・ベクトルの第２のセットを生成することと、
   前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第２のセットを用いて実行結果の第２のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第２のセットを取得することと、
   前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第２の非バイナリ成功率（Ｓ_ＡＶ’）を属性値ペア毎に記録することと、
   前記属性を含む前記属性値ペアのセットに対応する第２の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知すること、および前記属性値ペアのセットを使用する１つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記１つまたは複数のテスト・ケースが、前記ＳＵＴに関連付けられたソフト失敗を診断するために使用される、前記出力することと、
   を含む、前記プロセッサと、
   を備える、システム。
9. 前記非バイナリ成功率Ｓ_ＡＶが、疑似ブール代数を用いて計算される、請求項８に記載のシステム。
10. 前記方法が、前記属性を含む前記属性値ペアのセットに対応する前記第２の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する１つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記１つまたは複数のテスト・ケースが、前記ＳＵＴに関連付けられたソフト失敗を診断するために使用される、前記出力することをさらに含む、請求項８に記載のシステム。
11. ソフト失敗が、前記ＳＵＴの１つまたは複数の動作条件によって引き起こされる、請求項１０に記載のシステム。
12. 前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項８に記載のシステム。
13. 前記カルテシアン積空間が、前記ＳＵＴのアーキテクチャ制限に基づいてさらに縮小される、請求項１２に記載のシステム。
14. 前記アーキテクチャ制限が、第２の属性が特定の属性値を有する場合に第１の属性が１つもしくは複数の候補属性値をとることができないという要件、前記第２の属性が前記特定の属性値を有する場合に前記第１の属性が特定の候補属性値をとらなければならないという要件、または前記第２の属性が前記特定の属性値を有する場合に第３の属性を導入するための要件のうちの少なくとも１つを含む、請求項１３に記載のシステム。
15. プロセッサによる実行時にテスト対象システム（ＳＵＴ）をテストするときに欠陥を検出および限局する方法を前記プロセッサに実行させる、コンピュータ実行可能命令が記憶されたコンピュータ可読記憶媒体を含む、コンピュータ・プログラム製品であって、前記方法が、
    前記ＳＵＴへの入力を属性値ペアの集合としてモデル化することと、
    前記属性値ペアによって表されたテスト空間の完全ｎワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
    前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
    前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
    前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率（Ｓ_ＡＶ）を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
    属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
    選択される前記属性のための追加の値を含むテスト・ベクトルの第２のセットを生成することと、
    前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第２のセットを用いて実行結果の第２のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第２のセットを取得することと、
    前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第２の非バイナリ成功率（Ｓ_ＡＶ’）を属性値ペア毎に記録することと、
    前記属性を含む前記属性値ペアのセットに対応する第２の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知すること、および前記属性値ペアのセットを使用する１つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記１つまたは複数のテスト・ケースが、前記ＳＵＴに関連付けられたソフト失敗を診断するために使用される、前記出力することと、
    を含む、前記コンピュータ・プログラム製品。
16. 前記非バイナリ成功率Ｓ_ＡＶが、疑似ブール代数を用いて計算される、請求項１５に記載のコンピュータ・プログラム製品。
17. 前記方法が、前記属性を含む前記属性値ペアのセットに対応する前記第２の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する１つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記１つまたは複数のテスト・ケースが、前記ＳＵＴに関連付けられたソフト失敗を診断するために使用される、前記出力することをさらに含む、請求項１５に記載のコンピュータ・プログラム製品。
18. ソフト失敗が、前記ＳＵＴの１つまたは複数の動作条件によって引き起こされる、請求項１７に記載のコンピュータ・プログラム製品。
19. 前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項１５に記載のコンピュータ・プログラム製品。
20. 前記カルテシアン積空間が、前記ＳＵＴのアーキテクチャ制限に基づいてさらに縮小される、請求項１９に記載のコンピュータ・プログラム製品。

Images