what is test data test data preparation techniques with example
テストデータとは何か、およびテスト用のテストデータを準備する方法を学びます。
情報技術の革命的な成長の現在の叙事詩では、テスターは通常、ソフトウェアテストのライフサイクルでテストデータの大量消費を経験します。
テスターは、既存のソースからデータを収集/維持するだけでなく、大量のテストデータを生成して、実際に使用する製品の配信における品質の急上昇に貢献します。
したがって、テスターとしての私たちは、あらゆるタイプの機能的および非機能的テストのデータ収集、生成、保守、自動化、および包括的なデータ管理のための最も効率的なアプローチを継続的に調査、学習、および適用する必要があります。
このチュートリアルでは、私は提供します 不適切なデータや不完全なテスト環境のセットアップによって重要なテストケースを見逃さないように、テストデータを準備する方法に関するヒント。
学習内容：
テストデータとは何ですか、なぜそれが重要なのですか
2016年にIBMが実施した調査を参照すると、テストデータの検索、管理、保守、および生成には、テスターの時間の30％〜60％が含まれます。データの準備がソフトウェアテストの時間のかかるフェーズであることは否定できない証拠です。
図1： テスターのTDMに費やされた平均時間
それでも、ほとんどのデータサイエンティストが、モデルの開発時間の50％〜80％をデータの整理に費やしていることは、さまざまな分野で事実です。そして今、法律と個人情報（PII）を検討することで、テスターはテストの過程で圧倒的にまともな関与をするようになります。
今日、テストデータの信頼性と信頼性は、事業主にとって妥協のない要素と見なされています。製品の所有者は、テストデータのゴーストコピーを最大の課題と見なしています。これにより、品質保証に対するクライアントの要求/要件のこの独特な時期に、アプリケーションの信頼性が低下します。
テストデータの重要性を考慮すると、大多数のソフトウェア所有者は、セキュリティ対策において、偽のデータ以下のテスト済みアプリケーションを受け入れません。
この時点で、テストデータとは何かを思い出してみませんか？テストケースの作成を開始して、テスト対象のアプリケーションの特定の機能と開発されたシナリオを検証および検証する場合、欠陥を特定して特定するためのテストを実行するための入力として使用される情報が必要です。
qtpの記述的プログラミングとは
また、バグを特定するには、この情報が正確かつ完全である必要があることを私たちは知っています。これをテストデータと呼びます。正確に言うと、名前、国などは機密ではなく、連絡先情報、SSN、病歴、クレジットカード情報に関するデータは本質的に機密である可能性があります。
データは次のような形式にすることができます。
- システムテストデータ
- SQLテストデータ
- パフォーマンステストデータ
- XMLテストデータ
テストケースを作成している場合は、あらゆる種類のテストの入力データが必要です。テスターは、テストケースの実行時にこの入力データを提供するか、アプリケーションが事前定義されたデータの場所から必要な入力データを選択する場合があります。
データは、アプリケーションへのあらゆる種類の入力、アプリケーションによってロードされるあらゆる種類のファイル、またはデータベーステーブルから読み取られたエントリです。
適切な入力データの準備は、テストセットアップの一部です。 一般的に、テスターはそれを テストベッドの準備 。テストベッドでは、すべてのソフトウェアとハードウェアの要件は、事前定義されたデータ値を使用して設定されます。
データを構築するための体系的なアプローチがない場合 テストケースの作成と実行 その場合、いくつかの重要なテストケースを見逃す可能性があります。テスターは、テストのニーズに応じて独自のデータを作成できます。
他のテスターによって作成されたデータや標準の本番データに依存しないでください。要件に応じて、常に新しいデータセットを作成してください。
ビルドごとに完全に新しいデータセットを作成できない場合があります。このような場合、標準の生産データを使用できます。ただし、この既存のデータベースに独自のデータセットを追加/挿入することを忘れないでください。データを作成する最良の方法の1つは、既存のサンプルデータまたはテストベッドを使用し、テスト用に同じモジュールを取得するたびに新しいテストケースデータを追加することです。このようにして、期間中の包括的なデータセットを構築できます。
テストデータソーシングの課題
テスターが検討するテストデータ生成の領域の1つは、サブセットのデータソーシング要件です。たとえば、100万人を超える顧客がいて、テストには1,000人の顧客が必要です。また、このサンプルデータは一貫性があり、ターゲットグループの適切な分布を統計的に表す必要があります。言い換えれば、テストする適切な人を見つけることになっています。これは、ユースケースをテストするための最も有用な方法の1つです。
また、このサンプルデータは一貫性があり、ターゲットグループの適切な分布を統計的に表す必要があります。言い換えれば、テストする適切な人を見つけることになっています。これは、ユースケースをテストするための最も有用な方法の1つです。
さらに、プロセスにはいくつかの環境上の制約があります。それらの1つは、PIIポリシーのマッピングです。プライバシーは重大な障害であるため、テスターはPIIデータを分類する必要があります。
テストデータ管理ツール 上記の問題に対処するように設計されています。これらのツールは、それらが持っている標準/カタログに基づいてポリシーを提案します。しかし、それはあまり安全な運動ではありません。それでも、自分が何をしているかを監査する機会があります。
現在および将来の課題に対応するために、TDMの実施をいつ/どこから開始すべきかなどの質問を常に行う必要があります。何を自動化する必要がありますか？企業は、人的資源の継続的なスキル開発と新しいTDMツールの使用の分野でのテストにどのくらいの投資を割り当てる必要がありますか？機能テストと非機能テストのどちらからテストを開始する必要がありますか？そして、彼らとしてはるかに可能性の高い質問。
テストデータソーシングの最も一般的な課題のいくつかを以下に示します。
- チームには、十分なテストデータジェネレータツールの知識とスキルがない可能性があります
- テストデータの範囲はしばしば不完全です
- 収集フェーズ中のボリューム仕様をカバーするデータ要件の明確性が低い
- テストチームはデータソースにアクセスできません
- 開発者が本番データにテスターにアクセスできるようにするのが遅れる
- 実稼働環境データは、開発されたビジネスシナリオに基づくテストに完全に使用できない場合があります
- 一定の期間内に大量のデータが必要になる場合があります
- いくつかのビジネスシナリオをテストするためのデータの依存関係/組み合わせ
- テスターは、データを収集するためにアーキテクト、データベース管理者、およびBAとの通信に必要以上の時間を費やします
- ほとんどの場合、データはテストの実行中に作成または準備されます
- 複数のアプリケーションとデータバージョン
- 複数のアプリケーションにわたる継続的なリリースサイクル
- 個人識別情報（PII）を管理するための法律
データテストのホワイトボックス側では、開発者が本番データを準備します。そこで、QAは、AUTのテスト範囲をさらに拡大するために、開発者と連絡を取り合う必要があります。最大の課題の1つは、考えられるすべてのシナリオ（100％テストケース）を考えられるすべてのネガティブケースに組み込むことです。
このセクションでは、テストデータの課題について説明しました。それに応じて解決したので、さらに課題を追加できます。続いて、テストデータの設計と管理を処理するためのさまざまなアプローチを見ていきましょう。
テストデータ準備のための戦略
テスト業界のプレーヤーは、テストの取り組みを強化するためのさまざまな方法と手段を継続的に経験しており、最も重要なのはそのコスト効率を向上させることです。情報技術の進化の短い過程で、ツールが本番/テスト環境に組み込まれると、出力のレベルが大幅に増加することがわかりました。
テストの完全性と完全な範囲について話すとき、それは主にデータの品質に依存します。テストはソフトウェアの品質を達成するためのバックボーンであるため、テストデータはテストプロセスのコア要素です。
図2： テストデータ管理（TDM）の戦略
マッピングルールに基づくフラットファイルの作成。開発者がアプリケーションを設計およびコーディングした本番環境から、必要なデータのサブセットを作成することは常に実用的です。実際、このアプローチにより、テスターのデータ準備の労力が軽減され、既存のリソースを最大限に活用して、さらなる支出を回避できます。
通常、データを作成するか、少なくとも各プロジェクトが最初に持っている要件のタイプに基づいてデータを識別する必要があります。
TDMのプロセスを処理する次の戦略を適用できます。
- 本番環境からのデータ
- クライアントの既存のデータベースからデータを抽出するSQLクエリを取得する
- 自動データ生成ツール
テスターは、ここの図3に示す要素を考慮して、完全なデータを使用してテストをバックアップする必要があります。アジャイル開発チームの残りのメンバーは、テストケースを実行するために必要なデータを生成します。テストケースとは、ホワイトボックス、ブラックボックス、パフォーマンス、セキュリティなど、さまざまな種類のテストのケースを意味します。
この時点で、パフォーマンステストのデータは、特定のワークロードでシステムが応答する速度を決定して、かなりのカバレッジを持つ実際の大量のデータまたは実際の大量のデータに非常に近いものにする必要があることを認識しています。
ホワイトボックステストの場合、開発者は、可能な限り多くのブランチ、プログラムソースコード内のすべてのパス、およびネガティブアプリケーションプログラムインターフェイス（API）をカバーするために必要なデータを準備します。
図3： データ生成アクティビティのテスト
最終的には、ソフトウェア開発ライフサイクルで作業しているすべての人が SDLC ）BAと同様に、開発者と製品所有者は、テストデータの準備プロセスに十分に関与する必要があります。それは共同の努力である可能性があります。それでは、破損したテストデータの問題について説明します。
破損したテストデータ
既存のデータに対してテストケースを実行する前に、データが破損/古くなっていないこと、およびテスト対象のアプリケーションがデータソースを読み取れることを確認する必要があります。通常、複数のテスターがテスト環境でAUTの異なるモジュールを同時に操作している場合、データが破損する可能性が非常に高くなります。
同じ環境で、テスターはテストケースのニーズ/要件に従って既存のデータを変更します。ほとんどの場合、テスターがデータを使い終えると、データはそのままになります。次のテスターが変更されたデータを取得し、テストをもう一度実行するとすぐに、コードエラーや欠陥ではない特定のテストが失敗する可能性があります。
ほとんどの場合、これはデータが破損したり古くなったりして障害につながる方法です。データの不一致の可能性を回避および最小化するために、以下のソリューションを適用できます。そしてもちろん、このチュートリアルの最後のコメントセクションにソリューションを追加することもできます。
- データのバックアップをとる
- 変更したデータを元の状態に戻します
- テスター間のデータ分割
- データの変更/変更については、データウェアハウス管理者を最新の状態に保ちます
テスト環境でデータをそのまま維持するにはどうすればよいですか？
ほとんどの場合、多くのテスターが同じビルドのテストを担当します。この場合、複数のテスターが共通データにアクセスし、必要に応じて共通データセットを操作しようとします。
特定のモジュール用にデータを準備した場合、データセットをそのまま維持する最善の方法は、同じもののバックアップコピーを保持することです。
パフォーマンステストケースのテストデータ
パフォーマンステストには、非常に大きなデータセットが必要です。手動でデータを作成しても、テスト対象のアプリケーションによって作成された実際のデータによってのみ検出される可能性のある微妙なバグが検出されない場合があります。手動で作成することが不可能なリアルタイムデータが必要な場合は、リード/マネージャーにライブ環境から利用できるように依頼してください。
このデータは、すべての有効な入力に対してアプリケーションがスムーズに機能することを保証するのに役立ちます。
理想的なテストデータは何ですか？
データセットの最小サイズですべてのアプリケーションエラーを特定する場合、データは理想的であると言えます。すべてのアプリケーション機能を組み込むが、データの準備とテストの実行にかかるコストと時間の制約を超えないデータを準備するようにしてください。
最大のテストカバレッジを保証するデータを準備する方法は？
次のカテゴリを考慮してデータを設計します。
1）データなし： 空白またはデフォルトのデータでテストケースを実行します。適切なエラーメッセージが生成されるかどうかを確認します。
2）有効なデータセット： アプリケーションが要件に従って機能しており、有効な入力データがデータベースまたはファイルに適切に保存されているかどうかを確認するために作成します。
3）無効なデータセット： 無効なデータセットを準備して、負の値、英数字の文字列入力に対するアプリケーションの動作を確認します。
4）不正なデータ形式： 不正なデータ形式のデータセットを1つ作成します。システムは、無効または違法な形式のデータを受け入れてはなりません。また、適切なエラーメッセージが生成されることを確認してください。
5）境界条件データセット： 範囲外のデータを含むデータセット。アプリケーション境界のケースを特定し、下限条件と上限条件をカバーするデータセットを準備します。
6）パフォーマンス、負荷、およびストレステストのデータセット： このデータセットは大量である必要があります。
このようにして、テスト条件ごとに個別のデータセットを作成することで、完全なテストカバレッジが保証されます。
ブラックボックステストのデータ
品質保証テスターは、統合テスト、システムテスト、およびブラックボックステストと呼ばれる受け入れテストを実行します。このテスト方法では、テスターは、テスト対象のアプリケーションの内部構造、設計、およびコードに何の作業も行いません。
テスターの主な目的は、エラーを特定して特定することです。そうすることで、ブラックボックステストのさまざまな手法を使用して、機能テストまたは非機能テストを適用します。
図4： ブラックボックスのデータ設計方法
この時点で、テスターはブラックボックステストの手法を実行および実装するための入力としてテストデータを必要とします。また、テスターは、指定されたコストと時間を超えずに、すべてのアプリケーション機能を検査するデータを準備する必要があります。
テストケースのデータは、データなし、有効データ、無効データ、不正データ形式、境界条件データ、等価パーティション、決定データテーブル、状態遷移データ、ユースケースデータなどのデータセットカテゴリを考慮して設計できます。テスターは、データセットのカテゴリに入る前に、テスター（AUT）の下にあるアプリケーションの既存のリソースのデータ収集と分析を開始します。
データウェアハウスを常に最新の状態に保つことについて前述したポイントによると、テストケースレベルでデータ要件を文書化し、テストケースをスクリプト化するときにそれらを使用可能または再利用不可としてマークする必要があります。これは、テストに必要なデータが最初から明確に文書化されており、後で後で使用するために参照できるようにするのに役立ちます。
Open EMRAUTのテストデータの例
現在のチュートリアルでは、テスト対象アプリケーション（AUT）としてOpenEMRを使用しています。
=>見つけてください OpenEMRアプリケーションのリンクはこちら あなたの参照/練習のために。
cとc ++の構文
次の表は、テストケースのドキュメントの一部となる可能性があり、テストシナリオのテストケースを作成するときに更新されるデータ要件収集のサンプルのほとんどを示しています。
（（ 注意 ： クリック 拡大表示の画像）
OpenEMRアプリケーションをテストするための手動データの作成
特定のデータセットカテゴリに対してOpenEMRアプリケーションをテストするための手動データの作成に進みましょう。
1）データなし： テスターは、データを提供せずに、OpenEMRアプリケーションのURLと「患者の検索または追加」機能を検証します。
二） 有効なデータ： テスターは、有効なデータを提供して、OpenEMRアプリケーションのURLと「患者の検索または追加」機能を検証します。
3）無効なデータ： テスターは、Open EMRアプリケーションのURLと「患者の検索または追加」機能を検証し、無効なデータを提供します。
4） 違法なデータ形式： テスターは、Open EMRアプリケーションのURLと「患者の検索または追加」機能を検証し、無効なデータを提供します。
1〜4のデータセットカテゴリのテストデータ：
5） 境界条件データセット： データとして指定された値の内側または外側にある境界の入力値を決定することです。
6）等価パーティションデータセット： これは、入力データを有効と無効の入力値に分割するテスト手法です。
5のテストデータthおよび6thOpenEMRのユーザー名とパスワード用のデータセットカテゴリ：
7）デシジョンテーブルデータセット： これは、さまざまな結果を生成するために、入力の組み合わせでデータを修飾するための手法です。このブラックボックステストの方法は、テストデータのすべての組み合わせを検証する際のテストの労力を軽減するのに役立ちます。さらに、この手法により、完全なテストカバレッジを確保できます。
OpenEMRアプリケーションのユーザー名とパスワードのデシジョンテーブルデータセットを以下で参照してください。
上記の表で行われた組み合わせの計算は、以下の詳細情報について説明されています。 4つ以上の組み合わせを行う場合に必要になることがあります。
- 組み合わせの数= 条件の数1の値*条件の数2の値
- 組み合わせの数= 2 ^真/偽の条件の数
- 例：組み合わせの数– 2 ^ 2 = 4
8）状態遷移テストデータセット： これは、システムに入力条件を提供することにより、被テストアプリケーション（AUT）の状態遷移を検証するのに役立つテスト手法です。
例えば、最初の試行で正しいユーザー名とパスワードを入力して、OpenEMRアプリケーションにログインします。システムはアクセスを許可しますが、間違ったログインデータを入力すると、システムはアクセスを拒否します。状態遷移テストは、OpenEMRが閉じる前に実行できるログイン試行回数を検証します。
次の表は、ログインの正しい試行または誤った試行がどのように応答するかを示しています。
9） ユースケーステスト日： これは、特定の機能のエンドツーエンドのテストをキャプチャするテストケースを識別するテスト方法です。
例、EMRログインを開く：
また読む=> データデータ管理技術
優れたテストデータのプロパティ
テスターは、大学のウェブサイトの「試験結果」モジュールをテストする必要があります。アプリケーション全体が統合され、「テストの準備ができました」状態にあると考えてください。 「ExaminationModule」は、「Registration」、「Courses」、「Finance」モジュールにリンクされています。
アプリケーションに関する十分な情報があり、テストシナリオの包括的なリストを作成したと想定します。次に、これらのテストケースを設計、文書化、および実行する必要があります。テストケースの「アクション/ステップ」または「テスト入力」セクションで、テストの入力として受け入れ可能なデータを指定する必要があります。
テストケースに記載されているデータは適切に選択する必要があります。テストケースドキュメントの「実際の結果」列の精度は、主にテストデータに依存します。したがって、入力テストデータを準備する手順は非常に重要です。したがって、これが「DBテスト–テストデータ準備戦略」に関する私の要約です。
テストデータのプロパティ
テストデータは正確に選択する必要があり、次の4つの品質を備えている必要があります。
1）現実的：
現実的には、実際のシナリオのコンテキストでデータが正確である必要があることを意味します。たとえば、「年齢」フィールドをテストするには、すべての値が正で18以上である必要があります。大学への入学候補者が通常18歳であることは明らかです（これはビジネス要件の観点から異なる方法で定義される場合があります）。
現実的なテストデータを使用してテストを行うと、現実的なデータを使用して発生する可能性のあるバグのほとんどをキャプチャできるため、アプリがより堅牢になります。現実的なデータのもう1つの利点は、再利用性であり、新しいデータを何度も作成するための時間と労力を節約できます。
現実的なデータについて話すとき、ゴールデンデータセットの概念を紹介したいと思います。ゴールデンデータセットは、実際のプロジェクトで発生する可能性のあるほぼすべてのシナリオをカバーするデータセットです。 GDSを使用することで、最大のテストカバレッジを提供できます。私は組織で回帰テストを行うためにGDSを使用しています。これは、コードが本番ボックスに入った場合に発生する可能性のあるすべてのシナリオをテストするのに役立ちます。
データベース内の列の特性とユーザー定義を分析し、これらに基づいて現実的なテストデータを生成する、市場で入手可能なテストデータジェネレーターツールはたくさんあります。データベーステスト用のデータを生成するツールの良い例は次のとおりです。 DTMデータジェネレータ 、 SQLデータジェネレータ そして Mockaroo 。
2.実質的に有効：
これは現実に似ていますが、同じではありません。このプロパティは、AUTのビジネスロジックに関連しています。値60は年齢の分野では現実的ですが、卒業または修士課程の候補者にとっては事実上無効です。この場合、有効な範囲は18〜25年です（これは要件で定義されている場合があります）。
3.シナリオをカバーするための多用途：
偽のメールアドレスを取得する方法
1つのシナリオにはその後にいくつかの条件が存在する可能性があるため、データを慎重に選択して、最小のデータセットで単一のシナリオの最大の側面をカバーします。結果モジュールのテストデータを作成するときは、プログラムをスムーズに完了している正規の学生の場合だけを考慮しないでください。同じコースを繰り返し、異なる学期または異なるプログラムに属している学生に注意を払ってください。データセットは次のようになります。
| 氏＃ | 学生証 | Program_ID | Course_ID | グレード |
| 1 | BCS-2011年秋-朝-01 | BCS-F11 | CS-401 | に |
| 二 | BCS-Spring2011-Evening-14 | BCS-S11 | CS-401 | B + |
| 3 | MIT-2010年秋-午後-09 | MIT-F10 | CS-401 | に- |
| ..。 | ..。 | ..。 | ..。 | ..。 |
他にもいくつかの興味深くトリッキーなサブ条件があるかもしれません。例えば。学位プログラムを完了するための年数の制限、コースを登録するための前提条件のコースに合格する、最大数。学生が1学期などに登録できるコースの数。これらすべてのシナリオを有限のデータセットで賢くカバーするようにしてください。
4.例外的なデータ （該当する/必要な場合）：
発生頻度は低いが、発生時に高い注意が必要な特定の例外的なシナリオが存在する場合があります。障害のある学生に関連する問題。
例外的なデータセットのもう1つの良い説明と例は、次の画像に示されています。
取り除く：
テストデータは、現実的で、有効で、用途が広い場合、優れたテストデータとして知られています。データが例外的なシナリオにも対応できる場合は、追加の利点があります。
テストデータの準備技術
テストデータの重要なプロパティについて簡単に説明し、データベーステストを実行する際にテストデータの選択がどのように重要であるかも詳しく説明しました。それでは、 ' テストデータを準備するためのテクニック ' 。
テストデータを準備する方法は2つだけです。
方法＃1） 新しいデータを挿入する
クリーンなDBを取得し、テストケースで指定されているようにすべてのデータを挿入します。必要なデータと必要なデータがすべて入力されたら、テストケースの実行を開始し、「実際の出力」と「期待される出力」を比較して「合格/不合格」列に入力します。簡単そうですね。しかし、待ってください、それはそれほど単純ではありません。
いくつかの本質的かつ重大な懸念は次のとおりです。
- データベースの空のインスタンスが利用できない可能性があります
- 挿入されたテストデータは、パフォーマンスや負荷テストなどの一部のケースをテストするには不十分な場合があります。
- データベーステーブルの依存関係のため、必要なテストデータを空のDBに挿入するのは簡単な作業ではありません。この避けられない制限のために、データ挿入はテスターにとって難しい作業になる可能性があります。
- 限られたテストデータを挿入すると（テストケースのニーズに応じて）、大規模なデータセットでのみ見られる問題が隠される可能性があります。
- データ挿入の場合、複雑なクエリや手順が必要になる場合があり、このためには、DB開発者からの十分な支援または支援が必要になります。
上記の5つの問題は、テストデータの準備のためのこの手法の最も重要で最も明白な欠点です。ただし、いくつかの利点もあります。
- DBには必要なデータしかないため、TCの実行はより効率的になります。
- テストケースで指定されたデータのみがDBに存在するため、バグの分離に時間をかける必要はありません。
- テストと結果の比較に必要な時間が短縮されます。
- 整理整頓されたテストプロセス
方法＃2） 実際のDBデータからサンプルデータサブセットを選択します
これは、テストデータを準備するための実行可能でより実用的な手法です。ただし、適切な技術スキルが必要であり、DBスキーマとSQLの詳細な知識が必要です。この方法では、一部のフィールド値をダミー値に置き換えて、本番データをコピーして使用する必要があります。これは本番データを表すため、テストに最適なデータサブセットです。ただし、データのセキュリティとプライバシーの問題により、これが常に実行可能であるとは限りません。
取り除く：
上記のセクションでは、テストデータの準備手法について説明しました。つまり、新しいデータを作成するか、既存のデータからサブセットを選択するかの2つの手法があります。両方とも、選択したデータが、主に有効および無効なテスト、パフォーマンステスト、およびnullテストのさまざまなテストシナリオをカバーするように実行する必要があります。
最後のセクションでは、データ生成アプローチについても簡単に説明します。これらのアプローチは、新しいデータを生成する必要がある場合に役立ちます。
テストデータ生成アプローチ：
- 手動テストデータの生成： このアプローチでは、テストケースの要件に従って、テスターがテストデータを手動で入力します。これはプロセスに時間がかかり、エラーが発生しやすくなります。
- 自動テストデータ生成： これは、データ生成ツールの助けを借りて行われます。このアプローチの主な利点は、その速度と精度です。ただし、手動のテストデータ生成よりもコストが高くなります。
- バックエンドデータインジェクション ：これはSQLクエリを介して行われます。このアプローチでは、データベース内の既存のデータを更新することもできます。これは迅速かつ効率的ですが、既存のデータベースが破損しないように非常に注意深く実装する必要があります。
- サードパーティツールの使用 ：市場には、最初にテストシナリオを理解し、それに応じてデータを生成または挿入して幅広いテストカバレッジを提供するツールがあります。これらのツールは、ビジネスニーズに応じてカスタマイズされているため、正確です。しかし、それらはかなり高価です。
取り除く：
データ生成をテストするには、次の4つのアプローチがあります。
- ハンドブック、
- オートメーション、
- バックエンドデータインジェクション、
- およびサードパーティのツール。
それぞれのアプローチには、独自の長所と短所があります。ビジネスとテストのニーズを満たすアプローチを選択する必要があります。
結論
業界標準、法律、および実施されたプロジェクトのベースラインドキュメントに準拠した完全なソフトウェアテストデータを作成することは、テスターの中心的な責任の1つです。テストデータを効率的に管理すればするほど、実際のユーザー向けに合理的にバグのない製品を展開できるようになります。
テストデータ管理（TDM）は、課題の分析に基づいたプロセスであり、信頼性と最終出力（製品）の完全なカバレッジを損なうことなく、特定された問題に適切に対処するための最良のツールと方法を導入および適用します。
データを生成するためのツールの使用を含め、テスト方法を分析および選択するための革新的で費用効果の高い方法を検索するための質問を常に考え出す必要があります。適切に設計されたデータにより、マルチフェーズSDLCのすべてのフェーズでテスト対象のアプリケーションの欠陥を特定できることが広く証明されています。
私たちは創造的であり、アジャイルチームの内外のすべてのメンバーと参加する必要があります。データを管理することでAUTへのプラスの影響を最大化するために、継続的な技術的な議論を続けることができるように、フィードバック、経験、質問、コメントを共有してください。
適切なテストデータの準備は、「プロジェクトテスト環境のセットアップ」の中核部分です。完全なデータがテストに利用できなかったというテストケースを見逃すことはできません。テスターは、既存の標準的な本番データに加えて、独自のテストデータを作成する必要があります。データセットは、コストと時間の点で理想的である必要があります。
標準の本番データに依存するのではなく、創造性を発揮し、独自のスキルと判断を使用してさまざまなデータセットを作成します。
パートII- このチュートリアルの第2部は、 「」 GEDISStudioオンラインツールを使用したデータ生成のテスト 」。
テスト用の不完全なテストデータの問題に直面しましたか？どのように管理しましたか？ このディスカッションのトピックをさらに充実させるためのヒント、経験、コメント、および質問を共有してください。