ソフトウェア工学6 動的検証
ソフトウェアの検証
ソフトウェアの検証によって確かめる事項
– ソフトウェアの「正しさ」
– 「正しさ」を妨げるような欠陥があれば，その箇所
と原因を指摘
・ソフトウェアの正しさとは
– ソフトウェアが求められる機能を実行できる
– ソフトウェアが求められる品質を満たす
過去記事参照
検証の対象となる「ソフトウェア」
仕様 →レビュー，形式検証，モデル検査検証
文書 →レビュー
プログラム →動的検証 静的検証
動的検証
プログラムを動作させて検証する
– テスト：特定の入力を与えてプログラムを実行し想定する出力と比較
– 動的解析：実行回数の頻度（プロファイル）分布の作成と表明（アサーション）による検査
テスト（testing）
対象のプログラムを一定条件下で実行し，結果を分析する技法
上記一定の条件をテストケースという。どんな「代表」としてのテストケースを選ぶかが重要。そして、そのテストケースにおいてどのような結果が想定されるのか予測できるようなテストケースでなければならない。
テストの役割としては以下があげられる。
・故障の発見
・故障箇所の特定（あるいは「分離」(isolation)）
・結果としてディペンダビリティを向上
※故障しないことを示すことはできない。
※どこまでテストすれば、目指す品質をクリアできるか。
テストにはレベルがある。
・単体（unit）テスト： ソフトウェア部品・モジュールがその仕様通りに出来ているかを検査
・統合（integration）テスト： 部品の組み合わせに起因する故障を検査
・システム（system）テスト： システム全体での動作を検査，主に例外・異常処理，非機能要求，品質，などを対象
・受け入れ（acceptance）テスト： 顧客の要求に合致するかを確認（顧客が行う）
テストの種類もある。
・ブラックボックステスト（black box testing）： ソースコードを利用しないでテスト
・ホワイトボックステスト（white box testing）： 内部構造の解析結果を利用したテスト
・システムテスト・セキュリティテスト： さまざまな状況下であってもシステムが期待通り
に動作することをテストする。 システムの非機能要求が主な対象。
テストの心構え
バグを全部見つけるのは無理
故障（faults）は見つからないだろうという仮定のもとにテストを計画してはならない。
自分で作ったのプログラムをテストしてはならない。
プログラムのある部分で故障が見つかると、近いところで故障が発生することが多い。
どの部分に故障が出やすいか，そこにどのようなテスト手法を適用すれば品質・ディペンダビリティの向上が効率よくできるかを知る
テストの成熟度
参考：Beizer, B: Software Testing Techniques
レベル０
– テストとデバッグに差がない
レベル１
– テストの目的は，ソフトウェアが動くことを示すこと。（自分が望んだ通りに動くか？）
レベル２
– テストの目的は，ソフトウェアが動かないことを示すこと（売り物のソフトウェアの最低レベル）
レベル３
– テストの目的は，ソフトウェアが動かないことによる危険性を許容範囲まで減らすこと
レベル４
– テストは行動ではなく，ことさら意識してテストを行わなくとも品質の高いソフトウェアを作るための「精神的規律」（レベル３が意識しなくてもできる）
テストケース（test cases）
少ないテストケースで、多くの故障を検出したいため、故障やエラーの検出効率を高くする。
– 入力
– キーボードやインタフェース機器からのデータ
– ファイルやデータベースからの読み出し
– データ到着時のシステム状態
– システム実行環境（環境変数）からのデータ
– 出力
– インタフェース機器へのデータ
– ファイルやデータベースへの書き込み
– システム状態や実行環境（環境変数など）に対する変更
期待される実行結果（出力）を決定するには以下のような考え方がある。
・回帰テストのテストケース
– 過去のテストケース結果を比較する。システム開発は大半が既存システムの追加開発のため。
・正当性が実証されたデータ
–数式やテーブルなどの仕様記述から，正しく導出されているデータと比較。
・市販のテストケース
– 法改正に伴って行う消費税の計算のテストなど。需要が多いものは販売がある。
・ 既存のプログラム
– 以前のバージョンのプログラムを同時に動かして比較。
– 実行の順番
– 順番通りに行われるべきテストケース
• 結果が順番（コンテキスト）に依存しているため、順番通りに行う。
– 互いに独立なテストケース
• 個々のテストケースが自己完結する。一般にテストケースが大きく複雑になる
