JP2011221803A - テストツール、テスト方法 - Google Patents

Abstract

【課題】ハードウェアの仕様の違いに対応した基本ソフトウェアを効率的にテストする、テストツール及びテスト方法を提供することができる。
【解決手段】ハードウェアを抽象化した抽象化層３７の環境を設定するコンフィグレーションパラメータ１４と、ＡＰＩパラメータ１７と、網羅的にコンフィグレーションパラメータの組み合わせと、網羅的にＡＰＩパラメータの組み合わせを、それぞれ抽出する組み合わせ抽出手段２１と、処理シーケンスに含まれる処理に基づき、テストケースを生成するテストケース生成手段１８と、抽象化層３７のインタフェースをモデル化したインタフェースモデル４２と、コンフィグレーションパラメータの組み合わせ、ＡＰＩパラメータの組み合わせ、又は、テストケースを抽象化層３７に適用して抽象化層をテストするテスト実行手段２０と、を有することを特徴とする。
【選択図】図２

Description

本発明は、ソフトウェアをテストするテストツール等に関し、特に、ハードウェアに近いソフトウェアをテストするテストツール及びテスト方法に関する。

ソフトウェアの高機能化・複雑化が進み、ソフトウェアの検証やデバック作業のいっそうの効率化が求められるようになった。しかし、ソフトウェアのモジュール化が進んだため、ソフトウェア単体の検証だけでなく、種々のソフトウェアを組み合わせて検証することも必要になっている（例えば、特許文献１参照。）。

特許文献１では、プラグインモジュールからの情報を取得してテストケースを構築する検証方法が開示されている。これにより、機器に未知なる機能（プラグインモジュール）が搭載されても、動的にテストケースを構築できるので、ソフトウェアを組み合わせた検証が容易になるとしている。

特開２００９−２２３７００号公報

しかしながら、プラグインモジュールのように組み合わせの数が限定的なソフトウェアであれば、全組み合わせの検証も不可能でないが、ソフトウェアがハードウェアに近くなると組み合わせの数が膨大になるため、全組み合わせの検証が困難になってくる。

図１０（ａ）は、ハードウェアとソフトウェアの関係を模式的に示す図の一例である。図１０（ａ）では、ソフトウェアがハードウェアに依存した仕様（ハードウェアの凸部やその形状）を吸収することができることを示す。しかし、図１０(ａ)のように、各ハードウェア毎に特定の仕様を吸収するソフトウェアを用意すると、ソフトウェアの再利用性が低下してしまう。

そこで、異なるハードウェアに依存した仕様を吸収するような基本ソフトウェアが開発されるようになった。図１０（ｂ）は、再利用可能な基本ソフトウェアの構造を模式的に示す図の一例である。図１０（ｂ）ではハードウェアは例えばマイコンであり、ＲＴＥ（Runtime Environment）及びＢＳＷ（Basic Software）が基本ソフトウェアである。なお、ＢＳＷのみを基本ソフトウェアと呼ぶ分類方法もある。このような基本ソフトウェアでは、ＭＣＡＬ（マイクロコントローラ抽象化層）がハードウェアに依存した仕様を吸収するため、基本ソフトウェアをそのまま別のマイコン（自動車で言えば別のＥＣＵ）に搭載することができる。

しかし、ＭＣＡＬは、コンフィグレーション（マイコンの環境設定）により異なるマイコンの仕様に対応する。多様なマイコンの仕様に対応するため、コンフィグレーションの種類や設定値の取り得る値の範囲は膨大であり、コンフィグレーションの設定の全てをテストしようとすると、検査工数が膨大になるという問題がある。

また、ＭＣＡＬは上位層からＡＰＩを介して処理要求を受け付ける。ここでもＭＣＡＬのハードウェア依存性を低減するため、膨大な数のＡＰＩや、各ＡＰＩで設定可能なパラメータ（引数）が設定されている。

このように、ＭＣＡＬのテストにおいて、コンフィグレーションとＡＰＩの全ての組み合わせをテストしようとすると、検査工数が現実的でない数になってしまうという問題がある。

例えば、ＭＣＡＬのテスト項目を低減するだけでも、全体の検査工数は低減できる。しかし、ＭＣＡＬは、マイコンに特有の特殊レジスタを操作するため、むやみにＭＣＡＬのコンフィグレーションをテスト対象から除外すると、ソフトウェアとハードウェアの検証が不十分となるおそれがある。

本発明は、上記課題に鑑み、ハードウェアの仕様の違いに対応した基本ソフトウェアを効率的にテストする、テストツール及びテスト方法を提供することを目的とする。

上記課題に鑑み、本発明は、ハードウェアを抽象化した抽象化層の環境を設定するコンフィグレーションパラメータの記憶部と、前記抽象化層を呼び出すＡＰＩとＡＰＩ毎に設定可能引数が記述されたＡＰＩパラメータの記憶部と、複数の前記コンフィグレーションパラメータから網羅的にコンフィグレーションパラメータの組み合わせを、複数の前記ＡＰＩパラメータから網羅的にＡＰＩパラメータの組み合わせを、それぞれ抽出する組み合わせ抽出手段と、前記抽象化層の処理シーケンスに含まれる処理に基づき、テストケースを生成するテストケース生成手段と、ハードウェアと前記抽象化層のインタフェースをモデル化したインタフェースモデルと、コンフィグレーションパラメータの組み合わせ、ＡＰＩパラメータの組み合わせ、又は、テストケースを抽象化層に適用して抽象化層をテストするテスト実行手段と、を有することを特徴とする。

ハードウェアの仕様の違いに対応した基本ソフトウェアを効率的にテストする、テストツール及びテスト方法を提供することができる。

基本ソフトウェアの構造を模式的に説明する図の一例である。 自動テストツールの環境をフロー形式にて説明する図の一例である。 外部仕様書モジュール設計書からコンピュータ読み取り可能なフォーマットに変換されたConfiguration Descriptionの一例を示す図である。 コンフィグレーション拡張記述の一例を示す図である。 Configuration Descriptionの要素とXMLに記述される文の対応を説明する図の一例である。 ＡＰＩパラメータの一例を示す図である。 ＭＣＡＬのシーケンス図の一部の一例を示す。 実行環境を説明する図の一例である。 市販されているマイコンの特殊レジスタの一例を示す図である。 ハードウェアとソフトウェアの関係を模式的に示す図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
始めに、本実施形態のＭＣＡＬモジュール自動テストツール（以下、自動テストツールという）の概略を説明する。自動テストツールはプログラムである。以下、特に断らなければ、自動テストツールが処理を行う。
（１）タグ言語で記述されたＭＣＡＬのConfigurationパラメータを拡張記述する（以下、拡張記述したConfigurationパラメータを「Configuration拡張記述」という）。
（２）タグ言語で記述されたＡＰＩパラメータを拡張記述する（以下、拡張記述したＡＰＩパラメータを「ＡＰＩパラメータ拡張記述」という）。
（３）Configuration拡張記述からオールペア法によりConfigurationパラメータの組み合わせを抽出する。この組み合わせからConfigurationパラメータに関するテストケースソースコード（ＴＴＣＮ−３）を生成する。
（４）ＡＰＩパラメータ拡張記述からオールペア法によりＡＰＩパラメータの組み合わせを抽出する。この組み合わせからＡＰＩパラメータに関するテストケースソースコード（ＴＴＣＮ−３）を生成する。
（５）ＭＣＡＬのシーケンス図からテストケースの組み合わせを生成する。このテストケースからテストケースソースコード（ＴＴＣＮ−３）を生成する。
（６）マイコンのレジスタ（主に特殊レジスタ）をモデル化しておく（以下、テストスタブという）。
（７）テストケースソースコード、テスト対象であるＭＣＡＬ、テストスタブ、及び、テストドライバ等をコンパイル・リンクして、テストを実行する。

以上のような手順によれば、オールペア法によりConfigurationパラメータの組み合わせとＡＰＩパラメータの組み合わせを効率的に抽出でき、網羅性の高いパラメータによりマイコンの仕様をテストできる。また、テストスタブを生成しておくことで、マイコンに特有なハードウェアの仕様をテストすることができる。

〔基本ソフトウェアについて〕
図１は、基本ソフトウェアの構造を模式的に説明する図の一例である。上層から、アプリケーション層４０、基本ソフトウェア層（ＢＳＷ）４６、そして、最下層はマイコン４４である。また、ＢＳＷ４６内では、ハードウェアが階層的に抽象化されているという特徴がある。

このマイコン４４は、ＥＣＵ（electronic control unit）に搭載されるコンピュータである。また、ＢＳＷ４６としては、AUTOSAR（AUTomotive Open System Architecture）で標準化されている基本ソフトウェアを例にして説明するが、ＭＣＡＬ３７と同等の機能を有する基本ソフトウェアであれば本実施形態の自動テストツールを適用できる。

ＢＳＷ４６は、ＲＴＥ４１、サービス層４２、ＥＣＵ抽象化層４３、ＭＣＡＬ（マイクロコントローラ抽象化層）３７、及び、複合ドライバ４５によって構成される。最下層のＭＣＡＬ３７は、ＥＣＵのマイコン４４の全ての機能と周辺機器を抽象化する層である。ＭＣＡＬ３７より上位の階層はマイコン４４から独立している。ＭＣＡＬ３７は、例えば、マイクロコントローラドライバ、メモリドライバ、通信ドライバ及びＩ／Ｏドライバを有する。

ＥＣＵ抽象化層４３は、ＥＣＵ の全ての基本コンポーネントを抽象化する。ＥＣＵ抽象化層４３は、例えば、搭載機器抽象化、メモリハードウェア抽象化、通信ハードウェア抽象化及びＩ／Ｏハードウェア抽象化を有する。

また、サービス層４２は、ハードウェアから独立した、様々なサービスを提供する層であり、ＯＳ（例えば、ＯＳＥＫ（Open system together with interfaces for automotive electronics）やその他、組み込み用ＯＳ、リアルタイムＯＳ等）、システムサービス（診断ソフト、メモリ管理ソフト等）、メモリサービス、通信サービス（車載ＬＡＮの通信のためのネットワーク管理ソフト（ＣＡＮ、ＦｌｅｘＲａｙ，ＬＩＮ等））を有する。

ＲＴＥ４１は、サービス層４２等に対しアプリケーション層４０を抽象化し、ＢＳＷ４６とアプリケーション間のデータ通信を処理する。ＲＴＥ４１より上位のアプリケーションはハードウェアに依存せず、ＲＴＥ４１があることで、ＥＣＵにどのようなハードウェアが用いられるかという情報なしに開発者がアプリケーションを開発することを可能にする。なお、ＲＴＥ４１の種類には、AUTOSARインタフェース、標準AUTOSARインタフェース及び標準インタフェースがあるが、本実施形態では特に区別しない。

複合ドライバ４５は、特殊なタイミングの制約を受けるセンサやアクチュエータをアプリケーションが直接制御することを可能にする。アプリケーション層４０には、センサが検出した信号を処理するアプリケーション、モータの制御量を決定するアプリケーション、運転支援を行うアプリケーション等、様々なアプリケーションが搭載されうる。

〔自動テストツールの環境〕
図２は、自動テストツールの環境をフロー形式にて説明する図の一例である。これから説明する処理は、コンピュータ（パソコン、ワークステーション、サーバ等）１００上で実行される。コンピュータ１００はＣＰＵ、ＲＡＭ、ＲＯＭ、ＨＤＤ（Hard Disk Drive）、入出力装置（キーボード、マウス）等を有し、ＨＤＤには自動テストツールのプログラムが記憶されている。自動テストツールは、このプログラムをＣＰＵが実行することで実現される。したがって、コンピュータ１００と自動テストツールは一体である。

＜＜テストスイート＞＞
＜Configurationパラメータファイル２２の生成＞
まず、外部仕様書のモジュール設計書１１は、ＭＣＡＬ３７のConfigurationパラメータを自然言語や表形式で記述した電子ファイルである。外部仕様書のモジュール設計書１１は、例えばＨＤＤに記憶されている。Configuration Description１３、コンフィグレーション拡張記述１４、１５、Vendor Specific Module Description１６、ＡＰＩパラメータ拡張記述１７、Configurationパラメータファイル２２，ＡＰＩ定義ファイル２３、テストケース組み合わせファイル２４、外部仕様書のシーケンス図１９についても同様にＨＤＤに記憶されている。

ＭＣＡＬ３７は、マイコン４４の全ての機能と周辺機器を抽象化したものなので、具体的なＥＣＵの仕様に適合させるためパラメータを必要とする。例えば、マイコン４４の通信デバイスの種類、通信チャネル、送信時の通信速度、受信時の通信速度等がパラメータとなる。AUTOSARでは一連のパラメータをConfigurationパラメータと呼ぶ。

多様なマイコン４４に対応するため、Configurationパラメータの種類や設定可能な値は膨大な数にのぼる。この膨大な数のＭＣＡＬ３７のConfigurationパラメータが、外部仕様書のモジュール設計書１１に記述されている。外部仕様書のモジュール設計書１１は、自然言語で記述されていることが多いので、テスト担当者やマイコンメーカが、コンピュータ読み取り可能なフォーマットに変換しておく。外部仕様書のモジュール設計書１１がコンピュータ読み取り可能なフォーマットで配布されるのであれば、変換作業は不要である。

図３は、外部仕様書のモジュール設計書１１からコンピュータ読み取り可能なフォーマットに変換されたConfiguration Description１３の一例を示す。コンピュータ読み取り可能なフィーマットは、例えばタグ言語（例えばＸＭＬ）である。図３は表形式で記述されているが、表形式からＸＭＬ形式への変換（又は、その逆の変換）は容易なので、図３の表形式は実質的にはＸＭＬ形式である。自動テストツールはConfiguration Description１３を容易に読み込むことができる。なお、ＸＭＬでなくＣＳＶ（Comma Separated Value）等のフォーマットを利用してもよい。

図３は、通信ドライバ（ＣＡＮドライバ）のConfigurationパラメータの一例を示す図である。通信ドライバはさらに複数のモジュールに分けて抽象化されているが、図３ではＭＢＯＸ（メールボックス）のConfiguration（SPF_CPU_CAND_CFG_ID_MB）パラメータを例に説明する（メールボックス毎のCAN ID）。

SPF_CPU_CAND_CFG_ID_MBのパラメータによれば、ＭＢＯＸは「０〜３１」番まで昇順に選択すべきであり、メールの番号（＝ＣＡＮ
ＩＤ）は「０〜２０４７」までランダムに設定する、ように規定されている。この、「０〜３１」「０〜２０４７」がConfigurationパラメータである。図３に示しただけでも通信ドライバの他に多くのモジュールがあることがわかり、それぞれが「０〜３１」「０〜２０４７」のようなConfigurationパラメータを取るので、全組み合わせのテストを行おうとすると膨大な数の組み合わせになってしまう。

次に、自動テストツールは、Configuration Description１３から、タグ言語形式のコンフィグレーション拡張記述１４を生成する。タグ言語は、例えばＸＭＬ、ＨＴＭＬ等である。
図４は、コンフィグレーション拡張記述１４の一例を示す図である。自動テストツールは、Configuration Description１３から要素を読み出し、予め定義しておいたタグ名＜mstate＞＜ｍPlaces＞＜ｍMax＞＜mMin＞＜ｖState＞＜vMax＞＜vMin＞等に対応づけてＸＭＬ文書を生成する。Configuration Description１３の要素に対応して、ＸＭＬに記述される文（タグに挟まれる記述）もあらかじめ決まっている。

図５は、Configuration Description１３の要素とＸＭＬに記述される文の対応を説明する図の一例である。例えば、Configuration Description１３の要素が「マルチプル昇順」であればＸＭＬに記述される文は「selectMultiplicityByOrder」であり、Configuration Description１３の要素が「値ランダム」であればＸＭＬに記述される文は「selectValueRandom」である。

図４の記述Ａは「メールボックスは０〜３１まで昇順に選択する」ことを、記述Ｂは「CAN IDは０〜２０４７からランダムに選択する」ことを、それぞれ意味する。したがって、自動テストツールは、コンフィグレーション拡張記述１４から、Configurationパラメータに設定すべき値の範囲や、設定ルールを取得することができる。

なお、外部仕様書のモジュール設計書１１、Configuration Description１３、及び、コンフィグレーション拡張記述１４は、マイコン４４に共通（例えば、メーカの異なるマイコンでも）のConfigurationパラメータである。すなわち、各メーカは外部仕様書のモジュール設計書１１に則るようにマイコン４４を設計するので、コンフィグレーション拡張記述１４も各マイコン４４に共通になる。

図２に戻り、自動テストツールの組み合わせパラメータジェネレータ２１は、コンフィグレーション拡張記述１４から、オールペア法を用いてConfigurationパラメータファイル２２を生成する。Configurationパラメータファイル２２がＴＴＣＮ-３という言語で記述されることが自動テストツールの特徴の１つである。

オールペア法は公知の技術なので簡単に説明する。図３のConfiguration Description１３を例に、「Controller」「Channel」「Mbox」「Extend」の４つをオールペア法の因子Ａ〜Ｄとする。説明のため、各因子Ａ〜Ｄは１度にある項目しか取らないとし、各因子Ａ〜Ｄが「Ｍｂｏｘ」と同じ数のパラメータ（例えば、３２×２０４８＝６５５３６個）を取ると仮定する。すなわち、因子Ａ〜Ｄがそれぞれ６５５３６個のパラメータを持つ。なお、この段階で、因子Ａ〜Ｄのパラメータの数を制限してもよい。また、因子Ａ〜Ｄと他の因子を組み合わせたり、因子Ａ〜Ｄの一部を組み合わせから排除するなど、因子間の組み合わせの規則は予め定められている。

因子が４つの場合、オールペア法は、４つの因子のパラメータから抽出しうる２つのパラメータの組み合わせの全てを抽出し、２つのパラメータをなるべく重複しないように４つの因子にそれぞれ割り当てることで、４つの因子のパラメータの組み合わせを生成する。こうすることで、２因子については１００％の組み合わせが得られる。また、オールペア法では、組み合わせのあり得ない禁則を容易に指定できるので、４つの因子のパラメータの組み合わせをさらに低減することもできる。

Configurationパラメータファイル２２は、４つの因子のパラメータの組み合わせの１つ毎に生成される。１つのConfigurationパラメータファイル２２は、例えば、「Controller」のパラメータ１（６５５３６個の組み合わせのいずれか），「Channel」のパラメータ１，「Mbox」のパラメータ１，「Extend」のパラメータ１、の組を有する。

このようにして、自動テストツールは、ＭＣＡＬ３７のConfigurationパラメータから、十分な組み合わせを網羅したConfigurationパラメータファイル２２を生成できる。

・マイコン固有のConfigurationパラメータファイル２２の生成
コンフィグレーション拡張記述１４は、各マイコン４４に共通のものであると説明したが、マイコン４４に特有のConfigurationパラメータをテストするため、自動テストツールは、コンフィグレーション拡張記述１５からもConfigurationパラメータファイル２２を生成する。

外部仕様書のモジュール設計書１１には、あるマイコン４４のＭＣＡＬ３７に固有のConfigurationパラメータも自然言語や表形式で記述されている。マイコン４４に固有のConfigurationパラメータとは、例えば、異なるメーカ間や同じメーカでも製品間で違いが生じうるConfigurationパラメータである。

マイコン４４に固有のConfigurationパラメータには、例えば、マイコン４４に固有の、通信チャネル、送信時の通信速度、受信時の通信速度等が規定されている。テスト担当者やマイコンメーカが、マイコン４４に固有のConfigurationパラメータを、コンピュータ読み取り可能なフォーマットに変換しておく。こうすることで、Vendor Specific Module Description１６が生成される。記述の形式は、Configuration Description１３と同様、例えば表形式、ＸＭＬ形式、ＣＳＶ形式である。
自動テストツールは、Vendor Specific Module Description１６から、図４のようなコンフィグレーション拡張記述１５を生成することができる。自動テストツールは、マイコン４４に固有のコンフィグレーション拡張記述１５からオールペア法を用いて、Configurationパラメータファイルを生成する。なお、出来上がったConfigurationパラメータファイル２２が、マイコン４４に共通か固有かは特に区別しなくてよい。

ＴＴＣＮ−３で記述された１つのConfigurationパラメータファイル２２が、ＭＣＡＬをテストするための１つのテストケースとなる。

＜ＡＰＩ定義ファイル２３の生成＞
外部仕様書のモジュール設計書１１には、ＭＣＡＬ３７のＡＰＩパラメータが自然言語や表形式で記述されている。このＡＰＩは、例えば、ＥＣＵ抽象化層４３とＭＣＡＬ３７のＡＰＩである。ＡＰＩは関数形式で提供されている。したがって、典型的なＡＰＩは各関数であり、ＡＰＩパラメータは関数の引数である。外部仕様書のモジュール設計書１１には、このようなＭＣＡＬ３７のＡＰＩパラメータが記述されている。

図６は、ＡＰＩパラメータの一例を示す図である。関数毎に、関数が持つ１以上の引数、その引数が取り得る値、及び、複数の値からの値選択方法が記述されている。テスト担当者やマイコンメーカは、外部仕様書のモジュール設計書１１からコンピュータ読み取り可能なＡＰＩパラメータ拡張記述１７を生成する。Configurationパラメータと同様に、テスト担当者やマイコンメーカが、外部仕様書のモジュール設計書１１をコンピュータ読み取り可能なフォーマットに変換しておくことが好ましい。

自動テストツールは、図６のようなＡＰＩパラメータからＡＰＩパラメータ拡張記述１７を生成する。すなわち、ＡＰＩパラメータから要素を読み出し、予め定義しておいたタグ名に対応づけてＸＭＬ文書を生成する。タグ名に挟まれるＸＭＬに記述される文は、ＡＰＩパラメータの要素に対応して予め決まっている。

また、自動テストツールの組み合わせパラメータジェネレータ２１は、ＡＰＩパラメータ拡張記述１７から、オールペア法を用いてＡＰＩ定義ファイル２３を生成する。同様に、ＡＰＩパラメータ定義ファイルはＴＴＣＮ-３という言語で記述される。

図６のｆｕｎｃ１のように引数（引数ａ１，ａ２，ａ３）が３つの場合、引数を因子Ａ〜Ｃとする。組み合わせパラメータジェネレータ２１は、因子Ａ〜Ｃのパラメーから、抽出しうる全ての２つのパラメータの組み合わせを抽出し、２つのパラメータをなるべく重複しないように３つの因子にそれぞれ割り当てることで、３つの因子のパラメータの組み合わせを生成する。因子Ａ〜Ｃのパラメータの組み合わせのうち、引数の組み合わせとしてあり得ない組み合わせは、排除することができる。

ＴＴＣＮ−３で記述された１つのＡＰＩ定義ファイル２３が、ＭＣＡＬをテストするための１つのテストケースとなる。

＜テストケース組み合わせファイル２４の生成＞
外部仕様書のシーケンス図１９には、例えばＵＭＬ（Unified Modeling Language）で記述されたＭＣＡＬ３７のシーケンス図が記述されている。なお、ＵＭＬのクラス図を、シーケンス図の代わりに又はシーケンス図と共に利用することもできる。クラス図は、ＭＣＡＬ３７のシステムを構成するクラス間の関連を表す。各クラスは、属性（変数）と操作を含むことができる。属性には、アクセスレベル、変数名、型等が記述され、操作には、関連づけされたクラスからの要求で起動することのできるサービスが記述されている。

図７はＭＣＡＬ３７のシーケンス図の一部の一例を示す。図７ではｆｕｎｃ１とＣＡＮ Ｄｒｉｖｅｒがそれぞれ１つのクラスである。ＭＣＡＬの一般的な処理の手順を説明する。このシーケンス図では、例えば、ＥＣＵ抽象化層４３がＡＰＩとしてのｆｕｎｃ１を呼び出す。呼び出す際、ｆｕｎｃ１は引数ａ１〜ａ３を受け取る。ｆｕｎｃ１は、引数ａ１〜ａ３と共にＣＡＮ Ｄｒｉｖｅｒに送信要求を通知する。ＣＡＮ Ｄｒｉｖｅｒは、引数ａ１〜ａ３を用いて送信に必要な処理を行う。

ＣＡＮ Ｄｒｉｖｅｒは、マイクロコントローラに搭載されたＣＡＮコントローラを制御してメッセージを送信する。したがって、Configurationパラメータに誤った値が設定されれば、ＣＡＮコントローラの仕様を満たさずに送信できないことになる。本実施例の自動テストツールはこのような不整合を検出することを可能にする。

ＣＡＮ Ｄｒｉｖｅｒは送信結果をｆｕｎｃ１に通知するように設計されていることが多い。よって、シーケンス図に従ったテストをした場合、ＣＡＮ
Ｄｒｉｖｅｒは、送信結果（エラーの有無、エラーの種類）をｆｕｎｃ１に通知する。したがって、ｆｕｎｃ１は、送信結果をチェックして送信が無事に行われたか否か、無事に送信できない場合は、どのようなエラーが生じたかを判定することができる。したがって、自動テストツールがエラー内容をエコーすれば、テスト結果を記録することができる。

シーケンス図には、このように、一方のクラスが他方のクラスに要求する処理、及び、１つのクラス内で実行する処理等、が記述されている。

また、図7のシーケンス図とは逆に、ＣＡＮ Ｄｒｉｖｅｒがデータを受信して割り込みを発生させてＡＰＩを呼び出す処理もＭＣＡＬ３７のシーケンス図には記述されている。

自動テストツールのテストケースジェネレータ１８は、シーケンス図から処理手順を参照し、このようなテストケースの組み合わせを抽出する。好ましくは、全てのステップ及び分岐を一度は処理するように、１つのシーケンス図から複数のテストケースを抽出する。図７を例にすれば、ＥＣＵ抽象化層４３がｆｕｎｃ１を呼び出すための処理、ｆｕｎｃ１がＣＡＮ
Ｄｒｉｖｅｒを呼び出すための処理、ＣＡＮ Ｄｒｉｖｅｒがレジスタに値を設定するための処理、がテストケースとなる。なお、テストケースとは、一般に、テスト対象であるＭＣＡＬ３７に対して入力データとして与えるデータをいうが、本実施形態では、ＭＣＡＬ３７に要求する処理をいう。

テストケースジェネレータ１８は、テストケースの１つ１つを生成する。これらテストケースの集合がテストケース組み合わせファイル２４である。テストケース組み合わせファイル２４はＴＴＣＮ-3という言語で記述される。

テストケースジェネレータ１８は、ＴＴＣＮ−３により、ConfigurationパラメータやＡＰＩパラメータが含まれるテストケース組み合わせファイル２４を生成する。このテストケース組み合わせファイル２４と、Configurationパラメータファイル２２とＡＰＩ定義ファイル２３が、ＭＣＡＬのテスト内容となる。

また、テストケースジェネレータ１８は、生成したテストケースのConfigurationパラメータやＡＰＩパラメータを、すでに求められているConfigurationパラメータファイル２２やＡＰＩ定義ファイル２３の各パラメータで置き換えて、１つのテストケースから網羅的にテストケースを生成することもできる。この場合、自動テストツールは、シーケンス図から求めた１つのテストケースについて、網羅性の高いConfigurationパラメータ及びＡＰＩパラメータを使用して、テストを実行することができる。

なお、ＴＴＣＮ−３では、ＳＵＴ（ＭＣＡＬ３７）に対し、「port1.send(Stimulus)、Port2.Recieve(Response)」の手順でテストを実行する。「Stimulus」の具体的な記述が、Configurationパラメータファイル２２、ＡＰＩ定義ファイル２３又はテストケース組み合わせファイル２４から決定される。自動テストツールは、「Stimulus」として、ConfigurationパラメータやＡＰＩパラメータを設定するＴＴＣＮ−３の関数を含む記述、テストケースを実行するためＴＴＣＮ−３の具体的な記述等、を生成する。ＴＴＣＮ−３は一例であって、Ｕ２ＴＰ等のテスト言語を採用してもよい。

＜＜テスト実行環境＞＞
テスト実行環境２０もコンピュータ１００内の環境であるが、別のコンピュータ上で構築してもよい。テスト実行環境２０は、不図示のコンパイラ及びリンカを有し、自動テストツールから実行される。

テスト実行環境２０は、例えば、Ｃ言語をベースとする。このため、自動テストツールは、ＴＴＣＮ−３により記述されたConfigurationパラメータファイル２２、ＡＰＩ定義ファイル２３及びテストケース組み合わせファイル２４をＣ言語にトランスレートする。これは、テスト対象であるＭＣＡＬ３７がＣ言語で記述されているためである。したがって、ＭＣＡＬ３７がＪａｖａ（登録商標）で記述されていればＪａｖａ等にトランスレートしてもよいし、逆に、ＭＣＡＬ３７をＴＴＣＮ−３にトランスレートしてもよい。

ＴＴＣＮ−３とＣ言語の記述方法の対応は、不図示のテーブルに記述されており、自動テストツールがＴＴＣＮ−３の記述を元にＣ言語に変換していく。例えば、ＴＴＣＮ−３の「integer」はＣ言語の「int」に、「signature」は「function」にそれぞれ変換される。

Ｃ言語に変換された、Configurationパラメータファイル２２、ＡＰＩ定義ファイル２３又はテストケース組み合わせファイル２４の１つのテストファイルが、テストケース実行部分（ＴＥ）３１となる。全てのテストファイルが、Ｃ言語の例えばＭａｉｎ関数内に記述されることで、全てのテストケース実行部分３１がＭＣＡＬ３７に適用され、網羅的かつ効率的にテストを実行することができる。

ここで、Ｃ言語によるテスト実行環境２０では、ＭＣＡＬ３７のヘッダファイルが必要であるため、例えば、組み合わせパラメータジェネレータ２１は、ＭＣＡＬ３７のヘッダファイル（コンフィグレーションファイル（＊.h）２７を生成する（予め生成されている）。

また、テスト実行環境２０は、ＳＡ（ＳＵＴ Adapter）２９・３３、ＴＡ（Target Adapter）３５・３８、ＰＡ（Platform Adapter）３６・４１、テストドライバ３２、及び、テストスタブ４２を有する。これらについては後述する。

自動テストツールは、テスト実行環境２０の各ファイル（プログラム）をコンパイル及びリンクして、実行ファイルを生成し、実行する。実行結果は、コンピュータのハードディスク等に記憶されるので、テスト担当者はテスト結果を検証することができる。

例えば、送信時にエラーの起こりえないConfigurationパラメータの場合、エラーが検知されれば、テストにより不具合が検出されたことになる。このように、少なくとも、テストファイルと実行結果からテスト担当者が、正しい結果か否かを判定できるようになっている。なお、例えば、テストケース組み合わせファイル２４に、期待値を含ませることもできる。

図８は、実行環境を説明する図の一例である。左のテストケース実行部分３１Ａがテストドライバ３２と、右のテストケース実行部分３１Ｂがテストスタブ４２と、それぞれ接続されている。テストケース実行部分３１Ａは、ＥＣＵ抽象化層４３からＭＣＡＬ３７を使用する処理のテストケースの実行部である。

したがって、テストドライバ３２はＥＣＵ抽象化層４３に対応し、ＭＣＡＬ３７を呼び出すためのプログラムである。ＳＡ３３は、テストケース実行部分３１Ａからテストドライバ３２を介して要求される関数の呼び出しを受け付け、応答を返すアダプタ（プログラム）であり、ＴＡ３５はＳＡ３３が受け付けた関数の実行をＭＣＡＬ３７に要求する。なお、ＰＡ３６、４１は、テストケース実行部分３１Ａ，３１Ｂにタイマなどの実行環境のリソースを提供するモジュール（プログラム）である。

ＭＣＡＬ３７は、ＴＡ３５から要求された関数を実行するなどの処理を行い、処理結果をＴＡ３８に出力する。ＭＣＡＬ３７はマイクロコントローラを抽象化したものなので、多くの場合、テストケースはマイクロコントローラを制御する。具体的には、汎用レジスタや特殊レジスタへの値の設定、割り込みの発生、スイッチのオン・オフ等を行う。

本実施形態では、特に、特殊レジスタを抽象化してテストスタブ４２を生成したことが特徴の１つである。
図９は、市販されているマイコン４４の特殊レジスタの一例を示す図である。特殊レジスタは、マイコン４４の演算部がデータを自由に読み書きできる汎用レジスタと対比させたレジスタの呼称であり、マイコン４４のモードを決定するレジスタ、設定できる値が決まっているレジスタ、値が設定できないレジスタ、ポインタ専用のレジスタ等である。

特殊レジスタは、マイコン４４毎に一部又は全てが異なる可能性があるので、ＭＣＡＬ３７が正確に作動するかをテストするためには、テストケースに応答してＭＣＡＬ３７が特殊レジスタを正常に操作できるか否かをテストすることが好ましい。本実施形態では、特殊レジスタをテストスタブ４１にすることで、マイコン４４に特有のハードウェアをテストすることができる。

図８に戻り、ＭＣＡＬ３７は、ＴＡ３８に対しテストスタブ４２の呼び出しを通知し、ＴＡ３８はＳＡ３９にテストスタブ４２の呼び出しを通知する。ＳＡ３９はＭＣＡＬ３７が要求した値をテストスタブ４２に値を設定する。テストスタブ４２は、設定した値や設定結果をＳＡ３９に返すなどして、最終的にテストケース実行部分３１Ａがテスト結果を取得する。テストケース実行部分３１Ａは、テストケース毎にテスト結果を記録する。

一方、テストケース実行部分３１Ｂは、ＭＣＡＬ３７が利用するテストスタブ４２に、ＭＣＡＬ３７を介することなく値を設定するなどの処理を施す。すなわち、直接的に特殊レジスタに値を設定することができる。このようなテストケースにより、例えばマイコン４４に割り込みが生じた際の、ＭＣＡＬ３７の応答をテストすることができる。同様に、テストケース実行部分３１Ｂは、テストケース毎にテスト結果を記録する。

以上説明したように、本実施形態の自動テストツールは、Configurationパラメータの組み合わせとＡＰＩパラメータの組み合わせを効率的かつ網羅的に抽出して、網羅性の高いパラメータによりマイコンの仕様をテストできる。また、マイコンに特有なハードウェアの仕様をテストすることもできる。

１１ 外部仕様書のモジュール設計書
１３ Configuration Description
１４、１５コンフィグレーション拡張記述
１６ Vendor Specific Module Description
１７ ＡＰＩパラメータ拡張記述
１８ テストケースジェネレータ
１９ 外部仕様書のシーケンス図
２０ 実行環境
２１ 組み合わせパラメータジェネレータ
２２ Configurationパラメータファイル
２３ ＡＰＩ定義ファイル
２４ テストケース組み合わせファイル
３７ ＭＣＡＬ
１００ コンピュータ

Claims (9)

1. ハードウェアを抽象化した抽象化層の環境を設定するコンフィグレーションパラメータと、
   前記抽象化層を呼び出すＡＰＩとＡＰＩ毎に設定可能引数が記述されたＡＰＩパラメータと、
   複数の前記コンフィグレーションパラメータから網羅的にコンフィグレーションパラメータの組み合わせを、複数の前記ＡＰＩパラメータから網羅的にＡＰＩパラメータの組み合わせを、それぞれ抽出する組み合わせ抽出手段と、
   前記抽象化層の処理シーケンスに含まれる処理に基づき、テストケースを生成するテストケース生成手段と、
   前記ハードウェアと前記抽象化層のインタフェースをモデル化したインタフェースモデルと、
   前記コンフィグレーションパラメータの組み合わせ、前記ＡＰＩパラメータの組み合わせ、又は、前記テストケースを前記抽象化層に適用して前記抽象化層をテストするテスト実行手段と、
   を有することを特徴とするテストツール。
2. 前記組み合わせ抽出手段は、オールペア法により前記コンフィグレーションパラメータの組み合わせ、及び、前記ＡＰＩパラメータの組み合わせを抽出する、
   ことを特徴とする請求項１記載のテストツール。
3. 前記インタフェースモデルは、マイコンの特殊レジスタをモデル化したものである、
   ことを特徴とする請求項１又は２記載のテストツール。
4. 前記コンフィグレーションパラメータには、ハードウェアに固有の仕様が含まれる、
   ことを特徴とする請求項１〜３いずれか１項記載のテストツール。
5. 前記コンフィグレーションパラメータ又は前記ＡＰＩパラメータは、タグ言語で記述されている、
   ことを特徴とする請求項１〜４いずれか1項記載のテストツール。
6. 前記コンフィグレーションパラメータ、前記ＡＰＩパラメータ、及び、前記テストケースは、テスト用言語のＴＴＣＮ−３を用いて記述されている、
   ことを特徴とする請求項１〜５いずれか1項記載のテストツール。
7. 前記コンフィグレーションパラメータには、設定可能範囲から1つの値を選択する値選択方法が記述されており、
   前記ＡＰＩパラメータには、設定可能範囲から１つの値を選択する値選択方法が記述されている、
   ことを特徴とする請求項１〜５いずれか1項記載のテストツール。
8. 前記抽象化層は、マイコンの機能と周辺機器を抽象化した層である、
   ことを特徴とする請求項１〜７いずれか１項記載のテストツール。
9. ハードウェアを抽象化した抽象化層をテストするテスト方法であって、
   前記抽象化層の環境を設定するコンフィグレーションパラメータから、網羅的にコンフィグレーションパラメータの組み合わせを抽出するステップと、
   前記抽象化層を呼び出すＡＰＩ毎に設定可能引数が記述されたＡＰＩパラメータから、網羅的にＡＰＩパラメータの組み合わせを抽出するステップと、
   前記抽象化層の処理シーケンスに含まれる処理に基づき、テストケースを生成するテストケース生成ステップと、
   前記コンフィグレーションパラメータの組み合わせ、前記ＡＰＩパラメータの組み合わせ、又は、前記テストケースを、ハードウェアとのインタフェースがモデル化された前記抽象化層に適用して前記抽象化層をテストするテスト実行ステップと、
   を有することを特徴とするテスト方法。

Images