ソフトウェアテストの基礎-01

目標：

1. ソフトウェアテストの定義。

2.7つのテストカテゴリーの違い;

3. 品質モデルの 5 つの主要項目。

4. テストプロセスの 6 つのステップ。

5. テストテンプレートの 8 つの要素。

雇用の方向性:

1. 機能テスト + インターフェーステスト

2. 機能テスト + パフォーマンステスト

3. 機能テスト + Web オートメーション

1. ソフトウェアテストの概要

(1) 定義：

ソフトウェア:コンピュータ ハードウェアの動作を制御するツール。

ソフトウェア テスト:技術的手段を使用して、ソフトウェアが要件を満たしているかどうかを検証します。 (目的: ソフトウェア エラーを削減し、ソフトウェア品質を制御する)

(2) 主流スキル:

1. 機能テスト:テストでは主にプログラムの機能が要件を満たしているかどうかを検証します。

2. 自動テスト:手動作業の代わりにコードまたはツールを使用してプロジェクトをテストします。

3. インターフェイス テスト: コードまたはツールを使用して、シーケンス内のインターフェイスに正常にアクセスできるかどうかを確認します。

4. パフォーマンス テスト: サーバーの欠陥を見つけるためにソフトウェアを使用して複数人をシミュレートします。

(3) モデル:

1. 品質モデル:優れたソフトウェアの寸法を測定します (テスト時に考慮すべき側面がわかります)

焦点: 機能、パフォーマンス、互換性、使いやすさ、セキュリティ 結論: ハードウェアをテストする場合でもソフトウェアをテストする場合でも、上記の点に基づいて分類検証を実行する必要があります

2. モデルをテストする

2. テストの分類

(1) テスト段階（ソフトウェアの製造工程順序）ごとに分ける：

単体テスト：プログラムのソースコードをテストする（単位：独立した最小の機能コードセグメント）

統合テスト: ユニット間のインターフェイスのテスト (インターフェイス テストとも呼ばれ、モジュール間のアクセス アドレスのテスト)

システムテスト: システム全体の機能 + 互換性 + ドキュメント (説明書、インストール文書)

受け入れテスト: 内部テスト (企業の内部担当者が使用し、欠陥を発見して修正する)、公開テスト (ユーザーにテストを手伝ってもらう)

(2) コードの可視性による分割:

ブラックボックステスト：ソースコードは見えず（UI機能は見える）、主にプログラムのUI機能をテストします。 (フェーズ分割→システムテスト)

グレー ボックス テスト: コードの一部を確認し (関数は表示されません)、主にプログラム コードの一部をテストします。 (フェーズ分割→結合テスト)

ホワイト ボックス テスト: すべてのコードを確認します (UI 関数は表示されません)。主にプログラムのソース コードをテストします。 (フェーズ分割→単体テスト)

(3) まとめ：

システム テストとブラック ボックス テストの中核は機能テストです。統合テストとグレー ボックス テストはインターフェイス テストとも呼ばれます。単体テストとホワイト ボックス テストはコードをテストします。自動テストは機能テストに属します。パフォーマンス テストとセキュリティ テストは特別なテストに属します。テスト中。

3.試験工程

• ニーズ分析（レビュー）

   前提条件: 要件ドキュメントを一度読み、あいまいな点があれば記録してください。 
  参加者: フロントエンド、バックエンド、テスト、製品
  目的:
      1. すべての部門がニーズを一貫して理解していることを確認する
      2. 各役割が要件を確認して記入します
      3. ソフトウェアのいくつかの機能を理解する
  ヒント: 要件分析段階 - > ソフトウェアはまだ実装されていません (プロジェクトは設立されたばかりです)

• テスト計画

  説明: テストの実行をガイドするドキュメント (重要)
  何を測定するか (ターゲット、範囲)
  誰がテストを行うのか (担当者の進捗と手配)
  テスト方法 (テストツール、テスト戦略)

• ユースケースの設計

   説明: ソフトウェア テスト ポイントの実行を正確に検証するための文書。 
  1. 要件を分析する
  2. テスト ポイントを抽出する
  3. テスト ポイントをカバーするユースケースを設計する

• ユースケースの実行

  説明: テストを実装します。

• 欠陥管理

  送信 -> 確認 -> 閉じる

• テストレポート

  1. バグ分析と統計
  2. テスト中に発生した問題
  3. テストの概要 (このテストの長所と短所)

4.テストケース

ユースケース:ユーザーのユースケース。

ユースケースの役割:1. テスト漏れを防ぐため; 2. ソフトウェアが合格したかどうかを測定するため

ユースケースドキュメントの作成仕様:

ユースケース番号: project_module_number
ユースケースのタイトル: 期待される結果 (テスト ポイント)
モジュール/プロジェクト: プロジェクトまたはそれが属するモジュール
前提条件: このユースケースを実行するための前提条件となる操作は何ですか
優先度: ユースケース P0 ～ P4 の重要性または影響度を示します (P0 が最も高くなります)
テスト手順: テスト手順を説明する
テスト データ: 操作データ。利用できない場合は空にすることができます
期待される結果: 達成が期待されるもの

テンプレートの例:

ユースケースの設計方法:

目標：

1. 網羅的なシナリオのテスト ポイントを設計できる 2. 制限された境界ルールのテスト ポイントを設計できる 3. 複数条件の依存関係のテスト ポイントを設計できる 4. プロジェクト ビジネスのテスト ポイントを設計できる

(1) 網羅的シナリオのテストポイント設計能力（網羅的：エンドレス）

同値クラス分割法

重要なポイント: 有効な等価性を 1 つと無効な等価性を 1 つだけ取得します。 
手順:
    1. ニーズを明確にする
    2. 有効な同等性と無効な同等性を判断する
    3. 有効なデータと無効なデータに基づいてユースケースを作成する
注: 完全なユースケースは、等価クラスと境界値とともに記述する必要があります。 

テンプレートの例:

(2) 制限された境界ルールのテスト ポイントを設計できる (境界値を使用して境界桁制限の問題を解決する)

境界値

手順:
    1. ニーズを明確にする
    2. 有効な同等性と無効な同等性を判断する
    3. 境界範囲を決定する
    4. データを抽出してユースケースを作成する

テンプレートのケース:

(3) 複数条件の依存関係のテスト ポイントを設計する機能 (デシジョン テーブルを使用)

デシジョンテーブル

手順:
    1. ニーズを明確にする
    2. 判定表を描く
        1) 条件パイルとアクション パイルをリストする 
        2) 条件項目を入力し、条件の組み合わせを完成させます 
        3) 条件項目の組み合わせに基づいてアクション項目を決定します 
        4) 同様のルールを簡素化して統合します (同じアクションを使用)
    3. ルールに従ってテスト ケースを作成する
ヒント: 
    1. 複数の条件間に依存関係があり、テスト カバレッジにデシジョン テーブルが使用されます。 
    2. デシジョンテーブルは通常、4 つの条件内の条件依存性に適しています
    3. 条件が 4 つ以上ある場合、すべての条件をカバーするのは適切ではないため、(直交法) を使用して解決する必要があります。 

テンプレートの例:

(4) プロジェクト業務のテストポイント（フローチャート）を設計できる

ビジネスユースケースはフローチャートに基づいて分類されているため、最初にフローチャートを理解する必要があります。

1. オンライン ツール: https://processon.com/diagraming/605880af07912927bd71c388
2. オフライン ツール: visio
3. その他のツール: Excel

ユースケースの実行

実行結果は、ユースケース (意味) の期待される結果と一致しません。これは欠陥です。 (ユースケースの実行の失敗は欠陥であり、欠陥管理が必要です)

欠陥：

1. 定義:ソフトウェアに存在するさまざまな問題は欠陥であり、バグと呼ばれます。

2. 欠陥基準：

1. 機能が少ない 2. 機能上のエラーがある 3. 多機能である 4. 隠れた機能がない 5. 使いやすさ（ソフトウェアテスターの専門的な観点から）

3. 欠陥の原因:

1. 要件文書 2. アーキテクチャ設計 3. コーディング実装 4. 環境 (ハードウェア、ソフトウェア)

4. 欠陥のライフサイクル:

1. 回帰テスト:
    ①通常プロジェクトの復帰：今回プロジェクトには2つの新しいモジュールが追加されましたが、最も基本的なことは、新しいモジュールと、新しいモジュールに関連付けられている古いモジュールの機能をテストすることです。 
    ② 非定常プロジェクト (銀行、軍事、航空宇宙): すべての新しい機能を再テストする必要があります。 
2. 回帰バグ: 前のバージョンで発見された欠陥は開発および修復され、次のバージョンで再検証されます。 

5. 欠陥の中核要素:

6. 欠陥提出要素:

7.欠陥の種類:

1. 機能エラー 2. UI ページのエラー 3. 互換性 4. データ (データベース) 5. 使いやすさ 6. 提案 7. アーキテクチャの欠陥

8. ワークフロー:

ユースケースの設計→ユースケースの実行（テストの実行）→欠陥（サブミット、検証、クローズ） 欠陥定義：あらゆる問題（バグ） 欠陥標準：多機能、機能が少ない、エラー、隠し機能がない、簡単使用説明 欠陥の焦点: 欠陥のタイトル、前提条件、再現手順、期待される結果、実際の結果、添付メモ 欠陥情報の提出: 譲受人、欠陥レベル、修復の優先順位、種類、ステータス (統計的欠陥)

欠陥管理:

1.エクセルサンプル：

2. 欠陥追跡プロセス: (テストおよび開発プロセスに関わる作業についてだけ知っておいてください)

3. 提出メモ:

ヒント:
面接の質問: 欠陥を発見した後、最初に何をすべきですか? -- バグが再現可能であり、間違いなくバグであることを確認してください。 
送信する際には、欠陥がすでに存在するかどうかを確認してください。 

4. 欠陥管理ツール:

1. プロジェクト管理ツール - 欠陥の管理 (ZenTao、JIRA、TFS)
2. Excel 管理の欠陥

(1) ZenTao（プロジェクト管理ツール）

• アドレス:ユーザー ログイン - ZenTao

• 特徴：

  

• フローチャートを使用する

• ZenTao を使用して欠陥を管理する

  • ログイン

  

  • 欠陥を作成する

  

  • 近い欠陥

  

5. 欠陥タイトルの拡張: