JP2002505000A - 低コストで使用が容易な自動テスト・システム用ソフトウェア - Google Patents

Abstract

(57)【要約】 テスト・プログラムを開発し実行する低コストで使用が容易であるソフトウェアを備えた半導体デバイスの自動テスト装置である。テスタは、市販のスプレッドシート・プログラムを動作させるコンピュータ・ワークステーションを用いて制御される。この市販のスプレッドシート・プログラムは、プログラム開発環境を提供するアプリケーションとして設定されている。更に、市販のスプレッドシート・プログラムを用いて作られたプログラムが、半導体デバイスに対するテストの実行を制御する。テスタは、プログラムが容易であるが、これは、市販のスプレッドシート・プログラムを用いることにより広く知られたプログラミング・インターフェースが発生されることによる。このようにして、この市販のスプレッドシート・プログラムは、アプリケーションによって用いられるスプレッドシート機能を単に提供するのではなく、テスタを制御するソフトウェアを実現する。従って、自動テスト装置を制御するこのソフトウェアは、プログラムする又は修正を行うのが非常に容易である。また、プログラムするのも非常に容易である。

Description

【発明の詳細な説明】 低コストで使用が容易な自動テスト・システム用ソフトウェア 本発明は、広くは、半導体製造において用いられる自動テスト（試験）装置に 関し、更に詳しくは、そのようなテスト・システムのための制御ソフトウェアに 関する。 自動テスト装置は、半導体の製造において広く用いられている。半導体は、そ の製造の間に少なくとも１回はテストがなされるのが一般的であり、時には、製 造プロセスにおいて複数回のテストがなされることもある。すべての素子がテス トされるのであるから、テスト速度は、半導体の経済的な製造にとって重要であ る。ゆっくりとテストを行うのでは、半導体素子を製造するのに必要となる高価 な設備である装置を完全に用いないことになる。 現代の半導体素子は非常に複雑であり、多くの動作状態を有する。完全なテス トを実行するには、これらの動作状態のそれぞれを確認してみなければならない 。従って、自動テスト装置は、テスト・データを半導体デバイスに与え、多数の 測定を製造過程において行うように設計されている。図１には、従来技術による 自動テスト・システムが一般化された態様で示されている。完全で迅速なテスト を行うには、自動テスト・システムは、テスタ（試験装置）本体１１２と、コン ピュータ化されたワークステーション１１０と、操作デバイス（handling devic e）１１４とを含むのが一般的である。 コンピュータ・ワークステーション１１０は、操作デバイス１１４とテスタ本 体１１２との両方を制御する。コンピュータ・ワークステーション１１０は、半 導体デバイス（図示せず）をテスタ本体１１２上の多数のテスト・プローブ１１ ８と接触する位置に位置決めするように、操作デバイス１１４を制御する。多く の場合、テスタは、テスト・プローブ１１８を含む別個のテスト・ヘッドを含ん でいる。しかし、そのような区別は、本 発明には重要ではない。 ワークステーション１１０は、次に、テスト対象であるデバイスに対して一連 のテストを実行するように、テスタ本体１１２を制御する。それぞれのテストは 、制御信号がワークステーション１１０からテスタ本体１１２に送られるセット アップ部分を含むのが一般的である。制御信号は、通常、バス１１６を介して送 られるデジタル値である。これらの制御信号は、テストに必要な測定を行うよう にテスタ本体１１２内のハードウェアのコンフィギュレーションを定める。テス タ本体内部のハードウェアは、制御信号に従って、刺激を与え、テスト対象デバ イスからの応答を測定する。 図１には、テスタ本体１１２内のハードウェアがピン１２４として識別される 多数の回路を含んでいる様子が示されている。それぞれのピン１２４は、テスト ・プローブ１１８の１つに対して信号を発生し測定を行う。それぞれのピンは、 静的（static）な、すなわち直流信号を提供しうる。また、それぞれのピン１２ ４は、時には「バースト(burst)」とも称される状況では、変化するデータを提 供又は測定することもあり得る。 バーストの間には、テスタ本体１１２は、タイミング及びシーケンシング(seq uencing)回路１２０によって制御される。タイミング及びシーケンシング回路１ ２０は、ピン１２４のそれぞれに、関連するメモリ１２８から一連のデータ値を 読み出させる。それぞれのデータ値は、ピンがその関連するテスト・プローブ１ １８で特定の時点において与えるべき又は測定を予測すべき信号のタイプを示す 。ピンが測定値を予測値と比較すると、その結果もまたメモリ１２８に記憶され うる。 １回にすべてのピン１２４が提供すべき又は測定を予測すべき値を定義するデ ータ値の組は、「ベクトル」と称される。バーストの間には、多くのベクトルが 実行される。テスト対象デバイスの実際の動作条件をシミュレートするには、ベ クトルは、非常な高速で実行されなければならない。半導体デバイスをテストす るのに必要なバーストを定義するには、数百万のベクトルが存在する。これらの ベクトルは、典型的には、テスト・システムが特定のタイプのパーツをテストす るようにプログラムされている時刻 において、メモリ１２８にロードされる。このローディング・プロセスには数分 を要することがあり、それぞれのバーストに対して反復されない。むしろ、それ ぞれのバーストに対して、ワークステーション１１０は、どのベクトルがバース トの一部として実行されるべきかを示すコマンドを送る。バーストがいったん完 了すると、ワークステーション１１０は、バーストの結果を、メモリ１２８又は タイミング及びシーケンシング回路１２０から読み出す。 更に、テスタ本体１１２は、１つ又は複数の器具（instruments）１２６を含 む。１つの器具が、特定のテスト機能を実行する。器具は、例えば、正弦波など の特定のテスト信号を発生しうる。また、器具は、高速で信号をサンプリングし 、それによって、後でデジタル信号プロセッサによる解析が可能にすることもあ る。これらの機能は、あるバーストの一部として実行されることもあるし、バー ストとは別に実行されることもある。 １つのパーツの完全なテストは、時には「ジョブ」と呼ばれるが、直流測定又 は器具１２６による測定に対して散在する一連のバーストから構成される。バー ストは、テスト対象デバイスの特定の機能的属性(functional attributes)を測 定するのに用いられ得る。また、それぞれのバーストは、テスト対象デバイスを 直流測定が実行可能な状態におく目的だけに用いられることもある。テストのこ れらの構成要素が実行される順序は、時には「フロー」とも呼ばれるが、ワーク ステーション１１０内のソフトウェアによって決定される。 あるデバイスが完全にテストされる、又は、欠陥があると判断される時点まで テストされると、ワークステーション１１０は、制御信号を操作デバイス１１４ に対して発生する。すると、操作デバイス１１４は、次にテストされるべきデバ イスをテスタ本体１１２に提供し、プロセスが反復される。ワークステーション １１０は、また、特定のデバイスがテストに合格した又は失格したことに関する データを収集する。ワークステーション１１０は、このデータを処理し欠陥のあ るデバイスが廃棄されるようにすることができるし、また、欠陥の傾向に関する データを解析するなど、そ れ以外の機能を実行することもできる。 ワークステーション１１０の中のソフトウェアのもう１つの重要な機能として 、特定のデバイスに対するテストの開発（development）中や、更にはデバイス の設計それ自体の間にも、補助的機能を果たすことがある。開発の間には、テス ト・エンジニアは、テスタ本体１１２内部のハードウェアに対する設定などを特 定できなければならない。技術者は、また、テストのフローを特定できなければ ならない。テスタを制御するソフトウェアは、融通性があり、学習及び使用が非 常に容易であることが非常に望ましい。半導体チップの市場は、非常に競争が激 しく、多くの場合、技術革新によって左右される。従って、チップが可能な限り 迅速に開発され製造の準備が整うことは、重要である。テスト・エンジニアがテ スタのプログラム方法を学ぶ必要があるために遅れが生じるようなことは望まし くない。 図２には、ワークステーション１１０内のソフトウェアのための伝統的なソフ トウェア・アーキテクチャが示されている。このソフトウェアは、テストの開発 及び解析時に用いられる要素と、テストの実行時に用いられるソフトウェアとに 分けられる。 テストを定義する第１のステップは、一般的には、デバイス・データを特定す ることである。図２には、デバイス・データ開発ツール２１０が示されている。 伝統的には、これらのツールは、テスト対象である特定のデバイスに関するデー タを集め、そのテスタのためにカスタム開発されたデータベースに記憶している 。この情報は、これらをピン・グループ及びタイム・セット（time set）として 定義する。半導体デバイスは、多くのデバイス・リードを有する。これらのリー ドは、グループとしてまとまって動作することが多い。例えば、あるグループは 、アドレス・バス又はデータ・バスを表すことがあり得る。従って、あるツール によって、リードのグループを特定することが可能になる。別のツールによれば 、デバイス上の特定のリードとテスタ上のピンとの間の相関関係を特定すること が可能になる。場合によっては、特定のデータを、その値を別のデータ値に関係 付ける方程式によって定義することが可能である。しかし、従来技術では、 方程式を扱う能力は限定的なものであった。 他のツールによれば、信号のタイミングを特定することが可能となる。それぞ れのピン１２４は、タイミング「エッジ」に関係して定義される信号を発生又は 測定することができる。それぞれのピンには、１組のタイミング・エッジが存在 する。それぞれのエッジは、実行されるそれぞれのベクトルに対して１回生じう る。それぞれのエッジが生じる時間は、プログラムすることができる。それぞれ のピンに対するそれぞれのエッジに対するプログラムされた時間が、１組のタイ ミング・データを表す。異なるバーストにおいて又は同一のバーストの中でも所 望のプログラミングは異なりうるので、複数のタイム・セットが特定されるのが 通常である。それぞれのタイム・セットの組が入力され記憶されなければならな い。この情報は、伝統的には、特定のテスタに対して設計されたカスタム・デー タベース・プログラムを介して入力されてきた。カスタム・データベースを介し て入力された情報は、デバイス・データ・ファイル２１４に記憶される。 入力されなければならない別のタイプの情報は、あるテストのために実行され なければならない特定のステップである。この情報は、テスト・テンプレート２ ２０において特定される。テンプレートとは、どのような特定のデバイス・デー タ・ファイルの値とも独立に記述されるステップの組である。テスト・テンプレ ートは、特定のテスト・システムに対して定義されたフォーマットのデータ・フ ァイルとして記録されてきた。これらのファイルは、一般的には、テスタを製造 した者によって提供され、典型的には、高速な実行速度で知られているＣプログ ラミング言語などのプログラミング言語で書かれている。場合によっては、テス ト・エンジニアが、テスト・テンプレートをカスタマイズする。 テスト・テンプレートは、コンパイラ２５０によってコンパイルされる。コン パイルされたプログラムは、翻訳された（interpreted）プログラムよりも高速 に実行可能であると、通常考えられている。テスタにおける実行速度に関する要 件のために、コンパイルされたテスト・プログラムの方が好まれてきた。 カスタム・フロー・ツール２１８はまた、テストの順序の特定を可能にする。 フローは、プログラム・フロー２２２として記録される。伝統的には、フローは 、テーブルへの一連のエントリとして特定されるが、伝統的なプログラミング言 語と類似する特別なプログラミング言語でも可能である。 フローのステップを特定するために、特定のテスト・テンプレートを、そのス テップに対して用いられるべきデバイス・データ・ファイルと共に特定すること もできる。あるテンプレートによって、実行されるバーストが特定される。また 、他のテンプレートによって、テストの結果がテスタ１１２の中のハードウェア から読み出されることや、そのハードウェアが特定の方法でセットアップされる ことが決まる。フローの他のステップとして、伝統的なプログラミング言語にお いて見られる分岐（branching）及びルーピング（looping）命令などの制御ステ ートメントがある。 プログラム・フローは、カスタム・エグゼクティブ（custom executive）２２ ４として機能する。カスタム・エグセクティブ２２４は、プログラム・フローに おいて特定されたテンプレートの中に、デバイス・データ・ファイル２１４から のデータを満たす。これによって、テスト・オブジェクトが作成される。 テスト時間においては、カスタム・エグゼクティブ２２４は、テスト・オブジ ェクトを処理し、テスタ１１２を実際に制御する。カスタム・エグゼクティブ２ ２４は、データ及びコマンドをデバイス・ドライバ２２８を介してテスタ１１２ に送る。カスタム・エグゼクティブ２２４の動作速度が全体のテスト時間を決定 するのに大きな意味を有するので、カスタム・エグゼクティブは、伝統的に、プ ログラマにその実行を特定し従って最適化するオプションを与えるＣ言語などの プログラミング言語で書かれてきた。 デバイス・ドライバ２２８は、バス１１６を介して情報を送受信してテスタ１ １２内部のハードウェアを制御するプログラム手順である。デバイス・ドライバ ２２８は、低レベルのハードウェア制御を実行するので、そ のような制御を許容するＣ言語などのプログラミング言語で書かれている。 すべてのデバイスができるだけ迅速にテストされることが、強く望まれる。従 って、プログラム・フローにおけるそれぞれのステップを実行するのに要求され る時間は、非常に短いことが望ましい。テスタ１１２又は操作デバイス１１４が コマンドに応答する又はそれを「実行」するのにかかる実際の時間は、ワークス テーション１１０内のソフトウェアとは無関係である。しかし、ワークステーシ ョン１１０内のソフトウェアは、それぞれのコマンドを設定するのにかかる時間 の長さである「オーバヘッド」を決定する。１つのジョブの実行時間を非常に短 くするために、かなりの努力がなされている。従って、オーバヘッド時間もまた 非常に短いことが非常に重要である。従来技術のシステムでは、これは、カスタ ム・エグゼクティブ２２４を用いて達成された。カスタム・エグゼクティブ２２ ４は、伝統的にＣ言語で書かれている。Ｃ言語は、設計されうるエグゼクティブ の開発が迅速になされることを可能にする言語であると広く認められている。 Ｃ言語でカスタム・エグゼクティブ２２４を準備するのに伴う主な問題は、そ のようなエグゼクティブを書くのに非常に長い時間がかかるということである。 そのための費用は、文字通り数百万ドルになる可能性があり、数年の努力を要す る可能性がある。カスタム・エグゼクティブを有することに伴う別の問題として 、ユーザ・インターフェースもまたカスタム・インターフェースであるというこ とがある。これは、テスタを操作している技術者は、テスタをプログラムする方 法を学習するのに時間をかけなければならないことを意味しているが、これは、 ほとんどのユーザにとって望ましくない。しかし、これまでは、これらの短所は 、テスタを迅速に動作させるためには必要であると考えられてきた。 Ｃ言語でのカスタム・エグゼクティブの別の欠点として、ユーザ・インターフ ェース能力が極めて限定される可能性が大きいということがある。ユーザ・イン ターフェースは、テスタにとって特に重要である。というのは、テスタは、非常 に異なったスキルのレベルを有する複数の人間によっ て様々な時に操作されるからである。デバイス及びテストの開発段階では、テス タは、熟練度の高い技術者によって操作される。しかし、いったんデバイス及び テストが開発されてしまうと、テスタは、中程度のスキルを有するプロダクショ ン・ワーカー（production worker）によって操作される。従って、ユーザ・イ ンターフェースは、生産段階では、極めて単純化されていなければならない。 テスタは、伝統的には、ワークステーション１１０上で動作する別個の生産イ ンターフェースを有している。ユーザ・インターフェースは、伝統的には、１つ のメニュとして実現されてきた。テスト・エンジニアは、メニュ上に、生産段階 のテストにおいてオペレータが必要とするコマンドだけを配置する。従って、テ スタと共に提供されるソフトウェアでは、メニュの形式でユーザ・インターフェ ースを作成することしかできなかった。不運なことであるが、メニュは階層的で あるが、多くの操作はそうではない。従って、非階層的なインターフェースを迅 速かつ容易に開発することを可能にするソフトウェアをテスタに提供することが 望ましいだろう。 図２には、ワークステーション１１０に含まれる他のソフトウェア要素が示さ れている。メモリ１２８（図１）にロードされたベクトルは、大量のデータを表 す。これらは、通常、ソフトウェア・シミュレータによって開発されるか、又は 、自動化された方法で導かれる。これらは、ユーザによってマニュアルで入力さ れるのが通常である。ベクトル開発ツールによって、ユーザは、ベクトル・ファ イルを編集することが可能になり、ベクトル・ファイルは、その後で、ベクトル 及び結果ファイル２３４に記憶される。ベクトル・ファイルは、テストに先立っ て、メモリ１２８にロードされる。 同様にして、多数の連続するサイクルの間にテスト対象デバイスにおいて例え ば測定された値を表している大量のデータがテストの間に集められた場合には、 それは、バス１１６（図１）を介して戻される(passed back)。 ベクトル・ファイル２３４は、デバグ及び解析ツール２３０によってもアクセ ス可能である。デバグ及び解析ツールは、テストを開発しているエ ンジニア又はテスト対象のパーツを開発しているエンジニアによって用いられる 。これらのツールによれば、ベクトルや結果をグラフィカルに表示したり、ユー ザが、ベクトル・ファイルを修正したり予測される値を測定された値の上に重ね 書きすることが可能になる。更に、デバグ及び解析ツールによると、ユーザは、 テスタ１１２におけるハードウェアを直接にプログラムすることができるように なる。従って、これらのツールは、時には、デバイス・ドライバ２２８をコール することもある。 典型的なシナリオでは、デバイス・データ及び開発ツール２１２と、テスト及 びフロー開発ツール２１８と、デバグ及び解析ツールと、テスト・ベクトル開発 ツール２３２とは、テスタと共に供給される。テスト対象デバイスがまだ開発中 である間も、ユーザは、デバイス・データ及び開発ツール２１２を用いて、デバ イスの特性を特定する。テスト及びフロー開発ッール２１８は、デバイス上でな されるいくつかのテストを特定するのに用いられる。 サンプル・デバイスが製造される。テスト・プログラムが動かされ、デバグ及 び解析ツールが用いられて、これらのサンプル・デバイスがチェックされる。こ のプロセスでは、サンプル・デバイスにおける欠陥が検出される又はプログラム に伴う問題点が検出される。これらの問題点は、訂正され、更なるテストが作ら れ動作される。 開発プロセスが終了すると、半導体デバイスは、テスト・プログラムと共に、 生産に移行される。生産においては、それぞれのパーッは、製造される際にテス トがなされる。 発明の概要 以上の背景を鑑みると、本発明の目的は、迅速かつ安価に開発することができ るテスタ制御ソフトウェアを提供することである。 更に、ユーザが容易かつ迅速に使い方を学習できるテスタ用ソフトウェアを提 供することも本発明の目的である。 以上の及びそれ以外の目的は、市販のスプレッドシート・ソフトウェアを用い て、デバイス・データ・ファイルとテスト・テンプレートとプログ ラム・フローとを開発することで達成される。市販のスプレッドシート・ソフト ウェアが、これらの機能のすべてを、要求される速度をもって、非常な低コスト で提供することができ、更に、ユーザが高価なトレーニングを受けなくとも学習 できる標準的なユーザ・インターフェースを与えてくれるという長所を有するこ とを見いだされた。 図面の簡単な説明 本発明は、次の添付した図面と以下の詳細な説明を参照することによって、よ りよく理解されるはずである。 図１は、従来技術によるテスタのハードウェア・ブロック図である。 図２は、従来技術によるテスタのためのソフトウェアのソフトウェア・ブロッ ク図である。 図３は、本発明によるソフトウェアのソフトウェア・ブロック図である。 図４Ａないし９は、本発明と共に用いられるデバイス・データ・シートを図解 している。 図１０Ａないし１１Ｃは、本発明と共に用いられるフロー・データ・シートを 図解している。 図１２Ａ及び１２Ｂは、サンプル・テスト・テンプレートを示している。 図１３は、本発明によるフロー制御ソフトウェアの動作を示している図である 。 図１４は、本発明によって容易に実現され得るオプショナルなプログラミング ・インターフェースである。 図１５は、別の市販のスプレッドシート・プログラムを用いて実現されるデバ イス・データ・シートの例である。 図１６Ａ及び１６Ｂは、オプショナルなデバイス・データ及びフロー開発ツー ルの例である。 好適実施例の説明 図３は、従来技術によるテスタにおけるカスタム・ソフトウェアの機能のほと んどは市販のスプレッドシート・プログラムによって実行されうるという認識か ら生じるユニークなソフトウェア・アーキテクチャを示して いる。この好適実施例では、来国ワシントン州レドモンド（Redmond）所在のマ イクロソフト社（Microsoft）によるエクセル（EXCEL）が用いられる。 エクセルは、ユーザが「ワークブック(workbook)」を作成することを可能にす るスプレッドシート・プログラムである。ワークブックは、異なるスプレッドシ ートとして構成されたデータの集まりである。スプレッドシートとは、単に、セ ル(cell)の格子(グリッド:grid)であり、それぞれのセルは、１つのデータ又は データ値が他のセルにおける値からいかにして計算されるべきかを定義する方程 式を保持する。セルは、順序付けられたグリッドに現れる。セルは、一般的に、 関連するデータが特定のロー（列、row）又は特定のコラム（行、column）にあ るセルの中に生じるように構成されている。セルのそれぞれに対して作用するツ ールは、データが何を表しているかとは無関係に、同一である。ワークブックの 内部では、スプレッドシートのどれにもアクセス可能であり、あるスプレッドシ ートの中のデータを別のスプレッドシートにおいて用いることができる。 エクセルは、また、スプレッドシートを定義し、「アプリケーション」を開発 するという特徴も含む。エクセルは、会計システムの開発などのアプリケーショ ンに用いられてきた。スプレッドシートの外観を特定して、ユーザが、特定のタ スクに関係するセルだけを見るようにすることができる。表示を、『エクセル・ アプリケーション開発者ガイド』やキュー・コーポレーション（Que Corporatio n）から１９９６年に刊行されたJeff Webbによる"Using Excel Visual Basic fo r Applications"（ISBN O-7897-0269-X）に説明されている他の方法に変更する こともできる。これらの書籍は、この出願において援用する。 エクセルを用いてアプリケーションを作成することができる第２の方法では、 ビジュアル・ベーシック（Visual Basic）を用いる。ビジュアル・ベーシックは 、エクセルの中に組み入れられるプログラミング言語である。その名称が示唆す るように、ビジュアル・ベーシックの基本的な目的は、ユーザがデータを入力す るために与えられる際のスプレッドシートの外観を制御することである。ビジュ アル・ベーシックは、一般的には、複数の スプレッドシートのどれをアプリケーションが実行されている間の任意の時点に おいてユーザに提供するかを選択するのに用いられる。選択は、一般的には、ユ ーザによって入力されたデータ又はコマンドに基づいており、それによって、任 意の与えられたタスクが実行されている間に、ユーザは、そのタスクに関連する データを見ることになる。従って、ビジュアル・ベーシックは、動作しているア プリケーションがユーザにとってどのように見えるのかを制御するのに用いるこ とができる多くのコマンドを含む。ビジュアル・ベーシックは、また、分岐（ブ ランチング：branching)及びルーピング(Iooping)のための条件ステートメント などのプログラム・フローを制御するプログラミング・コマンドを含む。 本発明者は、半導体テスタのワークステーションにおいて用いられるときにテ ストの実行を制御するだけでなく、テスト・テンプレートを書くのにも、ビジュ アル・ベーシックを用いることができることを発見した。特に、エクセルなどの 市販のスプレッドシート・プログラムをカスタマイズして、データ及びテスト・ テンプレートからのテスト・プログラムを非常に迅速にアセンブルすることがで きるので、カスタム・エグゼクティブと比較してテストを実行する速度がほとん ど失われないということを発見した。この認識によって、多数の長所を達成する ことができた。このようなソフトウェア・アプリケーションの開発は非常に迅速 である。更に、ほとんどのプログラマは市販のスプレッドシート・プログラムに 親しんでいるので、誰かが、そのアプリケーションの使用法を学習するのは非常 に容易である。更にまた、テスタ制御ソフトウェアは、コンテキスト・センシテ ィブなヘルプや編集コマンドなど、カスタム・スプレッドシート・プログラムの 中に組み込まれている多くの特徴を利用することができる。 図３は、デバイス・データ及びフロー開発ツール３１０を示している。この好 適実施例では、これらのツールは、エクセル・ワークブックの中のスプレッドシ ートをカスタマイズすることによって、実現される。デバイス・データを保持す るためには、ピン・マップと、それぞれのピンにおいて印加される信号のレベル と、タイム・セットとに対するスプレッドシー トが存在する。チャネル・マップ、様々な定数値の仕様、エッジ・セットなどの データに対する他のスプレッドシートも、オプションとして、存在しうる。それ ぞれのタイプのスプレッドシートは複数あり得るが、これは、異なるデータ値が 異なる種類のテストに必要であるからである。それぞれのスプレッドシートは、 「データ・セット」と称される。ある好適実施例において用いられるデバイス・ データのためのスプレッドシートが、図４ないし９において図解されている。 テスト・フローは、ワークブック内のスプレッドシートとしても表される。テ スト・フローは、実行される一連のステップによって特定される。それぞれのス テップと関連するデータが存在し、それぞれのステップは、スプレッドシートに おける１つのローとして表される。それぞれのステップにおいて実行される厳密 な動作は、１つ又は複数のフラグの状態によって影響されうる。ステップの実行 によって、これらのフラグのいずれかの状態が変更されることもあり得る。これ により、ブランチング又はそれ以外の同様な制御の構築が達成されうる。 フローにおけるあるステップに対して特定されるデータの１つとして、どのテ スト・テンプレートがどのデータ・セットと共に用いられるかがある。テスト・ テンプレートとそのテスト・テンプレートと共に用いるデータ・セットとは、「 インスタンス(instance)」と称される。インスタンスは、スプレッドシートとし ても記述することができる。ある好適実施例において用いられるフロー情報のた めのスプレッドシートが、図１０ないし１１に図解されている。 それぞれのスプレッドシートの構造は、ワークステーション１１０内のソフト ウェアによって定義される。それぞれのスプレッドシートの構造は、市販のスプ レッドシート・プログラムの広く知られたメカニズムを用いてテンプレートを特 定することによって、作成される。それぞれのスプレッドシートに対するデータ 値は、テスト・エンジニアによって入れられ、これらの値は、テスト対象のデバ イスのタイプに左右される。 本発明によるテスタ制御ソフトウェアは、従来技術の場合のように、デ バグ及び解析ツールとテスト・ベクトル開発ツールとを用いる。これらのアイテ ムは、簡潔にするために、図３には示されていない。この好適実施例では、ベク トル・ファイルは、市販のスプレッドシート・プログラムで容易に扱うには、大 きすぎる。その理由で、これらは、エクセルにおいては実現されない。 次に図４Ａ及び４Ｂを参照すると、ピンマップ・デバイス・データ・シートが アクセスされている間のワータステーション１１０上の表示が示されている。図 ４Ａ及び４Ｂが、１つのウィンドウを表す。このウィンドウは、ワークステーシ ョン１１０上のエクセル・ソフトウェアによって表示 ト社の商標）オペレーティング・システムによって制御されるので、一度に複数 のウィンドウを、スクリーン上に表示することができる。 それぞれのウィンドウは、いくつかのフィールドを含む。フィールド４１０は 、ツール・バーとして知られている。フィールド４２０は、メニュ・バーとして 知られている。フィールド４３０は、データ・セル・フィールドである。フィー ルド４４０は、タブ・フィールドである。これらのフィールドのコンテンツは、 多くの場合に、ワークステーション１１０を制御するソフトウェアの準備の一部 として特定される。しかし、これらのフィールドのそれぞれの配置及び一般的な 動作は、エクセルを用いて開発されるすべてのアプリケーションに対して標準的 である。従って、本発明によっても、エクセルが、半導体テスト・システムの制 御に用いられ、エクセルや他のエクセル・アプリケーションに親しんでいる者で あれば、このソフトウェアの使用法を一般的に理解するであろう。このようにし て、本発明によれば、使用が容易であるから、カスタム・ソフトウェア・システ ムと比較して、著しい時間及びコストの削減が達成される。 ツール・バー４１０は、ツール・アイコン４１２及び４１４など、多くのツー ル・アイコンを含む。後により詳しく説明されるように、テスタ１１２のための テスト・プログラムは、様々なスプレッドシートにデータを入れることによって 、大部分が特定される。データは財務上のデータや市 販のスプレッドシート・プログラムが通常用いられるそれ以外のタイプのデータ とは異なり半導体テスタに対する制御情報を表すという事実にもかかわらず、デ ータは、同じように操作されなければならない。従って、データ操作ツールが必 要であるが、エクセルと共に用いられる標準的なデータ操作ツールでよい。これ らのツールは、データのコピー、データの削除、スプレッドシートのコンピュー タ・ファイルへのセーブなどの機能を実行する。これらのツールは、マウスやト ラックボールなどの入力デバイスを操作して特定のツール・アイコンを選択する ユーザによってアクセスされる。 更に、フィールド４１０は、カスタム・ツールを用いてカスタマイズすること ができる。エクセルによれば、カスタム・ツールを特定してツール・バーに追加 することができる。望む場合には、テスト・プログラムの生成に対して一意的な 機能を実行するカスタム・ツールを、ツール・バー４１０に追加することもでき る。例えば、一方で、テスト・プログラムを実行するカスタム・ツールもあれば 、他方では、デバイス・データをチェックしてエラーや非一貫性(不一致)を検出 するカスタム・ツールもある。 メニュ・バー４２０は、４２２や４２４などのシステム・メニュ・アイテムを 含む。これらのアイテムは、ユーザによってアクセスされると、このシステム・ メニュ・アイテムに関係する作用の複数の選択肢を提供するように拡張する。例 えば、ファイル（FILE）というシステム・メニュ・アイテムの下には、保存(sav e)、削除(delete)、印刷（print）などの選択肢がある。ッール・バー４１０と メニュ・バー４２０とからアクセスできるツールの間にはいくらかの重複がある 。一般的には、ほとんどの共通のツールは、ツール・バー４１０上に現れ、シス テム・メニュ・アイテムの１つの下にある選択肢の１つとして複写されることが 多い。 メニュ・アイテムのほとんどは、自動テスト・システムに用いられるデータに 特定ではない機能を表す。従って、エクセル・アプリケーションに対するデフォ ルト条件として提供されるシステム・メニュ・アイテムを、ほとんどのメニュ・ アイテムに対して用いることができる。しかし、自動 テスト・システムに特定の機能も多く存在する。この好適実施例では、これらの 機能は、ユーザがカスタム・メニュ・アイコン４２６からの選択肢を選択するこ とによって実行される。エクセルは、上述したエクセル・アプリケーション開発 ガイドにおいて提供されている命令に従って、アプリケーションに対してカスタ マイズすることができる。カスタム・メニュの選択肢は、システム・メニュ・ア イテムと同じメニュ・バー又は別個のカスタム・メニュ・バーの上に現れる。 デバイス・データを含むデータ・シートに対しては、カスタム・メニュ・アイ テムによって、データ・シートの「有効化確認(validate)」を可能にする。すで に述べたように、データ・シートにおける様々なセルは、データ有効化機能をそ れらと関係付けしている場合がある。これらのデータ有効化機能は、現在のデー タ・シートのコンテキストにおける不適切なデータ値を検出することができる。 例えば、特定のフィールドが数値を保持することを意図されていれば、入力され る値が文宇を含む場合には、エラーが検出されうる。また、別のセルが正の値だ けに限定されている場合には、入力される値が負であれば、エラーが指示される 。しかし、複数のシートに依存する有効化機能もある。例えば、ピンの総数は、 １つのシート上で特定され、ある属性は、それぞれのピンに対して別のシート上 で特定される場合がある。属性があまりに少数のピンに対して特定されている場 合には、これは、２つのシートを比較することによって検出されるだけである。 様々な有効化機能を、テスタ・ハードウェアの要件及び制限に基づいて定義する ことができる。これらの有効化機能は、カスタム・メニュ・アイテムから選択す ることができる。また、同じ機能を、ツールバー・ボタンを用いて選択すること もできる。 更に、フロー・データ・シートに対しては、そのフローによって定義されるテ ストを実行する方法が存在することが要求される。フロー・シートと関連するカ スタム・メニュ・アイテムによって、フローが実行され、また、実行の態様も決 定される。例えば、フローの実行においてブレーク・ポイントを設定する、又は 、一度に１つのステップずつフローを実行する ことが望ましい場合がある。これらの機能のそれぞれは、カスタム・メニュ又は ツールバー・ボタンからのメニュ選択として特定することができる。 カスタム・メニュ・アイテムは、シートのそれぞれとは異なることがある。エ クセルによると、その何らかの属性を、それぞれのデータ・シートに対して特定 することが可能である。これらの属性の１つに、カスタム・メニュ・アイテムが ある。このようにして、カスタム・メニュを、特定のシートに表示される特定の データ・タイプに適する操作だけを含むように修正することができる。以下では 、ソフトウェア制御テスタ１１２によって実行される他の操作について説明する 。これらの操作は、カスタム・メニュ上に現れるメニュ・アイテムにマップされ る機能として定義することができる。 データ・セル・フィールド４３０は、テスタ１１２を制御するようにカスタマ イズされたデータ・セルを含む。セルのレイアウトは、エクセルによって提供さ れる。しかし、ウィンドウにおいて見ることができるロー及びコラムの数は、エ クセルをプログラムすることによって、決定される。図４Ａ及び４Ｂは、デバイ ス・ピンマップ・データ・シートを表している。従って、データ・セル・フィー ルド４３０は、デバイス・ピンマップ・データを受け取るように設定されたセル のロー及びコラムを含む。 半導体テスタでは、デバイス・ピンマップ(device pinmap)は、論理的な名称 を物理的なピン１１８（図１）に、テスト・プログラムが動いている間にこれら のピン１１８がどのようにテスト対象デバイスと接触するかに基づいて、割り当 てる。データ・セル・フィールド４３０は、データ・セル４３２Ａ、・・・、４ ３２Ｄの４つのコラムと共に示されている。これらのコラムのそれぞれは、先頭 に、ヘッダ・セル４３４などのセルを有する。ヘッダ・セル４３４は、そのコラ ムの残りのセルに入れられるデータのタイプの記述を含む。スプレッドシートが エクセルにおいて定義されるときには、ヘッダ・セルなどのいくつかのセルには 、固定値を与えることができる。 データを入力しチェックするための規則(ルール)は、図４Ａ及び４Ｂで は見ることができない。しかし、市販されているスプレッドシート・プログラム の特徴の１つとして、様々なセルに入力される際にデータが有効化されるという ことがある。また、データ・セルによっては、他のセルに入力された値に基づい て計算されうるものもある。市販のスプレッドシートは、大量の財務データを入 力するなどの目的で、この特徴を備えているように開発された。しかし、データ をテスタ制御のために用いる場合でも、いくつかのデータ入力規則は可能であり 、用いることができる。 図４Ａ及び４Ｂにおける別のフィールドとして、タブ・フィールド４４０があ る。タブ・フィールド４４０は、４４２及び４４４などの一連のタブを含む。そ れぞれのタブは、テスト・プログラムを含むワークブックの中にある１つのスプ レッドシートを表す。ユーザは、タブの１つを付勢する（アクティブにする）こ とによって、どのスプレッドシートがアクティブであるかを選択する。図４Ａ及 び４Ｂの図解では、pinmap.pmpという名称を有するタブ４４３が、他のタブの最 上位にある。これが選択されたタブであり、図４Ａ及び４Ｂに示されているピン マップ・スプレッドシートに対応する。 タブ・フィールド４４０は、すべてのデバイス・データを１つのワークブック としてセットアップするという重要な効果を図解している。異なるタイプのデー タが異なるツールに入力されていた従来技術によるテスタとは対照的に、すべて のデバイス・データが、１つのエクセル・ワークブックに入力される。すべての データを１つのワークブックにおいて有することによって、１つのスプレッドシ ートにおけるデータ値が別のスプレッドシートに入力されたデータに依存するこ とが可能となる。更に、これにより、テスト・プログラムを開発している人間が 、異なるタイプのデータに対するシートの間で迅速に切り替えを行うことが可能 となる。テスタのためのカスタム・プログラム環境が適切に開発された場合には これらの操作のそれぞれが可能であり得るのに対し、データを１つのプログラミ ング・ツールから別のプログラミング・ツールに送ることの複雑性なしに、この 簡潔性が比較的低コストで達成される。更に、これは、プログラマが迅速 に理解することが概念的に容易であるような態様で実現される。 図５を参照すると、第２のデバイス・データ・スプレッドシートが示されてい る。図５は、チャネル・マップ(channel map)データが入力される間に現れるワ ークステーション１１０のスクリーン上のウィンドウを示している。チャネル・ マップ・データはピン・マップ・データとは異なっているが、図４Ａ／４Ｂと図 ５とのスクリーン表示は非常に類似していることに注意することは重要である。 図５におけるスクリーン表示は、図４Ａ及び４Ｂと同じフィールドを有する。 ツール・バー５１０は、ツール・バー４１０と同じである。メニュ・バー５２０ は、メニュ・バー４２０と同じである。メニュ・バー５１０におけるいくつかの メニュ・アイテムがメニュ・バー４１０におけるアイテムと異なることはあり得 る。例えば、いくつかの機能はチャネル・マップ・データにだけ適用可能である ような場合には、そうである。その場合には、これらの機能に対するメニュ・ア イテム又はサブメニュ・アイテムは、メニュ・バー５１０にだけ現れる。好適実 施例では、表示されているスプレッドシートにおけるテスタ・データのタイプに 依存するこれらの機能は、カスタム・メニュ・アイテム５２６の下のサブメニュ ・アイテムとして現れる。また、データに依存する機能は、カスタム・ツール・ バー・アイテムを介してアクセスすることもできる。 テスタのためのソフトウェアを実現するのに用いられる市販のスプレッドシー トは、異なるタイプのデータ・シートの定義を許容し、更に、表示されるサブメ ニュ・アイテムが用いられるデータ・シートのタイプに依存することを許容する という特徴を含むことが好ましい。 タブ・フィールド５４０では、それぞれのタブがその上に２つの部分からなる 名称を有していることに注意すべきである。第１の部分は、スプレッドシートに 対する識別子である。名称の第２の部分、又は、拡張子は、スプレッドシートの タイプである。例えば、図５は、Channel Map.cmpとラベル付けされたタブを示 している。チャネル・マップを定義するタイプであるデータを保持するすべての スプレッドシートは、.cmpという拡張子を 有する。しかし、テスト・エンジニアが特定の識別子を選択する。好適実施例で は、ワークステーション１１０上で動いている市販のスプレッドシート・プログ ラムによれば、アプリケーションの開発者は、そのタイプのスプレッドシートに 対してどのメニュ・アイテム及びサブメニュ・アイテムがメニュ・バー４２０上 に現れるかを特定することができる。 次に、図６を参照すると、スペック・シート（spec sheet）に対するスプレッ ドシートが示されている。他のすべてのデータ・ツールと同じように、このスプ レッドシートは、ツール・バー６１０と、メニュ・バー６２０と、タブ・フィー ルド６４０とを有している。タブ・フィールド６４０は、「SpecSheet,sps」と ラベル付けされた現在のスプレッドシートがハイライトされて示されている。同 様に、SpecSheetは、多くのデータ・セルがロー及びコラムとして構成されてい るデータ・フィールド６３０を有している。ここで、それぞれのローは、特定の テスト対象デバイスと関連するパラメータに対するシンボルを含む。それぞれの パラメータには、様々な情報が与えられる。図６は、データ・フィールド６３０ のそれぞれのローにおける７つのコラムを示している。シンボル名に加えて、そ れぞれのローは、値と、その値に対する単位と、シンボルの説明のためのテキス ト・フィールドと、適切に動作するパーツのための最小値及び最大値と、コメン ト・フィールドとを含む。データ・シートはすべて１つのエクセル・ワークブッ クにおいて開発されるので、これらのシンボルは、他のスプレッドシートにおけ る名称によって参照することができる。より重要なこととして、それぞれのシン ボルと関連するパラメータは、他のスプレッドシートにおいても用いることがで きる。更に、スペック・シートの名称は、テスト・インスタンスが開発される際 に、特定のテスト・テンプレートにパラメータとして送られうる。これによって 、テスト・テンプレートが、テスト対象デバイスが仕様の範囲内で動作している かどうか（すなわち、テストに合格なのか不合格なのか）を決定するなど、スペ ック・シート・データと比較することが可能になる。 図６は、１つの仕様シートを示している。１つのジョブの中において、 異なるタイプのテストのために異なる仕様が要求されることもあり得る。従って 、複数の仕様シートを用いることができる。データ・マネジャ３１６との関係で 後に説明されるように、特定のタイプを有する複数のデータの組を有するための 用意（provisions）がなされている。 図７は、エッジ・セット(edge set)を定義するのに用いられる別のデバイス・ データ・シートを示している。図１に示されているように、テスタ１１２は、複 数のピン１２４を含む。それぞれのピンは、それぞれがエッジを発生しエッジ発 生器と称される複数の回路を含む。エッジは、ピン１２４による何らかの作用を 計時するのに用いられる信号である。例えば、ピンによって生じるパルスの開始 及び停止時間などのパラメータを制御する４つのエッジ信号が存在しうる。それ ぞれのエッジが発生される時間は、プログラムすることができる。１つのピンに 対するそれぞれのエッジがプログラムされる時間は、エッジ・セットとして定義 される。エッジが特定のピンに対してプログラムされる時間はジョブの間に変化 しうるので、それぞれのピンに対して複数のエッジ・セットがあり得る。 図７は、１つのピンに対するエッジ・セットを示している。コラム７５０は、 エッジ・セットが特定されるピンは、「QdataPins」と称されることを示してい る。他のピンに対するエッジ・セットは、データ・フィールド７３０にローを更 に加えることによって追加することが可能である。コラム７５２は、ピンQdataP insに対する１つのエッジ・セットは、「LooseFunction 1」と称されることを示 している。データ・フィールド７３０にローを加えることによって追加すること が可能である。 コラム７５４及び７５６は、ピン１２４をセットアップし所望の信号を発生す るのに必要なそれ以外の情報を与える。コラム７５８は、そのピンの中のエッジ をリスト化し、隣接するコラム７６０及び７６２は、これらのエッジが生じる時 間に対する値を与える。 コラム７６０及び７６２は、市販のスプレッドシートを用いてテスタ１１２を 制御することの有益な長所を図解している。スプレッドシートは、自動的に方程 式から値を計算することができる。従って、コラム７６２に よって、それぞれのエッジに対する時間値が、他のスプレッドシートにおいて定 義された他の定数又はパラメータとの関係で方程式として特定されることを可能 になる。コラム７６０は、そのフィールドに対してプログラムされた数値がコラ ム７６２における方程式を評価することによってスプレッドシート・プログラム によって自動的に計算されることを示している。 セル７６６、７６８、７７０及び７７２は、市販のスプレッドシート・プログ ラムを用いることによって得られる他の効果を示している。データ・フィールド ７３０におけるドロップ・ダウン・リスト・ボックスは、データ・フィールド７ ３０におけるデータ・セルの表示又は値を制御するのに用いることができる。こ れらのセルは、ドロップ・ダウン・ボックスとして実現されるが、これは、エク セルにおける標準的なオブジェクトである。それぞれのドロップ・ダウン・ボッ クスは、固定された数の値の中の１つを有することができる。これらの値は、固 定されたリストとして、又は、ワークブックの中のスプレッドシートの１つに入 力された値を参照して特定することができ、入力された値が変化すると、これら の値も変化する。 テスタ１１２に多数のピンが与えられると、エッジ・セット・スプレッドシー トは、潜在的に多くのローを含みうる。セル７６６、７６８、７７０及び７７２ は、一度に表示されるデータの量を制限するのに用いることができる。セル７６ ６は、特定のピン又はピン・グループの名称を含む。そのピン又はグループ内の 複数のピンに対するエッジ・セットだけが、データ・フィールド７３０の中に表 示される。同様にして、セル７６８及び７７０は、特定のタイミング・モードと 選択された数のエッジだけとに対するエッジ・セットを表示する。セル７７２は 、同様に、ドロップ・ダウン・ボックスであるが、値コラム７６０に入力される 値に対する単位を特定するのに用いられる。 図８Ａは、エクセル・ワークブック内の別のデータ・シートを示している。図 ８Ａにおけるシートは、タイム・セットに対するデータを与えており、他のデー タ・シートと同じフォーマットを有している。タイム・セッ トは、エッジ・セットの集合であり、ピン１２４のそれぞれに１つが対応する。 複数のタイム・セットが定義され、異なるプログラムされた時間が１つのジョブ の中で用いられることも多い。 図８Ａは、タイム・セットの名称の上にデータの入力を許容するコラムを示し ている。周期は、そのタイム・セットとピン又はピン・グループと関連している 。それぞれのピン又はピン・グループに対しては、テーブル内に１つのローが存 在する。それぞれのピン又はピン・グループに対しては、そのピンのエッジに対 するプログラムされた時間がエッジ・セット又は方程式のどちらかをを参照する ことによって特定されることを可能にするコラムが存在する。図８Ａはまた、ド ロップ・ダウン・ボックス８３２Ａ及び８３４Ａを示している。ドロップ・ダウ ン・ボックス８３２Ａは、どのタイム・セットが表示されるかを選択する。ドロ ップ・ダウン・ボックス８３４Ａは、すべての時間値が表示される単位を指定す る。 図８Ｂは、市販のスプレッドシート・プログラムを用いる結果として得られる 別の効果を図解している。複数のスプレッドシート・テンプレートを、同じデー タに対して定義することができる。同じスプレッドシートに対して複数のテンプ レートを有することによって、同じデータが異なって表示され、それにより、ユ ーザは、現在自分が作業しているタスクが何であってもそれに対して最も便利な フォーマットでそのデータを見ることが可能になる。図８Ｂは、エッジ・セット ・データを表示する別のテンプレートを示している。これは、ドロップ・ダウン ・ボックス８３２Ａのようなドロップ・ダウン・ボックス８３２Ｂを有する。こ れはまた、データ・フィールド８３０Ａと類似のデータ・フィールド８３０Ｂを 有する。しかし、データ・フィールド８３０Ａ及び８３０Ｂにおけるコラムは、 異なる態様で構成されている。 図８Ａに示されているテンプレートは、例えば、ピン・グループを特定のタイ ム・セットに割り当てるのに用いられ得る。図８Ｂにおけるテンプレートは、例 えば、それぞれのピンがどのエッジに割り当てられているかを判断するのに用い られ得る。好適実施例では、図８Ｂのテンプレートは、 リード・オンリ・テンプレートである。 図９は、ユーザによって一貫したフォーマットで容易に入力されうる更に別の タイプのデータを示している。図９は、他のスプレッドシートに用いられるのと 同じツール・バーとメニュ・バーとを示している。図９は、様々な名称のパラメ ータと関連するレベルを特定するスプレッドシートを示している。これらのパラ メータは、同様に、様々の測定値又は刺激信号と関連する電圧及び電流レベルで ある。エクセルによれば、これらの名称付きのパラメータは、他のスプレッドシ ートにおける名称によって、参照されることが可能である。また、パラメータの 値を、他の名称付きの値を組み入れている方程式によって特定することも可能で ある。 図１０Ａを参照すると、本発明の効果の１つを見ることができる。図１０Ａは 、「フロー・タイプの」スプレッドシートを表している。図１０Ａは、テスト「 インスタンス」が特定のテストに対して定義される態様を表す。半導体テスト・ システムは、一般的に、限定された数のものに対するテストを行うのに必要とさ れる。例えば、このテスト・システムは、パターン「バースト」をランさせるこ ともありうる。バーストの間には、テスタは、特定された刺激を与え、いくつか の予測される応答をチェックする。刺激及び応答に対する値は、「ベクトル・フ ァイル」において特定される。ベクトル・ファイルの中の異なる値は、異なる種 類のパーツをテストする、又は、同じパーツ上で異なるテストを行うのに用いら れる。しかし、ベクトル・ファイルを用いるためにテスタが実行する動作は、そ の中の特定のデータ値とは関係なく、同一であるのが一般的である。 テスト・システムがパターン・バーストを実行するのに経験する一連のステッ プは、「テンプレート」と称される。テンプレートは、特定のベクトル・ファイ ル又は必要とされるそれ以外のデータの記述のためのブランク・スペースと同等 のプログラミングを用いて実行されなければならない一連のステップである。こ のようにして、テンプレートは、それが用いる特定のデータ値がいったん特定さ れると、任意のテストに対して用いることができる。データが特定のテンプレー トと共に用いられるために特定さ れると、このテンプレートの「インスタンス」が作成される。インスタンスは、 プログラムにおいて用いることができる。 テスタの製造業者は、一般に、その制御ソフトウェアの一部として複数のテス ト・テンプレートを提供する。テスト・テンプレートは、パターン・バーストを ランしたり、漏れ電流の測定を行ったり、テスト対象デバイスのリード上の直流 レベルやそれ以外のテスタ動作をチェックするのに用いられる。後で更に詳しく 説明されるように、好適実施例のテンプレートは、ビジュアル・ベーシックで書 かれているが、これは、スプレッドシート・プログラムであるエクセルと関連す るプログラミング言語である。それぞれのテンプレートは、ビジュアル・ベーシ ックの手順として書かれ、データ値は、手順への引数（argument）として特定さ れる。 図１０Ａは、プログラム・インスタンスが作成される方法を図解している。デ ータ・フィールド１０３０は、テスト・ジョブにおいて用いられ得るインスタン スの名称をリスト化するコラム１０３２Ａを含む。コラム１０３２Ｂは、インス タンスを作成するのに用いられるテンプレートの名称を含む。 図１０Ｂは、特定のデータがあるテンプレートとどのように関連するかを示し ている。エクセルは、ダイアログ・ボックス１０３６をデータ・フィールド１０ ３０における特定のセルと関連させることを可能とするプログラミング上の特徴 を含む。セルにおける又はどれか別のセルにおける値に依存して、異なるダイア ログ・ボックスを選択することができる。例えば、図１０Ｂでは、ダイアログ・ ボックス１０３６は、セル１０３４と関連するように示されている。セル１０３ ４は、特定のデータ値をセル１０３５の中にリスト化されたテンプレートと関連 付けることによって、作成されるインスタンスの名称である。この例では、ダイ アログ・ボックス１０３６のフォーマットは、セル１０３５にリスト化されたテ ンプレートに基づいて選択される。 ダイアログ・ボックス１０３６は、領域１０３８及び１０５０と含んでおり、 それぞれが、セル１０３５におけるテンプレートが関連付けられる いくつかのデータ値がリスト化されるフィールドを備えている。「30Mhzfunc」 とラベル付けされるテスト・インスタンスを作成するために、ダイアログ・ボッ クス１０３６の中の値は、引数として、「functional」という名称のテンプレー トに送られる。 図１０Ｂは、データ・フィールド１０３０が多くのローを含むことを示してい る。テスト・ジョブにおいて必要とされるそれぞれのテスト・インスタンスに対 して、１つのローが存在する。「Functional」と命名されたテンプレートは２つ の異なるインスタンスを作成するのに用いられる。異なる引数をダイアログ・ボ ックス１０３６において特定することによって、同じテンプレートを用いて異な るインスタンスが作成される。 図１０Ａ及び１０Ｂは、テスト・フローを特定する際のステップを示している 。しかし、このユーザ・インターフェースは、図４ないし９のデータ・スプレッ ドシートのためのユーザ・インターフェースと同じであることに注意すべきであ る。従って、プログラム・フローを特定するために、特別のトレーニングは何も 必要とならない。また、ダイアログ・ボックス１０３６に入力される引数は、他 のスプレッドシートの名称か、又は、スプレッドシートの中で定義される値であ ることがほとんどである。従って、デバイス・データは、プログラム・フロー情 報との組合せが容易であり、ソフトウェアの開発時間をかなり節約することがで きる。この利点は、デバイス・データとプログラム・フローとの両方がスプレッ ドシートにおいて表されているという事実に起因する。 他のプログラム・フロー情報は、図１１Ａに示されているスプレッドシートに 入力される。インスタンスがいったん定義されると、実行される順序が特定され なければならない。更に、インスタンスがテスト・ジョブの中のテストを記述す るので、テスト・インスタンスが合格するか又は失敗する場合にどのイベントが 生じるかに関する情報が提供されなければならない。この情報の全体が、他のフ ローやデバイス・データ・スプレッドシートと同じインターフェースを用いて、 スプレッドシートの中にユーザによって入力される。 データ・フィールド１１３０の中には、テスト・ジョブにおけるそれぞれのス テップに対して特定されなければならない情報を保持する複数のコラムが存在す る。データ・フィールド１１３０におけるそれぞれのローは、テスト・ジョブに おける１つのステップに関する情報を保持している。コラム１３２は「OPCODE」 とラベル付けされる。このコラムは、この特定のステップにおいて何が起こるの かを指示する。一般的に、OPCODEコラム１３２におけるそれぞれのエントリは、 テスト・インスタンスである。 コラム１１３４は、テストにおけるステップ番号を含む。ステップ番号は、テ スト・システムがそのテストの実行に関する報告に用いることができる。例えば 、欠陥がテストの間に検出された場合には、欠陥が検出されたステップ番号を報 告することができる。 コラム１１３６は、合格ビン番号（pass bin number）を含む。それぞれのデ バイスがテストされる際に、テスタは、一般に、テスト対象デバイスに、テスト の結果に対応する「ビン」番号を割り当てる。ビン番号は、パーツのグレード付 け（grading）を示す。例えば、あるビン番号は、デバイス仕様の程度まで動作 するパーツを表す。他のビン番号は、欠陥があり役に立たないパーツを示す。更 に別のビン番号は、仕様の範囲内の動作はしないが、程度を落とした仕様の程度 であれば十分に機能を果たすデバイスを示す。テスト・エンジニアが、ビン番号 とその意味とを割り当てる。 コラム１１３８も同様である。これには、テストが失敗した場合に割り当てら れるビン番号を含む。 データ・フィールド１１３０は、示されている範囲を超えたそれ以外のコラム を含みうる。図１１Ｂは、より複雑なフロー制御のためのより多くのコラムの情 報によって拡張されたデータ・フィールド１１３０Ｂを有するフロー・シートを 示している。例えば、データ・フィールド１１３０Ｂは、フラグ・フィールド１ １５６及び１１５８を含む。フラグ・フィールド１１５６は、オプションで、あ るステップで特定されたテストに合格した場合に「真」(true)であると設定され るフラグ、すなわち、ブール変数（boolean variable）と同じものを含む。フィ ールド１１５８も同様であ るが、テストが不合格であった場合に設定されるフラグの名称を含む。 データ・フィールド１１３０Ｂにおける他のコラムは、複数のデバイスが同時 にテストされるような場合のより複雑なフローに用いられ得る。例えば、コラム １１５２は、任意のローにおいて特定されたステップがどのデバイスに適用され 得るかを示している。それまでのすべてのテストに合格してきたデバイスにだけ 他のテストを実行することがありうる。また、先行する１回のテストに合格しな かったデバイスにだけ他のテストを実行することがありうる。 コラム１１５４は、テストの結果をどのデバイスに適用すべきかを特定する。 これらの示されているもの以外のコラムを用いることもありうる。そのステッ プにおけるテスト・インスタンスの実行の前に、あるブール表現の評価が与えら れている条件フィールドを含むコラムもありうる。このようにして、条件的なプ ログラム・フローを実現することができる。この機能は、それがブール表現をと ることを許容することによって、コラム１１５２と組み合わせることができる。 真であると評価されるブール表現は、テストがすべてのデバイスに対して実行さ れることを示す。逆に、表現が偽（false）であると評価される場合には、テス トはすべてのデバイスに対して行われるとは限らない。ブール表現をそれぞれの デバイスに対して特定できる場合には、混合的（ハイブリッド）な状況もありう る。図１１Ｂの例では、コラム１１５２は、「すべて」に関して一定値を有する 何らかの値を含む。そのような値は、そのローにおいて参照されたテストがすべ てのデバイスに対して無条件的に実行されるべきであることを示している。しか し、他のローは、先行するローにおいてコラム１１５４又は１１５８にリスト化 されているフラグを参照するブール表現を示している。更に、これは、セルがそ の中ではある値に設定されデバッギング・ブレーク・ポイント（debugging brea k point）のように作用するコラムを含みうる。 図１１Ｂに示されている情報は、既存のテスタをプログラムするために特定さ れなければならない情報と類似している。しかし、図１１Ｂのフロ ー情報は、複数のローとして構成され、それぞれのローは、それぞれの中に複数 の種類の情報を有している複数のコラムを含む。フロー情報をテキスト・ファイ ルの中に記憶するのと比較すると、市販のスプレッドシート・プログラムを用い ることから帰結されるロー及びコラムの構成は、プログラマにとってははるかに 直感的であり、それによって、プログラマは、フローをより迅速にプログラムす ることを学ぶことになる。第２の利点は、図１１Ｂに示されているフロー情報を 操作するための構造及びツールが、市販のスプレッドシート・プログラムによっ て提供されるということである。このようにして、ソフトウェアの開発をより迅 速に行うことができる。 図１１Ｃは、フロー制御情報を特定することができる別の方法を示している。 図１１Ｃは、低級の制御ソフトウェア３１４（図３）のオプションを修正するオ プションを特定するのに用いることができるポップアップ・オプション・ボック スを示している。オプションは、ダイアログ・ボックスの中の選択肢の上をクリ ックすることによって、人間であるテスト・エンジニアによって特定される。例 えば、「すべてを実行せよ」というオプションによれば、１つのステップが失敗 した場合であってもフロー制御ソフトウェア３１４にプログラム・フローにおけ るすべてのステップを動作させることになる。このオプションが選択されないと きには、特定のパーツのテストは、１つのステップが失敗すると、停止すること になる。別の例としては、「最終のものを印刷せよ」というオプションの場合に は、テスト・ジョブが終了すると、テストの結果が印刷されることになる。選択 されないときには、結果は印刷されないが、ユーザによって読み出されるまで記 憶されていることになる。更に別の例として、「計時を実行」(Do Time)のオプ ションによると、フロー制御ソフトウェアは、ジョブの開始とジョブの終了の時 間を記録し、それによって、ジョブに要した時間の長さを記憶することができる 。以下で説明されるように、フロー・データ・シートは、フロー・データ構造に 変換される。特定されたオプションによって、この変換がなされる実際の方法が 影響を受ける。 図１２Ａ及び１２Ｂは、テスト・テンプレートのサンプルを示している。 テスト・テンプレートは、ビジュアル・ベーシックで書かれているが、このビジ ュアル・ベーシックは、スプレッドシートに添付されたマクロを書くのに用いる ことができるプログラミング言語である。それぞれのマクロは、プログラミング 言語における手順として用いることができ、従って、テスト・テンプレートとし て用いることができる。 図１２Ａ及び１２Ｂでは、複数の重要なポイントを見ることができる。第１に 、全体的なプログラミング環境は、情報をデバイス・データとフロー・スプレッ ドシートに入力するのに用いられるものと同一である。同じツール・バー１２１ ０と、メニュ・バー１２２０と、タブ・フィールド１２４０とを有している。し かし、データ・フィールドの代わりに、テスト・テンプレート・スクリーンは、 複数のラインのプログラム・コードを含む。 プログラム・コードのそれぞれのラインは、テスタ製造業者によって開発され た他の手順をコールすることができるし、又は、ユーザが書くこともできる。ラ イン１２５０及び１２５４は、テスタ製造業者によって提供される機能へのコー ルを表している。ライン１２５０では、「PinHi」は、デバイス・ドライバ３２ ８（図３）の１つにアクセスし、特定されたピンをハイ（high）状態に設定する 手順である。ライン１２５４では、「StartPatgen」は、タイミング及びシーケ ンシング回路１２０（図１）の動作を開始させるのと同じ機能である。 図１２Ａ及び１２Ｂは、また、デバグ・ツール・バー１２３２を示している。 新たな半導体デバイスが最初に開発されているときには、デバイス・エンジニア は、このデバイスの実際のパフォーマンスを測定しその設計が適切であるかどう かを評価することが必要である。欠陥が検出されたときには、デバイス・エンジ ニアは、何がうまくいかなかったのかを正確に割り出すことを望む。そのために 、デバイス・エンジニアは、テスタを「デバグ・モード」で用いる。デバイス・ エンジニアは、テスタが一度に１つの動作を実行するように制御し、それによっ て、それぞれの動作の結果を解析できるようにする。デバグ・ツール・バー１２ ３２は、好ましくは、市販のスプレッドシート・プログラムの一部として提供さ れている。 デバグ・ツール・バー１２３２は、様々なデバグ機能を実行するツールを含む 。例えば、ツール１２３４は、コードにおけるブレーク・ポイントを設定する。 ライン１２５４は、そのラインにおいてブレーク・ポイントが設定されているこ とを示すためにハイライトされる。テストを実行する間には、ブレーク・ポイン トのマークが記されているラインを実行する前に、実行は停止する。とのときに 、デバイス・エンジニアは、テスタ又はデバイスの状態をチェックすることがで きる。 ブレーク・ポイントにおいて実行が停止したときには、デバグ・ツール・バー １２３２上の他のツールが、実行がどのように継続するかを制御する。例えば、 ツール１２３６によって、実行がそれ以後のすべての手順までステップ・バイ・ ステップで進行することが可能になる。対照的に、他のツールでは、手順をスキ ップしてとばすことが可能になるし、更に別のツールによると、ある値が検査さ れることが可能になる。このようにして、デバイス・エンジニアは、デバイスの 動作について多くのことを観察することができる。同じデバグ・ツールは、テス ト対象デバイスのためのテストを開発しているテスト・エンジニアによって用い られることも可能である。有意義なことに、これらの能力のすべては、デバグ・ ツールを備えたプログラミング言語と関連付けされている市販のスプレッドシー ト・プログラムを用いることによって、非常に低コストで提供され得る。 テスト・ジョブのためのデータ及びフロー情報がテスト・エンジニア又はシス テムのそれ以外のユーザによって入力されると、ワークステーション１１０内の ソフトウェアを動作させ、テスト・ジョブを制御することができる。図３に示さ れているように、テスト・ジョブの実行は、ユーザ入力に応答して、フロー制御 ソフトウェア３１４によってなされる。図解されている実施例では、フロー制御 ソフトウェア３１４は、Ｃ＋＋言語として実現されている。より詳しくは、それ は、ＤＬＬである。 図１３は、フロー制御ソフトウェア３１４の動作を説明する流れ図である。フ ロー制御ソフトウェア３１４は、アイドル状態１３１０から始動する。フロー制 御ソフトウェア３１４は、ソフトウェアへの入力に基づき、 ３つの異なる作用の中の１つを実行することができる。フロー制御ソフトウェア ３１４がとりうる１つの作用として、テスト・ジョブのためのデータをテスト・ ジョブの間にアクセスすることができるデータ構造に構成することがある。図１ ０及び１１と共に既に説明したように、テスト・ジョブは、インスタンスのリス トとして特定され、インスタンスは、特定のデバイス・データとあるテンプレー トとの関連付けによって特定される。更に、特定のインスタンスが実行される順 序は、プログラムのフロー・データ・シートに入力される条件によって影響され る。 ユーザ・コマンドに応答して、フロー制御ソフトウェア３１４は、実行される それぞれのテンプレートとそのテンプレートの実行のために用いられるデータと をリスト化するジョブ制御データ構造を構築する。テンプレートの実行順序を条 件から決定することができる場合には、それは、テンプレートがコア・ブロック 制御データ構造の中に配置される前に決められる。しかし、テンプレートの実行 順序がテスト・ジョブが実行されるまで決められない場合には、ジョブ制御デー タ構造は、単に、テンプレートが実行される順序を決定するのに評価される条件 に関する情報を含む。ジョブ制御データ構造は、インデクス付きのリストであり うるが、それ以外の実現例も可能である。 ジョブ制御データ構造を構築する際には、実行は、ステップ１３１２に進む。 ステップ１３１２では、第１のテンプレートが決定される。テンプレートは、フ ロー・データ・シートにおける第１のインスタンスから決定される。このインス タンスと関連するテンプレートは、インスタンス・データ・シートから決定され る。テンプレートに対するノーテーション（記号、notation）は、ジョブ制御デ ータ構造に入力される。好適実施例では、このノーテーションは、テンプレート を実行するようにコールするサブプログラムの名称を示す。 ステップ１３１４では、選択されたテンプレート・サブプログラムのコールの 際に送られるデータが識別される。どのデータを用いるべきかは、インスタンス ・データ・シートから決定される。 ステップ１３１６では、特定のテスト・テンプレートのための用いられるデー タのＩＤがジョブ制御データ構造に追加される。図３に示されているように、デ ータ・マネジャが、データを、テスタ１１２（図ｌ）に与えるために、エクセル ・ワークブックからデバイス・ドライバに送る。後で詳細に説明されるように、 データ・マネジャ３１６は、テスト・ジョブの間のテスタ１１２に送られる特定 のデータを保持するパラメータ・データ構造をアセンブルする。パラメータ・デ ータ構造におけるデータは、「コンテナ」(容器、containers)の中に構成される ことにより、データに正しい「コンテナ」の名称を提供することによって、正しい データがパラメータ・データ構造から選択されることが可能になる。フロー制御 データ構造に加えられる引数は、データ・マネジャ３１６がパラメータ・データ 構造から選択する正しい「コンテナ」を特定する。この情報は、好適実施例では 、データ・シートに与えられた名称に基づいて選択されるテキスト・ストリング として表される。コンテナには、同じテキスト・ストリングが関連付けされる。 しかし、コンテナを識別する別の方法を、代わりに用いることもできる。 「コンテナ」の名称を表す引数に加えて、データ値である引数が特定のテンプ レートによって用いられ、更に、おアクチュエータ・データ構造に追加されるこ ともありうる。 テンプレートを識別する情報とデータ値とがジョブ制御データ構造に追加され ると、実行は、ステップ１３１８に進む。ステップ１３１８では、フロー・シー トにおいて特定された次のテンプレートを実行するための条件が決定される。こ の条件は、実行すべき次のインスタンスでありうるフロー・シートにおけるすべ てのありうるインスタンスを決定するために計算される。更に、それぞれのイン スタンスが次になる条件が、論理方程式として表現される。テスト・ジョブの間 に評価されなければならない値に対して、変数が用いられる。これらの論理的表 現は、ジョブ制御データ構造にステップ１３２０において入力される。これらの 論理的表現は、伝統的なプログラミングにおけるブランチング（分岐）命令と何 が等しくなり うるかの条件として用いられる。 フロー制御シートの１つのローに対する情報が入力されると、実行は、ステッ プ１３２２に進む。ステップ１３２２は、フロー制御データ・シートにローが更 にあるかどうかをチェックする。あるならば、実行は、ステップ１３１２までル ープする。フロー制御データ・シートにそれ以上ローがない場合には、フロー制 御ソフトウェア３１４は、アイドル状態１３１０に戻る。 フロー制御ソフトウェア３１４は、そのアイドル状態にあるときには、ユーザ からテスト・ジョブを実行せよとのコマンドを受け取ったり、又は、操作デバイ ス１１４から、テスト対象デバイスがロードされテストの準備ができていること を示す開始信号を受け取ったりする。テスト・ジョブを実行するようにとのコマ ンドを受け取ったときには、実行は、ステップ１３２４に進む。ステップ１３２ ４では、ジョブ制御データ構造からの第１のテンプレートが読み出される。テン プレートは、ジョブ制御データ構造からの特定の引数を伴うサブプログラムとし てコールされる。次に、テンプレート・サブプログラムが実行され、フロー制御 ソフトウェア３１４に戻る。 テストを表すそれぞれのテンプレート・サブプログラムは、テストが合格だっ たのか不合格だったのかを指示する。テストの結果が指示されうる１つの方法と して、テンプレート・サブプログラムが、値を、そのサブプログラム・テンプレ ートによって行われたテストの結果を指示するコール・プログラムに戻すように コード化されているかどうかである。また、テンプレートか、又は、適切な場合 にデバイス・ドライバは、テスタの状態をチェックしてテストが合格であった不 合格であったかを判断するフローＤＬＬの中の機能をコールすることができる。 ステップ１３２６では、テスト・ジョブの状態は、コールされたばかりのテスト ・テンプレートによって戻された値に基づいて更新される。例えば、テストは、 エラーを検出することなく（すなわち、テストは合格）テスト・テンプレートが 実行されたか又はエラーが検出されたかを示す。場合によっては、エラーは、 テスト対象デバイスのビニング（binning）を容易にする数値を有することがあ る。 ステップ１３２８では、テストの新たな状態を用いて、ステップ１３２８にお いてジョブ・フロー・データ構造に記憶された論理的表現を評価する。この評価 に基づき、次のテンプレートが、ステップ１３２０において記憶されたブランチ ング情報を用いて選択される。 実行は、次に、ステップ１３３０に進む。ステップ１３３０では、実行すべき 別のテンプレートがあるかどうかが評価される。ある場合には、ジョブ実行は、 ステップ１３２４へのループ上に戻る。それ以上のテンプレートがない場合には 、フロー制御ソフトウェア３１４は、そのアイドル状態に戻る。 好適実施例では、テスト・ジョブの結果は、テストが終了したときに、ユーザ 又は操作デバイス１１４に与えられることはない。データを提供すると、テスト ・ジョブの実効速度を低下させることになる。従って、好適実施例では、それぞ れのテスト・ジョブの実行結果は、リクエストがなされるまで、コンピュータ・ メモリに記憶される。結果をリクエストすると、フロー制御ソフトウェア３１４ が、アイドル状態１３１０からステップ１３３２に移動することになる。ステッ プ１３３２では、結果を人間であるユーザのために表示したり、操作デバイス１ １４に送ったりすることができる。結果は、ユーザに都合の良い態様又は操作デ バイスに対して適切な態様で表示のためにフォーマット化することができる。 データ・マネジャ３１６に関する詳細をここで述べることにする。データ・マ ネジャ３１６は、一連のＣ＋＋「クラス」から構成されている。クラスは、関連 する状態図（state diagram）を有さない。クラスは、他のプログラミング要素 からのリクエストに応答して動作を実行する。クラスは、関連する「方法」を有 する。それぞれの方法は、従来のプログラミング機能のようにコールして、クラ ス内に記憶されているデータにアクセスすることができる。 Ｃ＋＋の方法は、他のＣ＋＋プログラムによって直接的にコールされる ことができる。図３の実施例では、デバイス・ドライバ３２８は、Ｃ＋＋手順と して実現されているので、方法をコールしてデータ・マネジャ３１６内のデータ を直接に読み出す又は変更することができる。エクセル・ワークブックは、Ｃ＋ ＋ではないので、データ・マネジャ３１６からのデータを記憶したり検索したり する方法をコールするのにＡＰＩ（Application Program Interfaces）を必要と する。しかし、ＡＰＩは、広く知られたプログラミング構造である。データは、 ビジュアル・ベーシックのマクロを含むエクセル・プログラムと「SafeArray」 と称されるフォーマットのデータ・マネジャ３１６との間でやりとりされる。Sa feArrayは、市販のスプレッドシート・プログラムであるマイクロソフト・エク セルと共に用いることができるマイクロソフトＯＬＥ（Object Linking and Emb edding Language）の一部である。 データ・マネジャ３１６は、「コンテナ」と称される。一連のメモリ構造とし て実現される。コンテナのフォーマットは、記憶されるデータのタイプに依存す る。例えば、ピン・マップ・データは、レベル・シート・データを保持している コンテナとは異なるフォーマットでコンテナに記憶されている。コンテナのフォ ーマットは、記憶される情報に基づき、既知のプログラミング技術を用いて定義 される。 コンテナは、入れ子状（nested）にすることができる。例えば、ピン・マップ に対するコンテナ内部には、複数のピン・グループが存在しうる。それぞれのピ ン・グループの中には、複数のピンが存在しうる。この例では、コンテナは、３ つのレベルの入れ子構造（nesting）を有している。しかし、任意のレベルの入 れ子構造を採用することができる。 Ｃ＋＋ＳＴＬ（スタンダード・テンプレート・ライブラリ）は、クラス内のデ ータを操作するのに有用な方法を含む。これらの方法の中の２つとして、MAP及 びVECTORがある。一般に、「コンテナ」は、コンピュータ・メモリの中に、論理 的な順序ではなくプログラムによって作成された順序で配分されている。しかし 、情報の検索をより容易にするために、コンテナの名称とメモリ内のその物理的 位置との間に１組の「キー」(鍵)が作成 される。これらのキーは、正確なキーを見つけることによって所望のデータを見 つけることができるように、インデクスとして機能する。 MAPの方法は、バイナリ・ツリー（二進木、binary tree）のように分岐してい る１組のキーを作成する。VECTORの方法は、リストのような、順序付けがなされ たインデタスを作成する。MAPの方法の長所は、ランダムなアイテムを迅速に発 見することができるということである。MAPの方法の短所は、順序付けが失われ ているということである。例えば、ピンマップ・データ・シートにおけるピンの 順序は、テスト・プログラムにとって重要な情報である。MAPの方法だけを用い ると、結果として、順序が失われてしまう。データをデータ・マネジャ３１６に 記憶する方法は、MAP及びVECTORのSTLの組合せを用いて、それぞれの長所を達成 している。 記憶及び検索機能に加えて、データ・マネジャ３１６は、必要となるデータ管 理機能を実行する他の方法を含む。追加的な機能は、SELECT DEFAULT機能である 。既に述べたように、１つのテスト・ジョブに複数のピン・マップが存在するこ とがありうる。SELECT DEFAULTの方法は、どのデータの組をデフォルトとして用 いるかを指示する。例えば、テスト・ジョブが２つのピン・マップPIN MAP1及び PIN MAP2を有する場合には、PIN MAP1が、デフォルトに設定される。ピン・マッ プ・データを検索する検索する検索機能をどのように用いても、検索動作が実行 されるときにPIN MAP2が明白に指示されていなければ、データは、PIN MAP1から 取得される。 データ・マネジャ３１６には、SELECT ACTIVEの方法もまた、含まれうる。こ の方法は、SELECT DEFAULTと類似しているが、用いられ得るコンテナを特定する 。 含まれうる別の方法に、REPLACEの方法がある。既に述べたように、データ・ マネジャ３１６は、テスト・ジョブが特定のデバイスをテストするデータのため の一連のコンテナである。テスト・ジョブの開発の間に、又は、特定のジョブに おけるテストの間に、そのデバイスに対するデータのいくつかを変更することが 望ましい場合がありうる。REPLACEの方法によれば、１組のデータが別のものと 交換されることが可能となる。例えば、 ユーザがテスト・ジョブの開発プロセスの一部としてデバイスのピン・マップ・ スプレッドシートを編集した場合には、ピン・マップ・データ・シートと関連す るマクロは、自動的にREPLACEの方法をコールして、テスト・ジョブが実行され るときに新たなデータが用いられることを確認する。データが変更されたときに 自動的に実行されるのではなく、REPLACEの方法は、ユーザ入力に応答して動作 するマクロによってコールされる。 データ・マネジャにおけるデータがデバイス・ドライバ３２８によって変更さ れる場合には、同様の方法が必要となる。既に述べたように、データ・マネジャ ３１６は、本質的に、エクセル・ワークブックの中に維持されるデータとは別個 のデータのコピーを維持する。エクセル・ワークブックの中の変更は、REPLACE の方法によって、データ・マネジャ３１６において反映される。データ・マネジ ャの中のデータがワークブックの内部においてではなく変更された場合には、RE PLICATEの方法が必要となる。例えば、デバイス・ドライバたデータ・マネジャ におけるコンテナの１つの中の値を変更する場合には、データ・マネジャ３１６ は、REPLICATEの方法をコールすることになる。 REPLICATEの方法は、現在のデータをデータ・マネジャ３１６から読み戻すエ クセル・ツールをコールする。データは、適当なエクセルのスプレッドシートの 中にロードされ、これによって、ワークブックと関連するエクセルの機能は、変 更されたデータに基づいてすべてのデータを再計算することになる。そして、変 更されたすべてのスプレッドシートにおけるデータは、データ・マネジャにおい て、交換される。データ・マネジャによって記憶されたデータを変更する動作を 実行するテスト・テンプレートは、実行を終了すると、REPLICATEの方法を用い る。動作 以上で、テスタ１１２を制御するソフトウェアの構造を説明した。このソフト ウェアの多くの使用が可能である。１つの可能性のある使用法は、最初にテスト ・ジョブを開発し、次に半導体デバイスを製造する間にそのテスト・ジョブを反 復的に実行するように用いることである。また、可能 性のある使用法は、デバイス・エンジニアが、必要であれば、最初にテスト・テ ンプレート３２０を編集することであろう。非常に少数のテスト・テンプレート で多くの種類のデバイスをテストすることができることが意図されている。従っ て、テスト・テンプレートの編集が要求される可能性は低い。 半導体テスト・デバイスの開発者が選択する可能性のある次のステップは、デ バイス・データとフロー開発ツール３１０（図３）とを用いることである。これ らのツールは、開発されている特定のデバイスに対してエクセル・ワークブック を開くことによってアクセスすることができる。特に、これらのツールは、図４ ないし１１に示されているスプレッドシートを表している。マクロ又はウィザー ドを用いて、これらのフォームに関してユーザを誘導することができる。有効化 マクロを、特定のシートに対するデータ・エントリが完了したときに動作させ、 他のデータと一貫性のないデータはすべて検出され訂正されるようにすることが できる。例えば、プログラマは、ピン・マップにない特定のピンに対するデータ 値を入力することができる。しかし、そのような入力は、エラーを示すのであり 、その理由は、そのピンがピン・マップから偶然に取り去られたからであったり 、又は、特定のピンに対して誤った名称が用いられたからである。 好適実施例では、ソフトウェアは、データが入力されなかった又は変更され有 効化されなかった場合にはテスト・ジョブが動作しないようにコード化される。 有効化は、ユーザによって、カスタム・メニュ・バーから選択されうる。 データがいったん入力されると、ユーザは、「コンパイル」のオプションを選 択する。好適実施例では、このコンパイル・オプションは、フロー・データ・シ ートに関連するカスタム・メニュ・アイテムから選択される。コンパイル・オプ ションによって、フロー制御ソフトウェア３１４が、ジョブ・フロー・データ構 造を構築することがトリガされる。また、これによって、データ・マネジャ３１ ６内の方法が、エクセル・ワークブックからデータ・マネジャにデータを転送す ることになる。 開発環境では、テスト・エンジニアは、次に、プログラムのデバッギングのプ ロセスを開始する。おそらく、このエンジニアは、デバイスをテスタ１１２に接 続する。また、テスト・エンジニアは、シミュレータを用いてテスト・プログラ ムをデバッギングする可能性もある。シミュレータとは、それに接続されたデバ イスを用いてテスタ１１２の動作をシミュレートするソフトウェア・プログラム である。 エンジニアは、既に述べたようなデバッギング・ツールを用いて、プログラム を検査することがありうる。テスト・エンジニアは、プログラムにおけるエラー を検出する際に、テスト・テンプレートを編集することもありうる。テスト・テ ンプレートは翻訳された言語であるビジュアル・ベーシックで書かれているので 、テスト・ジョブをリコンパイル（recompile）することなく、この変更は直ち に効力を生じることができる。 また、テスト・エンジニアは、デバイス・データ構造の１つにおいてデータの いくつかを変更する必要が生じることもある。テスト・エンジニアは、図４ない し１１に示されたスプレッドシート・スクリーンを介してデータにアクセスし得 る。次に、有効化プロセスが再び動作する。有効化プロセスの一部として、REPL ACEツールが自動的にランする。REPLACEツールを自動的に用いることによって、 データ・マネジャ３１６が日付データまでを提供することが保証される。 デバッギングの一部としてテスト・エンジニアがプログラム・フローを変更す る場合には、フローは、新たなジョブ・フロー構造が構築され得るようにリコン パイルされなければならない。 要求された変更がデバイス・データ、テスト・テンプレート又はデバイス・フ ローに対してなされると、テスト・ジョブを再度ランさせることができる。テス ト・プログラムに変更を加えるのに要する時間は、非常に短いことがありうる。 従来技術によるいくつかのシステムでは、テスト・ジョブに対するどのような変 更でも、非常にわずかなものであっても、完全なリコンパイルが要求された。結 果として、そのような変更でも、１時間程度を要することがあった。本発明では 、テンプレートへの変更は、リコ ンパイルを全く要求しない。デバイス・データへの変更がなされると、変更され たデータが再ロードされることだけが要求される。変更された場合にコンパイル されなければならないのは、プログラム・フローだけである。コンパイルはフロ ーだけを扱うのであって、すべてのデータを扱うとは限らないので、数秒で実行 することができる。 典型的な開発のセッティングでは、テスト・エンジニアは、テスト・ジョブが 予測されたとおりに実行されるまでは、テスト・ジョブを変更するプロセスを反 復する。完了すると、テスト・ジョブは、製造のセッティングに転送される。製 造セッティングでは、デバイス・データ及びフロー開発ツールは、用いられない 。同様に、カスタム・インターフェースが開発される。カスタム・インターフェ ースは、テスタを動かしてパーツをテストするのに必要な制御だけを提供し、基 本的な出力情報だけを表示してオペレータにテストが進行していることを知らせ る。テスタは多くのデータを測定し記憶することができるが、製造環境ではオペ レータに対しほんのわずかな部分だけが提示される。 ソフトウェアはエクセルを用いて実現されているが、ビジュアル・ベーシック のプログラミング言語を用いて、カスタム製造インターフェースを準備すること ができる。インターフェースにおいて可能性のあるのは、テストを開始し、テス トを終了し、いずれかのテストに合格しなかったデバイスの数を示す表示を行う という制御である。他の実施例 以上で１つの実施例を説明したが、多くの別の実施例又は変更例が可能である 。例えば、本発明は、本体（ボディ）と別個のコンピュータ化されたワークステ ーションとを有するテスタに関して説明されている。しかし、コンピュータ化さ れたワークステーションがテスタ本体と物理的に分離していることは必要ない。 例えば、テスタ本体の内部に組み入れることも可能である。それ以外の構成も可 能である。例えば、テスタには、メインフレームとテスト・ヘッドとを有するも のがある。しかし、本発明の目的のためには、テスタは、１つ又は複数の異なる パッケージであってもよい。 特定のデータ及びフロー・シートの例を与えてきた。それぞれのローは、特定 の数のコラムを有し、それぞれのコラムは、フローにおけるアイテム又はステッ プに関する特定のタイプの情報を含むように、示した。動作されるタイプによっ て、テスタのハードウェアや、テスト対象のデバイスの要件、それぞれのローに 含まれる情報の数及び種類は、異なることがある。より多く又はより少ないコラ ムでもかまわない。１つの可能性としては、それぞれのタイプのスプレッドシー トに対してスーパー・セット（super set）の可能なコラムを有することである 。ユーザは、次に、どのコラムが特定のジョブに対して重要であるのかを選択す る。ウィザード（Wizard）を提供して、選択プロセスによってプログラマを誘導 することもできる。ウィザードとは、ユーザに選択を促すマクロである。特定の スクリーン上の表示のために選択されていないスーパー・セットにおけるこれら のコラムは、スプレッドシートから全体を削除することができるし、与えられる が表示されないことも可能である。存在するが表示されないコラムは、無視され るか、又は、デフォルト値を与えられる。 フロー制御ソフトウェア３１４はＣ＋＋で書かれているものとして説明してき た。Ｃ＋＋はビジュアル・ベーシックよりも高速に実行することができると広く 考えられている。ビジュアル・ベーシックは、市販のスプレッドシート・プログ ラムであるエクセルの一部であるプログラミング言語である。しかし、フロー制 御ソフトウェアがＣ＋＋で書かれている場合にはより高速に実行されるが、デバ イスへのインターフェースと、エクセル・プログラムを用いたフロー・データ入 力とに要する時間は、より低速であることが認識された。従って、場合によって は、フロー制御ソフトウェアをビジュアル・ベーシックや、市販のスプレッドシ ート・プログラムの一部である他のマクロ・プログラミング言語で実現すること が好ましい。 図１３との関係で既に述べたことであるが、フロー制御ソフトウェア３１４は 、単一のパーツをテストするテスト・ジョブを制御する。テスタ１１２は、数百 から数千個のピン１２４を有していることが多い。従って、複数のパーツをテス タ１１２に同時に接続するのに十分なだけのピンが存 在している。この場合には、ピンは、「サイト」(sites)としてグループ化され ている。それぞれのサイトにおけるピンは、同一のデータを取得し、同じ測定を 行う。しかし、１つのサイトが１つのエラーを検出する場合には、異なる処理が そのサイトに対して必要となる可能性がある。従って、フロー制御ソフトウェア ３１４は、複数のサイトに対して複数のテストを同時に実行するように構成する ことができる。しかし、どれかのサイトが故障する場合には、そのサイトは、別 個にテストされることになる。この機能を実行するには、ステップ１３２６を変 更し、サイトの状態を別々にトラッキングすることがありうる。次に、ステップ １３２８は、変更され、それぞれのサイトにおけるデバイスがテスト・ジョブに おける何らかのテストに合格したか不合格であったかによって、それぞれのサイ トに対するテンプレートを選択する。 また、テスト・システムは半導体素子をテストすると説明してきた。プリント 回路ボード又はそれ以外のデバイスに対するテスト・システムを制御するのにも 、同様のソフトウェアを用いることもできる。 更に、市販のスプレッドシート・プログラムを用いることによってテスト・シ ステムを制御するソフトウェアをユーザが容易に理解することができる態様で迅 速に実現することができるようになることを説明してきた。図１４は、実現可能 な別のツールの例を示している。図１４は、デバグ又は解析ツールとして用いら れることが主に意図されたツールを示している。ここでは、データ入力スクリー ンが示されている。このスクリーンは、スプレッドシートではなくビジュアル・ ベーシックを用いてダイアログ・ボックスとして実現されている。図１４の特定 の例は、ただ１つのピン（図１）のハードウェア・セットアップに関係する。ダ イアログ・ボックスは、データを入力することができる複数のフィールドを含ん でいる。データは、テスタにおけるハードウェアに送られる値を表す。このダイ アログ・ボックスが用いられるときには、これは、フロー制御３１４を介する通 常のデータ経路をバイパスし、直接にデバイス・ドライバ３２８をコールしてテ スタ・ハードウェアにアクセスする。 可能性のある変更の別の例として、市販のスプレッドシート・プログラムは、 エクセル以外のものや、図面に示したもの以外のバージョンのエクセルを用いる こともできる。図１５には、マイクロソフト社から販売された市販のスプレッド シート・プログラムであるエクセル９７を用いて実現されたデータ・エントリ・ スクリーンの例を示してある。複数の追加的な特徴が、エクセル９７を用いるこ とを通じて可能である。制御要素１５１０は、グループ表示制御である。複数の ローのデータが同じグループに書き込まれた場合には、表示は、ただ１つのロー だけがそのグループを表示する専用となるように、隠れてしまう可能性がある。 図１５では、例えば、１５１２及び１５１４において示されたローは、すべて、 「rdcycle」と命名されるタイム・セットの中にある。すべてのローが示されて おり、グループは拡張（復活）したと称される。しかし、グループ表示制御１５ １０が用いられる場合には、ただ１つのローだけがそのグループに対して示され る。他のローを見ることができないにもかかわらず、それらのローは、図１５の データ・エントリ・スクリーンを用いて実行される任意の動作によって作用を受 ける。 エクセル９７の使用を介して用いられる別の特徴として、データを、そのタイ プに基づいて異なる外観にすることがある。例えば、セル１５１６内のデータは 、セル１５１８の中のデータとは異なる外観を有する。この理由は、セル１５１ ６におけるデータには、アドレス・バスのためのタイプが割り当てられ、セル１ ５１８の中のデータには、データ・バスのためのタイプが割り当てられているか らである。異なるタイプのデータを視覚的に区別することによって、ソフトウェ アをより容易に用いることが可能になる。 図１６Ａ及び１６Ｂには、行うことができるそれ以外の強化策（enhancements ）が図解されている。グループ制御要素１６１０は、その拡張（展開）状態で示 されている。従って、「General Info」として示されているグループに対して示 された要素のリストが存在する。対照的に、グループ制御１６１２は、その非拡 張状態で示されている。このように、グ ループ「Digiｔal Setup」に対するエントリは示されていない。 図１６Ａ及び１６Ｂは、また、グループを視覚的に区別可能とすることの利点 を強調している。例えば、フィールド１６１４及び１６１６は、異なるタイプの データを含むために異なる外観を呈する。 図１６Ａ及び１６Ｂに示されている別の特徴は、ナビゲーションの特徴である 。これまでの例では、ツールにアクセスするには、スクリーンの最下部にあるタ ブを選択することによった。図１６Ａ及び１６Ｂは、スクリーンは「ホット・リ ンク」を用いて相互にリンクすることが可能であることを示している。別のスク リーンからスクリーンの名称をクリックすることにより、ユーザは、スクリーン 表示を変更することができる。また、ナビゲーション・ツール・バーは、所望の データ・スクリーンを見つけるために有用なツールを含んでいる。ナビゲーショ ン・ツール・バーは、インターネット・ナビゲータで見出されるツールを含む。 このツールは、先のスクリーンに移動するとか、予め特定しておいた好みのスク リーンに行くなどの動作を実行する。 エクセル９７を用いることの別の利点として、それが、オブジェクト指向言語 である点がある。それぞれのデータ・スクリーンはオブジェクトである。データ ・スクリーンなどのそれぞれのオブジェクトは、それに関連するクラスを有して いる。すべてのデータ・シートにベース・クラスを与えることが可能であり、こ のベース・クラスが、任意のデータ・シートに共通の動作を定義する。例えば、 エラー処理、データ・タイプ及びフォーマッティングなどが、ベース・クラスに おいて定義されうる。データの有効化やデータのデータ・マネジャへの送出など それ以外の機能は、そのベース・クラスに対する「公共的な方法」(public meth ods)として定義することができる。このようにして、これらの能力の全体が、す べてのデータ・スクリーンに提供される。ただし、これらが特定されるのは１回 だけである。等しく重要なことであるが、それぞれのデバイス・データ又はフロ ー・データ・ツールは、同じように動作する。 オブジェクト指向プログラミングを用いることによって可能となるこれ 以外の変更は、シート間のエラー（inter-sheet errors）を瞬間的に有効化する ことである。有効化規則は特定することができ、データは、入力されたときにチ ェックされる。複数のシートの間で一貫性のないデータをチェックする有効化ル ーチンは、依然として動作させることができる。 従って、本発明は、請求の範囲の精神と範囲とによってだけ限定されるべきも のである。

【手続補正書】特許法第１８４条の８第１項 【提出日】平成１１年１月１９日（１９９９．１．１９） 【補正内容】 請求の範囲全文を次のように補正する。 『１．複数のテスト信号を発生し測定する電子回路(120,122,124,126,128)を保 持するボディ(112)と、前記のボディ内の前記電子回路に制御情報を提供するコ ンピュータ・ワークステーション(110)とを有し、更に、前記コンピュータ・ワ ークステーション内に制御ソフトウェアを有し、該制御ソフトウェアは、それぞ れが、前記ボディ内の前記電子回路の一部を制御する複数のデバイス・ドライバ ・プログラム要素(328)を含むタイプの半導体テスト・システムであって、前記 制御ソフトウェアが、 複数のタイプのスプレッドシート(312)を有しており、前記複数のタイプのス プレッドシートの第１の部分は、テスト対象デバイスに関するデータを保持する ように構成され、前記複数のタイプのスプレッドシートの第２の部分は、テスト 対象デバイスに対するテスト・ジョブの間に実行されるステップに影響する情報 を保持するように構成されている、市販のスプレッドシート・プログラムと、 前記複数のタイプのスプレッドシートの前記第２の部分からデータを受け取り 、前記第１のタイプのスプレッドシートから前記複数のプログラム要素の中の選 択された要素に、前記第２のタイプのスプレッドシートにおけるデータによって 決定される順序でデータを提供することによって、テスト・ジョブの実行を制御 するプログラム手段(314,316,320)と、 を更に含むことを特徴とする半導体テスト・システム。 ２．前記市販のスプレッドシート・プログラムは、スプレッドシートからデータ を読み出すように統合された統合型プログラム言語を含み、前記プログラム手段 は、前記統合型プログラミング言語で書かれたフロー制御ソフトウェアを含む、 請求項１記載のテスト・システム。 ３．前記統合型プログラミング言語はビジュアル・ベーシックである、請 求項２記載のテスト・システム。 ４．前記複数のタイプのスプレッドシートはワークブックに構成され、前記ワー クブックの中の１つのスプレッドシートにおけるデータは、前記ワークブックの 中の別のスプレッドシートからアクセス可能である、請求項１記載のテスト・シ ステム。 ５．前記市販のスプレッドシート・プログラムはエクセルである、請求項１記載 のテスト・システム。 ６．それぞれが前記テスト・ジョブの１つのステップの間に実行される機能を表 す複数のテスト・プログラム要素を更に含み、前記複数のスプレッドシートの前 記第２の部分におけるスプレッドシートは複数のローを含むフロー・シートであ り、前記複数のローの少なくとも一部は、それぞれが、 テスト・プログラム要素への参照と、 前記参照されたテストが実行されるときに故障を示す場合には、前記テスト対 象デバイスに割り当てられる分類の指示と、 を含む、請求項１記載のテスト・システム。 ７．フロー・シートにおける前記複数のローの少なくとも一部は、それぞれが、 前記参照されたテストが失敗したときに設定されるフラグの名称と、 前記参照されたテストが実行されるべきかどうかを指示するブール表現を表す セルであって、１つのローにおける前記ブール表現は、他のローに含まれるフラ グの名称を含む、セルと、 を更に含む、請求項６記載のテスト・システム。 ８．それぞれのフロー・シートは、前記テスト・ジョブの実行を修正する引数を 入力する手段をそれ自体と関連付けている、請求項７記載のテス ト・システム。 ９．前記テスト・プログラム要素のそれぞれはテスト・テンプレートを含み、前 記複数のスプレッドシートの前記第２の部分におけるスプレッドシートは複数の ローを含むインスタンス・シートであり、前記複数のローの少なくとも一部は、 それぞれが、前記テスト・テンプレートのインスタンスを定義し、 テスト・テンプレートへの参照と、 前記テスト・テンプレートに対する識別子と、 を含み、前記インスタンス・シートは、前記テスト・テンプレートと組み合わさ れて前記テスト・インスタンスを形成するテスト対象デバイスに関するデータを 保持するように構成されたスプレッドシートの中の選択されたスプレッドシート を特定する手段を更に含み、前記フロー・シートにおけるテスト・プログラム要 素への前記参照は、テスト・インスタンスに対する前記識別子を含む、請求項６ 記載のテスト・システム。 １０．前記テスト・テンプレートのそれぞれは、翻訳されたプログラミング言語 で書かれている、請求項９記載のテスト・システム。 １１．前記プログラム手段は、 前記デバイス・ドライバ・プログラムの中の選択されたプログラムを、前記複 数のタイプのスプレッドシートの前記第２の部分におけるスプレッドシートにお ける情報によって決定される順序でコールするフロー制御プログラム手段と、 前記デバイス・ドライバ・プログラム要素によってコールされ、前記複数のタ イプのスプレッドシートの前記第１の部分におけるスプレッドシートにおける情 報によって決定される値を戻すデータ検索プログラム手段と、を含む、請求項１ 記載の半導体テスト・システム。

Claims (1)

1. 【特許請求の範囲】 １．複数のテスト信号を発生し測定する電子回路を保持するボディと、前記の ボディ内の前記電子回路に制御情報を提供するコンピュータ・ワークステーショ ンとを有し、更に、前記コンピュータ・ワークステーション内に制御ソフトウェ アを有するタイプの半導体テスト・システムであって、前記制御ソフトウェアは 、 ａ）複数のタイプのスプレッドシートを有しており、前記複数のタイプのスプ レッドシートの第１の部分は、テスト対象デバイスに関するデータを保持するよ うに構成され、前記複数のタイプのスプレッドシートの第２の部分は、半導体デ バイスに対するテスト・ジョブの間に実行されるステップに影響する情報を保持 するように構成されている、市販のスプレッドシート・プログラムと、 ｂ）それぞれが、前記ボディ内の前記電子回路の一部を制御する複数のデバイ ス・ドライバ・プログラム要素と、 ｃ）前記複数のタイプのスプレッドシートの前記第２の部分からデータを受け 取り、前記第１のタイプのスプレッドシートから前記複数のプログラム要素の中 の選択された要素に、前記第２のタイプのスプレッドシートにおけるデータによ って決定される順序でデータを提供することによって、テスト・ジョブの実行を 制御するプログラム手段と、 から構成される半導体テスト・システム。 ２．前記市販のスプレッドシート・プログラムは、スプレッドシートからデー タを読み出すように統合された統合型プログラム言語を含み、前記プログラム手 段は、前記統合型プログラミング言語で書かれたフロー制御ソフトウェアを含む 、請求項１記載のテスト・システム。 ３．前記統合型プログラミング言語はビジュアル・ベーシックである、請求項 ２記載のテスト・システム。 ４．前記複数のタイプのスプレッドシートはワークブックに構成され、前記ワ ークブックの中の１つのスプレッドシートにおけるデータは、前記 ワークブックの中の別のスプレッドシートからアクセス可能である、請求項１記 載のテスト・システム。 ５．前記市販のスプレッドシート・プログラムはエクセルである、請求項１記 載のテスト・システム。 ６．それぞれが前記テスト・ジョブの１つのステップの間に実行される機能を 表す複数のテスト・プログラム要素を更に含み、前記複数のスプレッドシートの 前記第２の部分におけるスプレッドシートは複数のローを含むフロー・シートで あり、前記複数のローの少なくとも一部は、それぞれが、 ａ）テスト・プログラム要素への参照と、 ｂ）前記参照されたテストが実行されるときに故障を示す場合には、前記テス ト対象デバイスに割り当てられる分類の指示と、 を含む、請求項１記載のテスト・システム。 ７．フロー・シートにおける前記複数のローの少なくとも一部は、それぞれが 、 ａ）前記参照されたテストが失敗したときに設定されるフラグの名称と、 ｂ）前記参照されたテストが実行されるべきかどうかを指示するブール表現を 表すセルであって、１つのローにおける前記ブール表現は、他のローに含まれる フラグの名称を含む、セルと、 を更に含む、請求項６記載のテスト・システム。 ８．それぞれのフロー・シートは、前記テスト・ジョブの実行を修正する引数 を入力する手段をそれ自体と関連付けている、請求項７記載のテスト・システム 。 ９．前記テスト・プログラム要素のそれぞれはテスト・テンプレートを含み、 前記複数のスプレッドシートの前記第２の部分におけるスプレッドシートは複数 のローを含むインスタンス・シートであり、前記複数のローの少なくとも一部は 、それぞれが、前記テスト・テンプレートのインスタンスを定義し、 ａ）テスト・テンプレートへの参照と、 ｂ）前記テスト・テンプレートに対する識別子と、 を含み、前記インスタンス・シートは、前記テスト・テンプレートと組み合わ されて前記テスト・インスタンスを形成するテスト対象デバイスに関するデータ を保持するように構成されたスプレッドシートの中の選択されたスプレッドシー トを特定する手段を更に含み、前記フロー・シートにおけるテスト・プログラム 要素への前記参照は、テスト・インスタンスに対する前記識別子を含む、請求項 ６記載のテスト・システム。 １０．前記テスト・テンプレートのそれぞれは、翻訳されたプログラミング言 語で書かれている、請求項９記載のテスト・システム。 １１．前記プログラム手段は、 ａ）前記デバイス・ドライバ・プログラムの中の選択されたプログラムを、前 記複数のタイプのスプレッドシートの前記第２の部分におけるスプレッドシート における情報によって決定される順序でコールするフロー制御プログラム手段と 、 ｂ）前記デバイス・ドライバ・プログラム要素によってコールされ、前記複数 のタイプのスプレッドシートの前記第１の部分におけるスプレッドシートにおけ る情報によって決定される値を戻すデータ検索プログラム手段と、 を含む、請求項１記載の半導体テスト・システム。 １２．複数のデータ入力スクリーンを含む半導体デバイスをテストする自動テ スト装置を制御するソフトウェアであって、前記スクリーンのそれぞれは、 ａ）ロー及びコラムに構成された複数のデータ・セルを有するデータ・セル・ フィールドであって、それぞれのコラムは共通のタイプのデータを保持し、前記 スクリーンの第１の部分におけるデータ・セルはテスト対象半導体デバイスに関 するデータを保持し、前記スクリーンの第２の部分におけるデータ・セルは前記 テスト対象半導体デバイスのためのテスト・プログラム実行のフローに関するデ ータを保持する、データ・セル・フィールドと、 ｂ）複数のツール・アイコンを有するツール・バー・フィールドと、 ｃ）それぞれのタブが異なるデータ入力スクリーンにアクセスするように選択 可能であるタブ・フィールドと、 ｃ）それぞれが複数のサブメニュ・アイテムを示すように選択可能である複数 のメニュ・アイテムを有するメニュ・バー・フィールドであって、前記メニュ・ アイテムの少なくとも１つの下にある前記サブメニュ・アイテムは、前記選択さ れたタブ・フィールドに応答して選択される、メニュ・バー・フィールドと、 を含む、ソフトウェア。 １３．ソフトウエアが市販のスプレッドシート・プログラムにおけるアプリケ ーションとして実現されている、請求項１２記載の自動テスト装置の制御ソフト ウェア。 １４．前記市販のスプレッドシート・プログラムはエクセルである、請求項１ ３記載の自動テスト装置の制御ソフトウェア。