テスト（またはqa）とステージング環境-ステージング環境の機能の説明
この質問 を見ました。私が理解している限り、テスト環境はqa部門がテストを実施することであり、ステージングはprodと同じですが、エンドユーザーから隠されています。
私の質問は：
- ステージングはprodと100％同一である必要がありますか、それともステージングに「混乱した」データが含まれていても問題ありませんか？ステージングdbが本番dbと異なるのはどれだけいいですか？
- ステージング環境から製品環境にテーブルをコピーするのは通常の/標準的な手順ですか？それは、現実の世界で他の会社がそれをしている方法ですか
なぜ私が尋ねているのか（またはどこから来ているのか）
私にはtxtファイルがあり、このファイルの内容をデータベースにダンプする必要があります。 3つの環境があります：開発、テスト、製品。データを開発、テストにダンプできますが、本番にはできません。データを製品データベースに直接ダンプすることはできません。データベースの移動を要求することによってのみ、データを移動できます。次に、誰かがテストから本番にテーブルをコピーします。私の懸念は、テストデータベースでテストを実行しているときにデータの正確性を損なう可能性があることです。データベース移動ドキュメントを送信すると、承認された混乱したデータが本番データベースに送られることになります。もちろん、これは避けたいです。
ステージングは本番環境と100％同一である必要がありますか？
この質問への答えは会社ごとに大幅に異なる可能性があると思います。あなたの会社のさまざまな環境の詳細について、あなたの仕事に精通している誰かと話し合う必要があります。
私の懸念は、テストデータベースでテストを実行しているときにデータの正確性を損なう可能性があることです。データベース移動ドキュメントを送信すると、承認された混乱したデータが本番データベースに送られることになります。
「テスト」環境でのデータの乱用が心配な場合は、開発環境やテスト環境で実行できる変更を安全に行うために、ある種のテストを開発することをお勧めします。これらのテストの形式は作業の範囲によって異なりますが、いくつかの提案には次のようなものがあります。
- 作成したコードに対する直接テスト（「ユニット」または「小規模」テスト）
- ダンプした後にデータベーステーブルを反復処理し、すべてのデータが正しいことを確認するスクリプト
- テストケースの代表的なサンプルをプルして、手動（またはスクリプト）で検証します。
意味のある他の検証形式があるかもしれませんが、特定のシステムのコンテキストがないと、決定的なテストスイートを指すのは困難です。