(57)【要約】  ＡＰＩの実行手順を記載するテスト手順記述部と、ターゲット装置のＡＰＩのインターフェースをテスト手順記述部に提供することでＡＰＩを呼び出すコマンドを発行して戻り値を取得する仮想ＡＰＩ部と、スクリプト解釈を行なうスクリプト実行部と、ターゲット装置にコマンドを送信するコマンド送信部と、ターゲット装置からＡＰＩ実行後の結果ログを受信するログ受信部とを備えて、ターゲット装置上に実装されたユーザプログラムをＡＰＩ単位で制御し検証する。
2009150788.tif 000002
【特許請求の範囲】
【請求項１】
ＡＰＩ(Application Program Interface)を実行可能なターゲット装置に相互通信可能に接続されたＡＰＩ検証装置であって、
前記ＡＰＩのテスト手順が記述されたテスト手順記述部と、
前記ターゲット装置におけるＡＰＩインターフェースを前記テスト手順記述部に提供したうえで当該テスト手順記述部から前記テスト手順を取り出し、取り出した当該テスト手順で前記ＡＰＩを呼び出すコマンドを発行する仮想ＡＰＩ部と、
前記コマンドのスクリプト解釈を行なうスクリプト実行部と、
前記スクリプト実行部でスクリプト解釈された前記コマンドを前記ターゲット装置に送信するコマンド送信部と、
前記コマンドに基づいて前記ＡＰＩを実行する前記ターゲット装置から前記ＡＰＩの実行結果ログを受信するログ受信部と、
を備え、
前記仮想ＡＰＩ部は、前記ログ受信部が受信する前記実行結果ログから前記ＡＰＩを実行することで得られる戻り値を取得する、
ＡＰＩ検証装置。
【請求項２】
前記仮想ＡＰＩ部は、前記ターゲット装置上で実行される前記ＡＰＩと同種のインターフェースを有しており、
かつ前記仮想ＡＰＩ部は、
前記ターゲット装置で前記ＡＰＩを実行させるトリガを出力するＡＰＩ実行器と、
前記ＡＰＩに渡すパラメータを記憶するパラメータ記憶器と、
前記ターゲット装置が前記ＡＰＩの実行を完了するタイミングを検出するＡＰＩ実行完了待機設定器と、
前記ターゲット装置で実行される前記ＡＰＩにおける実行完了イベントを管理するイベント情報管理器と、
前記実行結果ログから、前記戻り値を示す情報と、ＡＰＩ実行完了を示す情報と、イベント情報に関するログとを抽出するログフィルタと、
を備える、
請求項１のＡＰＩ検証装置。
【請求項３】
請求項２のＡＰＩ検証装置と、前記ターゲット装置とを備え、
前記ターゲット装置は、
前記ＡＰＩ検証装置が送信する前記コマンドを受信するコマンド受信部と、
前記コマンドと前記ＡＰＩとを互いに対応させて記憶するコマンド・ＡＰＩ対応管理部と、
前記コマンド受信部で受信する前記コマンドに対応付けられた前記ＡＰＩを前記コマンド・ＡＰＩ対応管理部において特定したうえで、特定した前記ＡＰＩを実行するコマンド実行部と、
前記ＡＰＩが提供する機能が実装されたユーザプログラムと、
前記コマンド実行部で前記ＡＰＩが実行されることで得られる戻り値と返却引数の値とを含む前記実行結果ログを作成するログ出力部と、
前記実行結果ログの出力方法を定義するログ記述ルール管理部と、
前記ログ記述ルール管理部で定義された前記出力方法に基づいて前記実行結果ログを前記ＡＰＩ検証装置に送信するログ送信部と、
を備える、
検証システム。
【請求項４】
前記ターゲット装置は、
前記ＡＰＩの実行後に任意のタイミングで発生する、非同期イベントを受信するイベント受信部をさらに備え、
前記ログ記述ルール管理部は、前記非同期イベントに関するログの出力方法を定義し、
前記イベント受信部は、前記非同期イベントの受信を前記ログ出力部に通知し、
前記ログ出力部は、前記非同期イベントを検証する際には、前記ログ記述ルール管理部から読み出した前記非同期イベントに関するログ記述ルールを含む実行結果ログを生成し、
前記仮想ＡＰＩ部は、
前記ターゲット装置で前記非同期イベントが発生するタイミングを検出する非同期イベント待機設定器をさらに備え、
前記イベント情報管理器は、前記非同期イベントの情報をさらに管理し、
前記ログフィルタは、前記イベント情報管理器で管理している前記非同期イベントの情報に基づいて、前記実行結果ログから前記非同期イベントに関するログを抽出する、
請求項３の検証システム。
【請求項５】
前記テスト手順記述部は、
第一のテスト手順が記述された第一のテスト手順記述部と、
第二のテスト手順が記述された第二のテスト手順記述部と、
を備え、
前記仮想ＡＰＩ部は、
前記第一のテスト手順記述部から読出した前記第一のテスト手順と前記第二のテスト手順記述部から読出した前記第二のテスト手順とに、これらのテスト手順を個別に識別する識別子を付与したうえで、識別子付与後の両テスト手順を、前記ＡＰＩ実行器における両テスト手順の実施状態に応じて前記ＡＰＩ実行器に順次出力する仮想ＡＰＩ制御器を、
さらに備え、
前記ＡＰＩ実行器は、
前記第一のテスト手順に記載されたＡＰＩ実行手順を実施する第一のＡＰＩ実行器と、
前記第二のテスト手順に記載されたＡＰＩ実行手順を実施する第二のＡＰＩ実行器と、
をさらに備え、
前記ＡＰＩ実行完了待機設定器は、前記第一のＡＰＩ実行器と、前記第二のＡＰＩ実行器とにＡＰＩ実行完了通知を行ない、
前記コマンド実行部は、前記コマンドから前記識別子に基づいて前記第一、第二のテスト手順のどちらが実行されているのかを判別したうえでその判別結果を前記ログ出力部に出力し、
前記ログ出力部は、前記判別結果に基づいて前記第一のテスト手順と前記第二のテスト手順とのうちのどちらを実施しているかを示すログを含んだ前記実行結果ログを出力する、
請求項３のＡＰＩ検証システム。
【請求項６】
前記ターゲット装置は、
第一のターゲット装置と、
第二のターゲット装置と、
を備え、
前記テスト手順記述部に記述された前記テスト手順には、当該テスト手順を実行するターゲット装置を指定する情報がさらに記述されており、
前記ＡＰＩ実行器は、
第一のＡＰＩ実行器と、
第二のＡＰＩ実行器と、
を備え、
前記仮想ＡＰＩ部は、
前記テスト手順で指定されたターゲット装置の識別情報と前記ＡＰＩ実行器とを関連付けたコマンドを前記ＡＰＩ実行器に出力する仮想ＡＰＩ制御器を、
さらに備え、
前記ＡＰＩ実行完了待機設定器は、前記ログフィルタが抽出する前記実行結果ログを、前記第一のＡＰＩ実行器と前記第二のＡＰＩ実行器とに通知する、
請求項３の検証システム。
【請求項７】
前記ログフィルタは、前記実行結果ログから前記ＡＰＩのテスト結果を判定するためのログをさらに抽出し、
前記ＡＰＩ検証装置は、
前記テスト結果を判定するためのログに基づいて前記ＡＰＩが正しく実行されたか否かを判定するテスト結果判定部を、
さらに備える、
請求項３の検証システム。
【請求項８】
前記ターゲット装置は、
前記テスト結果を判定するためのログの記述ルールが記述されたログ記述ルール管理部と、
前記テスト結果を判定するためのログと前記実行結果ログとを振り分けるログフィルタと、
前記ログフィルタによって振り分けられた前記テスト結果を判定するためのログを蓄積するログ蓄積部と、
をさらに備え、
前記ログ送信部は、ＡＰＩの実行完了後、前記テスト結果の判定を行なうためのログを前記ログ蓄積部から読み出して、前記ＡＰＩ検証装置に送信する、
請求項７の検証システム。
【請求項９】
前記ターゲット装置は、
前記テスト結果を判定するためのログと前記実行結果ログとを振り分けるログフィルタと、
前記ログフィルタで振り分けられた前記テスト結果を判定するためのログを前記ＡＰＩ検証装置に送信する第二のログ送信部と、
を備え、
前記ＡＰＩ検証装置は、
前記第二のログ送信部から送信された前記テスト結果の判定するためのログを受信して前記テスト結果判定部に直接出力する第二のログ受信部を、
さらに備える、
請求項７の検証システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置を評価する技術に関し、特にマイクロコンピュータが組み込まれた装置を評価する技術に関する。
【背景技術】
【０００２】
近年家電機器の商品サイクルの短期化から開発期間の短縮化が要求されるようになり、その結果、組み込みソフト開発の検証工数においても効率化が要求されている。検証工数の効率化のために、マイクロコンピュータのユーザプログラムを自動で評価する検証システムが研究されている。（例えば、特許文献１参照）。【０００３】
図１２を参照して従来技術について説明する。この従来技術の検証システムは、ホストコンピュータ２と、ユーザシステム１（以降、ターゲットシステムまたはターゲット装置とも呼ぶ）とに、以下の構成を備える。すなわち、ホストコンピュータ２上の検証装置はコマンド制御部１２１と通信制御部１２４とを備える。コマンド制御部１２１は評価結果比較部１２３とコマンド実行部１２２とを備える。ユーザシステム１上には、通信制御部１０２（データ受信部１０３とデータ送信部１０４とからなる）と、コマンド判定部１０５と、ユーザメモリ１０８と、同期コマンド処理部１０６と、非同期コマンド処理部１０７とを備える。【０００４】
上記従来の検証システムでは、ホストコンピュータ２上の検証装置のコマンド制御部１２１からユーザシステム１上のリアルタイムＯＳの機能を操作するコマンドを出力することによって、ユーザプログラムを制御して検証を行なう。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１８９６１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の検証システムでは、リアルタイムＯＳ上の機能を使用してユーザプログラムを制御するため、ユーザプログラムをタスク単位でしか制御することができない。そのため、種々のテスト項目において、ＡＰＩ界面でテストすることができない。なお、ＡＰＩとは、Application Program Interfaceのことであって、ＯＳやミドルウェア等のプラットフォームに対応するソフトウェアを開発する際に使用可能な命令/関数やそれら命令/関数を利用するためのプログラム上の手続きを定めた規約の集合等からなるインターフェースを示す。
【課題を解決するための手段】
【０００７】
本発明のＡＰＩ検証システムは、
ＡＰＩ(Application Program Interface)を実行可能なターゲット装置と、前記ターゲット装置に相互通信可能に接続されたＡＰＩ検証装置とを備え、
前記ＡＰＩ検証装置は、
前記ＡＰＩのテスト手順が記述されたテスト手順記述部と、
前記ターゲット装置におけるＡＰＩインターフェースを前記テスト手順記述部に提供したうえで当該テスト手順記述部から前記テスト手順を取り出し、取り出した当該テスト手順で前記ＡＰＩを呼び出すコマンドを発行する仮想ＡＰＩ部と、
前記コマンドのスクリプト解釈を行なうスクリプト実行部と、
前記スクリプト実行部でスクリプト解釈された前記コマンドを前記ターゲット装置に送信するコマンド送信部と、
前記コマンドに基づいて前記ＡＰＩを実行する前記ターゲット装置から前記ＡＰＩの実行結果ログを受信するログ受信部と、
を備え、
前記仮想ＡＰＩ部は、前記ログ受信部が受信する前記実行結果ログから前記ＡＰＩを実行することで得られる戻り値を取得し、
前記仮想ＡＰＩ部は、前記ターゲット装置上で実行される前記ＡＰＩと同種のインターフェースを有しており、
かつ前記仮想ＡＰＩ部は、
前記ターゲット装置で前記ＡＰＩを実行させるトリガを出力するＡＰＩ実行器と、
前記ＡＰＩに渡すパラメータを記憶するパラメータ記憶器と、
前記ターゲット装置が前記ＡＰＩの実行を完了するタイミングを検出するＡＰＩ実行完了待機設定器と、
前記ターゲット装置で実行される前記ＡＰＩにおける実行完了イベントを管理するイベント情報管理器と、
前記実行結果ログから、前記戻り値を示す情報と、ＡＰＩ実行完了を示す情報と、イベント情報に関するログとを抽出するログフィルタと、
を備え、
前記ターゲット装置は、
前記ＡＰＩ検証装置が送信する前記コマンドを受信するコマンド受信部と、
前記コマンドと前記ＡＰＩとを互いに対応させて記憶するコマンド・ＡＰＩ対応管理部と、
前記コマンド受信部で受信する前記コマンドに対応付けられた前記ＡＰＩを前記コマンド・ＡＰＩ対応管理部において特定したうえで、特定した前記ＡＰＩを実行するコマンド実行部と、
前記ＡＰＩが提供する機能が実装されたユーザプログラムと、
前記コマンド実行部で前記ＡＰＩが実行されることで得られる戻り値と返却引数の値とを含む前記実行結果ログを作成するログ出力部と、
前記実行結果ログの出力方法を定義するログ記述ルール管理部と、
前記ログ記述ルール管理部で定義された前記出力方法に基づいて前記実行結果ログを前記ＡＰＩ検証装置に送信するログ送信部と、
を備える。【０００８】
かかる構成により、ターゲット装置上のユーザプログラムをＡＰＩ単位で制御し、ターゲット装置上で出力したログからテスト結果を判定することを可能となる。【０００９】
本発明のＡＰＩ検証システムは、
前記ＡＰＩの実行後に任意のタイミングで発生する、非同期イベントを受信するイベント受信部をさらに備え、
前記ログ記述ルール管理部は、前記非同期イベントに関するログの出力方法を定義し、
前記イベント受信部は、前記非同期イベントの受信を前記ログ出力部に通知し、
前記ログ出力部は、前記非同期イベントを検証する際には、前記ログ記述ルール管理部から読み出した前記非同期イベントに関するログ記述ルールを含む実行結果ログを生成し、
前記仮想ＡＰＩ部は、
前記ターゲット装置で前記非同期イベントが発生するタイミングを検出する非同期イベント待機設定器をさらに備え、
前記イベント情報管理器は、前記非同期イベントの情報をさらに管理し、
前記ログフィルタは、前記イベント情報管理器で管理している前記非同期イベントの情報に基づいて、前記実行結果ログから前記非同期イベントに関するログを抽出する、
のが好ましい。かかる構成により、前記発明に加え、ＡＰＩ検証システム上で非同期イベントに対応する制御も可能となる。【００１０】
本発明のＡＰＩ検証システムは、
前記テスト手順記述部は、
第一のテスト手順が記述された第一のテスト手順記述部と、
第二のテスト手順が記述された第二のテスト手順記述部と、
を備え、
前記仮想ＡＰＩ部は、
前記第一のテスト手順記述部から読出した前記第一のテスト記述と前記第二のテスト手順記述部から読出した前記第二のテスト記述とに、これらのテスト手順を個別に識別する識別子を付与したうえで、識別子付与後の両テスト手順を、前記ＡＰＩ実行器における両テスト手順の実施状態に応じて前記ＡＰＩ実行器に順次出力する仮想ＡＰＩ制御器を、
さらに備え、
前記ＡＰＩ実行器は、
前記第一のテスト手順に記載されたＡＰＩ実行手順を実施する第一のＡＰＩ実行器と、
前記第二のテスト手順に記載されたＡＰＩ実行手順を実施する第二のＡＰＩ実行器と、
をさらに備え、
前記ＡＰＩ実行完了待機設定器は、前記第一のＡＰＩ実行器と、前記第二のＡＰＩ実行器とにＡＰＩ実行完了通知を行ない、
前記コマンド実行部は、前記コマンドから前記識別子に基づいて前記第一、第二のテスト手順のどちらが実行されているのかを判別したうえでその判別結果を前記ログ出力部に出力し、
前記ログ出力部は、前記判別結果に基づいて前記第一のテスト手順と前記第二のテスト手順とのうちのどちらを実施しているかを示すログを含んだ前記実行結果ログを出力する、
のが好ましい。【００１１】
かかる構成により、複数のテスト手順を同時に実行することが可能となる。なお、同構成により、テスト手順を複数のターゲット上で実行することも可能となる。
【発明の効果】
【００１２】
本発明のＡＰＩ検証装置によれば、テストスクリプトからユーザシステム上に実装されたソフトウェアをＡＰＩ単位で制御することが可能となる。これにより、テスト実行時のシステムの状態をＡＰＩ呼び出しにより取得したうえで、取得した状態に応じて関連するソフトウェアを制御することができる。そのため、常に同じテスト条件を作り出すことができる。その結果、デバイスドライバなどの下位層のソフトウェアを、ＡＰＩの界面でテストすることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】図１は本発明の実施の形態１における検証システム全体を示す構成図である。
【図２】図２は実施の形態１におけるパラメータ記憶器に登録するデータ構造である。
【図３】図３は、実施の形態１におけるイベント情報である。
【図４】図４は、実施の形態１におけるコマンド構造を示す図である。
【図５】図５は、実施の形態１におけるコマンド・ＡＰＩ対応を表す図である。
【図６】図６は、実施の形態１におけるログ記述ルールである。
【図７】図７は、実施の形態１における検証システム全体を示す構成図である。
【図８】図８は、実施の形態１における検証システム全体を示す構成図である。
【図９】図９は、実施の形態１における実行ログ記述ルールである。
【図１０】図１０は、本発明の実施の形態２における検証システム全体を示す構成図である。
【図１１】図１１は、本発明の実施の形態３における検証システム全体を示す構成図である。
【図１２】図１２は、従来例における検証システム全体を示す構成図である。
【発明を実施するための形態】
【００１４】
以下、本発明のＡＰＩ検証装置等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動を行うので、再度の説明を省略する場合がある。
【００１５】
（実施の形態１）
図１は、本発明の実施の態１におけるＡＰＩ検証装置のブロック図である。本実施形態にかかる検証システムは、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ａとターゲット装置２０００Ａとを備える。ＡＰＩ検証装置１０００Ａは、テスト手順記述部１１００、仮想ＡＰＩ部１２００、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える。仮想ＡＰＩ部１２００は、ＡＰＩ実行器１２０１、パラメータ記憶器１２０２、ＡＰＩ実行完了待機設定器１２０３、イベント情報管理器１２０４、ログフィルタ１２０５、およびテスト結果判定部１６００を備える。ターゲット装置２０００Ａは、コマンド受信部２１００、コマンド実行部２２００、コマンド・ＡＰＩ対応管理部２３００、ユーザプログラム２４００、ログ出力部２５００、ログ記述ルール管理部２６００、およびログ送信部２７００を備える。
【００１６】
以下、実際に検証を行なう際の流れを説明するとともに各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ａのコマンド送信動作と、ターゲット装置２０００Ａのログ送信動作と、ＡＰＩ検証装置１０００Ａのログ受信動作とを含む。
【００１７】
（ＡＰＩ検証装置１０００Ａのコマンド送信動作）
テスト手順記述部１１００にはテスト実行手順が記述されている。テスト実行手順は、ＡＰＩに渡す引数の値の代入手順やＡＰＩの呼び出し順序が記載されたものである。以降、テスト実行手順をＡＰＩの実行単位に区切ったものをＡＰＩの実行手順と呼ぶ。検証が開始されるとテスト手順記述部１１００は、テスト手順をＡＰＩ実行器１２０１に出力する。テスト手順を受け取ったＡＰＩ実行器１２０１は、引数や戻り値を設定する変数の情報をパラメータ記憶器１２０２に登録するとともに、ＡＰＩの実行が完了するまで待機する旨のＡＰＩの実行登録をＡＰＩ実行完了待機設定器１２０３に行なう。その後、ＡＰＩ実行器１２０１は、ＡＰＩ実行手順をスクリプト実行部１３００に出力する。
【００１８】
ここでパラメータ記憶器１２０２に登録・記憶されるパラメータ詳細内容について説明する。パラメータ詳細内容とは、引数や戻り値を設定する変数の情報のことである。図２はパラメータ記憶器１２０２に登録・記憶されるパラメータ詳細内容を示す図である。パラメータ記憶器１２０２には、パラメータ詳細内容として、ＡＰＩ名と、そのＡＰＩに渡される引数および戻り値とが互いに関連付けられた状態で格納される。したがって、パラメータの詳細内容を参照すれば、登録されているＡＰＩ名から引数と戻り値とを特定できる。引数と戻り値とには、ＡＰＩを呼び出す際においてＡＰＩに入力されるパラメータの値のみが設定される。そのうえで、引数と戻り値とには、ＡＰＩの呼び出しが完了した後において出力パラメータが設定される。なお、出力パラメータの設定はログフィルタ１２０５より行なわれる。
【００１９】
ＡＰＩ実行完了待機設定器１２０３は、ＡＰＩ完了イベントをイベント情報管理器１２０４に登録する。具体的にはＡＰＩ実行完了待機設定器１２０３は、ＡＰＩ完了イベントとして“WAITING情報”をイベント情報管理器１２０４に登録する。イベント情報管理器１２０４は、“WAITING情報”に基づいて、登録された情報（ＡＰＩやそのパラメータ詳細内容）がログフィルタ１２０５にイベントとして通知されるまで、”WAITING″(待ち)を行なう。ここで言う”WAITING”とは、例えば無限ループや定期的にイベントを確認するポーリング処理などを示すが、それらに限定されるものではないのはいうまでもない。
【００２０】
イベント情報管理器１２０４は、ＡＰＩの完了イベントとＡＰＩとを関連付けてなるイベント情報を保持する。図３はイベント情報管理器１２０４が保持するイベント情報の例を示す。図３の例では、文字列でイベント名を表しており、仮想ＡＰＩ部１２００は、イベント情報管理器１２０４が保持するイベント情報を検出するか否かに基づいて、処理がＡＰＩの呼び出しから復帰してきたか否かを判断する。パラメータ記憶器１２０２は、ＡＰＩ実行器１２０１によって登録処理される引数や戻り値といったパラメータ詳細情報を保持する。
【００２１】
スクリプト実行部１３００はＡＰＩ実行器１２０１から送られてきたＡＰＩ実行手順を解釈することでそれを図４に示すコマンドの構造（以下、単にコマンドと称す）に変換する。スクリプト実行部１３００は、コマンド（ＡＰＩ実行手順）をコマンド送信部１４００に出力する。コマンド送信部１４００は、スクリプト実行部１３００から受け取ったコマンドを送信順序に従ってターゲット装置２０００Ａに送信する。
【００２２】
ここで、コマンド送信部１４００によって送信されるコマンドの説明を行なう。図４に示すようにコマンドは文字列によって表されており、先頭の「ＡＰＩＮＡＭＥ」という文字列によって表わされるＡＰＩとその引数とが順次配置されている。コマンドは、その配置順に沿ってコマンド送信部１４００からターゲット装置２０００Ａに送信される。
【００２３】
（ターゲット装置２０００Ａのコマンド受信/ログ送信動作）
コマンド受信部２１００は、ＡＰＩ検証装置１０００Ａから送信されるコマンドを受信し、コマンド実行部２２００に渡す。コマンド実行部２２００は、コマンド・ＡＰＩ対応管理部２３００に格納されているコマンドとＡＰＩとの対応付けを参照することで、受信したコマンドに対応するＡＰＩをユーザプログラム２４００から読み出して実行する。以下、さらに詳細に説明する。
【００２４】
コマンド・ＡＰＩ対応管理部２３００は、図５に示すように、ＡＰＩ名と、そのＡＰＩがユーザプログラム２４００のメモリ（以下、単にメモリという）上に配置されているアドレスとを対応付けて保持している。コマンド実行部２２００は、コマンド内のＡＰＩ名（図例では「ＡＰＩＮＡＭＥ#Ｘ」（Ｘ：通し番号）からなる文字列）を、コマンド・ＡＰＩ対応管理部２３００に参照することで、そのＡＰＩが配置されているメモリ上の先頭アドレス（以下、ＡＰＩ先頭アドレスという）を特定する。さらにコマンド・ＡＰＩ対応管理部２３００は、特定したＡＰＩ先頭アドレスに存在するＡＰＩを実行する。更にコマンド実行部２２００は、ＡＰＩ実行した結果（引数・戻り値）をユーザプログラム２４００から取得して、ログ出力部２５００に渡す。ログ出力部２５００は、ログ記述ルール管理部２６００に設けられた管理情報（以下、ログ記述ルールという）を元に受け取ったＡＰＩ実行結果を示すログ（以下、ＡＰＩ実行結果ログと呼ぶ）を作成し、作成したＡＰＩ実行結果ログをログ送信部２７００に出力する。
【００２５】
ログ記述ルール管理部２６００が管理するログ記述ルールの構造について図６を参照して説明する。図６は、ユーザプログラム２４００上のＡＰＩを呼び出した場合のログ記述ルールの例を示す。この例では、先頭に「ＥＶＴ＿ＡＰＩＲＥＴ：」という文字列が、その後に「ＲＥＴＶＡＬ」の部分が、さらにその後に「ＡＲＧＶＡＬ１」、「ＡＲＧＶＡＬ２」の部分が設けられている。なお、ここでいう前後とは、データ送信順序に沿った位置関係をいう。
【００２６】
「ＥＶＴ＿ＡＰＩＲＥＴ：」は、ＡＰＩを呼び出す際のログ記述ルールであることを示す。「ＲＥＴＶＡＬ」の部分には、ＡＰＩを呼び出す際に返却された戻り値がログとして付加される。「ＡＲＧＶＡＬ１」、「ＡＲＧＶＡＬ２」の部分には、ＡＰＩの引数として出力されるパラメータのログが付加される。
【００２７】
ログ出力部２５００による出力動作に戻って説明を行う。ログ出力部２５００は、テスト結果を判定するためのログ（以下、テスト結果を判定するためのログという）を、ログ記述ルールで記述されたＡＰＩ実行結果ログとともにログ送信部２７００に出力する。テスト結果を判定するためのログは、例えばＡＰＩに渡した引数・戻り値の情報やＡＰＩの内部の処理経路を表すログのことを示し、その先頭には、テスト結果を判定するためのログであることを表すヘッダが付加される。このヘッダの一例が図９に示す「＜ＥＸＬＯＧ＞」である。以降、ＡＰＩ実行結果ログとテスト結果を判定するためのログとを合わせて実行結果ログという。ログ送信部２７００は、実行結果ログをＡＰＩ検証装置１０００Ａのログ受信部１５００に送信する。
【００２８】
（ＡＰＩ検証装置１０００Ａのログ受信動作）
ログ受信部１５００は、ターゲット装置２０００Ａから受信した実行結果ログをログフィルタ１２０５に出力する。ログフィルタ１２０５は、実行結果ログを受け取ると、イベント情報管理器１２０４から“WAITING情報”を取得する。“WAITING情報”とは、前述した通り、待ちＡＰＩ実行完了待機設定器１２０３がWAITING（待ち）を行なっているＡＰＩ（イベント）に関する情報である。ログフィルタ１２０５は、実行結果ログを“WAITING情報”に基づいて解析することで、実行結果ログの中に、WAITING（待ち）を行なっているＡＰＩの実行結果が含まれるか否かを判断する。含まれると判断する場合、ログフィルタ１２０５は、WAITING（待ち）を行なっているＡＰＩの実行が完了したと判断してそのことをＡＰＩ実行完了待機設定器１２０３に通知する。ＡＰＩ実行完了待機設定器１２０３は、受け取った通知（ＡＰＩ完了通知）に基づいて、実行が完了したＡＰＩのWAITING（待ち）を解除する。さらにログフィルタ１２０５は、実行結果ログから、処理が完了したＡＰＩのＡＰＩ実行結果ログを抽出する。このログは前述したように引数や戻り値の情報である。ログフィルタ１２０５は、抽出したＡＰＩ実行結果ログをパラメータ記憶器１２０２に登録されている変数の情報に照合させることでその値（引数・戻り値）を設定する。ログフィルタ１２０５は、設定したＡＰＩ実行結果ログの値（引数・戻り値）をログフィルタ１２０５を介してＡＰＩ実行完了待機設定器１２０３に出力する。
【００２９】
さらにログフィルタ１２０５は、実行結果ログから、テスト結果を判定するためのログを抽出し、抽出したテスト結果を判定するためのログをテスト結果判定部１６００に出力する。テスト結果判定部１６００はテスト結果を判定するためのログを解析することで、実行が完了したＡＰＩが正しく実行されたか否かを判定する。
【００３０】
ＡＰＩ実行完了待機設定器１２０３は、WAITING（待ち）を解除したタイミングでＡＰＩ実行結果ログの値（引数・戻り値）をＡＰＩ実行器１２０１を介してテスト手順記述部１１００に出力する。テスト手順記述部１１００は、取得したＡＰＩ実行結果ログの値（引数・戻り値）に基づいて次のＡＰＩの呼び出しを実施する。
【００３１】
以上説明したように、本実施の形態によれば仮想ＡＰＩ部１２００がターゲット装置２０００Ａと同期してＡＰＩの呼び出しコマンドの送信や、決まった形式で出力された実行結果ログを解析してその引数・戻り値を設定したうえで、設定した引数・戻り値をテスト手順記述部１１００に返却する。これにより、テスト手順記述部１１００上では、仮想ＡＰＩ部１２００が提供するユーザプログラムと同じインターフェースを用いて、ターゲット側ＡＰＩの実行を制御することが可能となる。これにより本実施の形態では、ターゲット装置２０００Ａ上で出力された実行結果ログに基づいてテスト結果判定部１６００がテスト結果を自動的に判定することが可能となる。
【００３２】
なお、本実施の形態では、図７に示すように、ターゲット装置２０００Ｆにログ蓄積部２９００とログフィルタ２８００とを設けてもよい。この構成では、テスト結果を判定するためのログを一旦ターゲット装置２０００Ｆのログ蓄積部２９００で蓄積したうえで、テスト手順が一通り実施されたタイミングでテスト結果を判定するためのログをターゲット装置２０００Ｆのログ送信部２７００からＡＰＩ検証装置１０００Ｆに送信する。ＡＰＩ検証装置１０００Ｆでは、受信したテスト結果を判定するためのログをログ受信部１５００とログフィルタ１２１５とを介してテスト結果判定部１６００に出力する。これによれば、テスト結果を判定するためのログの伝送に起因してＡＰＩの実行が遅延することが防止される。
【００３３】
さらに、本実施の形態では、図８に示すように、ターゲット装置２０００Ｇにログフィルタ２８００と第二のログ送信部２７１０とをさらに設け、ＡＰＩ検証装置１０００Ｇに第二のログ受信部１５１０をさらに設けてもよい。この構成では、ターゲット装置２０００Ｇのログフィルタ２８００が、ＡＰＩ実行結果ログからテスト結果を判定するためのログを抽出したうえで、抽出したテスト結果を判定するためのログを、ログフィルタ２８００が第二のログ送信部２７１０を介してＡＰＩ検証装置１０００Ｇに送信する。ＡＰＩ検証装置１０００Ｇでは、第二のログ受信部１５１０でテスト結果を判定するためのログを受信したうえで、第二のログ受信部１５１０から直接にテスト結果判定部１６００に出力することでテスト結果を判定するためのログの伝送に起因してＡＰＩの実行が遅延することが防止される。
【００３４】
（実施の形態２）
実施の形態２では、非同期イベントを検証するシステムについて説明する。まず、本実施の形態２における、非同期イベントの定義について明らかにする。非同期イベントとは、ＡＰＩ実行をトリガとしてターゲット装置上のハードウェア、ソフトウェアから発生する割り込みイベントのことを示す。例えば、メモリ間のデータ転送開始処理が実装されたＡＰＩの場合、ＡＰＩの呼び出し後、データの転送開始処理自体は確認できるが、データの転送処理自体が実施されたどうかは、実際にハードウェア及び更に下位にあたるプログラムからの応答を受けるまで確認することができない。ここで言う“応答”とは、例えばデータ転送完了通知等を示す。このようなハードウェア及び下位プログラムからの応答のことを非同期イベントと呼ぶ。
【００３５】
図１０は本発明の実施の形態２の構成図である。図１０についても図１と同様に、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ｂとターゲット装置２０００Ｂとを備える。ＡＰＩ検証装置１０００Ｂは、テスト手順記述部１１００、仮想ＡＰＩ部１２１０、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える。仮想ＡＰＩ部１２１０は、ＡＰＩ実行器１２０１、パラメータ記憶器１２０２、ＡＰＩ実行完了待機設定器１２０３、イベント情報管理器１２１４、ログフィルタ１２１５、および非同期イベント待機設定器１２１６を備える。
【００３６】
ターゲット装置２０００Ｂは、コマンド受信部２１００、コマンド実行部２２００、コマンド・ＡＰＩ対応管理部２３００、ユーザプログラム２４００、ログ出力部２５００、ログ記述ルール管理部２６１０、ログ送信部２７００、およびイベント受信部３０００を備える。
【００３７】
本実施の形態が実施の形態１と異なる点は、
・ＡＰＩ検証装置１０００Ｂが非同期イベント待機設定器１２１６を備えること、
・イベント情報管理器１２１４が非同期イベント情報管理機能を備えること、
・ログフィルタ１２１５が非同期イベント抽出機能を備えること、
・ターゲット装置２０００Ｂにイベント受信部３０００を備えること、
である。
【００３８】
以下、本実施の形態において、非同期イベントのWAITING(待ち）処理を実施する際における各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ｂの準備動作と、ターゲット装置２０００Ｂのログ送信動作と、ＡＰＩ検証装置１０００Ｂのログ受信動作とを含む。
【００３９】
（ＡＰＩ検証装置１０００Ｂの準備動作）
非同期イベントのWAITING(待ち)処理を行なう場合、テスト手順記述部１１００は、非同期イベント待機設定器１２１６に、非同期イベントのWAITING(待ち)処理を行なう際の手順を示す情報を出力する。非同期イベント待機設定器１２１６は、イベント情報管理器１２１４に、WAITING(待ち)処理を行なうイベント情報を登録する。なお、非同期イベントのWAITING(待ち)処理を行なう手順とは、非同期イベント待機設定器１２１６によって待機開始が設定されたうえで待機が終了する（返却される）までの間の一連の処理手順のことを示す。
【００４０】
（ターゲット装置２０００Ｂのログ送信動作）
ＡＰＩ検証装置１０００Ｂの準備動作が完了した後、テスト手順記述部１１００からのＡＰＩの実行などをトリガとして、ターゲット装置２０００Ｂの上のシステムで非同期イベントが発生すると、イベント受信部３０００は、ユーザプログラム２４００から、非同期イベントが発生した際に通知されるパラメータを受信し、ログ出力部２５００に出力する。ログ出力部２５００はログ記述ルール管理部２６１０から非同期イベントのログ記述ルールを参照して非同期イベントの実行結果ログを作成する。ログ出力部２５００は、作成した非同期イベントの実行結果ログをログ送信部２７００に出力する。ログ送信部２７００は、受け取った非同期イベントの実行結果ログをＡＰＩ検証装置１０００Ｂのログ受信部１５００に送信する。
【００４１】
（ＡＰＩ検証装置１０００Ｂのログ受信動作）
ログ受信部１５００は、ログ送信部２７００から受け取った非同期イベントの実行結果ログをログフィルタ１２１５に出力する。ログフィルタ１２１５は、受け取った非同期イベントの実行結果ログを解析する。この解析において、イベント情報管理器１２１４に登録されている非同期イベントを検出すると、ログフィルタ１２１５は、非同期イベントログに含まれるパラメータをパラメータ記憶器１２０２に設定し、さらに、非同期イベントを検出したことを非同期イベント待機設定器１２１６に通知する。
【００４２】
非同期イベント待機設定器１２１６は、非同期イベント検出通知を受け取ると、パラメータ記憶器１２０２から非同期イベントにより返却される変数を呼び出し、呼び出した変数に非同期イベント時に返却された値を設定して、テスト手順記述部１１００に返却する。
【００４３】
以上のように、本実施の形態では、非同期イベントのWAITING（待ち）処理を行なう際に、ログフィルタ１２１５が、イベント情報管理器１２１４を参照して非同期イベントを判断することで、ターゲット装置２０００Ｂにおける非同期イベントの発生（非同期イベントの実行ログ）を検知し、非同期イベント待機設定器１２１６に非同期イベントの発生を通知する。なお、ログフィルタ１２１５が、イベント情報管理器１２１４から参照する情報は、ＡＰＩ検証装置１０００Ｂの準備動作にて予め設定しておいた、WAITING（待ち）処理を行うイベント情報である。
【００４４】
これにより、ＡＰＩを実行し戻り値を取得した後、実際の内部処理が行われ、その動作が完了した時点で発生する非同期イベントの受信をもってＡＰＩの目的が達成される、いわゆる非同期イベントの検証を実施することが可能となる。
【００４５】
（実施の形態３）
本発明の実施形態３にかかる検証システムは、図１１に示すように、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ｄと第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとを備える。第一のターゲット装置２０００Ａａは、第一のコマンド受信部２１００ａ、第一のコマンド実行部２２００ａ、第一のコマンド・ＡＰＩ対応管理部２３００ａ、第一のユーザプログラム２４００ａ、第一のログ出力部２５００ａ、第一のログ記述ルール管理部２６００ａ、および第一のログ送信部２７００ａを備える。第二のターゲット装置２０００Ａｂは、第二のコマンド受信部２１００ｂ、第二のコマンド実行部２２００ｂ、第二のコマンド・ＡＰＩ対応管理部２３００ｂ、第二のユーザプログラム２４００ｂ、第二のログ出力部２５００ｂ、第二のログ記述ルール管理部２６００ｂ、および第二のログ送信部２７００ｂを備える。
【００４６】
このように第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとは、ターゲット装置２０００Ａと同様の構成を備える。さらには、ＡＰＩ検証装置１０００Ｄが、テスト手順記述部１１００、仮想ＡＰＩ部１２２０、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える点は、実施の形態１（図１）と同様である。
【００４７】
本実施の形態が実施の形態１（図１）と異なるのは、仮想ＡＰＩ部１２２０に、仮想ＡＰＩ制御器１２１７と、第一のＡＰＩ実行器１２２１ａと、第二のＡＰＩ実行器１２２１ｂと、ＡＰＩ実行完了待機設定部１２２３とを備えることである。但し、第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとは全く同じ機能を有する。
【００４８】
以上のように構成された本実施の形態の検証システムについて、以下に各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ｄのコマンド送信動作と、第一、第二のターゲット装置２０００Ａａ、２０００Ａｂのログ送信動作と、ＡＰＩ検証装置１０００Ｄのログ受信動作とを含む。
【００４９】
（ＡＰＩ検証装置１０００Ｄのコマンド送信動作）
第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとにはそれぞれテスト手順が記述されている。テスト手順には、ＡＰＩに渡す引数に値を代入する手順やＡＰＩを呼び出す順序が記載されている。検証が開始されると第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとは、テスト手順を、仮想ＡＰＩ制御器１２１７に出力する。第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとに記述されているテスト手順には、各々のテストを識別するための識別情報（以下、スクリプト識別情報という）が記述されている。
【００５０】
仮想ＡＰＩ制御器１２１７は、第一のＡＰＩ実行器１２２１ａあるいは第二のＡＰＩ実行器１２２１ｂにＡＰＩ実行手順を出力する。仮想ＡＰＩ制御器１２１７は、ＡＰＩ実行手順の出力に際して、第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとのうちのどちらにＡＰＩ実行手順を出力するかを選択する。以下、その選択方法について説明する。
【００５１】
まず仮想ＡＰＩ制御器１２１７は、任意に選択した一つのＡＰＩ実行器（例えば第一のＡＰＩ実行器１２２１ａ）にＡＰＩ実行手順を出力可能であるかどうかを判断する。この判断は、選択したＡＰＩ実行器において既に他のテスト手順が実施されている状態であるか否かを確認することで実施される。出力可能であると判断する場合、仮想ＡＰＩ制御器１２１７は、出力可能と判断した方のＡＰＩ実行器（例えば第一のＡＰＩ実行器１２２１ａ）にＡＰＩ実行手順を出力する。出力不可能であると判断する場合、仮想ＡＰＩ制御器１２１７は、出力不可能と判断した方とは異なる他方のＡＰＩ実行器（例えば第二のＡＰＩ実行器１２２１ｂ）にＡＰＩ実行手順を出力する。以下、ＡＰＩ実行手順が出力されるＡＰＩ実行器に、便宜的に符号１２２１ｘを付す。
【００５２】
なお、仮想ＡＰＩ制御器１２１７は、ＡＰＩ実行手順を出力する際には、ＡＰＩ実行手順を送信するターゲット装置を識別する識別情報（以下、ターゲット装置識別情報という）をＡＰＩ実行手順に付加する。ターゲット装置の識別情報とは、例えばＩＰアドレスやＭＡＣアドレスを示すが、それらに限定されるものではないのはいうまでもない。
【００５３】
ＡＰＩ実行手順を受け取ったＡＰＩ実行器１２２１ｘは、スクリプト実行部１３００にＡＰＩ実行手順を出力する。この時、ＡＰＩ実行器１２２１ｘはスクリプト記述情報に基づいて、実行しているスクリプトを特定する情報を作成して保持しておく。スクリプト実行部１３００は、受け取ったＡＰＩ実行手順を解釈することでコマンド（ＡＰＩ名と引数との構造）に変換してコマンド送信部１４００に出力する。スクリプト実行部１３００は、作成するコマンドに、ターゲット装置識別情報やスクリプトの記述情報を更に付与する。ターゲット装置識別情報は、前述したように仮想ＡＰＩ制御器１２１７によってＡＰＩ実行手順に付加されている。
【００５４】
コマンド送信部１４００は、ＡＰＩ実行手順に付加されたターゲット装置識別情報に基づいて、コマンド（ＡＰＩ実行手順）をターゲット装置２０００Ａｘに送信する。ここで、ターゲット装置２０００Ａｘは、第一のターゲット装置２０００Ａａ、または第二のターゲット装置２０００Ａｂ、または両ターゲット装置２０００Ａａ、２０００Ａｂとなる。
【００５５】
（第一、第二のターゲット装置２０００Ａａ、２０００Ａｂのコマンド受信/ログ送信動作）
第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとは全く同機能を有し、同じ動作をするため、第一のターゲット装置２０００Ａａを代表してその動作の説明を行なう。
【００５６】
第一のコマンド受信部２１００ａは、コマンドを受信するとそのコマンドを第一のコマンド実行部２２２０ａに出力する。第一のコマンド実行部２２２０ａは、第一のコマンド・ＡＰＩ対応管理部２３００ａを参照することで、受信したコマンドをコマンドそのものとＡＰＩ引き数とに変換する。第一のコマンド実行部２２２０ａは、変換により得られるコマンドとＡＰＩ引き数とに基づいて第一のユーザプログラム２４００ａ上のＡＰＩを実行する。
【００５７】
第一のコマンド実行部２２２０ａは、第一のユーザプログラム２４００ａ上のＡＰＩを実行することで、実行しているスクリプトを特定する情報（以下、スクリプト識別情報という）と、実行しているターゲットを特定する情報（以下、ターゲット識別情報という）と、ＡＰＩを実行した結果得られる戻り値とを取得し、それらを第一のログ出力部２５００ａに出力する。
【００５８】
第一のログ出力部２５００ａは、ＡＰＩ実行の結果得られる戻り値とスクリプト識別情報とターゲット識別情報とを第一のログ送信部２７００ａに出力する。戻り値とスクリプト識別情報とターゲット識別情報とは、第一のログ記述ルール管理部２６００ａの指示に従ってＡＰＩを実行した結果のログ（実行結果ログ）である。第一のログ送信部２７００ａは、受け取った実行結果ログを、第一のログ出力部２５００ａからＡＰＩ検証装置１０００Ｄのログ受信部１５００に送信する。
【００５９】
（ＡＰＩ検証装置１０００Ｄのログ受信動作）
ログ受信部１５００は、受信した実行結果ログを仮想ＡＰＩ部１２２０のログフィルタ１２０５に出力する。ログフィルタ１２０５は、受信した実行結果ログを、イベント情報管理器１２０４を参照して調べることで、ＡＰＩ実行完了待機状態のイベントを示すログが受信ログ内にあるか否かを判断する。ＡＰＩ実行完了待機状態のイベントを示すログが受信ログ内にあると判断するとログフィルタ１２０５は、ＡＰＩ実行完了待機状態のイベントに対応する戻り値パラメータをパラメータ記憶器１２０２に設定した後、ＡＰＩ実行完了待機設定器１２２３にスクリプト識別情報とターゲット識別情報とを通知する。ＡＰＩ実行完了待機設定器１２２３は、通知を受けたスクリプト識別情報とターゲット識別情報とを第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとに出力する。第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとは、スクリプト識別情報を解釈して、そのスクリプトが現在実行しているスクリプトであると判断すれば、パラメータ記憶器１２０２から上記戻り値パラメータを取得して、その戻り値パラメータを仮想ＡＰＩ制御器１２１７に返却する。戻り値パラメータの返却を受けた仮想ＡＰＩ制御器１２１７は、スクリプト識別情報に基づいて第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとのうちの一つを特定したうえで、特定したテスト手順記述部に戻り値を返却する。但し、同じスクリプトを別のターゲット上でも実行している場合はもう一方のターゲット上でのＡＰＩの実行完了を待つ。
【００６０】
以上説明したように、本実施の形態によれば複数のテスト手順を実行することが可能となる。なお、本実施の形態によれば一つ以上のテスト手順を実行する場合に、仮想ＡＰＩ制御器１２１７からコマンド送信先を指定することで複数のターゲット装置を同時にＡＰＩ単位で制御することが可能となる。
【産業上の利用可能性】
【００６１】
以上のように、本発明にかかるＡＰＩ検証装置は、テストスクリプトからユーザシステム上に実装されたソフトウェアをＡＰＩ単位で制御することが可能となる、という効果を有し、ＡＰＩ検証装置やターゲット側のシステムと組み合わせた、ＡＰＩ検証システムとして有用である。
【符号の説明】
【００６２】
１０００Ａ  ＡＰＩ検証装置
２０００Ａ  ターゲット装置
２０００Ａａ  第一のターゲット装置
２０００Ａｂ  第二のターゲット装置
１１００    テスト手順記述部
１１００ａ  第一のテスト手順記述部
１１００ｂ  第二のテスト手順記述部
１２００    仮想ＡＰＩ部
１２０１    ＡＰＩ実行器
１２０１ａ  第一のＡＰＩ実行器
１２０１ｂ  第二のＡＰＩ実行器
１２０２    パラメータ記憶器
１２０３    ＡＰＩ実行完了待機設定器
１２０４    イベント情報管理器
１２０５    ログフィルタ
１２１７    仮想ＡＰＩ制御器
１２２１ａ    第一のＡＰＩ実行器
１２２１ｂ    第二のＡＰＩ実行器
１３００    スクリプト実行部
１４００    コマンド送信部
１５００    ログ受信部
１５１０    第二のログ受信部
１８００    テスト結果判定部
２１００    コマンド受信部
２１００ａ  第一のコマンド受信部
２１００ｂ  第二のコマンド受信部
２２００    コマンド実行部
２２００ａ  第一のコマンド実行部
２２００ｂ  第二のコマンド実行部
２３００    コマンド・ＡＰＩ対応管理部
２３００ａ  第一のコマンド・ＡＰＩ対応管理部
２３００ｂ  第二のコマンド・ＡＰＩ対応管理部
２４００    ユーザプログラム
２４００ａ  第一のユーザプログラム
２４００ｂ  第二のユーザプログラム
２５００    ログ出力部
２５００ａ  第一のログ出力部
２５００ｂ  第二のログ出力部
２６００    ログ記述ルール管理部
２６００ａ  第一のログ記述ルール管理部
２６００ｂ  第二のログ記述ルール管理部
２６１０    ログ記述ルール管理部
２７００    ログ送信部
２７００ａ  第一のログ送信部
２７００ｂ  第二のログ送信部
２７１０    第二のログ送信部
２８００    ログフィルタ
２９００    ログ蓄積部
【図１】
2009150788.tif 000003
【図２】
2009150788.tif 000004
【図３】
2009150788.tif 000005
【図４】
2009150788.tif 000006
【図５】
2009150788.tif 000007
【図６】
2009150788.tif 000008
【図７】
2009150788.tif 000009
【図８】
2009150788.tif 000010
【図９】
2009150788.tif 000011
【図１０】
2009150788.tif 000012
【図１１】
2009150788.tif 000013
【図１２】
2009150788.tif 000014
【手続補正書】
【提出日】平成22年11月12日(2010.11.12)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置を評価する技術に関し、特にマイクロコンピュータが組み込まれた装置を評価する技術に関する。
【背景技術】
【０００２】
近年家電機器の商品サイクルの短期化から開発期間の短縮化が要求されるようになり、その結果、組み込みソフト開発の検証工数においても効率化が要求されている。検証工数の効率化のために、マイクロコンピュータのユーザプログラムを自動で評価する検証システムが研究されている。（例えば、特許文献１参照）。
【０００３】
図１２を参照して従来技術について説明する。この従来技術の検証システムは、ホストコンピュータ２と、ユーザシステム１（以降、ターゲットシステムまたはターゲット装置とも呼ぶ）とに、以下の構成を備える。すなわち、ホストコンピュータ２上の検証装置はコマンド制御部１２１と通信制御部１２４とを備える。コマンド制御部１２１は評価結果比較部１２３とコマンド実行部１２２とを備える。ユーザシステム１上には、通信制御部１０２（データ受信部１０３とデータ送信部１０４とからなる）と、コマンド判定部１０５と、ユーザメモリ１０８と、同期コマンド処理部１０６と、非同期コマンド処理部１０７とを備える。
【０００４】
上記従来の検証システムでは、ホストコンピュータ２上の検証装置のコマンド制御部１２１からユーザシステム１上のリアルタイムＯＳの機能を操作するコマンドを出力することによって、ユーザプログラムを制御して検証を行なう。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１８９６１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来の検証システムでは、リアルタイムＯＳ上の機能を使用してユーザプログラムを制御するため、ユーザプログラムをタスク単位でしか制御することができない。そのため、種々のテスト項目において、ＡＰＩ界面でテストすることができない。なお、ＡＰＩとは、Application Program Interfaceのことであって、ＯＳやミドルウェア等のプラットフォームに対応するソフトウェアを開発する際に使用可能な命令/関数やそれら命令/関数を利用するためのプログラム上の手続きを定めた規約の集合等からなるインターフェースを示す。
【課題を解決するための手段】
【０００７】
本発明のＡＰＩ検証システムは、
ＡＰＩ(Application Program Interface)を実行可能なターゲット装置と、前記ターゲット装置に相互通信可能に接続されたＡＰＩ検証装置とを備え、
前記ＡＰＩ検証装置は、
前記ＡＰＩのテスト手順が記述されたテスト手順記述部と、
前記ターゲット装置におけるＡＰＩインターフェースを前記テスト手順記述部に提供したうえで当該テスト手順記述部から前記テスト手順を取り出し、取り出した当該テスト手順で前記ＡＰＩを呼び出すコマンドを発行する仮想ＡＰＩ部と、
前記コマンドのスクリプト解釈を行なうスクリプト実行部と、
前記スクリプト実行部でスクリプト解釈された前記コマンドを前記ターゲット装置に送信するコマンド送信部と、
前記コマンドに基づいて前記ＡＰＩを実行する前記ターゲット装置から前記ＡＰＩの実行結果ログを受信するログ受信部と、
を備え、
前記仮想ＡＰＩ部は、前記ログ受信部が受信する前記実行結果ログから前記ＡＰＩを実行することで得られる戻り値を取得し、
前記仮想ＡＰＩ部は、前記ターゲット装置上で実行される前記ＡＰＩと同種のインターフェースを有しており、
かつ前記仮想ＡＰＩ部は、
前記ターゲット装置で前記ＡＰＩを実行させるトリガを出力するＡＰＩ実行器と、
前記ＡＰＩに渡すパラメータを記憶するパラメータ記憶器と、
前記ターゲット装置が前記ＡＰＩの実行を完了するタイミングを検出するＡＰＩ実行完了待機設定器と、
前記ターゲット装置で実行される前記ＡＰＩにおける実行完了イベントを管理するイベント情報管理器と、
前記実行結果ログから、前記戻り値を示す情報と、ＡＰＩ実行完了を示す情報と、イベント情報に関するログとを抽出するログフィルタと、
を備え、
前記ターゲット装置は、
前記ＡＰＩ検証装置が送信する前記コマンドを受信するコマンド受信部と、
前記コマンドと前記ＡＰＩとを互いに対応させて記憶するコマンド・ＡＰＩ対応管理部と、
前記コマンド受信部で受信する前記コマンドに対応付けられた前記ＡＰＩを前記コマンド・ＡＰＩ対応管理部において特定したうえで、特定した前記ＡＰＩを実行するコマンド実行部と、
前記ＡＰＩが提供する機能が実装されたユーザプログラムと、
前記コマンド実行部で前記ＡＰＩが実行されることで得られる戻り値と返却引数の値とを含む前記実行結果ログを作成するログ出力部と、
前記実行結果ログの出力方法を定義するログ記述ルール管理部と、
前記ログ記述ルール管理部で定義された前記出力方法に基づいて前記実行結果ログを前記ＡＰＩ検証装置に送信するログ送信部と、
を備える。
【０００８】
かかる構成により、ターゲット装置上のユーザプログラムをＡＰＩ単位で制御し、ターゲット装置上で出力したログからテスト結果を判定することを可能となる。
【０００９】
本発明のＡＰＩ検証システムは、
前記ＡＰＩの実行後に任意のタイミングで発生する、非同期イベントを受信するイベント受信部をさらに備え、
前記ログ記述ルール管理部は、前記非同期イベントに関するログの出力方法を定義し、
前記イベント受信部は、前記非同期イベントの受信を前記ログ出力部に通知し、
前記ログ出力部は、前記非同期イベントを検証する際には、前記ログ記述ルール管理部から読み出した前記非同期イベントに関するログ記述ルールを含む実行結果ログを生成し、
前記仮想ＡＰＩ部は、
前記ターゲット装置で前記非同期イベントが発生するタイミングを検出する非同期イベント待機設定器をさらに備え、
前記イベント情報管理器は、前記非同期イベントの情報をさらに管理し、
前記ログフィルタは、前記イベント情報管理器で管理している前記非同期イベントの情報に基づいて、前記実行結果ログから前記非同期イベントに関するログを抽出する、
のが好ましい。
【００１０】
かかる構成により、前記発明に加え、ＡＰＩ検証システム上で非同期イベントに対応する制御も可能となる。
【００１１】
本発明のＡＰＩ検証システムは、
前記テスト手順記述部は、
第一のテスト手順が記述された第一のテスト手順記述部と、
第二のテスト手順が記述された第二のテスト手順記述部と、
を備え、
前記仮想ＡＰＩ部は、
前記第一のテスト手順記述部から読出した前記第一のテスト記述と前記第二のテスト手順記述部から読出した前記第二のテスト記述とに、これらのテスト手順を個別に識別する識別子を付与したうえで、識別子付与後の両テスト手順を、前記ＡＰＩ実行器における両テスト手順の実施状態に応じて前記ＡＰＩ実行器に順次出力する仮想ＡＰＩ制御器を、
さらに備え、
前記ＡＰＩ実行器は、
前記第一のテスト手順に記載されたＡＰＩ実行手順を実施する第一のＡＰＩ実行器と、
前記第二のテスト手順に記載されたＡＰＩ実行手順を実施する第二のＡＰＩ実行器と、
をさらに備え、
前記ＡＰＩ実行完了待機設定器は、前記第一のＡＰＩ実行器と、前記第二のＡＰＩ実行器とにＡＰＩ実行完了通知を行ない、
前記コマンド実行部は、前記コマンドから前記識別子に基づいて前記第一、第二のテスト手順のどちらが実行されているのかを判別したうえでその判別結果を前記ログ出力部に出力し、
前記ログ出力部は、前記判別結果に基づいて前記第一のテスト手順と前記第二のテスト手順とのうちのどちらを実施しているかを示すログを含んだ前記実行結果ログを出力する、
のが好ましい。
【００１２】
かかる構成により、複数のテスト手順を同時に実行することが可能となる。なお、同構成により、テスト手順を複数のターゲット上で実行することも可能となる。
【発明の効果】
【００１３】
本発明のＡＰＩ検証装置によれば、テストスクリプトからユーザシステム上に実装されたソフトウェアをＡＰＩ単位で制御することが可能となる。これにより、テスト実行時のシステムの状態をＡＰＩ呼び出しにより取得したうえで、取得した状態に応じて関連するソフトウェアを制御することができる。そのため、常に同じテスト条件を作り出すことができる。その結果、デバイスドライバなどの下位層のソフトウェアを、ＡＰＩの界面でテストすることが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施の形態１における検証システム全体を示す構成図である。
【図２】実施の形態１におけるパラメータ記憶器に登録するデータ構造である。
【図３】実施の形態１におけるイベント情報である。
【図４】実施の形態１におけるコマンド構造を示す図である。
【図５】実施の形態１におけるコマンド・ＡＰＩ対応を表す図である。
【図６】実施の形態１におけるログ記述ルールである。
【図７】実施の形態１における検証システム全体を示す構成図である。
【図８】実施の形態１における検証システム全体を示す構成図である。
【図９】実施の形態１における実行ログ記述ルールである。
【図１０】本発明の実施の形態２における検証システム全体を示す構成図である。
【図１１】本発明の実施の形態３における検証システム全体を示す構成図である。
【図１２】従来例における検証システム全体を示す構成図である。
【発明を実施するための形態】
【００１５】
以下、本発明のＡＰＩ検証装置等の実施形態について図面を参照して説明する。なお、実施の形態において同じ符号を付した構成要素は同様の動を行うので、再度の説明を省略する場合がある。
【００１６】
（実施の形態１）
図１は、本発明の実施の形態１におけるＡＰＩ検証装置のブロック図である。本実施形態にかかる検証システムは、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ａとターゲット装置２０００Ａとを備える。ＡＰＩ検証装置１０００Ａは、テスト手順記述部１１００、仮想ＡＰＩ部１２００、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える。仮想ＡＰＩ部１２００は、ＡＰＩ実行器１２０１、パラメータ記憶器１２０２、ＡＰＩ実行完了待機設定器１２０３、イベント情報管理器１２０４、ログフィルタ１２０５、およびテスト結果判定部１６００を備える。ターゲット装置２０００Ａは、コマンド受信部２１００、コマンド実行部２２００、コマンド・ＡＰＩ対応管理部２３００、ユーザプログラム２４００、ログ出力部２５００、ログ記述ルール管理部２６００、およびログ送信部２７００を備える。
【００１７】
以下、実際に検証を行なう際の流れを説明するとともに各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ａのコマンド送信動作と、ターゲット装置２０００Ａのログ送信動作と、ＡＰＩ検証装置１０００Ａのログ受信動作とを含む。
【００１８】
（ＡＰＩ検証装置１０００Ａのコマンド送信動作）
テスト手順記述部１１００にはテスト実行手順が記述されている。テスト実行手順は、ＡＰＩに渡す引数の値の代入手順やＡＰＩの呼び出し順序が記載されたものである。以降、テスト実行手順をＡＰＩの実行単位に区切ったものをＡＰＩの実行手順と呼ぶ。検証が開始されるとテスト手順記述部１１００は、テスト手順をＡＰＩ実行器１２０１に出力する。テスト手順を受け取ったＡＰＩ実行器１２０１は、引数や戻り値を設定する変数の情報をパラメータ記憶器１２０２に登録するとともに、ＡＰＩの実行が完了するまで待機する旨のＡＰＩの実行登録をＡＰＩ実行完了待機設定器１２０３に行なう。その後、ＡＰＩ実行器１２０１は、ＡＰＩ実行手順をスクリプト実行部１３００に出力する。
【００１９】
ここでパラメータ記憶器１２０２に登録・記憶されるパラメータ詳細内容について説明する。パラメータ詳細内容とは、引数や戻り値を設定する変数の情報のことである。図２はパラメータ記憶器１２０２に登録・記憶されるパラメータ詳細内容を示す図である。パラメータ記憶器１２０２には、パラメータ詳細内容として、ＡＰＩ名と、そのＡＰＩに渡される引数および戻り値とが互いに関連付けられた状態で格納される。したがって、パラメータの詳細内容を参照すれば、登録されているＡＰＩ名から引数と戻り値とを特定できる。引数と戻り値とには、ＡＰＩを呼び出す際においてＡＰＩに入力されるパラメータの値のみが設定される。そのうえで、引数と戻り値とには、ＡＰＩの呼び出しが完了した後において出力パラメータが設定される。なお、出力パラメータの設定はログフィルタ１２０５より行なわれる。
【００２０】
ＡＰＩ実行完了待機設定器１２０３は、ＡＰＩ完了イベントをイベント情報管理器１２０４に登録する。具体的にはＡＰＩ実行完了待機設定器１２０３は、ＡＰＩ完了イベントとして“WAITING情報”をイベント情報管理器１２０４に登録する。イベント情報管理器１２０４は、“WAITING情報”に基づいて、登録された情報（ＡＰＩやそのパラメータ詳細内容）がログフィルタ１２０５にイベントとして通知されるまで、”WAITING”(待ち)を行なう。ここで言う”WAITING”とは、例えば無限ループや定期的にイベントを確認するポーリング処理などを示すが、それらに限定されるものではないのはいうまでもない。
【００２１】
イベント情報管理器１２０４は、ＡＰＩの完了イベントとＡＰＩとを関連付けてなるイベント情報を保持する。図３はイベント情報管理器１２０４が保持するイベント情報の例を示す。図３の例では、文字列でイベント名を表しており、仮想ＡＰＩ部１２００は、イベント情報管理器１２０４が保持するイベント情報を検出するか否かに基づいて、処理がＡＰＩの呼び出しから復帰してきたか否かを判断する。パラメータ記憶器１２０２は、ＡＰＩ実行器１２０１によって登録処理される引数や戻り値といったパラメータ詳細情報を保持する。
【００２２】
スクリプト実行部１３００はＡＰＩ実行器１２０１から送られてきたＡＰＩ実行手順を解釈することでそれを図４に示すコマンドの構造（以下、単にコマンドと称す）に変換する。スクリプト実行部１３００は、コマンド（ＡＰＩ実行手順）をコマンド送信部１４００に出力する。コマンド送信部１４００は、スクリプト実行部１３００から受け取ったコマンドを送信順序に従ってターゲット装置２０００Ａに送信する。
【００２３】
ここで、コマンド送信部１４００によって送信されるコマンドの説明を行なう。図４に示すようにコマンドは文字列によって表されており、先頭の「ＡＰＩＮＡＭＥ」という文字列によって表わされるＡＰＩとその引数とが順次配置されている。コマンドは、その配置順に沿ってコマンド送信部１４００からターゲット装置２０００Ａに送信される。
【００２４】
（ターゲット装置２０００Ａのコマンド受信/ログ送信動作）
コマンド受信部２１００は、ＡＰＩ検証装置１０００Ａから送信されるコマンドを受信し、コマンド実行部２２００に渡す。コマンド実行部２２００は、コマンド・ＡＰＩ対応管理部２３００に格納されているコマンドとＡＰＩとの対応付けを参照することで、受信したコマンドに対応するＡＰＩをユーザプログラム２４００から読み出して実行する。以下、さらに詳細に説明する。
【００２５】
コマンド・ＡＰＩ対応管理部２３００は、図５に示すように、ＡＰＩ名と、そのＡＰＩがユーザプログラム２４００のメモリ（以下、単にメモリという）上に配置されているアドレスとを対応付けて保持している。コマンド実行部２２００は、コマンド内のＡＰＩ名（図例では「ＡＰＩＮＡＭＥ_Ｘ」（Ｘ：通し番号）からなる文字列）を、コマンド・ＡＰＩ対応管理部２３００に参照することで、そのＡＰＩが配置されているメモリ上の先頭アドレス（以下、ＡＰＩ先頭アドレスという）を特定する。さらにコマンド・ＡＰＩ対応管理部２３００は、特定したＡＰＩ先頭アドレスに存在するＡＰＩを実行する。更にコマンド実行部２２００は、ＡＰＩ実行した結果（引数・戻り値）をユーザプログラム２４００から取得して、ログ出力部２５００に渡す。ログ出力部２５００は、ログ記述ルール管理部２６００に設けられた管理情報（以下、ログ記述ルールという）を元に受け取ったＡＰＩ実行結果を示すログ（以下、ＡＰＩ実行結果ログと呼ぶ）を作成し、作成したＡＰＩ実行結果ログをログ送信部２７００に出力する。
【００２６】
ログ記述ルール管理部２６００が管理するログ記述ルールの構造について図６を参照して説明する。図６は、ユーザプログラム２４００上のＡＰＩを呼び出した場合のログ記述ルールの例を示す。この例では、先頭に「ＥＶＴ＿ＡＰＩＲＥＴ：」という文字列が、その後に「ＲＥＴＶＡＬ」の部分が、さらにその後に「ＡＲＧＶＡＬ１」、「ＡＲＧＶＡＬ２」の部分が設けられている。なお、ここでいう前後とは、データ送信順序に沿った位置関係をいう。
【００２７】
「ＥＶＴ＿ＡＰＩＲＥＴ：」は、ＡＰＩを呼び出す際のログ記述ルールであることを示す。「ＲＥＴＶＡＬ」の部分には、ＡＰＩを呼び出す際に返却された戻り値がログとして付加される。「ＡＲＧＶＡＬ１」、「ＡＲＧＶＡＬ２」の部分には、ＡＰＩの引数として出力されるパラメータのログが付加される。
【００２８】
ログ出力部２５００による出力動作に戻って説明を行う。ログ出力部２５００は、テスト結果を判定するためのログ（以下、テスト結果を判定するためのログという）を、ログ記述ルールで記述されたＡＰＩ実行結果ログとともにログ送信部２７００に出力する。テスト結果を判定するためのログは、例えばＡＰＩに渡した引数・戻り値の情報やＡＰＩの内部の処理経路を表すログのことを示し、その先頭には、テスト結果を判定するためのログであることを表すヘッダが付加される。このヘッダの一例が図９に示す「＜ＥＸＬＯＧ＞」である。以降、ＡＰＩ実行結果ログとテスト結果を判定するためのログとを合わせて実行結果ログという。ログ送信部２７００は、実行結果ログをＡＰＩ検証装置１０００Ａのログ受信部１５００に送信する。
【００２９】
（ＡＰＩ検証装置１０００Ａのログ受信動作）
ログ受信部１５００は、ターゲット装置２０００Ａから受信した実行結果ログをログフィルタ１２０５に出力する。ログフィルタ１２０５は、実行結果ログを受け取ると、イベント情報管理器１２０４から“WAITING情報”を取得する。“WAITING情報”とは、前述した通り、待ちＡＰＩ実行完了待機設定器１２０３がWAITING（待ち）を行なっているＡＰＩ（イベント）に関する情報である。ログフィルタ１２０５は、実行結果ログを“WAITING情報”に基づいて解析することで、実行結果ログの中に、WAITING（待ち）を行なっているＡＰＩの実行結果が含まれるか否かを判断する。含まれると判断する場合、ログフィルタ１２０５は、WAITING（待ち）を行なっているＡＰＩの実行が完了したと判断してそのことをＡＰＩ実行完了待機設定器１２０３に通知する。ＡＰＩ実行完了待機設定器１２０３は、受け取った通知（ＡＰＩ完了通知）に基づいて、実行が完了したＡＰＩのWAITING（待ち）を解除する。さらにログフィルタ１２０５は、実行結果ログから、処理が完了したＡＰＩのＡＰＩ実行結果ログを抽出する。このログは前述したように引数や戻り値の情報である。ログフィルタ１２０５は、抽出したＡＰＩ実行結果ログをパラメータ記憶器１２０２に登録されている変数の情報に照合させることでその値（引数・戻り値）を設定する。ログフィルタ１２０５は、設定したＡＰＩ実行結果ログの値（引数・戻り値）をログフィルタ１２０５を介してＡＰＩ実行完了待機設定器１２０３に出力する。
【００３０】
さらにログフィルタ１２０５は、実行結果ログから、テスト結果を判定するためのログを抽出し、抽出したテスト結果を判定するためのログをテスト結果判定部１６００に出力する。テスト結果判定部１６００はテスト結果を判定するためのログを解析することで、実行が完了したＡＰＩが正しく実行されたか否かを判定する。
【００３１】
ＡＰＩ実行完了待機設定器１２０３は、WAITING（待ち）を解除したタイミングでＡＰＩ実行結果ログの値（引数・戻り値）をＡＰＩ実行器１２０１を介してテスト手順記述部１１００に出力する。テスト手順記述部１１００は、取得したＡＰＩ実行結果ログの値（引数・戻り値）に基づいて次のＡＰＩの呼び出しを実施する。
【００３２】
以上説明したように、本実施の形態によれば仮想ＡＰＩ部１２００がターゲット装置２０００Ａと同期してＡＰＩの呼び出しコマンドの送信や、決まった形式で出力された実行結果ログを解析してその引数・戻り値を設定したうえで、設定した引数・戻り値をテスト手順記述部１１００に返却する。これにより、テスト手順記述部１１００上では、仮想ＡＰＩ部１２００が提供するユーザプログラムと同じインターフェースを用いて、ターゲット側ＡＰＩの実行を制御することが可能となる。これにより本実施の形態では、ターゲット装置２０００Ａ上で出力された実行結果ログに基づいてテスト結果判定部１６００がテスト結果を自動的に判定することが可能となる。
【００３３】
なお、本実施の形態では、図７に示すように、ターゲット装置２０００Ｆにログ蓄積部２９００とログフィルタ２８００とを設けてもよい。この構成では、テスト結果を判定するためのログを一旦ターゲット装置２０００Ｆのログ蓄積部２９００で蓄積したうえで、テスト手順が一通り実施されたタイミングでテスト結果を判定するためのログをターゲット装置２０００Ｆのログ送信部２７００からＡＰＩ検証装置１０００Ｆに送信する。ＡＰＩ検証装置１０００Ｆでは、受信したテスト結果を判定するためのログをログ受信部１５００とログフィルタ１２１５とを介してテスト結果判定部１６００に出力する。これによれば、テスト結果を判定するためのログの伝送に起因してＡＰＩの実行が遅延することが防止される。
【００３４】
さらに、本実施の形態では、図８に示すように、ターゲット装置２０００Ｇにログフィルタ２８００と第二のログ送信部２７１０とをさらに設け、ＡＰＩ検証装置１０００Ｇに第二のログ受信部１５１０をさらに設けてもよい。この構成では、ターゲット装置２０００Ｇのログフィルタ２８００が、ＡＰＩ実行結果ログからテスト結果を判定するためのログを抽出したうえで、抽出したテスト結果を判定するためのログを、ログフィルタ２８００が第二のログ送信部２７１０を介してＡＰＩ検証装置１０００Ｇに送信する。ＡＰＩ検証装置１０００Ｇでは、第二のログ受信部１５１０でテスト結果を判定するためのログを受信したうえで、第二のログ受信部１５１０から直接にテスト結果判定部１６００に出力することでテスト結果を判定するためのログの伝送に起因してＡＰＩの実行が遅延することが防止される。
【００３５】
（実施の形態２）
実施の形態２では、非同期イベントを検証するシステムについて説明する。まず、本実施の形態２における、非同期イベントの定義について明らかにする。非同期イベントとは、ＡＰＩ実行をトリガとしてターゲット装置上のハードウェア、ソフトウェアから発生する割り込みイベントのことを示す。例えば、メモリ間のデータ転送開始処理が実装されたＡＰＩの場合、ＡＰＩの呼び出し後、データの転送開始処理自体は確認できるが、データの転送処理自体が実施されたどうかは、実際にハードウェア及び更に下位にあたるプログラムからの応答を受けるまで確認することができない。ここで言う“応答”とは、例えばデータ転送完了通知等を示す。このようなハードウェア及び下位プログラムからの応答のことを非同期イベントと呼ぶ。
【００３６】
図１０は本発明の実施の形態２の構成図である。図１０についても図１と同様に、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ｂとターゲット装置２０００Ｂとを備える。ＡＰＩ検証装置１０００Ｂは、テスト手順記述部１１００、仮想ＡＰＩ部１２１０、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える。仮想ＡＰＩ部１２１０は、ＡＰＩ実行器１２０１、パラメータ記憶器１２０２、ＡＰＩ実行完了待機設定器１２０３、イベント情報管理器１２１４、ログフィルタ１２１５、および非同期イベント待機設定器１２１６を備える。
【００３７】
ターゲット装置２０００Ｂは、コマンド受信部２１００、コマンド実行部２２００、コマンド・ＡＰＩ対応管理部２３００、ユーザプログラム２４００、ログ出力部２５００、ログ記述ルール管理部２６１０、ログ送信部２７００、およびイベント受信部３０００を備える。
【００３８】
本実施の形態が実施の形態１と異なる点は、
・ＡＰＩ検証装置１０００Ｂが非同期イベント待機設定器１２１６を備えること、
・イベント情報管理器１２１４が非同期イベント情報管理機能を備えること、
・ログフィルタ１２１５が非同期イベント抽出機能を備えること、
・ターゲット装置２０００Ｂにイベント受信部３０００を備えること、
である。
【００３９】
以下、本実施の形態において、非同期イベントのWAITING(待ち）処理を実施する際における各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ｂの準備動作と、ターゲット装置２０００Ｂのログ送信動作と、ＡＰＩ検証装置１０００Ｂのログ受信動作とを含む。
【００４０】
（ＡＰＩ検証装置１０００Ｂの準備動作）
非同期イベントのWAITING(待ち)処理を行なう場合、テスト手順記述部１１００は、非同期イベント待機設定器１２１６に、非同期イベントのWAITING(待ち)処理を行なう際の手順を示す情報を出力する。非同期イベント待機設定器１２１６は、イベント情報管理器１２１４に、WAITING(待ち)処理を行なうイベント情報を登録する。なお、非同期イベントのWAITING(待ち)処理を行なう手順とは、非同期イベント待機設定器１２１６によって待機開始が設定されたうえで待機が終了する（返却される）までの間の一連の処理手順のことを示す。
【００４１】
（ターゲット装置２０００Ｂのログ送信動作）
ＡＰＩ検証装置１０００Ｂの準備動作が完了した後、テスト手順記述部１１００からのＡＰＩの実行などをトリガとして、ターゲット装置２０００Ｂの上のシステムで非同期イベントが発生すると、イベント受信部３０００は、ユーザプログラム２４００から、非同期イベントが発生した際に通知されるパラメータを受信し、ログ出力部２５００に出力する。ログ出力部２５００はログ記述ルール管理部２６１０から非同期イベントのログ記述ルールを参照して非同期イベントの実行結果ログを作成する。ログ出力部２５００は、作成した非同期イベントの実行結果ログをログ送信部２７００に出力する。ログ送信部２７００は、受け取った非同期イベントの実行結果ログをＡＰＩ検証装置１０００Ｂのログ受信部１５００に送信する。
【００４２】
（ＡＰＩ検証装置１０００Ｂのログ受信動作）
ログ受信部１５００は、ログ送信部２７００から受け取った非同期イベントの実行結果ログをログフィルタ１２１５に出力する。ログフィルタ１２１５は、受け取った非同期イベントの実行結果ログを解析する。この解析において、イベント情報管理器１２１４に登録されている非同期イベントを検出すると、ログフィルタ１２１５は、非同期イベントログに含まれるパラメータをパラメータ記憶器１２０２に設定し、さらに、非同期イベントを検出したことを非同期イベント待機設定器１２１６に通知する。
【００４３】
非同期イベント待機設定器１２１６は、非同期イベント検出通知を受け取ると、パラメータ記憶器１２０２から非同期イベントにより返却される変数を呼び出し、呼び出した変数に非同期イベント時に返却された値を設定して、テスト手順記述部１１００に返却する。
【００４４】
以上のように、本実施の形態では、非同期イベントのWAITING（待ち）処理を行なう際に、ログフィルタ１２１５が、イベント情報管理器１２１４を参照して非同期イベントを判断することで、ターゲット装置２０００Ｂにおける非同期イベントの発生（非同期イベントの実行ログ）を検知し、非同期イベント待機設定器１２１６に非同期イベントの発生を通知する。なお、ログフィルタ１２１５が、イベント情報管理器１２１４から参照する情報は、ＡＰＩ検証装置１０００Ｂの準備動作にて予め設定しておいた、WAITING（待ち）処理を行うイベント情報である。
【００４５】
これにより、ＡＰＩを実行し戻り値を取得した後、実際の内部処理が行われ、その動作が完了した時点で発生する非同期イベントの受信をもってＡＰＩの目的が達成される、いわゆる非同期イベントの検証を実施することが可能となる。
【００４６】
（実施の形態３）
本発明の実施形態３にかかる検証システムは、図１１に示すように、ホストＰＣ上で動作するＡＰＩ検証装置１０００Ｄと第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとを備える。第一のターゲット装置２０００Ａａは、第一のコマンド受信部２１００ａ、第一のコマンド実行部２２００ａ、第一のコマンド・ＡＰＩ対応管理部２３００ａ、第一のユーザプログラム２４００ａ、第一のログ出力部２５００ａ、第一のログ記述ルール管理部２６００ａ、および第一のログ送信部２７００ａを備える。第二のターゲット装置２０００Ａｂは、第二のコマンド受信部２１００ｂ、第二のコマンド実行部２２００ｂ、第二のコマンド・ＡＰＩ対応管理部２３００ｂ、第二のユーザプログラム２４００ｂ、第二のログ出力部２５００ｂ、第二のログ記述ルール管理部２６００ｂ、および第二のログ送信部２７００ｂを備える。
【００４７】
このように第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとは、ターゲット装置２０００Ａと同様の構成を備える。さらには、ＡＰＩ検証装置１０００Ｄが、テスト手順記述部１１００、仮想ＡＰＩ部１２２０、スクリプト実行部１３００、コマンド送信部１４００、およびログ受信部１５００を備える点は、実施の形態１（図１）と同様である。
【００４８】
本実施の形態が実施の形態１（図１）と異なるのは、仮想ＡＰＩ部１２２０に、仮想ＡＰＩ制御器１２１７と、第一のＡＰＩ実行器１２２１ａと、第二のＡＰＩ実行器１２２１ｂと、ＡＰＩ実行完了待機設定部１２２３とを備えることである。但し、第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとは全く同じ機能を有する。
【００４９】
以上のように構成された本実施の形態の検証システムについて、以下に各部の動作を説明する。検証動作は、ＡＰＩ検証装置１０００Ｄのコマンド送信動作と、第一、第二のターゲット装置２０００Ａａ、２０００Ａｂのログ送信動作と、ＡＰＩ検証装置１０００Ｄのログ受信動作とを含む。
【００５０】
（ＡＰＩ検証装置１０００Ｄのコマンド送信動作）
第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとにはそれぞれテスト手順が記述されている。テスト手順には、ＡＰＩに渡す引数に値を代入する手順やＡＰＩを呼び出す順序が記載されている。検証が開始されると第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとは、テスト手順を、仮想ＡＰＩ制御器１２１７に出力する。第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとに記述されているテスト手順には、各々のテストを識別するための識別情報（以下、スクリプト識別情報という）が記述されている。
【００５１】
仮想ＡＰＩ制御器１２１７は、第一のＡＰＩ実行器１２２１ａあるいは第二のＡＰＩ実行器１２２１ｂにＡＰＩ実行手順を出力する。仮想ＡＰＩ制御器１２１７は、ＡＰＩ実行手順の出力に際して、第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとのうちのどちらにＡＰＩ実行手順を出力するかを選択する。以下、その選択方法について説明する。
【００５２】
まず仮想ＡＰＩ制御器１２１７は、任意に選択した一つのＡＰＩ実行器（例えば第一のＡＰＩ実行器１２２１ａ）にＡＰＩ実行手順を出力可能であるかどうかを判断する。この判断は、選択したＡＰＩ実行器において既に他のテスト手順が実施されている状態であるか否かを確認することで実施される。出力可能であると判断する場合、仮想ＡＰＩ制御器１２１７は、出力可能と判断した方のＡＰＩ実行器（例えば第一のＡＰＩ実行器１２２１ａ）にＡＰＩ実行手順を出力する。出力不可能であると判断する場合、仮想ＡＰＩ制御器１２１７は、出力不可能と判断した方とは異なる他方のＡＰＩ実行器（例えば第二のＡＰＩ実行器１２２１ｂ）にＡＰＩ実行手順を出力する。以下、ＡＰＩ実行手順が出力されるＡＰＩ実行器に、便宜的に符号１２２１ｘを付す。
【００５３】
なお、仮想ＡＰＩ制御器１２１７は、ＡＰＩ実行手順を出力する際には、ＡＰＩ実行手順を送信するターゲット装置を識別する識別情報（以下、ターゲット装置識別情報という）をＡＰＩ実行手順に付加する。ターゲット装置の識別情報とは、例えばＩＰアドレスやＭＡＣアドレスを示すが、それらに限定されるものではないのはいうまでもない。
【００５４】
ＡＰＩ実行手順を受け取ったＡＰＩ実行器１２２１ｘは、スクリプト実行部１３００にＡＰＩ実行手順を出力する。この時、ＡＰＩ実行器１２２１ｘはスクリプト記述情報に基づいて、実行しているスクリプトを特定する情報を作成して保持しておく。スクリプト実行部１３００は、受け取ったＡＰＩ実行手順を解釈することでコマンド（ＡＰＩ名と引数との構造）に変換してコマンド送信部１４００に出力する。スクリプト実行部１３００は、作成するコマンドに、ターゲット装置識別情報やスクリプトの記述情報を更に付与する。ターゲット装置識別情報は、前述したように仮想ＡＰＩ制御器１２１７によってＡＰＩ実行手順に付加されている。
【００５５】
コマンド送信部１４００は、ＡＰＩ実行手順に付加されたターゲット装置識別情報に基づいて、コマンド（ＡＰＩ実行手順）をターゲット装置２０００Ａｘに送信する。ここで、ターゲット装置２０００Ａｘは、第一のターゲット装置２０００Ａａ、または第二のターゲット装置２０００Ａｂ、または両ターゲット装置２０００Ａａ、２０００Ａｂとなる。
【００５６】
（第一、第二のターゲット装置２０００Ａａ、２０００Ａｂのコマンド受信/ログ送信動作）第一のターゲット装置２０００Ａａと第二のターゲット装置２０００Ａｂとは全く同機能を有し、同じ動作をするため、第一のターゲット装置２０００Ａａを代表してその動作の説明を行なう。
【００５７】
第一のコマンド受信部２１００ａは、コマンドを受信するとそのコマンドを第一のコマンド実行部２２２０ａに出力する。第一のコマンド実行部２２２０ａは、第一のコマンド・ＡＰＩ対応管理部２３００ａを参照することで、受信したコマンドをコマンドそのものとＡＰＩ引き数とに変換する。第一のコマンド実行部２２２０ａは、変換により得られるコマンドとＡＰＩ引き数とに基づいて第一のユーザプログラム２４００ａ上のＡＰＩを実行する。
【００５８】
第一のコマンド実行部２２２０ａは、第一のユーザプログラム２４００ａ上のＡＰＩを実行することで、実行しているスクリプトを特定する情報（以下、スクリプト識別情報という）と、実行しているターゲットを特定する情報（以下、ターゲット識別情報という）と、ＡＰＩを実行した結果得られる戻り値とを取得し、それらを第一のログ出力部２５００ａに出力する。
【００５９】
第一のログ出力部２５００ａは、ＡＰＩ実行の結果得られる戻り値とスクリプト識別情報とターゲット識別情報とを第一のログ送信部２７００ａに出力する。戻り値とスクリプト識別情報とターゲット識別情報とは、第一のログ記述ルール管理部２６００ａの指示に従ってＡＰＩを実行した結果のログ（実行結果ログ）である。第一のログ送信部２７００ａは、受け取った実行結果ログを、第一のログ出力部２５００ａからＡＰＩ検証装置１０００Ｄのログ受信部１５００に送信する。
【００６０】
（ＡＰＩ検証装置１０００Ｄのログ受信動作）
ログ受信部１５００は、受信した実行結果ログを仮想ＡＰＩ部１２２０のログフィルタ１２０５に出力する。ログフィルタ１２０５は、受信した実行結果ログを、イベント情報管理器１２０４を参照して調べることで、ＡＰＩ実行完了待機状態のイベントを示すログが受信ログ内にあるか否かを判断する。ＡＰＩ実行完了待機状態のイベントを示すログが受信ログ内にあると判断するとログフィルタ１２０５は、ＡＰＩ実行完了待機状態のイベントに対応する戻り値パラメータをパラメータ記憶器１２０２に設定した後、ＡＰＩ実行完了待機設定器１２２３にスクリプト識別情報とターゲット識別情報とを通知する。ＡＰＩ実行完了待機設定器１２２３は、通知を受けたスクリプト識別情報とターゲット識別情報とを第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとに出力する。第一のＡＰＩ実行器１２２１ａと第二のＡＰＩ実行器１２２１ｂとは、スクリプト識別情報を解釈して、そのスクリプトが現在実行しているスクリプトであると判断すれば、パラメータ記憶器１２０２から上記戻り値パラメータを取得して、その戻り値パラメータを仮想ＡＰＩ制御器１２１７に返却する。戻り値パラメータの返却を受けた仮想ＡＰＩ制御器１２１７は、スクリプト識別情報に基づいて第一のテスト手順記述部１１００ａと第二のテスト手順記述部１１００ｂとのうちの一つを特定したうえで、特定したテスト手順記述部に戻り値を返却する。但し、同じスクリプトを別のターゲット上でも実行している場合はもう一方のターゲット上でのＡＰＩの実行完了を待つ。
【００６１】
以上説明したように、本実施の形態によれば複数のテスト手順を実行することが可能となる。なお、本実施の形態によれば一つ以上のテスト手順を実行する場合に、仮想ＡＰＩ制御器１２１７からコマンド送信先を指定することで複数のターゲット装置を同時にＡＰＩ単位で制御することが可能となる。
【産業上の利用可能性】
【００６２】
以上のように、本発明にかかるＡＰＩ検証装置は、テストスクリプトからユーザシステム上に実装されたソフトウェアをＡＰＩ単位で制御することが可能となる、という効果を有し、ＡＰＩ検証装置やターゲット側のシステムと組み合わせた、ＡＰＩ検証システムとして有用である。
【符号の説明】
【００６３】
１０００Ａ    ＡＰＩ検証装置
２０００Ａ    ターゲット装置
２０００Ａａ  第一のターゲット装置
２０００Ａｂ  第二のターゲット装置
１１００      テスト手順記述部
１１００ａ    第一のテスト手順記述部
１１００ｂ    第二のテスト手順記述部
１２００      仮想ＡＰＩ部
１２０１      ＡＰＩ実行器
１２０１ａ    第一のＡＰＩ実行器
１２０１ｂ    第二のＡＰＩ実行器
１２０２      パラメータ記憶器
１２０３      ＡＰＩ実行完了待機設定器
１２０４      イベント情報管理器
１２０５      ログフィルタ
１２１７      仮想ＡＰＩ制御器
１２２１ａ    第一のＡＰＩ実行器
１２２１ｂ    第二のＡＰＩ実行器
１３００      スクリプト実行部
１４００      コマンド送信部
１５００      ログ受信部
１５１０      第二のログ受信部
１８００      テスト結果判定部
２１００      コマンド受信部
２１００ａ    第一のコマンド受信部
２１００ｂ    第二のコマンド受信部
２２００      コマンド実行部
２２００ａ    第一のコマンド実行部
２２００ｂ    第二のコマンド実行部
２３００      コマンド・ＡＰＩ対応管理部
２３００ａ    第一のコマンド・ＡＰＩ対応管理部
２３００ｂ    第二のコマンド・ＡＰＩ対応管理部
２４００      ユーザプログラム
２４００ａ    第一のユーザプログラム
２４００ｂ    第二のユーザプログラム
２５００      ログ出力部
２５００ａ    第一のログ出力部
２５００ｂ    第二のログ出力部
２６００      ログ記述ルール管理部
２６００ａ    第一のログ記述ルール管理部
２６００ｂ    第二のログ記述ルール管理部
２６１０      ログ記述ルール管理部
２７００      ログ送信部
２７００ａ    第一のログ送信部
２７００ｂ    第二のログ送信部
２７１０      第二のログ送信部
２８００      ログフィルタ
２９００      ログ蓄積部
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＡＰＩ(Application Program Interface)を実行可能なターゲット装置に相互通信可能に接続されたＡＰＩ検証装置であって、
前記ＡＰＩのテスト手順が記述されたテスト手順記述部と、
前記ターゲット装置におけるＡＰＩインターフェースを前記テスト手順記述部に提供したうえで当該テスト手順記述部から前記テスト手順を取り出し、取り出した当該テスト手順で前記ＡＰＩを呼び出すコマンドを発行する仮想ＡＰＩ部と、
前記コマンドのスクリプト解釈を行なうスクリプト実行部と、
前記スクリプト実行部でスクリプト解釈された前記コマンドを前記ターゲット装置に送信するコマンド送信部と、
前記コマンドに基づいて前記ＡＰＩを実行する前記ターゲット装置から前記ＡＰＩの実行結果ログを受信するログ受信部と、
を備え、
前記仮想ＡＰＩ部は、前記ログ受信部が受信する前記実行結果ログから前記ＡＰＩを実行することで得られる戻り値を取得する、
ＡＰＩ検証装置。
【請求項２】
前記仮想ＡＰＩ部は、前記ターゲット装置上で実行される前記ＡＰＩと同種のインターフェースを有しており、
かつ前記仮想ＡＰＩ部は、
前記ターゲット装置で前記ＡＰＩを実行させるトリガを出力するＡＰＩ実行器と、
前記ＡＰＩに渡すパラメータを記憶するパラメータ記憶器と、
前記ターゲット装置が前記ＡＰＩの実行を完了するタイミングを検出するＡＰＩ実行完了待機設定器と、
前記ターゲット装置で実行される前記ＡＰＩにおける実行完了イベントを管理するイベント情報管理器と、
前記実行結果ログから、前記戻り値を示す情報と、ＡＰＩ実行完了を示す情報と、イベント情報に関するログとを抽出するログフィルタと、
を備える、
請求項１のＡＰＩ検証装置。
【請求項３】
請求項２のＡＰＩ検証装置と、前記ターゲット装置とを備え、
前記ターゲット装置は、
前記ＡＰＩ検証装置が送信する前記コマンドを受信するコマンド受信部と、
前記コマンドと前記ＡＰＩとを互いに対応させて記憶するコマンド・ＡＰＩ対応管理部と、
前記コマンド受信部で受信する前記コマンドに対応付けられた前記ＡＰＩを前記コマンド・ＡＰＩ対応管理部において特定したうえで、特定した前記ＡＰＩを実行するコマンド実行部と、
前記ＡＰＩが提供する機能が実装されたユーザプログラムと、
前記コマンド実行部で前記ＡＰＩが実行されることで得られる戻り値と返却引数の値とを含む前記実行結果ログを作成するログ出力部と、
前記実行結果ログの出力方法を定義するログ記述ルール管理部と、
前記ログ記述ルール管理部で定義された前記出力方法に基づいて前記実行結果ログを前記ＡＰＩ検証装置に送信するログ送信部と、
を備える、
検証システム。
【請求項４】
前記ターゲット装置は、
前記ＡＰＩの実行後に任意のタイミングで発生する、非同期イベントを受信するイベント受信部をさらに備え、
前記ログ記述ルール管理部は、前記非同期イベントに関するログの出力方法を定義し、
前記イベント受信部は、前記非同期イベントの受信を前記ログ出力部に通知し、
前記ログ出力部は、前記非同期イベントを検証する際には、前記ログ記述ルール管理部から読み出した前記非同期イベントに関するログ記述ルールを含む実行結果ログを生成し、
前記仮想ＡＰＩ部は、
前記ターゲット装置で前記非同期イベントが発生するタイミングを検出する非同期イベント待機設定器をさらに備え、
前記イベント情報管理器は、前記非同期イベントの情報をさらに管理し、
前記ログフィルタは、前記イベント情報管理器で管理している前記非同期イベントの情報に基づいて、前記実行結果ログから前記非同期イベントに関するログを抽出する、
請求項３の検証システム。
【請求項５】
前記テスト手順記述部は、
第一のテスト手順が記述された第一のテスト手順記述部と、
第二のテスト手順が記述された第二のテスト手順記述部と、
を備え、
前記仮想ＡＰＩ部は、
前記第一のテスト手順記述部から読出した前記第一のテスト手順と前記第二のテスト手順記述部から読出した前記第二のテスト手順とに、これらのテスト手順を個別に識別する識別子を付与したうえで、識別子付与後の両テスト手順を、前記ＡＰＩ実行器における両テスト手順の実施状態に応じて前記ＡＰＩ実行器に順次出力する仮想ＡＰＩ制御器を、
さらに備え、
前記ＡＰＩ実行器は、
前記第一のテスト手順に記載されたＡＰＩ実行手順を実施する第一のＡＰＩ実行器と、
前記第二のテスト手順に記載されたＡＰＩ実行手順を実施する第二のＡＰＩ実行器と、
をさらに備え、
前記ＡＰＩ実行完了待機設定器は、前記第一のＡＰＩ実行器と、前記第二のＡＰＩ実行器とにＡＰＩ実行完了通知を行ない、
前記コマンド実行部は、前記コマンドから前記識別子に基づいて前記第一、第二のテスト手順のどちらが実行されているのかを判別したうえでその判別結果を前記ログ出力部に出力し、
前記ログ出力部は、前記判別結果に基づいて前記第一のテスト手順と前記第二のテスト手順とのうちのどちらを実施しているかを示すログを含んだ前記実行結果ログを出力する、
請求項３のＡＰＩ検証システム。
【請求項６】
前記ターゲット装置は、
第一のターゲット装置と、
第二のターゲット装置と、
を備え、
前記テスト手順記述部に記述された前記テスト手順には、当該テスト手順を実行するターゲット装置を指定する情報がさらに記述されており、
前記ＡＰＩ実行器は、
第一のＡＰＩ実行器と、
第二のＡＰＩ実行器と、
を備え、
前記仮想ＡＰＩ部は、
前記テスト手順で指定されたターゲット装置の識別情報と前記ＡＰＩ実行器とを関連付けたコマンドを前記ＡＰＩ実行器に出力する仮想ＡＰＩ制御器を、
さらに備え、
前記ＡＰＩ実行完了待機設定器は、前記ログフィルタが抽出する前記実行結果ログを、前記第一のＡＰＩ実行器と前記第二のＡＰＩ実行器とに通知する、
請求項３の検証システム。
【請求項７】
前記ログフィルタは、前記実行結果ログから前記ＡＰＩのテスト結果を判定するためのログをさらに抽出し、
前記ＡＰＩ検証装置は、
前記テスト結果を判定するためのログに基づいて前記ＡＰＩが正しく実行されたか否かを判定するテスト結果判定部を、
さらに備える、
請求項３の検証システム。
【請求項８】
前記ターゲット装置は、
前記テスト結果を判定するためのログの記述ルールが記述されたログ記述ルール管理部と、
前記テスト結果を判定するためのログと前記実行結果ログとを振り分けるログフィルタと、
前記ログフィルタによって振り分けられた前記テスト結果を判定するためのログを蓄積するログ蓄積部と、
をさらに備え、
前記ログ送信部は、ＡＰＩの実行完了後、前記テスト結果の判定を行なうためのログを前記ログ蓄積部から読み出して、前記ＡＰＩ検証装置に送信する、
請求項７の検証システム。
【請求項９】
前記ターゲット装置は、
前記テスト結果を判定するためのログと前記実行結果ログとを振り分けるログフィルタと、
前記ログフィルタで振り分けられた前記テスト結果を判定するためのログを前記ＡＰＩ検証装置に送信する第二のログ送信部と、
を備え、
前記ＡＰＩ検証装置は、
前記第二のログ送信部から送信された前記テスト結果の判定するためのログを受信して前記テスト結果判定部に直接出力する第二のログ受信部を、
さらに備える、
請求項７の検証システム。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2009150788.tif 000015
【図２】
2009150788.tif 000016
【図３】
2009150788.tif 000017
【図４】
2009150788.tif 000018
【図５】
2009150788.tif 000019
【図６】
2009150788.tif 000020
【図７】
2009150788.tif 000021
【図８】
2009150788.tif 000022
【図９】
2009150788.tif 000023
【図１０】
2009150788.tif 000024
【図１１】
2009150788.tif 000025
【図１２】
2009150788.tif 000026
【国際調査報告】
2009150788.tif 000027
2009150788.tif 000028
2009150788.tif 000029
2009150788.tif 000030