概要・組み込みソフトのテスト品質を良くするのに重要なテスト項目のいろいろ
組み込みソフトの安定性や堅牢性の改善に効果のある重要なテストのいろいろ
組み込み系ソフトは24時間365日の安定動作が求められるので、特に注意して実施しておくべき重要なテスト項目もあります。メモリリークテスト、タイマのロールオーバテスト、複数機能の同時実行テスト、起動時の準正常系テスト、二次記憶の劣化テスト、高負荷エージングテスト、品質の悪い通信路でのテスト、など組み込み系ソフトとして実施しておいた方が良いテストについて紹介します。
ソフトのテストについては世の中にも色々な図書やWebページの公開情報があります。ただし、ソフトという括りで検索してみると判るのですが、どうしても開発件数の多い Web 系のソフトや企業の基幹系ソフトのテストを主体にした情報が多くて、組み込みソフトの品質に特有のテストについての情報は余り見かけません。
組み込み系ソフトと言っても対象は広いのですが、グータラ親父がこれまで経験してきた制御系や通信系の組み込みソフトを例に、品質を確保するために役立ちそうな具体的なテストについて少し紹介してみます。皆さんがテストを考える時の参考になれば幸いです。
なお、テストの分類については別の記事で紹介していますので興味のあるかたはそちらをご覧ください。この記事分類とそれに続く記事ではもう少し具体的なテストについて紹介します。この記事ではテストの概要を紹介し、各々の記事ではもう少し詳しく紹介していきます。
メモリリークテスト
動的メモリがリークしていない事を確認するテストです。必要な時にOSから獲得して使い終わったらOSに返却するような、動的メモリ（Dynamic Memory）を使っている場合には必須です。メモリリークが起きていると、電源投入してから暫くは正常に動作していたのがある時期から急に不具合を起こす時限爆弾バグの元になるのでテストによる検出が大切です。
メモリ以外の動的資源リークテスト
動的メモリと同じように、必要になったら獲得して使い終えたら返す動的資源には、アプリ内で管理している登録・削除機能のあるテーブルのエントリや、OSから獲得する通信のためのソケットやあります。これらも、リークがあると時限爆弾バグとなるのでテストが必要です。
タイマーやカウンタのロールオーバーテスト
時限爆弾バグの原因として動的資源のリークと双璧をなすのがタイマーのロールオーバー処理に潜むバグです。タイマーは符号なしや符号付の整数の変数で値が保持されますが、その整数の最大値を超えてカウントアップしたり、最小値を超えてカウントダウンしたりという事が起きた時に、正しく処理するコードが無いと不具合が起きます。
複数機能の同時実行テスト
単体の機能を使っている時には問題が無くても、機能Aが動作している最中に機能Bを使うと不具合が起きる、というのもわりと良くあります。ソフトの処理で、機能Aと機能Bとが同じ内部処理Cを呼び出している場合に、処理Cの排他制御にバグがあったりするとこのような事が良く起こります。単体の機能を確認するテストでは見つからないので、複数機能の同時実行を意識したテストが必要になります。
起動時テストには準正常系と異常系を加える
起動時には、各種の設定の確認や内部制御変数の初期化やサーバとの接続など、通常あまり動かない処理が沢山実行されます。通常あまり動かなくて起動時にしか動かないような処理は、普通の機能テストや安定性確認テストでは実行される機会が少ないので、あまり検査されません。また、起動時に何等かのエラーが起きて起動に失敗してしまうと装置が使えないので影響が大きくなります。ですので、起動時テストでは異常系や準正常系にも加えた十分なテストが必要になります。
フラッシュメモリやHDDなどの二次記憶装置の劣化テスト
組み込み装置で一般的な二次記憶装置としては、フラッシュメモリやハードディスクがあります。どちらの二次記憶も内部ではデータが消える事を前提としたエラー回復機能を組み込んであるので、外から見た場合にはエラー無しでデータの読み書きができている様に見えます。しかし実際にはエラーの増加によるアクセス速度の低下や書いた情報の消失が起こる事があります。そのような状況でのソフトの安定性を確認するためには、わざとエラーを起こり易くした二次記憶装置を用意して、二次記憶装置の劣化テストをしておく事が大切です。
高負荷エージングテスト
通常不可での長時間エージングテストとは別に高負荷でのエージングテストも潜在不具合の洗い出しには効果的です。高負荷の時と通常不可の時とで何が変わるかというと、処理に組み込まれた負荷の均一化のための仕組み、例えば処理待ちキュー（処理時間を散らしてピーク負荷に耐える）やキャッシュ機能（先に延ばせる処理を先に延ばしておく）などの処理が大量に動作するという部分です。これらの、高負荷になって初めて大量に実行される箇所の潜在バグを洗い出すには、高負荷エージングテストが欠かせません。
品質の悪い通信路でのエージングテスト
他の装置や機器との通信がある場合には、当然その通信を使う機能のテストは実施されると思います。そのテストで使う通信路については、正常な通信路とは別にエラーが多発したり伝送遅延が起きたりするような品質の悪い通信路をテスト環境に使ったエージングテストも実施しておくのが良いです。テストを行うテスト作業室の通信路の環境は特に注意しなければ非常に綺麗な通信路になります。一方で、実際の本番環境では通信路長も長く周囲から飛び込むノイズもあり、通信路の品質がかなり悪い場合もあり得ます。そのような通信環境での動作の安定性を確認するのが、品質の悪い通信路でのエージングテストです。
ハードウエア資源半減テスト
組み込みソフトは予め定められたハード資源（CPUの性能やメインメモリの容量や通信速度等）を前提として設計・制作・テストがされています。ハード資源に十分な余裕があれば良いのですが、コストパフォーマンスを追及する製品開発の場合、結構ぎりぎりのハード資源でソフトを動かす必要が出てくる場合もあります。このような場合には、ちょっとした動作環境の変動や入力量の変動で、ハード資源が不足するような状況が起こり得ます。そんな時にもソフトがバングしたりせずに安定して動作を続けられるかどうかを確認するには、予めハード資源を半減ささた環境で動作確認をするという手があります。
ハードウォッチドッグテスト
組み込み系装置の場合CPUのハング等を検出しリセットにより回復を試みるハードウォッチドッグ回路が組み込まれている場合が多いです。ハードウォッチドッグ回路の設計項目の中で重要なのは、何をハートビート信号（CPUがハングしていない事を確認する信号）にしているのかと、どんな手段で回復を試みるか（ソフトリセットかハードリセットか電源Off/On か）です。これらの、ハードウォッチドック回路の重要な設計項目が設計どおりに動作しているのかを確認しておかないと、実際にハードウォッチドッグが発生した時に思ったような回復処理が動かない事となり、かなり被害が大きくなります。
ソフトウォッチドッグテスト
ある程度規模の大きなマルチタスク/マルチスレッドのソフトの場合には、ソフトの機能ごとにソフトウォッチドッグ機能を実装する場合もあります。ソフトウォッチドッグ機能は、ソフトの機能毎に決められたハートビート処理（処理がハングしていない事を確認する処理）を監視し、機能のハングアップや停止が観測されたらその機能のリセットを行う事で、他の機能への影響を最小限に抑えて問題の起きている機能の回復を図る処理を行います。そのようなソフトウォッチドッグ機能が実装されている場合には、その機能が設計通りに動作している事を確認するテストが必要になります。
タイムアウトテスト
ソフトが行う通信処理には、同じCPU内の他のタスクやスレッドを相手に行うCPU内通信処理と、他の装置や機器を相手に行う外部通信処理の２つがあります。どちらの通信処理も、通信相手が一定の時間内に応答を返さない場合にハングアップしないように、タイムアウト時間を決めてあります。タイムアウト時間が超過したら設計した内容に従ってタイムアウトの処理が動作するかどうか、タイムアウト機能の動作を確認するのがタイムアウトテストです。タイムアウト時間は、自ソフトの修正や通信相手の機器や装置のソフトの変更によって変わります。タイムアウト時間に影響のある変化があった時にはタイムアウトテストの実施が必要です。
組み込みソフトの品質保証にはいろいろなテストが必要
組み込みソフトの品質を改善したり保証したりするには、いろいろな観点でのテストが必要になります。この記事であげたのはほんの一例になりますが、皆さんがテストを考える時に少しでもお役に立てばと思います。
以下の記事では、各々のテストについてグータラ親父の経験した事を元にして、もう少し具体的に紹介していきまので、興味のある方はご覧ください。