GAIO CLUB

2004年11月04日

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

GAIO CLUB 特集
GAIO CLUB【2004/11月号】
開発の工程全体で総合的にソフト品質を上げる膨大なテスト工数を自動化で削減する
~開発初期段階でのモジュールテスト・評価の有効性~


組み込みソフトの大規模化に伴い、「ソフトウエア品質」を如何に管理、維持するかは、組み込み開発の最も大きな課題の一つです。ソフト品質を上げるための手段として、例えば、コーディング規則の作成など開発手法の標準化、ソフト評価ツールの導入などが行われています。今回の特集では、開発工程のピンポイントでなく、工程全体を見回す視点から、ソフト品質向上の手法を考えてみたいと思います。

大規模化するソフト開発の課題

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

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

ソフトウエアの基礎「モジュール評価」の重要性

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

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

コーディング時のソース評価

もっと単純なソフト評価と言えば、メンバー間のレビュー会議や、開発マネージャによるソースコードのレビューです。しかしながら、全てのソースコードをトレースすることなど、物理的に不可能なケースがほとんどです。大量のソースコードに埋もれてしまうと、単純な条件分岐のミスコーディング、メモリ確保のミスでさえも発見できないことがあります。
  • この状況に対応するために、ソースコードをフローチャートや構造図などに可視化するリバースCASEツールや、ソースを解析してエラーを発見するSQA(ソフト品質保証)ツールを導入するケースが多くなりました。これらは、単純なコーディングミスを機械的に洗い流したり、ソースを見ているだけでは気が付かない、モジュールの構造上の問題などを「早期の段階で」発見するのに有効です。

膨大な工数を強いるモジュール単体テスト

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

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

工数をかけない品質保証はテストの自動化から

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

CSVファイルでテスト対象入力データを指定

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

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

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

システム動作テストも自動化

組み込みシステムで頻繁に発生する不具合に、システムへのイベント発生タイミングによるものがあります。例えば、ボタンの連続押しや多重割り込みやなどがそれに当たります。このような現象は例外動作的なものが多く、実機を用いたテストでは再現性が低く、テストができないまま製品がリリースされるケースも多くあります。
  • これにも「シミュレータ」の活用が非常に有効です。実時間で動く実機では起こしにくい微妙なタイミングでも、シミュレータであれば、イベントの発生タイミングをシナリオ化するだけで、故意に例外的な条件を発生できます。コマンドを送受信するだけの部分であっても、コマンドの組み合わせ、順序、時間間隔などを網羅的に準備しておき、シミュレータならではのバッチ処理により、人手をかけないテストが可能です。

最後に

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

人気のコラム

最新のコラム