車載ソフトウェアにおける統合テストの実施方法(ISO 26262)
2021-04-16

ISO 26262の標準規格に則した統合テストのベストプラクティス

現場を担当するVectorCASTのフィールドアプリケーションエンジニアに寄せられる質問で最近増えているのが、ISO 26262の標準規格に則した統合テストのベストプラクティスについてです。確かに、これまで自動車業界のお客様がISO 26262に準拠するための取組みといえば、コードカバレッジを含む単体テストのみにフォーカスしたものが大半でした。単体テストの取組みといっても、その解釈は通常は自由で、複数のファイルが含まれたテスト環境でこれを行う場合もあります。  

一方、統合テストで私たちが直面するのは、この標準規格が持つもう1つの現実です。ISO 26262 Part 6 10.2には以下の記述があります。

このサブフェーズでは、特定の統合レベルがソフトウェアのアーキテクチャ設計に照らしてテストされる。そして、ソフトウェアユニットとソフトウェアコンポーネントの間のインターフェイスがテストされる。統合とソフトウェアコンポーネントのテストのステップは、ソフトウェアの階層的なアーキテクチャに直接対応しなければならない。

この後には、そのレベルで実行すべきテストと使用すべきコードカバレッジレベル、関数カバレッジとコールカバレッジの説明が続きます。しかし、統合テストが何かという正確な定義については、あいまいな部分が残っています。「ソフトウェアユニット」はどう定義されるのでしょうか。ファイルはソフトウェアユニットでしょうか。モジュールはどうでしょうか。AUTOSARフレームワーク内で動作しているアプリケーションはどうでしょうか。

今回のコラムでは、お客様に採用されてきた、考えられる2つの解を紹介します。一方の解ではサブシステムレベルで、他方の解ではシステムレベルで、それぞれソリューションが提供されます。また、組込ソフトウェアのテストソリューションであるVectorCASTを使用して、これらの解を実現する方法についても説明します。

サブシステムとしての統合か、アプリケーションレベルでのテストか

説明

「統合テストとは何のテストですか」という問いに対し、お客様から返って来るであろう答えの1つが「アプリケーション」です。このように答えるお客様は通常、コードベースにAUTOSAR OS(あるいは、以前であればOSEKの何らかのフレーバー)を実装しています。このオペレーティングシステムは多数のタスクを起動し、そしてそれらのタスクが多数のアプリケーションを起動します。このシステムには周期があり、それぞれ異なる時間間隔(10ms、100ms、500msなど)で定期的にタスクを再起動します。 

画像:RTOSの構造の簡略図
図1:RTOSの構造の簡略図

このように、このお客様の場合、タスク機能によってアプリケーションが起動されたとき、すなわちAUTOSARの「上」でアプリケーションをテストすることが最終目標になります。テストの実行は、他のアプリケーションから分離して行うか、テストするタスクはテストハーネスでラップして実行し、それ以外のタスクは通常どおり起動させるかして行います。テストが完了したらシステム全体を停止させ、その結果を収集します。

ソリューション

このようなお客様に私たちが適用するのはVectorCAST/C++を用いたソリューションです。VectorCAST/C++は1つの環境で、アプリケーション内の任意の数のユニットをテストできます。その意味でこれは単体/モジュール/統合テストのためのツールといえます。VectorCAST/C++は、その環境内のユニットの数とは無関係に、個々の関数を直接呼び出し、グローバル変数を設定してテストを実行します。そのため、このソリューションは「ホワイトボックステスト」と呼ばれます。もっとも、この「ホワイトボックス」という言葉にも複数の定義があります。

私たちが行うインテグレーションでは、お客様の本番用コンパイラーを使用し、ターゲット上でテストを実行します。これはもちろん、ターゲットがオペレーティングシステムを実行していなくてもテストを行うことができます。ただし、その場合はOS(AUTOSAR)をまず起動します。一連のタスクが初期化されると、それらのタスクのいずれかがVectorCASTのテストハーネスを起動します。VectorCASTはお客様の環境にある機能と統合され、テストの実行をモニタリングしつつ、その結果を収集します。これを実現する具体的な方法は無数にあります。その方法にはデバッガーによるポートの読取りとメモリーキャプチャーが含まれ、また、ユーザーの要求に合わせたカスタマイズも行われます。

考えられるコンフィギュレーション

このソリューションは、AUTOSARの上でテストを実行する方法を提供することにより、お客様のニーズを満たしています。コード内に存在するOSコールはどれもスタブ化されず、テストハーネスはタスクの一部として実行されます。OSは通常、お客様のニーズに合わせてカスタマイズされているため、それに対応するVectorCASTのインテグレーションもカスタマイズしなければなりません。

このようなインテグレーションはさまざまな方法で改良できますが、そういった選択肢の多くはテストのスコープと意味に影響を与えるため、ソリューションを適用する際には、VectorCASTのフィールドアプリケーションエンジニアと、以下の点を検討する必要があります。

  • テストハーネスは、テスト対象のアプリケーションを他のすべてのアプリケーションから切り離し、事実上単独で動作させるべきか。それともテスト対象のアプリケーション以外のその他のすべてのアプリケーションを、テストハーネスが起動させるべきか 
  • いくつのファイルを(スタブ化しないコンパイル済みファイル、あるいはスタブ化済みのファイルを用いずに)テスト対象に設定するか。これは、リセットの頻度が特に高いタスクをテストハーネスで動作させる必要がある場合に特に重要な問題です。テストハーネスがあまりにも複雑でテスト完了まで実行できない場合、テストは失敗してしまいます。テスト対象のファイルの数を極力少なくすればそういった恐れは減ります。また、テスト対象でないコードは、それらをコードカバレッジに含める場合でも、スタブ化する必要はありません
  • このアプローチでは、タスクを起動するファイルに変更を加えることが避けられませんが、その変更をファイルの別のコピーに加えるべきか。それとも、関連するVectorCASTコンパイルマクロをコンパイル時に提供した場合にのみそれらが有効になる条件で、それらのファイルをビルドに含めることができるか
  • 最後に、AUTOSARリンカーファイルは細かくセグメント化される傾向があり、テストハーネスの要件に適さない場合があることから、テストハーネスの多様な要求に対応できるよう、専用のリンカーファイルを開発した方がよいか

システムレベルでの統合

環境

もちろん、他方のお客様では統合テストに関する考え方がまったく異なります。これらのお客様は、統合テストは特定のアプリケーションを呼び出すことができ、常に完全なビルド上で実行する必要があると考えています。選択されたソフトウェアアプリケーションやそのセクションは、デバッガーのスクリプトやCANシグナルをはじめとするさまざまな手段で刺激を与えることにより、選択的にアクティブ化されます。システムはAUTOSARベースであってもなくてもかまいません。通常、このようなアプローチを好むのは、すでに完全なテスト環境をCANoeなどのツール内に保有しており、ISO 26262の要求を満たす目的で、まずコードカバレッジを測定したいというお客様です。そういったお客様は多くの場合、それらのテストを自動化して、たとえばソースコードの変更後直ちにテストを行うなど、もっと頻繁にテストを実行したいとも考えています。

ソリューション

このようなお客様には、VectorCASTのもう1つのモジュール、VectorCAST/QAを適用します。VectorCAST/QAは単体テストツールであるVectorCAST/C++と同じコードカバレッジ機能を備え、修正なしでお客様のビルドプロセスを利用できるため、操作をシームレスに行うことができます。VectorCAST/QAはカバレッジ取得用のコードを埋め込み、コンパイルしてテストを実行します。そして、一旦すべてのテストを実行した後は、ソースコードの変更に従って、どのテストを再実行する必要があるのかを判断します。これは変更ベーステストと呼ばれる機能で、これによってリグレッションテストの作業に要する時間を短縮できます。このアプローチは手動テストでも使用できます。

このようなタイプのテストは「ブラックボックス」とも呼ばれます。これは、現場で利用されるものと同じ環境を使用してコードが実行されるためで、そのため関数を直接呼び出す必要はありません。ただし、ここではより正確を期すために、「グレーボックス」テストがあることもお話ししておきましょう。というのは、VectorCAST/QAはプローブポイントを使用してソフトウェアの戦略的な場所にテストコードのステートメントを挿入し、実行に変更を加えることができるのです。これによって特殊な状況下でのテストを簡素化できます。

コードのスティミュレーションに関しては、使用するツールなどのお客様のニーズについて検討する必要がありますが、それに加えて、メモリーとタイミングに対するコードカバレッジの影響についても検討することが大切です。コードカバレッジによって、プログラムには追加の演算が必要になります。そのためソフトウェアの実行が遅くなり、それが実行中のトラブルの原因となる場合もあります。ただし、VectorCAST/QAなどのツールは通常、フットプリントを減らし、複数のシステムの要求に適合できるように、高度に最適化されています。しかも、VX1000プローブのようなベクターの他の製品を利用すれば、システムの安定性を維持できるだけのスピードでデータを取得できないケースにも対応できる場合があります。このアプリケーションについては、別のコラムで説明します。
 

まとめ

どちらのアプローチにもそれぞれのメリットがあります。サブシステムのアプローチは非常に柔軟です。しかも、ユニットレベルで開発したテストケースを統合テスト環境で再利用することも可能です。ですから、お客様はテストケースを単体テスト、モジュールテスト、統合テストというように段階的に再利用して時間を節約できるだけでなく、テスト対象コードの量ができるだけ少ないうちにバグを発見することもできます。実際、ユニットレベルで発見したバグは、そのレベルで捕捉し、解決するのが理にかなっています。もっと大規模かつ複雑な環境でバグが発生するまで待っていれば、デバッグと修正のプロセスが長くなり、効率は低下します。

その一方で、システムテストのアプローチには非常に大きな優位性が1つあります。それは、すべてのお客様が既にシステムテストを日常的に実施しているという事実です。そのため、それをISO 26262の統合テストの要求に合わせて拡張すれば、非常に効率的だと考えられます。ただしその際には、変更ベースのテスト自動化などの、さらなる自動化の実装を検討することをお勧めします。これによってテストツールは、ソースコード、あるいは要求やテストなどのその他の種類の変更に基づいたテストだけを再実行することが可能になります。VectorCAST/C++とVectorCAST/QAはどちらもこの変更ベースのテスト機能を備えています。そのためどちらのアプローチでもこれを利用できます。

最後になりましたが、現時点ではどちらのアプローチが最適かを決定する法則は存在しないことをお伝えしておかねばなりません。実際、両方のアプローチを一緒に使用することもできますし、他にはハイブリッド型のアプローチも可能です。

詳細についてはこちらからお問い合わせください。

関連トピック

はじめての単体テスト

単体テスト、単体テストの効率化について解説している資料です。

詳細はこちら
ソフトウェア開発のライフサイクルを通してテスト作業を自動化

VectorCASTはC言語、C++に対応した組込の単体テストを自動化するための単体テストツールです。

詳細はこちら
導入事例|VectorCAST(日本精機株式会社)

フルグラフィッククラスター制御の単体テストにVectorCASTを採用

詳細はこちら
ホワイトペーパー|組込ソフトウェア開発を効率化する変更ベーステスト

VectorCASTのホワイトペーパー「組込ソフトウェア開発を効率化する変更ベーステスト」をダウンロードいただけます。

詳細はこちら
ホワイトペーパー|医療機器のテスト

世界的な医療機器/医療用品メーカーのお客様との間で先日完了したサービス案件について詳しく説明します。

詳細はこちら
ホワイトペーパー|バグの修正および防止コストの定量化

このホワイトペーパーでは、テストの効率向上に使用できる手法を取り上げます。

詳細はこちら