| Home | 会社案内 | 製品情報 | リファレンス | ニュース | 採用情報 | コンタクト |
TestWeaver 向けFAQ
多くのお客さまから TestWeaver は他のテストツール、既存のテスト手法とどこが違うのか質問をいただきます。ここではそれに対する回答をしています。ここで記述されていることは、範囲が非常に幅広く、深いので、これだけではご理解いただけない面もあるかもしれません。
また特定の手法やツールが他に対して優れているといった比較はしておりません。色々な手法やツールは一長一短、制約等があり、色々な環境下において特定のツール、手法が他の物に入れ替えられることはありません。ここで記載されている事について、ご意見ご質問などございましたら、ぜひこちらまでお問い合わせください。
.
- TestWeaver はどういう解析をおこなっているのでしょうか？
TestWeaver はシステムのテスト及び検証用のツールです。TestWeaver は既存のテストツールに比べより幅広い範囲のテストに適用が可能です。ツールの機能の範囲としてソフトウェア不具合検出、品質解析、許容解析、故障解析、安全性解析、堅牢性解析等をサポートしています。
TestWeaver は単にシミュレートされたシナリオによるシステムの特定の特性の違反チェック以上のことが可能になります。各種ステートへの到達度、網羅度を向上し、特定の不具合を検出する為に、ヒューリスティックな解析、探索手法を用い、テスト対象システムのリアクティブな特性を考慮したテストシナリオの自動生成およびテストが可能です。各種抽象度を持つテスト結果レポート生成により、テストシナリオ結果の把握の視覚化を支援します。これらにより、TestWeaver は従来のテストを遥かに超えた範囲の検証が可能となります。
TestWeaver はシステムの弱点を探し出し、見つけることに使えます。例えば、特定の品質要求が許容範囲を下回るようなシナリオ、制御順の間違いなど。これらの事を行うために、定量的、定性的な品質要求基準の設定と、シミュレーションを行うことになります。
TestWeaver はパラメータが許容値以上に逸脱しないかといった解析にも使用可能です。これは、センサーやアクチュエーターの故障の影響調査などに応用でき、システムの安全性や堅牢性のチェックなどに使えます。
しかしながらTestWeaver は不具合の発見はできますが、不具合が起こり得ないということの証明はできかねます。TestWeaver によりステートの到達度を把握することが可能です。
- TestWeaver は組込みソフトウェア、組込みシステム向けに限定されたツールなのですか？
TestWeaver は実際組み込みシステムに限定されるものではありません。ソフトウェアで実行されるほとんどの物にTestWeaver を接続することが可能です。しかしながら現在は特定のテストツール、例えばGUI、Web アプリケーション、インストールツール等はサポートしていません。C もしくは Python ライブラリーを使って TestWeaver と通信をしますので、それをテストフレームで使用できるようにできれば、 TestWeaver を使えるようになります。
- TestWeaver は Embedded Validator、SPIN 等のモデルチェッキングツールや形式検証手法とは違うのですか。
形式検証手法はモデルが好ましくない特性を持たないことを数学的に証明することが可能です。TestWeaver のようなテストツールは不具合の検出はできますが、不具合が無いことの証明はできません。形式検証は複雑なモデルへの適用は困難ですが、TestWeaver はこの制限はありません。また形式検証手法ではそれ以外にも色々な制約がありますが、TestWeaver には当てはまりません。
もしいくつかの特性がモデルチェッキングやその他の 形式検証手法で不具合が無いことが証明された場合、検証という意味では、テスト手法以上の完全な解となります。しかしながら、実際のシステムは物理的なコンポーネントやプロセスをもち、それらは形式検証ではチェックできません。 また、形式検証は以下のような制約があります。
- 解析のスコープが狭い
これが形式検証手法が直面する最もシリアスな問題となります。表現の制限、複雑さの限界等々。このことにより、形式検証では複雑なシステムの一部の解析のみ可能となり、実世界との相互関係は無く、その結果解析はシステム検証という目的を満たすことができません。いくつかのモジュールのモデルの形式的な検証にはなりますが、一般的にそれはシステムが安全であることの証明にはなりえず、品質のチェックや仕様に一致しているかどうかの検証にはなかなか使用できません。TestWeaver 等のシミュレーションをベースとした手法はこの限界は無く、大規模で複雑な実世界と相互関係を持つシステムに適用できます - 仕様記述言語：表現の制約
形式手法では、表現できること、何を検証できるかに大きな制約が有ります。例えば、一般的にステートマシン等のディスクリートモデルや静的モデルプロパティは表現可能ですが、複雑なディスクリートや微分方程式を含む連続モデルが混合した解析などができるツールはありません。TestWeaver を使ったテスト手法では、これらは一般的に問題にはなりません。もしシミュレーションができれば、それはテスト可能です。 - 仕様記述言語：一つの言語 vs 複数の言語
モデルとモデルプロパティに適用できる形式手法はいくつかの限定された言語で定義されます。解析するためにはそれらの言語により完全に定義されたモデルが必要です。もし解析範囲が独立した一つ、もしくは少しのモジュールであれば問題ないかもしれません。しかしながら完全なシステムではそれは不可能、もしくは実用的ではありません。TestWeaver はそういった仕様記述言語で発生する制限はありません。なぜならそれはシミュレーションを行い、評価しているからです。モジュールは多様な言語で実装することが可能です。例えばC、Python、MATLAB/Simulink、Modelica - 実行ができ TestWeaver に接続できれば、実質的に TestWeaver による制約はありません。複数の異なった言語をミックスして一つのシミュレーションに定義することも可能です。 - 形式言語：モデルに対する検証 vs 実装の検証
通常フォーマル解析はモデルに対して適用され、実装（実際の実行コード）には適用されません。その違いを考慮すべきです。例えばソフトウェアインザループシミュレーション（SIL）のようなシミュレーションではTestWeaver はほぼ実装に近い特性をチェックしています。 - モデルのサイズと複雑さ
形式検証に基づいた手法とツールは検証可能なモデルのサイズを常に考慮する必要が有ります。TestWeaver に"物理的な制限"はなく、テスト可能なモジュールのサイズに制限は受けません。例えば、TestWeaver は百万行以上の C ソースコードのシステムをチェックすることが可能です。
- 解析のスコープが狭い
- TestWeaver は PolySpace や Coverity、その他の静的解析ツールとどう違うのですか。
モデルチェッキングや形式手法と同様の事が言えます：手法により強み、弱点、範囲が異なります。どの手法も完全に他の物を補完するものはありません。複雑なプロジェクトでは TestWeaverはさらなるバグ、例えばコード解析が行われる前に不具合を見つけることもできます。また TestWeavr は静的解析では全く見つからない不具合を見つけることが可能です。
静的解析とシンボリックコード評価はいくつかのソフトウェアの不具合、例えばゼロ除算、アクセス違反、配列の境界外アクセス違反等を見つけることが可能です。それらの手法、ツールによっては修正されたコードがそれ以上不具合が発生しないことを保証することも可能です。
しかしながら実際にはそれは常にうまくいくとは限りません。一つの理由として解析可能なソースコードのサイズの制限によるものです。他の理由は特に組み込みソフトウェアではクリティカルですが、ソフトウェアで制御される物理システムは解析の範囲外であるからです。センサーやアクチュエーターやバス通信は個別の入出力として扱われ、解析されます。（複数スレッドや通信に関する不具合の検出は難しい面があります）。また多くの検出されたワーニング（例えば PolySpace で言うオレンジ）は本当の不具合であるかどうかが解析では完全には決定できないからです。人手でそれらをチェックする必要があり、複雑さから完全にバグを取り除くことができない場合もあります。TestWeaver は他の手法では見つからない不具合を見つけることへの支援が可能です。TestWeaver はしかしながら、静的コード解析で検出できる不具合を常に見つけられるとは保証できません。
TestWeaver は静的解析では全く見つからないバグを見つけることが可能な場合があります。制御システムと環境の間の相互作用に関連する不具合、例えば仕様に関する不具合、システムのオーバーヒート、故障時のリアクションが正しいか等といった事です。それらは静的解析ツールでは見つかりませんが、TestWeaver であれば可能です。
- TestWeaver は Embedded Tester、Conformiq Qtronic、Rhapsody Automated TestGenerator
等のモデルベースのテスト生成ツールとどう違うのですか？
フォーマル検証ツールと同様、モデルベーステスト自動生成（MBTG）は一般的には限定されたディスクリートモデルを使用した仕様記述言語によりシステムを定式化したモデルに基づいています。TestWeaver はシステムのシミュレーションを使用するため、完全なモデルは必要としません。さらに、TestWeaver は Simulink もしくは他の仕様記述言語やディスクリート現象の解析にも限定されることは無く、制限されることはありません。MBTGはディスクリートモデル（と独立したソフトウェア）のプロパティの解析に有効です。しかしながら、物理コンポーネントと微分方程式といった処理を含むシステムのプロパティ解析にはそれほど有効ではありません。続きを読む
形式検証手法と同様、システムのモデル（もしくはシステムの使用法）は特定の言語で開発されます。多くの仕様記述言語は種々のステートオートマタです。ほぼ常にそれらはディスクリートモデルで、微分方程式などは含まれません。従って、テストはほとんどコントローラーの特性に限られ、実世界やコントロールされる、水圧、油圧、機械システム等との相互作用のチェックはできかねます。テスト生成は多くの場合、ステートの到達度もしくはステートマシンの移行の到達度をチェックするものとなります。
TestWeaver は（フォーマルな）モデルを開発する必要はありません。モジュールはコンパイルされた（実行）形式のみが必要で、そのモジュール自体が解析されるか、それは解析対象システムに含まれます。特に、ソフトウェアにより制御されたシステムの物理量との複雑な関連がシミュレーションにより解析されます。
モデルのソース（コード）にアクセスできるのでMBTGはコードカバレッジに関して、良い情報を提供できます。TestWeaver では直接にはこの情報にアクセスできません。TestWeaver の結果はシナリオの形で保管され、テストの再現や、そこからのさらなるシミュレーションが可能となります。
- TestWeaver とテストパターン／テストベクター生成ツールとの違いは何ですか。
TestWeaver は単に、組み合わせのテストやテスト入力をランダムに作成するのではありません。TestWeaver ではシステムが入力信号に対し動的に反応し、連続的に変化する信号やステートに合わせたインテリジェントなテストシナリオが生成されます。
- TestWeaver はモジュールテスト用でしょうか、システムテスト用でしょうか？
TestWeaver はモジュールテストにも使用できますが、システムテストと検証向けのツールです。
TestWeaver はモジュールテストとシステムテストに使用できます。多くの TestWeaver を使用されているお客様はシステムテストに使われています。一つの理由は、モジュールテストでは多くの他のツールが既に存在し、それらは良い結果をもたらしているということです。例えば、それらツールはテストスクリプトを使っています。TestWeaver はテストスクリプトを使うこともできますが、現在のところはまだ各種制約があります。2009年年末に予定しているバージョン2.0ではインテリジェントなシナリオ生成に加えて、さらなるテストスクリプトのサポートを予定しています。
TestWeaver は、投資効果としては、モジュールテストに関しては他のテストツール、手法と同等ですが、大きくて複雑なシステムテストに関しては他のツール、手法に比べ大きな投資効果を得られます。
- TestWeaver はテストスクリプトツール、例えばTTCN3やPython、その他のスクリプト言語ツールやTPTのようなステートオートマタをサポートしたツールとどう違うのですか。
テストスクリプトは手動で設定、もしくは作成する必要があります。TestWeaver は手動でテストスクリプトを設定する必要はありません。
テストスクリプトツールはPythonやステートオートマタ、もしくはTTCN3といった仕様記述言語を使ってテストの組み合わせを定義することが必要になります。テストの実装はプラットフォーム毎に異なるテストケースを作成し実行します。例えば、HiLもしくはMATLAB/Simulinkなどです。各々のテストは色々な入力コントロールシーケンスやテスト目的を表現しており、それらを実行しテストがパスするのか、フェイルするのかを検証します。TestWeaver1.2 はまたPython テストスクリプトをサポートしており、また Silver のコシミュレーションプラットフォームに対応しています。手動の定義によるテスト手法はシステムの複雑度が増加した場合など、スケーラビリティに対応できません。複雑なシステムに必要な、膨大なパターン組み合わせ、また網羅率の高いテストシナリオを限定されたプロジェクトリソースで手動で作成し短期間のうちにテストするのは現実的ではなくなりつつあります。
TestWeaver は手動によるテストスクリプトの定義を行う必要はありません。TestWeaver は何千もの品質の高いテストシナリオをそれ自体で人手を介すること無しに生成できます。TestWeaver 関連する入力信号の定義のみを必要とします。
複雑なシステムになればなるほど、TestWeaver によるシステマティックなテストシナリオ生成アプローチが効果を発揮します。特に手動によるテスト定義に比べてコストメリットが大きくなります。例えば複雑なシステムの場合、全てのテスト環境で関連したテストを手動で行うすることは事実上不可能です。
- どのような種類の不具合が TestWeaver で見つかりますか？それらの不具合を見つけるのにどれだけの作業が必要になりますか。
ゼロ除算、アクセス違反等の実行時エラー検出に関して定義は不要です：期待される最小値、最大値範囲違反、フォールスフォールト検出、モデルと実装の違い等は多少の定義作業が必要です。システム固有の品質チェックにはさらなる作業が必要です。
数多くの種類の不具合が TestWeaver によって見つかります。いくつかの重要な不具合はコーディングに関するもので、その他はシステムレベルの不具合で、一つの機能もしくはモジュールだけのテストでは簡単には見つからない場合もあります。幾つかの不具合はさらに検出するために作業が必要になります。以下は TestWeaver で見つかる各種不具合で、定義作業の少ない順序にリストアップされています。
- 定義作業不要：無限ループ、ゼロ除算、アクセス違反等の実行時エラー
- 多少の作業が必要：
- コントローラーやプラントモデル信号の期待される最少-最大境界違反。例えば、高すぎる温度、高すぎたり、低すぎたりする気圧、エンジンオーバースピード、エンジンストール、A2Lデータベース内で定義された値の最小-最大境界違反
- フォールス、フォールト検出、例えば、明らかな振る舞いの違反
- モデル（MIL）と実装（SIL）間の不一致、同じモデルのバージョン間での不一致
- コントローラーのプラント状態とシミュレーションのプラント状態との不一致
- システムステート間で遷移に時間がかかりすぎる場合、例えばオートマティックトランスミッションの長すぎるシフト時間
- 特定のコントロールシーケンスの間違い：特定の実行条件間のコントローラーの発振、オートマチックトランスミッションのシフトアップ、ダウンの不要な繰り返し
- プログラミングなどのさらなる作業が必要：例えばオートマチックトランスミッションの悪いシフトパターン（運転操作ではなく、制御用のコントローラー内部自動シフト）のような複雑なシステムの特定の品質観測
- TestWeaver で自動生成されたテストのカバレッジはどのように計測するのですか？
TestWeaver はテストにより到達したシステムのステートを異なった抽象度の異なったテーブルで表示します。ソースコードカバレッジ計測ツール、例えば Testwell の CTC++ や gcov 等を使用することによりソフトウェアモジュールのソースコードカバレッジ測定が可能です。
- ユーザーは TestWeaver によるテストの範囲を決め、シミュレーションに時間がかかりすぎないようにすることができますか。
制約プログラミングにより、ユーザーは起こり得ない条件やステートを設定し、そのテストを行わないことにより、効率よくテストを行うことが可能になります。
- TestWeaver はMIL、SIL、HILのテストを生成できますか？
TestWeaver はMIL、SILシミュレーションに直接接続することが可能です。Silver の機能により、SIL テストを HILにエクスポート可能です。 TestWeaver のHIL シミュレーションの直接接続は 2009年末に予定しています。
- 幾つの TestWeaver のインスツルメント（SUT、テスト対象ソフトウェアとの接続設定）が典型的な複雑なアプリケーションで使われますか？
例えば複雑オートマチックトランスミッションコントローラーの例では約10-15のチューザー（入力用インスツルメント）が入力として、約40-60のレポーター（出力用インスツルメント）がシステムステートと品質の観測に使用されます。
- TestWeaver による解析のために、どれぐらいのシミュレーション速度が必要ですか？
多くの場合、テストは一晩もしくは週末にかけて行うのが実用的です。そういった場合、シミュレーションをリアルタイムに近い速度で実行することが推奨されます。シミュレーション速度が遅い場合、いくつかのPC使用しテストを並列に実行することを推奨します。
- 例えばインタープリタ MATLAB/Simulink モデルとコンパイルされた Real Time Workshop の様にインタープリタモデルとコンパイルされたモデルとの実行時間の関係はどうなりますか？
インタープリタモデルは通常非常に遅いものになります。複雑さにもよりますが、例えばリアルタイムに比べて100倍くらい時間かかります。モデルのコンパイルを行うと、300倍くらいのスピードアップが図れます。
- TestWeaver でのテスト時間をどれぐらい行えばよいのか、どのように決定すればよいのでしょうか？
プロジェクトによります。例えば夜間や週末に最初にシステムテストを実行し、システムステートのカバレッジ及びコードのカバレッジを解析し、その結果を後のテスト実行時間の見積もりに使用します。
- TestWeaver にどのようなシミュレーションツールが接続できますか？
直接接続できるものは、C、Dymola、MATLAB/Simulink、Real Time Workshop、Python、Silver となります。Silver を介して以下のようなさらなる接続が可能です。AMESim、SimulationX、SIMPACK、Python.
- TargetLinkを使用しているプロジェクトで TestWeaverは使用できますか？
はい。次の例をご覧ください。http://www.qtronic.de/doc/DCT_2009.pdf
- TestWeaver は直接 MATLAB/Simulink に接続できますが、MATLAB/Simulink を使っている場合、Silver でシミュレーションすることにどのような利点がありますか。
以下の利点があります。Python スクリプト；シミュレーションのフェイル；XCP, ASAP2/A2Lといった自動車 インターフェース；A2Lの最小/最大境界値自動モニター；モジュールとSUTのバージョンの違いによる違いの比較；シミュレーションの視覚化のための使用しやすいGUI；MDFもしくは CVS フォーマットによるシナリオの読み込み、書き込み；Dymola サブシステムが統合されてるときでも高速で堅牢性の高いシミュレーション；Visual Studio デバッガーへの接続等
- TestWeaver のシナリオ生成にはどのような手法や戦略が使われているのでしょうか？
遺伝的アルゴリズムからの複雑なヒューリスティック手法、モデルチェッキングの経験を活かしたゲーム理論、モデルベースの診断等です。