テストの種類・RAS の機能テスト
重要な RAS の機能は専用のテストで動作や品質を確認する
RAS機能のテストとは Reliability（信頼性）, Availability（可用性）, Serviceability（保守性）を確認するテストです。RAS機能の定義の仕方も色々ありますが、グータラ親父はRAS機能の定義とそのテストを、おおまかに以下の様に考えてきました。
- Reliability（信頼性）：故障などでサービス停止が起きにくい能力なので、色々な故障を起こしてその時の動作を確認する
- Availability（可用性）：サービスを提供し続ける能力なので、再起動時間や定期保守の時間等サービス停止時間を確認する
- Serviceability（保守性）：故障時の調査・回復の能力なので、調査用のログ機能や遠隔保守機能を確認する
RAS機能のテストはセキュリティテストと合わせて、最近になって重要性が高くなってきた機能についてのテストです。どちらも、ソフトがエンドユーザに提供するサービスに直接関する機能ではなくて、ソフトが常に安定してサービスを提供するための非機能要件に相当する裏方的な機能です。なので、ソフトの要求仕様などに明確に書かれていない事もあるのでテストの設計時には注意が必要です。とはいえ、組み込みシステムではテスト設計にいくつか工夫が必要な箇所もありますので、実際のテストの内容やテスト設計での注意点について、この記事で紹介してみましょう。
RAS の機能ってそもそも何でしょう
RAS の機能とは、Reliability, Availability, Serviceability の頭文字をとった略語ですが、日本語にすると信頼性、可用性、保守性ですね。Reliability（信頼性）は故障などによるシステムの停止や機能不良が起きにくい性質を指します、要するにいつも安定して動く性能ですね。Availability（可用性）は信頼性と似ているのですが、こちらはシステムの稼働率の高さや障害や保守による機能停止の短さを指す性質です、簡単に言えばいつでも使える性能です。そしてServiceability （保守性）は故障などからの復旧のし易さや速さを示す性質です、故障しても直ぐに治る性能の事ですね。これらのRAS機能の動作を確認するのが、RAS 機能テストになります。
組み込みシステムの信頼性（Reliability）
組み込みシステムで信頼性（Reliability）をテストするには、どんな観点でのテストをすれば良いのでしょうか。信頼性とは故障によるシステムの停止や機能不良が起きにくい性質の事ですので、テストとしては色々な故障を起こしてみて、その時にシステムが停止したり機能不良になったりせずに、稼働を続ける事を確認するようなテストをすれば、信頼性を確認する事ができます。良く似たテストには、故障回復性のテストがあります。
故障回復性は、予めシステムに実装されている故障回復機能が正常に動作している事を確認するテストになるので、信頼性テストの準正常系と考える事もできます。とすると、信頼性テストの異常系は想定されていないよううな故障やエラーが発生した時に、システムが停止したり機能不良になったりしない事を確認するテストとなります。
信頼性のテストはそれ単独でテスト設計をしても良いのですが、信頼性テストで実施するテストの内容は準正常系テストや異常系のテストと殆ど同じでになる場合が多いです。例えば装置のハードウエアに故障が起きた場合を想定した信頼性のテストを考えてみましょう。ハードウエアが経年劣化してしまい、ソフトからのコマンドの実行指示に対し時々エラー応答がかえってくるという故障状態を考えます。ソフトではハードウエアからエラーが返され得たら３回を限度にリトライにを試す仕様で作られていると想定します。
この場合、ハードウエアの故障を１回発生させてソフトがリトライによる回復を試みて無事に機能が動作する事を確認するというテストと、ハードウエアの故障を連続して３回発生させてソフトがリトライによる回復失敗と判断してエラー処理を行う、という２つのパターンで信頼性試験を設計する事になります。
ところでこの２つのテスト内容は、実はハードウエアが故障してエラーを返してきた時のソフトの動作を確認しているので、ハードウエアを制御するという機能の視点から見ると、予め決められたエラーに対する処理を確認する準正常系のテストと見る事もできます。
この例のように、信頼性のテストはそれ単独で考えるよりも、通常の機能テストの中で実施する準正常系と異常系のテストに含まれるとみる事もできます。テストの内容や合否案断の基準は同じでも、そのテストをある機能の準正常系の確認を目的としたテストとみるか、信頼性のテストと見るか、２通りの見方があると考えて不必要なテストの重複は避けるように注意する必要があります。
組み込みシステムの可用性（Availability）
組み込みシステムで可用性（Availabiity）を考えるのは、少しやりにくいです。可用性とは、システムが使える割合を示す性質で、システムの稼働率などで表す事もあります。例えば、１年365日のうち、毎年12月31日にはまる１日を掛けて保守作業があるので使えないという仕様のシステムを想定します。このシステムの可用性は 稼働率で表すと (365日-1日）/ 365日なので 99.7% です。 このシステムの可用性のテストはどんな物になるかというと、何時でも使える性能、つまりは保守によるシステムの停止が仕様通りの１日で済む事を確認するテストになります。ですので、実際に保守作業を実施してそれが１日で終わればテスト合格ですが、例えば保守作業の中で行うデータのバックアップ量が多くてバックアップがおわらなくて１日で保守作業が終わらなければ、可用性のテストは不合格です。
このように、可用性が仕様として明確になっているシステムだとその仕様に従って可用性のテストが実施できます。でも、組み込みシステムでは多くの場合 24時間 365日動き続ける事が前提の場合が多いです。すると、24時間365日動き続ける事を確認するテストをしようとしても、いつまで経っても合格なのか不降格なのか結果が出せません。このように、24時間365日の稼働が前提の組み込むシステムでは、本来の意味での可用性のテストが考えにくいです。
そんな場合は少し視点を変えて、システムが使えない状況が起きた場合の回復までの時間がどの程度かを確認する事で、可用性のテストを考える事ができます。例えば、システムがハングアップしてウォッチドック機能によるシステムのリセットが実効されて再起動による回復処理がおこなわれる場合を想定します。リセットから再起動まで 1分で終わるシステムと60分かかるがあったとすると、1分で再起動が終わるシステムのほうが使えない時間が短いので、可用性は高いと考えられす。こう考ると、ウォッチドッグによるシステムの回復時間が仕様書に記載されていたら、その時間内に再起動が終わるかどうかを確認するというテストは可用性のテストになります。 もし仕様書に回復時間が書かれていなくても、類似の装置と比較して回復時間が長いか短いかを比べる事で可用性の良し悪しを測る事もできます。
このように、組み込みシステムで可用性のテストを考える時には、システムが使えなくなる時間に着目するとテストの項目が見えてきます。
組み込みシステムの保守性（Serviceability）
組み込みシステムの保守性を考える時には、大きく２つに分けて考えると判り易くなります。一つは不具合の原因を調査するための機能で、もう一つは不具合に対応するための機能です。この保守性の機能についても、要求仕様書に明確に書いてあればその内容を確認する事で保守性をテストする事ができます。しかし保守性の機能が要求仕様書に明確に書いていない時には、保守機能の有無や使えるかどうかを保守性についてのテストで確認する必要があります。
原因調査のための保守性の機能とそのテスト
組み込みシステムが市場で問題を起こした時に、その不具合が社内で再現できるかできないかで、その後の対応の難しさが変わります。問題の発生条件が明確に判っていて社内で再現できると、いろいろな調査の方法が使えるので、短時間で原因が判りソフトの不具合修正やその効果の確認も素早く済ませられます。しかし残念ながら組み込みシステムの市場問題では、発生の条件が不明だったり機器の動作環境に依存したりして、社内で不具合が再現できない事も良くあります。
この様な場合に備えて、組み込みシステムでは不具合の原因を調査するための情報を記録しておく機能を予め搭載しておくという方法がよく使われます。一般にエラーログや動作ログと呼ばれるログ機能や、カーネルダンプと呼ばれるOSの持つ不具合発生時の状態保存機能です。エラーログにはどんな種類のエラーが何回発生したのかを記録するカウンターログや、何時何分にどんな種類のエラーが起きたのかを順次記録していくイベントログがあります。カーネルダンプは Unix 系のシステムが標準で持っている、問題が起きた時のカーネルの様々な状態をスナップショットとして残してくれる機能ですね。
これらの、原因調査のための情報は、①問題が起きる直前までの状態を表す情報として収集され ②問題が起きた時にはそれまでに収集された情報がどこかに記録され ③その情報がソフトエンジニアの手元まで届けられて ④ソフトエンジニアがその情報を解析して、初めて問題の原因調査に役に立ちます。
原因調査のための保守性機能のテストでは、問題が発生した時にこの①から③までの機能が予定どおりに動作して、情報が無事にソフトエンジニアの手元に届く事を確認します。 例えば、エラーログがDRAMに記録されていた場合には、問題が起きた直後に自動再起動でDRAMの内容が消えてしまうと、②の機能がちゃんと動作しない場面が発生してしまいます。このような事態が起きるような場合は無いか、保守機能のテストでは様々な場面を想定して確認します。
不具合対応のための保守性の機能とそのテスト
市場で不具合が起きた時にはその原因の調査も大切ですが、まずは市場にある製品の機能を回復してエンドユーザに対するサービスの提供を再開させる事が、より優先されます。装置自身の自動回復機能が働いて機能が復帰すれば一番良いのですが、そうでない場合もあります。この様な場合には、管理センターから市場にある装置をリモートで操作して回復処理を試みるなどの遠隔保守の操作をする場合も多いです。このような遠隔保守の機能が不具合対応での保守性の機能になります。
もちろん、遠隔保守に必要な機能が装置に実装されている事が前提ですが、一般的には①装置の状態を確認する ②装置の設定を書き換える ③装置のファームウエアを書き換える ④装置を再起動する 等の機能が搭載されている場合が多いです。
これらの遠隔保守の機能は、装置がエンドユーザに提供するサービスに直接関係する物でもなく、また装置が問題なく動作している時には使われる事も無い機能です。つまりは、装置の表舞台にはあまり出てこない裏方の機能です。しかし、一旦装置が市場で不具合を起こした時には、これらの機能は必ず安定して動作してくれないと、不具合の対応ができなくなるで困ります。言い換えると、遠隔保守の機能はその他の機能よりも一段高い品質が求めれられる、という事になります。
ですので、不具合対応のための保守性の機能をテストする場合には、その機能がどんな場面でも安定して動作するかにつて、特に注意して確認する事が大切です。