アプリケーションをテストする



LabVIEW 2018ヘルプ


発行年月: 2018年3月
製品番号: 371361R-0112
製品情報を参照

ダウンロード (Windowsのみ)


LabVIEW 2015ヘルプ
LabVIEW 2016ヘルプ
LabVIEW 2017ヘルプ
LabVIEW 2018ヘルプ
LabVIEW 2019ヘルプ

まずプロジェクトに必要なテストのレベルを決定します。厳しいスケジュールを与えられているエンジニアは、テストよりも開発に時間をかける傾向があります。テストのレベルを決定することで、確実に時間を節約できます。

開発者は、決定されたテストのレベルを明確に理解している必要があります。また、テストの手法が標準化され、結果が追跡できる状態でなければなりません。要件と設計仕様を作成する際に、システムとそのすべてのコンポーネントの動作を検証するためのテストプランも作成してください。テストは、目標とする品質を実現するためのものでなければなりません。たとえば、堅牢性よりも性能が重要である場合は、性能のテストを増やし、入力の誤りやメモリ不足の是正を目的としたテストを減らします。

テストは、後から思いつきで行うものではありません。テストは、最初から設計段階の一部と見なし、開発プロセス全体を通して実行して早急な問題の検出と解決に役立てる必要があります。

テストには様々な手法があります。VIプロジェクトの品質を向上させるには、以下のテスト手法を取ることができます。

スタティック/ダイナミックコード解析

スタティックコード解析とは、ソースコードと事前に決定されているスタイル、構成、品質を比較するための手法またはツールを指します。スタティックコード解析では、アプリケーションをコンパイルまたは実行する必要はありません。

メモ  スタティックコード解析は、LabVIEW VI Analyzer(VIアナライザ)ツールキットを使用して行うことができます。

ダイナミックコード解析とは、コードの実行テストなどによってソフトウェアの実行時の動作を理解するためのツールを指します。ダイナミックコード解析には、ブラックボックステストとホワイトボックステストを使用できます。ダイナミックコード解析では、メモリリークとパフォーマンス改善の余地を検出し、不正な動作やエラーの原因を特定し、アプリケーションが各ターゲットで同様に動作することを確認します。ダイナミックコード解析を行うには、パフォーマンスおよびメモリをプロファイルウィンドウを使用します。

メモ  また、Desktop Execution Trace(デスクトップ実行トレース)ツールキットを使用することもできます。

ブラックボックス/ホワイトボックステスト

ブラックボックステストは、ソフトウェアの内部の働きには注目せず、必要な機能が動作するかをテストするものです。このテストは、内部の動作には注目しないことからブラックボックステストと呼ばれます。ブラックボックステストは、要件とモジュールインタフェースに関する知識を元に行います。サブVIに対するブラックボックステストでは、サブVIのインタフェースで様々な値を入力して結果を検証します。堅牢性が品質の目標である場合は、不正な入力データをサブVIが正常に処理するかどうかを評価します。たとえば、サブVIが数値入力でInf(無限)、NaN(非数)、その他の範囲外の数値を正しく処理するかを確認します。

ホワイトボックステストは、ソフトウェアの内部構造に注目します。ホワイトボックステストを使用して、主な実行パスがすべて正常に動作するかを確認します。ブロックダイアグラムでケースストラクチャの条件とループの制御値を確認することで、それらのパスを検証するためのテストを設計できます。すべてのパスを検証することは難しいため、大規模なホワイトボックステストは実用的ではありません。

ホワイトボックステストは、大規模なプロジェクト全体に適用することは難しくても、最も重要なパスや、最も複雑なパスに対して行うことは可能です。ホワイトボックステストとブラックボックステストを組み合わせることで、ソフトウェアを全体的にテストすることができます。

単体/統合/システムテスト

ブラックボックステストとホワイトボックステストによって、ソフトウェアのあらゆるコンポーネント(個々のVIまたは完全なアプリケーション)をテストできます。プロジェクトの単体テスト、統合テスト、システムテストには、ブラックボックステストとホワイトボックステストを適用できます。

単体テスト

単体テストでは、個々のソフトウェアコンポーネントをテストします。たとえば、個々のVIに対して、正しく動作するか、範囲外のデータを正しく処理するか、パフォーマンスが正常か、ブロックダイアグラムの主な実行パスの実行とパフォーマンスが正常かをテストします。単体テストは、各開発者がモジュール開発中に実行できます。

単体テストでは、一般に以下のような点に注目します。

  • 各入力の境界値(空の配列または文字列、サイズ入力での0という値)。浮動小数点数パラメータでInfNaNが正常に処理されるか確認します。
  • 各入力の無効な値(サイズ入力での-3という値など)
  • 不正な入力の組合せ。
  • ファイルの欠落や不正なパス名。
  • ユーザがファイルダイアログボックスでキャンセルボタンをクリックした時の動作。
  • ユーザがVIを中断した時の動作。

VIを完全にテストするために必要な入力の組み合せを決定し、それらの入力のさまざまな組み合せでVIを呼び出すテストVIを作成し、結果を確認します。対話的データログを使用して、入力のセット(テストベクトル)を作成し、それらを対話的に取得してVIを再テストします。または、プログラム的にデータログを行うテストVIから自動的にデータを取得することもできます。

単体テストを実行するためには、未実装のコンポーネントや開発途中のコンポーネントのスタブを作成する必要がある場合があります。たとえば、一人の開発者が計測器と通信してファイルに情報を書き込むVIを作成し、別の開発者が特定の形式で情報を書き込むファイルI/Oドライバを作成する場合が想定されます。コンポーネントを早い段階でテストするためには、ファイルI/Oドライバと同じインタフェースを持つVIをスタブとして作成します。このスタブVIによって、データを確認しやすい形式で書き込むことができます。実際のファイルI/Oドライバは、後期の実装段階においてテストします。

また、LabVIEW VI Analyzerツールキットを使用して、VIのスタイル、効率性、その他のLabVIEWプログラミング関連事項を、対話的またはプログラム的に検証することもできます。

どのようなVIのテスト方法においても、手順、タイミング、テストの対象を正確にドキュメントに記録し、作成したテストVIをすべて保存する必要があります。このテストドキュメントは、顧客向けまたは社内向けVIを作成している際には特に重要です。VIを修正する場合は、既存のテストを実行して、何も壊れていないかを確認してください。新しい機能を追加した場合はテストも更新する必要があります。

統合テスト

統合テストは、ユニットの組み合わせに対して実行します。単体テストで、通常ほとんどのバグが見つかりますが、統合テストで予期せぬ問題が明らかになることがあります。個々のモジュールが組み合わされると、予想どおりに動作しない場合もあります。個々のモジュールの共有データの扱い方により、予期しない方法で相互作用する可能性もあります。

メモ  統合テストは、LabVIEW開発システムとLabVIEWプロフェッショナル開発システムでのみ実行できます。

また、システム全体を統合する前に、初期の段階で統合テストを行うこともできます。たとえば、計測器と通信するVIのセットを開発者が作成する場合、各サブVIが正しく適切なコマンドを送信することを検証するための単体テストを作成するだけでなく、予想しない相互通信がないことを検証するために、それらのサブVIのいくつかを互いに組み合わせて統合テストを作成することもできます。

総合テストと統合テストは異なるものとして認識してください。(総合テストは、すべてのコンポーネントを統合してトップレベルのプログラムをテストする過程です。)大規模なVIのセットから問題の原因を特定するのは困難なため、この方法はコスト高になる可能性があります。代わりに、トップダウン、またはボトムアップのアプローチで、少しずつテストすることを検討してください。

トップダウンアプローチでは、スタブとして実装されているシステムの下位コンポーネントをテストすることで、主要コンポーネントを徐々に統合します。既存のコンポーネントが既存のフレームワーク内で正常に動作することが確認できたら、新たなコンポーネントを追加します。

ボトムアップアプローチでは、下位モジュールのテストから開始し、順に上位モジュールへと移行します。まず、ドライバテストのように、単純なシステムとして組み合わされた少数のコンポーネントをテストします。複数のモジュールの組み合せが正常に動作することが確認できたら、コンポーネントを追加してデバッグ済みのサブシステムでテストします。

ボトムアップアプローチでは少しずつテスト範囲を広げ、トップダウンアプローチでは新しいコンポーネントを追加するたびに詳細なテストを行います。

どのアプローチを取るかに関わらず、各ステップで回帰テストを行い、以前にテストした機能が現在も機能することを検証する必要があります。回帰テストでは、以前に行ったテストの一部、またはすべてを繰返し行います。同じテストを何度も実行する必要がある場合、そのテストで頻繁に利用するテストをまとめたテストを作成することを検討してください。このテストは各段階で使用することができます。問題が発生した場合には、より詳細なテストを行って各モジュールのセットをテストします。または、開発中に周期的に行われる詳細な回帰テストの一部として、より詳細なテストを行ってもよいでしょう。

システムテスト

システムテストは、システム統合後に、製品が顧客の要求を満たしているかどうかを判断し、ハードウェアを含めたシステム全体で期待どおりにソフトウェアが動作することを確認するために行います。システムは、ブラックボックステストによって要件を満たしているかを検証することができます。システムテストでは、ソフトウェアが設計どおりにシステム全体に組み込まれているかどうかを確認します。多くのLabVIEWアプリケーションは、何らかのI/Oを実行し、他のアプリケーションと通信します。必ず、アプリケーションと他のアプリケーションとの通信のテストを行ってください。

システムテストでは、次の点に注目します。

  • パフォーマンス要件を満たしているか。
  • 作成したアプリケーションが他のアプリケーションと通信する場合、そのアプリケーションの予期しない不具合にも対処できるか。

信頼性テストでは、最後にアルファテストとベータテストの両方を行います。アルファテストおよびベータテストでは、開発者が考慮していなかった部分や、未完成な部分を発見することができます。アルファテストでは、機能的に完成した製品を社内でテストし、なんらかの問題が発生しないかをチェックします。ベータテストでは、アルファテストの完了後、現地で顧客が製品をテストします。

アルファテストとベータテストは、一部の企業にとっては唯一のテスト手段となっています。しかし、アルファテストやベータテストは実際、不正確な場合があります。そのため、これらのテストは、各コンポーネントを厳しくテストし、それが規定の目的を満たしていることを検証する他のテストの代わりにはなりません。また、このタイプのテストを開発プロセスの後の段階で行う場合、提案された変更点を統合することが難しく、結果として、コストがかかります。

正式な検証方法

テスト手法には、問題を試行錯誤によって検出するものもありますが、多くのソフトウェアエンジニアはソフトウェアの正式な検証を実施します。正式な検証方法では、ソフトウェアの正確性を数学的に証明します。

原則として、プロジェクトの各関数を解析によって予想どおりの動作をするかを検証します。関数の前に一連の事前条件を、関数の後に関数の結果として後条件を、数学的に記述します。このプロセスは、プログラムの始めに開始して各関数に順に条件を追加するか、プログラムの最後に開始して各関数に対して最も弱い事前条件を作成して逆の順番で処理します。検証プロセスの詳細については、サードパーティリソースを参照してください。

このタイプのテストは、ループと条件の使用によってより多くの実行パスがプログラムに追加されるため、複雑になります。正式なテストは、ソフトウェアに関する興味深い結果を得ることができ、小規模なケースでの問題発見に役立ちますが、多くのプログラムにおいては実用的ではありません。



この記事は役に立ちましたか。

役に立たなかった