(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-12-26
(54)【発明の名称】隠れ変数、隠れ属性、および隠れ値検出を用いたシステム・テスト・インフラストラクチャ
(51)【国際特許分類】
G06F 11/36 20060101AFI20231219BHJP
【FI】
G06F11/36 184
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023536374
(86)(22)【出願日】2021-12-01
(85)【翻訳文提出日】2023-06-15
(86)【国際出願番号】 EP2021083725
(87)【国際公開番号】W WO2022128469
(87)【国際公開日】2022-06-23
(32)【優先日】2020-12-15
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】390009531
【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MACHINES CORPORATION
【住所又は居所原語表記】New Orchard Road, Armonk, New York 10504, United States of America
(74)【代理人】
【識別番号】100112690
【氏名又は名称】太佐 種一
(74)【代理人】
【識別番号】100120710
【氏名又は名称】片岡 忠彦
(74)【復代理人】
【識別番号】110000420
【氏名又は名称】弁理士法人MIP
(72)【発明者】
【氏名】ヒックス、アンドリュー
(72)【発明者】
【氏名】ミナーレイ、ケヴィン
(72)【発明者】
【氏名】ブルー、デール
(72)【発明者】
【氏名】ロウリンス、ライアン、トーマス
(72)【発明者】
【氏名】ギソルフィ、ダニエル、ニコラス
【テーマコード(参考)】
5B042
【Fターム(参考)】
5B042HH17
5B042HH18
5B042HH49
(57)【要約】
テスト対象システム(SUT)への入力が、属性値ペアの集合としてモデル化される。テスト・ケースのセットは、属性値ペアの完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを用いて実行される。テスト・ケースの実行毎に、非バイナリ成功率(SAV)が、バイナリ実行結果に基づいて属性値ペア毎に計算される。属性は、上記属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて選択される。テスト・ケースのセットが、選択された属性のための追加の値を使用するテスト・ベクトルの別のセットを用いて実行される。テスト・ケースのセットの実行毎に、第2の非バイナリ成功率(SAV’)が、属性値ペア毎に記録される。ここで所定の閾値が満たされる場合、検出された属性のための追加の値がユーザに通知される。
【特許請求の範囲】
【請求項1】
テスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法であって、
前記SUTへの入力を属性値ペアの集合としてモデル化することと、
前記属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率(S
AV)を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
選択される前記属性のための追加の値を含むテスト・ベクトルの第2のセットを生成することと、
前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第2のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第2の非バイナリ成功率(S
AV’)を属性値ペア毎に記録することと、
前記属性を含む前記属性値ペアのセットに対応する第2の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知することと、
を含む、方法。
【請求項2】
前記非バイナリ成功率S
AVが、疑似ブール代数を用いて計算される、請求項1に記載の方法。
【請求項3】
前記属性を含む前記属性値ペアのセットに対応する前記第2の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、請求項1に記載の方法。
【請求項4】
ソフト失敗が、前記SUTの1つまたは複数の動作条件によって引き起こされる、請求項3に記載の方法。
【請求項5】
前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項1に記載の方法。
【請求項6】
前記カルテシアン積空間が、前記SUTのアーキテクチャ制限に基づいてさらに縮小される、請求項5に記載の方法。
【請求項7】
前記アーキテクチャ制限が、第2の属性が特定の属性値を有する場合に第1の属性が1つもしくは複数の候補属性値をとることができないという要件、前記第2の属性が前記特定の属性値を有する場合に前記第1の属性が特定の候補属性値をとらなければならないという要件、または前記第2の属性が前記特定の属性値を有する場合に第3の属性を導入するための要件のうちの少なくとも1つを含む、請求項6に記載の方法。
【請求項8】
システムであって、
メモリと、
前記メモリに連結されたプロセッサであって、前記プロセッサが、テスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法を実行するように構成され、前記方法が、
前記SUTへの入力を属性値ペアの集合としてモデル化することと、
前記属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率(S
AV)を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
選択される前記属性のための追加の値を含むテスト・ベクトルの第2のセットを生成することと、
前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第2のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第2の非バイナリ成功率(S
AV’)を属性値ペア毎に記録することと、
前記属性を含む前記属性値ペアのセットに対応する第2の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知すること、および前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することと、
を含む、前記プロセッサと、
を備える、システム。
【請求項9】
前記非バイナリ成功率S
AVが、疑似ブール代数を用いて計算される、請求項8に記載のシステム。
【請求項10】
前記方法が、前記属性を含む前記属性値ペアのセットに対応する前記第2の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することをさらに含む、請求項8に記載のシステム。
【請求項11】
ソフト失敗が、前記SUTの1つまたは複数の動作条件によって引き起こされる、請求項10に記載のシステム。
【請求項12】
前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項8に記載のシステム。
【請求項13】
前記カルテシアン積空間が、前記SUTのアーキテクチャ制限に基づいてさらに縮小される、請求項12に記載のシステム。
【請求項14】
前記アーキテクチャ制限が、第2の属性が特定の属性値を有する場合に第1の属性が1つもしくは複数の候補属性値をとることができないという要件、前記第2の属性が前記特定の属性値を有する場合に前記第1の属性が特定の候補属性値をとらなければならないという要件、または前記第2の属性が前記特定の属性値を有する場合に第3の属性を導入するための要件のうちの少なくとも1つを含む、請求項13に記載のシステム。
【請求項15】
プロセッサによる実行時にテスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法を前記プロセッサに実行させる、コンピュータ実行可能命令が記憶されたコンピュータ可読記憶媒体を含む、コンピュータ・プログラム製品であって、前記方法が、
前記SUTへの入力を属性値ペアの集合としてモデル化することと、
前記属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率(S
AV)を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
選択される前記属性のための追加の値を含むテスト・ベクトルの第2のセットを生成することと、
前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第2のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第2の非バイナリ成功率(S
AV’)を属性値ペア毎に記録することと、
前記属性を含む前記属性値ペアのセットに対応する第2の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知すること、および前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することと、
を含む、前記コンピュータ・プログラム製品。
【請求項16】
前記非バイナリ成功率S
AVが、疑似ブール代数を用いて計算される、請求項15に記載のコンピュータ・プログラム製品。
【請求項17】
前記方法が、前記属性を含む前記属性値ペアのセットに対応する前記第2の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することをさらに含む、請求項15に記載のコンピュータ・プログラム製品。
【請求項18】
ソフト失敗が、前記SUTの1つまたは複数の動作条件によって引き起こされる、請求項17に記載のコンピュータ・プログラム製品。
【請求項19】
前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項15に記載のコンピュータ・プログラム製品。
【請求項20】
前記カルテシアン積空間が、前記SUTのアーキテクチャ制限に基づいてさらに縮小される、請求項19に記載のコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、コンピュータ・システムのテストに関し、より詳細には、テストされていないがテストすべきである、隠れ変数、隠れ属性、および隠れ属性値を識別し得るテスト・ケース・インフラストラクチャに関する。さらに、本発明は、例えば、そのような変数をテストするために追加のテスト・ケースを生成すること、実行しなければならないコード・パスを識別すること、などによって、識別された隠れ変数を使用して、テスト・インフラストラクチャを改善することに関する。
【背景技術】
【0002】
コンピュータ化デバイスは、文書を書くこと、信号機の制御、電子商取引の完了から有人宇宙船任務の制御まで、我々の生活のほとんど全ての側面を制御する。しかしながら、コンピュータ化デバイスは、エラーが生じ易いことが多く、したがって、エラーを発見し補正するテスト段階を必要とする。テスト段階は、コンピュータ化デバイスを設計する際の最も困難なタスクの1つと考えられる。エラーを発見しないことの代償は、コンピュータ化デバイスの利用方法次第では莫大であることがあるため、徹底的なテストが重要である。ソフトウェアをチェックするためのカバレッジ・ツールは、評価されているソフトウェアがテスト中にどのくらいうまく実行されているかの尺度を提供し、それによりソフトウェアが高品質であるという保証のレベルを与える。
【発明の概要】
【0003】
本発明の1つまたは複数の実施形態によれば、テスト対象システム(SUT)をテストするときに欠陥を検出および限局するための方法は、SUTへの入力を属性値ペアの集合としてモデル化することと、属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、を含む。方法は、テスト・ベクトルの初期セットからテスト・ケースのセットを生成することをさらに含む。方法は、テスト・ケースのセットを実行して実行結果のセットを取得することであって、実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、テスト・ケースのセットが、複数回実行される、実行結果のセットを取得することをさらに含む。方法は、テスト・ケースのセットの実行毎に、実行結果に基づいて非バイナリ成功率(SAV)を属性値ペア毎に更新することであって、属性値ペアの非バイナリ成功率が、上記属性値ペアを使用する各テスト・ケースの実行結果に基づく、更新することをさらに含む。方法は、属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて上記属性を選択することをさらに含む。選択される属性のための追加の値を含む、テスト・ベクトルの第2のセットが生成される。さらに、テスト・ケースのセットは、テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得するために実行され、テスト・ケースのセットが、少なくとも所定の回数実行される。さらに、テスト・ケースのセットの実行毎に、第2の非バイナリ成功率(SAV’)が、実行結果に基づいて属性値ペア毎に記録される。上記属性を含む属性値ペアのセットに対応する第2の成功率のセットが所定の閾値を満たすことに応じて、検出された属性のための追加の値がユーザに通知される。
【0004】
本発明の1つまたは複数の実施形態によれば、システムは、メモリと、メモリに連結されたプロセッサと、を含み、プロセッサが、テスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法を実行する。方法は、SUTへの入力を属性値ペアの集合としてモデル化することと、属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、を含む。方法は、テスト・ベクトルの初期セットからテスト・ケースのセットを生成することをさらに含む。方法は、テスト・ケースのセットを実行して実行結果のセットを取得することであって、実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、テスト・ケースのセットが、複数回実行される、実行結果のセットを取得することをさらに含む。方法は、テスト・ケースのセットの実行毎に、実行結果に基づいて非バイナリ成功率(SAV)を属性値ペア毎に更新することであって、属性値ペアの非バイナリ成功率が、上記属性値ペアを使用する各テスト・ケースの実行結果に基づく、更新することをさらに含む。方法は、上記属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて属性を選択することをさらに含む。選択される属性のための追加の値を含む、テスト・ベクトルの第2のセットが生成される。さらに、テスト・ケースのセットは、テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得するために実行され、テスト・ケースのセットが、少なくとも所定の回数実行される。さらに、テスト・ケースのセットの実行毎に、第2の非バイナリ成功率(SAV’)が、実行結果に基づいて属性値ペア毎に記録される。上記属性を含む属性値ペアのセットに対応する第2の成功率のセットが所定の閾値を満たすことに応じて、検出された属性のための追加の値がユーザに通知される。
【0005】
本発明の1つまたは複数の実施形態によれば、コンピュータ・プログラム製品は、プロセッサによる実行時にテスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法をプロセッサに実行させる、コンピュータ実行可能命令が記憶されたコンピュータ可読記憶媒体を含む。方法は、SUTへの入力を属性値ペアの集合としてモデル化することと、属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、を含む。方法は、テスト・ベクトルの初期セットからテスト・ケースのセットを生成することをさらに含む。方法は、テスト・ケースのセットを実行して実行結果のセットを取得することであって、実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、テスト・ケースのセットが、複数回実行される、実行結果のセットを取得することをさらに含む。方法は、テスト・ケースのセットの実行毎に、実行結果に基づいて非バイナリ成功率(SAV)を属性値ペア毎に更新することであって、属性値ペアの非バイナリ成功率が、上記属性値ペアを使用する各テスト・ケースの実行結果に基づく、更新することをさらに含む。方法は、上記属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて属性を選択することをさらに含む。選択される属性のための追加の値を含む、テスト・ベクトルの第2のセットが生成される。さらに、テスト・ケースのセットは、テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得するために実行され、テスト・ケースのセットが、少なくとも所定の回数実行される。さらに、テスト・ケースのセットの実行毎に、第2の非バイナリ成功率(SAV’)が、実行結果に基づいて属性値ペア毎に記録される。上記属性を含む属性値ペアのセットに対応する第2の成功率のセットが所定の閾値を満たすことに応じて、検出された属性のための追加の値がユーザに通知される。
【0006】
追加の技術的特徴および利益が、本発明の技術を通して実現される。本発明の実施形態および態様が、本明細書において詳細に説明され、特許請求される主題の一部と考えられる。より良く理解するために、詳細な説明および図面を参照する。
【0007】
本明細書で説明される排他的権利の詳細は、明細書の末尾における特許請求の範囲において詳細に指示され、明確に請求される。本発明の実施形態の、前述のおよびその他の特徴および利点は、添付図面と併せて用いられる以下の詳細な説明から明らかである。
【図面の簡単な説明】
【0008】
【
図1】本発明の1つまたは複数の実施形態による、コンピュータ化環境の概略図を示す。
【
図2】本発明の実施形態による、テスト・インフラストラクチャを提供するモジュールを表すブロック図である。
【
図3】本発明の1つまたは複数の実施形態による、組み合わせテスト設計(CTD)を用いた欠陥検出および限局、ならびに検出された欠陥を顕在化させる失敗テスト・ケースの回帰バケットの生成を示す概略ハイブリッド・データ・フロー/ブロック図である。
【
図4】本発明の1つまたは複数の実施形態による、例としてのCTDベクトルのセットを示す。
【
図5】本発明の1つまたは複数の実施形態による、例としてのCTDベクトルを示す。
【
図6】本発明の1つまたは複数の実施形態による、CTD技術を用いてnワイズ欠陥を検出および限局するため、ならびに検出されたnワイズ欠陥を顕在化させる失敗テスト・ケースの回帰バケットを生成するための、例示的方法のプロセス・フロー図である。
【
図7】本発明の1つまたは複数の実施形態による、テスト対象システムをテストするときに経時的な属性値ペアの成功率を用いてテスト・モデルの不備を検出する方法のフローチャートを示す。
【
図8】本発明の1つまたは複数の実施形態による、属性値ペアの成功率(S
AV)の可視化の例を示す。
【
図9】本発明の1つまたは複数の実施形態による、隠れ属性が現在のテスト・モデルに存在するかどうかを判断する方法のフローチャートを示す。
【
図10】本発明の1つまたは複数の実施形態による、隠れ属性を駆動するテスト対象システムの部分を識別する方法のフローチャートを示す。
【
図11】本発明の1つまたは複数の実施形態による、隠れ属性を駆動するSUTの部分を識別する方法のフローチャートを示す。
【
図12】本発明の1つまたは複数の実施形態による、コンピュータ・システムを示す。
【
図13】本発明の1つまたは複数の実施形態による、クラウド・コンピューティング環境を示す。
【
図14】本発明の1つまたは複数の実施形態による、抽象化モデル層を示す。
【発明を実施するための形態】
【0009】
本明細書で示される図は、例示である。本発明の思想から逸脱することなく、図面またはそこに説明される動作に対して多くの変形が存在し得る。例えば、アクションは、異なる順序で実行されてもよく、またはアクションが、追加され、削除され、もしくは修正されてもよい。また、「連結される」という用語およびその変形は、2つの要素間に通信経路を有することを述べ、要素間に介在要素/接続のない要素間の直接接続を意味するものではない。これらの変形の全てが、明細書の一部と考えられる。
【0010】
本発明の例示的実施形態は、特に、組み合わせテスト設計(CTD)技術を用いて欠陥検出および限局を実行するため、ならびに検出された欠陥を顕在化させるテスト・ケースの回帰バケットを生成するための、デバイス、システム、方法、コンピュータ可読媒体、技術、および方法論に関する。本発明の例示的実施形態では、検出および限局された欠陥が、テスト対象システム(SUT)において生じる。SUTは、ハードウェア・システムまたはソフトウェア・システムであってもよい。さらに、本発明の例示的実施形態では、欠陥検出および限局は、SUTに対するアーキテクチャ制限を遵守しながら実行され得る。
【0011】
SUTの品質を査定するとき、SUTの「より脆弱な部分」を識別し、それらが存在する理由を理解することが必須である。この文脈における「より脆弱な部分」は、SUTに関連付けられた1つまたは複数のパラメータが変化するときにより失敗を起こし易い、SUTの部分であり得る。例えば、失敗を引き起こす「隠れ属性」が、SUTの脆弱部分と考えられ得る。SUTに関連付けられたパラメータは、SUTの設定可能な値、例えば、メモリの量、プロセッサの数、またはSUTを形成する任意の他のそのようなハードウェア/ソフトウェア、およびSUTのハードウェアまたはソフトウェアあるいはその両方に関連付けられた任意の設定を含み得る。加えて、SUTの成功/失敗、またはSUTの1つもしくは複数のテスト・ケースの成功/失敗に影響を及ぼし得るSUTのパラメータは、温度、湿度、電力、併せて実行されているソフトウェア・アプリケーションの組み合わせ、SUTによって併せて実行されているジョブの数/種類、およびSUTのインスタンスによって変化し得る任意の他のそのような動的条件などの、SUTに関連付けられる動作条件を含み得る。
【0012】
SUTのより脆弱な部分を識別する既存技術は、範囲が狭く、失敗またはエラーを引き起こすメトリックが十分述べられていない。ゆえに、メトリックは、1つまたは複数のそのような失敗の原因を説明するのに十分ではない。所与のテスト・ケースの成功率の計算のように、いくつかのそのような既存技術は、SUTでの根本的な問題を早期に警告する標識を提供し得る。しかしながら、根本的な問題の識別には、人手による介入、および当技術分野における深いスキルが必要である。
【0013】
例えば、テスト・ケースの失敗は、バグなどのSUT自体の実装におけるエラーのせいである場合がある。代替的に、テスト・ケースの失敗は、間違ったユーザ入力のせいである場合がある。代替的に、テスト・ケースの失敗は、SUTを予期せぬ方式で動作させる、動作条件によって引き起こされる場合がある。さらに、テスト・ケースの失敗は、テスト・ケース内のテストされていない(ゆえに、調整されていない)属性、または値のせいである場合がある。加えて、テスト・ケースの失敗は、ある構成を有する第1のSUTにおいて発生しているが、実質的に同一の構成を有する第2のSUTにおいては発生していない場合がある。
【0014】
SUTをテストすると、いくつかのエラーは、特定の環境またはタイミング状況の要件に起因して、一貫して表面化しないことが観測される。例えば、ソフトウェアSUTの場合、状況は、ソフトウェアが実行されているコンピュータ・システムの1つまたは複数のパラメータを含み得る。例えば、パラメータは、コンピュータ・システムの設定、コンピュータ・システム上で実行されている他のソフトウェア、コンピュータ・システムのハードウェア構成などを含み得る。同様に、ハードウェアSUTの場合、ハードウェアSUTがその一部であるシステムの構成が、環境条件に影響を及ぼし得る。言い換えると、SUTにおける特定のエラーは、システム状態の結果であり、SUT自体の品質ではない場合がある。いくつかのエラーは、「ソフト失敗」と呼ばれることがある。本明細書で「隠れ変数」と呼ばれる、ソフト失敗につながり得るそのような条件を識別することが、技術的課題である。追加的に、ソフト失敗を識別すること、即ち、エラーがソフト失敗であると判断することも、技術的課題であり得る。
【0015】
SUTにおける隠れ変数がテストの結果に大きな影響を及ぼすとき、この困難度が特に悪化する。隠れ変数は、制御されていない因子である場合があり、場合によっては、テスト・ケース実行時に制御できないことがある。例えば、テスト・ケース自体によって構成されないがテスト・ケースを断続的に失敗させることがある、温度、湿度、ジョブの組み合わせ、利用可能なメモリなどのSUTの動作条件のいずれかが、隠れ変数と考えられ得る。隠れ変数は、それらがSUTの特定範囲外であるために、所与のテスト・インフラストラクチャに対して常に発見可能であるとは限らない。例えば、ストレス・テストは、様々なリソース(例えば、メモリ、計算サイクルなど)が制約された構成にSUTを追い込んで、それによって、一貫して再現することが、不可能でないにしても困難な、SUTにおいて予測不能なエラーまたは失敗を引き起こし得る。これは、ストレス・テストが検証する特定の機能または特徴が安定しているとしても、ストレス・テストが依存するリソースによって、SUTが不適当に実行し、または失敗し得ることを意味する。
【0016】
よって、技術的課題は、1つまたは複数の隠れ変数が所与のテスト・ケースの結果に一貫して影響を及ぼすと判断し、そのような隠れ変数をさらに識別するための、テスト・インフラストラクチャに存在する。さらに、リソースを調整し得るか、または新たなテスト・インフラストラクチャがそれに従って開発され得るように、テスト・インフラストラクチャ自体以上の因子に起因してテスト・ケースが失敗しているときに、そのような隠れ変数を識別するために、技術的課題が存在する。
【0017】
本発明の実施形態は、コンピュータ・システムのためのテスト・インフラストラクチャでのそのような技術的課題に対処する。テスト・インフラストラクチャ自体が、メモリ・デバイス、処理ユニット、および1つまたは複数のコンピュータ実行可能命令を含むコンピュータ・システムを含むことに留意されたい。したがって、本発明の実施形態は、コンピューティング技術、テスト・インフラストラクチャ、およびSUTに対する改善を容易にする。本発明の1つまたは複数の実施形態では、本発明の実施形態は、ハイティング代数などの疑似ブール代数を利用することによって、テスト・ベクトルの成功率を量子化しつつ、テスト・ケースの結果に一貫して影響を及ぼす隠れ変数をカプセル化し得る。例えば、テスト・ベクトル<アンドリュー,青,30>について、これは、この場合、割り当てられた値の組み合わせを有する3つの属性<名前,色,年齢>を有し、成功率は、テスト・ケースがこの特定の値の組み合わせを用いる間に成功する頻度を示す。「属性値ペア」は、テスト・ケースによってテストされている特定の属性に割り当てられる、特定の値を表す。属性は、テスト中に複数の値を通して循環される。さらに、テストされる複数のそのような属性が存在し得る。属性値ペアの成功率の量子化は、品質保証エンジニアなどのユーザが、リソースを調整し得るか、または新たなテスト・インフラストラクチャがそれに従って開発され得るように、テスト・インフラストラクチャ自体以上の因子に起因してテスト・ケースが失敗しているときを確実に識別することを可能にする。この強化された成功メトリックは、SUTの全体的な安定性を改善するテストの取り組みの効率および確実性を改善するために使用され得る。したがって、本発明の実施形態は、コンピューティング技術、特にSUTをテストするために使用されるテスト・インフラストラクチャにおける技術的課題に対する改善、実用化、および技術的解決策を提供する。
【0018】
追加的に、SUTをテストするためのカバレッジ・ツールは、SUTがテスト中にどれだけうまく動作しているかの尺度を提供し、それによりSUTが高品質であるというあるレベルの保証が得られる。ステートメント・カバレッジ、ライン・カバレッジ、条件カバレッジ、パス・カバレッジ、メソッド・カバレッジなどの、当技術分野において既知のいくつかの種類のカバレッジが存在する。1つのさらなるカバレッジ方法は、機能カバレッジである。機能カバレッジは、所定の機能的挙動を検査したテストの量、部分、または類似のメトリックを測定するように設計される。機能カバレッジが測定されると、品質保証(QA)要員は、テストされていない挙動を検査するための追加テストを設計し得る。
【0019】
しかしながら、テスト・インフラストラクチャは、非常にコストがかかる場合があり、製品、テスト、および環境を絶え間なく最適化しなければ、テスト・サイクル毎のコストは増加する。多くのテストが追加されるにつれて、より多くのテスト・スイートが動作し、サポート・サービスの複雑性が、各テスト・サイクルのコストと共に増加する。テスト環境、テスト依存関係、およびテスト・スイートは、出荷されている製品(即ちSUT)と同一の厳密さで管理される必要がある。したがって、テスト・インフラストラクチャを管理することが技術的課題であり、同様に、テスト・インフラストラクチャの効率的な縮小が技術的課題である。テスト・インフラストラクチャの縮小は、SUTのテスト品質の低下を意味しないことに留意されたい。むしろ、技術的課題は、テスト品質がテスト・インフラストラクチャの縮小と共に改善されるべきであるということである。
【0020】
本発明の実施形態は、そのような技術的課題に対処する。本発明の1つまたは複数の実施形態によれば、SUTのためのテスト・ケースの縮小セットが、システム上で実行される。システムはSUTとは異なり、SUTは、システムを用いて実行されていることに留意されたい。テスト・ケースの縮小セットは、組み合わせテスト設計(CTD)を用いて生成され得る。エラーは、その縮小セットから失敗するテストのサブセットに基づいて識別され得る。さらに、本発明の1つまたは複数の実施形態によれば、逆CTDが、システムにおける欠陥を限局するために使用される。
【0021】
本発明の1つまたは複数の実施形態によれば、CTDは、ペアワイズ・インタラクション、nタプル・インタラクション、またはその他などのインタラクション要件に関して行われる。テスト計画は、インタラクション要件が満たされることを保証する十分なカバレッジ・タスクを提供し得る。いくつかの例示的実施形態では、テスト計画は、機能カバレッジ・モデルを用いたテスト空間のモデル化に基づく。テスト空間は、入力、シナリオ、構成、アプリケーションの内部状態、またはテストされる必要があり得る任意の他の態様を表し得る。機能カバレッジ・モデルは、機能属性のセットを含み得る。本発明の他の実施形態では、カバレッジ・モデルは、ステートメント・カバレッジ、ライン・カバレッジ、条件カバレッジ、パス・カバレッジ、メソッド・カバレッジなどの、当技術分野において既知のいくつかの種類のカバレッジから1つを含み得る。カバレッジの種類は、本明細書に記載されるテスト・インフラストラクチャ技術の縮小に影響を及ぼさない。
【0022】
さらに、テスト計画に関して、テスト空間は、SUT上で実行され得る潜在テストを定義し得る。テストは、カバレッジ・タスクとは対照的に、1つだけの潜在テストに関連付けられ得る。本発明のいくつかの例示的実施形態では、いくつかの異なるテストが、同一の潜在テストを保持し得る。
【0023】
本発明のいくつかの例示的実施形態では、CTDの手法に対する動機付けは、大抵のエラーが少数の機能属性間のインタラクションに依存するということである。CTDアルゴリズムは、スケーラビリティの問題にも対処し得る。CTDアルゴリズムは、組み合わせ空間が大きすぎて明示的に表すことができないと仮定する場合があり、それらは、様々な技術を用いて、全ての可能な組み合わせを明示的に列挙することなく最適化されたテスト計画を生成しようと試みる。そのようなアルゴリズムの例が、直交配列または被覆配列問題への縮小であり得る。それらの技術は、値の組み合わせに与える制限の種類、または要求されるインタラクション・レベルの種類において制限され、モデル変数の数が増加するにつれてスケーラビリティの問題にやはりぶつかる。
【0024】
本発明の1つまたは複数の実施形態では、SUTへの入力は、属性値ペアの集合としてモデル化される。より具体的には、SUTへの入力は、属性の集合としモデル化されてもよく、そのそれぞれが、1つまたは複数の対応する属性値をとり得る。本発明の1つまたは複数の実施形態では、属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間全体が、テスト空間全体の完全nワイズ・カバレッジを提供するテスト・ベクトルのより小さなセットに縮小され得る。例えば、4つの異なる属性A、B、C、およびDがモデル化されると仮定される場合、かつ属性Aが4つの別個の値をとることができ、属性Bが3つの別個の値をとることができ、属性Cが3つの別個の値をとることができ、属性Dが2つの別個の値をとることができるとさらに仮定される場合、属性値ペアの可能な組み合わせの総数は、4×3×3×2=72となる。したがって、この例示的な例では、カルテシアン積空間全体が、属性値ペアの72の異なる組み合わせを含む。前述した通り、属性値ペアのこれらの72の異なる組み合わせは、カルテシアン積空間の完全nワイズ・カバレッジを依然として提供する組み合わせのより小さなセットに縮小され得る。例えば、上記で導入された同じ例を参照すると、完全ペアワイズ・カバレッジが求められる場合、72の異なる組み合わせが、属性値のあらゆる可能なペアワイズ・インタラクションを一緒に含む、12の別個の組み合わせに減少され得る。nワイズ・カバレッジを提供するために必要な、減少された数の組み合わせは、nが増加するにつれて対数的に増加し得る。
【0025】
本発明の例示的実施形態では、属性値ペアの全ての組み合わせを含むカルテシアン積空間全体が、所望のnについて完全nワイズ・カバレッジを提供するCTDテスト・ベクトルのより小さなセットに縮小される。複雑なハードウェアまたはソフトウェア・システムにおいては、属性の総数および対応する候補属性値が極めて大きい場合があり、その場合、カルテシアン積空間全体を作り上げる属性値の可能な組み合わせの総数は、天文学的に大きくなることがあり、それによって、全ての可能な組み合わせをテストすることは事実上実行不可能となる。カルテシアン積空間全体を、完全nワイズ・カバレッジをやはり提供する大幅に小さな数のCTDテスト・ベクトルに縮小することによって、テスト空間における全ての可能な組み合わせを直接テストしなくても、任意のnワイズ(またはm<nの場合にmワイズ)欠陥が検出されることが可能となる。
【0026】
本発明の例示的実施形態において、縮小を実行し、完全nワイズ・カバレッジを提供するCTDベクトルの縮小セットを識別するために、二分決定図などが使用され得る。本発明の1つまたは複数の実施形態では、生成される各CTDテスト・ベクトルは、属性値の一意な組み合わせを含み、CTDテスト・ベクトルのセットは、属性値の全ての可能なnワイズ・インタラクションを一緒に含む。特に、各CTDベクトルは、モデル化される属性の数に対応する次元を有し得る。その場合、CTDベクトルの各成分は、対応する属性のそれぞれの属性値である。しかしながら、生成されるCTDベクトルのセットは、一意ではない場合がある。即ち、CTDベクトルの複数の異なるセットが存在することがあり、そのそれぞれが完全nワイズ・カバレッジを提供する。本発明の1つまたは複数の実施形態では、CTDベクトルが、完全nワイズ・カバレッジを依然として確保しながら、ランダムに選択され得る。他の1つまたは複数の実施形態では、CTDベクトルの初期セットは、例えば、CTDベクトルのセットの中の特定の属性値の表現を増加または減少させるなど考慮して特定の基準で選択され得る。
【0027】
本発明の例示的実施形態では、CTDテスト・ベクトルの初期セットが一旦生成されると、それらは、テスト・ケースの対応するセットを生成するために使用される。例えば、CTDテスト・ベクトルのセットは、各CTDベクトルのためのそれぞれの対応するテスト・ケースを生成するように構成されるテスト・ケース生成ツールへの入力として、提供され得る。各テスト・ケースは、対応するCTDベクトルに含まれる属性値の特定の組み合わせ間のインタラクションをテストするように設計され得る。
【0028】
本発明の例示的実施形態では、次いで、テスト・ケースが実行される。各テスト・ケースの実行は、テスト・ケースに関連付けられた属性値の組み合わせがnワイズ(もしくはm<nの場合にmワイズ)エラーを含まないことを示す成功の実行結果、またはテスト・ケースに関連付けられた属性値の組み合わせがnワイズ(もしくはm<nの場合にmワイズ)エラーを含むことを示す失敗の実行結果のいずれかの結果をもたらす。本発明の1つまたは複数の実施形態では、特定の失敗テスト・ケースが次いで選択され、逆組み合わせ論が失敗テスト・ケースに適用されてバグを顕在化させることが可能なテスト・ケースの新たなセットを作り出す。本発明の例示的実施形態では、選択した失敗テスト・ケースへの逆組み合わせ論の適用は、属性毎にそれぞれの新たなテスト・ケースを生成することを含む。したがって、生成される新たなテスト・ケースの数は、属性の数に等しくなり得る。本発明の例示的実施形態では、それぞれの新たなテスト・ケースにおいて、選択した失敗テスト・ケース内の対応する属性の属性値が、どの失敗テスト・ケースにも存在しない属性についての属性値に変更され、他の各属性についてのそれぞれの属性値は、選択した失敗テスト・ケースに存在するものから変更されない。
【0029】
成功の実行結果を生じるそれらの新たなテスト・ケースは、次いで、nワイズ(またはm<nの場合にmワイズ)エラーを検出および限局するために査定され得る。特に、エラーを引き起こす特定の属性値ペアは、実行が成功する新たなテスト・ケースに基づいて識別され得る。テスト・ケースの回帰バケットは、次いで、属性値ペアのエラーを生じさせる組み合わせに基づいて生成され得る。より具体的には、エラーを引き起こすと判断される属性値を含む属性値の全ての可能な組み合わせが判断されてもよく、これらの組み合わせをテストするための対応するテスト・ケースの回帰バケットが、例えば、手動テスタにより使用するために出力され得る。特に、本発明の1つまたは複数の実施形態では、回帰バケットに含まれる全てのテスト・ケースは、バグが修正されるまで実行時に失敗し、バグ修正後は、全ての回帰バケット・テスト・ケースが合格するはずである(即ち、成功の実行結果を生じる)。
【0030】
本発明の例示的実施形態では、アーキテクチャ制限が、SUTに適用され得る。アーキテクチャ制限は、SUTへの入力に対する多様な制限のうちのいずれかを含み得る。例えば、例としての制限は、所与の属性が特定の属性値を有する場合に、1つまたは複数の他の属性が、ある属性値を有することから除外されることであってもよい。別の例としてのアーキテクチャ制限は、所与の属性が特定の属性値を有する場合に、1つまたは複数の他の属性が、ある属性値を有しなければならないということであってもよい。さらに別の例としてのアーキテクチャ制限は、特定の属性が特定の属性値を有する場合にのみ、新たな属性が導入されることであってもよい。アーキテクチャ制限の上記の例は、単なる例示であり、網羅的ではないことを理解されたい。
【0031】
本発明の例示的実施形態では、所望の完全nワイズ・カバレッジを提供するCTDベクトルの初期セットへのカルテシアン積空間全体の縮小を実行する前に、アーキテクチャ制限が考慮される。即ち、本発明の例示的実施形態では、任意のアーキテクチャ制限に違反する属性値の特定の組み合わせは、カルテシアン積空間から最初に除外され、次いで、所望の完全nワイズ・カバレッジを提供するCTDベクトルのセットへの縮小が実行される。このようにして、アーキテクチャ制限に違反する属性値の組み合わせがCTDベクトルの初期セットに含まれないことが保証され得る。さらに、本発明の例示的実施形態では、初期CTDベクトルに対応する選択したテスト・ケースが失敗し、かつnワイズ・エラーを検出および限局するように設計された新たなテスト・ケースのセットを取得するための拡大のために選択されるとき、その拡大は、いかなるアーキテクチャ制限も考慮に入れることなく最初に実行され得る。次いで、アーキテクチャ制限に違反する任意の新たなテスト・ケースが除外され得る。このようにして、拡大は、失敗テスト・ケースの近傍におけるテスト空間の可能な限り多くのカバレッジを提供することが保証され得る。加えて、本発明の例示的実施形態では、失敗テスト・ケースの回帰バケットが、アーキテクチャ制限に関係なく最初に生成されてもよく、次いで、アーキテクチャ制限に違反する任意のテスト・ケースが、回帰バケットから除外されてもよい。即ち、nワイズ・エラーまたはより低い次数のエラーを引き起こす属性値の特定の組み合わせを含む、カルテシアン積テスト空間全体における全ての可能な組み合わせに対応するテスト・ケースが、最初に生成され、次いで制限に違反するいかなるテスト・ケースも除外するように縮小され得る。代替的に、回帰バケットに含まれるテスト・ケースは、CTDベクトルの初期セットが選択される、縮小されたカルテシアン積空間から選択されてもよく、その場合、回帰バケットは、エラーを引き起こす属性値のサブセットを含み、かついかなるアーキテクチャ制限にも違反しない、それらの属性値の組み合わせのみを含むように生成される。
【0032】
本発明の1つまたは複数の実施形態は、コンピュータ技術に様々な改善をもたらす技術的効果を生じる様々な技術的特徴を含む。例えば、本発明の例示的実施形態は、選択した失敗テスト・ケースからテスト・ケースのセットを拡大するための、逆組み合わせ論の技術的特徴を含む。この技術的特徴は、nワイズ欠陥またはより低い次数の欠陥が、拡大の単一の繰り返しの中で検出および限局されることを可能にする。この技術的効果は、デバッグおよび欠陥検出コンピュータ技術に対する改善を表す。それは、欠陥の検出および限局を容易にするように特に設計された方式で、選択した失敗テスト・ケースの周囲の追加テスト・ケースの生成を自動化するからである。よって、本発明の1つまたは複数の実施形態による新たなテスト・ケースの自動生成は、手動によるテスト・ケース生成よりも効率的に欠陥を顕在化させることおよび基本的に異なる方法論を用いることを可能にする。本発明の例示的実施形態は、nワイズ欠陥を引き起こす属性値の特定のサブセットを含む属性値の全ての可能な組み合わせをテストする、テスト・ケースの回帰バケットを生成する技術的特徴も含む。よって、回帰バケットは、欠陥の補正前は全て失敗し、かつ欠陥の補正後に全て合格するテスト・ケースのみを含む。よって、本発明の1つまたは複数の実施形態による失敗テスト・ケースの回帰バケットの自動生成は、そのそれぞれが失敗することが確実である、テスト・ケースのセットを有するテスタまたは自動テスト・アルゴリズムを提供することによってコンピュータ技術に対する改善をもたらし、それによって、テスタまたは自動テスト・アルゴリズムが、テスト・ケースの回帰バケットを使用して、デバッグ実行後全てのテスト・ケースが最終的に合格するときに、欠陥が補正されていることを検証し得る。
【0033】
SUTをテストする取り組みのライフサイクルの間、相当な時間およびリソースが、テスト・ケースを実行してSUTを検証するために一貫したテスト・システムを提供する、持続可能な、信頼できるテスト・ケースおよびインフラストラクチャを構築することに費やされる。テスト・システム構築の最終結果は、特に、メンテナンスおよび更新が経時的に適用されるように、SUTの寿命全体を通してSUTを連続的に検証するための確実で効率的な方法である。十分なテスト・カバレッジを確実にする一般的な方法は、CTDの使用を通してテスト・カバレッジが十分であることを保証することである。
【0034】
このパラダイムを伴う技術的課題は、テスト・モデル設計者が、テストされるべきものから属性値を見落とすこと、またはテストされるべき属性の値に対して不十分な粒度を定義することのいずれかにある。このような場合、テスト・システムによる使用のために生成されるテスト・モデルは、不完全である場合があり、これがSUTの不完全なテストにつながる。別の技術的課題は、テストを生成するために使用される特定のアルゴリズムに起因した、経時的な任意の1つのテスト属性変数値の偏った使用である。この場合も、属性値のいくつかが実行されない結果となり、さらにSUTのテストが不完全なものとなる。欠落している属性値に加えて、前述した通り、技術的課題は、隠れ変数が、SUTで発生している場合がある失敗の根本原因をテストまたは識別できない、あるいはその両方のテスト・ケースを引き起こすことも含む。
【0035】
「隠れ変数」が、SUTの温度などの、SUTと同時稼働する他のアプリケーション、ジョブ、またはサービスなどのパラメータを制御することが困難であることに起因して、断続的に失敗し得ることに留意されたい。「隠れ属性」は、より良好なテスト・ベクトルを生成するために、モデルに含まれるべき属性である。「隠れ属性値」は、より良好なテスト・ベクトルを生成するためにモデル内の属性に含まれるべきであるが、テスト・モデル生成時に欠落した/見落とされた値、またはユーザがテスト・モデル設計時に意識しなかった値である。一方、「隠れ値」は、1つまたは複数のテスト・ケースの結果に影響を及ぼす、環境因子/外的因子である。
【0036】
本発明の実施形態は、CTDを用いて、SUTをテストするためのテスト・ケースを自動的に生成および選択すること、ならびに1つまたは複数のテスト・ケースの失敗を引き起こす1つまたは複数の隠れ変数を検出するためにハイティング代数、クリプキ代数、または任意の他の直観主義論理などの疑似ブール代数の使用をさらに容易にすることによって、そのような技術的課題に対処する。本発明の実施形態は、検出された隠れ変数を用いて、テスト・ケースの失敗を引き起こし得るエラーを検出するためにさらに診断する必要があり得る、SUTの1つまたは複数の部分を判断することをさらに容易にする。
【0037】
本発明の1つまたは複数の実施形態では、テストされるべき欠落した属性/隠れ属性を認識するために、属性値ペア毎の経時的な成功率が、疑似ブール・アルゴリズムを用いて計算される。成功率の履歴は、そのとき、不規則に分散された視覚的表現を用いて視覚的に表示される。視覚的表現は、SUTをテストするために使用されたモデルのテスト・ベクトル属性値の不均一テーブルまたはヒートマップとも呼ばれ得る。代替的に、または加えて、履歴データに基づいて、所定の閾値を満たしていない成功率を有する値を含む、モデル内の属性が識別される。識別された属性は、少なくともその属性をテストするために使用された値のセットにおける深さ不足を識別し、明らかにするために用いられる。追加の値を属性および任意の他の関連属性に加えることによって、属性の成功率が、再び経時的にモニタリングされる。成功率閾値が満たされる場合、隠れ値または隠れ属性が、追加された値によって識別されていると見なされ得る。隠れ値は、その後、テスト・ケースのさらなるセットにおいて使用され得る。
【0038】
ここで
図1を参照すると、
図1は、本発明の実施形態による、コンピュータ化環境の概略図を示す。コンピュータ化環境100は、1つまたは複数のコンピュータ化ツールを含み得る。図はブロック図の1つの可能な例であること、およびいくつかのコンポーネントは明確化のために図示されないことがあることに留意されたい。
【0039】
本発明の1つまたは複数の実施形態では、開発者、QAスタッフ・メンバ、テスタ、設計者、検証エンジニアなどのユーザ110が、コンピュータ化環境100と対話し得る。ユーザ110は、端末、ディスプレイ、キーボード、入力デバイスなどの、マンマシン・インターフェース(MMI)112を利用し得る。
【0040】
本発明のいくつかの例示的実施形態では、カバレッジ・モデル定義ツール102は、機能カバレッジ・モデルなどのテスト・カバレッジ・モデルを定義するために利用され得る。本発明のいくつかの例示的実施形態では、ユーザ110は、テストされる属性、例えば、機能カバレッジがテストされている場合は機能属性を定義し得る。本発明のいくつかの例示的実施形態では、類似のツールが、テスト空間を定義するために利用され得る。いくつかの例示的実施形態では、カバレッジ・モデルは、テスト・モデルとして利用されるように適合され得る。
【0041】
本発明のいくつかの例示的実施形態では、テスト実行エンジン108は、SUTをテストするために利用され得る。SUTは、ハードウェア、ファームウェア、ソフトウェア、それらの組み合わせ、または任意の他の種類のコンピュータ化デバイスであってもよいことに留意されたい。テスト実行エンジン108は、シミュレーションベース検証ツール、テスト生成プラットフォームなどであってもよい。テスト実行エンジン108は、テスト計画ツール106に動作可能に連結され、テスト計画に従ってテストを実行するように構成され得る。いくつかの例示的実施形態では、テスト計画ツール106は、テスト実行エンジン108が実行するためのテストを提供し得る。動的検証は、SUTのテストよりも幅広い概念であり、テスト計画、カバレッジ分析などをさらに含むことに留意されたい。テスト実行エンジン108は、動的検証中に実行され得る動作範囲全体の態様1つだけを提供し、「動的検証」という用語をより狭く解釈するために使用されるべきではない。
【0042】
本発明のいくつかの例示的実施態様では、カバレッジ分析ツール104は、テスト実行エンジン108によって実行される動的検証に基づいて、SUTのためのテスト空間のカバレッジを測定するように構成される。例えば、カバレッジ分析ツール104は、機能カバレッジ分析ツールであってもよい。カバレッジ分析ツール104は、テスト実行エンジン108によって実行される動的検証の間カバーされたカバレッジ・タスクを示す、カバレッジ・テスト空間または定義されたテスト計画の一部などのカバレッジ測定値を提供する。ユーザ110は、カバレッジ測定値またはカバーされたタスクのリストあるいはその両方をレビューし得る。
【0043】
本発明のいくつかの例示的実施形態では、テスト計画ツール106は、カバーされるテスト計画を定義し得る。本発明のいくつかの例示的実施形態では、テスト計画は、カバーされるカバレッジ・タスクのセットであってもよい。本発明のいくつかの例示的実施形態では、テスト計画ツール106は、SUTの特定態様をカバーするように知られ/推定されるテストを含むデータストアに記憶されるテスト・ベンチマークなどに基づいて、テスト計画をカバーすると見られるテストを提供し得る。別の例として、テスト計画ツール106は、カバレッジ・タスクをカバーするようなテストを生成するように構成される。ユーザ110は、テスト計画、選択したテストなどをレビューし得る。本発明のいくつかの例示的実施形態では、ユーザ110は、テスト計画ツール106のためのパラメータを提供して、所望のインタラクション・レベルなどのテスト計画の目的を判断する際に使用し得る。本発明の実施形態は、生成されたテストにおけるいかなる冗長性の除去も可能にする。
【0044】
図1の図示は、カバレッジ・モデル定義ツール102、カバレッジ分析ツール104、テスト計画ツール106、およびテスト実行エンジン108を含む特定のコンポーネントを用いて記載されているが、本発明の実施形態は、これらのコンポーネントまたはシステム構成に限定されず、より少ないまたは追加のコンポーネントを採用した他のシステム構成を用いて実施され得る。
【0045】
図2は、本発明の実施形態による、テスト・インフラストラクチャを提供するモジュールを表すブロック図である。より具体的には、インフラストラクチャは、テスト生成器208を含む。テスト生成器208は、テスト・ケース202のリポジトリなどのテスト・インフラストラクチャにアクセスし、テスト・ケース202のリポジトリは、SUT214の正当性を検証するために利用可能なテスト・ケースのスイートを記憶する。各テスト・ケースは、SUT214に適用される入力、および(その正当な動作を示すための)この入力に応答して返されるべき予期される応答を指定する。典型的には、テスト・ケースは、セット(テスト・スイート)、例えばSUT214の異なるコンポーネントについての各テスト・スイートに編成される。
【0046】
テスト生成器208は、SUT214上のテストの実行毎に実行バケットを作成する。バケットは、(XMLベースなどの)機械可読言語における所望のテスト・ケースを実行させるために行われる動作を指定する。特に、完全テストの場合、利用可能なテスト・ケースの全てが、SUT214の各コンポーネント上で実行され、逆に、回帰テストの場合、実行は、選択したテスト・ケースのサブセットに限定される。そのように取得されたバケットは、ファイルに保存され得る。
【0047】
テスト実行エンジン108は、ファイルから読み出されるバケットの実行を制御する。バケット212の各テスト・ケースの場合、これは、SUT214への対応する入力(属性値)の適用を伴う。それに応答して、SUT214は、対応する出力をテスト実行エンジン108に返す。テスト実行エンジン108は、その出力を(例えば、ファイルから抽出される)対応する予期される応答と比較することによって、テスト・ケースの結果を判断する。テスト・ケースの結果(即ち、2つの値が合致するときは肯定的で、そうでないときは否定的)は、ログに保存される。例えば、これは、標準テスト・トラッキング・ツール(TTT)を用いて実現され得る。テストの(現在の)実行結果が、それらの分析のためのログにおいて利用可能である。
【0048】
大規模で複雑なSUT214の場合、テスト・ケース・インフラストラクチャ202は、大量の二重テスト・アクション/テスト・ケースを含み得る。本発明のある実施形態によれば、これらの課題に対処するために開発された1つの技術は、フィンガープリント・リポジトリ206の使用を、テスト・リポジトリ202に記憶された複数の回帰テストに対応するフィンガープリントのセットを含む情報のストアと組み合わせる。一実施形態では、フィンガープリントは、フィンガープリント生成器204によって生成される。例えば、フィンガープリント・リポジトリ206は、テスト・リポジトリ202に記憶されたテストの、全てではないがほとんどのフィンガープリントと、本の索引に類似した、テスト・インフラストラクチャ全体を通してテストのコピーが位置する場所への参照と、を含み得る。各フィンガープリントは、対応するテスト・ケースによってカバーされる特定のコード・パスを一意に識別する。このようにして、システムは、冗長かつ場合によっては二重である、フィンガープリント(および対応するテスト)を識別し得る。
【0049】
本発明の実施形態によれば、テスト生成器208によって生成され、テスト実行エンジン108によって実行される回帰テストの結果216の処理は、それぞれの生成された回帰テストの実行中に通過するコード・パスの判断、およびコード・パスに少なくとも部分的に基づいて実行された回帰テスト・ケース毎のフィンガープリントの生成を含み得る。本発明のいくつかの実施形態では、これらのステップは、フィンガープリント生成器204によって実行され得る。ここで、テスト・ケースに関連付けられた「コード・パス」は、テスト・ケースによって実行されるSUT214の部分を指す。
【0050】
冗長性分析器218は、テスト生成器208によって生成される全てのテスト・ケースに対応するフィンガープリントをフィンガープリント・リポジトリ206に記憶された複数のフィンガープリントと比較する。冗長性分析器218は、フィンガープリント・リポジトリ206に記憶された1つまたは複数のフィンガープリントと合致するフィンガープリントを有する、テスト生成器208によって生成された回帰テスト・ケースのリストを提供する。この情報は、(以下に記述されるように)テスト・リポジトリ202から二重テスト・ケースを選択および破棄するために使用される。
【0051】
図3は、本発明の1つまたは複数の実施形態による、CTD技術を用いた欠陥検出および限局、ならびに検出された欠陥を顕在化させる失敗テスト・ケースの回帰バケットの生成を示す、概略ハイブリッド・データ・フロー/ブロック図である。
図6は、本発明の1つまたは複数の実施形態による、CTD技術を用いてnワイズ欠陥を検出および限局するため、ならびに検出されたnワイズ欠陥を顕在化させる失敗テスト・ケースの回帰バケットを生成するための、例示的方法600のプロセス・フロー図である。
図6は、
図1~
図5と併せて説明される。
【0052】
本発明の1つまたは複数の実施形態による例示的方法、ならびに方法を実行するための対応するデータ構造(例えば、モジュール、ユニット、および他のそのようなコンポーネント)が、ここで説明される。本明細書に記載された1つまたは複数の方法の各動作が、本明細書に記載されたモジュールなどのうちの1つまたは複数によって実行され得ることに留意されたい。これらのモジュールは、本明細書に記載されたハードウェア、ソフトウェア、またはファームウェア、あるいはそれらの組み合わせの任意の組み合わせで実施され得る。ある1つまたは複数の実施形態では、これらのモジュールのうちの1つまたは複数が、処理回路による実行時に1つまたは複数の動作を実行させるコンピュータ実行可能命令を含むソフトウェア・モジュールまたはファームウェア・モジュールあるいはその両方として少なくとも一部、実施され得る。1つまたは複数の実施形態を実施するように構成されているとして本明細書に記載されるシステムまたはデバイスは、1つまたは複数の処理回路を含んでもよく、そのそれぞれが、1つまたは複数の処理ユニットまたはノードを含み得る。コンピュータ実行可能命令は、処理ユニットによる実行時に、コンピュータ実行可能プログラム・コードに含まれるかまたはコンピュータ実行可能プログラム・コードによって参照される入力データが出力データをもたらすようにアクセスされ処理され得る、コンピュータ実行可能プログラム・コードを含み得る。
【0053】
本発明の1つまたは複数の実施形態において、
図3と併せて
図6を参照すると、方法600のブロック602において、SUT214への入力が属性値ペア302の集合としてモデル化される。任意の数の属性が、SUT入力をモデル化するために使用されてもよく、各属性は、任意の数の候補属性値をとり得る。ブロック604において、1つまたは複数のnワイズ・カバレッジCTDベクトル生成モジュール304のコンピュータ実行可能命令が、属性値ペア302の集合に関連付けられたカルテシアン積空間全体のnワイズ・カバレッジを提供する、CTDベクトルの初期セット306を生成するために実行される。
【0054】
特に、属性値ペア302の全ての可能な組み合わせを含むカルテシアン積空間全体が、テスト空間全体の完全nワイズ・カバレッジを提供するCTDテスト・ベクトルのより小さなセット306に縮小される。本発明の1つまたは複数の実施形態では、CTDベクトルのセット306によって提供される完全nワイズ・カバレッジは、完全ペアワイズ・カバレッジであってもよい。例えば、3つの属性、即ち、
図4に示される「名前」属性、「色」属性、および「形状」属性がモデル化されると仮定される場合、かつ「名前」属性が4つの別個の属性(デール、レイチェル、アンドリュー、およびライアン)をとることができ、「色」属性が2つの別個の属性(緑、青)をとることができ、「形状」属性が3つの別個の属性(円、四角、三角)をとることができるとさらに仮定される場合、属性値ペアの可能な組み合わせの総数は、4×3×2=24となる。したがって、この例示的な例では、カルテシアン積空間全体が、属性値ペアの24の異なる組み合わせを含むことになる。
【0055】
属性値ペアの24の異なる組み合わせが、カルテシアン積空間の完全nワイズ・カバレッジをやはり提供する組み合わせのより小さなセット(即ち、CTDベクトルのセット306)に縮小され得る。例えば、完全ペアワイズ・カバレッジが求められる場合、24の異なる組み合わせが、属性値の全ての可能なペアワイズ・インタラクションを共に含む12の別個の組み合わせに縮小され得る。CTDベクトルの例としてのセット400が、
図4に示される。CTDベクトルの例としてのセット400は、属性「名前」、「色」、および「形状」の属性値間の全てのペアワイズ・インタラクションを含む。
【0056】
縮小を実行し、完全nワイズ・カバレッジを提供するCTDベクトルの縮小セット306を識別するために、二分決定図などが使用され得る。CTDベクトルのセット306内の各CTDベクトルは属性値の一意な組み合わせを含むが、CTDベクトルのセット306自体が、一意ではないことがある。即ち、CTDベクトルの複数の異なるセットが存在してもよく、そのそれぞれが、完全nワイズ・カバレッジを提供する。例えば、
図4は、記載された例としての属性および属性値についてのCTDベクトルの例としてのセット400を示しているが、属性値の異なる組み合わせを含むCTDベクトルの代替セットが完全nワイズ・カバレッジも独立して提供し得ることを理解されたい。CTDベクトルの例としてのセット400が完全ペアワイズ・カバレッジおよび部分的3ワイズ・カバレッジを提供するが、より大きな数のCTDベクトルが、完全3ワイズ・カバレッジを提供するために必要であることを、さらに理解されたい。さらに概して述べると、nが増加するにつれて、完全nワイズ・カバレッジを提供するために必要なCTDベクトルの数が、nと共に対数的に増加する。
【0057】
図5は、CTDベクトルのセット306に含まれ得る種類の例としてのCTDベクトル500を示す。例としてのCTDベクトル500は、複数の属性502を含む。前述の通り、属性502は、SUT214への入力をモデル化するために使用され得る。属性502は、属性値504に関連付けられ得る。特に、各属性502は、対応する属性値504を有してもよく、属性値504は、属性がとることが可能な1つまたは複数の候補属性値のうちの1つであってもよい。
【0058】
本発明の1つまたは複数の実施形態では、アーキテクチャ制限は、所望の完全nワイズ・カバレッジを提供するCTDベクトルの初期セット306へのカルテシアン積空間全体の縮小を実行する前に、方法600において考慮される。即ち、任意のアーキテクチャ制限に違反する属性値の特定の組み合わせは、カルテシアン積空間から最初に除外され、次いで、所望の完全nワイズ・カバレッジを提供するCTDベクトルのセット306への縮小が実行される。このようにして、アーキテクチャ制限に違反する属性値の組み合わせがCTDベクトルの初期セット306に含まれないことが保証され得る。
【0059】
アーキテクチャ制限は、SUT214への入力に対する多様な制限のうちのいずれかを含み得る。例えば、例としての制限は、所与の属性が特定の属性値を有する場合に、1つまたは複数の他の属性が、ある属性値を有することから除外されるということであってもよい。別の例としてのアーキテクチャ制限は、所与の属性が特定の属性値を有する場合に、1つまたは複数の他の属性が、ある属性値を有しなければならないということであってもよい。さらに別の例としてのアーキテクチャ制限は、特定の属性が特定の属性値を有する場合およびその場合にのみ、新たな属性が導入されるということであってもよい。アーキテクチャ制限の上記の例は、単なる例示であり、網羅的ではないことを理解されたい。
【0060】
再び
図6を参照すると、方法600のブロック606において、本発明の1つまたは複数の実施形態では、テスト・ケース生成モジュール208は、CTDテスト・ベクトルの初期セット306から、テスト・ケース202の対応するセットを生成するために実行されてもよく、テスト・ケース202の対応するセットは、次いで、テスト・ケース実行モジュール108によって実行されて、テスト・ケース毎の実行結果(合格または失敗)がもたらされる。
【0061】
例えば、CTDテスト・ベクトルのセット306は、CTDベクトル毎のそれぞれの対応するテスト・ケースを生成するテスト・ケース生成ツール208への入力として提供され得る。テスト・ケース202のセット内の各テスト・ケースは、CTDベクトルのセット306の対応するCTDベクトルに含まれる属性値の特定の組み合わせ間のインタラクションをテストする。CTDベクトルのセットおよびそれらの対応するテスト・ケースが、ここでの時点において、交換可能に説明または図示され、あるいはその両方が行われ得ることを理解されたい。例えば、
図4に示されるCTDベクトルの例としてのセット400は、CTDベクトルのセット400によって表される属性値の特定の組み合わせをテストする、テスト・ケースの対応するセットとして交換可能に考えられ得る。
【0062】
方法600のブロック608において、テスト・ケース実行モジュール108のコンピュータ実行可能命令が、テスト・ケース202のセット内の任意のテスト・ケースが失敗したかどうかを判断するために実行される。本発明の1つまたは複数の実施形態において、各テスト・ケース202の実行は、対応するCTDベクトル306に含まれる属性値の組み合わせがnワイズ(もしくはm<nの場合にmワイズ)エラーを含まないことを示す成功の実行結果、または対応するCTDベクトル306における属性値の組み合わせがnワイズ(もしくはm<nの場合にmワイズ)エラーを含むことを示す失敗の実行結果のいずれかの結果をもたらす。
【0063】
図4に示される例を参照すると、CTDベクトルの例としてのセット400に対応するテスト・ケースは、ブロック606において実行されて、テスト・ケース毎のそれぞれの実行結果をもたらす。特に、2つのテスト・ケース402および404は、失敗をもたらすとして
図4に例示的に示されている。失敗テスト・ケース402は、属性値の以下の組み合わせ、デール、青、三角をテストする。デール、青、三角は、それぞれ名前属性、色属性、および形状属性に対応する。失敗テスト・ケース404は、属性値の以下の組み合わせ、デール、青、円をテストする。デール、青、円は、それぞれ名前属性、色属性、および形状属性に対応する。「デール」および「青」は、失敗テスト・ケース402に対応するCTDベクトル、および失敗テスト・ケース404に対応するCTDベクトルの両方に存在するが、「デール」および「青」がペアワイズ・エラーを生成しているかどうか、「デール」および(「三角」もしくは「円」)がペアワイズ・エラーを生成しているかどうか、または「青」および(「三角」または「円」)がペアワイズ・エラーを生成しているかどうかについては、プロセスのこの段階では不明確である。方法600の後続動作は、逆組み合わせ論を利用して、nワイズ・エラー(
図4に示される例の場合のペアワイズ・エラー)を引き起こしている属性値の特定の組み合わせを検出および限局するために、選択した失敗テスト・ケースの周りのテスト空間を拡大し得る。
【0064】
ブロック608における否定的な判断に応答して、テスト・ケース202の初期セットのいずれも失敗しなかったため、方法600は終了し得る。CTDベクトルの初期セット306(それに基づいてテスト・ケース202のセットが生成される)は、完全nワイズ・カバレッジを提供したため、それは、nワイズ・エラーまたはより低い次数のエラーが存在しないことが保証され得る。しかしながら、テスト・ケース202の初期セット内の全てのテスト・ケースの実行成功は、より高い次数のエラー(k>nの場合にkワイズ)が存在しないことを保証しない。
【0065】
一方、ブロック608の肯定的判断が、テスト・ケース202のセットの実行が1つまたは複数の失敗テスト・ケース314をもたらすことを示すことに応答して、方法600は、逆CTDテスト・ケース生成モジュール316を用いて、特定の失敗テスト・ケース314を実行および選択し、選択した失敗テスト・ケース314に逆組み合わせ論を適用してnワイズ・エラーまたはより低い次数のエラーを引き起こしている属性値の組み合わせを検出および限局するために使用されることが可能なテスト・ケース318の新たなセットを作り出すことを含む。
【0066】
本発明の1つまたは複数の実施形態では、選択した失敗テスト・ケース314への逆組み合わせ論の適用は、属性毎にそれぞれの新たなテスト・ケース318を生成することを含む。したがって、生成される新たなテスト・ケースの数は、属性の数に等しくなり得る。1つまたは複数の実施形態では、それぞれの新たなテスト・ケース318において、対応する属性の選択した失敗テスト・ケース314における属性値は、いかなる他の失敗テスト・ケースにも存在しない属性についての属性値に変更され、他の各属性についてのそれぞれの属性値は、選択した失敗テスト・ケース314に存在するものから変更されない。
【0067】
図4に示される例を再び参照して、失敗テスト・ケース402がブロック610において選択されると仮定すると、新たなテスト・ケース406の例としてのセットが生成され得る。本発明の1つまたは複数の実施形態では、それぞれの例としての新たなテスト・ケース406は、選択した失敗テスト・ケース402内の対応する属性の属性値を任意の他の失敗テスト・ケースに存在しない異なる値に変更することによって生成され得る。例えば、CTDベクトル<アンドリュー、青、三角>に対応する第1の新たなテスト・ケースは、失敗テスト・ケース402における「名前」属性の属性値を「デール」から「アンドリュー」へ変更する一方、他の属性についての属性値を失敗テスト・ケース402と同一に保つことによって取得される。同様に、CTDベクトル<デール、緑、三角>に対応する第2の新たなテスト・ケースは、失敗テスト・ケース402における「色」属性の属性値を「青」から「緑」へ変更する一方、他の属性についての属性値を失敗テスト・ケース402と同一に保つことによって取得される。最後に、CTDベクトル<デール、青、四角>に対応する第3の新たなテスト・ケースは、失敗テスト・ケース402における「形状」属性の属性値を「三角」から「四角」へ変更する一方、他の属性についての属性値を失敗テスト・ケース402と同一に保つことによって取得される。
【0068】
それぞれの新たなテスト・ケース406を取得するために変更されるそれぞれの属性値が、選択した失敗テスト・ケース402には明らかに存在しないことを理解されたい。さらに、それぞれの変更された属性値は、いかなる他の失敗テスト・ケース(例えば、失敗テスト・ケース404)にも存在しない。具体的には、第1の新たなテスト・ケースについて変更された属性値「アンドリュー」は、どの失敗テスト・ケースにも存在せず、第2の新たなテスト・ケースについて変更された属性値「緑」は、どの失敗テスト・ケースにも存在せず、第3の新たなテスト・ケースについて変更された属性値「四角」は、どの失敗テスト・ケースにも存在しない。
【0069】
選択した失敗テスト・ケース314に対して逆組み合わせ論を実行することによって新たなテスト・ケース318のセットを生成した後、テスト・ケース実行モジュール108は、方法600のブロック612において、新たなテスト・ケース318を実行するために使用される。さらに、ブロック614において、1つまたは複数のnワイズ・エラー限局モジュール322は、変更すると合格する新たなテスト・ケースをもたらす、選択した失敗テスト・ケース314内の属性およびそれらの対応する元の失敗属性値に基づいて、nワイズ・エラーまたはより低い次数のエラーを検出および限局する。特に、nワイズ・エラー限局モジュール322のコンピュータ実行可能命令は、新たなテスト・ケース318のセットについての実行結果320を評価して成功の実行結果をもたらす新たなテスト・ケースに基づいてnワイズ・エラーまたはより低い次数のエラーを検出および限局するために、実行される。本明細書で使用される、より低い次数のエラーは、CTDベクトルのセット306による完全nワイズ・カバレッジを想定して、m<nの場合のmワイズ・エラーを指している。
【0070】
ペアワイズ・エラーの検出および限局を想定する
図4に示される例を再び参照すると、新たなテスト・ケース406のセットの実行は、CTDベクトル<アンドリュー、青、三角>に対応する第1の新たなテスト・ケースが合格し、CTDベクトル<デール、緑、三角>に対応する第2の新たなテスト・ケースが合格し、CTDベクトル<デール、青、四角>に対応する第3の新たなテスト・ケースが失敗するという結果になる。1つまたは複数の実施形態では、失敗テスト402の「三角」から第3の新たなテスト・ケースの「四角」に属性値を変更することによって失敗の結果が続くため、nワイズ・エラー限局モジュール322は、第3の新たなテスト・ケースについての失敗の実行結果に基づいて、「形状」属性はペアワイズ・エラーの一因ではないと判断する。
【0071】
一方、nワイズ・エラー限局モジュール322は、実行が合格した新たなテスト・ケースを取得するために属性値が変更された属性が、ペアワイズ・エラーの一因であると判断し得る。具体的には、本発明の1つまたは複数の実施形態では、CTDベクトル<アンドリュー、青、三角>に対応する第1の新たなテスト・ケースについての成功の実行結果に基づいて、nワイズ・エラー限局モジュール322は、「名前」属性および元の失敗属性値「デール」がペアワイズ・エラーの一因であると判断する。同様に、1つまたは複数の実施形態では、CTDベクトル<デール、緑、三角>に対応する第2の新たなテスト・ケースについての成功の実行結果に基づいて、nワイズ・エラー限局モジュール322は、「色」属性および元の失敗属性値「青」もペアワイズ・エラーの一因であると判断する。
【0072】
よって、新たなテスト・ケース318のセットについての実行結果320に基づいて、nワイズ・エラー限局モジュール322は、
図4に示される例において、属性値「デール」および「青」をそれぞれ有する属性「名前」および「色」が、ペアワイズ・エラーの原因であると判断し得る。さらに概して述べると、nワイズ・エラー限局モジュール322は、新たなケース318のセットについての実行結果320の評価に基づいて、nワイズ・エラーまたはより低い次数のエラーを引き起こす特定の属性値ペア、より具体的には、合格する新たなテスト・ケースを取得するために選択した失敗テスト・ケースにおいて変更された元の属性値を判断し得る。
【0073】
図4に示される例は、完全ペアワイズ・カバレッジを提供するCTDベクトルの初期セット400を想定し、その場合に、ペアワイズ・エラーまたはより低い次数のエラー(例えば、エラーを引き起こす単一属性値)は、選択した失敗テスト・ケースに逆組み合わせ論を適用するただ1つの合格において検出および限局されて、新たなテスト・ケース318のセットを取得し得る。概して、CTDベクトルの初期セット306がnワイズ・カバレッジを提供する場合、選択した失敗テスト・ケースに対して逆組み合わせ論を適用するただ1つの合格が、nワイズ・エラーまたはより低い次数のエラーを明らかにする。k>nの場合のkワイズ・エラーは、完全nワイズ・カバレッジを提供するCTDベクトルの初期セットを用いて検出可能であってもよいが、CTDベクトルの初期セット306は全てのkワイズ・インタラクションを含まないため、これは保証できない。しかしながら、完全nワイズ・カバレッジ(例えば、完全ペアワイズ・カバレッジ)を提供するCTDベクトルの初期セット306は、k>nの場合にある程度のkワイズ・カバレッジ(例えば、3ワイズ・カバレッジ)を提供してもよく、よって、選択される特定のCTDベクトルに基づいて、方法600は、選択した失敗テスト・ケースに逆組み合わせ論を提供するただ1つの合格において、または複数の合格後に、kワイズ・エラーを明らかにし得る。
【0074】
再び
図6を参照すると、方法600のブロック616において、1つまたは複数の回帰バケット生成モジュール326のコンピュータ実行可能命令が、元の失敗属性値ペアを含むカルテシアン積空間における全ての可能な組み合わせを含む失敗テスト・ケースの回帰バケット212を生成および出力するために実行される。回帰バケット生成モジュール326は、本発明の1つまたは複数の実施形態において、属性値ペアのエラー生成サブセット324の標識を入力として受信し、検出されたエラーを引き起こしている特定の属性値を含むカルテシアン積空間における全ての可能な組み合わせに対応するテスト・ケースのみを含む、回帰バケット212を判断および出力する。
【0075】
図4の例を再び参照すると、回帰バケット生成モジュール326は、ペアワイズ・エラーを引き起こしている属性「名前」および「色」ならびに対応する属性値「デール」および「青」を入力として受信し、「デール」および「青」を含むカルテシアン積空間における全ての属性値組み合わせを判断し、これらの組み合わせの全てに対応するテスト・ケースを回帰バケット212に投入する。この例では、回帰バケット212は、以下のテスト・ケース、(デール、青、三角)、(デール、青、円)、および(デール、青、四角)を含む。回帰バケット212内のテスト・ケースのそれぞれが、属性「名前」および「色」に対して属性値「デール」および「青」をそれぞれ含み、それらは共に、検出されたペアワイズ・エラーの原因となっており、回帰バケット212内の各テスト・ケースは、失敗することが保証されている。本発明の1つまたは複数の実施形態では、回帰バケット212は、手動によるテスタまたは別の自動デバッグ・アルゴリズムにより使用するために出力され得る。失敗テスト・ケースの回帰バケット212は、エラーが修正されたときにのみ、回帰バケット212に含まれる全てのテスト・ケースが合格するため、検出されたエラーが補正されているかどうかを検証するために使用され得る。よって、回帰バケット212内の任意のテスト・ケースが、エラーを補正するための試みにおいてSUT214に対して行われた修正にも関わらず失敗し続ける場合、これは、エラーが完全に解決されていないことを示す。
【0076】
図7は、本発明の1つまたは複数の実施形態による、SUTをテストするときに経時的な属性値ペアの成功率を用いてテスト・モデルの不備を検出する方法のフローチャートを示す。方法700は、ブロック702において、SUT214をテストするための属性値ペアをモデル化することを含む。モデル化は、方法600において実行されるものと同様であり、テスト・ケースの全ての組み合わせを生成するために使用され得る属性およびそれらの対応する値の辞書を生成する。
【0077】
ブロック704において、nワイズ・カバレッジCTDベクトル生成モジュール304は、モデルを用いてnワイズ・カバレッジでSUT214をテストするために、CTDベクトル306のセットを生成する。本発明の1つまたは複数の実施形態では、CTDベクトル306は、SUT214についてテストされる属性のカルテシアン積空間全体から生成される。本発明の例としての実施形態では、各CTDベクトル306は、SUT214のアーキテクチャ制限に違反する属性値の無効な組み合わせを除外する、縮小テスト空間からのみ選択される。例えば、CTDベクトル生成モジュール304は、SUT214に関連付けられたアーキテクチャ制限を遵守しない組み合わせを識別し除外することによって、属性値ペア302の集合に関連付けられたカルテシアン積空間全体を縮小する。
【0078】
ブロック706において、テスト・ケース202のセットは、CTDベクトル306の初期セットから生成され、方法600のブロック606と同様に実行される。本発明の1つまたは複数の実施形態では、テスト・ケース202を生成および実行することは、1つまたは複数の失敗テスト・ケース202に基づく逆組み合わせ理論を使用して、追加テスト・ケース202を生成することを含み得る。
【0079】
ブロック708において、各テスト・ケース202の結果は、テスト・ケース202の少なくとも所定回数の実行、即ち、テスト・ケース202の同一セットの反復実行に対して記録される。テスト・ケース202の実行回数は、10回、100回、1000回などの所定回数の実行を用いて、または所定の期間、例えば、時間、日、週、月などにわたる実行を用いて、制限され得る。
【0080】
テスト・ケース実行の結果は、バイナリ、即ち、合格または失敗である。それに応じて、SUT214の所与の構成について、いかなる構成変更もなく、テスト・ケース202の結果が複数の実行にわたって変化しないことが予期され得る。しかしながら、前述の通り、隠れ属性のために、SUT214の特定の構成を用いたある実行において合格(または失敗)する同一のテスト・ケースが、同一構成を用いた別の実行において失敗(または合格)することがある。したがって、ブロック710において、テスト・ケース202の結果が、結果を記憶する前に、非バイナリ形式に変換される。
【0081】
テスト・ケース202の結果を非バイナリ形式に変換することは、テスト・ケースによって使用される属性値ペアの成功率を計算することによって実行される。本発明の1つまたは複数の実施形態では、成功率は、成功/失敗テスト・ケースを表すブール結果のベクトルを量子化するために、ハイティング代数などの疑似ブール代数を用いて計算される。本発明の1つまたは複数の実施形態では、テスト・モデルのテスト・ケースによって使用される属性値ペア毎に計算される成功率(即ち、ハイティング値)に基づいて、固有値が計算される。テスト・モデルの計算された成功率の全てが、固有ベクトル内に集合され、固有ベクトルは、次いで固有値を計算するために使用される。各属性値ペアの成功率(または失敗率)(SAV)は、各テスト・ケースの実行に基づいて計算される。よって、属性値ペアの成功率(SAV)は、所与の属性値ペアの経時的な成功率/失敗率を記述する非バイナリ値であり、その場合に、成功率は疑似ブール代数を用いて計算される。属性値ペアを用いたテスト・ケースの複数の実行の結果を含むベクトルは、SAV=f(t1,t2...tn)と量子化され得る。ここで、SAV=属性値ペアの成功率、ti=テスト・ケースiの成功/失敗に基づく1/0、n=テスト・ケース実行回数、およびf=ブール値tiを非バイナリSAVに変換する疑似ブール代数関数である。ここで、nは、属性値ペアを使用するテスト・ケースの数、およびテスト・ケースが実行される回数であってもよい。
【0082】
加えて、テスト・ケース毎の成功率(ST)(または失敗率)もまた、非バイナリ値としてモニタリングおよび記録される。テスト・ケースの成功率(ST)は、経時的なテスト・ケース実行結果のベクトルを量子化するために、疑似ブール代数を用いて計算される。例えば、テスト・ケースの複数の実行の結果を含むベクトルは、ST=g(t1,t2...tn)と量子化され得る。ここで、ST=テスト・ケースの成功率、ti=テスト・ケースiの成功/失敗に基づく1/0、n=テスト・ケース実行回数、およびg=ブール値tiを非バイナリSTに変換する疑似ブール代数関数である。ここで、nは、テスト・ケースが実行される回数であってもよい。本発明の1つまたは複数の実施形態では、テスト・モデルのテスト・ベクトル(即ち、テスト・ケース)毎に計算される成功率(即ち、ハイティング値)に基づいて、固有値が計算される。テスト・モデルの計算された成功率の全てが、固有ベクトル内に集合され、固有ベクトルは、次いで固有値を計算するために使用される。
【0083】
表1および表2は、例としてのテスト・ベクトルを示し、ここで、テストされている属性は、<名前,色,州,年齢>を含み、使用される値は、表1に示されるセットからのものである。これは単なる一例であり、本発明の他の実施形態では、テスト・ベクトルは、異なる属性またはテスト・ベクトル内の異なる数の属性あるいはその両方を含み得ると、理解されたい。また、属性の値は、本明細書に示されるものから変化し得る。表1は、属性値ペア毎の成功率を示し、表2は、テスト・ケース毎の成功率を示す。テスト・ケースの成功率は、テスト・ベクトルの成功率と同一であってもよい。表2の最後の列は、疑似ブール代数の固有ベクトルであり、成功率の全てを含む。固有値は、固有ベクトルの数値表現である。
【0084】
【0085】
【0086】
「隠れ変数」が、SUT214の温度などの、SUT214と同時稼働する他のアプリケーション、ジョブ、またはサービスなどのソフト失敗に対する困難に起因して、テスト・ケースを断続的に失敗させ得ることに留意されたい。「隠れ属性」は、属性の異なる組み合わせを有するテスト・ベクトルを生成するために、モデルに含まれるべき属性である。さらに、「隠れ属性値」は、モデル内に既にある属性をテストするために含まれるべき値である。即ち、属性の組み合わせが変化せず、SUT214をテストするために使用される属性値の組み合わせが変更される。「隠れ値」は、1つまたは複数のテスト・ケースの結果に影響を及ぼす、環境因子/外的因子である。隠れ変数は、隠れ値の種類である。
【0087】
表2の例では、テスト・ベクトル#1によって表された属性値の組み合わせを用いたテスト・ケースが、50%の確率で失敗し、テスト・ベクトル#2および#5が、テスト・ケースが100%の確率で合格する結果となる。テスト・ベクトル#1、#2、および#5は、図示されるように、単一の値だけ互いに異なる。
【0088】
この例のために、属性値<色,黒>および<州,コネチカット>の組み合わせによってテスト・ケースが失敗すると仮定する。もしそうであれば、疑似ブール代数毎に、テスト・ベクトル#2および#5を有するテスト・ケースもまた、成功率50%で失敗するはずであった(ベクトル#1と同一)と見なされ得る。しかし、ここではそうでないため、モデルが、即ち、例えば未知の環境条件によって引き起こされるソフト失敗に対する制御を行わない「隠れ変数」が存在するとみなされ得る。さらに、3つの全てのテスト・ベクトル#1、#2、および#5が結果的に50%の成功率となった場合、追加テスト・ベクトルを生成するために使用されなければならない「隠れ属性」が存在すると見なされ得る。さらにそれでも、1つまたは複数の値を属性の範囲に追加すること、および新たな属性値の経時的な成功率をモニタリングすることによって、1つまたは複数の追加の値を使用することによって成功率閾値が満たされる場合に、「隠れ属性値」が検出され得る。また、隠れ変数が存在し、かつテスト・ケースが実行されると断続的な失敗を引き起こすとき、特定のテスト・ベクトルの成功率は、経時的に変化し得る。
【0089】
ブロック712において、属性値ペアの成功率(SAV)は、カルノー図、ヒートマップ、または属性の傾向を経時的に検出するために分析され得る不均一データ構造の任意の他の形式などの、データ構造に記憶される。各属性が、テストされる異なる数の値を有し得るため、データ構造は不均一である。
【0090】
図8は、本発明の1つまたは複数の実施形態による、属性値ペアの成功率(S
AV)の可視化の例を示す。可視化800は、ヒートマップ、多角形、または成功率(S
AV)の不均一テーブルを可視化する任意の他の表現などの技術を用いて、成功率(S
AV)を記憶するために用いられるデータ構造に基づいて、生成され得る。可視化800は、不均一ヒートマップであり、各正方形802の色またはシェーディングがその正方形802に対応する属性値ペアの成功率(S
AV)を表す。図示される特定の例では、正方形が暗いほど、成功率(S
AV)が低く、逆に、正方形が明るいほど、対応する属性値ペアの成功率(S
AV)が高い。しかしながら、ヒートマップ800は、他の実施形態では異なるルールを用いてシェーディングされ得ると理解されたい。代替的に、または加えて、成功率(S
AV)は、色以外の、可視化の異なる特性を用いて表現されてもよく、例えばサイズが用いられてもよい。さらに、可視化800は2D描写であるが、本発明の他の実施形態では、可視化が、3Dなどの異なる次数を使用し得ると理解されたい。
【0091】
可視化800を用いて、特定範囲の属性を分析することによって、各属性の有効性が、モデルの属性値における深さ不足を明らかにし得る。例えば、可視化800における属性「年齢」が、属性値ペア毎に閾値を超える(または下回る)成功率(SAV)を示す場合、属性をテストするために使用される値の範囲が、発達不十分である場合がある。そうでなければ、追加の値を属性に追加することが、少なくとも所定の閾値によって可視化800(即ち、基礎となる成功率)を変更しない場合、属性は、十分に探索されると見なされる。
【0092】
ブロック714において、成功率は、テスト・モデルまたはデータあるいはその両方の不備を判断するために分析される。不備は、隠れ変数、隠れ属性、または隠れ属性値、あるいはそれらの組み合わせを含み得る。本発明の1つまたは複数の実施形態では、テスト・モデルは、動作され得るテスト・バケットを生成するために使用される。結果を用いて、失敗したテスト・ベクトル毎の逆組み合わせセットが、計算され得る。逆組み合わせ理論は、既知の技術であり、全ての失敗テスト・ベクトルを識別することを容易にする。失敗テスト・ベクトル毎に、逆組み合わせセットが生成される。逆組み合わせセット毎に、SUTをテストおよび診断して失敗テスト・ケースの原因を判断するために、新たなテスト・バケットが生成される。さらに、本発明の1つまたは複数の実施形態では、逆テスト・ケースが動作され、その結果が、根本原因分析を実行するために用いられる。それによって、元のテスト・モデルにおける失敗のソースを特定する結果となる。
【0093】
本発明の1つまたは複数の実施形態では、分析は、テスト・ケース202の成功率(ST)に基づいて固有値および固有ベクトルを計算することを含む。例えば、S=<ST1,ST2...STN>は、テスト・ケース202の経時的な成功率のベクトルを表す。固有値および固有ベクトルは、ベクトルSに対して計算される。
【0094】
本発明の1つまたは複数の実施形態では、固有ベクトルは、線グラフなどの複数の方法で可視化され得る。固有ベクトルおよび固有値は、経時的に、テスト・プロセスの改善および劣化を示し、また、テスト・ケース202の実行#n+1についての焦点も強調する。本発明の1つまたは複数の実施形態では、テスト・ケースの成功率を表す固有ベクトルは、経時的なテスト・モデル・カバレッジを表す単位ベクトルを生成するために使用され得る。さらに、固有ベクトルおよび固有値は、既存のテスト・ケースに対する変更、新たなテスト・ケースの生成、SUT214に対する変更、または任意の他の変更による結果の品質の変化をモニタリング/追跡するために使用され得る。したがって、固有値および固有ベクトルは、SUT214およびテスト環境100が変化すると、テスト・ケース品質の定量化およびモニタリングを容易にし得る。これは、テスト・インフラストラクチャを維持および強化するための新たなメトリックをユーザに提供する。
【0095】
本発明の1つまたは複数の実施形態では、成功率(SAV)は、カルノー図、または可視化800のための任意の他のデータ構造の形式で記憶される。カルノー図の表面極小値および極大値は、それぞれ、現在のモデルによるテストにおける属性値ペアの不備、および堅牢性で逆にカバーされる属性値ペアを識別し得る。本発明の1つまたは複数の実施形態では、テスト環境100は、より多くのリソースまたは異なるリソースが、SUT214を適切にテストし、またはストレスを与える必要があり得ることを示し得る。さらに、複数のテスト・ケース実行にわたって得られた複数のそのような可視化800が、SUT214を査定するために用いられ得る。例えば、可視化800は、SUT214またはテスト・インフラストラクチャ100あるいはその両方がどのくらい成熟し変化したかを示すために、パターンを経時的に隔離するための可視化800の1つまたは複数のバージョンと比較され得る。比較のために用いられる基準バージョンは、SUT214自体を用いて生成される1つまたは複数の可視化800であってもよい。代替的に、または加えて、基準可視化800は、SUT214の異なるインスタンスを用いてオフラインで生成された参照可視化を含み得る。
【0096】
本発明の1つまたは複数の実施形態では、SUT214の各リリース・バージョンにおける可視化800の各セットに対してクラスタリングが実行され、あるクラスタからそれらのピアの移行とは異なる別のクラスタに移行する、個々のマップを識別し得る。例えば、隠れ属性がトリガされると、限局されたホットスポットが移行することがあり、これは、類似属性/テスト範囲を査定して、失敗を引き起こす同一属性が複数のビューの下で表面化するかどうかを判断することに関連する。
【0097】
さらに、分析は、テスト・ベクトル(例えば、表1内のベクトル#1)の値の第1の組み合わせの成功率STが、同一のテスト・ベクトル(例えば、表1内のベクトル#2および#5)の値の他の組み合わせから逸脱するかどうかを判断することを含む。この条件が満たされる場合、隠れ変数は、第1のテスト・ベクトルを使用するテスト・ケース202に関連付けられると見なされ得る。例えば、テスト・ベクトルについての属性値の第1の組み合わせが第1の成功率、例えば50%を有し、かつ属性値の他の全ての組み合わせが第2の成功率、例えば100%を有する場合、第1の組み合わせが、ソフト失敗をトリガすると見なされる。本発明の1つまたは複数の実施形態では、ブロック716において、テスト・ケース202、テスト・ベクトル、およびそのようなソフト失敗をトリガする属性値の組み合わせが、ユーザに通知され得る。
【0098】
追加的に、特定のテスト・ケースの成功率STが、所定回数のテスト実行(または期間)にわたって所定の閾値、例えば50%未満である場合、ブロック718において、1つまたは複数の値を属性値の範囲に追加すること、および新たな属性値の経時的な成功率ST’をモニタリングすることにより1つまたは複数の追加の値を用いて、成功率閾値STが満たされる場合に、「隠れ属性値」が検出され得る。
【0099】
代替的に、または加えて、ブロック718において、隠れ属性値は、全て所定の閾値未満である、属性に関連付けられた属性値ペアのセットに対応する成功率(SAV)のセットに基づいて検出され得る。属性は、次いで、追加の属性値を用いてより多くのテスト・ベクトルを追加すること、および追加の属性値を用いてテスト・ケースを実行することによって、さらに診断され得る。追加の属性値を用いて実行されたテスト・ケースの成功率SAV’が、所定の閾値を満たす場合、隠れ属性値条件が識別されており、隠れ値が発見されている。それに応じてユーザに通知が行われる。
【0100】
成功率閾値が満たされない場合、ブロック720において、隠れ属性が存在するかどうかの判断に基づいて、ユーザに、隠れ属性が通知され得るかまたはSUT214を診断するように通知され得る。即ち、追加の属性は、特定のテスト・ベクトルでテスト・ケースを失敗させている、コード・パスを実行する必要があり得る。
【0101】
図9は、本発明の1つまたは複数の実施形態による、隠れ属性が現在のテスト・モデルに存在するかどうかを判断する方法のフローチャートを示す。方法900は、テスト・ケースの成功率S
Tが所定の閾値、例えば50%未満であることを検出することに応じて、トリガされる。S
T=0%は、テスト・ケースが一貫して失敗していることを示すため、本明細書の全ての例における成功率S
Tは、明示的に述べられた場合を除いて、0%を超えることに留意されたい。ここで、テスト・ケースが断続的に成功および失敗しており、ゆえに、欠陥がSUT214、テスト・ケース、環境(ソフト失敗)、または任意の他の因子にあるかどうかを判断するという技術的課題がある。
【0102】
方法900は、ブロック902において、現在のモデル、テスト・ベクトルからの属性値ペア、および断続的に失敗するテスト・ケース202に基づいて、逆組み合わせテスト・ケースのセット全体を生成することを含む。逆CTDの既知の技術が、テスト・ケースのセットを生成するために使用され得る。生成されるテスト・ケースのセットは、断続的に失敗するテスト・ケース202と同数のテスト・ケースを有し、テスト・ケースの元のセットからのテスト・ケースAと逆組み合わせテスト・ケース内の対応するテスト・ケースA’との間に1対1対応を有する。
【0103】
逆組み合わせセットは、1つの属性値が元のテスト・モデルからの別の値と置換される、変化したテスト・ベクトルのセットとして定義される。最小限の変化の場合、n個のテスト・ベクトルが生成され、ここで、nは、初期失敗テスト・ベクトル内の属性の数である。例えば、失敗したテスト・ベクトルが<アンドリュー,黒,ニューヨーク,20,0>(表2参照)である場合、最大の逆組み合わせセットは、
【0104】
【0105】
この例での最小逆組み合わせセットは、
【0106】
【0107】
ブロック904において、逆組み合わせテスト・ケースのセットが、少なくとも所定の回数実行される。ブロック906において、逆組み合わせテスト・ケースのセットの成功率ST’が、記録および記憶される。逆組み合わせテスト・ケースのセットの成功率ST’は、元のテスト・ケースの成功率と同じ方式で、疑似ブール代数を用いて計算される。
【0108】
ブロック908において、逆組み合わせテスト・ケースの成功率ST’は、断続的に失敗するテスト・ケース、即ち元のテスト・ケースの対応する成功率STと比較される。本発明の1つまたは複数の実施形態では、成功率ST’のベクトルの固有値を成功率STのベクトルの固有値と比較することによって、比較が実行され得る。
【0109】
逆組み合わせテスト・ケース内の失敗テストの全てが、テスト・ケースの元のセットにおけるものと同じ割合で失敗する場合、ブロック910において、テスト・モデルに不具合があると見なされ得る。例えば、2つの固有値が同一である場合、テスト・ケースの2つのセットが、同じ割合で失敗していると見なされる。ブロック912において、この場合にテスト・モデルが診断および改訂される必要があることが、ユーザに通知される。
【0110】
代替的に、ブロック914および916において、逆組み合わせテスト・ケースのセット内のどのテスト・ケースも失敗しない場合、隠れモデル属性がモデルに追加されるべきであると見なされ、それに応じてユーザに通知が行われる。テスト・ケースの失敗率が異なり、かつ逆組み合わせテスト・ケースのセット内のテスト・ケースの少なくともいくつかが失敗する場合、ブロック918において、失敗テスト・ケースの原因を判断するためにSUT214が診断される必要があることが、ユーザに通知される。
【0111】
図10は、本発明の1つまたは複数の実施形態による、隠れ属性を駆動するSUTの部分を識別する方法のフローチャートを示す。ここまで説明した通り、疑似ブール代数、固有ベクトル、および不均一テーブル・ヒートマップを用いることによって、モデルが1つまたは複数の属性、即ち隠れ属性を欠落していることを明らかにするテスト・ケースを識別する助けとなり得る。次の技術的課題は、これらの隠れ属性のどれが所与のモデルのためのものであるかを判断することである。本発明の実施形態は、疑似ブール代数、固有ベクトル、および不均一テーブル・ヒートマップを用いて、テスト・ケースの元のセット内のより低い疑似ブール値に対応するパスを駆動する、追加テスト・ケースを識別および生成することによって、これらの技術的課題に対処する。所定の閾値未満の成功率の値を有する属性値ペアを表す、可視化800のより暗い領域は、モデル内の隠れ属性を明らかにするテスト・ケースを示す。
【0112】
図10の方法1000および
図11の方法1100などの本発明の実施形態は、ブレークポイントを用いてテスト・ケースの成功および失敗動作のコード・パスを追跡して、それらのテスト・ケースを実行する部分、例えばコード・パスを隔離することを容易にする。SUT214の1つまたは複数の部分、例えば、コード・パスは、システム構成およびタイミング・ウィンドウに基づいて隠れ属性を識別するためにさらに調査するための領域として識別および強調される。
【0113】
方法1000は、ブロック1002において、所定の閾値未満の成功率(SAV)を有する属性値ペアのセットを識別することを含む。属性値ペアは、可視化800においてより暗いシェーディングで表されるものであり、可視化800において、成功率(SAV)は正方形のシェーディングを判断するために使用され、SAVが低いほど正方形がより暗くなる。本発明の1つまたは複数の実施形態では、ユーザは、グラフィカル・ユーザ・インターフェース(GUI)を用いてさらに調査されるべき可視化800内の1つまたは複数の正方形を選択する。代替的に、または加えて、ユーザは、閾値より低い(またはより大きい)SAVを有する正方形を選択するために閾値SAVを提供し得る。
【0114】
さらに、ブロック1004において、実行されるテスト・ケース202からのテスト・ケースのサブセットが識別され、サブセットからのテスト・ケースは、属性値ペアの識別されたセットから属性値ペアの少なくとも1つを使用する。テスト・ケースのサブセットを識別することは、テスト・ケース202をスキャンして、識別された属性値ペアのいずれかを用いるテスト・ケースを識別することによって、実行され得る。代替的に、テスト実行エンジン108またはテスト生成器208は、テスト・ケースおよび対応する属性値ペアの記録を保持する。
【0115】
ブロック1006において、テスト・ケースのサブセットに関連付けられたコード・パスが判断される。コード・パスは、サブセット内の各テスト・ケースに関連付けられたフィンガープリント206を用いて判断され得る。
【0116】
ブロック1008において、コード・パスの交差領域が判断される。交差領域は、テスト・ケース202のほとんどの断続的な成功/失敗を引き起こしているSUT214の部分にさらにズームし、または焦点を合わせる。本発明の1つまたは複数の実施形態では、ブロック1010において、コード・パスの交差領域が、SUT214のソース・コードにおいて強調される。
【0117】
本発明の1つまたは複数の実施形態では、ブロック1012において、デバッグ・コードが、この方式で識別されるSUT214の部分を診断するために生成される。デバッグ・コードは、テスト・ケースの断続的な成功/失敗を引き起こすソフト失敗または任意の他の不具合に適用および診断するためにユーザに提供され得る。例えば、SUT214がz/OS(登録商標)に基づく場合、SLIPなどのコマンド、または性能関連問題を調査するために使用される任意の他のそのようなコマンドが、デバッグ・コードを生成するために使用され得る。SUT214が任意の他のアーキテクチャまたはオペレーティング・システムを使用している場合に、そのアーキテクチャからの性能関連コマンドが、デバッグ・コードを生成するために使用されると理解されたい。
【0118】
図11は、本発明の1つまたは複数の実施形態による、隠れ属性を駆動するSUTの部分を識別する方法のフローチャートを示す。方法1100は、ブロック1102において、所定の閾値未満の成功率(S
AV)を有する属性値ペアのセットを識別することを含む。属性値ペアは、可視化800においてより暗いシェーディングで表されるものであり、可視化800において、成功率(S
AV)は正方形のシェーディングを判断するために使用され、S
AVが低いほど正方形がより暗くなる。本発明の1つまたは複数の実施形態では、ユーザは、グラフィカル・ユーザ・インターフェース(GUI)を用いてさらに調査されるべき可視化800内の1つまたは複数の正方形を選択する。代替的に、または加えて、ユーザは、閾値より低い(またはより大きい)S
AVを有する正方形を選択するために閾値S
AVを提供し得る。
【0119】
さらに、ブロック1104において、実行されるテスト・ケース202からのテスト・ケースのサブセットが識別され、サブセットからのテスト・ケースは、属性値ペアの識別されたセットから属性値ペアの少なくとも1つを使用する。テスト・ケースのサブセットを識別することは、テスト・ケース202をスキャンして、識別された属性値ペアのいずれかを用いるテスト・ケースを識別することによって、実行され得る。代替的に、テスト実行エンジン108またはテスト生成器208は、テスト・ケースおよび対応する属性値ペアの記録を保持する。
【0120】
テスト・ケースのサブセット内のテスト・ケース毎に、ブロック1106において、テスト・ケースの成功した実行に関連付けられる第1のコード・パスを判断し、テスト・ケースの失敗した実行に関連付けられる第2のコード・パスを判断する。コード・パスは、サブセット内の各テスト・ケースに関連付けられたフィンガープリント206を用いて判断され得る。
【0121】
ブロック1108において、第1のコード・パスおよび第2のコード・パスは、異なるコード・パスの部分を識別するために比較され、それらの部分は、ユーザによる検査のために強調される。コード・パスは、本発明の1つまたは複数の実施形態において、コード・パス内にあるソース・コードを比較するために、テキスト比較を用いて比較され得る。コード・パスの部分の強調は、マークおよび強調されるべきソース・コードの部分を識別するコマンドをグラフィカル・ユーザ・インターフェースに送信することによって、実行され得る。
【0122】
本発明の1つまたは複数の実施形態では、ブロック1110において、デバッグ・コードが、この方式で識別されるSUT214の部分を診断するために生成される。デバッグ・コードは、テスト・ケースの断続的な成功/失敗を引き起こすソフト失敗または任意の他の不具合に適用および診断するためにユーザに提供され得る。例えば、SUT214がz/OS(登録商標)に基づく場合、SLIPなどのコマンド、または性能関連問題を調査するために使用される任意の他のそのようなコマンドが、デバッグ・コードを生成するために使用され得る。SUT214が任意の他のアーキテクチャまたはオペレーティング・システムを使用している場合に、そのアーキテクチャからの性能関連コマンドが、デバッグ・コードを生成するために使用されると理解されたい。
【0123】
本発明の実施形態は、したがって、それらの領域が、可視化800の他の領域と比較して、テスト・ケースをより断続的に成功/失敗させる不具合を強調するため、可視化800内のより暗い(またはより明るい)領域にアーティスティック・テストを集中させることを容易にする。本発明の実施形態は、ブレークポイント、フィンガープリント、または他の技術を用いて、弱点が示される可視化800に基づいて、さらに調査されるべきSUT214のソース・コード内の領域を強調することを、さらに容易にする。
【0124】
ハイティング代数などの疑似ブール代数を利用して、テスト・システム100は、テスト・ケースの成功率を量子化するとともに、テスト・ケースの結果に一貫して影響を及ぼす隠れ変数をカプセル化し得る。これによって、リソースを調整し得るか、または新たなテスト・インフラストラクチャがそれに従って開発され得るように、テスト・インフラストラクチャ自体以上の因子に起因してテスト・ケースが失敗しているときにユーザがより確実に識別することが可能となる。この強化された成功メトリックは、SUT214の安定性テストの効率および確実性を改善するために使用され得る。
【0125】
ここで
図12を参照すると、コンピュータ・システム1200は、概して、本発明の実施形態に従って示されている。コンピュータ・システム1200は、本明細書に記載されるように、様々な通信技術を利用する任意の数および組み合わせのコンピューティング・デバイスおよびネットワークを含むかまたは利用し、あるいはその両方である、電子コンピュータ・フレームワークであり得る。コンピュータ・システム1200は、異なるサービスに変更し、またはそれ以外から独立していくつかの特徴を再構成する能力を用いて、容易にスケール可能であり、拡張可能であり、モジュール式であり得る。コンピュータ・システム1200は、例えば、サーバ、デスクトップ・コンピュータ、ラップトップ・コンピュータ、タブレット・コンピュータ、またはスマートフォンであってもよい。いくつかの例では、コンピュータ・システム1200は、クラウド・コンピューティング・ノードであってもよい。コンピュータ・システム1200は、コンピュータ・システムによって実行されている、プログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈において説明され得る。概して、プログラム・モジュールは、特定のタスクを実行し、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、ロジック、データ構造などを含み得る。コンピュータ・システム1200は、通信ネットワークを通してリンクされたリモート処理デバイスによってタスクが実行される、分散型クラウド・コンピューティング環境において実施され得る。分散型クラウド・コンピューティング環境では、プログラム・モジュールが、メモリ記憶デバイスを含むローカルおよびリモート両方のコンピュータ・システム記憶媒体に位置し得る。
【0126】
図12に示されるように、コンピュータ・システム1200は、1つまたは複数の中央処理装置(CPU)1201a、1201b、1201cなど(まとめて、または概してプロセッサ1201と呼ばれる)を有する。プロセッサ1201は、シングルコア・プロセッサ、マルチコア・プロセッサ、コンピューティング・クラスタ、または任意の数の他の構成であってもよい。プロセッサ1201は、処理回路とも呼ばれ、システム・バス1202を介してシステム・メモリ1203および様々な他のコンポーネントに連結される。システム・メモリ1203は、読み取り専用メモリ(ROM)1204およびランダム・アクセス・メモリ(RAM)1205を含み得る。ROM1204は、システム・バス1202に連結され、基本入出力システム(BIOS)を含んでもよく、BIOSは、コンピュータ・システム1200のある基本機能を制御する。RAMは、プロセッサ1201により使用するために、システム・バス1202に連結された読み取り書き込み用メモリである。システム・メモリ1203は、動作中に上記命令の動作のための一時メモリ空間を提供する。システム・メモリ1203は、ランダム・アクセス・メモリ(RAM)、読み取り専用メモリ、フラッシュ・メモリ、または任意の他の適当なメモリ・システムを含み得る。
【0127】
コンピュータ・システム1200は、システム・バス1202に連結された入力/出力(I/O)アダプタ1206および通信アダプタ1207を含む。I/Oアダプタ1206は、ハード・ディスク1208または任意の他の類似のコンポーネントあるいはその両方と通信するスモール・コンピュータ・システム・インターフェース(SCSI)・アダプタであってもよい。I/Oアダプタ1206およびハード・ディスク1208は、本明細書では大規模ストレージ1210とまとめて呼ばれる。
【0128】
コンピュータ・システム1200上で実行するためのソフトウェア1211は、大規模ストレージ1210に記憶され得る。大規模ストレージ1210は、プロセッサ1201により読み取り可能な有形記憶媒体の例である。ソフトウェア1211は、様々な図面に関して本明細書で以下に記載されるように、コンピュータ・システム1200を動作させる、プロセッサ1201による実行のための命令として記憶される。コンピュータ・プログラム製品の例およびそのような命令の実行は、本明細書でより詳細に論じられる。通信アダプタ1207は、システム・バス1202をネットワーク1212と相互接続し、ネットワーク1212は、外部ネットワークであってもよく、コンピュータ・システム1200が他のそのようなシステムと通信することを可能にする。一実施形態では、システム・メモリ1203および大規模ストレージ1210の一部が、オペレーティング・システムを集合的に記憶し、オペレーティング・システムは、
図12に示される様々なコンポーネントの機能を協調させるための、IBM(登録商標) Corporationのz/OS(登録商標)またはAIX(登録商標)オペレーティング・システムなどの任意の適当なオペレーティング・システムであってもよい。
【0129】
追加入力/出力デバイスが、ディスプレイ・アダプタ1215およびインターフェース・アダプタ1216を介してシステム・バス1202に接続されるように示される。一実施形態では、アダプタ1206、1207、1215、および1216は、中間バス・ブリッジ(図示せず)を介してシステム・バス1202に接続される1つまたは複数のI/Oバスに接続され得る。ディスプレイ1219(例えば、スクリーンまたはディスプレイ・モニタ)は、ディスプレイ・アダプタ1215によってシステム・バス1202に接続され、ディスプレイ・アダプタ1215は、グラフィックス集約型アプリケーションおよびビデオ・コントローラの性能を改善するためのグラフィックス・コントローラを含み得る。キーボード1221、マウス1222、スピーカ1223などが、インターフェース・アダプタ1216を介してシステム・バス1202に相互接続され得る。インターフェース・アダプタ1216は、例えば複数のデバイス・アダプタを単一の集積回路に統合するスーパーI/Oチップを含み得る。ハード・ディスク・コントローラ、ネットワーク・アダプタ、およびグラフィックス・アダプタなどの周辺デバイスを接続するための適当なI/Oバスは、典型的には、ペリフェラル・コンポーネント・インターコネクト(PCI)などの共通プロトコルを含む。よって、
図12に構成されるように、コンピュータ・システム1200は、プロセッサ1201の形態の処理ケイパビリティ、システム・メモリ1203および大規模ストレージ1210を含むストレージ・ケイパビリティ、キーボード1221およびマウス1222などの入力手段、ならびにスピーカ1223およびディスプレイ1219を含む出力ケイパビリティを含む。
【0130】
いくつかの実施形態では、通信アダプタ1207は、特にインターネット・スモール・コンピュータ・システム・インターフェースなどの任意の適当なインターフェースまたはプロトコルを用いてデータを送信し得る。ネットワーク1212は、特に、セルラー・ネットワーク、無線ネットワーク、ワイド・エリア・ネットワーク(WAN)、ローカル・エリア・ネットワーク(LAN)、またはインターネットであってもよい。外部コンピューティング・デバイスは、ネットワーク1212を通してコンピュータ・システム1200に接続し得る。いくつかの例では、外部コンピューティング・デバイスは、外部ウェブサーバまたはクラウド・コンピューティング・ノードであってもよい。
【0131】
図12のブロック図は、コンピュータ・システム1200が
図12に示されるコンポーネントの全てを含むことを示すように意図されないことを理解されたい。むしろ、コンピュータ・システム1200は、
図12に示されない、任意の適切な、より少ないまたは追加のコンポーネント(例えば、追加メモリ・コンポーネント、組み込みコントローラ、モジュール、追加ネットワーク・インターフェースなど)を含み得る。さらに、コンピュータ・システム1200に関して本明細書に記載された実施形態は、任意の適切なロジックで実施され得る。ロジックは、本明細書に参照されるように、様々な実施形態において、任意の適当なハードウェア(例えば、特にプロセッサ、組み込みコントローラ、もしくは特定用途向け集積回路)、ソフトウェア(例えば、特にアプリケーション)、ファームウェア、またはハードウェア、ソフトウェア、およびファームウェアの任意の適当な組み合わせを含み得る。
【0132】
本開示は、クラウド・コンピューティングについての詳細な説明を含むが、本明細書に列挙する教示の実施態様は、クラウド・コンピューティング環境に限定されないと理解されたい。むしろ、本発明の実施形態は、現在既知の、または後に開発される任意の他の種類のコンピューティング環境と併せて実装されることが可能である。
【0133】
クラウド・コンピューティングは、最小の管理労力またはサービス・プロバイダとの対話で迅速に供給され、解放され得る、構成可能なコンピューティング・リソース(例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想機械、およびサービス)の共有プールへの便利なオンデマンド・ネットワーク・アクセスを可能にするためのサービス配信のモデルである。このクラウド・モデルは、少なくとも5つの特性、少なくとも3つのサービス・モデル、および少なくとも4つの展開モデルを含み得る。
【0134】
特性は、以下の通りである。
オンデマンド・セルフサービス:クラウド消費者は、サービス・プロバイダと人との対話を必要とすることなく、必要に応じて自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング・ケイパビリティを一方的に供給し得る。
幅広いネットワーク・アクセス:ケイパビリティは、ネットワーク上で利用可能であり、異種シン・クライアントまたはシック・クライアント・プラットフォーム(例えば、携帯電話、ラップトップ、およびPDA)による使用を促進する標準的なメカニズムを通してアクセスされる。
リソースの共用:プロバイダのコンピューティング・リソースが、マルチテナント型モデルを使用して複数の消費者にサービスするためにプールされ、異なる物理リソースおよび仮想リソースが要求に従って動的に割り当ておよび再割り当てされる。消費者が、概して、提供されるリソースの正確な場所に対する制御または知識を有しないが、より高い抽象レベル(例えば、国、州、またはデータセンタ)において場所を指定することが可能であり得るという点において、位置独立の意味がある。
迅速な順応性:ケイパビリティは、場合によっては自動的に、即座にスケール・アウトするように迅速かつ弾力的に供給され、即座にスケール・インするように迅速に解放され得る。消費者に対しては、供給に利用可能なケイパビリティが、多くの場合無制限であるように見え、いつでも任意の量で購入可能である。
サービスが計測可能であること:クラウド・システムは、サービスの種類(例えば、ストレージ、処理、帯域幅、アクティブ・ユーザ・アカウント)に適したある抽象レベルにおいて計測ケイパビリティを活用することによって、リソース使用を自動的に制御し、最適化する。リソース使用量は、モニタリングされ、制御され、報告されて、利用サービスのプロバイダおよび消費者の両方に透明性をもたらし得る。
【0135】
サービス・モデルは、以下の通りである。
サービスとしてのソフトウェア(SaaS):消費者に提供されるケイパビリティは、クラウド・インフラストラクチャ上で実行中のプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース(例えば、ウェブ・ベースの電子メール)を通して、様々なクライアント・デバイスからアクセス可能である。消費者は、限定されたユーザ固有アプリケーションの構成設定は例外である可能性があるが、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または個々のアプリケーション・ケイパビリティでさえも含む、基礎となるクラウド・インフラストラクチャを管理または制御しない。
サービスとしてのプラットフォーム(PaaS):消費者に提供されるケイパビリティは、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、消費者が作成したアプリケーションまたは消費者が取得したアプリケーションを、クラウド・インフラストラクチャ上に展開することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎的なクラウド・インフラストラクチャを管理または制御しないが、展開されたアプリケーション、および、可能な限りアプリケーション・ホスティング環境構成に対して制御を行う。
サービスとしてのインフラストラクチャ(IaaS):消費者に提供されるケイパビリティは、処理、ストレージ、ネットワーク、ならびに消費者がオペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアを展開および実行することが可能な、他の基本コンピューティング・リソースを供給することである。消費者は、基礎となるクラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、ストレージ、展開されたアプリケーションに対して制御を行い、かつ可能な限り選択ネットワーキング・コンポーネント(例えば、ホスト・ファイアウォール)の限定的な制御を行う。
【0136】
展開モデルは、以下の通りである。
プライベート・クラウド:クラウド・インフラストラクチャは、組織のためだけに運用される。クラウド・インフラストラクチャは、その組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスに存在し得る。
コミュニティ・クラウド:クラウド・インフラストラクチャは、複数の組織によって共有され、共有の関心事(例えば、任務、セキュリティ要件、ポリシー、およびコンプライアンスの考慮事項)を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、その組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスに存在し得る。
パブリック・クラウド:クラウド・インフラストラクチャは、一般公衆または大きな業界団体に利用可能とされ、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド:クラウド・インフラストラクチャは、一意なエンティティのままであるが、データおよびアプリケーション・ポータビリティを可能にする標準化技術または独自技術(例えば、クラウド間のロード・バランシングのためのクラウド・バースティング)によって結合された、2つ以上のクラウド(プライベート、コミュニティ、またはパブリック)の合成物である。
【0137】
クラウド・コンピューティング環境は、無国籍、低結合、モジュール性、および意味相互運用性を中心としたサービス指向型である。クラウド・コンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。
【0138】
ここで
図13を参照すると、例示的なクラウド・コンピューティング環境50が示されている。図示するように、クラウド・コンピューティング環境50は、クラウド消費者によって使用されるローカル・コンピューティング・デバイス、例えば、携帯情報端末(PDA)もしくは携帯電話54A、デスクトップ・コンピュータ54B、ラップトップ・コンピュータ54C、または自動車コンピュータ・システム54N、あるいはそれらの組み合わせが通信し得る、1つまたは複数のクラウド・コンピューティング・ノード10を含む。ノード10は、互いに通信し得る。それらは、上述のようなプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、もしくはハイブリッド・クラウド、またはそれらの組み合わせなどの、1つまたは複数のネットワーク内で物理的または仮想的にグループ化され得る(図示せず)。これによって、クラウド・コンピューティング環境50が、インフラストラクチャ、プラットフォーム、またはソフトウェア、あるいはそれらの組み合わせを、クラウド消費者がローカル・コンピューティング・デバイス上でリソースを維持する必要がないサービスとして提案することが可能となる。
図13に示されるコンピューティング・デバイス54A~Nの種類は、単なる例示であることを意図し、コンピューティング・ノード10およびクラウド・コンピューティング環境50は、任意の種類のネットワークまたはネットワーク・アドレス可能な接続あるいはその両方を経て(例えば、ウェブ・ブラウザを用いて)、任意の種類のコンピュータ化デバイスと通信し得ると理解されたい。
【0139】
ここで
図14を参照すると、クラウド・コンピューティング環境50(
図13)によって提供される機能抽象層のセットが示されている。
図14に示されるコンポーネント、層、および機能は、単なる例示であるように意図され、本発明の実施形態は、それらに限定されないと、予め理解されたい。図示されるように、以下の層および対応する機能が提供される。
【0140】
ハードウェア層およびソフトウェア層60は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例は、メインフレーム61、RISC(Reduced Instruction Set Computer)アーキテクチャ・ベース・サーバ62、サーバ63、ブレード・サーバ64、記憶デバイス65、ならびにネットワークおよびネットワーキング・コンポーネント66を含む。いくつかの実施形態において、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア67およびデータベース・ソフトウェア68を含む。
【0141】
仮想化層70は、仮想エンティティの以下の例、仮想サーバ71、仮想ストレージ72、仮想プライベート・ネットワークを含む仮想ネットワーク73、仮想アプリケーションおよびオペレーティング・システム74、ならびに仮想クライアント75が提供され得る、抽象層を提供する。
【0142】
一例では、管理層80は、後述の機能を提供し得る。リソース供給81は、クラウド・コンピューティング環境内でタスクを実行するために利用される、コンピューティング・リソースおよび他のリソースの動的な調達を提供する。測定および価格設定82は、リソースが、クラウド・コンピューティング環境内で利用され、これらのリソースの消費に対して課金または請求されるときに、コスト追跡を提供する。1つの例では、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含み得る。セキュリティは、データおよび他のリソースについての保護だけでなく、クラウド消費者およびタスクのための本人確認を提供する。ユーザ・ポータル83は、消費者およびシステム管理者にクラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル管理84は、要求されるサービス・レベルが満たされるように、クラウド・コンピューティング・リソース割り当ておよび管理を提供する。サービス水準合意(SLA)計画および遂行85は、SLAに従って将来の要件が予期されるクラウド・コンピューティング・リソースの事前配置および調達を提供する。
【0143】
ワークロード層90は、クラウド・コンピューティング環境が利用され得る機能性の例を提供する。この層から提供され得るワークロードおよび機能の例は、マッピングおよびナビゲーション91、ソフトウェア開発およびライフサイクル管理92、仮想クラスルーム教育配信93、データ解析処理94、トランザクション処理95、ならびにテスト96を含む。
【0144】
本発明の1つまたは複数の実施形態では、コンピュータ・システムは、SUT214がコンピュータ・システムによって使用されているコンピュータ・プログラムまたはハードウェア・コンポーネントである環境100であってもよい。本発明の1つまたは複数の実施形態では、コンピュータ・システムは、SUT214であってもよく、SUT214は、サーバ・クラスタの一部である。
【0145】
本発明は、任意の可能な統合の技術的詳細レベルにおけるシステム、方法、またはコンピュータ・プログラム製品、あるいはそれらの組み合わせであってもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令をその上に有する、コンピュータ可読記憶媒体(または複数の媒体)を含み得る。
【0146】
コンピュータ可読記憶媒体は、命令実行デバイスにより使用するための命令を保持および記憶し得る有形デバイスであり得る。コンピュータ可読記憶媒体は、例えば、電子記憶デバイス、磁気記憶デバイス、光学記憶デバイス、電磁気記憶デバイス、半導体記憶デバイス、または前述したものの任意の適当な組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な実施例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ(RAM)、読み取り専用メモリ(ROM)、消去可能プログラマブル読み取り専用メモリ(EPROMまたはフラッシュ・メモリ)、静的ランダム・アクセス・メモリ(SRAM)、ポータブル・コンパクト・ディスク読み取り専用メモリ(CD-ROM)、デジタル・バーサタイル・ディスク(DVD)、メモリ・スティック(登録商標)、フロッピー(登録商標)・ディスク、パンチカードまたは命令をその上に記録させる溝内の隆起構造などの機械的に符号化されたデバイス、および前述したものの任意の適当な組み合わせを含む。本明細書で用いられるコンピュータ可読記憶媒体は、電波もしくは他の自由伝播する電磁波、導波管もしくは他の送信媒体を通って伝播する電磁波(例えば、光ファイバ・ケーブルを通過する光パルス)、または電線を通って送信される電気信号などの、一過性信号それ自体であると解釈されるべきではない。
【0147】
本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング/処理デバイスに、あるいはネットワーク、例えば、インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくは無線ネットワーク、またはそれらの組み合わせを介して外部コンピュータまたは外部記憶デバイスに、ダウンロードされ得る。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、またはエッジ・サーバ、あるいはそれらの組み合わせを含み得る。各コンピューティング/処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、コンピュータ可読プログラム命令をネットワークから受信し、それぞれのコンピューティング/処理デバイス内のコンピュータ可読記憶媒体の記憶用にコンピュータ可読プログラム命令を転送する。
【0148】
本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ(ISA)命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用の構成データ、またはSmalltalk(登録商標)、C++などのオブジェクト指向プログラミング言語、および「C」プログラミング言語もしくは類似のプログラミング言語などの手続き型プログラミング言語を含む、1つもしくは複数のプログラミング言語の任意の組み合わせで書かれたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で完全に、ユーザのコンピュータ上で部分的に、スタンドアロン・ソフトウェア・パッケージとして、ユーザのコンピュータ上で部分的にかつリモート・コンピュータ上で部分的に、またはリモート・コンピュータもしくはサーバ上で完全に、実行してもよい。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク(LAN)もしくはワイド・エリア・ネットワーク(WAN)を含む任意の種類のネットワークを通してユーザのコンピュータに接続されてもよく、または、接続は、(例えば、インターネット・サービス・プロバイダを用いてインターネットを通して)外部コンピュータに対して行われてもよい。いくつかの実施形態では、例えば、プログラマブル論理回路、フィールド・プログラマブル・ゲート・アレイ(FPGA)、またはプログラマブル・ロジック・アレイ(PLA)を含む電子回路は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路を個別化することによって、コンピュータ可読プログラム命令を実行し得る。
【0149】
本発明の態様は、本発明の実施形態による、方法、装置(システム)、およびコンピュータ・プログラム製品のフローチャート図またはブロック図あるいはその両方を参照して、本明細書において説明される。フローチャート図またはブロック図あるいはその両方の各ブロック、およびフローチャート図またはブロック図あるいはその両方のブロックの組み合わせが、コンピュータ可読プログラム命令によって実施され得ると理解されたい。
【0150】
コンピュータまたは他のプログラマブル・データ処理装置のプロセッサによって実行する命令が、フローチャートまたはブロック図あるいはその両方の1つまたは複数のブロックにおいて指定される機能/動作を実施する手段を作成するように、これらのコンピュータ可読プログラム命令は、汎用コンピュータ、専用コンピュータ、または機械を製造するための他のプログラマブル・データ処理装置のプロセッサに提供されてもよい。命令が記憶されたコンピュータ可読記憶媒体が、フローチャートまたはブロック図あるいはその両方の1つまたは複数のブロックにおいて指定される機能/動作の態様を実施する命令を含む製品を含むように、これらのコンピュータ可読プログラム命令は、また、コンピュータ、プログラマブル・データ処理装置、または他のデバイス、あるいはそれらの組み合わせに特定の方式で機能するように指示し得る、コンピュータ可読記憶媒体に記憶されてもよい。
【0151】
コンピュータ、他のプログラマブル装置、または他のデバイス上で実行する命令が、フローチャートまたはブロック図あるいはその両方の1つまたは複数のブロックにおいて指定される機能/動作を実施するように、コンピュータ可読プログラム命令は、また、コンピュータ、他のプログラマブル装置、または他のデバイス上で一連の動作ステップを実行させてコンピュータ実施プロセスを生み出すために、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードされてもよい。
【0152】
図面中のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の考えられる実施態様のアーキテクチャ、機能性、および動作を例示する。この点に関して、フローチャートまたはブロック図内の各ブロックは、指定された論理機能を実施するための1つまたは複数の実行可能命令を含む、モジュール、セグメント、または命令の一部を表し得る。いくつかの代替実施態様において、ブロック内に記載された機能は、図面中に記載された順序以外で発生してもよい。例えば、連続して示される2つのブロックが、実際には、実質的に同時に実行されてもよく、または、ブロックが、関係する機能性次第で逆の順序で実行されることがあってもよい。ブロック図またはフローチャート図あるいはその両方の各ブロック、およびブロック図またはフローチャート図あるいはその両方におけるブロックの組み合わせが、指定された機能もしくは動作を実行し、または専用ハードウェアおよびコンピュータ命令の組み合わせを実行する専用ハードウェア・ベース・システムによって実施され得ることにも留意されたい。
【0153】
本発明の様々な実施形態の説明は、例示の目的で提示されているが、網羅的であること、または開示される実施形態に限定することを意図するものではない。多くの修正および変形が、説明された実施形態の範囲および思想から逸脱することなく当業者には明らかであろう。本明細書で使用される用語は、実施形態の原理、実際の用途、もしくは市場で発見される技術を超える技術的改善を最もよく説明するため、または他の当業者が本明細書で説明された実施形態を理解できるようにするために、選択された。
【0154】
本発明の様々な実施形態が、関連する図面を参照して本明細書において説明される。本発明の代替実施形態は、この発明の範囲から逸脱することなく考案され得る。様々な接続および位置関係(例えば、上、下、隣接など)が、以下の説明および図面における要素間で述べられている。これらの接続または位置関係あるいはその両方が、特段の指定がない限り、直接または間接であってもよく、本発明は、この点に関して限定することを意図するものではない。したがって、要素の連結は、直接連結または間接連結のいずれかを指してもよく、要素間の位置関係は、直接または間接の位置関係であってもよい。さらに、本明細書で説明される様々なタスクおよび処理ステップは、本明細書で詳細に説明されない追加ステップまたは機能性を有する、より包括的な手続きまたはプロセスに組み込まれ得る。
【0155】
以下の定義および略称は、特許請求の範囲および明細書の解釈のために使用されるものとする。本明細書で使用される、「備える(comprises)」、「備えている(comprising)」、「含む(includes)」、「含んでいる(including)」、「有する(has)」、「有している(having)」、「包含する(contains)」、もしくは「包含している(containing)」という用語、またはそれらの任意の他の変形は、非排他的包含を含むように意図するものである。例えば、要素のリストを含む合成物、混合物、プロセス、方法、物品、または装置は、必ずしもそれらの要素だけに限定されず、明示的に列挙されない他の要素、またはそのような合成物、混合物、プロセス、方法、物品、もしくは装置に固有の他の要素を含み得る。
【0156】
追加的に、「例示的」という用語は、「例、事例、または例示として機能すること」を意味するために、本明細書において使用される。本明細書において「例示的」と説明される任意の実施形態または設計は、必ずしも他の実施形態または設計よりも好適または有利であると解釈されるべきではない。「少なくとも1つの」および「1つまたは複数の」という用語は、1以上の任意の整数、即ち、1、2、3、4などを含むように理解され得る。「複数の」という用語は、2以上の任意の整数、即ち、2、3、4、5などを含むように理解され得る。「接続」という用語は、間接「接続」および直接「接続」の両方を含み得る。
【0157】
「約」、「実質的に」、「ほぼ」という用語およびそれらの変形は、本出願の出願時点に入手可能な機器に基づく特定の数量の測定値に関連する誤差の程度を含むことを意図するものである。例えば、「約」は、所与の値の±8%、または5%、または2%の範囲を含み得る。
【0158】
簡潔さのために、本発明の態様を作成し使用することに関連する従来技術は、本明細書において詳細に説明されるとは限らない。特に、本明細書で説明される様々な技術的特徴を実施するコンピューティング・システムおよび特定のコンピュータ・プログラムの様々な態様は、周知である。したがって、簡潔にするために、多くの従来の実施態様の詳細は、本明細書で簡潔に述べられるだけであり、あるいは周知のシステムもしくはプロセスまたはその両方の詳細を提供することなく完全に省略される。
【手続補正書】
【提出日】2023-06-20
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
テスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法であって、
前記SUTへの入力を属性値ペアの集合としてモデル化することと、
前記属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率(S
AV)を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
選択される前記属性のための追加の値を含むテスト・ベクトルの第2のセットを生成することと、
前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第2のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第2の非バイナリ成功率(S
AV’)を属性値ペア毎に記録することと、
前記属性を含む前記属性値ペアのセットに対応する第2の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知することと、
を含む、方法。
【請求項2】
前記非バイナリ成功率S
AVが、疑似ブール代数を用いて計算される、請求項1に記載の方法。
【請求項3】
前記属性を含む前記属性値ペアのセットに対応する前記第2の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、請求項1に記載の方法。
【請求項4】
ソフト失敗が、前記SUTの1つまたは複数の動作条件によって引き起こされる、請求項3に記載の方法。
【請求項5】
前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項1に記載の方法。
【請求項6】
前記カルテシアン積空間が、前記SUTのアーキテクチャ制限に基づいてさらに縮小される、請求項5に記載の方法。
【請求項7】
前記アーキテクチャ制限が、第2の属性が特定の属性値を有する場合に第1の属性が1つもしくは複数の候補属性値をとることができないという要件、前記第2の属性が前記特定の属性値を有する場合に前記第1の属性が特定の候補属性値をとらなければならないという要件、または前記第2の属性が前記特定の属性値を有する場合に第3の属性を導入するための要件のうちの少なくとも1つを含む、請求項6に記載の方法。
【請求項8】
システムであって、
メモリと、
前記メモリに連結されたプロセッサであって、前記プロセッサが、テスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法を実行するように構成され、前記方法が、
前記SUTへの入力を属性値ペアの集合としてモデル化することと、
前記属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率(S
AV)を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
選択される前記属性のための追加の値を含むテスト・ベクトルの第2のセットを生成することと、
前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第2のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第2の非バイナリ成功率(S
AV’)を属性値ペア毎に記録することと、
前記属性を含む前記属性値ペアのセットに対応する第2の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知すること、および前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することと、
を含む、前記プロセッサと、
を備える、システム。
【請求項9】
前記非バイナリ成功率S
AVが、疑似ブール代数を用いて計算される、請求項8に記載のシステム。
【請求項10】
前記方法が、前記属性を含む前記属性値ペアのセットに対応する前記第2の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することをさらに含む、請求項8に記載のシステム。
【請求項11】
ソフト失敗が、前記SUTの1つまたは複数の動作条件によって引き起こされる、請求項10に記載のシステム。
【請求項12】
前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項8に記載のシステム。
【請求項13】
前記カルテシアン積空間が、前記SUTのアーキテクチャ制限に基づいてさらに縮小される、請求項12に記載のシステム。
【請求項14】
前記アーキテクチャ制限が、第2の属性が特定の属性値を有する場合に第1の属性が1つもしくは複数の候補属性値をとることができないという要件、前記第2の属性が前記特定の属性値を有する場合に前記第1の属性が特定の候補属性値をとらなければならないという要件、または前記第2の属性が前記特定の属性値を有する場合に第3の属性を導入するための要件のうちの少なくとも1つを含む、請求項13に記載のシステム。
【請求項15】
プロセッサによる実行時にテスト対象システム(SUT)をテストするときに欠陥を検出および限局する方法を前記プロセッサに実行させる
、コンピュータ・プログラ
ムであって
、
前記SUTへの入力を属性値ペアの集合としてモデル化することと、
前記属性値ペアによって表されたテスト空間の完全nワイズ・カバレッジを提供するテスト・ベクトルの初期セットを生成することと、
前記テスト・ベクトルの初期セットからテスト・ケースのセットを生成することと、
前記テスト・ケースのセットを実行して実行結果のセットを取得することであって、前記実行結果が、テスト・ケースが成功したかまたは失敗したかをバイナリ形式で示し、前記テスト・ケースのセットが、複数回実行される、前記実行結果のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて非バイナリ成功率(S
AV)を属性値ペア毎に更新することであって、属性値ペアの前記非バイナリ成功率が、前記属性値ペアを使用する各テスト・ケースの実行結果に基づく、前記更新することと、
属性を含む属性値ペアのセットに対応する成功率のセットが全て所定の閾値未満であることに応じて前記属性を選択することと、
選択される前記属性のための追加の値を含むテスト・ベクトルの第2のセットを生成することと、
前記テスト・ケースのセットを実行して、前記テスト・ベクトルの第2のセットを用いて実行結果の第2のセットを取得することであって、前記テスト・ケースのセットが、少なくとも所定の回数実行される、前記実行結果の第2のセットを取得することと、
前記テスト・ケースのセットの実行毎に、前記実行結果に基づいて第2の非バイナリ成功率(S
AV’)を属性値ペア毎に記録することと、
前記属性を含む前記属性値ペアのセットに対応する第2の成功率のセットが前記所定の閾値を満たすことに応じて、検出された前記属性のための前記追加の値をユーザに通知すること、および前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することと、
を
実行させる、コンピュータ・プログラ
ム。
【請求項16】
前記非バイナリ成功率S
AVが、疑似ブール代数を用いて計算される、請求項15に記載のコンピュータ・プログラ
ム。
【請求項17】
前記方法が、前記属性を含む前記属性値ペアのセットに対応する前記第2の成功率のセットが前記所定の閾値を満たさないことに応じて、前記属性値ペアのセットを使用する1つまたは複数のテスト・ケースの識別を前記ユーザに出力することであって、前記1つまたは複数のテスト・ケースが、前記SUTに関連付けられたソフト失敗を診断するために使用される、前記出力することをさらに
実行させる、請求項15に記載のコンピュータ・プログラ
ム。
【請求項18】
ソフト失敗が、前記SUTの1つまたは複数の動作条件によって引き起こされる、請求項17に記載のコンピュータ・プログラ
ム。
【請求項19】
前記属性値ペアの全ての可能な組み合わせを含むカルテシアン積空間が、組み合わせ理論テスト設計を少なくとも一部用いて縮小テスト空間に縮小される、請求項15に記載のコンピュータ・プログラ
ム。
【請求項20】
前記カルテシアン積空間が、前記SUTのアーキテクチャ制限に基づいてさらに縮小される、請求項19に記載のコンピュータ・プログラ
ム。
【国際調査報告】