６章：テストと保守 テスト工程 テストケース設計技法 テスト妥当性評価 保守 ６．１ テスト工程 1. テストとは，品質管理における検査手段 1. 2. 3. プログラム内に残存するエラー検出ための実行行為 テスト空間：テストケースの全集合 テストにおける課題 1. 2. 2. 限られた時間内に最大の効果を上げる プログラム品質に，保証指標を与える テストプロセスと技法 1. 2. 3. 4. 計画・・・品質目標値の設定，テスト手順の計画 準備・・・テスト環境の準備，テストケース設計 実行・・・テスト実行，結果確認・記録 評価・・・判定 ６．１ テスト工程 1. テスト工程の位置付けとテスト容易性の実現 1. ソフトウェア単体・組合せテスト段階 1. 詳細設計書に基づき，モジュール仕様と結合時整合性の確認 2. ソフトウェア統合テスト段階 1. 基本設計書に基づき，ソフトウェア外部仕様の確認 3. システムテスト段階 1. システム仕様書に基づく開発者側の最終テスト，システム動作と性能確認 2. 要求仕様書に基づく実運用状況での要求仕様の確認 2. 開発プロセス全体にテスト容易性を組入れる 1. 要求と設計の対応付けを明確にする 2. プログラムアーキテクチャに対する配慮 3. 開発段階から，開発手法・環境・コーディング規約などを選択する ６．１ テスト工程 1. テスト環境の準備 入力 1. ドライバー 2. スタブ 引数：戻り値 被テスト モジュール 2. テスト戦略 1. 増加テスト法 1. トップダウン・テスト 出力 ドライバー 引数：戻り値 スタブA 引数：戻り値 スタブB 1. 上位のモジュールにありがちな重大な欠陥を先に発見できる 2. ドライバを作らなくて済むが，スタブを作る必要はある 3. 当初からプログラムの結合状態でテスト環境を構成するため，会モジュールを並 列的にテストすることが難しい 2. ボトムアップ・テスト 1. 下位モジュールを独立・並行にテストできる 2. スタブを作らなくて済むが，ドライバーを作る必要はある 3. アーキテクチャやインターフェースに関する重大なエラーがテストの最終段階に なるまで見つからない 2. テスト手順の計画における考慮事項 1. 人員の有効利用 2. 開発スケジュールとの整合 3. テスト戦略 ６．２ テストケース設計技法 1. ブラックボックステスト 1. 同値分割・・・プログラムの入力条件だけからテスト入力空間を分割する 1. 系統的手法，個人差が出ない 2. 入力条件を網羅できる最小のテストケースを作れる 3. 同値クラス・・・入力条件について，プログラムにとって同じ扱いを受けるはず の値の範囲 1. 手順１：入力条件ごとに，有効同値と無効同値クラスを設定する 2. 手順２：テストケースを設定する 1. 出来るだけ多くの有効同値クラスを用いるテストケース 2. 無効同値クラスの１つだけをカバーするテストケース 2. 限界値分析・・・プログラミング上の実装ミスを見出す技法技法 プログラム条件の変わり目と思われる値に焦点を絞り テストケースを設計する 1. 指針１：入力件のみならず出力条件も考慮する 1. ファイル出力，表示出力，パケット出力 2. 指針２：各条件の境目の値をテストケースとして選択する ６．２ テストケース設計技法 1. ブラックボックステスト 1. 状態ベース仕様に基づくテストケース 1. 機能的仕様の網羅度と対応する 2. 仕様とプログラムとの一致性を保証 3. 仕様記述からテストケースを生成できる ６．２ テストケース設計技法 1. ホワイトボックステスト 1. プログラムの内部処理に注目して，プログラム構造を網羅するテストケー スを見出す方法 1. 命令網羅テスト 2. 分岐網羅テスト 3. ランダムテスト・・・入力空間にどのような確率的モデルを使用するかにより バリエーションがある． 4. テストケース設計技法のテスト段階への適応可能性 テスト法 単体・組合せテスト 統合・システムテスト ブラックボックス ○ ○ ホワイトボックス ○ × ランダム × ○ ６．３ テスト妥当性評価 テスト妥当性評価：テストをどのように，どれだけ行えば，プログラム品 質をどれだけ保証できるかが重要 1.網羅性基準 1. 仕様に基づく基準 1. 機能記述 1. 仕様書内の自然言語の機能記述に基づくもの 2. 状態ベースの仕様記述に基づくもの 2. 入力・出力条件 1. 入力条件に基づくもの 2. 入力と出力の両条件に基づくもの 2. プログラムに基づく基準 1. 制御構造・・・命令・分岐・条件 2. データフロー・・・変数値のプログラム内での変更パターンの組合せを追跡する ６．３ テスト妥当性評価 1.欠如除去基準 プログラムに内在するエラーの総数が分かれば，検出されたエラーから，欠如除去率が 計算できる 1. エラー散布モデル 被テストプログラムに，予めエラーを埋め込んでおきテストを実施し，その検知エラー率から潜在 するえらーの総数を推定する 2. 成長曲線モデル 同一プログラムを，異なるテストデータセットで順次テストを行うと，新たに発見されるエラーは徐々 に減り，限りなく０になるはず 成長曲線モデル：エラーの累積数を関数 f(x)で表現・・・・ゴンベルツ曲線 E=Kabt D=At + B D=log(dE/dt・1/E) A=logb, B=log(log a・log b) 信頼性予測曲線：成長曲線が求まれば，エラー総数の予測値Ｋが分かり，ある時点のエラー発 見累積数をＫで割った数値は，そのプログラムの信頼度として扱うことが出来る ６．４ 保守 1.エラー修正のための保守 1. 修正までの作業が多い 2. 開発チームが解散しているケースが多い 3. 運用開始後のエラー 1. ユーザ要求との不一致 2. 運用環境との不一致 3. 想定外の利用 2.適合・改善・拡張のための保守 1. 2. 3. 4. ハードウェアの変更・機器増設，コンピュータ機種変更 使用ＯＳ・ミドルウェアのバージョン変更 追加要求による機能改善 性能改善 3.予防のための保守 1. ハードウェアの変化への対応 2. 将来のＯＳやミドルウェアの変化に対する考慮 3. 将来の拡張機能項目への対処 ６．４ 保守 保守作業の課題と解決アプローチ 1. 保守作業手順 1. 2. 3. 4. ユーザからの不具合の報告とその受領 報告の分析と修正計画 修正 再リリース 2. 修正による影響 1. 回帰テストの必要性 3. 経験値 1. ソフトウェアのテストと保守に，55∼60% 2. 5%の変更に対して，95%以上の開発費を投資
© Copyright 2024 Paperzz
