ソフトウェアテストのテストケース設計方法のまとめ

1. ユースケースの設計方法

1.1 基本概念

  1. テストケース:実際のテストで使用されるデータとステップの組み合わせ
  2. テストの経済性:
    できるだけ多くのケースをカバーするために、できるだけ少ないテスト ケースを使用します。網羅的手法は無理がある。
  3. テストカバレッジ:可能なカテゴリに従ったカバレッジ
  • テストのパラドックス: 無尽蔵のパラドックス。すべての欠陥を見つけることは不可能であり、私たちの仕事はすべて欠陥が限りなく 0 に近いものです。
  • y=x+c: c は既知の定数 (テストで見つかった欠陥の数)、x は見つからなかった欠陥の数、y はテスト バージョンに固有の欠陥の数です。

2. 同値クラスの分割方法

2.1 コンセプト

  1. 等価クラス:入力データの類似または同じ効果に従ってタイプを分類し、データをテストする方法としてこれらの分類から代表的なデータを選択します。
  2. 有効な同値クラス: 要件を満たす同値クラス
  3. 無効な同値クラス: 要件を満たさない同値クラス

2.2 機能

  • 等価クラスを使用する方法では、高いカバレッジを維持しながらテスト ケースの数が削減されます。

2.3 適用範囲

  • 入力フィールド: 単一の入力フィールドのみに入力機能を提供するコンポーネント

2.4 使用手順

1. 同等クラスを確認します。

  • 入力は何ですか (入力の長さ、タイプなど)
  • 次に、入力項目から条件制約を見つけ出し、条件制約を分類します。
  • ここに画像の説明を挿入
    2. 同値クラス分割表を作成する
  • 確認された有効クラスと無効クラスを表に記入します
    。 3. 等価クラス分割表に従ってユースケースを記述します。
  • 可能な限り少ないユースケースですべての有効なクラスをカバーする
  • void クラスの場合、1 つのユースケースのみがオーバーライドできます。
  • ここに画像の説明を挿入

2.5 メリットとデメリット

アドバンテージ:

  1. 多数のユースケースを削減
  2. 比較的高いカバレッジを保証
  3. 設計手順は明確かつシンプルです

欠点:

  1. ロジックや特殊なケースを無視して分類のみに焦点を当てる
  2. 補正方法:境界値解析法

2.6 機能テストの最終目的は何ですか?

  • コード実装ロジック

3. 境界値分析

3.1 コンセプト

  1. 境界値:入力データが順序付きセットまたは範囲の場合、セットまたは範囲の境界上の値。
  2. 上点: 境界上の点。開いた区間と閉じた区間に関係なく、上の点が境界点になります。
  • (4, 8) 上の点は 4 と 8 です
  • [3, 9] 上の点は 3 と 9 です
  1. 出発点: 指定された間隔から出発する点。閉区間の出発点は外側にあり、開区間の出発点は内側にあります。
  • (2, 5) オフポイントは 3, 4
  • [3, 8] オフポイントは 2, 9
    ここに画像の説明を挿入
  1. 内側の点: 上部の点と外側の点を除く区間内の任意の点。
  2. テスト ケースの値を取得する場合、上部の点と外側の点の両方が取得されます。

3.2 適用範囲

  1. 入力ドメイン条件に順序付きセットまたは範囲が存在する場合。
  2. 2. 一部のデータの種類やコンピュータ内部の設定条件(帯域幅、容量などに制限値があります)

3.3 使用手順

  1. 等価クラス
  2. 設計等価クラス パーティション テーブル
  3. 適用範囲の要件に従って境界値を記入します

3.4 メリットとデメリット

アドバンテージ

  • 入力の境界条件に焦点を当てることは、境界上の問題を見つけるのに非常に効果的です。
  • 少ない使用例で多くのバグを見つけます。

欠点がある

  • 国境の状況のみに注意を払い、他の状況には注意を払いません。
  • 単独で使用することはできず、同値クラスを補足するものとして「同値クラス分割法」と併用するのが一般的です。

4. プロセス分析

4.1 コンセプト

  1. プロセス: 特定のビジネス目的を完了または達成するためにユーザーが実行する必要がある一連の操作。
  2. 基本的な流れ: ビジネスを正常に完了するプロセス。
  3. 代替フロー: 使用プロセスには他の選択肢があるため、ユーザーはこれらの選択肢を処理した後、基本フローに戻る必要があります。
  4. 異常なフロー:使用中にシステム障害が発生し、その障害に対処する必要があります。

4.2 適用範囲

  • ビジネスロジック関連

4.3 使用手順

  1. 要件に応じてフローチャートを作成します
    ここに画像の説明を挿入
    (フローチャートを作成する際は、判定条件が複数の場合はひし形で囲む、条件が複数の場合は条件ごとにひし形図が必要など、まとめて判定漏れを起こしてテストケースの網羅が不完全にならないように注意する必要があります)
  2. フローチャートに従ってテストケースを書く
    プロセスブランチとユースケースが1つ、プロセスブランチの数はダイヤの数+1

4.4 メリットとデメリット

アドバンテージ

  • ユーザーの使用シナリオを迅速にカバーし、ユーザーの操作プロセスがスムーズであるかどうかを確認し、スモークテストが一般的に使用されます

欠点がある

  • シーンがスムーズであるかどうかのみに焦点を当て、多数の異常な入力や無効なクラスを無視するため、欠陥の欠落につながります。

5. 間違った推測方法

5.1 コンセプト

  • プログラム内のさまざまなエラーは、目標を絞った方法でテスト ケースを設計するために、経験または直感に基づいて推奨されます。
  • それは、テスト エンジニアの製品ビジネスへの精通度、歴史的問題への精通度、プロジェクトの経験などによって異なります。
  • どのような経験が参考になりますか?
    • 境界値
    • 限界値
    • 特別な値: 一重引用符、山かっこ <>
    • 年月日の値
    • 仕事で起きた問題

5.2 メリットとデメリット

アドバンテージ

  1. 人間の直感と経験を活用する
  2. ブレーンストーミング
  3. 使いやすく、すぐにアクセスできる

欠点がある

  1. ユースケースの範囲を評価できません
  2. 見落としやすい未知のエリア
  3. 主観的であり、再現することはできません
  4. ユースケース設計の補助的な方法のみであり、単独で使用することはできません

6. 状態遷移方法

6.1 コンセプト

  1. さまざまな状態で物事がどのように遷移するかに基づいて、状態遷移イベントを使用してテスト ケースを設計する方法。
  2. ステート マシン: 特定のイベントによって状況は変化しますが、状態の総数は限られています。(有限状態マシン)

6.2 2 つの要素

  1. イベント: 何かの状態に変化を引き起こすアクション。
  2. 状態: 特定の瞬間における物事の状態。

6.3 適用範囲

  • 測定対象の状態が多く、変換状況が比較的複雑な場合。
  • 例:
    ここに画像の説明を挿入

6.4 使用手順

  1. テスト対象のオブジェクトの状態と、状態変化をトリガーするイベントを特定し、状態遷移テーブルを描画します。
    ![ここに画像の説明を挿入](https://img-blog.csdnimg.cn/2439f87371a24f7da7a5edb4fc308426.pn
  2. 状態遷移表に従って状態遷移図を描く
  • 円は状態を表します
  • 有向矢印は状態遷移の方向を示します
  • カットヘッドにイベントをマーキングする
    ここに画像の説明を挿入
  1. 状態遷移図に従って状態遷移ツリーを描く
  • 状態遷移図で状態を選択し、矢印を観察し、矢印の方向に応じてツリー図に変換します。
    **大胆なスタイル**
  1. テストケースを書く
  • 状態遷移ツリーに従って、テスト ケース、ブランチ、ユース ケースを 1 つずつ書きます。
    ここに画像の説明を挿入

6.5 利点と欠点

アドバンテージ

  • テストされるオブジェクトの状態が多く、変換状況が比較的複雑な状況では、テスト ケース設計の整合性が保証されます。

欠点がある

  • 入力やビジネスロジックに注意を払わない

7. 直交実験法

7.1 コンセプト

  1. これは、複数の要因と複数のレベルを研究するために使用される実験方法です。
  2. 数学ツールの使用: 直交表

7.2 適用範囲

  1. 構成テスト: さまざまな構成ユニットと構成項目を調整することにより、ソフトウェア システムは最も効果的なサービス効果を得ることができます。
  2. 互換性テスト
  3. 機能テスト: 複数の入力ボックスがあり、各入力ボックスには異なる数の値があります。

適用可能な機能

  1. 均一に分散した
  2. きちんとしていて比較可能な

使用手順

ここに画像の説明を挿入

  • 直交表を使用してユースケースを設計した後は、自分の経験に基づいて不足しているユースケースを確認し、補足する必要があります。直交実験法はペアワイズマッチングであるため、3 つのレベルのマッチングは自動的に失われます。ユースケースを検討するときは、3 つの組み合わせから始めます。

8. 一般的なテストケース設計方法のまとめ

ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/Lucifer__hell/article/details/131534178