ほとんどのテストでテストデータを準備する必要があることは誰もが知っています。たとえば、手動テストでは構成データなどの準備が必要な基本データが必要です。自動テストとパフォーマンステストでは、基本を準備する必要があります。既存のデータ、動的操作中に生成されたデータも必要です。これにはデータの概念が含まれます。
1.テストデータの分類
テストデータをいくつかのカテゴリに分類できます。
基本データ：たとえば、一部のコンテンツ管理システムは、サイトのタイトルやフレンドリリンクなどの基本構成データを構成します。
在庫データ：つまり、既存のデータ。たとえば、一部のeコマースサイトをテストする場合、いくつかの商品情報、カテゴリ情報、物流情報などが事前に挿入されます。
動的データ：セッションデータとも呼ばれます。たとえば、電子商取引サイトで商品を公開する機能をテストすると、新しい商品が作成されることがよくあります。
基本的なデータを本番環境と簡単に一致させることができると想像できます。テスト環境のインベントリデータはオンライン環境よりも少なく、テスト環境の動的データはオンライン環境ほど実際にはない場合があります。
ここでは、テストデータの大きさと信頼性について説明する必要があります。
第二に、テストデータの大きさ
ほとんどの場合、テストデータの大きさは環境内であまり生成されません。そのため、テストデータは実際のデータのサブセットにすることができます。
本番環境のような環境またはプレリリース環境がある場合は、オンラインデータの順序でそれを維持するように試みることができます。テスト環境では簡単に測定できないデータ量によって引き起こされるこのような問題は、プレリリース環境でも測定できます。
3.テストデータの信頼性
テスト環境のデータは、実際のユーザーが生成したデータとは異なる場合がよくあります。たとえば、フォーラムシステムをテストする場合、投稿にステッカーが非常に少なく、サイズもちょうど良いかもしれませんが、オンラインユーザーにはさまざまなステッカーがあり、予期しない問題が発生する可能性があります。
4.基本データと在庫データの準備方法
ベースおよびインベントリデータのオンライン環境との整合性が高いほど、テストで問題が見つかる可能性が高くなります。一般的に言えば、あなたは次の戦略を持つことができます
1.フルボリューム+感度低下戦略：オンラインデータを直接かつ定期的に感度低下させ、テスト環境にインポートします。ここでは鈍感化が必須であり、データ漏洩によって引き起こされる問題の重大度は、通常のオンラインバグよりもはるかに深刻です。
2.定量的+鈍感化戦略：オンラインデータの一部のみをアップロードします。たとえば、1000の製品と1000のユーザー情報のみをプルしてから、鈍感化を行います。ここでの技術的な実装の難しさは比較的高くなります。結局のところ、関連表を整理する必要があります。
3.クローラー戦略：新しいプロジェクト/製品の場合、ガイドするオンラインインベントリデータがないため、友人に行って一部のデータをクロールし、テストのためにテスト環境に導く必要がある場合があります。たとえば、旅行サイトを作成する場合、最初はユーザーの旅行メモがありません。現時点では、同様のサイトにアクセスして、少しクロールしてテストする必要があります。
4.動的データの生成：オンラインにデータがなく、友達やビジネスマンがクロールしない場合は、人間または自動化された方法でデータを生成する必要があります。システムがシンプルな場合は、sqlを使用して実行できますが、複雑な場合は、インターフェイスを呼び出すか、自動化された方法で生成する必要があります。違いがない場合は、一部のデータを手動で作成することもできます。
V.動的データについて
自動化またはインターフェースのテストを行った後、人々はしばしば大量の動的データを生成します。それから質問が来ています。
このデータはどこにありますか？どういう意味？自動で製品を作成する必要がある場合、製品情報と画像アドレスはどこに配置すればよいですか？実際、これは永続的な問題です。
1.ファイルに入れる：xml / csv / json / yamlなど、多くのファイル形式から選択できます。ただし、Excelはお勧めできません。結局のところ、拡張性が高くない独自の形式です。また、Excelがアップグレードされたら、解析コードとライブラリも一度変更する必要があるかもしれませんが、これはお勧めできません。
2.データベースに配置する：いくつかの商品情報をデータベースにクロールしてからデータベースを読み取ることも良い方法ですが、インタビューでよく尋ねられるSQLの使用法にも精通しているほか、データベーストランザクションメカニズムを使用してテストデータをクリーンアップすることもできます。
3.コードで動的に生成：ユーザーの名前、性別、年齢を動的にランダムに生成するなど
データが生成された後、クリーンアップの問題があります。問題のクリーンアップは、実際にはデータのライフサイクルの問題です。テストデータには次のライフサイクルが必要です。
1.短期データ：ユースケースの終了後に削除されたデータ通常、オンラインでのパフォーマンステストのデータは、このような短期データです。
2.長期データ：ユースケースからのデータはそこに配置しても問題なく、常に存在できます。データが多すぎると、テスト環境のパフォーマンスに影響する場合があります
自動実行の頻度は実際には非常に高い可能性があるため、自動テストで不足したデータの短期データを作成し、それをクリアする方法を見つけることをお勧めします。毎回大量のデータが生成される場合、データの大きさは短期的には非常に大きくなる可能性があります。テスト環境のパフォーマンスに影響があります。
以上で、テストデータの作り方はおおまかに理解できましたので、良い提案をさせていただきたいと思いますので、よろしければコメント欄にコメントをお願いします。