【単体から実機検証まで】V字モデルで理解する組み込み開発のテスト工程と品質保証
近年の組み込みシステムでは、高度な制御やIoT連携が不可欠となり、ソフトウェアの品質が製品の価値を左右するケースも珍しくありません。
しかし、高度化した現代の組み込み開発において、あらゆる条件下での正常動作を証明し品質を担保するには、膨大なコストがかかるのが現実です。
そこで本記事では、テストの重複や漏れをなくし効率的に品質を担保するために、各テストレベルが果たすべき本来の役割と、限られたリソースの中で品質保証を実現するための考え方について解説します。この記事を読めば、組み込み開発における各テスト工程の役割と、何をもって品質を保証したといえるのか、という品質管理の考え方が理解できます。
V字モデルによる品質保証の考え方
V字モデルにおけるテスト工程とは、単にバグを探す作業ではありません。その役割は、設計フェーズで定義した内容が正しく実現されているかを証明することです。
設計通りであることを証明するための仕組みがトレーサビリティです。トレーサビリティとは、要件から設計、テスト結果までの履歴をいつでも追跡できる状態を指します。
V字モデルが左右対称の形をしている理由は、トレーサビリティを表しているからです。各テストレベルは、特定の設計フェーズと以下のように一対一で対応しています。
- 単体テスト ⇔ 詳細設計：個々の関数の内部ロジックを検証
- 結合テスト ⇔ 基本設計：モジュール間のインターフェースや連携を検証
- システムテスト ⇔ 要件定義：製品全体がユーザーの要求を満たしているかを検証
組み込みソフトウェアの場合、ハードウェアとソフトウェアの結合が必要になりますので、それぞれの単体テストの後、それぞれを繋いだ際も結合テストを行うことになります。これらの対応関係によって、何を根拠にこのテスト結果を合格としたのか、という裏付けが取れます。その結果、複雑化したシステムにおいても、根拠に基づき確信を持った製品リリースが可能になります。
テストを段階的に分ける理由
単体テスト、結合テスト、システムテストとテスト工程を段階的に分ける理由は、不具合発生時における原因の切り分けを最速で行い、デバッグ工数を最小限に抑えるためおよび、それぞれのフェーズで品質を確認しながら進めることで、品質を積み上げるように作り上げていくことができるためです。
組み込みソフトウェアのシステムは、ハードウェア、OS、デバイスドライバ、ミドルウェア、アプリケーションが複雑に絡み合っています。実機テストからいきなりテストを開始した場合、不具合が発生した際にアプリケーションのロジックミスなのか、通信タイミングのズレなのか、ハードウェアの回路不良なのかなどを特定することは困難です。
不具合の特定工数を削減するために、まずは単体テストで最小単位における正常動作を確実に担保し、段階的に検証範囲を広げていきます。あらかじめ単体モジュールの品質を保証しておくことによって、「どこまでが正しく動いているか」がわかるので、後工程で問題が起きた際の切り分けが容易になり、最小限の調査工数に抑えられます。
各テストレベルの役割と検証ポイント
V字モデルにおける各テストレベルは下記の通りです。
- 単体テスト
- 結合テスト
- システムテスト
それぞれのテストが担う具体的な役割と、品質を保証するためのポイントについて解説します。
1.単体テスト
単体テストは、モジュール単位で内部ロジックが詳細設計通りに正しく動作することを証明する工程です。
詳細設計で決めた複雑な条件分岐や計算ロジックに不備がないか、カバレッジ（テストの網羅度を測るための指標値）を確認しながら徹底的に検証します。単体テストの段階で論理的なバグを出し切ることにより、その後のテストでは個々のモジュールが正常に動作することを前提に進められます。
2.結合テスト
結合テストは、複数のモジュールを組み合わせた際に、基本設計通りに正しく機能するかを証明する工程です。
モジュール単体では正常に動作しても、複数のモジュールを結合した際に、データの型の不一致や割り込みタイミングによるデータの上書きといったトラブルが起こりえます。
特にリアルタイムOSを用いる構成では、排他制御の不備によるデッドロックや、優先順位の逆転現象などが発生しがちで、そういった観点のテストを重点的に行うことで、品質を向上させることができます。
モジュール単体では正常に動作しても、複数のモジュールを結合した際に、データの型が合わない、割り込みのタイミングによってデータが上書きされる、などのトラブルは起こりえます。特にリアルタイムOSを用いる構成では、排他制御の不備によるデッドロックや、優先順位の逆転現象などが発生しがちです。
モジュール同士の連携を確認しておくことにより、最終段階であるシステムテストでは、製品全体としての振る舞いやハードウェア制約への適合といった検証に専念できるようになります。
3.システムテスト
システムテストの役割は、要件定義で定められた機能やセキュリティなどが、基準を満たしているかを証明することです。
長時間稼働によるメモリリークの有無や定格電圧の限界値における動作、ノイズ環境下での耐性など、過酷な実環境を想定したテストを行います。ユーザー視点での機能確認だけではなく、組み込みシステム特有の非機能要件に対する検証も重要なポイントです。
システムテストで発覚した不備は、設計の根本が崩れている可能性を示すため、非常に深刻な意味を持ちます。そのため、早い段階で不備や問題を見つけることはプロジェクトを予定通り進める上で重要になります。不具合を再現させることも、不具合を修正することも開発フェーズが進めば進むほど時間がかかるようになります。なるべく早いタイミングで品質を作り上げていくことが重要です。
テストではハードを含めた実機検証が不可欠
最終的な品質保証には実機による検証が欠かせません。PC上でのテストでは再現できない実機ならではの不具合が存在するためです。
実際に起こる不具合としては、周辺機器からの物理的な干渉やタイミングのズレに起因するものが挙げられます。たとえば、プロセッサにおけるキャッシュの挙動や周辺回路の待機時間によってミリ秒単位のズレが生じ、そのわずかな差が原因で数万回に一度のタイミングで割り込み処理が重なりシステムがフリーズする、あるいは外部からの通信による割り込み処理によりCPUの処理時間がとられ、リアルタイムな動作ができなくなるなどといったトラブルです。
その他にも、ソフトウェアのロジック自体は正しくても、隣接するモーターが回転した瞬間に発生する逆起電力や電磁ノイズが通信線に入り込み、不具合を引き起こすといった事態も考えられます。このようなトラブルは、事前に仮想環境で検証することは困難です。
想定外の挙動による製品の不具合を未然に防ぐためにも、実機検証による品質の裏付けは欠かせません。こういった、ハードウェア起因の不具合が起こりうる、ということが組み込みシステムの特徴であり、ソフトウェアのテストについても、汎用ソフトと異なる検証が重要な理由になります。
テストはバグ探しでなく品質を証明する工程
テスト工程の完了とは、設計した全項目を漏れなく確認し、合格のエビデンスをそろえた状態を指します。主要な機能が動作しているからこれ以上の検証は不要だろう、といった主観的な判断でリリースの可否を決めるべきではありません。
複雑化したシステムにおいて、感覚に頼ったリリースは市場での致命的な不具合を招く可能性があります。あるべき品質保証とは、要件定義の段階であらかじめ決めておいた検証項目をすべてパスした、という客観的なエビデンスを積み上げることです。
客観的なエビデンスを提示し、やるべきテストをやり切ったと可視化することが、限られたリソースの中で品質を担保した製品のリリースへとつながります。