システムのテストとメンテナンス

1. システムテスト

1. テストの目的: テストとは、エラーを見つけるためにプログラムを実行するプロセスです。
2. テストの原則:

1. 1. 早期かつ継続的にテストする
   2. プログラマーは、自分で設計したプログラムのテストを避けます。テスト作業は、最初にソフトウェアを開発した人またはグループによって回避されるべきです (単体テストを除く)。
   3. 合理的で有効な入力条件だけでなく、不合理で無効な入力条件も含める
   4. 入力データを決定するだけでなく、システムの機能から出力結果を決定する
   5. プログラムがすべきことを行っているかどうかだけでなく、すべきでないことを行っているかどうかも検出する
   6. 修正後に回帰テストを行う必要があります
   7. 発見されていないバグの数は、プログラムが発見したバグの数に比例します

1. 基本的なテスト アクティビティ:

1. 1. テスト計画を立てる、システムテストの計画を立てる テスト計画を立てるときは、プロジェクト全体の開発時間と進捗状況、およびいくつかの人的要因と客観的条件を十分に考慮して、テスト計画が実行可能になるようにします。テスト計画の内容には、主にテスト内容、スケジュール、テスト環境と条件、テストトレーニングの手配などが含まれます。
   2. テストの基礎となるテスト概要を準備します。試験では、システムの機能や特徴ごとにクリアしなければならない基本的な試験項目と試験完了基準を明確かつ網羅的に規定しています。
   3. テストケースの設計と生成 テスト概要に従って、テストケースの設計と生成を行います。ユース ケースをテストする場合、上記で紹介したテスト ケース設計手法を包括的に使用して、主にテスト項目、入力データ、テスト プロセス、期待される出力結果などを含むテスト設計ドキュメントを生成できます。
   4. システム テストを実行し、テストを実装します。テストの実装フェーズは、一連のテスト サイクルで構成されます。各テスト サイクルで、テスターと開発者は、事前にプログラムされたテスト アウトラインと準備されたテスト ケースに従って、テスト対象のソフトウェアまたは機器に対して完全なテストを実施します。
   5. 欠陥管理とエラー修正、テストレポートの生成; テストが完了した後、主にテストを要約し、テストの結論をリストし、欠陥とエラーを指摘する、対応するテストレポートを作成する必要があります

1. テスト段階の分割:

1. 1. 単体テスト：

1. 1. 1. コンセプト: モジュールテストとは、最小のソフトウェアモジュールをそれぞれテストし、各プログラムモジュールの機能説明をチェックして、正常に動作することを確認することです。
      2. テスト対象: 単体テストは開発者によって実行されます
      3. テスト内容：モジュールインターフェーステスト、ローカルデータ構造テスト、パステスト、エラーハンドリングテスト、境界テスト（モジュールテスト、モジュール機能、性能、インターフェースなど）

1. 1. 統合テスト:

1. 1. 1. コンセプト：ユニットテストに基づいて、一般設計仕様と詳細設計仕様の要件に従って、すべてのモジュールを組み立てることが必要です。その目的は、ソフトウェアシステムを構成するモジュール（モジュール間のインターフェース）のインターフェースと交換機能を検証することです。
      2. 組み立て時に考慮すべき質問: モジュールを一緒に接続すると、モジュール インターフェイスを通過するデータが失われますか?
      3. あるモジュールの機能が別のモジュールの機能に影響を与え、悪影響を引き起こすかどうか、さまざまなサブ機能の組み合わせが期待される親機能を達成できるかどうか、グローバル データ構造に問題があるかどうか、単一のモジュールのエラーがあるかどうかモジュールは、蓄積されると許容できない程度に拡大されます。
      4. モジュールの組み立て方法:

1. 1. 1. 1. 1回限りの組み立て方法：エラーが発生した場合、理由が特定できず、エラーの確認と修正が困難になります
         2. トップダウン アセンブリ: テスト プロセスの早い段階で主要な制御点と判断ポイントが検証され、機能の実現可能性が早期に発見および確認され、開発者とユーザーの成功に関する情報が強化されます。短所: 過剰な回帰テストにつながります。
         3. ボトムアップ付加価値方式：問題が発生しやすい部分を早期に発見し、早期に解決できる 欠点：最後まで主要部分の制御にアクセスできない 複数モジュールの並列テストを実装してテスト効率を向上できる;
         4. 混合付加価値方式

1. 1. 1. スモーク テスト: ハードウェア業界に端を発し、ハードウェアまたはハードウェア コンポーネントの変更または修理が行われた直後にデバイスの電源を入れます。煙が出なければ、コンポーネントはテストに合格しています

1. 1. システムテスト:

1. 1. 1. コンセプト: 完全なソフトウェア構成アイテムがシステムに正しく接続できるかどうかを検証するための、実際の環境でのシステム テスト。システム全体のハードウェア、周辺機器、サポートソフトウェア、データ、および人員とソフトウェアを組み合わせ、要件仕様に基づいて実際の動作環境でテストを実行します。システムマニュアルに準拠していない箇所がないか確認してください。
      2. システム テスト プロセスは、計画と準備、実行、やり直し、回帰テストの 3 つのフェーズに分かれています。

1. 1. 1. 1. 内容: システム テストでは、通常、機能テスト、パフォーマンス テスト、回復テスト、セキュリティ テスト、強度テスト、およびその他の制限テストを完了する必要があります。

1. 1. 1. 3 つのパフォーマンス テスト:

1. 1. 1. 1. 負荷テスト: さまざまなワークロードの下でシステムのパフォーマンスを決定します。目標は、負荷が徐々に増加したときのシステムのさまざまなパフォーマンス インジケーターの変化をテストすることです。
         2. ストレス テスト: システムのボトルネックまたは許容できないパフォーマンス ポイントを特定することによって、システムが提供できる最大のサービス レベルを取得するためのテスト
         3. 強度テスト: システム リソースが特に少ない場合のソフトウェア システムの動作を調べる
         4. 同時実行テスト: 同時実行テストは、キャパシティ テストとも呼ばれ、主に、システムが処理できる同時オンライン ユーザーの最大数を決定するために使用されます。

1. 1. 確認試験：

1. 1. 1. コンセプト: ソフトウェアとユーザー要件の一貫性を検証するために使用される適合性テスト
      2. 確認テストには、内部確認テスト、アルファ テスト、ベータ テスト、受け入れテストが含まれます。

1. 静的テストと動的テスト

1. 1. 静的テストは、ソフトウェア テストを実行しないプログラムですが、手動検出とコンピューター分析を使用して静的分析を支援し、プログラムをテストします。静的テストの方法には、主にフロント デスク検査、コード ウォークスルー、およびコード レビューが含まれます。
   2. 動的テストは、ブラック ボックス テスト、ホワイト ボックス テスト、グレー ボックス テストに分けられます。ホワイト ボックス テストは構造テストとも呼ばれ、ブラック ボックス テストは機能テストとも呼ばれ、グレー ボックス テストはこの 2 つの組み合わせです。

1. 静的試験方法:

1. 1. デスク検査: プログラマーは自分のプログラムをチェックします。プログラムがコンパイルされた後、単体テストの設計の前に、プログラマーはプログラムのエラーを見つけるために、ソース コードを分析および検査し、関連するドキュメントを補足します。
   2. コード レビュー: コード レビューは、複数のプログラマーとテスターで構成されるレビュー チームが、読み取り、議論、論争を通じてプログラムの静的分析を行うプロセスです。コード レビュー プロセスは、次の 2 つのステップに分けることができます。
   3. コード ウォークスルー: コード ウォークスルーは基本的にコード レビューと同じで、プロセスも 2 つのステップに分かれています。その後、会議を開催します。ステップ 2: 会議のプログラムはコード レビューとは異なり、単にプログラムを読んでプログラム チェックリストと照合するのではなく、参加者がコンピュータとして "行動" できるようにします。つまり、最初に、テスト チームのメンバーは、テストするプログラムの代表的なテスト ケースのバッチを準備し、それらをウォークスルー チームに提出します。ウォークスルー チームは会議を開催し、集合的にコンピューターの役割を果たし、プログラムのロジックに沿ってテスト ケースを実行し、分析と議論のためにいつでもプログラムのトレースを記録します。
   4. 静的テストは静的分析で行われ、静的分析には以下が含まれます。

1. 1. 1. 制御フロー分析: 未使用のステートメント、到達不能ステートメント、存在しないサブルーチンの呼び出しはありますか
      2. データ フロー分析: 未定義の変数の参照、以前に使用されていなかった変数の再割り当て
      3. インターフェイス分析: モジュール間のインターフェイスの一貫性、サブルーチンと関数間のインターフェイスの一貫性、および関数の仮パラメーターと実パラメーターの数、順序、および型の一貫性
      4. 式の分析: ブラケットの不一致、範囲外の配列参照、0 による除数など。

1. 動的試験方法:

1. 1. ホワイトボックステスト（構造テスト）

1. 1. 1. コンセプト: 内部構造とロジックに従ってテスト ケースを設計し、プログラムのパスとプロセスをテストします。主に単体テスト段階で使用されます。
      2. 声明の対象範囲:
      3. 判定範囲
      4. 条件のオーバーライド:
      5. 判定・条件付：
      6. 条件の組み合わせのオーバーライド:
      7. パス カバレッジ:
      8. 基本パステスト
      9. ループ カバレッジ:

1. 1. ブラック ボックス テスト (機能テスト):

1. 1. 1. コンセプト：Heihe Testは、製品の仕様に基づいて、製品の具体的な機能や特徴をユーザーの視点から検証活動を行い、各機能が完全に実装されているかどうか、ユーザーがそれらの機能を正常に使用できるかどうかを確認します.主に統合テストに使用されます. 、確認試験、システム試験段階。
      2. 検出エラーの表示: 機能が正しくないか不足している、インターフェイス エラー、データベース アクセス エラー、パフォーマンス エラー、初期化および終了エラーなど。
      3. 方法：

1. 1. 1. 1. 等価クラス分割方法:
         2. 境界値分析:
         3. 間違った推測:
         4. 意思決定表: 複数の論理条件値の組み合わせによって形成される複雑な状況で実行されるさまざまなアクションを記述するのに最適です。
         5. 原因と結果の表: 入力条件と出力結果の因果関係に従ってテスト ケースを設計します。

1. オブジェクト指向テスト:

1. 1. アルゴリズム層（単体テスト）：同値類分割テスト、複合関数テスト（決定表によるテスト）、再帰関数テスト、多態性メッセージテスト（メソッドレベル）を含む
   2. クラス層 (モジュール テスト): 不変境界テスト、モーダル クラス テスト、および非モーダル クラス テストを含む
   3. テンプレート レイヤー、クラス ツリー レイヤー (統合テスト): ポリモーフィック サービス テストとフラット化テストを含む
   4. システム層、システムテスト

1. テストの自動化:

1. 1. 利点: テスト実行速度の向上、運用効率の向上、テスト結果の精度の確保、テスト スクリプトの継続的な実行、実環境での制約された状況のシミュレーション
   2. 短所: すべてのテスト活動が自動的に完了するという保証はありません; 人件費を削減する保証はありません; 通常は無料で利用できません; テストツールを削減する保証はありません

1. 検証と確認の違い

1. 1. 検証とは、ソフトウェア開発サイクルの特定の段階にある製品が、前の段階で確立された要件を満たすプロセスです。
   2. 検証とは、ソフトウェア開発プロセスの最後にソフトウェアを評価して、ソフトウェア要件に準拠しているかどうかを判断するプロセスです。
   3. テストとは、プログラムを実行することにより、プログラム中の設計ミスやコーディングミスを意識的に発見することであり、テストは検証・確認の手段の1つです。

2. レガシーシステムの進化テスト

1. 変革戦略（ハイレベル、ハイバリュー）：レガシーシステムをベースに、新機能の追加や改善を行う
2. 統合戦略 (高レベル、低価値): 孤立した情報の島があり、情報の島は統合によって開かれます。
3. 排除戦略（低レベル、低価値）
4. 統合戦略 (低レベル、高価値): レガシー システムの機能モデルおよびデータ モデルと完全に互換性のある方法でシステムを再開発します。

3. 新旧システム変換試験

1. ダイレクトコンバージョン【ハイリスク、ローコスト】
2. 並列変換 [低リスク、高コスト]: 古いシステムと新しいシステムが一定期間並行して実行されます。
3. 分割変換【折衷案】：新システムは地域ごとに立ち上げ、新システムは分子システムごとに段階的に立ち上げる

4. システムの運用・保守

1. 保守性に影響を与える要因

1. 1. 理解可能性: ソース コードと関連ドキュメントを読むことによって、ソフトウェアの機能とそのしくみを理解しやすいことです。
   2. 変更可能性: ソフトウェアを変更できる容易さを指します。
   3. テスト容易性: ソフトウェア プログラムが正しいことを容易に検証できることを指します。
   4. 最後に: 通常、テスト容易性が高いソフトウェアとは、ソフトウェア設計が単純で複雑さが少ないことを意味します。ソフトウェアが複雑になればなるほど、テストが難しくなります。
   5. 信頼性: ソフトウェアの信頼性が高いほど、メンテナンスが必要になる可能性は低くなります。
   6. 移植性: ソフトウェアをある環境から移植して、新しい環境で正しく実行できることの容易さを指します。ソフトウェアの動作環境の変更は、ソフトウェア保守の一般的な状況であり、移植性の良いソフトウェアは保守の可能性を減らします。

1. ソフトウェア メンテナンスのカテゴリ:

1. 1. 是正保守: ソフトウェア エラーの特定と修正 (テスト段階で発見されなかったバグ)
   2. 適応保守: 外部環境 (新しいハードウェアおよびソフトウェア構成)、データ環境 (データベース、データ形式、データ記憶媒体) の可能な変更。このような変化に合わせてソフトウェアを修正するプロセスは、アダプティブ メンテナンスと呼ばれます。
   3. 改善メンテナンス: パフォーマンスの改善または機能の追加
   4. 予防保守：将来に向けて、システムの保守性と信頼性を事前に向上させます。今後の報告書様式の変化に対応するため、特別報告書機能を一般報告書作成機能に変更するなど