JP2003501743A - 同種のシステム間におけるプロトコル応答 - Google Patents

Abstract

(57)【要約】 グラフィカルユーザインタフェイスプログラム、ターゲットデバイスと通信して前記グラフィカルユーザインタフェイスからのコマンドに応答するエンジン、オペレーティングシステムの少なくとも１つのコンポーネントのテスト及び評価を行うための少なくとも１つのテストを有する複数のテストスーツ、及びターゲットデバイスの使用を可能にするプロトコル応答ソフトウェアパッケージ(4000)とを有する、ホストコンピュータ上のテスト及び評価用ソフトウェアプログラムが提供される。前記プロトコル応答ソフトウェアパッケージは、オペレーティングシステムにより生成されたイベントハンドルをプロトコルのメンバフィールドとして使用してターゲットデバイスからの応答メッセージを待っている実行スレッドを解放し、前記イベントハンドルが応答メッセージパケット(3002)のヘッダ部分に配置されて前記応答メッセージ内で送り返され、受信スレッドが、前記応答メッセージ(2003)内のイベントハンドルを待っているあらゆる送信実行スレッドをアンブロックする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、製品の品質保証に関し、及びコンピュータ化された製品において提
供されるオペレーティングシステムの有効性を実証するテストシステム及び方法
に関する。より詳細には、本発明は、製品の品質保証に関し、及びコンピュータ
化された製品の開発時にオペレーティングシステムの有効性を実証するテストシ
ステム及び方法に関する。更に詳細には、本発明は、製品の品質保証に関し、及
びコンピュータ化された製品において一般に提供される（Microsoft, Incorpora
ted (Redond,WA)により製造販売されている）Windows CE（商標）等のオペレー
ティングシステムの有効性を実証するテストシステム及び方法に関する。

【０００２】

【従来の技術】

開発者は、セットトップボックス、ゲームシステム、バーコードスキャナ、及
びファクトリーオートメーションシステムを含む多くの異なるタイプのコンピュ
ータ化製品（以下コンピュータ化製品と称す）にWindows CE等のオペレーティン
グシステムを組み込むようになりつつある。Windows CEが成長するにつれて、「
市販の(off-the-shelf)」ソフトウェア開発ツールもまた必要とされている。装
置の設計時間を節約する（これは迅速な装置開発に通ずる）ために多くのツール
及び「市販の」ソフトウェアキットが販売されているが、かかる新製品の互換性
を（特に装置開発の最終段階で）確証するための高速なテストシステム又は方法
は全く存在しない。

【０００３】 従来、オペレーティングシステム装置テストの選択肢は、次の２つしか存在し
なかった。 (1) テストコードの社内での作成 (2) カスタムコードの開発の別会社へのアウトソーシング テストプロジェクトを社内で完遂するには、相手先商標製造会社（ＯＥＭ）は、
数ヶ月を要して同会社のスタッフを教育し、更に数ヶ月を要してテストコードを
開発し、更に数ヶ月を要して準備を整えた後、該テストコードを使用してテスト
を実施することが可能となる。同様に、アウトソーシングによるカスタムコード
開発を行う会社は、テストコードの開発に数ヶ月を要することになる。このため
、何れの選択肢も多くの時間を要するものとなり、したがって高コストとなる。

【０００４】 関連分野における品質保証のための装置テストシステムでは、幾つかのネット
ワークプロトコルが使用され、かかるプロトコルは、送信済メッセージに対する
応答を待つ間、プログラムの実行を保留させる。例えば、伝送制御プロトコル（
ＴＣＰ）は、低レベルでは、特定の送信済メッセージに対する応答が「コネクシ
ョン」の遠隔端により返されるまでプログラムの実行をブロックする。殆どのプ
ロトコルは、ＯＳに依存する態様で実施される。応答を必要とする送信済メッセ
ージは、かかる態様のものとして特定のリスト中に維持されなければならない。
該リストは、送信済メッセージの指示と実行スレッドとの相互参照を行うもので
あり、かかるスレッドは前記応答を待つものである。かかる関連分野のシステム
は、最初のメッセージの送信に先立ってメッセージＩＤを作成し、該メッセージ
ＩＤを実行スレッドに関連するリスト中の要素に付加し、該メッセージを送信し
、送信実行スレッドが受信コードによりアンブロックされる(unblock)まで該送
信実行スレッドをブロックし、元のメッセージＩＤを含むＡＣＫメッセージを返
送することで送信済メッセージに対する応答をリモートプロセスにより行い、該
ＡＣＫメッセージを送信側マシンにより受信し、元の送信済メッセージのメッセ
ージＩＤに関する構文解析を行い、リスト中のメッセージＩＤをルックアップし
、どの実行スレッドをリストから外すかを決定し、最後に元の送信実行スレッド
を解放して、プログラムの実行を続行する、という冗長なシーケンスに従うもの
である。

【０００５】 これらのオペレーティングシステム装置テストのための選択肢は、長時間を要
するものであるため、製品の品質を改善し、多くの人／月(person-month)という
時間及びコストを削減し、及び製品開発プロセスを効率化を提供させるための、
同種のシステム間でのプロトコル応答を利用する統合化されたテストシステムが
長い間必要とされてきた。特に、Windows CE オペレーティングシステムが組み
込まれたデバイスのテスト及び評価を行うためのシステム及び方法は、上述の問
題を克服することが必要とされており、ひいては、製品品質を改善し、多くの人
／月という時間及びコストを削減し、及び製品開発プロセスの効率化を提供し、
結果的にはデバイス設計者のための十分に自動化された設計評価パッケージを提
供する、システム及び方法を提供することが必要とされている。特に、ＯＳによ
り提供されるイベント、ＯＳが内部的に維持するイベントリスト、及びＯＳが内
部的に維持するブロックスレッド（すなわち送信スレッド）リストを使用するシ
ステムが必要とされている。このため、関連分野のプロトコル応答方法とは異な
り、幾つかのステップをなくす必要がある（例えば、実行スレッドに関連する要
素にリスト中のメッセージＩＤを付加し、該リスト中のメッセージＩＤを相互参
照し、及びリストエントリから外すべき実行スレッドを決定するという各ステッ
プ）。

【０００６】

【発明が解決しようとする課題】

このため、代替的なＡＣＫ処理方法による一層単純で短くてエラー発生率の低
いコードが有利なものとなる。この場合には、応答メッセージの受信時に複数の
アクションを実行することができる（例えば、多数の相互参照及び付随する遅延
がなくなり、ＡＣＫの受信のためのコードは、単一スレッドの場合とほぼ同一と
なり、優先順位データは、多数のスレッドが優先順位付けされる場合に送信済メ
ッセージリスト中に維持する必要のないものとなり、及びＩＤリストは、ＯＳが
適当な優先順位で全てのスレッドをリスタートさせる際にスレッド解放優先順位
を決定するために全体的にスキャンする必要のないものとなる）。有益なシステ
ムはまた、ＡＣＫメッセージを待っている多数の保留中の実行スレッドを実行す
ることができ、この場合、該実行スレッドは、最初の「送信」によりプロトコル
ヘッダ中に組み込まれたイベントハンドルを待つ機能（ＯＳにより提供される機
能）を単に使用するだけでよい。同様に、複数の送信済メッセージの何れかにつ
いてのＡＣＫにより、追加の相互参照処理を必要とすることなく、有利な多数の
実行スレッドをトリガすることが可能である。

【０００７】

【課題を解決するための手段】

したがって、本出願人の商標「CEValidator」を付して市販されることになる
本発明は、オペレーティングシステム評価手段(validator)（本書ではＯＳ評価
手段とも称す）であり、これを図面に符号1で示す。該ＯＳ評価手段は、新たに
開発されたターゲットデバイスのハードウェア及び／又はソフトウェアにおいて
Windows CE（商標）等のオペレーティングシステムのポートをテストするための
自動化されたテストスーツ方法を含むテストシステムを提供することにより、上
述の問題を解決するものである。該ＯＳ評価手段は、（特に、同種のシステム間
の応答プロトコルに関して一意で同時のマルチスレッド実行メソドロジーを使用
して、ＯＳ、デバイスドライバ、ＯＥＭアダプテーション層（ＯＡＬ:OEM Adapt
ation Layer）、及びハードウェアの対話に意図的にストレスを加えるよう開発
された）広範なコードベースを含むものである。該提供されるテストスーツは、
３つの主な欠陥、すなわち、ハードウェア設計、ハードウェアプログラミング（
ドライバ／ＯＡＬ）、及びオペレーティングシステム対話に的を絞ったものであ
る。歴史的に大多数の問題を示してきたWindows CEサブシステムに特に診断上の
重点が置かれる。該テストスーツは、1500近くのテストからなり、かかるテスト
は、システムストレステストルーチン並びに特徴及び機能テストを含み、Window
s CEポートの完全な分析を提供する。これらのテストはＯＳ評価手段によりグル
ープ化される。ＯＳ評価手段は、全てのテストに関するテスト用ソースコードと
実行可能プログラムとの両者を含んでいる。

【０００８】 テストスーツの実行及び情報採取(logging)結果の収集を単純化するために、M
icrosoft Windowsユーザインタフェイスをてこ入れする標準的なウィンドウズ（ 登録商標）アプリケーション等の、ＯＳ評価手段のホスト側コンポーネントのた めの直観的なユーザインタフェイスが利用される。ＯＳ評価手段は、クライアン ト／サーバアプリケーションとしてテストスーツを分散させる。グラフィカルユ ーザインタフェイス（ＧＵＩ）は、ターゲットデバイス上で実行されている小さ なアプリケーション「CEHarness.exe」と対話を行う。このための通信がEhterne tを介して発生するため、少なくとも１つのホストが少なくとも１つのターゲッ トデバイスに対して複数のスーツを実行することが可能である。

【０００９】 ＯＳ評価手段は、ターゲットデバイスがテストに合格しなかった場合に有用な
エラー情報を生成する。スーツの実行中に、複数の動的に生成されたログウィン
ドウ並びにコンフィギュレーションウィンドウのサマリタブに結果が表示される
。該ログウィンドウは、所与のテストの結果の完全なテキストを含む。テストの
不合格は、識別を容易にするために赤にカラーコード化される。ログウィンドウ
内のナビゲーションボタンは、ユーザが１つの不合格から別の不合格へと迅速に
移動することを可能にする。また、テストのログＡＰＩは、開始ログ(prolog)及
び終了ログ(epilog)を各結果ファイル中に生成することを可能にする。同時に実
行中のプロセス、バッテリーパワーレベル、及び実行日時といった情報が、前記
結果ファイル中に自動的に記録され、ログウィンドウ内に表示される。プログラ
ム用メモリの損失、記憶用メモリの損失、又は総テスト実行時間といった有用な
サマリ情報は、ログウィンドウタブ中に提供される。また、所与のテスト結果に
関するサマリ情報が収集されてコンフィギュレーションウィンドウのサマリタブ
中に表示される。該サマリタブは、多数の合格及び不合格のテストケースをリア
ルタイムで報告する。個々のスーツに関する合格及び不合格の数の明細(breakou
t)もまた表示される。コンフィギュレーションウィンドウのサマリタブは、おそ
らくは何千というテスト結果のうちの個々の不合格への迅速なナビゲーションを
可能にする。ロギングされた不合格に対応する厳密なソースファイル及び行番号
は、ＯＳ評価手段のログＡＰＩにより自動的に報告される。ＯＳ評価手段は、全
ての実行可能プログラムのソースコードを提供するため、エラーを報告するソー
スコードへ直接移行可能であることは、不合格のテキスト記述に対する強力な付
随物である。

【００１０】 本発明は、ＯＳにより生成されたイベントハンドルをプロトコルのメンバフィ
ールドとして使用して、応答（ＡＣＫ）メッセージを待っている実行スレッドを
解放する。ＷＩＮ３２イベントハンドル等のＯＳにより生成されるイベントハン
ドルは、元の送信実行スレッドをブロックするために使用されるものであり、ヘ
ッダ中に配置されてＡＣＫにおいて返信される。受信スレッドは、リストに対す
るトランザクション識別子（ＩＤ）のルックアップ処理を必要としない。その代
わり、受信スレッドは、イベントを待っているあらゆるスレッドをアンブロック
する。換言すれば、本発明は、ＯＳにより提供されるイベント、ＯＳにより内部
的に維持されるイベントリスト、及びＯＳにより内部的に維持されるブロックス
レッド（すなわち送信スレッド）リストを使用する。このため、関連分野のプロ
トコル応答方法とは異なり、幾つかのステップがなくなり、すなわち、実行スレ
ッドに関連する要素にリスト中のメッセージＩＤを付加し、該リスト中のメッセ
ージＩＤをルックアップし、及びリストエントリから外すべき実行スレッドを決
定する、という各ステップがなくなる。

【００１１】 結果的に、本発明の上記の代替的なＡＣＫ処理方法により、コードが一層単純
で短くてエラー発生率の低いものとなる。このため、本発明は、応答メッセージ
の受信時に複数のアクションを実行する場合に多くの利点を提供するものとなり
、すなわち、多数の相互参照及び付随する遅延がなくなり、ＡＣＫの受信のため
のコードが単一スレッドの場合とほぼ同一のものとなり、多数のスレッドが優先
順位付けされる場合に優先順位データを送信済メッセージリスト中に維持する必
要がなくなり、ＯＳが適当な優先順位で全てのスレッドをリスタートさせる際に
スレッド解放優先順位を決定するためにＩＤリストを全体的にスキャンする必要
がなくなる。ＡＣＫメッセージを待っている多数の保留中の実行スレッドを実行
するために、該実行スレッドは、最初の「送信」によりプロトコルヘッダ中に組
み込まれたイベントハンドルを待つ機能（ＯＳにより提供される機能）を単に使
用するだけでよい。同様に、複数の送信済メッセージの何れかについてのＡＣＫ
により、追加の相互参照処理を必要とすることなく、多数の実行スレッドをトリ
ガすることが可能である。

【００１２】 本発明の他の特徴については「発明の実施の形態」と題する以下のセクション
に開示する。該他の特徴は同セクションから自明である。

【００１３】

【発明の実施の形態】

図１は、コンピュータ化製品1000,(9)を示している。該コンピュータ化製品は
典型的には、オペレーティングシステム（符号1001aで示す）が組み込まれた現
行のコンピュータワークステーション、セットトップボックス、ゲームシステム
、バーコードスキャナ、及びファクトリオートメーションシステムといったもの
である。図示し本書で説明するように、製品1000は、組込型Windows CEオペレー
ティングシステム（ＯＳ）等のオペレーティングシステム1001aが組み込まれた
一般的なターゲットデバイス9を含むことが可能である。該コンピュータ化製品1
000は、本発明をインストールすれば、スタンドアロン装置として、すなわち、
該製品自体のオペレーティングシステム1001aのテスト及び評価を行うＯＳ評価
手段1として機能することが可能である。そのスタンドアロンテストは、ＯＳ評
価手段のインフラストラクチャに関する複雑な知識を必要としないため、新たな
テスト開発及び報告された欠陥のデバッグを容易化するものとなる。しかし、最
も考え得る用途では、図２に示すように、製品1000は、製造品質の保証のための
テスト環境Ｍにおいて、オペレーティングシステム1001aが設けられてターゲッ
トデバイス9をテストする本発明によるＯＳ評価手段1を実施したホストコンピュ
ータ4として機能する可能性がある。ここで図１を再び参照する。コンピュータ
化製品1000は、例えば、複数の入出力ポート1021を含む制御ユニット1020、キー
ボード1009、プリンタ1010、マウス1011、及びモニタ1012を含む幾つかの副構成
要素を備えることが可能である。かかる副構成要素1009,1010,1011,1012自体は
、テスト可能なターゲットデバイスとすることが可能なものである。典型的な制
御ユニット1020自体は、中央処理装置1001、ハードディスクドライブ1004等の記
憶装置やＲＡＭ1002、ＲＯＭ1003、コンパクトディスク1005等を含む他の記憶構
成要素、オーディオ構成要素1006、ネットワーク／サーバカード1007、及びモデ
ム1008を含む幾つかの副構成要素を備えている。制御ユニットに必ず必要なもの
は、製品1000を便利な装置として機能させるためのオペレーティングシステム10
01aである。

【００１４】 図３は、グラフィカルユーザインタフェイス（ＧＵＩ）2、エンジン3、複数の
テストスーツ11、及びロギングライブラリ12を含むＯＳ評価手段1の主な構成要
素を示している。ＧＵＩ2及びエンジン3は、ＯＳ評価手段1内に符号7で示し以下
で詳述するHarnessLink.dllと称するコンポーネントを介して内部的に双方向に
通信する。図４は、ＯＳ評価手段1が配設されたホストコンピュータ4を示してい
る。図示のように、複数のターゲットデバイス9には、本発明に従ってテストを
行うＯＳ1001aが配設されている。ＯＳ評価手段1は、該ターゲットデバイス9内
のＯＳ1001aの制御下で特定の機能をテストするために、複数のテストコンフィ
ギュレーション21a,21b,21c等のテスト用コンフィギュレーションを生成する能
力を有している。CEHarness8と称するデバイス側コンポーネントは、ＯＳ評価手
段1内のエンジン3と通信する。図５ａ及び図５ｂに示すように、CEHarness8は、
Ehternet手段4aを介してＯＳ評価手段1内のエンジン3と通信することも可能であ
る。図５ａは、Ehtenetを介した通信が可能であるため、複数のホスト4が複数の
ターゲットデバイス9に対して複数のスーツを実行することが可能であることを
示している。更に別の代替例では、特定のテストスーツ実行環境を図６に示すよ
うに、CEHarness8はまた、スーツ実行接続1021aを介してＯＳ評価手段1内のエン
ジン3と通信することも可能である。この場合、ホストコンピュータ4はＮＴ（商
標）ホストコンピュータとして構成することが可能であり、ロギングライブラリ
12もまたターゲットデバイス9中に配設され、テスト結果は、ソケット接続1021b
を介してホストコンピュータ4へ提供される。

【００１５】 動作には、ＯＳ評価手段1は、例えばWindows CEオペレーティングシステムに
より、オペレーティングシステムが組み込まれたターゲットデバイス9をテスト
し評価する。より広義には、ＯＳ評価手段1は、(1)ターゲットデバイスへのWido
ws CEポートを評価し、(2)ストレス及び性能テストを提供し、(3)結果のロギン
グ及び分析を行い、(4)複数のアプリケーションプログラムインタフェイス（Ａ
ＰＩ）（図７,８Ａ,８Ｂ,８Ｃにおけるテーブル1.0及びテーブル2.0を参照）を
含む複数の関数領域をテストし、(5)複数のテストスーツにおいて複数の合格／
不合格テストを実行し、(6)自動化されたスーツにおけるテストのカスタム化を
容易にし、(7)ホスト側のグラフィカルテストハーネスを提供し、(8)ストレスを
加えてメモリ性能を評価し、(9)複数のＡＰＩ（図９のテーブル3.0を参照）を含
むテストの自動化を構築するための手段を提供し、(10)CEAnalyzerと称する結果
分析ツールを提供することで機能する。既述のように、及び図１０に示すように
、ＯＳ評価手段1は、全てのテストについて、テストソースコードSCと実行可能
プログラムEP（テストエグゼキュータブルとも呼ばれる）との両者を含む。テス
トエグゼキュータブルEPに関する唯一の実施上の要件は、２つの特定のＡＰＩ「
WRITETESTPASS()」及び「WRITETESTFAIL()」を使用してテストケース「合格」及
び「不合格」が報告されることである。これらのマクロは、周知の関数「printf
()」と類似したシグネチャを有するものであるが、それらマクロの使用は、自動
化されたサマリ化になじみやすい標準的なテストケース結果形式を「結果」ファ
イルにおいて生成し、その報告をホストユーザインタフェイスと統合させるもの
となる。ＯＳ評価手段1による方法は更に、ＧＵＩ2とテストエグゼキュータブル
EP内にカプセル化されたテストケースとの間の取り次ぎを行い、及びＧＵＩ2が
複数のテストの分散及び調整を行うための手段を提供する、という各ステップを
含む。テストスーツ11は、テストの分散及び実行のために必要となるタスクの直
接的な表現であるスーツ言語コマンド（例えばPUT,RUN,WAIT,DELETE等）から構
成されるテキストファイル5を含む。その他のサポートされるコマンドとして、
ターゲットデバイス9からファイルを取り出すためのGET、ホストコンピュータ4
上で実行可能プログラムを実行するためのRUNHOST（クライアント／サーバ式の
テストにとって有用なもの）、ホストコンピュータ4上のプロセスの終了を待機
するWAITHOST（これもまたクライアント／サーバ式のテストにとって有用である
）、デバイスのシステムディレクトリ（/Windows）中にファイルを配置するため
のPUTSYSTEM、他の全てが不合格であった場合の基本的な時間であるSLEEP、ホス
トマシン上にメッセージボックスを表示するためのMSGBOX、デバイスのレジスト
リセッティングを追加し又は変更するためのSETREG、及びデバイスからレジスト
リセッティングを削除するためのDELREGが挙げられる。内部的なスーツドキュメ
ントに加えて、初期スーツファイルコメントが、スーツ記述としてＧＵＩ2に渡
される。ＯＳ評価手段1の方法は、ホストコンピュータ4上のディレクトリ構造内
で、複数のテストスーツファイル5を階層的な配置に編成する。図１１に示すよ
うに、テストスーツ11は、自動テストスーツ（Ａｕ）、手動テストスーツ（Ｍａ
）、又はストレステストスーツ（ＳＳ）の何れかになるようにトップレベルで分
けられる。自動スーツＡｕは、実行中にユーザの介在を一切必要としないテスト
である。これとは対照的に、手動スーツＭａはユーザの介在（例えばキーボード
及びタッチパネルスーツ）を必要とする。ＯＳ評価手段1の方法は、入出力（Ｉ
／Ｏ）スループットを限界まで高めることによりストレススーツＳＳを介してシ
ステムへストレスを加え、プログラム又はオブジェクト記憶メモリを僅かに使用
して又は全く使用せずに動作し、マルチスレッド化された同時のストレスにより
カスタムファイルシステムをおそらくは転覆させる(bring down)、をという各ス
テップを含む。この階層のトップレベルよりも下では、ＯＳ評価手段1の方法は
、関数領域（全体的に図７を参照）によりテストスーツ11を構成するステップを
含む。

【００１６】 上述のように、図３は、グラフィカルユーザインタフェイス（ＧＵＩ）2、エ
ンジン3、複数のテストスーツ11、及びロギングライブラリ12を含む、ＯＳ評価
手段1の主な構成要素を示している。ＯＳ評価手段1は、Visual Basicコンポーネ
ントとしてＧＵＩ2を利用する。これは、あらゆるレベルのユーザに対して良好
に機能するからである。ＧＵＩ2の設計は、基礎をなす構成要素とユーザ入力と
の間のインタフェイスをとるという概念に基づくものである。エンジン3は機能
の中核部分をホストコンピュータ4上に保持する。エンジン3は、複数のスーツフ
ァイル5を読み出し解析してコマンドを実行する。エンジン3は、ＧＵＩ2から情
報を取得し、該情報を使用して様々な実行オプションをセットアップする。エン
ジン3は、Ｃ／Ｃ＋＋言語で書かれる。エンジン3は、HarnessLink.dll 7（Activ
eXコントロール）と称するコンポーネントを介してＧＵＩ2にリンクされる。Har
nessLink.dll 7は、その実行を開始する前にエンジン3に渡される様々な情報に
よりＧＵＩ2から示され呼び出される。HarnessLink.dll 7はまた、実行中にエン
ジン3とＧＵＩ2との間で通信を行って、情報、エラーメッセージ、及び何らかの
動的な実行時コマンドを中継する。ターゲットデバイス9は、CEHarness 8と称す
るデバイス側（ホスト側と対局をなすもの）コンポーネントを含む。CEHarness
8は、ターゲットデバイス9上に存在するＣ／Ｃ＋＋プログラムであり、ネットワ
ーク上にターゲット情報がブロードキャストされ、かかる情報をＧＵＩ2が受信
して該情報をエンジン3に渡さない限り（図５及び図５ａ参照）、図４に示すよ
うに、ほぼ専らエンジン3と通信を行う。CEHarness 8は、イベント駆動型アプリ
ケーションであり、この場合、エンジン3がイベントを送りCEHarness 8がこれに
応答する。２つの残りのコンポーネント、すなわち、テストスーツ11及びロギン
グライブラリ12は互いに密接に関係する(intertwine)。これは、テストスーツ11
が、ロギングライブラリ12の一部をなす複数のアプリケーションプログラムイン
タフェイス（ＡＰＩ）を使用して書かれているからである（図８Ａ,８Ｂ,８Ｃを
参照）。これらのＡＰＩ13は、十分な機能を有するものであり、コンポーネント
チェーンを介して渡された情報に幾分か依存するものである。ロギングライブラ
リ12は、単純な機能上の概念を有するものであり、ＴＣＰ／ＩＰ情報16をＧＵＩ
2にロギングする（図５参照）ことにより又は結果14及びログファイル15をデバ
イス9に直接書き込む（図６参照）ことによりログファイル15を生成することで
、テスト結果14の通信を行う。図１２に示すように、ロギングウィンドウLWは、
テスト結果14をテストファイル15内に示し、プログラムメモリに対するユーザア
クセスを容易にする不合格F及びサマリタブSumTは、合格、不合格、及びタイミ
ング情報を示す。複数のテストスーツ11は、ＯＳ評価手段1の必要不可欠な構成
要素からなる。図１３は、複数のテストデバイスが同時にテストされる際にテス
トサイクル時間CTが短縮することを示すグラフである。

【００１７】 更に詳細には、ＧＵＩ2は、そのコンポーネント層を取り扱うのに必要となる
機能の度合いに起因して、複雑なコードとなる。ＧＵＩ2は「ウィザード」を提
供し、その主な機能は、新たなユーザに様々な選択可能なセッティングを提示し
デフォルトセッティングを列挙することである。図１４に示すように、ＧＵＩ2
はまた、テストデバイス9上の一組の選択されたスーツ11を介した単一パスから
なるテストランを実行するための手段としてコンフィギュレーションウィンドウ
CWを提供する。図４に示すように、複数のコンフィギュレーション21a,21b,21c
は、様々なシナリオをシミュレートするように実行させることが可能である。コ
ンフィギュレーションウィンドウCWの内容は、ユーザ制御のための複数のタブを
含む。例えば、スーツタブSは、ＯＳ評価手段1のディレクトリ下にあるスーツフ
ァイルディレクトリのツリービューを提供する。このツリービューは、ユーザが
選択する複数のタイプのテスト間で有意の相違を提供するよう編成される。更に
、このツリービューは、ユーザがコンフィギュレーションウィンドウCWをオープ
ンした際に生成され、該ユーザが、ＯＳ評価手段1のインストールプログラムに
より生成されたスーツファイルディレクトリへ新たなユーザ入力されたスーツを
追加することによりＯＳ評価手段1を拡張することを可能にする。テストスーツ1
1はコマンドスクリプトであり、該コマンドスクリプトをエンジン3が読み出して
該コマンドスクリプトに対応するアクションを実行する。スーツファイル5は、
典型的には一連のコメントで始まる。かかるコメントは、該スーツファイルのス
ーツファイル情報セクションに現れるものである。スーツファイル5の最上部に
ワード「手動」が現れた場合には、該ファイルは手動での実行を必要とし、この
ため異なるアイコンが割り当てられる。図１１に示すように、テストスーツセク
ションにおいて、ユーザは、テストスーツファイル5を任意の態様で整理し直す
ことが可能である。更に図１４を参照すると、ロギングタブはかなり有用な情報
を含む。ユーザは、３つのロギング方法、すなわち、ホスト4へのロギングLH、
ターゲットデバイス9へのロギングLTD、又はホスト4及びターゲットデバイス9の
両者へのロギングLHDを選択することが可能である。次いでログ情報が、編集ボ
ックス内に列挙された構成可能ディレクトリ内に格納される。この情報の全てが
DLL7を介してエンジン3へ送られ、次いでターゲットデバイス9内のCEHarness 8
へ送られる。続いて、該情報がテスト11の実行時にロギングライブラリ12により
獲得される。コンフィギュレーションウィンドウCW内の他のタブとして、ストレ
ス設定条件タブSC、スーツの実行時に高順位スレッドを選択するためのスレッド
選択タブT、プログラム及び記憶メモリを削減するためのタブPM,SM、実行時間を
選択するためのタブSRT、及び実行を停止させるためのタブSTOPが含まれる。ユ
ーザは、システムのメモリリークを探し出すために無限ループタブIloopを使用
することができる。プログラムメモリの損失、記憶メモリの損失、又は総テスト
実行時間といった有用なサマリ情報は、サマリタブSumT内に提供される。所与の
テスト結果に関するサマリ情報もまた収集されてサマリタブSumT内に表示される
。該サマリタブは、合格又は不合格テストケースの数をリアルタイムで報告する
。個々のスーツについての詳細な合格及び不合格の数もまた表示される。コンフ
ィギュレーションウィンドウのサマリタブは、おそらくは数千ものテスト結果の
うちの個々の不合格への迅速な誘導を容易化するものとなる。ロギングされた不
合格に対応する正確なソースファイル及び行番号が、ＯＳ評価手段のロギングＡ
ＰＩにより自動的に報告される。ＯＳ評価手段1が全てのエグゼキュータブルの
ソースコードを提供するため、エラーが報告されたソースコードへ直接移行する
ことが可能であることは、不合格のテキスト記述に対する強力な付随物である。

【００１８】 ロギングオプションは、その実施形態及び効果が動的に変化するものである。
第１のオプションは、ユーザがテストスーツ11を実行する際に必ず「合格」する
ことを仮定したものであり、かかるテスト結果14を要約した一組のログファイル
15が自動的に生成される。選択されたロギング方法に応じて、CEHarness 8又は
エンジン3の何れかによりサマリファイル15が生成される。基本的には、エンジ
ン3は、ロギングディレクトリ中のログファイル16を全て調査して、実行中のテ
スト11に対応しないログファイルリストをユーザが受信することを可能とする。
サマリファイル15を実行中のテスト11をより一層表すものとするために、ユーザ
は、実行前にログディレクトリを削除することが可能であり、又はエンジン3が
各テスト毎に１つのログファイル15のみを調査するようにする「最新のサマリ結
果のみを返す」といったロギングオプションを選択することが可能である。これ
は、ユーザが所与の日にファイルシステムテストを30回実行した場合に最も最近
の実行に対応するテストについてサマリログ内に１つのエントリしか存在しない
ことを意味する。該サマリログは、各テスト11毎にたった１つのエントリを有す
ることになり、該テストのログファイル15は、ロギングされたディレクトリ内に
未だ存在する。他の２つのオプションはＧＵＩ2内で操作される。ユーザが、Ｔ
ＣＰ／ＩＰ接続4aを介してホスト4にログオンした場合、該ユーザのホスト4上で
生成されたログファイル15内に１つのエントリが入り、ＧＵＩ2のログウィンド
ウ内に現れる。これにより、ユーザがＯＳ評価手段1に関連するログファイル15
を検査することが可能となり、これは大きな利点となる。これは、ユーザが合格
（より重要には不合格）を直ちに監視することができるからである。しかし、環
境によっては、実行されるテスト11のサイズに起因して過度の量のログファイル
が存在する可能性がある。このため、ログウィンドウLWをそれ以上オープンする
ことなくクローズすることによりホスト4のメモリが維持され、またＯＳ評価手
段1のためのクリアなビュー領域が提供されることになる。更なる利点として、
不合格のない全てのログファイル15のクローズが挙げられる。製品設計者にとっ
て、不合格は、ターゲットデバイス9を更に開発する必要があることを示すもの
である。ユーザは、不合格を含むウィンドウＦをオープンしたままにするための
ロギングウィンドウ中のオプションをクリックすることにより、不合格を含むウ
ィンドウＦを全てオープンしたままにすることを望む可能性がある。

【００１９】 図５ａに示すような本発明の動作時に、利用可能ターゲットと称するウィンド
ウが、ＧＵＩ2へ情報をブロードキャストしているネットワーク上のアクティブ
なデバイスを示す。該アクティブなデバイスは大量の情報を送り、そのうちの幾
つかが利用可能ターゲットウィンドウ内に表示される。ユーザは、ビュー／利用
可能ターゲットメニューを選択することにより情報を見ることが可能である。一
組の完全なブロードキャスト情報を得るために別のウィンドウにアクセスしては
ならない。このブロードキャスト情報は有用なものであり、エンジン3からター
ゲットデバイス9中の特定のCEHarness 8への接続を初期化するために使用される
。

【００２０】 図１１を参照してストレステストセッティングSSについて説明する。ストレス
スーツ11は、様々な形態で実施されるが、その基本的な目的は、極めて長いテス
トを実行し、短いテストの多数の反復を実行し、又は１回のテストで広範囲のパ
ラメータを選択することにより、ターゲットデバイス9にストレスを加えること
にある。これらは、それ自体のテスト領域に固有のもの（例えば、Windows CE（
商標）等のＯＳのデータベース機能にのみストレスを加えるデータベースストレ
ススーツ）となる。ストレステストオプションはストレススーツ11とは区別可能
なものである。ストレステストオプションは、実世界の慣行モデルと等価なより
広範囲のストレスシナリオを提供する機能をターゲットとしたものであるため、
ストレススーツとは異なるものである。かかるシナリオは、ユーザにより選択さ
れた任意の組をなすテストスーツファイル5に関連して実行される。任意のテス
トプランの範囲が大幅に高められる場合には、ストレステストオプションを互い
に連係して又は別個に実行することができ、またそうすべきである。最初の２つ
のストレステストオプションは、ターゲットデバイス9上のメモリに関係するも
のである。第１のストレステストオプションは、選択されたテスト11を実行する
前にターゲットデバイスの仮想メモリの量を大幅に低減させる低仮想メモリオプ
ションである。これは、ユーザが15個のアプリケーションをオープンした場合に
発生して動作不良を生じさせ得る現実的な厳しい環境をシミュレートする。第２
のストレステストオプションは低記憶メモリオプションである。該第２のオプシ
ョンが選択されると、該オプションは、低記憶メモリソリューションに対する応
答をターゲットデバイス9に経験させるために、該ターゲットデバイス9の記憶メ
モリをその最大容量まで満たす。場合によっては、この第２のストレステストオ
プションは、ターゲットデバイス9内に含まれるアプリケーションプログラムを
テストするのにも良好なものとなる。これは、かかるアプリケーションプログラ
ムが、記憶メモリが存在しないことに依存する可能性があるからである。次の３
つのストレステストオプションは実行オプションである。第１のエグゼキュータ
ブルストレスオプションは無限ループであり、これは長いテストサイクルにとっ
ては理想的である。多くのデバイスドライバにおける共通の問題は、長くて激し
くてストレスの大きい状況下での動作不良である。この無限ループストレステス
トは、考え得る故障を決定するためのテストを提供するものとなる。この無限ル
ープストレステストは、選択されたスーツ11を、ユーザがストップボタンを手動
で押下するまで実行する。次のストレス実行オプションは、Data.txtと称するＯ
Ｓ評価手段＼Tests＼TestInputFilesとして識別されるテキストファイルとして
利用することが可能な構成可能なＣＰＵサイクル剥奪(deprivation)テストであ
る。ユーザが、コピーし、再使用し、又は修正することが可能なファイルで２つ
の例が提供される。該テキストファイルData.txtは、ユーザがテストの実行に含
めることが可能なスレッドの数及びその属性を制御する。換言すれば、ユーザは
、他のプロセスがＣＰＵ時間を消費している間に自分のテストを実行することが
でき、これにより、タイミングを含む多くの問題が解消される。最後のストレス
テストオプションはランダム実行である。ユーザがこのオプションを選択すると
、ＧＵＩ2は、テストスーツ11のリストを実行時に整理し直し、該テストスーツ
を異なる順序で実行するようにする。このオプションは、様々なコンポーネント
に関する相互作用上の問題の診断を容易化するため、理想的なものである。

【００２１】 残りのテスト実行オプションは、ユーザが制御することが可能な汎用的なアク
ティビティである。第１のオプション「選択されたターゲットを専ら使用」は重
要なものである。これは、ターゲットデバイス9がEthernetを介して接続される
際に、サブネット中の他のユーザがＯＳ評価手段1の利用可能ターゲットデバイ
スウィンドウを介して該ターゲットデバイス9にアクセスできるからである。こ
れは、ターゲットデバイス9にストレスを生成するのを助ける。問題を隔離する
ことをユーザが望む場合には、余計なストレスを加えるべきではない。かかる状
況では、ユーザは、ターゲットデバイス9のみに対するアクセスを有するべきで
ある。最後のテスト実行オプションはターゲット時間の設定である。これは、ホ
ストコンピュータ4からターゲットデバイス9へ時間を送るようエンジン3に促す
ことにより、ターゲットデバイス9のシステム時間をホストコンピュータ4の時間
に同期させる。ターゲットデバイス9上の日時に関する日時スタンプと共にログ
ファイルが返されるため、該同期は有利である。これら日時を正確に維持するた
めに、ユーザはターゲットデバイス9の日時を設定すべきである。テストの実行
前の最後のタブは、様々な選択可能な環境変数のための重要な情報を含む環境設
定タブである。これらの環境設定は、テストスーツファイル5がハードカード(ha
rd carded)情報の代わりに環境変数を含むことを可能にすることによりテストス
ーツファイル5の拡張及び要約を行うよう設計される。例えば、シリアルテスト
は、利用可能なCOMポートをパラメータとして選択する。該COMポートが環境変数
として入力されなかった場合には、COMポートをオープンすることができないた
め、テストに失敗する。スーツで使用される全ての環境変数が提供されるが、ユ
ーザにより入力されるスーツに対してあらゆる追加の環境変数をユーザにより付
加することが可能である。テストの実行後、「テストステータス」を使用して、
現在のテストランに関するステータス情報を得ることが可能である。該情報は、
動的に更新されているものである。

【００２２】 スーツランセクションウィンドウは、既に開始されている選択されたスーツを
列挙する。ユーザは、所望のテストアイコンを選択することにより、任意のログ
ファイルをオープンすることが可能である。このコントロールにおける他のアイ
コンは、不合格情報を提供する。不合格アイコンは、例えば、赤い「Ｘ」が取消
線として付された様式化されたビーカーとして示される。テストランサマリ情報
は、実行されたテストスーツファイルの数、選択されたスーツ、不合格となった
スーツ、及び不合格となったスーツのパーセンテージを追跡する。１つのテスト
ランの完了時に、ユーザは、現在のテストランにおける全ての失敗したスーツを
選択する新たなコンフィギュレーションウィンドウを現すことを促す「構成失敗
スーツ」タブを選択することが可能であり、これにより回帰テストが容易となる
。

【００２３】 残りの２つのセクションは「テスト詳細」と呼ばれるものである。これらテス
ト詳細セクションの一方は、合格又は失敗となった個々のテストケースを監視す
るものであり、テストランの値を測定するのに有用なものである。残りのテスト
詳細セクションは、不合格を有する全ての選択されたスーツがスーツ名により列
挙されて、それに対応する合格及び不合格のテストケースの数が示される。この
情報の全ては、１つのテストラン中にターゲットデバイス9の限界に関する極め
て良好な見解（すなわち何が合格したか、より重要には何が不合格となったか）
をユーザに提供するものとなる。

【００２４】 本発明の主な目的は、Windows CE 等のＯＳ1001aのポートを適切にテストする
ことにある。このタスクを達成するために、数百というテストスーツ11が必要と
なり、かかるテストがＯＳ評価手段1により提供される。例えば、検証されたＯ
Ｓサブシステムによりグループ化された1500個近くのテストスーツ11が提供され
る。図１０に示すように、ＯＳ評価手段1は、（歴史的に最も多くの問題を呈し
ているサブシステムを最重要視して）主要なＯＳ1001aのサブシステム及び一般
的に適用されるドライバをカバーする全てのテスト11に関するソースコード及び
実行可能コードの両者を含む。ＯＳ評価手段1によりテストされるＯＳサブシス
テムのコンポーネントとしては、Ehternet/NDIS、シリアルポートドライバ、デ
ィスプレイドライバ、タッチパネルドライバ、マウスドライバ、キーボードドラ
イバ、ＯＥＭアダプテーション層、及びＰＣカードアダプタドライバが挙げられ
る。図１５Ａないし図１５Ｃは、これらのシステムコンポーネントのテストの詳
細を列挙した表である。

【００２５】 上述のように、及び図３に示したように、エンジン3は、HarnessLink.dll 7（
Active X コントロール）を介してＧＵＩ2にリンクされる。詳細には、HarnessL
ink.dll 7は、エンジン3を呼び出す（すなわちエンジン3を動かす）ための一組
の関数をＧＵＩ2に提供する。HarnessLink.dll 7の関数呼び出しの大多数が、エ
ンジン3のコマンドラインに関する幾つかのパラメータを設定する。該コマンド
ラインを介して初期情報の全てがエンジン3へ送られて、特定の実行に関するエ
ンジン3の準備が確実に整う。複数のＧＵＩ関連機能が、コマンドラインに関す
る情報を提供する。コマンドラインに関する情報はＧＵＩ2の情報に対応する。H
arnessLink.dll 7が提供する他の主要な機能は、名前付きパイプをオープンする
ことによりエンジン3の実行中にアクティビティを通信することである。何らか
のメモリ情報を送信するために何らかのエラー又は必要性が生じた場合に、エン
ジン3は名前付パイプを介して通信を行う。名前付パイプは、エンジン3と特定の
HarnessLinkとの間の通信が直接的で正確なものであり及び複数のエンジン3が実
行している場合に複製上の問題を伴うことのないものとなることを確実にする。
HarnessLink.dll 7は、パイプからメッセージを受信すると、適当なＶＢイベン
トを通知し、次いで該ＶＢイベントがＧＵＩ2に情報の取得並びにその処理を行
わせる。図５に関連して上述したように、エンジン3は、１つのHarnessLink.dll
7と通信し、次いで該HarnessLink.dll 7がCEHarness 8と通信する。エンジン3
の実行は単純なものであり、すなわち、コマンドラインが受信されて処理され、
ターゲットデバイスへの実行ソケット接続を確立し、ＧＵＩ2との通信のための
パイプをオープンし、テストスーツファイル5を読み出し、続いてテストを３つ
の段階（事前実行、実行、後実行）で実行する。事前実行段階は、ターゲットデ
バイス9とホスト4との間のエラーソケット接続を確立する。ロギングパス及びス
タイル、様々なテストラン情報、及びストレスシナリオといった関連データは、
事前実行段階で送られる。実行段階は、一連の各スーツコマンドに対する応答を
伴う。スーツコマンドは一般にホスト4により送られてCEHarness 8により処理さ
れ、次いで該コマンドの実行が完了した際に該CEHarness 8がソケットメッセー
ジで応答する。後実行段階は、ログ情報の縮小及びサマリログの生成を主に伴う
ものである。かかるサマリログの完成時に、エンジン3はその処理を終了する。
ターゲットデバイス9中のCEHarness 8は、エンジン3よりも遙かに複雑なコンポ
ーネントである。これは、各ターゲットデバイス9が所与の時点で１つのCEHarne
ss 8を有するが、該デバイス9が複数の接続を同時に扱い得るからであり、これ
は、ＯＳ評価手段1により提供されるテスト方法論に対する絶対的に重要な特徴
である。ユーザがCEHarness 8を開始させると、該CEHarness 8は、実行時間全体
にわたり持続する２つのスレッドすなわちブロードキャストスレッド及び実行ス
レッドを生成する。該ブロードキャストスレッドは、デバイスＩＰ、コネクショ
ンタイプ、及び利用可能なCOMポートといった情報を10秒毎に更新し、ネットワ
ークと同じ速度でメッセージをブロードキャストする。デバイス9がWindows CE
サービスを介してホストコンピュータ4（すなわちＮＴ側）に接続され、及びrem
net又はrepllog（すなわちデバイス側）に接続されると、コネクションタイプが
ＰＰＰピアに変更されることになる。これが生じると、ターゲットデバイス9が
直接接続しているホスト4に対してのみブロードキャストメッセージが送られる
。ユーザが実行中に何らかの時点でコネクションを変更した場合に、該メッセー
ジが更新される。その間、実行スレッドが該コネクションを受容して、必要とさ
れる様々な機能を実行するもう１つのスレッド（すなわちメイン実行スレッド）
を生成する。該メイン実行スレッドは、エラー及びメモリ情報を送るためのもう
１つのソケットを開始させる。このため、実行スレッドは、イベント駆動型のも
のであり、コマンドの受信及び応答を適宜行うものである。各コネクションの試
行は、それ自体のスレッドを生成し、それ故、単一のCEHarness 8は、多数のア
クティブなコネクションを有することが可能であり、１つのターゲットデバイス
9について複数のコンフィギュレーションを同時に実行することによりテスト機
能を拡張させ、これにより一層現実的なストレス状況を生成することが可能なも
のである。

【００２６】 図１６は、メッセージ送信手段2000及びメッセージ受信手段3000を備えた本発
明のプロトコル応答システム4000を示すフローチャートである。該メッセージ送
信手段2000は、情報の並列処理を可能にする受信スレッド2001及び送信スレッド
2009を有している。該送信スレッド2009はブロック2008でメッセージを生成し、
ブロック2007に示すように、WIN32イベントハンドルがヘッダフィールド内にあ
るパケットを形成するよう該メッセージの周辺にヘッダを配置する。次いでかか
るパケットが、ブロック2006で、送信スレッド2009をブロックするためにブロッ
ク2005へ送られ、又はメッセージ受信手段3000により該パケットを受信するため
にブロック3001へ送られ、次いで該メッセージ受信手段3000が、ブロック3002に
示すように、ヘッダフィールド内にWIN32イベントハンドルを有するパケットを
受信ブロック2002を介して受信スレッド2001へ送り、又は該メッセージ受信手段
3000の機能に従って処理を続行する。受信スレッド2001は、応答パケットを受信
すると、ブロック2003で、該応答パケットのヘッダ中のWIN32イベントハンドル
を使用して送信スレッドをアンブロックし、次いでブロック2004で送信スレッド
2009を再開させ、又は該受信スレッド2001の機能の処理を続行する。

【００２７】 このため、図３に示すロギングライブラリ12は、様々な態様でＯＳ評価手段1
と統合された複雑なツールである。第１に、ロギングライブラリ12は、テスト用
のソースファイル中に統合される。該テストは、テスト結果の捕捉及び記録に関
する全ての詳細を該ライブラリが扱う場合にライブラリＡＰＩに対する呼び出し
を行うものである。ロギングライブラリ12はまた、様々な通信オプションをサポ
ートする。推奨されるオプションはＴＣＰを介したものであり、これにより、ユ
ーザがＴＣＰコネクションから移動する際に該ユーザがログファイルの情報を見
ることが可能となる。別の通信オプションは、デバイス上のファイルに対する直
接的なロギングである。これは、例えば、ユーザがPCMCIAカードに対するログは
必要とするがネットワーク上にブロードキャストされる余分な情報は必要としな
い場合に有利なものである。しかし、ロギングライブラリ12はＴＣＰ通信に対し
てデバイス側のコンポーネントとして作用し、ホスト4のコンポーネントはＴＣ
Ｐ通信に対してＧＵＩ2側のコンポーネントとして作用する。このロギングライ
ブラリ12の特徴は、ホスト4上にログウィンドウを提供しテスト結果に関するカ
ラーコードを提供する。例えば、不合格メッセージが赤ラインとして表示される
。ソースコードファイルの名称及び位置並びにメッセージが生成された行番号が
、ロギングライブラリ12のメッセージ内に含まれる。また、極めて重要なことに
、プログラム中の現在のイベントを解説する詳細なエラーメッセージが提供され
る。各ログウィンドウは、プログラムメモリ、合格、不合格、及びタイミング情
報へのユーザアクセスを容易にするサマリタブを有している。ログファイルの別
の重要な特徴は、テストの開始時及び終了時に大量の情報を捕捉することにある
。この情報は、メモリ、システム、電源、及びその他の有用な情報のスナップシ
ョットを提供する。

【００２８】 本書で詳細に解説し図示した情報は、本発明の上記目的を十分に達成すること
が可能なものであると共に、本発明の現時点での好適な実施形態であり、したが
って、本発明が広範に意図する要旨を表したものである。本発明の範囲は、当業
者にとって自明である他の実施形態を完全に包含するものであり、したがって、
特許請求の範囲以外の如何なるものによっても制限されるものではない。また、
特許請求の範囲において、単一の構成要素は（特に明記しない限り）「唯一」を
意図するものではなく、「１つ又は２つ以上」を意味するものである。上述の好
適な実施形態及び当業者に自明な更なる実施形態と構造的または機能的に等価な
ものを特許請求の範囲に含めることが意図されている。また、本発明が解決しよ
うとする個々の又はあらゆる問題に取り組む装置又は方法を本発明に含める必要
はない。更に、本開示の構成要素、部品、又は方法ステップは、各請求項に明示
されている。

【図面の簡単な説明】

【図１】 制御ユニット内にオペレーティングシステムが組み込まれたコンピュータ化製
品を示す概略図である。

【図２】 オペレーティングシステムが組み込まれたコンピュータ化製品についての本発
明による品質保証テストを示す製造フローチャートである。

【図３】 本発明のオペレーティングシステム評価手段の主な構成要素（本発明によるグ
ラフィカルユーザインタフェイス、エンジン、複数のテストスーツ、及びロギン
グライブラリを含む）を示すブロック図である。

【図４】 オペレーティングシステムが組み込まれた複数のターゲットデバイスをテスト
するためのホスト装置からの本発明による複数のテストスーツコンフィギュレー
ションの実行を示すブロック図である。

【図５】 ホストにおけるＯＳ評価手段とのターゲットデバイスによるEthernet手段を介
した通信を示している点を除き、本質的には図４に示した本発明を示すブロック
図である。

【図５ａ】 複数のホストとターゲットデバイスとの間の通信をEthernetを介して行うこと
が可能な本発明による構成を示している。

【図６】 テストスーツ実行環境のための本発明による更に別の構成を示している。

【図７】 自動的に又は手動でテストスーツを実行することによりテストされる特定のＡ
ＰＩの関数領域を示すテーブルである。

【図８Ａ】 本発明に従って自動モード又は手動モードでテストすることが可能な関数領域
及びその個々のＡＰＩを包括的に示すテーブルである。

【図８Ｂ】 本発明に従って自動モード又は手動モードでテストすることが可能な関数領域
及びその個々のＡＰＩを包括的に示すテーブルである。

【図８Ｃ】 本発明に従って自動モード又は手動モードでテストすることが可能な関数領域
及びその個々のＡＰＩを包括的に示すテーブルである。

【図９】 本発明による自動スクリプトの作成に使用するために選択されたＡＰＩのテー
ブルである。

【図１０】 本発明による全ての実行可能プログラムについてソースコードを提供する本発
明の思想を示す概略図である。

【図１１】 本発明によるテストスーツ選択オプション並びに他の関連するサマリ機能を示
すウィンドウをブロック図である。

【図１２】 本発明によるテスト結果、テスト不合格、及び関連するテストサマリオプショ
ンのためのタブを示すロギングウィンドウを示すブロック図である。

【図１３】 本発明による現在テスト中のテスト装置の数の関数としてテストサイクル時間
を示すグラフである。

【図１４】 本発明による様々なコンフィギュレーション関連機能を実行するためのタブを
示すコンフィギュレーションウィンドウを示すブロック図である。

【図１５Ａ】 本発明によるオペレーティングシステムの構成要素のテストの詳細のリストを
示すテーブルである。

【図１５Ｂ】 本発明によるオペレーティングシステムの構成要素のテストの詳細のリストを
示すテーブルである。

【図１５Ｃ】 本発明によるオペレーティングシステムの構成要素のテストの詳細のリストを
示すテーブルである。

【図１６】 本発明による同種のシステム間の応答プロトコルに関する一意の同時のマルチ
スレッド化能力を示すフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ， ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ， ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，Ｋ Ｒ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ， ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，Ｓ Ｇ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 ウォルターズ，ジェイムス，フロイド アメリカ合衆国ワシントン州98101，シア トル，セネカ・ストリート・ナンバー 404・1101 (72)発明者 サンプル，イアン アメリカ合衆国ワシントン州98105，シア トル，ユニバーシティ・ウェイ・ノースイ ースト・ナンバー101・5256 (72)発明者 ルーカス，ショーン，マイケル アメリカ合衆国ワシントン州98028，ケン モア，ノースイースト・ワンハンドレッド セブンティファースト・レーン・7239 (72)発明者 ディング，ジー，エイチ アメリカ合衆国ワシントン州98053，レッ ドモンド，ノースイースト・サーティファ ースト・コート・27523 (72)発明者 ボイス，デイビッド，マシュー アメリカ合衆国ワシントン州98032，ケン ト，シックスティセカンド・アベニュー・ サウス・ナンバーティー208・25331 Ｆターム(参考） 5B042 GA12 GA21 GA23 GC10 HH11 HH17 5B089 GA21 GB01 GB02 JA35 KE02 KE03 KF04 MC16 5B098 GA02 GA05 GC16 JJ06

Claims (20)

【特許請求の範囲】
1. 【請求項１】 ターゲットデバイス内に組み込まれたオペレーティングシステムのテスト及び
   評価を行うためのコンピュータベースのシステムであって、 a. ホストコンピュータと、 b. オペレーティングシステムが配設されたターゲットデバイスと、 c. 前記ホストコンピュータ内に配設されたオペレーティングシステムテスト及
   び評価用ソフトウェアプログラムであって、 該プログラムが、ユーザとのインタフェイスをとるグラフィカルユーザイ
   ンタフェイスプログラム手段と、前記ターゲットデバイスと通信し前記グラフィ
   カルユーザインタフェイスからのコマンドに応答するエンジン手段と、前記オペ
   レーティングシステムの少なくとも１つのコンポーネントのテスト及び評価を行
   うための少なくとも１つのテストを含む複数のテストスーツと、前記ターゲット
   デバイスの使用を可能にするプロトコル応答ソフトウェアパッケージとからなり
   、 該プロトコル応答ソフトウェアパッケージが、オペレーティングシステム
   により生成されたイベントハンドルを、前記ターゲットデバイスからの応答メッ
   セージを待っている実行スレッドを解放するためにプロトコルのメンバフィール
   ドとして利用し、 前記イベントハンドルが、メッセージパケットのヘッダ部内に配置されて
   前記応答メッセージ内で送り返され、該応答メッセージ内の該イベントハンドル
   を待っているあらゆる送信実行スレッドを受信スレッドがアンブロックする、 オペレーティングシステムテスト及び評価用ソフトウェアプログラムと、 d. 該オペレーティングシステムテスト及び評価用ソフトウェアプログラムによ
   り生成されたテスト関連情報の操作及び格納を行うためのロギングライブラリ手
   段と を備えている、ターゲットデバイス内に組み込まれたオペレーティングシステム
   のテスト及び評価を行うためのコンピュータベースのシステム。
2. 【請求項２】 前記オペレーティングシステムテスト及び評価用ソフトウェアプログラムが、
   前記エンジン手段を呼び出すための一組の機能を前記グラフィカルユーザインタ
   フェイス上に有している、請求項１に記載のコンピュータベースのシステム。
3. 【請求項３】 前記ターゲットデバイスが、前記エンジン手段と通信するためのイベント駆動
   型アプリケーションを更に備えており、 前記エンジン手段がイベントを送出し、前記イベント駆動型アプリケーション
   がこれに応答する、 請求項１に記載のコンピュータベースのシステム。
4. 【請求項４】 前記ターゲットデバイス内の前記オペレーティングシステムが、Windows CE
   オペレーティングシステムからなり、 前記イベントハンドルがWIN32イベントハンドルである、 、請求項１に記載のコンピュータベースのシステム。
5. 【請求項５】 前記テストスーツが、少なくとも１つのシステムストレステストルーチン及び
   少なくとも１つの機能及び関数テストからなる、請求項１に記載のコンピュータ
   ベースのシステム。
6. 【請求項６】 前記システムストレステストルーチンが、前記オペレーティングシステムの前
   記少なくとも１つのコンポーネントのストレステストを行うためのコードベース
   からなり、 前記オペレーティングシステムの前記少なくとも１つのコンポーネントが、Et
   hernet/NDIS、PCMCIA、メモリ、ファイルシステム、シリアルポート、複数のア
   プリケーションプログラムインタフェイスを有するビデオシステム、赤外線シス
   テム、ＯＥＭアダプテーション層、タッチパネル、マウス、キーボード、及びオ
   ーディオ／waveシステムを含む１グループのオペレーティングシステムコンポー
   ネントから選択され、 前記テストが、少なくとも３つの欠陥、すなわち、ハードウェア設計、ハード
   ウェアプログラミング、及びオペレーティングシステム対話を識別し、及び自動
   又は手動モードで実行される、 請求項５に記載のコンピュータベースのシステム。
7. 【請求項７】 前記ターゲットデバイスが、前記ホストコンピュータとは独立して評価及びス
   トレステストを行う前記オペレーティングシステムテスト及び評価用ソフトウェ
   アプログラムが配設されたスタンドアロンユニットからなる、請求項１に記載の
   コンピュータベースのシステム。
8. 【請求項８】 テスト及び評価タスクを実行するために前記ホスト及び前記ターゲットデバイ
   スに結合されたEthernetコネクションを含む、請求項１に記載のコンピュータベ
   ースのシステム。
9. 【請求項９】 前記ロギングライブラリ手段が、WRITETESTPASSアプリケーションプログラム
   インタフェイスを用いた少なくとも１つの合格テスト結果ファイルを含む、請求
   項１に記載のコンピュータベースのシステム。
10. 【請求項１０】 前記少なくとも１つのパステストファイルが前記ターゲットデバイス内に存在
    する、請求項９に記載のコンピュータベースのシステム。
11. 【請求項１１】 前記ロギングライブラリ手段が、WRITETESTFAILアプリケーションプログラム
    インタフェイスを用いた少なくとも１つの不合格テスト結果ファイルを含む、請
    求項１に記載のコンピュータベースのシステム。
12. 【請求項１２】 前記少なくとも１つの不合格テスト結果ファイルが前記ターゲットデバイス内
    に存在する、請求項１１に記載のコンピュータベースのシステム。
13. 【請求項１３】 ターゲットデバイス内に組み込まれたオペレーティングシステムのテスト及び
    評価を行うためのコンピュータベースの方法であって、 a. ホストコンピュータを配設し、 b. オペレーティングシステムを有するターゲットデバイスを配設し、 c. 前記ホストコンピュータ内にオペレーティングシステムテスト及び評価用ソ
    フトウェアプログラムを配設し、 該プログラムが、ユーザとのインタフェイスをとるグラフィカルユーザイ
    ンタフェイスプログラム手段と、前記ターゲットデバイスと通信し前記グラフィ
    カルユーザインタフェイスからのコマンドに応答するエンジン手段と、前記オペ
    レーティングシステムの少なくとも１つのコンポーネントのテスト及び評価を行
    うための少なくとも１つのテストを含む複数のテストスーツと、前記ターゲット
    デバイスの使用を可能にするプロトコル応答ソフトウェアパッケージとからなり
    、 前記プロトコル応答ソフトウェアパッケージが、オペレーティングシステ
    ムにより生成されたイベントハンドルを、前記ターゲットデバイスからの応答メ
    ッセージを待っている実行スレッドを解放するためにプロトコルのメンバフィー
    ルドとして利用し、 前記イベントハンドルが、メッセージパケットのヘッダ部内に配置されて
    前記応答メッセージ内で送り返され、受信スレッドが、前記応答メッセージ内の
    前記イベントハンドルを待っているあらゆる送信実行スレッドをアンブロックし
    、 d. 該オペレーティングシステムテスト及び評価用ソフトウェアプログラムによ
    り生成されたテスト関連情報の操作及び格納を行うためのロギングライブラリ手
    段を提供し、 e. 前記ターゲットデバイス上の前記オペレーティングシステムテスト及び評価
    ソフトウェアプログラムを実行して前記オペレーティングシステムのテスト及び
    評価を行い、該実行ステップが、 前記応答メッセージ内の前記イベントハンドルに応じて送信実行スレッド
    をアンブロックすることからなり、 f. 合格及び不合格テスト結果を生成する、 という各ステップを有する、ターゲットデバイス内に組み込まれたオペレーティ
    ングシステムのテスト及び評価を行うためのコンピュータベースの方法。
14. 【請求項１４】 前記エンジン手段を呼び出すための前記グラフィカルユーザインタフェイス上
    の一組の機能を前記オペレーティングシステムテスト及び評価用ソフトウェアプ
    ログラムに設けるステップを更に有する、請求項１３に記載の組込型オペレーテ
    ィングシステムのテスト及び評価を行うためのコンピュータベースの方法。
15. 【請求項１５】 前記エンジン手段と通信するためのイベント駆動型アプリケーションを前記タ
    ーゲットデバイスに設け、該エンジン手段がイベントを送出し、前記イベント駆
    動型アプリケーションがこれに応答する、請求項１３に記載の組込型オペレーテ
    ィングシステムのテスト及び評価を行うためのコンピュータベースの方法。
16. 【請求項１６】 a. 前記ターゲットデバイスにWindows CE オペレーティングシステムを提供し
    、 b. 前記イベントハンドルにWIN32イベントハンドルを提供する、 という各ステップを更に有する、請求項１３に記載の組込型オペレーティングシ
    ステムのテスト及び評価を行うためのコンピュータベースの方法。
17. 【請求項１７】 前記オペレーティングシステムの少なくとも１つのコンポーネントのストレス
    テストを行うためのコードベースを含むシステムストレステストルーチンという
    形でテストスーツを提供し、 前記オペレーティングシステムの前記少なくとも１つのコンポーネントが、Et
    hernet/NDIS、PCMCIA、メモリ、ファイルシステム、シリアルポート、複数のア
    プリケーションプログラムインタフェイスを有するビデオシステム、赤外線シス
    テム、ＯＥＭアダプテーション層、タッチパネル、マウス、キーボード、及びオ
    ーディオ／waveシステムを含む１グループのオペレーティングシステムコンポー
    ネントから選択され、 前記テストが、少なくとも３つの欠陥、すなわち、ハードウェア設計、ハード
    ウェアプログラミング、及びオペレーティングシステム対話を識別し、及び自動
    又は手動モードで実行される、 という各ステップを更に有する、請求項１３に記載の組込型オペレーティングシ
    ステムのテスト及び評価を行うためのコンピュータベースの方法。
18. 【請求項１８】 前記ターゲットデバイスについてテスト及び評価タスクを実行するために前記
    ホスト及び前記ターゲットデバイスに結合されたEthernetコネクションを提供す
    るステップを更に有する、請求項１３に記載の組込型オペレーティングシステム
    のテスト及び評価を行うためのコンピュータベースの方法。
19. 【請求項１９】 WRITETESTPASSアプリケーションプログラムインタフェイスを用いた少なくと
    も１つの合格テスト結果ファイルを前記ロギングライブラリ手段に提供するステ
    ップを更に有する、請求項１３に記載の組込型オペレーティングシステムのテス
    ト及び評価を行うためのコンピュータベースの方法。
20. 【請求項２０】 WRITETESTFAILアプリケーションプログラムインタフェイスを用いた少なくと
    も１つの不合格テスト結果ファイルを前記ロギングライブラリ手段に提供するス
    テップを更に有する、請求項１３に記載の組込型オペレーティングシステムのテ
    スト及び評価を行うためのコンピュータベースの方法。