テストの種類・機能/大容量データ/高負荷/利用性/セキュリティ/性能/記憶領域
システムテストカテゴリの読み替えと取捨選択
この記事では、”The Art of Software Testing “ に載っている15種類のシステムテストカテゴリを組み込みソフトのテストカテゴリとして使うために必要になる読み替えや取捨選択について、グータラ親父の考え方を紹介します。 この記事では、機能テスト、大容量データテスト、高負荷テスト、利用性テスト、セキュリティテスト、性能テスト、記憶領域テスト について紹介します。
Facility （機能）テスト
仕様書や取扱説明書に乗っている機能が搭載されている事を確認する最も基本的なテストカテゴリですので、組み込みソフトのテストカテゴリとして基本のテスト項目ちして使います。Function テストと呼ぶ場合もありますが、”The Art of Software Testing " では Function テストはシステムテストの前段階に行う単機能のテストの名前に使っているので、混同しないように Facility テストという呼び名が使われています。 ですので、グータラ親父もシステムテストのカテゴリとして Facilityテストという名前を使っていました。機能が搭載されている事の確認なので、正常な操作を行った時に仕様書や取扱説明書に書かれている機能やサービスが問題無く提供される事を確認する、正常系のテストを実施します。
Volume （大容容量データ）テスト
大容量のデータを処理できるかを確認するのが Volume テストですが、グータラ親父は組み込み系ソフトのシステムテストカテゴリとしては、使っていませんでした。サーバ系のソフトの場合は大容量の入力データを扱えるかという確認のために Volume テストというカテゴリは必須です。組み込み系ソフトの場合も、大きなデータが通信路経由で入力された時に処理ができるかという観点のテストが考えられます。しかし組み込み系システムでは多くの場合、大きなデータというと長時間に渡って連続して入力されるデータになります。そして連続した入力データに対する動作の確認は、通常の機能の確認の中で実施されるテスト含まれる事が多いです。このよう、組み込み系システムでは Volume テストが Facility テストの一部に含まれる事が多いので、多グータラ親父はシステムテストではこのカテゴリは使っていませんでした。
Stress (高負荷）テスト
日本語にすると高負荷テストや過負荷テストと呼ばれるのが Stress テストです。Volume テストが大量のデータを扱えるかの確認なのに対して Stress テストはデータや処理のピーク負荷時の動作を確認するためのテストです。例えば文書の作成を例にすると、大量の総ページ数の文章を処理する機能の確認は Volume テストですが、1分間に大量のページ数の文書が処理できるかを確認するのが Stress テストです。
機器の制御や通信など担う事の多い組み込み系ソフトでは、負荷のピーク時でも確実に動作する事が大切ですので、この Stress テストはしっかりと実施する必要があります。組み込み系のシステムテストでは、負荷の種類を洗い出した上でそれぞれの負荷について最大の負荷を与えた時の動作を確認するテスト項目をが必要です。 これらのテストケースを Stress テストというテストカテゴリで設計して実施する必要があるので、システムテストカテゴリとしても必須です。
Usability (利用性）テスト
装置を使う人にとって使い易いかという観点で利用性を確認する Usability テストは Web GUI を持つ事が多くなってきた組み込み系ソフトでも必要性が高いです。最近の装置では、いろいろな設定をエンドユーザが確認したり設定したるするためのユーザインターフェースとして、ブラウザベースの GUI が採用される事が多くなってきました。 画面の見やすさや設定値の入力のし易さ、間違えた値を入れた時のエラー表示の判り易さなど、いろいろな面での使いやすさを確認しておく事が、組み込み系ソフトにも重要になってきています。組み込み系のソフトでユーザインターフェースが全くない機器であれば Usabilityテストは不要ですが、最近は何等かの GUI や CUI をもつ装置が多くなっていますので、組み込み系ソフトのシステムテストカテゴリとして Usabilityテストは必要です。
Security （セキュリティ）テスト
別の記事でも書きましたが、セキュリティテストは最近の組み込み系ソフトにとって非常に重要なテストになってきました。組み込み系ソフトがその中に大量の重要なデータを持つ事は少ないので、情報漏洩という観点では、組み込み系システムにはセキュリティリスクはあまりありません。しかし IoT の広がりでインターネットに常時接続される機能が搭載される事が増えてきた現状では、装置が乗っ取られて他者への攻撃拠点に使われるというリスクが高まってきています。これらのサイバー攻撃に対応する能力を持っているかを確認しておっくために、Security テストというテストカテゴリはがシステムテストに必須です。
Performance （性能）テスト
性能を確認するのが Performance テストです、機能を確認する Facility テストと並んでシステムテストの最も一般的なテスト項目ですので必須のテストです。 特に組み込み系のソフトではヒューマンインターフェースだけではなく、他のコンピュータとのインターフェースや制御や監視の対象となる機器とのインターフェースを持っている事が多いです。
これらの人間でない相手とのインターフェースは、相手の応答速度や性能とつり合いが取れないといけないので、性能や応答性が髭仕様どおりに出ているのかを確認する Performance テストはとても大切です。性能を確認する時には、単位時間あたりの処理量（通信速度やトラザクションの処理速度）だけではなく、応答性能についても確認を忘れないようにする事も大切です。
制御系のようなハードリアルタイム（一定の期間内に処理が実施される事を保証する必要があるリアルタイムシステム）では特に処理性能と応答性確認が重用です。例えば、自動車のアンチロックブレーキを制御する制御ソフトならば、どんな状況にあっても必要なブレーキ制御を必要な応答性で実施しなければなりません。そのような事を確認するのが Performance テストですので、組み込み系ソフトのシステムテストとしてこのテストカテゴリは必須です。
Storage (記憶領域）テスト
Storage テストはコンピュータシステムに備わっている記憶装置の記憶領域の制御ができているかどうかを確認するテストです。コンピュータには一次記憶（電源が切れると内容が消える記憶領域）と二次記憶（電源が切れても内容が維持される記憶領域）がありますが、どちらもその記憶容量は有限です。記憶領域の容量が有限なので、使う記憶容量を制御する機能がソフトには必ず組み込まれています。
パソコン等では、十分な容量の記憶装置が備えられている場合が多いのと、ＯＳが記憶容量の制御をしているので記憶容量の制御についてあまり意識する事あはありません。しかし組み込み系では限られた容量の記憶装置を効率的に使って処理を進める必要があるために、様々な記憶容量の制御をする必要が出てくるので確認が大切になってきます。
例えば代表的な一次時記憶装置である主メモリについての簡単な Storage テストは、動的メモリの残量管理機能の確認です。残量の確認機能やメモリの獲得/解放機能、これらの機能を組み合わせて実現される残メモリの上限/下限の確認やそれを超えた場合の処理などが、動的メモリの残量管理機能としてソフトに実装されています。 これらが正常に動作している事を確認するのが主メモリ上の動的メモリに対する Storage テストになります。動的メモリのリークの有無を確認するメモリリークテストも、この動的メモリに対するテスト中の１項目です。
組み込み系システムの場合二次記録装置としてフラッシュメモリを搭載している場合も多いです。ここに何等かのファイルシステムを搭載して、プログラムそのものを記録したり、エラーログを記録したりします。フラッシュメモリに対する Storage テストは、例えば大容量のログファイルの書きこみテスト、などです。 フラッシュメモリの現時点の空き容量を超えるサイズのファイルの書き込みが発生した時に、ソフトはどのような動作をするのが正しいのか、その動作を確認すうるのが、フラッシュメモリに対する Storage テストです。
Storage テストはもともとは大型計算機の外部記憶装置であるハードディスクに対する情報記録機能を確認する事を目的としてテストですが、組み込み系システムでは一時記憶装置や二次記憶装置の記憶容量の制御機能に焦点を絞って考える事で、システムテストに必要なテストカテゴリとして扱っています。