test data management concept
前回のチュートリアルでは、 テスト環境の欠陥を最小限に抑えるためにテストベッドを準備する方法 。同じチュートリアルを続けて、今日は学びます テスト環境をセットアップして維持する方法と重要テストデータ管理テクニック。
テスト環境のセットアッププロセス
テスト環境の最も重要な要素は、エンドユーザー環境にできるだけ近い場所でテスト環境を複製することです。一般に、完全な製品またはシステムが出荷されるため、エンドユーザーが自分で構成またはインストールを実行することは期待されていません。したがって、 その定義では、テストチームでさえそのような構成を明示的に実行する必要はありません。
純粋にテスト目的でそのような構成が必要な場合（ただし、エンドユーザー向けに構成されます）、管理者を特定する必要があります。開発環境を構成する管理者は、テスト環境を構成する管理者と同じである必要があります。
開発チーム自体がインストール/構成で主導権を握る場合、テスト環境でも同じことを行うのを支援する必要があります。
例えば、 さまざまなOSプラットフォームなどのシステムでアプリケーション（関連するミドルウェアをインストールおよび構成する）をテストする必要がある場合-これに対処する最善の方法は、を使用することです。 仮想化またはクラウド環境 。
すべてのアプリケーションと必要なミドルウェアが正しくインストールおよび構成されているマスターシステムを用意します。次に、このシステムをキャプチャしてマスターイメージにし、この同じイメージから複数のインスタンスを複製して、各ユーザーがテスト対象のアプリケーションを備えた専用システムを持っているように感じられるようにします。
以下は、テスト環境プロセスに伴うものの図解です。
テスト環境のセットアッププロセス
学習内容：
テスト環境のメンテナンス
課題はあるものの、テスト環境の準備については多くのことが語られていますが、これは間違いなく、テスト環境の保守や標準化を必要とする根拠以上のものです。多くの場合、テスターは環境やセットアップの問題のためにテスト時間を失います。
オペレーティングシステムとハードウェアおよびソフトウェアの範囲が急速に増加しているため、ニーズに対応するために、環境は本質的にほぼ動的である必要があります。テストチームは、優れたテスト管理プロセスを備えた高品質の製品を提供していることを確認できます。これにより、限られたリソースを最適に使用できるようになります。
テスト環境の効果的なメンテナンスを確実にするための重要なポイント
テスト環境として、ほとんどの場合、異種のプラットフォームとスタックが含まれています。以下に、テスト環境の効果的なメンテナンスを確実にするためのいくつかの重要なポイントを示します。
＃1）効果的な環境の共有と配布：
すでに前述したように、テスト環境の準備における重要な課題の1つは、多くのチームまたは人々がテスト目的で同じリソースのセットを使用する必要があることです。したがって、スケジュールを遅らせることなく、すべてのチームと人々のニーズに応える適切な共有メカニズムを開発する必要があります。
これは、以下に関するすべてのデータが含まれるリポジトリまたは情報リンクを維持することによって実現できます。
- 環境を使用している人、
- 環境が自由に使用できる場合
- 環境使用時間の分布を正確に入力する方法。
リソースの要件が大きいのか、リソースの可用性が限られているのかを事前に判断することで、大量の混乱が自動的に無効になります。
これの2番目の側面は、それぞれのチームのリソース要件を再検討することです。 テストサイクル そして、どのリソースがあまり頻繁に使用されていないかを探します。それらの特定のリソースを、必要になる可能性のある新しいリソースまたはシステムに置き換えることができるかどうかを分析します。
＃2）健全性チェック：
一部のテスト要件では、包括的なテストセットアップまたはセットアップが必要です。これには、非常に時間がかかる複雑な手順が含まれます。これは特に、 エンドツーエンドのテスト これには、2つ以上のコンポーネントが連携して機能することが含まれます。したがって、同じテスト環境を複数のチームで再利用する必要がある場合があります。
このような場合、環境全体をよく理解し、さまざまなチームがどのようなテストを実行しているかを照合することで、それぞれのチームに特定のリソースを提供するのに役立つ合理的な図を描くことができます。
上記の要因を考慮すると、基本的な健全性テストを実行できます。これは、個々のチームのテストを迅速化するのに役立ちます。または、これらの健全性チェックの結果として環境に変更や修正が必要な場合は、すぐに警告します。
＃3）停止を追跡する：
テスト環境を所有するすべてのチームが持っているのと同じように、組織には、グローバルサポートチームによって維持されているすべての可能なテスト環境があります。
さらに、テスト環境を所有するチームがファームウェア/ソフトウェアのアップグレードの場合に独自のローカルダウンタイムを持っているように、グローバルチームも、すべての環境が停電またはネットワークの停止を伴う可能性のある最新の標準に準拠していることを確認する必要があります。
したがって、テスト環境を維持している人は、発生する可能性のあるそのような停止を監視し、それに応じて作業を計画するように事前にテストチームに通知する必要があります。
＃4）可能な限り仮想化する：
これは、環境を共有してテストを実行する必要があり、リソースの最適化が切実に必要な場合にも非常に重要です。そのような場合、テスト目的でクラウドなどの仮想化環境を使用することが答えです。
このような環境を使用する場合、テスターが行う必要があるのは、インスタントを提供することだけです。このインスタンスがプロビジョニングされると、専用のOS、データベース、ミドルウェア、自動化フレームワークなどのさまざまなリソースをすべて含む独立したテストベッドまたはテスト環境が形成されます。 、などはテストに必要です。
テストが終了すると、これらのインスタンスを破棄できるため、組織のコストを大幅に削減できます。クラウド環境は、機能検証テスト、自動化テスト領域に特に役立ちます。
＃5）回帰テスト/自動化：
品質保証と品質管理
新しい機能や機能が開発されているときは、 回帰テスト これらの機能については、リリースサイクルごとに実行する必要があります。したがって、後部では、回帰テストのテスト環境は同じデータを使用して同じテストセットアップで実行されているように見えますが、実際には、実装されている機能に応じてリリースごとに絶えず進化しています。
すべての製品リリースサイクルには、1回以上の回帰テストがあります。したがって、製品リリースサイクルごとに回帰テスト環境を確立し、サイクル内でそれらを再利用することで、テスト環境の安定性を確実に表現できます。
自動化フレームワークを開発し、回帰テストに自動化を使用すると、テスト環境の効率を改善するのにも役立ちます。自動化では、環境が安定しており、発生した欠陥が純粋に機能/コード指向であると想定されるためです。
＃6）一般的なガバナンス：
テスト環境のハードウェアまたはソフトウェアに問題がある場合、ラボを保守している人が内部で修正できない場合は、適切な人にこれらの問題を転送して修正を確実にする必要があります。
例えば、 テストによって、現在の環境で使用されているファームウェアまたはソフトウェアの制限を含む欠陥が発生した場合、これは通常、環境メンテナンスの責任者だけが修正することはできません。
したがって、コンシューマー（この場合はテスター）は、適切なサービス要求を出すように求められる必要があります。これらは適切なベンダーまたはチームに転送する必要があり、次のバージョンで特定の問題が修正されるように、定期的に調整を行う必要があります。
ガバナンスのもう1つの側面は、詳細な環境レポートを経営陣または利害関係者に随時提供することです。これは、透明性を発揮するのに役立ち、分析の良い基盤を形成します。
テストデータの準備
それでは、後半部分を見てみましょう。 テストベッドの作成–テストデータの設定が含まれます 。テスト環境についてこのように大きな塊が言われているので、テスト環境の真の本質、その堅牢性、および効率は、テストデータで測定できます。定義上、テストデータは、テスト対象のソフトウェアコードに与えられるあらゆる種類の入力です。
テストケースの設計にはかなりの時間を費やしていますが、テストデータが重要である理由は、あらゆる種類のシナリオに対して完全なテストカバレッジを保証し、それによって品質を向上させるためです。ハッピーパステストまたはポジティブパステストに必要なテストデータがいくつかある可能性があります。
他のいくつかのデータは、エラーまたはネガティブテスト用に設計できます。これは、異常な状況に置かれたときにアプリケーションがどのように実行されるかを発見するのに非常に役立ちます。
テストデータは通常、テキストの実行が始まる前に作成されます。これは、すべてのテスト環境に独自の複雑さのセットがあるため、またはデータ自体の準備が時間のかかるプロセスになる可能性があるためです。したがって、一般的に、テストデータソースは、内部開発チームまたはコードまたは機能を消費するエンドユーザーである可能性があります。
例えば、機能テスト
機能テストまたはブラックボックステストを実行する必要がある例を見てみましょう。ここでの目的は、指定された要件を満たすためにコードが機能的になければならないことです。
したがって、そのような場合–テストケースの準備では、通常、次の種類のデータをカバーする必要があります。
- ポジティブパスデータ： 開発ユースケースドキュメントを参照として、これはポジティブパスシナリオの実行と一般的に同期しているデータです。
- ネガティブパスデータ： これは、コードの正しい機能動作に関して一般に「無効」と見なされるデータです。
- ヌルデータ： アプリケーションまたはコードがそのデータを予期している場合、データを提供しません。
- 誤ったデータ： データが不正な形式で提供された場合のコードのパフォーマンスの決定。
- 境界条件データ： インデックスまたは配列から提供されるデータをテストして、コードのパフォーマンスを判断します。
テストデータは、製品または機能が完全に破損する可能性がある場所を特定する上で重要な役割を果たします。テストのさまざまなフェーズで、テスト環境に提供されるデータの種類をポーリングして検証する練習を常に行ってください。
テストデータ管理
テストデータが製品の品質を保証する上で非常に重要な役割を果たす場合、その管理と合理化は、顧客にリリースする必要のある製品の品質保証においても同様に重要な役割を果たすと言っても過言ではありません。
テストデータ管理とベストプラクティスの必要性：
＃1） 多数の組織が 急速に変化するビジネス目標 エンドユーザーのニーズに応えるため、適切なテストデータがテストの品質を決定するのに役立つことは言うまでもありません。これには、それぞれのテスト環境に正確な種類のデータを設定し、動作パターンを監視することが含まれます。
すでに説明したように、テストチームの時間の大部分は、テストデータとそれに関連するタスクの計画に費やされます。多くの場合、適切なテストデータが利用できないため、機能のテストが大幅に妨げられる傾向があり、完全なテストカバレッジに関して重大な課題が発生します。
＃二） また、特定のテスト要件についても テストデータは常に更新する必要があります 。これ自体が、絶え間ないやり直しのためにサイクルに多くの遅延を引き起こし、それはまた、市場に到達するアプリケーションのコストを増加させます。
また、出荷される製品が大規模な組織内のさまざまなワークグループユニットに関与している場合、テストデータの作成と更新には、これらのワークグループ間の複雑なレベルの調整が必要になります。
＃3） テストチームは、適切なテストを確実にするために可能なすべての種類のデータを作成する必要がありますが、これを行うと、すべての異なる種類のデータをある種のリポジトリに保存する必要があることも考慮する必要があります。
リポジトリを持つことは良い習慣ですが、過剰な 不要なデータ これらの大きなデータチャンクを格納するためのストレージスペースが大幅に増えるだけでなく、このリポジトリのバージョンメンテナンスとアーカイブがない場合、問題のテストに適切なデータをフェッチすることがますます困難になります。
ほとんどの組織は、一般に、テストデータに関してこれらの一般的な課題に直面しています。したがって、これらの課題の程度を最小限に抑えるために実施する必要のあるいくつかの管理戦略が必要です。
以下は、テストデータを管理し、テストのニーズに関連するようにするための推奨される方法論です。次のプラクティスは非常に基本的で一般的であり、ほとんどの組織で一般的に機能します。それがどのように採用されるかは、純粋にそれぞれの組織の裁量です。
テストデータ管理戦略
＃1）データの分析
通常、テストデータは実行するテストケースに基づいて作成されます。たとえば、システムテストチームでは、 エンドツーエンドのテストシナリオ テストデータの設計に基づいて特定する必要があります。これには、1つ以上のアプリケーションが機能することが含まれる場合があります。
ワークロード管理を行う製品について考えてみましょう。これには、管理コントローラーアプリケーション、ミドルウェアアプリケーション、データベースアプリケーションがすべて相互に関連して機能することが含まれます。同じものに必要なテストデータが散在する可能性があります。効果的な管理を確実にするために、必要となる可能性のあるすべての異なる種類のデータの徹底的な分析を行う必要があります。
＃2）本番環境をミラーリングするためのデータ設定
これは通常、前のステップからの拡張であり、エンドユーザーまたは本番シナリオがどのようなものになるか、およびそれらに必要なデータを理解することができます。そのデータを使用して、そのデータを現在のテスト環境に現在存在するデータと比較します。この新しいデータに基づいて、作成または変更する必要がある場合があります。
＃3） テストデータのクリーンアップの決定
現在のリリースサイクル（リリースサイクルが長期間にわたる可能性がある）のテスト要件に基づいて、上記のポイントで述べたように、テストデータを変更または作成する必要がある場合があります。このテストデータはすぐには関係ありませんが、後で必要になる場合があります。したがって、テストデータをいつクリーンアップできるかを判断する明確なプロセスを策定する必要があります。
＃4）機密データを特定して保護する
多くの場合、アプリケーションを適切にテストするために、非常に機密性の高いデータが大量に必要になる場合があります。 例えば、 クラウドベースのテスト環境は、さまざまな製品のオンデマンドテストを提供するため、一般的な選択肢です。
ただし、クラウドでユーザーのプライバシーを保証するのと同じくらい基本的なことが懸念の原因です。したがって、特にユーザー環境を複製する必要がある場合は、機密データを保護するメカニズムを特定する必要があります。このメカニズムは、使用されるテストデータの量によって大きく左右されます。
＃5）自動化
繰り返しテストを実行したり、異なる種類のデータで同じテストを実行したりするために自動化を採用するのと同じように、テストデータの作成を自動化することもできます。これは、テスト中にデータに関して発生する可能性のあるエラーを明らかにするのに役立ちます。これを行うための可能な方法は、連続したテスト実行からのデータのセットによって生成された結果を比較することです。次に、この比較プロセスを自動化します。
＃6） 中央リポジトリを使用した効果的なデータ更新
これは断然最も重要な方法論であり、データ管理を実装するための中心を形成します。上記のすべてのポイント、特にデータのセットアップ、データのクリーンアップに関するポイントは、直接的または間接的にこれと相互に関連しています。
さまざまな種類のテストに必要となる可能性のあるすべての種類のデータを含む中央リポジトリを維持することにより、テストデータを作成するための多くの労力を節約できます。これはどのように行われますか？連続するテストサイクルで、新しいテストケースまたは変更されたテストケースのいずれかについて、データがリポジトリに存在するかどうかを確認します。存在しない場合は、最初にそのデータをテスト環境にフィードします。
次に、これは将来の参照のためにこのリポジトリに送信できます。これで、連続したリリースサイクルで、テストチームはこのデータのすべてまたはサブセットを使用できます。利点は非常に明白ではありませんか？頻繁に使用されるデータのセットによっては、古いデータを簡単に削除できるため、正しいデータが常に存在するようになり、不要なデータを保存するためのコストが削減されます。
次に、このリポジトリのいくつかのバージョンを保存したり、必要に応じて修正したりすることもできます。リポジトリのバージョンが異なると、データのどの変更がコードの破損を引き起こす可能性があるかを特定するための回帰テストに大いに役立ちます。
結論
テスト環境は、すべてのテストチームで最も重要である必要があります。すべてのリリースサイクルは、信頼性が低く計画外のテスト環境と戦うために、多くの新しい課題をもたらします。
革新的な対策として、多くの組織は現在、よりスムーズなリリースサイクルを確保するために、テスト環境の効果的なメンテナンスのための特定のフレームワークを確立する専用のテスト環境メンテナンスチームを編成するなどの戦略を実施しています。
テストの改善は、テストデータ管理を合理化することの明らかな効果にすぎません。その重要な本質は、製品の信頼性に妥協することなく、組織に費用効果の高いソリューションを保証することです。
テスト環境の管理方法とテストデータの準備方法を教えてください。ヒントを追加したいですか？