[情報処理挑戦記]#14統合実装


第二章集積実施


第一節モジュール実施


1.すべての単位を実現する


(1)汎用モジュール
  • は、システム全体の設計を行う際に、各サブシステムに共通するモジュールを組み合わせて配置されたソフトウェアライブラリである.
  • 汎用モジュールを作成する理由は、各サブシステムでモジュールを別々に作成すると、開発コストが重複し、標準化されないためである.
  • 汎用モジュールを組み合わせると、後でサブシステムが追加されても、汎用モジュールは再開発を行わずに再利用することができる.
  • (2)ユニットモジュール
  • 画面モジュール、画面入力データを処理するためのサービスコンポーネント、業務処理コンポーネントなど.
  • まず、
  • 汎用モジュールが実装され、その後、ユニットモジュール実装に再利用される.
  • (3)モジュール化
    [1]モジュールの独立性が高いほど、モジュール化の度合いが高くなる.
    [2]結合度
  • 結合度は、モジュール間の相互関連または接続の程度を表す.
  • 両モジュール間の相互依存性
  • [3]凝集度
  • は、1つのモジュール内の処理要素間の機能関連度を表し、凝集度が高い場合にのみ良いモジュールになる.
  • ❋モジュール化↑-独立性↑(凝集度↑,結合度↓)
    (凝集度)↑機能性,順序性,通信性,プログラム性,時間性,論理性,偶然性↓
    (結合度)↑内容、汎用、外部、制御、スタッフ、データ↓

    2.テストユニットモジュール


    テストとは、欠陥を探すためにソフトウェアを起動する一連の動作とステップを指す.
    (1)試験段階の区分
    [1]モジュールテスト:独立した環境で1つのモジュールのみをテストする
    [2]統合テスト:システムモジュール間のインタフェースをテストします.これは、モジュール間のデータ移動が望ましいかどうかを判断する必要があることを意味します.
    [3]検証テスト:お客様のニーズを満たすかどうかを検証する
    [4]システムテスト:システムが初期目的を満たしているかどうかをテストする
    モジュール(単位)テスト->統合テスト->システムテスト(開発者の観点=>プロセス検証)
    ->自己変数試験(α試験、β試験)(ユーザ観点=>製品検証)
    (2)試験方法別に分類する
    [1]ブラックボックステスト:ソフトウェアの外部リストに基づいてその機能と性能をテストする
    [2]ホワイトボックステスト:ソフトウェア内部の論理構造をテストする
    (3)ホワイトボックステスト
    [1]プログラム内のすべての論理構造、または計算経路の複雑さを理解し、テストケースを生成する.
    [2]プログラム、すなわち順序の制御構造を利用して、テストケースのテストケース設計方法を導く.
    [3]ソフトウェアジオメトリ(SWコンフィギュレーション)構造を使用してテストケースを作成する.
    [4]プログラムで許可されているすべての論理パス(基本パス)を理解したり、パスの複雑さを計算したりして、テストケースを作成します.
    [5]基本経路を調査するために引用された試験事例は、試験時に少なくとも1回のプログラムのすべての文を実行することを保証する.
    1)基礎経路試験(構造試験、複雑度試験)
  • の代表的なホワイトボックス技術は、McCabeが提案し、試験分野を現実的に最大化した.
  • の詳細な設計と元のコードに基づいて、論理フローチャートを描画し、プログラムの論理複雑度を測定します.
  • テストケース設計者は、実行経路を定義するための基礎として使用できるように、プログラム設計の論理的複雑さを測定する.
  • 制御フローは、論理フローチャートを使用して表される.
  • [1]論理フローチャート(フローチャート:Flow Graph)
  • 元(Node(N):プログラム内の1行または複数行の順序文の集合(プログラム文のセット)
  • 矢印(EdgeE):実行順、制御フロー
  • エリア:ノードと幹線の限定部分

  • [2]複雑度
    ソフトウェア測定法(SW Metrics),
  • プログラムの論理複雑度を定量的に測定する
  • V(G)=E-N+2(E:幹線数、N:ノード数)
  • V(G)=P+1(P:四半期ノード数)
  • 複雑度と質量
  • 5以下非常に単純なプログラム5-10非常に構造化、安定したプログラム20以上の問題自体が非常に複雑または構造が異常に複雑なプログラム50以上非常に非構造化、不安定なプログラム
    (4)ブラックボックステスト
  • プログラムロジック(アルゴリズム)を考慮せずに、プログラムの機能またはインタフェースの外部説明からデータを直接テストしてデータを選択する方法
  • 機能テスト、データ駆動テスト、IO駆動テスト
  • ブラックボックス試験方法はソフトウェアの機能要件に焦点を当てている.
  • 基礎システムモデルの観点は、
  • プログラムの論理またはアルゴリズムに関係なく
    1)等分
    [1]方法は,プログラムの入力ドメインをテストケースで計算可能なデータのクラスに分け,テストケースを生成してチェックする.
    [2]プログラムの入力条件を中心に、入力条件の適正値と不適正値を設定することにより、同等種別ごとの任意の値を試験例として選択する.
    [ㄱ] 유효동등 클래스 집합 : 프로그램에 유효한 입력을 가진 시험사례
    [ㄴ] 무효동등 클래스 집합 : 프로그램에 타당치 못한 입력을 가진 시험 사례
    [3]重要なのは、クラスごとに最小化されたテストケースを作成することである.
    2)分析境界値
  • 入力条件の中間値よりも境界値に誤りが生じる確率が高いことを利用して,入力条件の境界値からテストケースを選択する.
  • [1]入力資料のみを重視した同等の分割方法の整備を図る
    [2]入力条件と出力条件をテストケースとして選択
    [3]条件指定値の範囲(例えば[a,b])を入力すると、試験例では、a,b値だけでなく、[a,b]の範囲を少し超えた値を選択する.つまり、入力条件が数値を表す場合は、最大値、最小値、最大値よりやや大きい値、最小値よりやや小さい値を選択します.
    3)原因-結果グラフ技術
    [1]入力データ間の関係が出力に与える影響状況を系統的に分析し、効率の高いテストケースを抽出してテストする方法.
    [2]プログラム外部明細による入力条件(原因)と入力による出力(結果)を論理接続の図形で表し,テストケースを導出する.
    同等分割、境界値分析、原因-結果グラフ技術!重要!
    4)エラー検出技術
    5)比較試験技術
    6)組み合わせテスト