製品出荷前のテストにおいて、「組込み制御ソフトウェア」の「不具合」の原因を、早く見つけるためには、確実に正しい部分と怪しい部分を、上手く切り分けることが必要です。そのためにできる工夫として、「ソフトウェア設計での工夫」と、「ソフトウェア開発プロセスでの工夫」があります。
まず、「ソフトウェア設計での工夫」ですが、「組込み制御ソフトウェア」は、アプリケーション処理（アルゴリズムの計算処理）部分の他に、ハードウェア依存処理（デバイス入出力処理部分、サンプリングの周期を実現するCPU周辺処理）部分があります。ハードウェア依存処理部分が適切に動作するかどうかの確認には、組込みハードウェアが必要です。一方で、アプリケーション処理部分は、工夫次第で、組込みハードウェアが無くても、動作確認することができます。また、ハードウェア依存処理部分の動作確認は、組込みハードウェアがあれば、実際のアプリケーション処理部分がなくても、ダミーの処理を使えば実施できます。このように、あらかじめ、それぞれ独立して、各部分が正しく動作することを確認しておくことで、「不具合」の原因探索を、未確認部分に絞り、効率化を図ることができます。
ここで、前の章で説明した、データ更新のタイミングを、ソフトウェア開発者側で明確に管理できていることが、「組込み制御ソフトウェア」の各部分の独立した動作確認を可能にします。一方で、割込み処理の動作タイミングで、勝手に計算処理に使うデータが更新されるような構造になっている場合は、実際の割り込みが入る組込みハードウェアが必要となります。これでは、計算処理の動作確認に実際の組み込みハードと、実際の動作環境が必要になり、この状況は、全てのシステムが統合された最終のテストフェーズでないと実現できません。これでは、「不具合」発生時の問題の切り分けが難しく、時間がかかります。
なお、ここでは、製品出荷前のテストを短期間終わらせる目的で、動作確認に組み込みハードが必要な部分と、必要ない部分に分けるという、ソフトウェア構造を決めています。
次に、「ソフトウェア開発プロセスでの工夫」について、説明していきます。
ここで言う「プロセス」とは、ソフト開発の工程のことを指しており、プロセスでの工夫とは、単に、製品出荷前のテストより前に、「不具合」が無いことを確認するためのテストを行うことです。
事前に実施するテストとして追加するのは、前に取り上げた、ハードウェア依存処理部分と、アプリケーション部分の、それぞれのテストです。
規模が大きい「組込み制御ソフトウェア」では、アプリケーション処理の規模も大きくなるでしょう。その場合、アプリケーション処理部分だけでも「不具合」が無いことや、結果が正しいことを確認することは、簡単でなく、時間がかかります。そういった理由で、アプリケーション処理部分のテストが不十分なままにしておくと、ソフトウェアのデバッグが困難な製品出荷前のテストで「不具合」が見つかった場合、原因が見つからずに苦労することになります。そのため、アプリケーション処理部分のテストを効率良く実施するため、アプリケーション処理を、テストが簡単な単位（関数）で構成し、それぞれテストして、「不具合」が無いことを確認しておきます。つまり、アプリケーション処理のテスト工程の前に、アプリケーション処理を構成する関数単位のテストを実施します。こうして、テストプロセスをさらに追加します。
なお、ここでも、ソフトウェアの「不具合」の発見が容易になるよう、テストが簡単になるレベルまで、ソフトウェアを関数として分割するよう、構造を決めています。
