テストのレベルと計画 以下はそれぞれ目的が異なる別々のテスト。一緒くたにはできない。 受入れテスト– 顧客の要求を満たしているかを確かめる– 要求獲得・分析工程の成果としてテスト計画ができるシステムテスト– システム全体として要求仕様を満たすかを…

レビュー（見直し：review） レビューには大きく分けて以下2種類の方法があり、いずれも，主に仕様への準拠性を確認する。 顧客の要求，特に非機能要求の充足を確認することは難しい。仕様（要求定義・設計）やプログラムコードを読み直すことで検証。仕様を…

プログラムの静的検証（static V&V of program） 検証とは、仕様の検証を行うもので、動的解析と静的解析がある。 issunno-koin.hateblo.jp 静的検証は、正当性の証明を行う。動的検証では、プログラムが完全に正しいことは保証的ない。 正当性証明の手順 ①…

システムテスト（System Testing）とは システム全体のテストをする。システム全体での動作を検査，主に例外・異常処理，非機能要求，品質，などを対象とする。（⇔単体テスト、結合テスト） 機能のテストでカバーしきれないところをテストする。 構成テスト…

前回 issunno-koin.hateblo.jp 構造化テスト（structured testing） 制御フローグラフのトポロジ分析に基づくテストケースの選択手法。トポロジは、モノのつながりをモデル化する数学の分野。比較的小さい部品の単体テストに向く。 ①制御フローグラフの作成②…

ホワイトボックステスト テスト対象ソフトウェアの内部パス，構造，実装に関する知識を前提としたテスト ＝プログラムが読めないとテストできない 適用範囲– 単体テスト，統合テスト，システムテストの３レベルに適用可能（受け入れテストには向かない） 制…

前回 issunno-koin.hateblo.jp ディシジョンテーブルテスト（decision table testing） 条件によって振る舞いが異なるシステムの振る舞いを確認する。その条件を書いたものがディシジョンテーブル。複雑なルールが少数存在する場合に有効な方法。 ディシジョ…

前回 issunno-koin.hateblo.jp ブラックボックステスト 要求と仕様書のみを利用するテスト戦略。 単体テストから受け入れテストまですべてのレベルで適用可能で、大規模なソフトウェアに対応できるが、テスト対象のソフトウェア内部をどこまでテストできたか…

ソフトウェアの検証 ソフトウェアの検証によって確かめる事項– ソフトウェアの「正しさ」– 「正しさ」を妨げるような欠陥があれば，その箇所と原因を指摘 ・ソフトウェアの正しさとは– ソフトウェアが求められる機能を実行できる– ソフトウェアが求められる…

前回 issunno-koin.hateblo.jp 耐故障性（fault tolerance） ソフトウェアの障害時でも機能し続けることのできる性質耐故障性が重要な場面– 機能性が多少落ちたとしても高い可用性が求められる場合– 障害回復のためのコストが大きい場合システムが仕様通りに…

前回 issunno-koin.hateblo.jp ディペンダブルプログラミング（dependable programmin） ・故障の回避や耐故障性に効果のある言語要素やプログラミング技術を採用・情報隠蔽– オブジェクト指向の考え方（カプセル化）– データの予期しない参照・変更を防止・…

前回 issunno-koin.hateblo.jp 信頼性を得るための技術 ・冗長性（redundancy）– クリティカルな部品やサブシステムを複数利用可能状態にしておく（ バックアップサーバ，多重系，RAIDなど）。一つがダウンしても別のものが使える。・多様性（diversity）– …

前回 issunno-koin.hateblo.jp 可用性と信頼性 ・可用性 ーある一時点において、システムが正常にサービスを提供できる確率（使いたいときに使えたか MTTR平均修復時間） ・信頼性 指定した環境で、一定期間にシステムが正常に稼働し続ける確率（正常稼働の…

ソフトウェア検証→ソフトウェアが「正しい」かどうか確かめる →ソフトウェアが求められる機能を実行できる。 ソフトウェアが求められる品質（性能efficiency、精度precision、信頼性dependability） 検証対象の「ソフトウェア」 プログラム + 文章（仕様書。…