12

私は現在、レイヤーの「全範囲」(UI、中間、遍在するデータベース) を持つソリューションをテストしている最中です。

私が現在のチームに到着する前に、さまざまな関連性ルール、並べ替えなどに基づいて、ストアド プロシージャが返す必要がある結果セットを理論的に返すクエリを手動で作成するテスターに​​よって、クエリ テストが行​​われました。

これには、問題の実際のクエリに対してよりも、テスターのクエリに対してより頻繁にバグが報告されるという副作用がありました。

私は、既知の結果セットを実際に操作して、存在するデータを制御するため、それがどのように返されるかを推測できるようにすることを提案しました.

人々は、開発者が作成したものをテストするために独自のクエリを作成することにまだ固執していました。私は多くがまだそうであると思います。これはまったく理想的ではなく、テストのフットプリントを不必要に増やすだけだと思います。

ですから、このようなシナリオをテストするためにどのような方法を使用していますか?また、無秩序なデータを導入することなく、得られる最高のエンドツーエンドのカバレッジには何が理想的であると考えられますか?

私が抱えている問題は、どのテストを行うのに最適な場所かということです。サービスを直接突っ込んで、そのデータセットをストアド プロシージャから取得できるデータセットと比較するだけですか? 私は大まかなアイデアを持っており、これまでのところ十分に成功していますが、ここでまだ重要なものが欠けているように感じます.より良い。

4

9 に答える 9

3

ストアド プロシージャをテストするには、テストする各ユーザーがデータベースの個別のインスタンスを持っている必要があります。これは要件です。環境を共有すると、テストの結果に頼ることができなくなります。彼らは無価値になります。

また、結果が予測可能で安定するように、すべてのテスト後にデータベースを以前の状態にロールバックする必要があります。各テストの後に状態をロールバックする必要があるため、これらのテストは標準の単体テストよりも完了するまでに時間がかかるため、おそらく夜間に実行したいものになるでしょう。

これに役立つツールがいくつかあります。DbUnit もその 1 つです。Microsoft には、DB テストのサポートを含むデータベース プロフェッショナル向けのツール Visual Studio があったと思います。

于 2008-11-03T23:42:38.247 に答える
3

以下にいくつかのガイドラインを示します。

  1. 単体テスト用に分離されたデータベースを使用する (例: 他のテスト実行やアクティビティを行わない)
  2. 同じテスト内でクエリする予定のすべてのテスト データを常に挿入する
  3. テストを作成して、さまざまなボリュームのデータをランダムに作成します。たとえば、1 行から 10 行の間のランダムな数の挿入を行います。
  4. ブールフィールドのランダム挿入や true または false などのデータをランダム化します
  5. 変数のテストでカウントを保持します (例: 行数、真の数)
  6. アサートの場合、クエリを実行し、ローカル テスト変数と比較します
  7. Enterprises Services トランザクションを使用してデータベースを以前の状態にロールバックする

Enterprises Services Transaction テクニックについては、以下のリンクを参照してください。

http://weblogs.asp.net/rosherove/articles/DbUnitTesting.aspx

于 2008-11-03T23:55:11.387 に答える
1

SQLServerCentralには、tsqlUnitと呼ばれるTSQLユニットテストフレームワークに関する記事があります（登録する必要があるかもしれませんが、無料で文字列はありません）。これはオープンソースであり、xUnitフレームワークの伝統に従っています。

これは、SEATTDDパターンに従います。

セットアップ-オブジェクト、テーブル、および/またはデータを操作してテスト条件を準備します

演習-本番コードを呼び出す

アサート-実際の結果が期待される結果と等しいことを確認します

分解-すべてをテスト開始前の状態に戻します。これは、実際にはトランザクションをロールバックすることによって実行されます。これにより、すべてが適切に整理されます。

私は使ったことがありませんが、有望に見え、確かにもっと詳しく見ていきます。

フレームワークはここからダウンロードできます。

于 2008-11-04T22:43:04.433 に答える
1

Django には、データベースの単体テスト機能があります。彼らのデザイン アイデアを借りて、他の環境で再現することができます。

Django 関係者は、Python の標準 unittestTestCaseクラスのサブクラスを提供しています。これは、データベースに既知のフィクスチャ (既知のデータ行のセット) を設定します。

Django (および Python) の場合、JSON データ抽出からデータベースに入力するのが最も簡単です。フィクスチャの他のファイル形式は、他のフレームワークに使用できます。たとえば、Oracle で作業している場合は、CSV ファイルの方が操作しやすいかもしれません。

このTestCaseサブクラスを使用すると、既知のデータ フィクスチャを使用してデータベースを実行する典型的な TestCase を作成できます。

さらに、Django テスト ランナーは、テスト用の一時スキーマを作成します。これは、DDL の作成を含む完全なオブジェクト リレーショナル管理コンポーネントがあるため、Django にとっては簡単です。これが利用できない場合でも、単体テスト用のテスト スキーマを作成して破棄できるように、DDL スクリプトが必要になります。

于 2008-11-04T02:18:41.083 に答える
1

継続的な統合の一環として、データベース クエリの夜間の「ビルド」を実行します。これには、コード内の実際の呼び出しと予想されるアドホック クエリから定期的に更新される一連の DB 呼び出しが含まれます。

これらの呼び出しは、次のことを確実にするためにタイミングが設定されています。

1/ あまり時間がかからない。

2/前夜と（悪い意味で）大きく変わらない。

このようにして、誤ったクエリや DB の変更をすばやくキャッチします。

于 2008-11-03T23:48:30.543 に答える
1

特にこの場合、クエリ プランナーはあなたの味方です。インデックスが期待どおりに使用されていること、およびクエリで追加の作業を実行する必要がないことを確認することを常にお勧めします。スイートにストレス テストが含まれている場合でも、アプリが停止する前に負荷の高いクエリをキャッチすることをお勧めします。

于 2008-11-04T00:02:14.150 に答える
1

開発者とテスターごとに空のデータベースを用意しています。

テストが実行されると、各テストはデータベースをクリアし、使用する予定のデータをロードします。これにより、常に既知の状態が得られます。

その後、同じ DB でいくつかの異なるシナリオを (次々に) テストすることができ、別のテスターのつま先にスタンプを押すことはありません。

これには、データ アクセス自体のテストが含まれます。サービスのテストでは、ほぼ同じことを行いますが、サービスの内部のみをテストします。実際にはサービスをヒットせず、サービス処理クラスのインスタンスを作成し、必要なものすべてを渡します。そうすれば、インフラストラクチャ (メッセージなど) ではなく、コードをテストできます。

于 2008-11-04T00:38:55.700 に答える
0

データベースにクエリを実行した結果ではなく、データベースに送信される SQL をテストすると便利です。

後者を行わないわけではありませんが、データベースを持ち上げすぎるよりも、テストする方がはるかに高速であることがわかりました。

于 2008-11-04T00:31:18.723 に答える