テストの種類・構成/互換性/インストール/信頼性
システムテストカテゴリの読み替えと取捨選択
この記事では、前の記事に続けて ”The Art of Software Testing “ に載っている15種類のシステムテストカテゴリを組み込みソフトのテストカテゴリとして使うために必要になる読み替えや取捨選択について、グータラ親父の考え方を紹介します。この記事では、構成テスト、互換性テスト、インストールテスト、信頼性テスト について紹介します。
Configuration (構成）テスト
日本語にすると構成テストです。大型コンピュータシステムの場合にはハードやミドルウエアソフトの組み合わせでいろいろなシステム構成がとれるので、仕様に書いてあるどんな構成でも動作する事を確認するのがこの構成テストの目的です。 組み込みシステムの場合には装置の構成はほぼ固定されているので、構成テストの必要性はそれほど大きくはありせん。ただし、最近の組システムは単独でサービスを提供するのではなく、様々な下位装置や上位クラウドと繋がってサービスを提供する事も増えてきました。
このような場合に大切になってくるのは、接続する下位装置や上位クラウドとの相互接続性（インターオペラビリティ）の確認です。例えば、下位装置として USBで外付けハードディスクを接続したり、上位クラウドとして特定のサーバと通信したりする事で、本来のサービスを提供するという場面も増えてきました。このような場合には、接続する下位装置や上位クラウドとの相互接続の確認テストを十分にやっておかないと、実際の運用でうまくいかなくなります。
ですので、グータラ親父はこの Configuration テストは下位装置や上位クラウドとの相互接続性のテストと読み替えて、システムテストカテゴリとして使っていました。
Compatibility （互換性）テスト
互換性を確認するのが Compatibility テストです。これももともとは大型コンピュータシステムの場合にはシステムを構成するミドルウエアソフトやアプリケーションソフトのバージョンが変わった時に、それまでと同じように動作する事を確認するテストとして考えられていました。大型コンピュータシステムでは、多くのソフトウエアを搭載しているので、個々のソフトウエアのバージョンが変わる事もよくあり、その場合の動作を確認するのが Compatibility テストです。
組み込みソフトの場合には、内部に搭載しているミドルウエアなどのバージョンが変わる事はそれほど頻繁には起きないので、もともとの目的での互換性の確認は重要性はわりと低めです。しかし組み込み系システムの場合には、別の互換性の重要性が出てきます。それは、組み込み装置自身の互換性です。
組み込み装置それ自身は、いろいろな理由から新規のバージョンの装置に置き換わる事があります。例えば、AAA通信装置 という装置を販売していたのが主要部品が製造中止になったので、主要部品に別のメーカの物を使って New-AAA通信装置 という新しい装置を開発して後継機種として販売する事を想定してください。 この場合、New-AAA通信装置がもともとの AAA通信装置 に対してどのレベルの互換性を持っているのかを明確にしておく必要があります。互換性のレベルには特に明確な定義は決まっていないのですがグータラ親父は、完全互換性と上位互換性と互換性無しの３つに分けていました。
完全互換性は、色々な設定や基本的な性能やエラーが起きた時の動作まで完全に AAA通信装置 と同じように動くという定義です、この場合には顧客は AAA通信装置を New-AAA通信装置に単純に置き換えて運用しても何も問題は起きません。完全互換性の場合には、応答性などの性能やエラー時の処理も含めて前機種の AAA通信装置と同じになっている事を確認するのが互換性テストの目的になります。
上位互換性は、機能としては同じものが搭載されているのだけど、設定方法に少し違いがあったり性能が向上していたり前の機種には無い機能が増えていたりする場合の定義です。この場合には顧客は AAA通信装置を New-AAA通信装置に置き換える前に運用側で設定の変更や確認をする必要がでてきます。設定方法が変わっていれば新しい設定方法に合わせて設定のマニュアルを変更しなければいけないかも知れませんし、性能が向上していた場合には AAA通信装置 との間で設定していたタイムアウトの値を New-AAA通信装置に合わせて見直さないといけないかも知れません。上位互換性の場合には、何が変わっていて何が変わっていないのかがとても重要なので、変わった内容と変わっていない内容を確認するのが、互換性テストの目的になります。
互換性無しの場合にはそもそも互換性テストは必要なくて新しい New-AAA通信装置としての他のカテゴリのシステムテストをしっかりやれば良いですね。と言う事で、Compatibilityテストはシステムテストのカテゴリとして必要です。
Installation （インストール）テスト
インストールテストは大型計算機でソフトをシステムにインストールする操作についてのテストです。既存のソフトをバージョンアップする場合や新しくソフトを追加する場合など、様々な場面でのソフトのインストール作業が必要になるのですが、それらのインストール作業が様々なシステム構成でちゃんと動作する事を確認するのがインストールテストです。
組み込み系システムの場合には、装置や機器が工場で製造される時にその内部に必要なソフトが予め書きこまれるので、運用現場でインストール作業が行われる事はあまりありません。 ですので、グータラ親父は Installation テストのテストカテゴリは使っていませんでした。
Reliability (信頼性）テスト
信頼性テストはちょっと注意が必要なテストカテゴリです。そもそもシステムテストも含めて殆どのテストはソフトの信頼性を確認するために実施しているので、その中で改めて信頼性を確認するという目的のテストカテゴリを作ると他のテストとの違いが判らなくなってテスト設計が混乱してしまうかも知れないからです。この Reliability テストというテストカテゴリは、信頼性についての当別な要求事項があった時に、その要求事項が満たせているかどうかを確認するのが目的です。
では特別な要求事項とはどんな物でしょうか？ 例えば 「24時間365日必ず動作する事が必要」というような信頼性が明確に要求仕様に入っていた場合、これは信頼性に対する特別な要求事項になります。これを実現するためには、少なくとも様々な設計レベルでの２重化が必要になります。電源系、バックプレーン、ラック、基板、ソフトウエアシステム、通信経路 などの様々なレベルでハードやソフトや通信の故障が起きても、別系統を使って動作を続けるように２重系が設計されているはずです。この２重系がちゃんと構築され設計どおりの動作ができているのかを確認する事で、特別な信頼性に対する要求事項が達成されているかどうかを Reliability テストで確認する必要があります。
そこまで高い信頼性を求めれれていなくても、例えば１年間でのシステムのダウンは１回以下で１回のダウンタイムは10分以下とうように、具体的に信頼性の要求事項が定義されていた場合でも、これは信頼性についての特別な要求事項です。ソフトの視点で考えれば１年回に１回以上ハングやリセットが起きない程度の安定性を、様々な加速試験で確認したり、ハングが起きてもウォッチドック機能でこれを検出して再起動で復旧したり、再起動が発生した時には10分以内にサービスの提供が可能な状態に復帰したり、という信頼性を保証するテストが必要になります。このような、特別な信頼性についての要求事項を確認するのがReliability テストというシステムテテストカテゴリです。
Reliabilityテストは信頼性に関する特別な要求事項がある時にだけ検討するテストという条件が付きますが、システムテストのカテゴリとして必要なテストです。