4

スタックオーバーフローをすばやく検索しても何も見つからなかったので、ここに私の質問があります。

2 つのアプリケーションが毎日相互に同期して膨大な量のデータの同期を維持するアプリケーションのテスト戦略を書き留めようとしています。 ここに画像の説明を入力

膨大な量のデータなので、すべてをクロスチェックしたくはありません。しかし、データ同期が発生するたびにランダム チェックを実行したいだけです。そのようなシステムでは、ここでどのような戦略が必要ですか?

私はこの2つのアプローチを考えています。1) すべてのデータのカウントを取得し、両方が同じであることをクロス チェックします。 2) ランダムな 5 つのデータ エントリを選択し、それらのプロパティが同期していることを確認します。

どんな提案も素晴らしいでしょう。

4

1 に答える 1

2

必要なものはリスク管理と呼ばれ、ソフトウェア テストではソフトウェア リスク管理と呼ばれます。
あなたの質問は、あなたがテストしようとしているものを「テストする方法」ではなく、あなたが何をしているのか、なぜそれをしているのかを説明する方法についてのようです（質問に基づいて、あなた自身にもこの説明が必要だと思います...）。

SRM をテスト戦略に追加するには、次のことを説明する必要があります。

  • ミラーリングされたシステム内のすべてのデータを完全にテストしないことのリスク
  • SRM 対テストされたデータの量を縮小した表 (つまり、テストされたデータの n% のみがテストされた場合のエラーの確率と、-eg- 2n% がテストされた場合)、つまり、-eg!- 失われたデータ/無効なデータ/データの破損の 5% を示しています。 /etc データの x% が ak 分/時間の実行時間でテストされた場合
  • 前のポイントに基づいて、さまざまなオプションに使用されるリソースの内訳 (たとえば、n 時間の HW 負荷 %、使用される工数は y、HW/SW/HR 使用のコストは z USD)
  • 自動化コードのエラー/問題の確率とコスト (つまり、データ比較がうまくいかず、誤検知または誤検知が発生し、DBA、開発、および/またはテストにオーバーヘッドが発生します)
  • SRM オプションを選択した場合 ( !!eg!! 10% のデータをテストして、3% のデータ破損/損失リスクと 0.75% のオーバーヘッド リスク - 偽陽性/陰性結果 -) が実際の失敗、つまりビジネス継続性への言及とデータ、完全性などの損失の影響


他のすべてが頭に浮かび、現在のシステムの現在の問題に実際の好みが 当てはまると感じます。

于 2013-06-24T11:44:06.830 に答える