ソフトウエアのテスト自動化を進めよう

多くの製品開発のソフト検証工程では、試作した製品モデルを手に、大所帯のデバッグチームが実際に操作して、不具合を見つける作業が行われています。これは一般に「ブラックボックステスト」と言われています。ハードウエアを操作してその場で起こる現象をデバッグしているわけですから、ソフトウエアが持つ実行パスのうち、正常動作系のパスに重点が置かれたデバッグになっています。

しかしながら、どんなに人数を注ぎ込んでデバッグしても、市場で不具合が見つかるケースは多くあります。これは、実機によるブラックボックステストでは、テストできないケースがあると言うことです。不具合の多くは、正常動作系ではなく、例外動作系にあると言われています。

ソフトウエアの例外処理部分がテストされていれば、このような不具合は起こらない訳ですが、実機による正常動作系に偏ったブラックボックステストでは、例外処理を起こすことができないため、テストパターンから漏れてしまうのです。

全てをテストしていない製品を市場に出荷してしまうと言うことは、「運が悪ければ」市場で不具合が発生してしまうと言うことです。市場で不具合が出ていないケースでも、単に「運が良いだけ」ではないでしょうか？

例外処理も含めたソフトウエアの実行経路を全てテストできれば、このような運を天に任せるような話はなくなり、ソフトウエアの品質を保証できることになるのです。

実機でのテストできない例外処理をテストする方法の１つが「シミュレータ」による動作検証です。シミュレータは、マイコン自身の動作や、外的なハードウエアの振る舞いなどをソフトウエアで実現するため、例外動作を起こしたり、ソフトウエアをモジュール単位に動作させたりすることができます。

ハードウエアの試作モデルのように、ソフトウエアがROMに実装されたブラックボックステストでは出来ないことが、簡単に行えるようになります。

ソースコードレベルで、関数、タスクなどのモジュールが見える形で行うテストのことを「ホワイトボックステスト」と呼んでいます。シミュレータを使用して、ホワイトボックステストを進めることが、ソフトウエアの品質向上に、ダイレクトにつながります。

ガイオの立場からご紹介できる範囲の実例として、ガイオがリリースしているクロスコンパイラ製品の品質保証の手法をご紹介します。

皆様の開発する組み込みソフトとは明らかに分野が異なりますが、クロスコンパイラ製品もソフトウエアであり、この品質をどのように保証しているかは、組み込みソフトのテスト手法へつながる所も多くあると思います。

クロスコンパイラに限らず、ガイオのクロス製品のテスト工程は、完全に自動化されています。もちろん、コンパイラ開発当初は自動化されたテストシステムはありませんでした。このテストシステムは、20数年に渡りコンパイラを供給し続けてきたことから生まれた資産、ノウハウに他なりません。

自動化する前のテスト方法とは、テスト用のCソースを用意し、これを開発したばかりのコンパイラでコンパイルし、生成したオブジェクトをブレッドボードで実行し、実行結果が期待値通りになるかを、目視で確認すると言うものでした。新しいマイコン用のコンパイラを新規開発した場合、テストだけで、約12人月の工数がかかっていました。

現在では、この一連のテスト作業を、シミュレータを用いて自動化しており、新規のコンパイラを開発した場合でも、1週間1台のPCを回しっ放しにするだけで、自動的にテスト結果を出力するようなシステムになっています。

工数から見れば、自動化システムの導入で、1/50の工数で、しかも確実なテストが可能になったわけです。

下の図は、コンパイラ開発のフロー図です。開発した新しいマイコン用のコンパイラ・アセンブラをテストするステップは、まず、資産化されたテストデータ、すなわちテスト用のソースコードを開発したコンパイラでコンパイルし、オブジェクトコードを生成します。

次に、このオブジェクトコードをシミュレータで実行します。しかしながら、新しいマイコンのコンパイラを開発している時点では、当然そのマイコン用のシミュレータも完成しておらず、同時並行か、先行して開発されています。

テスト用のソースコードには、printf()文に相当するものが入っており、実行結果をログファイルに出力できるようになっています。

全てのテスト用ソースコード（数千ファイル）をバッチファイルで一括処理して、ログファイルを作成します。コンパイラには多くのコンパイラオプションがありますので、これを変えながら、繰り返しテストをすることになります。この工程には、PCを回しっ放しで1週間以上かかります。 出力されたログファイルの結果を、期待値ファイルと比較して、期待値と食い違う部分をレポートする仕組みとなっています。期待値ファイルは、1から作成しているわけではなく、既に品質が保証を終えたマイコンのコンパイラで作成されたログファイルを活用しています。

コンパイラとシミュレータを同時開発していますので、テスト結果がＮＧとなった場合、両方の開発者に情報をフィードバックして、開発担当同士で原因の切り分けを行っています。

テスト期間中は、開発者はテストの作業から解放されるため、バグフィックスの作業や、ソフト更新、デバッグの作業を行うことができます。

テスト用のソースコードは、20年来書き貯めたものであり、コンパイラ品質を確認するためのガイオの資産となっています。まれに、この自動テストをパスしたコンパイラでも不具合が見つかることがあり、これは、新しいテストパターンとして、テスト用ソースコードに順次追加しています。

組み込みソフトの検証においても、シミュレータを使用してソフトウエアの実行ができる環境が整えば、ガイオのコンパイラテストの場合と同様に、テストの自動化を行うことができます。

特に、実機を使ったデバッグでは決して出来ない、関数、タスクと言ったモジュール単位でのカバレッジテストや、if文が深くネストした複雑な条件分岐を含むソフトの実行パスカバレッジなども、その条件を故意に起こすシナリオをシミュレータに設定するだけで、容易にテストすることができます。

ソフト開発過程において、ソフトウエアを修正・更新した場合、前のバージョンでは動いていた機能が動かなってしまう、いわゆる「レベルダウン」に対する保証テストなどは、自動化テストにより、同じシナリオをシミュレータにかけるだけですので、非常に効率的にソフトウエアの品質を保つことができます。