クリティカル・システムに使う市販ソフトウェアの検証方法(3) ―― 検証記録に含めるべき事項を考える

●市販ソフトウェア検証記録の準備

　市販ソフトウェアの検証記録に含めるべき事項を列挙します．

• 報告書の管理番号（報告書作成側で文書管理されている必要がある）
• 報告書の発行日
• テスト対象物の製造業者名と所在地，連絡先
• テスト対象の品名および型式（対象物を特定する情報）
• テスト対象のソフトウェア・バージョン（内部で分割されている場合は，バージョン・リストも書く）
• 判定基準（テスト計画書やテスト仕様書が別に存在する場合は，その管理番号を書く）
• テスト担当機関と試験場所
• テスト結果（判定基準に適合しているのかどうか）
• テスト実施日と承認日
• テスト実施機関の名称，ロゴ，責任者の署名

　市販ソフトウェア検証記録を提出文書としてまとめるときのドキュメント構成の例を，図3に示します．テスト計画書とテスト報告書の両方にサマリ（要約）を付けていることに注目してください．

図3　市販ソフトウェア検証記録の構成例
μITRON仕様のリアルタイムOSに関する検証記録の事例．リアルタイムOSを共通部とデバイス依存部の二つに分け，さらにテスト計画のサマリとテスト結果のサマリを作成している．

　ある程度の大きさのソフトウェアに対して網羅性の高いテストを行うと，テスト記録はA4サイズで数千ページになることがよくあります．そのようなテスト結果を積み上げて提出すると迫力はありますが，評価者は中身を見る気になりません．

　そこで重要になるのが，テスト計画のサマリとテスト結果のサマリです．テスト計画のサマリにはテストの考え方や方法，テストの範囲，網羅性に関する方針などについて，テスト結果のサマリには，どんな種別のテストをいつ誰がどこで実施し，どのような問題があったのか，何を修正したのかを記載します．そうすれば，テストの評価者は，まず20ページ程度のテスト計画のサマリとテスト結果のサマリを眺めて，テストの全体を見渡した上で，気になった部分についてチェックすることができます．

　また，テストの結果を手書きで記載した場合は，生データを保管した上で，清書したテスト結果を提出します．テスト・ツールを使った場合は，ツールそのものの妥当性確認（CSV：Computerized System Validation）も行っておきます．検証記録は，テスト結果の評価者が見やすい形で，また，嘘がないことを証明できる状態で，作成・提出することが重要です．

●検証記録に必要なこと

　検証記録を作成するにあたっての必要条件を以下に示します．

• テスト仕様，テスト手順，判定基準が明確であること（テストの基本）
• 誰が実施しても，同じ試験結果になること（再現性）
• 検証記録が，いつ，誰によって証明・保証されたのかが分かること（保証・担保）

　ソフトウェアの検証記録の場合，ソフトウェア全体やソフトウェアの構成要素を特定するためのバージョン情報，および構成管理情報も重要です．これらは「再現性」の必要条件に含まれます．対象となるソフトウェアが改変されてしまった場合，以前のソフトウェア検証記録はそのままでは使えません．改変部分の検証と，改変が他へ影響を与えていない根拠を示す必要があります．

　そういった意味で，ソフトウェア検証記録は1回作ったら終わりではなく，ソフトウェアのテスト環境も含めて繰り返し利用する再利用資産である，と認識した方がよいでしょう．

●リアルタイムOSの検証で考慮するべきこと

　リアルタイムOSを検証する際には，以下の点を考慮する必要があります．

• リアルタイムOSの仕様は明確か（μITRON仕様など，何らかの仕様に準拠しているか，バージョン，カスタマイズの有無）
• リアルタイムOSの機能のうちどこまでを製品に使用するのか
• リアルタイムOSの何をテストするのか（テスト計画の作成．できるだけ早い段階で行う）
• 機能仕様に対するテストの設計（性能に関するテストは別途作成する）

　対象製品に使わない機能については，検証する必要はありません（他の機能に影響を与えないという条件付きだが）．例えば，200あるリアルタイムOSのシステム・コール（サービス・コール）のうち使っているシステム・コールが20だった場合，残りの180のシステム・コールについては機能テストを行う必要はありません．リアルタイムOSによっては，実装されるカーネルのサイズを極力小さくするため，使用していないシステム・コールのコードをビルド時に実装しないことがあります．その場合は特に，外されたシステム・コールが実装コードに影響を与える可能性はありません．

　ただし，リアルタイムOSの検証結果を幅広く再利用しようと考えている場合は，注意が必要です．Aプロジェクトでは使用していなかったシステム・コールをBプロジェクトが使用していた場合，両方のプロジェクトで検証結果を利用するつもりならば，両方のプロジェクトで使用しているシステム・コールのすべてをテストする必要があります．また，設計変更時に別のシステム・コールを使うような場合も同じです．

　このようなことを考えると，リアルタイムOSの検証記録については，OSベンダから全体を網羅したものを提供してもらえると最も合理的といえます．この際には，リアルタイムOSの取扱説明書に記載されている機能をすべて検証した記録があった方がよいでしょう．また，システム・コールのパラメータの一つ一つに範囲がある場合は，それらの境界値に対するテストが実施されているべきです．