JP2008516205A - フィーチャ指向型テストプログラムの開発と実行 - Google Patents

Abstract

【課題】異なるテストシステム間のテストプログラム互換性を改善すること。
【解決手段】リソース制約管理ユニットは、テストプログラムと共に、テストプログラムのうちの少なくとも一つのテストのフィーチャ仕様を受け取るように適合されたインタフェースを備え、前記フィーチャ仕様は、所定のテストを実行するのに必要なテストシステム能力を示す。リソース制約管理ユニットは、テスト毎に、それぞれのテストのフィーチャ仕様を対象テストシステムの能力と比較し、テストの各々に対して、対象テストシステムがそれぞれのテストを実行できるか否かを判断し、対象テストシステムの能力で前記テストを実行できる場合に前記テストの実行を開始するように適合されたフィーチャ仕様評価手段を備える。
【選択図】図５

Description

本発明は、対象テストシステムのためのリソース制約管理ユニットと、所定の対象テストシステムで特定のデバイスをテストするために用いるテストプログラムのためのセットアップ環境と、特定の対象テストシステムにテストプログラムの実行を適応させる方法に関する。

集積回路をテストするため、ひとつの会社で数種類の、又は数通りのハードウェア構成の、自動テストシステム（ＡＴＥ）が使用される場合がある。例えば、会社の研究開発部門に配置されたハイエンドマシンでテストプログラムを開発するとする。テストプログラムの作成と実際のＡＴＥにおける対話型デバッグとを含むテストプログラム開発が完了した後には、製造現場にある後進のテストシステムでテストプログラムが実行され得る。よって、第一のＡＴＥ（自動テスト装置）で開発されたテストプログラムは、別の種類の、又は別のハードウェア構成の、ＡＴＥでも実行しなければならない。種類又はハードウェア構成が異なるＡＴＥ間でテストプログラムの互換性をいかにして達成するかという問題が生じる。

本発明の目的は、異なるテストシステム間のテストプログラム互換性を改善することにある。この目的は独立請求項によって解決される。好適な実施形態を従属請求項で示す。

本発明の実施形態によるセットアップ環境は、少なくとも一つのテストを含むテストプログラムに対するフィーチャ仕様を生成するように適合される。セットアップ環境は、それぞれのテストを実行するにあたり必要な対象テストシステム能力を示すフィーチャ仕様をテスト毎に定義するように適合されたフィーチャ仕様モジュールを含む。セットアップ環境は、前記フィーチャ仕様をテストプログラムとともに格納するよう適合された格納手段をさらに含む。

本発明の実施形態によるセットアップ環境は、対象テストシステムが対応すべきフィーチャを、テストプログラムのテスト毎に個別に定義することを可能にする。所定のテストに必要なフィーチャに対象テストシステムが対応する場合には、このテストは対象テストシステムで実行可能である。対象テストシステムが所定のテストのフィーチャに対応しない場合には、このテストは無効、又はオフラインで処理される。セットアップ環境を用いることにより、テストプログラムの各テストには、このテストを実行するための最低条件を示すフィーチャ仕様を備えさせることができる。この種のテストプログラムを対象ＡＴＥへロードしなければならない場合には、それぞれのテストを対象テストシステムで実行できるか否かに関して、テストプログラムのテスト毎に個別に容易く判断できる。

テストを開発する際、例えばユーザはより先進のフィーチャを使用したがる可能性がある。このような場合には、少数のハイエンドテストシステムでのみテストを実行することになろう。しかし、ユーザが自ら単純なフィーチャに制限する場合には、ほぼ全ての対象テストシステムでテストを実行するであろう。本発明の実施形態によれば、テストプログラムの１つのテストを開発する前に、一方のテストプログラムの互換性と他方のフィーチャの利用可能性との間で妥協を図る。

テストプログラムのテストの各々にフィーチャ仕様を割り当てることにより、種類又はハードウェア構成の異なるＡＴＥで同一のテストプログラムを使用できる。ある特定の対象テストシステム向けにテストプログラムを開発するのではなく、低性能テストシステムとハイエンドテストシステムとを含む全対象テストシステムに向けてテストプログラムを開発することができる。対象テストシステムの側では、フィーチャ仕様により各々のプラットフォームで実行できるテストのそれぞれの部分集合を判断することができる。テストプログラムは一度開発するだけでよく、それ以降はたとえ対象テストシステムが異なっても、ただひとつのテストプログラムを保守すればよい。したがって、テストプログラムの開発・保守にかかる総費用が抑えられる。さらに、第一のＡＴＥで開発したテストプログラムを別種のＡＴＥへ容易く移行できるため、異なるテストシステム間の相互運用性が向上する。例えば、研究開発のために使用する一つのハイエンドテストシステムと、製造で使用する一つ又は複数の低性能マシンを所有する会社の場合、研究開発部門で開発されたテストプログラムを製造のテストシステムでも実行することができる。

別の好適な実施形態によれば、セットアップ環境はさらに、テストのうちの少なくとも一つに対するテストセットアップをテストごとに定義するように適合される。テストセットアップは例えば、テストの実行に先駆けピン単位テスタリソースにロードされる設定とパラメータを備え得る。セットアップ環境は、各々のテストのテストセットアップを対話式に定義することを可能にする。

好適な実施形態によれば、セットアップ環境はさらに、テスタリソースをピン名に割り当てることによってピン構成を定義するように適合される。一方で、許容パラメータ範囲を定義するフィーチャ集合をピン名に割り当てることができる。他方、ピン名毎に対応するテストセットアップを、テスタリソースへロードするように特定できる。

好適な実施形態によれば、対話型セットアップ環境は自動テスト装置（ＡＴＥ）の不可欠な部分である。この自動テスト装置で開発されるテストプログラムは、ある特定のＡＴＥではなく、１セットの予定された対象テストシステム向けに開発される。ハードウェアの互換性は、「偶発的に発生する」のではなく明示的なユーザ行為によって達成される。

別の好適な実施形態によれば、フィーチャ仕様は個々のピンに対するフィーチャ集合を含む。フィーチャ仕様は、使用する各テスタピンのフィーチャ集合を指定することにより、テストごとにセットアップされる。従って、例えば電圧レベル、ベクトルレート等のフィーチャを含むフィーチャ集合は、所定の対象テストシステムのピン単位テスタリソースに対応するようにセットアップされる。所定のテストに対して、対象テストシステムのピン単位テスタリソースがフィーチャ集合に合致する場合には、そのテストを各々の対象テストシステムで実行することができる。

別の好適な実施形態によれば、フィーチャ仕様は、各々のテストを実行するために対象テストシステム側に必要な最低限のハードウェアリソースを示す。例えば、フィーチャ仕様は所定のタイプの対象テスト装置を示し得る。

さらなる好適な実施形態によれば、ユーザは、ある種のテスタリソース、例えばある特定のテスタチャネル又は機器タイプを参照することによって、又は対象システムのテスタリソースの一定の性能水準を参照することによって、ピン単位フィーチャ集合を特定できる。よってフィーチャ集合は、各々のテスタリソースが対応するフィーチャに限定される。さらにユーザは、種類が異なるテスタリソース又は性能水準の共通部分を参照することによってピン単位フィーチャ集合を特定することができる。この場合のフィーチャ集合は、共通部分のテスタリソースの各々が対応するフィーチャに限定される。テストシステムは、異なる能力を有する異種テスタリソースを備えることがある。テスタリソースの種類を、又はこれの共通部分をピンごとに参照することにより、利用可能なピン単位テスタリソースにフィーチャ仕様を個別に適応させることができる。

別の好適な実施形態によれば、ユーザは所定のテストに対してフィーチャ仕様を手動でセットアップできる。このために、フィーチャ仕様モジュールは、所要のパラメータをテスト毎に入力できるようにする対話型編集手段を備え得る。ピン単位フィーチャ集合を生成するために、ユーザは所要のパラメータをピンごとに提供できる。

好適な実施形態において、フィーチャ仕様は最低／最高電圧レベル、最低／最高電圧範囲、最低／最高電流、最低／最高周波数及び周期、最低／最高データ速度、波形リソース数、タイミングリソース数、タイミング分解能、周期及び周波数分解能、ベクトルメモリ深度、シーケンサメモリ深度、波形メモリ深度、ビット分解能のうちの少なくとも一つを参照する。フィーチャ仕様は、所要のテストシステム能力を示す更なるパラメータを追加的に含んでもよい。

また別の実施形態によれば、ユーザは、複数のシステム定義フィーチャ仕様のうちの一つを選択することによって、フィーチャ仕様をセットアップできる。所定のフィーチャ識別子を参照することにより、フィーチャ仕様をセットアップする作業はより迅速に実行できる。

さらなる好適な実施形態によれば、システム定義フィーチャ仕様は、手動で特定されるフィーチャに部分的又は全面的に置き換えることができる。

代替の実施形態によれば、所定の外部基準によるテスタディスクリプションを、フィーチャ仕様をセットアップする基礎として使用することができる。

さらに別の好適な実施形態によれば、現在のテストシステムの能力を参照することによって所定のテストに対するフィーチャ仕様を生成できる。現在のテストシステムのフィーチャは、例えば現在のシステムに関する情報を含む現在のシステムのモデルファイルにアクセスすることによって、あるいは実際のＡＴＥハードウェアの自動検出を実行することによって、入手可能である。

好適な実施形態によれば、テストプログラムの異なるテストに対して異なるフィーチャ仕様を提供できる。テストプログラムの異なるテストに対し、異なる対象テストシステム能力が必要となり得る。これにより対象テストシステムの側では、各々のテストを対象テストシステムが実行できるか否かを、テストごとに判断できる。フィーチャ仕様をピンごとにセットアップする場合には、異なるテストに関連づけられた異なるピン単位フィーチャ集合が存在し得る。

好適な実施形態において、セットアップ環境は、フィーチャ仕様によってユーザがテストプログラムを開発する際に利用できるフィーチャを限定するように適合される。この実施形態において、セットアップ環境はフィーチャ仕様によって表されるフィーチャに限りアクセスを与えるように、及び／又はフィーチャ仕様に一致しない入力を無視するように適合される。よって、ある特定のテストをセットアップする際には、フィーチャ仕様の中で定義されたフィーチャのみの使用が徹底される。

好適な実施形態によれば、セットアップ環境は、フィーチャ仕様によってテストセットアップのパラメータ範囲を限定するように適合される。ユーザはテストセットアップを特定する際に、フィーチャ仕様の設定とパラメータ範囲に制限される。セットアップ環境は、フィーチャ仕様が定める限度を超えるユーザ入力を無視するように適合される。セットアップ環境は、フィーチャ仕様が所定の対象ＡＴＥのフィーチャに対応する場合に、それぞれの対象ＡＴＥのように機能する。

別の好適な実施形態によれば、セットアップ環境は、開発中のテストのフィーチャが対象とする対象ＡＴＥの能力に合致するか否かを絶えず監視するように適合された照合機構を備える。それらが合致しない場合には、照合機構はユーザに通知する。この場合に照合機構は、例えば現在のテストのフィーチャを限定する方法を示唆し得る。

本発明の実施形態はさらに、上述したセットアップ環境を備えるＡＴＥシステムソフトウェアに関する。さらなる好適な実施形態によれば、セットアップ環境はフィーチャ仕様を対話式に特定し、修正するように適合される。

本発明の実施形態によるリソース制約管理ユニットは、テストプログラムのうちの少なくとも一つのテストに対するフィーチャ仕様を、テストプログラムとともに受け取るように適合されたインタフェースを含む。フィーチャ仕様は、ある特定のテストを実行するにあたって要求されるテストシステム能力を指示する。リソース制約管理ユニットは、フィーチャ仕様評価手段をさらに含む。フィーチャ仕様評価手段は、それぞれのテストのフィーチャ仕様を対象テストシステムの能力とテスト毎に比較し、対象テストシステムがそれぞれのテストを実行できるか否かをテスト毎に判断するように適合される。フィーチャ仕様評価手段はさらに、使用する対象テストシステムの能力でテストの実行が可能である場合に、ハードウェアでテストの実行を開始するように適合される。

対象テストシステム側では、テストプログラムのテストのうちの少なくともいくつかに対して、テストの実行に必要な能力を示すフィーチャ仕様を受け取る。テスト単位フィーチャ仕様を対象テストシステムの特性と比較することにより、利用可能リソースでそれぞれのテストを実行できるか否かをテスト毎に判断できる。所定のテストのフィーチャ仕様が対象テストシステムの能力に合致する場合には、テストが実行開始される。

テストプログラムは、例えば、現在のテストシステムの能力に合致するテスト、並びに現在のテストシステムで利用できないフィーチャを必要とするテストを含み得る。この場合リソース制約管理ユニットは、利用可能なリソースに合致するテストの実行を開始するように適合される。上記で説明したようにリソース制約管理ユニットを実施することにより、簡素なテストと先進のテストとを含むテストプログラムを、低性能からハイエンドまでの幅広い種類の対象テストシステムで実行できる。テストプログラム互換性の問題はリソース制約管理ユニットによって自動的に処理される。

単一のテストプログラムバージョンを異なる対象テストシステムで使用できるため、ユーザは異なる対象テストシステムに対する異なるテストプログラムバージョンを把握せずにすむ。

好適な実施形態では、リソース制約管理ユニットは、利用可能なテスタリソースに合致しないフィーチャ仕様を有するテストを無効にするように適合される。例えば、後進の対象テストシステムではテストプログラムの小さい部分集合だけを実行し、ハイエンドマシンでは大きい部分集合の（又は全ての）テストを実行するようにすることが可能である。

好適な実施形態によれば、リソース制約管理ユニットは、利用可能なテスタハードウェアによって実行できないテストを処理するように適合されたオフライン処理機構を備える。ある特定のテストのフィーチャ仕様が利用可能なテスタリソースに合致しないとフィーチャ仕様評価手段が判断すれば常に、実際のテスト実行はオフラインテスト処理に置き換えられる。

好適な実施形態において、オフライン処理機構は、所定のテストを利用可能なテスタリソースで実行できない場合には常にエミュレーションテスト結果を生成する。この場合、実際のテスト実行はテストのエミュレーションに置き換えられる。かくして対象テストシステムはテストプログラムの全テストについてテスト結果を記録でき、これにより実際には実行されなかったテストの結果データが表示される。

別の好適な実施形態によれば、リソース制約管理ユニットはセットアップローダーユニットを備える。テストプログラムのテストが実行される前に、少なくとも一つの対応するセットアップがシステムのハードウェアへロードされる。所定のテストに対応する一つ又は複数のセットアップは、テストのフィーチャ仕様が利用可能なテスタリソースと合致する場合にだけロードされる。

好適な実施形態では、テストのフィーチャ仕様は多数のフィーチャ集合を含む。各ピンに対して、少なくともテストで使用される各ピンに対して、対応するフィーチャ集合が特定される。また別の好適な実施形態によれば、フィーチャ仕様評価手段は、テスト中に使用される各ピンに対して、対応するフィーチャ集合が対応するピン単位テスタリソースに合致するかどうかを判断するように適合される。テスト中に使用される各ピンに対してピン毎にフィーチャ集合をテスタリソースと比較することにより、そのテスト全般を実行できるかどうかを調べることができる。

本発明は、一つ以上の適切なソフトウェアプログラムによって部分的に又は全体的に具現又は支援されることができ、それら適切なソフトウェアプログラムは、いかなる種類のデータ記憶媒体にも格納でき、又はいかなる種類のデータ記憶媒体により提供でき、また、何らかの相応しいデータ処理ユニットにて実行でき、又は何らかの相応しいデータ処理ユニットによって実行できる。ある特定の対象テストシステムにテストプログラムの実行を適合させるように、ソフトウェアプログラム又はルーチンを適用させるのが好ましい。

本発明の実施形態の他の目的及び付随する利点の多くは、添付の図面と共に以下の好適な実施形態の詳細な説明を参照することにより、容易に理解されると共により理解が深まるであろう。実質的に又は機能的に同等又は同様の特徴については、同じ参照番号を付して示している。

自動テスト装置（ＡＴＥ）は一般的に、ＡＴＥシステムソフトウェアと複数のテスタリソース（チャネルカード及び／又は機器）とを備え、テスタリソースは、テスト対象デバイス（ＤＵＴ）にテスト信号を提供すると共にＤＵＴからテスト信号を受信するように、テストプログラムによって制御される。顧客の試験場には、製品世代と速度／性能等級とが異なるチャネルカードを備えるＡＴＥが存在し得る。さらに、テストプログラムをロード、開発、実行、保存するために使用するＡＴＥシステムソフトウェアのリリースが異なれば、テストプログラムのバージョンをこれに対応させる。顧客は一般的に、同じ能力を提供する異なるハードウェアリソース間での、そして異なるソフトウェアリリース間での、テストプログラムの互換性を期待する。

図１は、異なるテスタリソースとテストプログラムバージョンの一例を示す。軸１沿いには、ピン単位テスタリソースの二通りの製品世代、すなわち「世代Ａ」と名づけられた旧ハードウェア世代と、「世代Ｂ」と名づけられた新ハードウェア世代とが示されている。世代Ａは、三通りの速度／性能等級「Ｌ」（低価格）、「Ｍ」（中価格）、「Ｈ」（高価格）を含む。軸２沿いには、低価格から高価格にかけて優先フィーチャ集合を提供する速度／性能等級「Ｌ」、「Ｍ」、「Ｈ」が示されている。世代Ｂは、軸３沿いに示された速度等級「Ｌ II」（低価格）、「Ｍ II」（中価格）、「Ｈ II」（高価格）を含む。図面の第三の次元は種々のソフトウェアバージョンに相当する。軸４沿いには、リリース１．０、２．０、２．１、２．１．１、２．２を含む異なるテストプログラムバージョンが示されている。

例えば、ある顧客が旧製品世代のため、例えば「世代Ａ」システムのためのテストプログラムを開発したとする。この顧客が一つ又は複数の「世代Ｂ」システムを購入し、旧型のテストプログラムを改良して、所定のデバイスをテストするにあたり「世代Ｂ」システムから提供される新しいフィーチャを活用したい意向である。別の顧客は、自身の研究開発現場のため最新式のＡＴＥシステムを購入したが、製造現場では今なお旧製品世代のテストシステムが使われているとする。この場合、テストプログラムは能力が勝るテストシステムで、例えば「世代Ｂ」のテストシステムで開発され、そのテストプログラムは能力の劣る「世代Ａ」システムで実行することになる。さらに別の例として、顧客はコスト削減のため自身のテストプログラムを修正する場合もある。「Ｍ」又は「Ｍ II」能力を要するテストはいずれも省かれ、修正されたテストプログラムは「Ｌ」及び「Ｌ II」テスタリソースで実行することになる。

顧客は一般的に、同じ能力を提供する異なるハードウェアリソース間での、そして異なるソフトウェアリリース間での互換性を期待する。テストプログラム互換性に関しては、異なるソフトウェアバージョンによって生成されたテストプログラムの互換性（ソフトウェア互換性）と、異なるハードウェアリソースのために生成されたテストプログラムの互換性（ハードウェア互換性）とを含む様々な局面に取り組まなければならず、ここでハードウェア互換性は、異なるハードウェア世代（例えば「世代Ａ」及び「世代Ｂ」）間の互換性と、低価格から高価格まで優先フィーチャ集合を提供する異なる速度／性能等級間の互換性とを含む。勿論テストプログラム互換性は、異なるソフトウェアバージョンの、又は異なるテスタリソースの共通フィーチャ集合に対してのみ達成できる。

一般に、互換性があるという場合には上位互換性に関する場合と下位互換性に関する場合の両方がある。システムは、その後続バージョンと互換性があれば（例えば、後続バージョンによりデータを読み取ることができれば）、上位互換性である。システムは、これの先行バージョンと、あるいは場合によっては他の先行システムと、特にこれが代替となり得るシステムと互換性があれば（例えば、先行バージョンとともにデータを共有できれば）、下位互換性である。

ソフトウェア互換性は、別のソフトウェアバージョンによって保存されたテストプログラムをロードし実行する能力と定義される。ソフトウェア互換性に関しては、望ましい挙動として、例えばテストプログラムのロード、実行、及び保存にあたりスループットの低下をともなわない全リリース間の上位互換性と、マイナーリリース間の、例えばリリース２．１．１及び２．１間の、下位互換性とを挙げることができる。メジャーリリース間の、例えばリリース２．０及び１．０間の下位互換性は、必ずしも必要ないであろう。

ハードウェア互換性は、同じソフトウェア改訂版を使用し別のハードウェアで保存されたテストプログラムを、スループットの低下をともなわずにロードし、実行する能力と定義される。ハードウェア互換性は好ましくは、少なくともハードウェア制約が、例えば互換性のないレベル範囲等がない限りは、異なるハードウェア世代間の上位互換性を含む。例えば、「世代Ａ」システムで開発されたテストプログラムは「世代Ｂ」システムで実行できる。さらに好ましくは、ハードウェア互換性は、低価格から高価格まで優先フィーチャ集合を提供する異なる速度等級間の上位互換性を含む。この種の上位互換性は、「Ｍ」チャネルで開発されたテストプログラムを「Ｈ」チャネルで実行できることを意味する。ただし、上位互換性に制約を課すハードウェア制約は存在するかもしれない。ハードウェア互換性はこのほかに、テストプログラムによって種類が異なるチャネルカードが利用される共通のハードウェアフィーチャ集合をサポートする限り、異種チャネルカード間の下位互換性を含む。例えば、「世代Ｂ」システムで保存され、「世代Ｂ」に特有のフィーチャを利用しないテストプログラムは、「世代Ａ」システムで実行できる。

好ましくは、同じテストプログラムを最低限の投資で異なるＡＴＥシステム（システムソフトウェアとテスタリソース）で実行できるようにすべきである。

図２にはテスト開発プロセスが示されている。電子設計オートメーション（ＥＤＡ）領域５によって提供されるファイルは通常、テストパターン生成の出発点として使用される。ＥＤＡ領域５は、設計シミュレーションデータ、例えばＶＣＤファイル６、ベリログ(Ｖｅｒｉｌｏｇ)ファイル７、又はＶＨＤＬファイル８等を提供できるであろう。

ベリログは、オープン規格（Ｏｐｅｎ Ｖｅｒｉｌｏｇ）として定められた普遍的ハードウェア定義言語である。一般的に、ベリログは「ケイデンス(Ｃａｄｅｎｃｅ)」ベリログシミュレータとともに使用される。ベリログは、挙動、レジスタ転送レベル（ＲＴＬ）、ゲートレベルに対する記述、並びに刺激に対する記述を一つの言語でサポートする。

ＶＣＤ（Ｖｅｒｉｌｏｇ変更ダンプ）は、テストパターン生成のために使用されるベリログからの出力である。通常、ＶＣＤファイルはテスタによる読み取りが可能な別の形式に変換しなければならない。

ＶＨＤＬはＶＨＳＩＣ（超大規模集積回路）ハードウェア記述言語である。ＶＨＤＬは、ＩＥＥＥ規格１０７６に定められている。

ＥＤＡはまた、例えばＳＴＩＬファイル９、ＷＧＬファイル１０等、特定のＡＴＥから独立した専用テスト記述言語を利用しＤＦＴ（テスト設計）データやＡＴＰＧ（自動テストパターン生成）データを提供できるであろう。

ＩＥＥＥ規格１４５０に定められたＳＴＩＬ（標準テストインタフェース言語）は、シミュレーション、自動テストパターン生成（ＡＴＰＧ）、ビルトイン自己テスト（ＢＩＳＴ）、及びＡＴＥ間で高密度デジタルテストパターンを移行するためのものである。これは、シミュレーション、変換、及びＡＴＰＧツールによって生成できるタイミング、仕様、パターン、及びシリアルスキャンのテスタ中立記述をサポートする。ＳＴＩＬで使用される波形表現は階層状の信号タイミング定義を可能にし、現代のマイクロプロセッサバス構造に適している。タイミングは、タイミング仕様とタイミング関係の表として定義できる。ＳＴＩＬはシリアルスキャンデータを格納し、さらなるテスト変換を要求しない直接テスト実行向けに構成された形式にて完全、部分、又は境界スキャンをサポートする。

ＷＧＬ（波形生成言語）はＡＴＰＧとベクトル生成に対する事実上の標準である。ほとんどのパターン開発ツールはＷＧＬをサポートする。さらに、ＷＧＬを様々なネイティブＡＴＥ規格に変換するように適合された第三者ツールも存在する。

ＥＤＡ領域５の側では、ＡＴＰＧ又はシミュレーションテストファイルを生成する際に、利用可能なハードウェアリソースとテスタリソースの制約条件を勘案できるであろう。このためＡＴＥテストプログラム１７は、例えばテスタハードウェア１２の制約条件をＴＲＣジェネレータ１４に指示するテスタリソース制約条件（ＴＲＣ）情報１３を提供できるであろう。ＴＲＣジェネレータ１４は、ＴＲＣ情報１３をＥＤＡ領域５で処理できる規格に変換するように適合される。例えばＴＲＣジェネレータ１４は、ＳＴＩＬ ＴＲＣエクステンションとも呼ばれるＩＥＥＥ規格１４５０．３によってＴＲＣ情報１３をＴＲＣファイル１５に変換できるであろう。ＥＤＡ領域５は、ＡＴＰＧ又はシミュレーションテストファイルの生成過程で、利用可能なハードウェアリソースによって課せられる制約条件によってテストパターンをセットアップするため、ＴＲＣファイル１５にアクセスできるであろう。

設計−試験領域１６は、それぞれの入力ファイル、例えばＶＣＤ、ベリログ、又はＶＨＤＬファイル、ＷＧＬファイル、又はＳＴＩＬファイルから、ＡＴＥで処理できる対応するネイティブＡＴＥテストプログラム１７への変換を行う。ＥＤＡ領域５によって送られるテストデータはイベント本位テストファイルであってよい。つまりこれは、例えばアナログタイムドメインの中で順次に並べられる信号エッジ等を含む。この種のテストはＡＴＥによって直接的には実行できない。したがって設計−試験領域１６は、ユーザによって指定されるサイクル定義を適用することにより、イベント本位テストをサイクル本位テストに変換するように適合される。

本発明の実施形態によれば、ＡＴＥシステムソフトウェア１１は、対象ＡＴＥの能力によってＡＴＥテストプログラム１７を対話式に適応させるセットアップ・デバッグユーザインタフェース１８を備える。詳細には、セットアップ・デバッグユーザインタフェース１８は、ＡＴＥテストプログラム１７を読み取る（１９）ように、ピン構成２０、フィーチャ仕様２１、及びテストセットアップ２２を特定するように、そしてＡＴＥテストプログラム１７へ書き込むように適合される。

第一のステップではピン構成２０をセットアップする。ユーザはセットアップ・デバッグユーザインタフェース１８を用いることにより、対象ＡＴＥのテスタリソースを指定でき、さらにピン単位テスタリソースにピン名を割り当てることができる。

ユーザは次のステップで、予定された対象ＡＴＥのテストシステム能力を指示するフィーチャ仕様２１をセットアップできる。セットアップ・デバッグユーザインタフェース１８は、フィーチャ仕様２１にアクセスしこれを編集する（２５）ように適合されたフィーチャ仕様エディタ２４を備える。ユーザはフィーチャ仕様２１を用いることにより、使用テストシステム能力を意図的に制限できる。フィーチャ仕様２１は例えば、テスト毎に個別に、そしてテスト対象デバイス（ＤＵＴ）のピンのテストに用いるピン単位テスタリソース毎に個別に、セットアップされるフィーチャ集合を含む。ユーザがテストの機能性を最低限度まで制限する場合には、それぞれのテストは対象ＡＴＥで実行可能となる。しかし、ユーザが先進フィーチャの利用を望む場合には、完成したテストはハイエンドの対象ＡＴＥでのみ実行可能となる。よってユーザは、ネイティブＡＴＥテストプログラムを生成する前に、一方でテストプログラムの互換性と、他方で先進フィーチャの利用可能性との間で妥協点を見つけなければならない。ユーザは一般に、ある特定のテストに対して必要なフィーチャと能力とを特定する前に、テスト方法と利用可能なテスタリソースの両方を分析し、これを踏まえてフィーチャ仕様をセットアップする。

ある特定のテストのためフィーチャ仕様をセットアップすることにおいては、数通りの方法がある。第一の方法では、フィーチャ仕様エディタ２４を用いて個々のフィーチャと所要の仕様とを手動で特定する。一例として、対象ＡＴＥのハードウェアが一つ又は複数のデジタルチャネルを備えると仮定する。この場合のフィーチャ仕様は、例えば：
・最低／最高ベクトル周期
・最低／最高マスタークロック周波数
・１ベクトル当たりの波形数
・１ベクトル当たりの信号エッジ数
・ベクトルメモリ深度
・シーケンサメモリ深度
・電圧範囲
・その他
を含むであろう。

一般的に、フィーチャ仕様は大抵、ユーザには非表示にされるハードウェア仕様やハードウェアフィーチャではなく、テスタリソースの測定又は信号生成能力を参照する。

フィーチャ集合を指定する第二の方法では、ある特定のチャネルカードのフィーチャ又はチャネル仕様を反映するシステム定義識別子を参照するか、あるいは例えばＭ又はＬ II等、チャネルカードの種類を明示的に参照する。さらに、例えばチャネルカードＭ及びＭ IIの共通フィーチャ：Ｍ∩Ｍ IIを参照することにより、二種類以上のチャネルのフィーチャの共通部分を参照することによってフィーチャ集合を定義できる。

別の方法によれば、いずれかの種類の所定の業界標準テスタ記述を処理することによってフィーチャ集合をセットアップする。

さらに別の方法によれば、システム定義フィーチャ仕様を出発点とし、これによりユーザのニーズによって所定のフィーチャを対話式に編集し、置き換える。

さらに別の方法では、ＡＴＥテストプログラム１７を開発するＡＴＥの能力を参照することによってフィーチャ集合を定義する。例えば、実際のＡＴＥハードウェア１２の自動検出を行うことにより、現在のシステムの能力をハードウェアドライバ２６から得ることができる。代替的に、物理的ハードウェアを利用できない場合にはテスタハードウェアをエミュレートするために、ＡＴＥシステムソフトウェアによって要求されるテストシステム構成に関する全ての情報を含むＡＴＥ記述ファイル２７にアクセスできるであろう。

フィーチャ仕様エディタ２４は、フィーチャ仕様２１をセットアップするために上述の方法のうちの一つ又は複数に対応できるであろう。テストプログラムは一般的に、一連の異なるテストを含む。この場合、異なるテストのため異なるフィーチャ集合を特定することが可能である。

ピン構成２０とフィーチャ仕様２１が定義された後、第三のステップではテストセットアップ２２を特定する。テストセットアップ２２は、それぞれの対象ＡＴＥのハードウェアリソースへロードされる値とパラメータとを含む。

ＡＴＥシステムソフトウェア１１は、リソース制約管理部２８をさらに含む。リソース制約管理部２８にはピン構成２０とフィーチャ仕様２１の両方が提供される（２９）。リソース制約管理部２８は、ユーザによって指定されたテストセットアップ２２が定義済みフィーチャ仕様２１に一致するか否かを監視するように適合される。

ここで数通りの実施方法が存在する。第一の実施形態によれば、リソース制約管理部２８とセットアップ・デバッグユーザインタフェース１８は、フィーチャ仕様と一致させるようにテストセットアップ２２のパラメータ範囲を制限するように適合される。この実施形態では、ユーザはフィーチャ仕様２１と一致しないテストセットアップ２２を入力してはならない。図３にはその例が示されている。この例では、三つの異なる対象ＡＴＥ：Ｔ１、Ｔ２、Ｔ３の能力の共通部分としてフィーチャ仕様２１がセットアップされている。フィーチャ仕様２１は図３に示された領域３０に相当する。よって、ユーザが利用できるフィーチャとパラメータの範囲とは領域３０の中のフィーチャに限定される。ユーザがこれらの限度外のパラメータの入力しようとしても、これらの入力はセットアップ・デバッグユーザインタフェース１８によって受け付けられない。これに関し、ＡＴＥテストプログラムの開発に用いるＡＴＥは対象とする対象ＡＴＥのように、又は異なる対象ＡＴＥの共通部分のように挙動する。

第二の実施形態によれば、リソース制約管理部２８は、テストセットアップ２２が定義済みのフィーチャ仕様２１に一致するか否かを監視するように適合される。フィーチャ仕様２１に一致しないフィーチャやパラメータが使用されると、ユーザに通知する。この実施形態において、パラメータの範囲はフィーチャ仕様２１にて定義されたフィーチャに厳密には限定されない。ただしリソース制約管理部２８は、ユーザの入力を照合するように、そしてそれぞれの入力がフィーチャ仕様２１に一致しない場合にユーザに伝えるように、適合される。この実施形態において、対象ＡＴＥの能力を超えるフィーチャを含むテストを無効にする作業は、それぞれの対象ＡＴＥに委ねられる。

ピン構成２０、フィーチャ仕様２１、及びテストセットアップ２２をセットアップした後に、ＡＴＥテストプログラム１７を書き込む（２３）。次に、例えばある種のデータ記憶媒体に格納されたＡＴＥテストプログラムを、使用中の対象ＡＴＥで実行するか、又は別の対象ＡＴＥへ移行する。

図４は、ＡＴＥテストプログラム１７のテストシーケンスが実際に実行される対象ＡＴＥを示す。対象ＡＴＥはＡＴＥシステムソフトウェア３１と、例えばピン単位テスタリソース、詳細にはチャネルカード、機器等を備えるＡＴＥハードウェア３２を備える。ＡＴＥハードウェア３２のタイプ及び／又は構成は、図２に示すＡＴＥハードウェア１２と全く異なってもよい。対象ＡＴＥのシステムソフトウェア３１のバージョンは、図２に示すＡＴＥシステムソフトウェア１１のバージョンと異なってもよい。ＡＴＥシステムソフトウェア３１は、ＡＴＥテストプログラム１７にアクセスし（３４）これを処理するように適合された実行モジュール３３を備える。各テストにつき、それぞれのテストを実行するのに必要なフィーチャを利用可能なハードウェアリソースと比較しなければならない。この比較はリソース制約管理部３５によって行われる。このために、リソース制約管理部３５にはピン構成２０とフィーチャ仕様２１の両方が提供される（３６）。ハードウェアドライバ３７は実際のハードウェアリソースに関する情報３８をリソース制約管理部３５へ提供し、ここでハードウェアドライバ３７は、実際のＡＴＥハードウェア３２の自動検出を実行することによって、及び／又はＡＴＥ記述ファイル３９にアクセスすることによって、この情報を取得し得る。リソース制約管理部３５は、フィーチャ仕様３１を利用可能なハードウェアリソースとテスト毎に比較することにより、ＡＴＥハードウェア３２がそれぞれのテストを実行できるか否かを、テスト毎に個別に判断する。

フィーチャ仕様２１は、好ましくは所要のテスタリソースをピンごとに指示するピン単位フィーチャ集合をテスト毎に含む。従ってリソース制約管理部３５は、テスト毎に、そして同テストの際に使用されるピン毎に、それぞれのフィーチャ集合をテスタハードウェアの能力と比較するように適合される。ある特定のテストで、そのテストの際に使用される全ピンのフィーチャ集合が対応するピン単位ハードウェアリソースに合致する場合には、テストの実行が開始される。これはピン単位比較のそれぞれの結果の論理積に対応する。

リソース制約管理部３５は、それぞれのテストを実行できるか否かをローダー４１に伝える（４０）。ローダー４１はテストが実行可能である場合に、テストセットアップ２２の内の該当するテストセットアップを、ハードウェアドライバ３７を介してＡＴＥハードウェア３２へロードし、次にＡＴＥハードウェアがそれぞれのテストを実行する。テストの実行中に得たテスト結果は、ハードウェアドライバ３７を介して実行モジュール３３へ転送される。

所定のテストをＡＴＥ３２が実行できないことをリソース制約管理部３５がローダー４１に伝える（４０）と、ローダー４１は、テストセットアップ２２の内の該当するテストセットアップをオフラインテストセットアップデータ記憶装置４２へロードする。それぞれのテストを実際に実行することは可能でないため、実行モジュール３３は、結果データを生成するためにこのテストのオフライン処理を実行する。例えば、テスト実行をエミュレートする基礎として、テストセットアップのパラメータを採用することができる。実行モジュール３３は、テスト結果データを表示するためのグラフィカルユーザインタフェースを備えるセットアップ・デバッグユーザインタフェース４４にテスト結果データを提供する。テスト結果データ４３は、それぞれのテストが実際に実行されたか否かの表示、あるいはオフラインテスト処理を実行することによってテスト結果を取得したか否かの表示を、テスト毎に含む。

かくして、テスト結果データを利用できる。ユーザは作成されたテストプログラム１７をデバッグする過程で、生成されたテスト結果データをもとにセットアップパラメータを対話式に修正できる。

図５（ａ）にはテストプログラムＴＰが概略的に示されている。テストプログラムＴＰは一連のテストｔ１、ｔ２、...ｔ９を備える。これらのテストの各々につき、対象テストシステムの所要能力を示す対応するフィーチャ仕様が特定されており、ここでテストプログラムＴＰの各テストｔ１、ｔ２、...ｔ９に対して異なるフィーチャ仕様を提供してよい。

図４に示すように、対象テストシステムのＡＴＥシステムソフトウェア３１はローダー４１とリソース制約管理部３５とを備える。テストプログラム、例えば図５（ａ）に示すテストプログラムＴＰ等が対象ＡＴＥへロードされると、リソース制約管理部３５は、ＡＴＥハードウェア３２がそれぞれのテストを実行できるか否かを、テストｔ１からｔ９の各々に対して個別に判断する。ローダー４１は、利用可能なハードウェアリソースがそれぞれのテストのフィーチャ仕様に合致する場合に限り、テストのセットアップをテスタのハードウェアへロードする。テスタハードウェア３２が所定のテストを実行できない場合、そのテストのセットアップはロードされない。リソース制約管理部３５は、フィーチャ仕様を利用可能なハードウェアリソースにテスト毎に比較するように適合される。図５（ａ）にはこの比較の結果が示されている。対象テストシステムＴ１は例えば、テストｔ１からｔ５を実行できるが、テストｔ６からｔ９は実行できない。別の対象テストシステムＴ２は、ｔ２、ｔ３、...ｔ８を含むテストの部分集合を実行できるが、テストｔ１とｔ９は実行できない。テストシステムＴ３はテストｔ４からｔ９を実行できるが、ｔ１からｔ３のフィーチャ仕様はＴ３の能力に合致しない。

図５（ｂ）には、テストシステムＴ１の能力に合致するテストからなる第一の部分集合ＴＰＴ１に、そしてＴ１で実行できないテストからなる第二の部分集合ＴＰＮＯＴ（Ｔ１）に、テストプログラムＴＰのテストが分かれる様子が示されている。リソース制約管理部３５は、ＴＰＴ１がテストｔ１からｔ５を含み、さらにＴＰＮＯＴ（Ｔ１）がテストｔ６からｔ９を含むと判断する。

対象テストシステムは、テストの実行が完了した後にテスト結果を記録する。好適な実施形態において、テストプログラムの各テストのテスト結果データは、それぞれのテストが実際に実行されたか否かの表示を含む。例えば図５（ｂ）に示すケースでは、テスト結果データは、部分集合ＴＰＮＯＴ（ＴＰ）の中にある実行されなかったテストの結果データを含み得る。実行されなかったテスト、例えば図５（ｂ）にあるテストｔ６からｔ９等の結果データは、例えばこれらのテストのオフライン処理を実行することによって得ることができる。テストｔ６からｔ９が実際には実行されなかったこと、そして対応するテスト結果をオフライン処理によって得たことは、結果ファイルの中で示される。テストｔ６からｔ９のテスト結果は、例えばこれらのテストをエミュレートすることによって得ることができる。テスト対象デバイスのハードウェア記述から始まり、ノイズレベルを考慮することや、ジッタを付加すること等により、エミュレートしたテスト結果をオフラインで生成できる。

図６（ａ）及び図６（ｂ）には二通りのデータモデルが示されている。データモデルは、テストセットアップとフィーチャ集合との間の相互関係を提供する。

図６（ａ）に示す第一のデータモデルによれば、テストプログラム４５は一つ又は複数のテスト４６を含む。テスト４６の各々は対応するテストセットアップ４７を使用する。テストセットアップ４７の各々はＮ個のピン単位テストセットアップ４８からなり、Ｎ≧１は自然数である。Ｎ個のピン単位テストセットアップ４８の各々はフィーチャ集合４９を参照し、ここで数個のピン単位テストセットアップ４８が同一のフィーチャ集合４９を参照できる。

図６（ｂ）は、テストの脈絡としてフィーチャ仕様の概念を導入するより複雑なデータモデルを示す。テストプログラム５０は一つ又は複数のテスト５１を備える。テストプログラム５０はこのほかに一つ又は複数のテストセットアップ５２を備え、ここでテスト５１の各々はテストセットアップ５２のうちの一つを参照する。テストセットアップ５２の各々はＮ個のピン単位テストセットアップ５３を備え、Ｎ≧１は自然数である。テストプログラム５０は、一つ又は複数のフィーチャ仕様５４をさらに備える。テストセットアップ５２の各々はまさに一つのフィーチャ仕様を参照し、ここで一つ又は複数のテストセットアップから各フィーチャ仕様を参照できる。フィーチャ仕様５４の各々はＮ個のピン単位フィーチャ集合セットアップ５５からなり、ピン単位フィーチャ集合セットアップ５５の各々はフィーチャ集合５６を参照する。これにより、ピンの各々に対して、フィーチャ仕様５４のうちの一つを通じてピンのピン単位テストセットアップとフィーチャ集合５６との間に暗黙の関係５７が成立する。

異なるハードウェア及びソフトウェアバージョンの概要を示す図である。 テストプログラム開発プロセスを示す図である。 許容フィーチャ集合を三つの対象ＡＴＥ Ｔ１、Ｔ２、Ｔ３の共通部分にいかに制限できるかを示す図である。 ＡＴＥテストプログラムが実際に実行される対象ＡＴＥを示す図である。 九つのテストを含むテストプログラムＴＰを、三通りのテストシステムＴ１、Ｔ２、Ｔ３の能力とともに示す図である。 テストセットアップとフィーチャ集合との相互関係を提供する二通りのデータモデルを示す図である。

符号の説明

１１ ＡＴＥシステムソフトウェア
１７ ＡＴＥテストプログラム
２０ ピン構成
２１ フィーチャ仕様
２２ テストセットアップ
２８ リソース制約管理部

Claims (35)

1. 少なくとも一つのテスト（ｔ１、ｔ２、...ｔ９）を含むテストプログラム（ＴＰ）に対するフィーチャ仕様を生成するように適合されたセットアップ環境（１８）であって、
   それぞれのテストを実行するのに必要な対象テストシステム能力を示すフィーチャ仕様（２１）をテスト毎に定義するように適合されたフィーチャ仕様モジュール（２４）と、
   前記フィーチャ仕様（２１）を前記テストプログラム（１７）と共に格納するように適合された格納手段と、
   を備えることを特徴とするセットアップ環境。
2. 前記セットアップ環境がさらに、前記テストのうちの少なくとも一つのテストセットアップをテスト毎に定義するように適合されること、
   を特徴とする請求項１に記載のセットアップ環境。
3. 前記セットアップ環境がさらに、テスタリソースをピン名に割り当てることによってピン構成を定義するように適合されること、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
4. 前記セットアップ環境が自動テスト装置の不可欠な部分であること、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
5. 前記フィーチャ仕様モジュールが、テスト中に使用するピン単位テスタリソースの対象テストシステム能力を示すフィーチャ集合を、テスト毎及びピン毎に特定するように適合されること、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
6. 前記フィーチャ仕様が、最低限のハードウェア要件の観点から対象テストシステムの所要能力を示すこと、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
7. 前記フィーチャ仕様モジュールが、対象テストシステムのテスタリソースのそれぞれの種類又はテスタリソースの異なる種類を参照することによって、前記フィーチャ仕様をセットアップすることをサポートすること、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
8. 前記フィーチャ仕様モジュールが、前記フィーチャ仕様の手動セットアップをサポートする対話型編集手段を備えること、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
9. 前記フィーチャ仕様が、最低／最高電圧レベル、最低／最高電圧範囲、最低／最高電流、最低／最高周波数及び周期、最低／最高データ速度、波形リソース数、タイミングリソース数、タイミング分解能、周期及び周波数分解能、ベクトルメモリ深度、シーケンサメモリ深度、波形メモリ深度、ビット分解能のうちの少なくとも一つを含むこと、
   を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
10. 前記フィーチャ仕様モジュールが、システム定義フィーチャ仕様を参照することによって前記フィーチャ仕様をセットアップすることをサポートすること、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
11. 前記フィーチャ仕様モジュールが、個別定義フィーチャをセットアップすることによって、システム定義フィーチャ仕様を部分的又は全面的に無効にすることをサポートすること、
    を特徴とする請求項１０に記載のセットアップ環境。
12. 前記フィーチャ仕様モジュールが、所定の規格によってテスタ記述を処理することによって前記フィーチャ仕様をセットアップすることをサポートすること、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
13. 前記フィーチャ仕様モジュールが、現行テストシステムのテストシステム能力を検索することによって、前記フィーチャ仕様をセットアップすることをサポートすること、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
14. 前記フィーチャ仕様モジュールが、前記テストプログラムの異なるテスト毎に異なるフィーチャ仕様を特定することをサポートすること、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
15. 前記セットアップ環境が、前記フィーチャ仕様によってユーザがテストプログラムを開発する際に使用し得るフィーチャを制限するように適合されること、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
16. 前記セットアップ環境が、前記フィーチャ仕様によってテストセットアップのパラメータ範囲を制限するように適合されること、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
17. テストセットアップが前記フィーチャ仕様に合致するか否かを判断するように適合された照合機構をさらに含むこと、
    を特徴とする請求項１又は先行する請求項のいずれか一項に記載のセットアップ環境。
18. 前記照合機構が、前記テストセットアップが前記フィーチャ仕様に合致しない場合にユーザに通知するように適合されること、
    を特徴とする請求項１７に記載のセットアップ環境。
19. 請求項１から請求項１８のいずれか一項に記載のセットアップ環境（１８）を備えること、
    を特徴とするＡＴＥシステムソフトウェア（１１）。
20. 前記セットアップ環境が、前記フィーチャ仕様を対話式に特定し修正するように適合されること、
    を特徴とする請求項１９に記載のＡＴＥシステムソフトウェア。
21. 対象テストシステムのためのリソース制約管理ユニット（３５）であって、前記リソース制約管理ユニット（３５）は：
    テストプログラム（ＴＰ）と共に、前記テストプログラムのうちの少なくとも一つのテスト（ｔ１、ｔ２、...ｔ９）のフィーチャ仕様（２１）を受け取るように適合されたインタフェースであって、前記フィーチャ仕様（２１）は所定のテストを実行するのに必要なテストシステム能力を示す、前記インタフェースと；
    テスト毎に、それぞれのテストのフィーチャ仕様を前記対象テストシステムの能力と比較し、テスト（ｔ１、ｔ２、...ｔ９）の各々に対して、前記対象テストシステム（Ｔ１、Ｔ２、Ｔ３）が前記それぞれのテストを実行できるか否かを判断し、前記対象テストシステム（Ｔ１、Ｔ２、Ｔ３）の前記能力で前記テストを実行できる場合にテスト実行を開始するように適合されたフィーチャ仕様評価手段と；
    を備えることを特徴とするリソース制約管理ユニット。
22. 前記対象テストシステムの前記能力では前記テストを実行できない場合に、前記リソース制約管理ユニットが前記テストプログラムのテストの実行を開始しないように適合されること、
    を特徴とする請求項２１に記載のリソース制約管理ユニット。
23. 前記対象テストシステムの前記能力では前記テストを実行できない場合に、実際のテスト実行を前記テストのオフライン処理に置き換えるように適合されたオフライン処理機構をさらに備えること、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
24. 前記対象テストシステムの前記能力では前記テストを実行できない場合に、エミュレートしたテスト結果を出力すること、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
25. 各テストに対して、少なくとも一つの該当テストセットアップを前記対象テストシステムの前記テスタリソースにロードするように適合されたセットアップローダーユニットをさらに備えること、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
26. 前記セットアップローダーは、所定のテストを前記対象テストシステムで実行できないと前記フィーチャ仕様評価手段が判断する場合に、前記少なくとも一つの該当テストセットアップを前記対象テストシステムの前記テスタリソースにロードしないこと、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
27. 前記フィーチャ仕様が、少なくとも一つのピン単位テスタリソースに対して対応するフィーチャ集合を備えること、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
28. フィーチャ仕様評価手段が、前記対象テストシステムの前記能力が前記フィーチャ仕様に合致するか否かを判断するように適合されること、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
29. 前記フィーチャ仕様評価手段は、前記テスト中に使用する全ピン単位テスタリソースがそれぞれのフィーチャ集合に記された要件を満たすか否かを判断することによって、前記対象テストシステムが所定のテストを実行できるか否かについての判断するように適合されること、
    を特徴とする請求項２１又は先行する請求項のいずれか一項に記載のリソース制約管理ユニット。
30. テストプログラム（ＴＰ）の実行を所定の対象テストシステム（Ｔ１、Ｔ２、Ｔ３）に適応させる方法であって、前記テストプログラム（ＴＰ）は少なくとも一つのテスト（ｔ１、ｔ２、...ｔ９）を備え、前記テストプログラムは、前記テスト（ｔ１、ｔ２、...ｔ９）の各々に対して、前記対象テストシステムの前記所要フィーチャを特定するフィーチャ仕様を備え、前記方法は、
    各テスト（ｔ１、ｔ２、...ｔ９）に対して、前記テストの前記フィーチャ仕様を前記対象テストシステムの能力と比較するステップと、
    前記対象テストシステム（Ｔ１）で実行できるテストの部分集合（ＴＰＴ１）を判断するステップと、
    前記対象テストシステム（Ｔ１）で実行できるテストの前記部分集合（ＴＰＴ１）を実行するステップと、
    を含むことを特徴とする方法。
31. 前記対象テストシステムの前記テスタリソースの前記能力が前記それぞれのフィーチャ仕様に記された前記要件を満たす場合に、テストが実行可能であると判断されること、
    を特徴とする請求項３０に記載の方法。
32. 前記フィーチャ仕様が、テスト中に使用するピン単位テスタリソースの対象テストシステム能力を示すフィーチャ集合を含み、前記方法が、前記テスト中に使用する前記ピン単位テスタリソースの全てが前記それぞれのフィーチャ集合に記された前記要件を満たすか否かを判断するステップをさらに含むこと、
    を特徴とする請求項３０又は先行する請求項のいずれか一項に記載の方法。
33. 前記対象テストシステムが実行できないテストを無効にするステップをさらに含むこと、
    を特徴とする請求項３０又は先行する請求項のいずれか一項に記載の方法。
34. 前記対象テストシステムが実行できないテストの実行を前記テストのオフライン処理に置き換えるステップをさらに含むこと、
    を特徴とする請求項３０又は先行する請求項のいずれか一項に記載の方法。
35. 自動テスト装置又は他の任意のデータ処理システムで実行される際に、請求項３０から３４のいずれか一項の方法を実行する、好ましくはデータ記憶媒体に格納されるソフトウェアプログラム又は製品。

Images