開発の工程全体で総合的にソフト品質を上げる膨大なテスト工数を自動化で削減する

ソフトウエアは小さな関数、タスクなどのモジュールで成り立っています。大規模化するソフトウエアの開発では、必然的にこのモジュール数が多くなっています。また多数の技術者が分業をしながら開発を進めているため、開発の途中ではモジュールの組み合わせをテストすることが難しくなっています。多くの開発プロジェクトでは、各担当者が開発したモジュールの組み合わせテストは、開発がかなり進んだ段階で、実際のターゲット上で行われています。

この段階では、たとえ全てのモジュールのソースコードが揃っているとしても、ソースコードの全てを把握することは到底不可能です。結果的には、総合的なブラックボックステストを行うことになり、総合動作での不具合があった場合には、この原因を特定することがますます難しくなっています。

このような状況で、モジュールの全てを接続したソフトウエアを確実に動作させるには、モジュールを設計している段階で、前もってモジュールの品質を上げておくしかありません。モジュール単体が確実に動作することが保証されていれば、総合接続テストでは、原因の切り分けが非常に容易になります。
しかしながら、自動車業界など一部の業界を除き、ほとんどの組み込み開発では、十分なモジュール品質保証を行わないまま、これらを接続したソフトウエアとなっているのが現状です。

総合テストに入ってから、不具合の特定に何日もかかったあげく、その原因が一つのモジュール内の「ミスタイプだった」と言う話も、珍しいことではありません。

もっと単純なソフト評価と言えば、メンバー間のレビュー会議や、開発マネージャによるソースコードのレビューです。しかしながら、全てのソースコードをトレースすることなど、物理的に不可能なケースがほとんどです。大量のソースコードに埋もれてしまうと、単純な条件分岐のミスコーディング、メモリ確保のミスでさえも発見できないことがあります。

モジュールの動作にフォーカスしたテストは、「モジュール単体テスト」と呼ばれています。関数、タスクなど、モジュール間の関連が明確な小規模なグループモジュールに対して、データ入出力テストを行うのが一般的です。モジュール単体テストは、ソフト品質を上げるための基本的な手法であり、特に自動車電装品メーカーでは、古くから行われています。
しかしながら、このテストは、評価ボード上でICEを使用して手作業で行われているケースがほとんどです。関数単体にデータを与えて出力を期待値と比較すると言うテストは、手作業では膨大な時間と工数がかかるため、テストケースを最小限に絞ったり、開発の終盤でまとめて行なわれているのが現状です。

もう一つのソフト評価の基準となるテストが、「パスカバレッジ」テストです。業界では、「C0,C1,C2」というカバレッジテスト基準が設けられており、開発したソースコードの全ての行について、あるいは、全ての条件分岐についてテストを行っているかを定量的に示すものとなっています。これも、手作業でモジュールに条件を設定してテストされるケースが多く、膨大なテスト工数を必要とします。
一度モジュールのテストを行ってしまうと、後でそれに関連する関数が改変された場合でも、工数、時間的な制約から必ずしも再テストが行えるとは限らず、ソフト品質を完全に保証するのは困難であるのが現状です。

「カバレッジマスターwinAMS」は、モジュール単体自動テスト用ツールパッケージです。お使いのクロスコンパイラで作成したオブジェクトコードをそのまま使用して、ソフトウエア内の任意の関数の入出力テストを、自動実行することができます。

特にモジュール単体テストは、膨大な数の関数に対する評価の繰り返しになります。ここにかかる工数を削減するには、テストの自動化が最も有効です。しかしながら、ICEとターゲットを使用した環境では、自動化を行うのは難しく、そこで注目されているのが「シミュレータ」によるテスト環境です。
シミュレータは、マイコン動作を全てソフトウエアで動作させるため、ファイルからのテストデータの取り込みや、ファイルへの結果の書き出しが容易に行えます。また、テストの工程をシナリオ化（バッチ処理）することで、テストを開始すれば、後は終わるのを待つだけといった、完全自動化が可能です。
ただし、テストのための入力データと、結果を評価するための期待値データは、慎重に作成する必要があります。このデータはソフト品質の評価に直接関わるため、ソフトモジュールの設計と同様に重要度の高いものです。

「テストデータを自動で作ってくれないの？」という質問を受けるのですが、テストの自動化とは、テスト作業を自動化して工数をかけないための手法であり、評価基準の作成を自動化するわけではありません。一度テスト環境が構築できると、そのテストデータを使用すれば、工数をかけず何度でも繰り返しテストが行えるため、モジュールの一部が改変された場合でも、全てのモジュールを再確認することが可能です。

このような積み重ねが、結果的にシステムの品質を向上すると言えるでしょう。

組み込みシステムで頻繁に発生する不具合に、システムへのイベント発生タイミングによるものがあります。例えば、ボタンの連続押しや多重割り込みやなどがそれに当たります。このような現象は例外動作的なものが多く、実機を用いたテストでは再現性が低く、テストができないまま製品がリリースされるケースも多くあります。

面倒で敬遠されがちなモジュールテストは、結果的には総合的なソフトウエア品質の向上につながる鍵となっていることがお分かり頂けたと思います。今一度テスト工程を見直して、自動化を取り入れたソフト品質改善方法を考えてみてはいかがでしょうか？